@strangegopher: @bmeeks: I don't recall off the top of my head, but there is a forumula that uses the number of cores and memory to compute optimal stream memory settings.  I think some adjustments to that area of the binary also happened between the 3.2.x and 4.0.0 versions of the code, so that might account for the fact of not having that exact error using 3.2.x. Bill Seems like I am now (after fixing other issues) having the same issue as op. my supermicro a1sri-2758f has 8 cores and no threads, its non-standard core count I guess. Might explain the buggy multi threading  issues I am experiencing. See my reply in the other thread you linked.  You need to at least double the Stream Mem Cap setting, and possible increase it even more. Bill

@pfsense_user12123: I figured out that INLINE MODE causes the Problem. In Legacy Mode everything works great. So the Main Problem in the configuration file was the inline Mode which made the Router freeze. Not surprising.  Lots of NIC hardware has problems with Inline Mode due to the Netmap dependency.  It is still a buggy interface in all of the following:  (1) NIC drivers, (2) FreeBSD and (3) to some degree Suricata upstream. Bill

@chudak: Thx for the answer. The only interesting question remains - why this rule problem was unmasked by a snort version upgrade? It wasn't.  I've never seen that error in any of my test virtual machines nor in my personal firewall, and I've upgraded along with every version release.  It is likely a product of the particular rule sets you have enabled.  To be specific, the error is caused by not having the Sensitive Data preprocessor enabled while having an enabled rule that contains a sensitive-date preprocessor keyword (that "sd_pattern" keyword). Does Snort now not run at all, or did it just fail to automatically restart following the initial update? If you can, open the referenced file in the error message using the vi editor and go to line 424.  Paste the entire contents of that line back here so I can examine the failing rule. Bill

An update to my previous reply above.  I assumed initially the OP had turned on blocking mode, but the OP has this post in another sub-forum here on the board: https://forum.pfsense.org/index.php?topic=136442.msg746548#msg746548 In that post it is stated that "BLOCKING" and "BARNYARD2" both show as Disabled on the SNORT INTERFACES tab.  That would be why you are getting alerts and no blocking.  Snort does not block by default.  It is an IDS when using the defaults.  You must go to the INTERFACE SETTINGS tab by clicking the edit icon beside the interface.  On the INTERFACE SETTINGS tab, click the checkbox for Block Offenders in order to turn on IPS or blocking mode.  Save the change and then restart Snort on the interface.  You restart it back on the INTERFACES tab using the icon there. You will also need to weed out potential false positives. Bill

@bmeeks: What blocking mode are you using with Suricata when you enable blocking?  Is it Inline IPS Mode perhaps?  If so, my first theory is you have a compatibility issue with your NIC driver and Netmap.  Netmap is extraordinarily picky about having perfect support from the NIC hardware driver.  The fact your error messages from the kernel mention "netmap" is the clue I'm working from. If your NIC driver and Netmap do not play well together (and more NICs don't play well than do play well), then weird stuff begins to happen all the way up to a kernel crash. So if I'm right and you are attempting to use Inline IPS Mode, switch over to Legacy Mode blocking instead and let it run for a while to see if the problem repeats. Bill Hi thanks for the reply and advice I think you are onto something yes I'm using 'Inline IPS Mode' I've experimented with Promiscuous Mode on/off with little to no effect my hardware is a PC Engines APU2 with Intel i210AT NICs I do recall making some changes when I had Snort over Suricata to System/Advanced/Networking I have noticed that the following things are disabled Hardware Checksum Offloading Disabled Hardware TCP Segmentation Offloading Disabled Hardware Large Receive Offloading Disabled I'll experiment with legacy and see how it does I was hoping to use it if possible but perhaps its not going to play nice with my hardware config

@bmeeks It seems to be fine after 5 days. Appreciate for your help, Bill :)

Fair point, and to put it into perspective, I had restored the configuration from an xml file. Maybe that's it. Thanks for your help

