@denis_ju said in Alerts from "Signal Android App"!: I spoke for Vodafone Albania not in France. I do not understand this statement after reading your first. I would check out all destination IPs in the above image before disabling ... do a whois and reverse IP ... you can use Google to look up each ET Trojan above ... welcome to IDS/IPS.

@gspatton I think the point with enabling Snort on LAN is that you have control of what kind of traffic is going out from the network. Let say you have critical tools on LAN and multiple developers with access to those servers. They can misconfigure or install some malicious software. IPS/IDS will detect it once such application tries to connect to the Internet and based on rules configured on IPS/IDS will block such traffic. At least that how I see it. Most important you will know something is not right and start further investigation. Can you use other tools for that - sure, but IPS might actually save your bacon :)

@nogbadthebad Thank you for all the help! I finally got what I needed, although I'm not sure what to do with it. I was concerned about Snort alerts for DNS lookup for .to top level domains, because we seem to get rather a lot of them. .to domains have plenty of legitimate uses, but one of our important clients is convinced that most .to domains are in use for malware purposes, which may or may not be accurate. Having now had the opportunity to examine numerous .to DNS requests, I'm concerned because blocking them seems to also be blocking some important access. (The first one I looked at was yelp.to.)

@rogerboomhouser said in Snort no long running: GUI, status>system thanks, for the info, and now my is working to.

The rule has been fixed.. if you force update the rules now, Snort is happy again.

For what it's worth, rebooting my pfSense box seems to have stopped this for now.

Added to that : for all this to work, you have to install certs on every client device, certs being used so that client device can use and trust pfSense as a proxy, so pfSense can do the real MITM job. All this, on paper, is pure dynamite. In reality, its far better then that.

Problem is solved. The service provider gave an incorrect IP. I did not notice

@teamits I did that...twice. It blew right through with no issues. It happens after some time. And I cant see anything in the logs. Only way to circumvent it, is to set the Remove Blocked Hosts Interval to anything else than Never.

@rtw915 said in SNORT SID Mgmt Disable not working: @bmeeks So, I was wrong! It was a "zombie" process. I thought by restarting the Snort service it would kill it, but it did not. I Called Netgate to solve a PHP crashing issue due to Snort and he showed me how to kill a hung process. It is now working! No, restarting won't kill a zombie process. By definition those will not respond to anything from the GUI. They won't stop nor see any changes to the configuration. Those can happen if something causes pfSense to rapidly issue a series of "restart all packages' commands. One trigger is your WAN IP changing quickly. Another possibility is Snort in the middle of an auto-restart due to a rules update and during that short interval pfSense issues a "restart all packages" command. That can result in two copies of Snort on the same interface, but one of those copies will not respond to the GUI at all. The final thing that can lead to zombie Snort processes is the use of the Service Watchdog package to monitor Snort. That package does not understand how the internals of Snort are plumbed, and it therefore does not monitor everything necessary to adequately determine if Snort is running correctly. Also, it does not realize Snort stops and then restarts itself during a rules update (or when the admin manually cycles it via the GUI icons on the INTERFACES tab). When Service Watchdog sees the service down, it immediately calls the shell scrip to restart, but there may already be a restart in progress. Thus you can have two instances running on the same interface.

@cobrax2 said in Some "leakage" of packets will occur: @bmeeks Lol you are right! Btw, is there a way to have dnsbl without pfblockerng? Now i have it just as you said, but disabled ip filtering in pfblocker, and snort has a a few et and free vrt rules. Thing are working ok, just some instability (kernel panic sometimes that i have yet to discover why, for now swapped ram but still had a crash when i changed dns to not push dns server from pppoe to clients) Thanks again! I'm not an expert on the DNSBL thing, but in terms of GUI support you kind of need pfBlockerNG-devel in order to implement the DNSBL feature with unbound. That's because the pfBlockerNG-devel GUI code handles the messy tasks of configuring the Python module and managing other configuration settings required to make DNSBL work. You could certainly configure all that on your own via the command line, but it would not be as easy as "click this, click that" like it is in the GUI. As for the instability, that can happen as you burden the firewall with more and more things to keep track of while blocking. Adding millions of IP addresses to block from some list, and comparing each incoming packet against each IP on that list is a lot of CPU work and takes lots of state table entries and RAM. However, a single "deny all" rule is the ultimate in efficiency .

@cool_corona I think they all move around upon new install ... I just reset to how I originally had it manually.

The install is not completing successfully. The very last step of the install is creating the menu and service entries. Because those are missing for you, that means the install is not finishing. Most likely this is the same PHP crash bug that is impacting 2.5 CE and 21.02_1 boxes (SG-3100 boxes in particular). If this is the same bug, it's not a problem with the package as the same code works fine on other systems. It is something wrong with PHP on the SG-3100 appliances with the 32-bit ARM chip.

@bmeeks Ok thank you for that information. I do use AV on my clients, and install OS and browser updates (literally) daily.

@bmeeks I just finished updating to 21.02_1 so maybe I'll be in business now! I saw the option of the Deprecated 2.4.5_1 but my thinking was "let's go with the latest reliable version"....

@bmeeks it doesn't allow it, as it says the interface is not supported, but thanks for the confirmation

If using i211 interfaces which support netmap, hardware and tcp offloading, etc. which is the best (most efficient setup to use) i.e. Legacy - with hardware Checksum offloading hardware TCP segmentation offloading hardware Large Receive offloading Inline - with no hardware Checksum offloading no hardware TCP segmentation offloading no hardware Large Receive offloading

@bmeeks Hello and Thanks for your reply. All three off the check boxes are disabled per the configuration instructions.