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

I've found the cause of this error.  It is due to a change the Suricata team made upstream that changed how the TLS certificate storage directory was specified in the suricata.yaml file.  The fix will be in the next Suricata GUI package update.

Bill

^^ that spawned a possible good idea - for the pfsense dev's, setting the minute number randomly, on first install, would help for the future.  You should expect to see a higher server load as more people use pfsense.

Yeah, to be clear this is absolutely wrong place to post. Noone here maintains the snort.org webservers so noone here can fix broken checksums they keep uploading over and over and over again. If you have a paid subscription, complain to the Snort guys, if you have none, then you get what you paid for and simply wait till someone fixes it.

It helped me.  Thanks!

@userjanuary2017:

Oh wow, great news on pfsense reinstalling my packages automatically, thank you Bill, I really appreciate your help very much!

As I said, I'm not 100% sure on that point, but I believe it used to do that.  If you have pfSense paid support, they can verify that point for you in case I am mistaken.

Bill

@tiki1980:

@bmeeks:

I have abandoned the use of Barnyard2 on my personal firewall due to problems with it.  I wish it was more dependable, but the constant problems finally wore out my patience.  I was using it with Snorby.

Bill

Not really ontopic but what do u use as a frontend? I looked at www.aanval.com which has it's own proprietary shipping mechanism of the unified2 logs but this only allows for one sensor (really one interface)

Since it is just my home network firewall, I am not currently sending the log data anywhere.  I just periodically review stuff directly on the firewall.  I have not investigated using anything else since I dropped Snorby.

Bill

@pfcode:

@bmeeks:

As for the HTTP_INSPECT rules in Snort, I say this with some tongue-in-cheek – they will alert on pretty much any HTPP packet these days and have become darn near worthless becaue of that IMHO.  I have disabled the majority of those rules in my system.

Bill

Are you talking about LAN preprocs->Http Inspect??

Any of them to be honest.  A lot of them misfire (as in generate false positives and thus false blocks).  I know some of the rules might be OK, but many are either out of date or else a ton of legitimate web sites are sending out vastly screwed up HTTP traffic.  I just know that if you enable all those HTTP_INSPECT preprocessor rules you will immediately start to get alerts and subsequent blocks on a large number of mainstream and legit web sites.

Bill

@dhboyd26:

Thanks for the reply.  I should have thought about that possibility as much as I have been bamboozled by UNIX to DOS files before.  The lists were put in by hand in the GUI, so all is well. but for future reference (hopefully never) I will definitely check that.

On a completely unrelated topic, since you are the maintainer of the package, I wanted to let you know that we now have Suricata running inline after a hardware change from Intel X710 adapters to Intel X520 adapters.  Been working like a champ!  Thanks for your work maintaining this package.

Good to hear.  Netmap support is still not 100% in all the NIC drivers yet, but maybe someday we will get there.

Bill

@bmeeks:

If you uninstalled the package with the "Save Settings" checkbox unchecked, then all remnants of Snort were removed from your config.xml file which the firewall uses to store all of your configuration information.  So if you re-install the pacakge, it should behave as a 100% fresh install with no pre-existing configuration settings brought over.

Bill

Great.

So i uninstalled the package and reinstalled it, didnt help.
Installed suricate and it worked out of the box.
So I made a passlist and used that for external_net in snort instead, and it worked. But now the "!" infront of the IPs are gone, exactly like the home_net. In other words it says that my external_net is home_net now , but it worked somehow.
But when i added rules it stopped working again.
So i tried to find out exactly why it stops working and i have somewhat narrowed it down to the "emerging" rules, when i add one of them, snort stops working.

I have no idea whats going on anymore :P

Not surprising.  The latest 3.0_12 package just has two minor bug fixes within the GUI itself.  The underlying Suricata binary is unchanged and remains at 3.1.2.

Netmap support will make it into more and more NIC drivers, but it will take a little time.

Bill

wow bmeeks is back  now i forgot my issue that bmeeks can answer.

It happens to me as well. I just use service watchdog package to keep the service on automated restart in case it stops after the nightly updates.