@itsupport1212121 I don't currently have an open Suricata session in front of me, but from memory the settings let you select a maximum size for the packet log in megabytes and a limit on the number of captured packets. So the actual disk consumption is determined by the size of each packet (typically 1500 bytes) and how many packets you save. The log size limit is like an override that prevents the log from growing too large. All log data lives in /var/log/suricata and then in a sub-directory underneath for each configured interface. The sub-directory will be named with the physical interface name combined with a random GUID.

@zermus said in WAN interface keeps dropping out of snort: Years of using pfSense I would normally tend to agree with you, but that's the case. Under Snort Interfaces, if I use a heavy ruleset, it just somehow deletes itself out. There is no HA/Sync in this setup, it's a standalone box. The interface doesn't PHYSICALLY DISAPPEAR of course (I'm literally imagining a ghost going in and stealing my Intel NIC out of the box here), but it's dropping out of Snort Interfaces, exactly like someone goes in and deletes the WAN interface from Snort where I have to re-set it all back up again. The only correlation I can find is using a heavy rulset, which in the past was never a problem up until recently. I'm not sure how recent because I just noticed my WAN interface was missing about a week ago when I normally never had a need to go in there and check it. I'm not sure how it would resort to a previous config, because when I set this box up about 2 years ago, setting up Snort on the WAN/LAN was one of the first things I did. I'm not disputing what you are seeing, but I see absolutely no failure mechanism of any kind within the GUI PHP code that could result in a Snort interface being deleted. Deleting an interface requires a manual action. Go to DIAGNOSTICS > BACKUP AND RESTORE in the pfSense menu and then click the Config History tab. Examine the history closely to see what you find. When Snort deletes an interface via user action, it logs a message in the config history. The only part of the PHP GUI code that can delete an interface resides within the INTERFACE SETTINGS tab, and that code will always log a config history message as well as log a message in the pfSense system log when it removes an interface.

@davetheriault said in Snort Blocking Host No Matter What: Ya. I've tried 'removing' the individual entry in Blocked Hosts. And I have also tried the 'Clear - All blocked hosts will be removed' option each time I try to fix the issue. After I clear it from the Blocked Hosts table, I am able to visit the host with one successful page load, but it immediately get's re-added to the Blocked Hosts table by snort, and I can't continue or reload the page from that host, no matter what rules I have suppressed or pass lists I have created. I know of only two ways what you describe can physically happen. You are disabling the wrong rule (i.e., you are not disabling the rule that is actually firing) or else multiple rules are firing and you still haven't found them all; There is another duplicate Snort process running on the interface that is not responding to your rule changes. That can happen in rare circumstances. To see, run this command from a shell prompt on the firewall: ps -ax |grep snort You should see only a single Snort process listed for each configured interface. If you see more than one per interface, stop Snort in the GUI and then kill any remaining Snort processes from the command line shell. As for the Pass List "Snort_Pass_List" shown in your screen capture, do you have that list assigned to the Snort interface on the INTERFACE SETTINGS tab? There is a drop-down selector on that tab where you select the Pass List you want to use for the interface. Make sure "Snort_Pass_List" is selected, save the change, and then restart Snort on the interface. Using a custom Pass List is a two step process: (1) first create the list; and then (2) go to the INTERFACES SETTINGS tab and assign the list to the desired Snort interface.

The Suricata GUI package on pfSense is designed to make the deployment of an IDS/IPS somewhat simpler for users new to such technology. If you are at an advanced level where you want to integrate with multiple other systems and construct on-the-fly rules using script tools, then you really should abandon the GUI part of the package and simply use the Suricata binary itself. You can do that by simply installing Suricata from FreeBSD ports. You are going to have to install all of the other scripting language dependencies from there anyway. I am not in favor of loading up the Suricata package with a ton of new dependencies when the vast majority of users would likely not need them for a basic IDS/IPS. I'm talking about things like Python, Go, (and heaven forbid one old suggestion even needed Java! Can you imagine the security holes your firewall would have with Java installed on it?). There is a Github site for all of the pfSense packages here. You are free to submit pull requests there. I usally am asked for my opinion, but the pfSense developers have final say in what is accepted into the package.

@chudak said in Snort blocked hosts: @bmeeks You sound fine no worries And I’m actually not disagreeing on this point Need to digest, but then to be consistent with this - why do we allow Remove Blocked Hosts Interval option? What do we need it for ? Snort blocks hosts for say 1 hour and automatically removes it and then if needed blocks again. How does that sound ? PS: I’m not advocating for this change, just underlining the point. Because Snort hands off the actual blocking to the firewall packet filter, there needs to be an option to clean up blocked IPs after some period of time. Snort can't just "drop" packets like Suricata Inline Mode can. Think of a Snort block as a temporary firewall rule that is put in place. That rule needs to expire after some interval. Generally something like 15, 30 or 60 minutes is a reasonable expiration time. That is long enough to discourage port scanners and bot scripts that are say knocking on a bunch of port doors looking for a way in. It's true that Snort could hand the IP to the snort2c table and then clear it again almost immediately, but that would take a lot of extra processing on the part of Snort. Instead, Snort creates a cron task that uses the interval selected by the Clear Blocked Hosts setting. That cron task runs the pfctl utility to scan the snort2c table and remove any IP addresses that have not seen activity within the interval set by the Clear Blocked Hosts setting. So if the interval is set for 30 minutes, then only IP addresses that have not been seen in any traffic for the last 30 minutes will be cleared from the table.