Taking another look at this. Sorry if my questions are overly pedantic. I just don't want to break my system. I have attached the snort log facility options and the tabs in status / system logs / system / general from my system. Presumably they are the same as any other system. Here is unedited syslog.conf. I can see a rough correspondence between syslog.conf and the tabs. !radvd,routed,olsrd,zebra,ospfd,bgpd,miniupnpd *.* %/var/log/routing.log !ntp,ntpd,ntpdate *.* %/var/log/ntpd.log !ppp *.* %/var/log/ppp.log !poes *.* %/var/log/poes.log !l2tps *.* %/var/log/l2tps.log !charon,ipsec_starter *.* %/var/log/ipsec.log !openvpn *.* %/var/log/openvpn.log !dpinger *.* %/var/log/gateways.log !dnsmasq,named,filterdns,unbound *.* %/var/log/resolver.log !dhcpd,dhcrelay,dhclient,dhcp6c,dhcpleases,dhcpleases6 *.* %/var/log/dhcpd.log !relayd *.* %/var/log/relayd.log !hostapd *.* %/var/log/wireless.log !filterlog *.* %/var/log/filter.log !-ntp,ntpd,ntpdate,charon,ipsec_starter,openvpn,poes,l2tps,relayd,hostapd,dnsmasq,named,filterdns,unbound,dhcpd,dhcrelay,dhclient,dhcp6c,dpinger,radvd,routed,olsrd,zebra,ospfd,bgpd,miniupnpd,filterlog local3.* %/var/log/vpn.log local4.* %/var/log/portalauth.log local5.* %/var/log/nginx.log local7.* %/var/log/dhcpd.log *.notice;kern.debug;lpr.info;mail.crit;daemon.none;news.err;local0.none;local3.none;local4.none;local7.none;security.*;auth.info;authpriv.info;daemon.info %/var/log/system.log auth.info;authpriv.info |exec /usr/local/sbin/sshlockout_pf 15 *.emerg * Looking at the "local" subsection: local3.* %/var/log/vpn.log local4.* %/var/log/portalauth.log local5.* %/var/log/nginx.log local7.* %/var/log/dhcpd.log *.notice;kern.debug;lpr.info;mail.crit;daemon.none;news.err;local0.none;local3.none;local4.none;local7.none;security.*;auth.info;authpriv.info;daemon.info %/var/log/system.log ```I see that local3-7 are used. What is the significance of the entries "local0.none;local3.none;local4.none;local7.none" in the line for %/var/log/system.log? Are they there only in case a specific log file is not specified above? Why are there not entries for local1.none, local2.none, local5.none and local6.none? If I understand you correctly, to use the facility LOG_LOCAL2 for snort, I would make this change: local2.* %/var/log/snort.log If I do this, where will I see the log entries? Thank you very much.    

I assume that after you assigned the Pass List to the interface on the INTERFACE SETTINGS tab and saved that change that you also restarted Snort.  If not, then you must do that.  Pass Lists are only parsed and evaluated when Snort starts up.  So any changes made during a Snort run are not seen until the next time the service is restarted. I have tested this multiple times in my VM testing environment and pass lists always worked for me.  I have a Kali Linux machine I use to scan and otherwise "harrass" my pfSense virtual machines with Snort installed.  Snort will always block the Kali machine when it's not in a Pass List, and not block it when the Kali machine IP is in the Pass List. Bill

This has happened a handful of times to a few users.  I guess I need to add a manual "fix-it" button to the code.  The GUI code stores the name of the suppress list in the tag I provided, but the actual list contents are stored in a different set of tags.  So what happened in your case is the contents were missing in the other set of tags.  You can have multiple suppress lists defined, but of course a given interface can only use one at the time.  So the _<suppresslistname></suppresslistname>_tag is used to store which suppress list contents to use for the interface from that other tag's list of suppress list contents.  The tag for your WAN was pointing to a contents list that was not actually present in that other section. Bill

I fixed it by doing both of these suggested fixes : 1. "Remove the leading spaces from the line containing "{$http_hosts_default_policy}" and save the change. " 2. "I have run into the same problem, made a quick fix to my installation by editing /usr/local/pkg/suricata/suricata_generate_yaml.php and removing the whitespace before personality: IDS." After that I reinstalled the package and it works. Great job!

