@pfBasic: IDS/IPS are all CPU intensive. But I think your results are skewed. There are a lot of variables to determine CPU usage beyond threads. How many rules you are using is one of them, but more importantly the content of those rules. A rule that only inspects IP, port and direction (like a floating firewall rule) is very CPU light. On the other end a rule that has to inspect the IP, port, direction, header, and payload of a packet will take more CPU cycles. Multithreading is certainly great, but it isn't magic. My guess is that either something was wrong with your snort setup or you tested suricata with different rules than snort. If suricata were 50x faster than snort, no one would use snort. True.  With Snort I tested with all rules enabled.  With Suricata, I tested with all rules enabled.  Even uninstalling / reinstalling Snort didn't help.  Either way I'm impressed with the overall results of Suricata.  Very quick.

Just a quick note about the IPS Policy Mode option:  it will only appear when using Inline IPS Mode and when the VRT IPS Policy option is enabled.  The option is hidden when using Legacy Mode on the interface because there is no ability to distinguish between "alert" or "drop" in Legacy Mode.  Furthermore, the option will target only Snort VRT IPS Policy rules.  The Snort VRT rules have extra metadata in them that tags a rule as belonging to a particular policy set as well as providing a suggested action (drop or alert).  The Emerging Threats rules lack this IPS policy metadata and thus can't be managed using the IPS Policy options. Bill

Thanks Bill, I found some documentation and am looking through it. I'll probably screw it up but I'll report what I find.

@tiramisu: I was trolling the Suricata website and see a few different build guides for flavours of Linux. Has anyone posted a cookbook for building Suricata w/ Cuda on the pfsense distribution and doing whatever is required to patch it into the pfsense gui? I'm thinking this could provide an entertaining and educational hobby in the DMZ with a honeypot. No one has done this so far as I know.  Because using Cuda is a sort of specialized thing, I did not include that in the standard pfSense package I created.  You could certainly build your own CUDA-enabled binary.  You just need to create a FreeBSD 10.x or 11.x virtual machine to use as a package builder.  Then just compile the source files from FreeBSD ports and create a package.  You could then copy that over to a pfSense box and install.  I assume you don't want blocking (you mentioned for a honeypot), so the stock FreeBSD ports version of Suricata would work.  This would mean you don't need my blocking plugin patch (which you could only get by signing a CLA and getting access to the pfSense FreeBSD-ports Github repository). In terms of patching CUDA support into the GUI, you can configure everything by hand by adding the appropriate information to this file – /usr/local/pkg/suricata/suricata_yaml_template.inc That file is used to build the suricata.yaml for each interface. Bill

Bug #6690: SURICATA IPS Issue - Kills VLANS & Traffic Shaper https://redmine.pfsense.org/issues/6690

I'm using 2.4, it's great and very stable but no different than 2.3.x as far as this issue goes (in practice at least). Tried it with PRO/1000 & i340, no traffic shaper or VLAN. Still doesn't work yet. Just give it time. As dok stated, security wise about the only difference is that legacy will allow a few packets before it blocks the IP and kills the state.

just switch to suricata.

You will have to disable the rule if you can't pin down the IP range.  There is no capability for dynamic DNS lookup with either Snort or Suricata.  So you can't use a DNS name in a passlist alias.  This is due to the enormous overhead DNS lookups would add to packet processing.  The thread would hang waiting for the DNS lookup to complete. Bill

As indicated in the topic you referenced: <qoute>Ah, my bad! The lack of a separator there as opposed to the ones above it is a bit confusing Thank you for your time and effort.</qoute>

HAProxy works just fine here with suricata, cannot see why it wouldn't work with Snort either.

Thanks for the quick reply! If there is one on this forum, can you point me in the direction of a write up on where to add the custom Suricata rules in pfSense? Is it as simple as something like this (attached)? or do I need to figure how to make a separate rules list (attached)? EDIT Found this post and got what I needed. https://forum.pfsense.org/index.php?topic=91438.0 Thanks again bcan! [image: Capture.JPG] [image: Capture.JPG_thumb] [image: Capture2.JPG] [image: Capture2.JPG_thumb]

