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

@bmeeks: Suricata does some internal house cleaning as it runs.  I suspect it is recovering some RAM that was initially allocated and then later not needed.  During startup a lot of stuff is happening all at once in terms of loading the rule set and parsing/decoding the text into all the internal structures used for the pattern matching algorithm. If you have 6 active interfaces all with a decent number of enabled rules, that would account for the 2 GB number.  Also, based on 6 interfaces with a lot of enabled rules on each, I guess the 10 GB number is not that bad for startup usage. So long as Suricata is actually still running on each interface, you are not "losing" any protection because of the RAM usage reduction.  Just verify all the interfaces show Suricata running over on the INTERFACES tab. Bill Awesome! Thanks very much for the info. That makes sense. Yes the service and each individual interface remains running. Thanks again!!

@Xentrk: Thanks for the reply Bill. You confirmed the path I need to take. After my post, I did more research and realized it will take time to tune and learn more about suricata. Thank you for the tip on the forum posting "Taming the Beast".  I will definitely visit that post. I gave google a workout with my searches on suricata but never did come across that thread. The reason I did not get impacted until now is I had suricata turned on the WAN interface. Yet, all of my browsing was done on the VPN inteface. My problems only started when testing web browsing over the native WAN interface. That is when the rules started impacting me.  I have some users in the family that want native WAN while the rest of us want VPN to USA 100 percent of the time. I am trying to reduce my router foot print and go 100 percent pfSense.  I think I have things stable now that suricata is turned off.  I noticed my disk space started growing.  For next steps, I plan to do some more reading on the pfSense forum and other resources to learn all I can about suricata before I start testing it again. Thanks again for the advice and help! For the disk space growing issue, make sure all the automatic Log Management functions are turned on the LOGS MGMT tab.  They will auto-rotate and delete logs based on values set on that tab.  You can adjust the limits to match the size of your disk.  Suricata can be a "chatty" logger. Bill

Installed last night so far zero issues thanks for getting this out

Thanks Bill, its working a treat now :) alert icmp any any -> any any (msg:"ICMP Packet found";sid:1000001;rev:1;classtype:icmp-event) [image: Untitled.png] [image: Untitled.png_thumb]

It's been a while since I've toyed with Barnyard2.  It definitely sounds like a permissions or path thing to me, though.  Remember the running Barnyard2 process will not have the same environment variables set as your shell account will have.  So things that "just work" at a CLI prompt many times will not work when executed from within a script or a daemon. Is your private key literally in /etc, or is it maybe actually in /usr/local/etc?  The latter is where I think it should generally be on FreeBSD and pfSense.  All of the Snort, Suricata and Barnyard2 stuff is in /usr/local/etc. Bill

@techbee: While pfsense dropped the Layer 7 filtering and suggested using Snort,  I don't know why other commercial firewall still have Layer 7 filtering on them. I forgot what commercial firewall was that, probably Sophos. I believe it was because the Layer 7 filtering in pfSense was never great and it was a little hard to maintain.  I think it was more an experiment from one of the developers who has since departed.  The OpenAppID system now in Snort was open-sourced by Sourcefire soon after acquiring Snort.  It is modeled after some of their older proprietary stuff.  You have the basic engine available in the Snort binary, but to complete the circle and make it actually do something you need custom AppID rules.  A third party provider volunteered to create and maintain a cache of OpenAppID rules for the Snort package on pfSense.  Those rules are hosted on a University web site in Brazil.  You can enable their download in the Snort GUI on the GLOBAL SETTINGS tab.  Be aware, though, that the hosting web site does geo-blocking on certain countries.  If you reside in one of the countries they geo-block, then you won't be able to download the rules (at least not without using a VPN to get around the geo-blocking). Bill

This is a question you should direct to the Snort mailing list.  I don't have the URL, but you should be able to quickly find it on Google.  I know there is one. Bill

@justsomeone: Snort wont start after updating some rules. I have un-installed and reinstalled. Any help would be much appreciated. Here are the logs:``` Time Process PID Message Jul 21 15:03:54 php-fpm 40562 /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 35291 -D -q --suppress-config-log -l /var/log/snort/snort_em035291 --pid-path /var/run --nolock-pidfile -G 35291 -c /usr/local/etc/snort/snort_35291_em0/snort.conf -i em0' returned exit code '1', the output was '' Jul 21 15:03:54 snort 48245 FATAL ERROR: /usr/local/etc/snort/snort_35291_em0/rules/snort.rules(4832) byte_test rule option cannot extract more than 4 bytes without valid string prefix. Jul 21 15:03:53 php-fpm 40562 /snort/snort_interfaces.php: [Snort] Snort START for WAN(em0)... Jul 21 15:03:53 php-fpm 40562 /snort/snort_interfaces.php: Starting Snort on WAN(em0) per user request... Jul 21 15:03:51 php-fpm 40562 /snort/snort_interfaces.php: [Snort] Building new sid-msg.map file for WAN... Jul 21 15:03:50 php-fpm 40562 /snort/snort_interfaces.php: [Snort] Enabling any flowbit-required rules for: WAN... Jul 21 15:03:42 php-fpm 40562 /snort/snort_interfaces.php: [Snort] Updating rules configuration for: WAN ... This error is caused by a mis-written rule signature.  Likely it was updated by the authors but the error was not caught before the rule was added to the update tar ball.  You can find the errant rule and disable it by "decoding" the error message. Here is the snippet of the error message you need: /usr/local/etc/snort/snort_35291_em0/rules/snort.rules(4832) This tells you the file containing the rules where the error happened.  The file is /usr/local/etc/snort/snort_35291_em0/rules/snort.rules, and the error is on line 4832 in that file.  So open the file in an editor, locate line 4832, examine the rule there to find the SID and category and then disable that rule in the GUI on the RULES tab. Bill

@crester: I don't know why but rebooting had worked. 99 times out of 100 this means you had duplicate Snort instances running on the same interface.  To the GUI, one of those process instances is like a zombie and lost.  So any changes made to HOMENET or anything else in the GUI don't get applied to that running zombie process.  Rebooting will kill everything and then you get back to a single Snort instance per configured interface and things are normal. Bill

The GUI package update to accompany the binary update has been posted for review and approval by the pfSense developer team.  Should get merged into the package repository soon.  Here is a link to the Pull Request with details on bug fixes and the new feature in this coming update. https://github.com/pfsense/FreeBSD-ports/pull/393 I will post a full set of release notes after the update is merged into the package repositories and is available for users to install. Bill

I realize this is an old topic - however, maybe someone out there has crossed this bridge and can shed some light on the issue. I am running into the same problem as the OP.  Suricata (Inline - Intel i211) effectively shuts down the WAN interface and runs the CPU up to 100%.  Nothing in the logs indicates a problem, suricata log just goes silent.  A stop / start of Suricata and all is well again. The few times I've encountered this it did not seem to happen during times of high load on the interfaces. OP - Did you have any luck in adjusting buffers?

MrGlasspoole…just to be clear I do not recommend you disable those rules. If you are not getting many alerts "Suppress" might be a better route for you, assuming you have the available resources for your firewall to work harder.

I run Snort on the VLANS and exclude the parent interface, the untagged VLAN on my settup id for LAN management.