Just to finish off this thread - the workaround by adding the server ip to the interface passlist works in the sense that the server ip is no longer getting blocked. The downside of course is, that this server is now completely without protection from Snort.

@bmeeks I removed some rules and so far the process is staying on. Thank you very much for your input.

Not a huge deal, more of an annoyance. Thank's for confirming.

Great. Back up and running now. Thanks!

@harmisist said in Snort ignoring pass lists: I fixed the pass list on both interfaces. I do have several incoming services, so I need both. When I set Snort up several months ago I followed this KB article which shows them adding the pass list to the external interface. It seems to be working now, thanks for the reply. That should fix it for you, but DO NOT confuse the EXTERNAL_NET variable with the physical external interface (WAN, in your case). They are not the same thing at all. While it is true that most of the !HOME_NET addresses will come into your network via the WAN, that does not mean when you see EXTERNAL_NET to think that only applies to your physical WAN. Go read some of those Google tutorials I mentioned in my first post and learn what those two variables really mean within Snort. I don't mean to sound rude or patronizing with this statement, but your first action that caused your initial issue, and then your second reply to my post about the solution, leads me to believe you do not understand how Snort should be configured yet. Reading some of those tutorials will help you grasp the key concepts.

@theowolf said in Snort enable_react problem: okay thanks for checking! Best, Theo And to elaborate a bit more ... DAQ's netmap mode in Snort today requires that you dedicate two physical NIC interfaces to the connection: one as input and the other as output. The netmap module in DAQ then bridges those two physical interfaces, but with Snort sitting between the two operating in Inline IPS mode. So Snort then can either pass on, or drop, packets destined for the other interface. The main issue that makes this unattractive on a UTM-type firewall such as pfSense is the requirement of using two physical interfaces. So a typical minimal firewall would need four physical NIC interfaces: LAN, WAN and then another pair for the Snort-DAQ netmap bridge pair. That's a little wasteful of physical NICs in most situations. What I am looking into is patching DAQ's netmap module so that it can use the special "host stack" connection provided by native netmap on FreeBSD and other operating systems. This requires changes to DAQ's netmap module source code. If I can get this to work, then Snort Inline IPS mode can be configured the same as Suricata is done today on pfSense. That mode creates a pipe between the physical NIC interface and the host network stack, so the IPS can exist on the same interface as the LAN or WAN.

See my reply to you similar question here. To repeat the answer from there, "no, there is really no need to use the OpenAppID rules in a home network". As you surmised, those rules are primarily aimed at identifying various traffic types and are not designed to detect and stop malicious software. Mostly they are to help IT Security admins enforce corporate computing policies such as no or limited access to social media during work hours and other similar policies.

I've tried most of that thread, but no luck. Looks like CPU just can't keep up. Thanks for the suggestions!

@bmeeks Thanks. I have an old customer connection that still uses PPPoE which will hopefully be gone soon. I disabled the rules, and it is no longer flooding my syslog server. Everything else seems to be working as it should.

Thanks for the info Bill. I appreciate your help and guidance.

@bmeeks said in Suricata fails to start after pfSense reboot: @kiekar Start with these two Sticky Posts here in the IDS/IPS sub-forum. How Automatic SID Management and User Rule Overrides Work in Snort and Suricata About the New Block-on-Drops-Only Option in Suricata To get some examples of SID MGMT, go to the SID MGMT tab and click the "enable" checkbox. That will populate the page with content. Open any of the example files and you will find comments inside each that explain the options. The internal syntax is copied from PulledPork, so you can Google the PulledPork utility used with Snort to get some examples of what you can do with the enablesid.conf, disablesid.conf and dropsid.conf files. Great, thanks so much. You've been a great help

@s0m3f00l said in Suricata Not logging signature matches | | Suricata 4.0.13_11 with pfsense 2.4.4-RELEASE-p1 (arm): @bmeeks , It appears to have worked. After deleting the package from the GUI "/usr/local/etc/suricata" was left behind. I removed the directory and its contents and then everything reinstalled correctly without intervention. I will wait for the next update and test again. @bmeeks, thanks for putting up with me sir. You are extraordinarily helpful and supremely knowledgeable about suricata and snort on PFSENSE, and the community would be lost without your input. Thanks, again. Glad you got it working. There was likely a file that had been modified and contained "bad content" being left there. When pkg removes software, it compares the md5 hash of the file being removed to the hash the file had when installed. If different, pkg assumes the user modified the file so it leaves it alone. So simply removing and re-installing the package was not removing that modified file. Manually removing the directory and file gets rid of the malformed file. My guess is that it was a different version of the references.config file that was being left behind. That file then would get used with the next installation, so the problem persisted for you.

The alert simply describes a condition where a potential buffer overflow was observed. This could be a false positive or it could represent an actual attempt at compromise. To figure out which it was, start by doing research on Google about the rule that fired. Use the GID and SID to narrow the search. The GID is 124 and the SID is 3. GID 124 is the SMTP preprocessor. More than likely it is a false positive. If you get one or two now and then, I would chalk it up to false positives. If you get several in a row, or get them quite often, I might investigate further.

The permanent fix for this issue was merged in Suricata package version 4.1.2_2 which is now posted. This issue is resolved.