An IDS/IPS assumes that all applications (and thus software developers) follow all the standards for networking, so when the IDS/IPS sees something that looks amiss it will alert on it.  Unfortunately that assumption about all applications (and developers) solidly adhering to all published networking standards is a pipe dream… ;) The downside for IT Security Admins is we get flooded with spurious alerts that we have to spend time investigating.  The STREAM alerts are about as worthless in Suricata as the HTTP_INSPECT alerts in Snort.  What I mean by that blanket statement is there are so many false positives from both of those that they are both nearly worthless.  Most IT Security Admins will disable the majority, if not all, of these rules. Bill

Solved. The ET POLICY rules are in the Resolve Flowbits automatic rules. However, you can't view the rules in the Suricata Interface LANRules: decoder-events.rules page. You have to view them on the Suricata IDS / Interface LAN - Categories page.

Cool, thanks! I'm using 2.4, so it might be something going on there?

@jeffh is correct.  Snort can only block when block offenders is enabled.  This is because the custom plugin that does blocking simply uses every alert to generate a block.  So any alert that is fired will result in a block of the offending host or hosts when "block offenders" is enabled.  Which host is blocked (source, destination or both) is configurable in the GUI.  Of course alerts that are suppressed, or rules that are disabled, will not generate corresponding blocks.  Right now the plumbing used internally in Snort does not lend itself well to inline IPS mode on pfSense.  That may change in the future. Suricata leverages the somewhat new Netmap functionality introduced in FreeBSD (in version 9 I think, but I'm not sure off the top of my head) to provide a true inline IPS mode that honors "alert", "drop", "reject" or "pass" as rule actions.  Netmap allows very high speed pipes to be established between the NIC driver and user-land software (in this case, Suricata).  However (and it's a big "however"), Netmap is only fully supported by a tiny handful of NIC drivers on FreeBSD.  Some drivers sort of support it but are still quite buggy.  Also, in pfSense, Netmap is currently incompatible with the traffic shaper and VLANs.  So if you have a traffic shaper enabled or use VLANs, then Netmap will kill connectivity on any interface it is enabled on.  This in turn means Suricata can't work with inline mode on such an interface. Bill

Snort does this automatically via a cron job.  The update check interval is configurable within the GUI. You can run this file to manually update if you want to do it outside of the cron process.  Not sure why you would need to do this, though. /usr/local/pkg/snort/snort_check_for_rule_updates.php Bill

AC-BNFA or AC-BNFA-NQ. There are several discussion on why this should be the recommended setting, which you can google or search it.

Dont want to dig this up again but i have posted on a few times about VIP for snort or suricata, Have not heard any updates since but would it be possible to only monitor the VIP? Thank you

Something you might be interested in while learning pfSense and specifically IPS is pfMonitor. Check it out in the link. It is in Beta now, the developer is rolling out features rapidly. It lets you compare your firewall hits to other firewalls, gives notes and articles about new attacks and IP's and categorizes IP's so that you can figure out which attackers are serious or true attacks and which are just false positives. For example, this IP has over 1000 hits on my firewall, but none on any of the other firewalls in the program, which seems kind of strange to me, but probably is because I use a few custom rules that caught the IP (which it sounds like is a FP). It summarized all of the ports, and how many times that IP has hit my firewall when I searched it. It really has a ton of great data in it. I'll be writing up a review and a quick youtube video on it after I've had a chance to use it for a while and figure out all of its uses. https://forum.pfsense.org/index.php?topic=120972.0

In additoin to scp, you can download the PCAPs via the webgui Services->Snort->Alerts, Alert Log Actions: Download But if the alert file gets too big it can cause the php process to crash and you may have to resort back to scp.