When you click the icons on the RULES tab beside individual rules, that puts the SID in a special list for Suricata.  After all other things are processed (SID managment changes and the default states from the rule vendors) then the FORCE ENABLE and FORCE DISABLE rule changes you make on the RULES tab are applied using the SID to identify the rule.  So changes made on the RULES tab are the last thing that happens.  I'm working from memory here, but I think the disabling of rules is the last step (that is, the force enable rules are enabled, then the force disable rules are disabled). With the introduction of the SID MGMT tab a few releases back, you really should make your rule customizations there.  You can use the three modification config files there (enablesid, disablesid and modifysid) to make your changes.  The example files are full of sample rule modifications you can follow and learn from.  My advice is to create your own files from those samples (you could just save the samples with a new name and then edit from there).  This is because the sample files come with the package installation and will get overwritten if you upgrade Suricata or remove and reinstall the package.  Files you create with a different name will survive Suricata upgrades and package removal and reinstallation. One more warning about customized SID MGMT files you create.  They are stored in /var/db/suricata/sidmgmt on the firewall, but are not part of any configuration backup.  You will need to back them up yourself.  You can do that using the icons on the SID MGMT tab to download and save them to another location off the firewall.  That way, if you have to recover the firewall from scratch, you can upload your saved SID MGMT configuration files and be good to go again.  Otherwise, you would have to recreate them from scratch. Bill

@mkcharlie: Hi Bill, Everything seems to work exactly the way it should be for the moment. Thanks for taking the time to do the changes. Thanks for the feedback.  Glad to have found that particular bug and the related one in the logging code that caused Snort to die when logging a rule with no CLASSTYPE defined. Bill

Glad you found the issue.  That 0.0.0.0/0 network in the pass list would prevent blocks.  That's why you got no IPv4 blocks but got an IPv6 block.  That IPv4 net block would of course match any IPv4 adress, so Snort would think all IPv4 addresses were on the pass list. Bill

@maverick_slo: Ahhh ok. I tought it was smart and it's populating pairs autpmatically and then if mac changed fires an alert. Now that would be cool Thanks for clarification! No, it is not an automatic thing.  Also remember that in a switched LAN environment the preprocessor is not going to be able to see and catch everything.  There are some good papers to be found with a Google search about ARP spoof attacks and the difficulting of reliably detecting all of them. Bill

You have something very weird and rare going on if Suricata kills your DNS lookup and that persists even through a reboot, and only restoring a previous config solves the problem.  That sounds like something else more than just Suricata.  Are you trying to use any of the pfBlocker DNS Blacklist files?  That setup can cause problems with the firewall's DNS resolver, unbound, in some cases. Do these problems happen even before you put Suricata in blocking mode?  If you have not tried that, run first for at least a week and preferably nearly a month in non-blocking mode with just alerts firing to get a feel for what happens in your network.  You almost always will get false positives that you have to filter out.  There are guides here on the forum (entire threads, actually) on how to set up suppression lists and which "most likely to false positive" rules you should consider disabling. As far as the Inline IPS mode goes, that is totally dependent on the specific NIC hardware in your box and what driver it uses.  If you know which driver the NIC is using, you can search Google for compatibility issues with Netmap on FreeBSD.  I will tell you in advance that not all NICs work.  In fact, not very many work 100% correctly with Netmap.  And if a NIC does not work well with Netmap, then Inline IPS mode is a no-go. Finally, as to running Suricata on WAN, LAN or both; here is my advice.  For home networks using NAT, I suggest running Suricata only on the LAN.  That way the addresses you see in the alerts will be traceable to the hosts that generated them by IP address.  When you run it on the WAN, it sees traffic before the NAT is undone, so all of your local hosts on the LAN will show up with the firewall's external WAN IP.  It then is quite difficult to trace down an internal host generating alerts.  You have to dig through other firewall logs.  However, if you run Suricata on the LAN, it sees traffic after NAT is undone and thus the real host IP addresses appear in the alerts.  You can run Suricata on both interfaces, but that really wastes resources for home users and does not really provide any extra security.  The firewall is going to drop all unsolicited stuff anyway if you have it configured correctly.  Running on the WAN primarily helps for folks who have web servers, DNS servers, Email servers or other public-facing hosts.  You might want Suricata on the WAN providing some protection for those externally exposed hosts.  Of course if they sit in a DMZ, you could put Suricata just on the DMZ interface. Bill

@Beerman: Hi, I am not able to delete additional Server Configurations in the Snort Preprocessors configurations. Applies to: HTTP Inspect, Frag3 and Stream5. I can add another Server Configurations, but I cannot delete them afterwards. No matter what I do. Any solutions for this? Thx! :-) I just found this bug today while working on a new feature.  It's another hidden bug from the old conversion to Bootstrap.  I've fixed it in the GUI update I'm working on now.  Will be posting it in a day or two for approval and merge.  Trying to trace down the source of two more bugs before submitting the updated package. Bill