Well, I've been playing with it for a while, and my first hurdle was getting pfSense to acknowledge/see traffic not actually destined for it on the monitor interface(s). Creating a bridge group seems to be the solution, but Snort needs to still monitor the actual interface(s), and not the bridge for it to work. My second hurdle is with Barnyard. The config page made it seem as though I could possibly nab packet captures/dumps right from the UI, which seems to be incorrect. So, that means pfSense is only usable as a sensor, which is fine. It's ability to disable/suppress Snort rules/alerts is way ahead of what the SO people are doing. So I've been working on getting Barnyard2 in pfSense to push the events into Security Onion's MySQL database. I found an older howto on the Spiceworks forum, but it seems to no longer be valid. Security Onion no longer uses Snorby and instead now uses Sguil. The next step is probably to ask the Security Onion people for help. Anyone have any insight?

Hello vbentley, thank's for your reply, but I was misunderstood! The very open WLAN has for sure no access to the LAN, only to WAN and LAN has no access to the WLAN, only to WAN. My question is different (maybe my english is not the best) :-[: I want to setup snort on LAN and WAN, but only for traffic to and from LAN. I'm searching on how to setup the rules for snort in a way, that WLAN and WAN for WLAN is generally not affected. This "Freifunk"-thing is based on a club and one of the rules in that association is not to sniff any traffic (gentlemen's agreement). That's my goal! Many thanks!

Thanks for the help..

How to find the link-local machine… https://forum.pfsense.org/index.php?topic=122888.msg688720#msg688720

Yes, I found the line but I'm still perplexed why I can't renice a process through cron. In openwrt, it was no problem.  Why is cron different here???

if they're blocks to normal google searches, let them pass. same with akamai blocks.

@genesislubrigas: PS:  I dont use pfsense captive portal You might want to fix the totally misleading subject, plus move this to some Linux forum.

The dependency is already fixed, no need to do anything here. https://github.com/pfsense/FreeBSD-ports/blob/devel/security/pfSense-pkg-suricata/Makefile#L16

@bmeeks: Hey Sorry for the late reply. I have rebuilt my VM lab on Vbox and tested on it, very good success with Suppression list but still can't figure out pass list. But for now that will do nicely, Thank you very much for your help Bill.

Great job Bill, well explained. I absolutely agree with you that the best Passlist option is "none" for Inline mode.

Maybe with ??? http://asecuritysite.com/forensics/snort?fname=webpage.pcap&rulesname=ruleip.rules IP address alert tcp any any <> any any (pcre:"/[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/"; msg:"IP address";content:"number";nocase;sid:9000003;rev:1;)

@AR15USR: I currently have Snort configured and running but Im interested in checking out Suricata for a possible switch over. Can I install Suricata whilst already having Snort installed? Maybe just run Snort on the WAN and Suricata on the LAN for a testing period? Sure, but you can't run them both in blocking mode unless you operate Suricata using the new inline IPS mode.  That's because Snort and Suricata share the same pf firewall table for storing their blocked IP addresses, so if both packages are in blocking mode (with Suricata in Legacy mode blocking) they will clash over the pf table and not play well together. Inline IPS mode is only supported on a few network cards, though.  If the NIC in your firewall on the interface where you want to run Suricata is not on the supported list, switching on IPS mode in Suricata will break connectivity all the way up to possibly needing a firewall reboot to fix.  So be warned!  Check your NIC compatibility first.  Look for "netmap support".  Searching Google and the FreeBSD site will help you see if the NIC hardware and associated driver on your firewall support netmap (which is used by Suricata for inline IPS mode). I would just leave Snort as-is and install Suricata on the other interface in IDS mode.  Do not enable blocking.  You will be able to see all the alerts Suricata generates and from that determine how you like it as compared to Snort. Bill

@user12: Hey there! As soon as I active OpenAppID-Rules in my Snort configuration (downloading the rules is just working finde) the system will tell me: FATAL ERROR: /usr/local/etc/snort/snort_8522_rl0/rules/snort.rules(19371) Rule options must be enclosed in '(' and ')'. And the snort service won't start anymore… ideas? I just downloaded the rules and actived them for my interface. Snort is telling you what is wrong right here:  Rule options must be enclosed in '(' and ')'.  Snort will stop when it encounters any errors in a rule.  The snort.rules file is simply the collection of rules you have chosen from all the categories you have enabled.  To see exactly which rule it does not like, open that file and look on line #19371.  Snort prints the line number of the rule with the syntax error.  The error is caused by the rule writer and not the Snort package itself. See my reply this user's problem for more details:  https://forum.pfsense.org/index.php?topic=123883.msg686669#msg686669. You should also complain to the rule author (at the site where you are downloading the OpenAppID rules) to let him or her know the rule is defective.  I wish the Snort VRT developers would have Snort operate like Suricata and just log a syntax error, skip the bad rule, and go on to the next one instead of stopping with a Fatal Error as it does now.  Stopping with the fatal error leaves you totally unprotected, while skipping a rule or two would still leave you with some protection in place. Bill

The OpenAppID feaure was added by the Snort VRT about 2 or 3 years ago if I recall correctly.  Shortly after it was introduced I incorporated support for configuring it within the pfSense Snort package.  However, there is much more to using OpenAppID than simply checking the box in the GUI.  You must create your own custom rules to actually implement Application ID inspection.  There are a critical set of OpenAppID stems that come from the Snort VRT via the updates, but they are not all that you need to actually implement OpenAppID.  So if you enabled the feature without also creating the necessary custom rules for traffic inspection, it is actually doing nothing. There have been several reports of errors within the OpenAppID stems that are packaged in the Snort VRT signature updates.  Unfortunately with Snort, when it encounters any kind of syntax error in rules or other items it is loading, it will error out and quit.  Suricata will log an error, but then skip the errant rule and continue loading the others.  So what is likely happening with OpenAppID enabled is Snort hits one of those random errors that seem to get into the OpenAppID stems update and quits.  Because Snort is so terribly chatty and fills the system log with essentially every action it takes when you enable normal logging, the pfSense package always starts Snort with the "quiet" switch to cut down on all the log noise as Snort starts.  You can disable this feature and turn on the verbose logging by toggling a parameter on the GLOBAL SETTINGS tab. Here is how I think this might be happening to you.  Enabling the OpenAppID preprocessor will cause Snort to load that piece of code and to download the OpenAppID stem updates along with the regular VRT rules update.  Snort will then start to load and process the updated files.  If OpenAppID is enabled, and the OpenAppID stem files have any errors in them, Snort will log the error and die.  The error will only show up in the system log on pfSense if you have turned on verbose Snort logging (that GLOBAL SETTINGS parameter I mentioned earlier).  So if Snort encounters an error in the rules or OpenAppID updates, it will just seemingly die for no reason when the "quiet" switch is enabled.  As I mentioned, using the "quiet" switch is the default on pfSense otherwise you get several hundred lines of Snort start-up text in the system log. Bill

Thanks Bill, already updated the package. I'll test and let you know.

Going to need a lot more information than you provided. What versions of Snort and pfSense are you running? Have you checked the ALERTS tab to see if alerts are being logged related to the traffic that is not working? Do you have the blocking mode of Snort enabled?  If so, it's not a good idea to turn that on until you become very familar with the alerts generated by Snort on your network traffic. That gives you a chance to determine if the alerts are "false positives".  False positives need to be either suppressed via a Suppress List entry or the applicable rule signature disabled. Bill

suricata 3.1.2 is now available on pfSense 2.3.2.

suricata 3.1.2 is now available on pfSense 2.3.2