Snort vs Suricata
-
I don't want to start a flame war or anything, but I was just wondering what experience do people have going from Snort to Suricata (and vice-versa). Is there a reason someone would choose of of these systems over the other?
-
Personally I did not ever tried Suricata, the only reason is that Suricata does not support PPPoE in pfSense. As soon as it will I give it a chance. Reading several opinions seems to appoint Suricata being a real step ahead.
I am using Snort, configured as per https://forum.pfsense.org/index.php/topic,64674.0.html, it works pretty fine and I am ok with it.I am running 2.2Beta in home network and 15/1 ADSL.
-
From a home user perspective … For $30/year I can get the Snort VRT rules and use them with Snort (duh). Suricata cannot read all the Snort VRT rules.
So, it's a pretty easy decision to use Snort instead of Suricata.
If Suricata on pfSense develops into a true inline IPS, then that would be an important factor to reconsider changing. But for now advantage Snort.
-
I don't have a favorite. Each package offers some unique features. In terms of performance on pfSense, there is zero difference between the two packages today. In the future, that could change with a slight advantage going to Suricata because it is multi-threaded. However, any performance advantage will not show up until you get well past 1 Gigabit/second speeds.
It is true that Suricata cannot process all of the Snort VRT rule options and keywords. There are a handful it will not recognize, and so rules with those keywords will be tossed out. You get a warning in the log about the rule being ignored, and then Suricata continues on. The Suricata developers periodically update it so it recognizes newer VRT rule options. Generally speaking, Suricata today provides more detailed logging and offers additional packet inspection options as compared to Snort.
The newest release of Snort (2.9.7.0) now has a cool new Application Detection preprocessor. This preprocessor can recognize and alert on more than 2400 applications. I am currently testing this version in my lab and will soon be posting it for the pfSense developers to review and hopefully approve and merge. Details on the new Application ID feature can be found in this collection of Snort VRT Blog posts: http://blog.snort.org/search/label/openappid. For now, you have to create your own rules to use this new preprocessor. Fortunately creating custom rules is really quite easy. Some examples can be found in the previous link. For Snort on pfSense you will be able to enter the rules as "custom rules" on the RULES tab. So for all those admins out there who want to block Facebook or Twitter or just subcomponent applications, the new App ID feature coming in Snort 2.9.70 just might be your ticket!
Bill
-
That's a really cool feature! I wonder though, how would it work since Facebook, Twitter and alike use SSL? Wouldn't SSL stop Snort from performing a scan?
-
That's a really cool feature! I wonder though, how would it work since Facebook, Twitter and alike use SSL? Wouldn't SSL stop Snort from performing a scan?
I suppose that is possible, but maybe the new feature looks at the exchange of SSL startup data ??? It is based on the new Open Application ID kit that you can download from Snort.org. The application detection is done with Lua scripts which are included in the kit download.
I did a quick test yesterday by enabling the Twitter and Facebook app ID rules, and then visited the CNN web site. I got a ton of blocks and alerts from the various Twitter and Facebook widgets that are on the CNN web pages.
Bill
-
When would that version of Snort make it into pfSense? 2.2?
-
When would that version of Snort make it into pfSense? 2.2?
I can't give you an exact date. I can say that I have submitted the binary PBI package update patches to the pfSense Core Team for review. It appears from the flurry of posts and activity on the pfSense Bug Tracker Site that they are all quite busy getting pfSense 2.2 ready. So based on that, I'm guessing the Snort review may take a little longer than usual.
I have the updated GUI package Pull Request ready to submit as soon as the team has a chance to review the binary patches and then new PBIs are successfully built and tested.
Since the package is the same for 2.1.x and 2.2, when it is ready it will be released for both pfSense versions at the same time.
Bill
-
Suricata is more friendly when you write/test your own rules. But right now theres a CVE affecting 2.0.3…
Suricata let you write unusual rules with protocols and content inspect that I find more friendly when searching for malware/malformed crafted packet...
Snort is Cisco...
Suricata is US Gov funded...
Suricata is a powerfull engine, but unsoported by any "rules maker"....
Cisco is more and more protecting his business...
Suricata is a powerfull engine ;)
PS: Bill Dont forget IP rep for Suricta please :)
F.
-
Suricata is more friendly when you write/test your own rules. But right now theres a CVE affecting 2.0.3…
Suricata let you write unusual rules with protocols and content inspect that I find more friendly when searching for malware/malformed crafted packet...
Snort is Cisco...
Suricata is US Gov funded...
Suricata is a powerfull engine, but unsoported by any "rules maker"....
Cisco is more and more protecting his business...
Suricata is a powerfull engine ;)
PS: Bill Dont forget IP rep for Suricta please :)
F.
Version 2.0.4 of Suricata is also in the pipeline for the pfSense Core Team to review. As is the case with the Snort update review, I think they are quite busy with 2.2 for now and thus Suricata and Snort may have to wait a little.
Emerging Threats fully supports Suricata with a rule set customized a bit for it. I automatically load that rule set in the Suricata package when you select either of the two Emerging Threats options of "ET-Open" or "ET-Pro".
I have not forgotten about IP REP for Suricata, but unlike with Snort you must write your own IP REP rules for Suricata. There is no "automatic loading and using" of IP lists like exists for the Snort IP REP preprocessor. I have thus far hesitated adding it for this reason. I fear that Snort users will expect Suricata to work the same as Snort, and it will not out of the box. However, I will go ahead and add support for IP REP and bake in support for the Emerging Threats IQRisk paid subscription list.
Bill
-
Which rules do you believe provide better protection/coverage, ET or Snort VRT? And is it worth paying the $30/year for the pro versions of the rulesets?
-
Both of the rulesets are extremely outdated (those that have already started typing "but they were updated yesterday!", hush). That said, they do provide basic coverage for a general use case. Expect a lot of false positives coming from either set. Suricata works perfectly fine with ET, snort works perfectly fine with ET + snort's own rules.
I would personally go with their free versions, and add a few custom rules. That's what the snort and suricata config topics are for (blueprints).
-
As jflsakfja said above, both ET and VRT rules have some old and outdated stuff in them. They also do get updated for new threats, but one problem a lot of us see is that the old stuff seems to almost never get edited out. Or at least it is edited out somewhat slowly. I think that is the basis of @jflsakfja's comment about them being outdated.
Here is the primary difference between the paid and free rules. With the paid VRT rules subscription you are more likely to get a rule from them for a current exploit. The free rules are at least 30 days old, so any new exploit (less than 30 days old) will not be covered in the free rules. In the case of the ET-Open rules, it's actually a bit worse in my view because there are some exploit rules that never make it into the free version. They are only available in the paid ET-Pro version. That is the main way they differentiate between the two rule packages.
Using an IDS/IPS is a very labor intensive operation, especially at first. The admin must be able to identify and handle false positives while keeping rules in place to detect more prevalent threats. It's not really just install, turn on, and forget. Even the multi-thousand dollar commercial packages are not truly "turn on and forget" systems. If you don't know how to deal with false positives and tune your system to avoid them, then expect a lot of "outages" caused by the IDS/IPS that were unnecessary.
I see a decent number of posts here on the forum from users that seem to think you can just install the Snort or Suricata package and forget about it and your network will be protected. That's not true. You have to install the package, enable some rules, then start disabling false positives or adding suppress list entries for them. You have to analyze what types of assets you are protecting (web servers, mail servers, database servers, etc.) and set up either package (Snort or Suricata) keeping the defended networks in mind. You set things like ports, operating system types, etc. Then you make sure the appropriate preprocessors are enabled and that the proper rules are active.
Bill
-
Is there a good tutorial (or a set of tutorials) out there that I can go through to start learning how to do that, or do I need to get the pfSense 2.1 book?
-
In the case of the ET-Open rules, it's actually a bit worse in my view because there are some exploit rules that never make it into the free version. They are only available in the paid ET-Pro version. That is the main way they differentiate between the two rule packages.
And that is the problem with many skilled IT-people; they never paid attention in school during economics 101, because of which they still get scared when they hear these two words:
demand elasticity.
;D ;D ;D -
@Hollander: they not only missed the economics 101, but also missed the security 101 (refering to so called "industry leaders") ;-)
@Heli0s: Yeap, there are a couple of topics, depending on your usage (written by yours truly and contributed to by other members of the forum and others (those reading this will get it ;-))
I have to warn you though, these topics have sent a few people to "happy places where you wear your shirt front to back with nurses telling you "everything will be alright" as they stick needles in you". YMMVSnort: https://forum.pfsense.org/index.php?topic=64674.0 (outdated)
Suricata: https://forum.pfsense.org/index.php?topic=78062.0 (up to date, but written for suricata. some parts apply equally well to snort)
For serious exploits I've seen the free rules get the new rule faster than 30 days. Unless you are protecting mission critical systems (and even then it's debatable) I wouldn't go with the paid versions.
-
@jflsakfja:
For serious exploits I've seen the free rules get the new rule faster than 30 days. Unless you are protecting mission critical systems (and even then it's debatable) I wouldn't go with the paid versions.
For the most part I agree with jflsakfja on the point about free rules versus paid rules. In my personal opinion the subscriber VRT rules (just under $30 US per year) is not a bad deal. I currently maintain that subscription. For the price I pay I get a few rules earlier than I might using the free version, and it helps the Sourcefire VRT guys feed themselves and their family (that is, they derive some income from their efforts and so will hopefully continue their work). Now the $30 VRT option is only available for home users. Commercial subscriptions cost more. The ET-Pro rules currently only come in a commercial subscription version. They do not have a reduced cost "home user" version.
Bill
-
I might have been misunderstood at some point (gets more common everyday, I must do something about that). I'm not saying don't support them financially. If you like the project as a project (devs respond, you get value out of using it) and the only means of supporting them are the paid subscriptions, please get the subscription. If they openly accept donations, please donate to them. I'm saying I wouldn't use the rules that come from the paid subscriptions. The only downside might be that you are dealing with a couple of extra FP rules. If running production systems, that may or may not cost you your paycheck.
As bmeeks said, devs also need to eat :)
-
@jflsakfja:
I might have been misunderstood at some point (gets more common everyday, I must do something about that). I'm not saying don't support them financially. If you like the project as a project (devs respond, you get value out of using it) and the only means of supporting them are the paid subscriptions, please get the subscription. If they openly accept donations, please donate to them. I'm saying I wouldn't use the rules that come from the paid subscriptions. The only downside might be that you are dealing with a couple of extra FP rules. If running production systems, that may or may not cost you your paycheck.
As bmeeks said, devs also need to eat :)
Noted…and I knew what you were saying. Any rules, free or paid, will need monitoring and tweaking in order to work well for you. And that monitoring and tweaking certainly becomes much more critical for production commercial systems.
Bill
-
I think we should support the maintainers of the Rules, that being Snort or ET. I also believe that having both Snort and Suricata as a choice for IDS/IPS is beneficial. I know that Bill is maintaining both packages and keeping up with the updates which we all appreciate.
I hope that people remain somewhat split between the two packages so that we keep competition strong and in the end we all benefit from it.
In regards to the rules, I notice that the Pro verison gets a lot more updates to current events, Trojans and Malware. Even after 30 days, I do not believe that all of these make it to the Free Version. (I could be wrong).
I would recommend the ET Pro version for any commercial site vs the ET Open. If they had a better pricing package for Home Use, I believe they would sell a lot more Subscriptions.
ET Release: Daily Ruleset Update Summary 11/07/2014
http://emergingthreats.net/daily-ruleset-update-summary-11072014/
[] Summary: []
11 new Open signatures, 13 new Pro (11+2). Nuclear EK, Archie EK, Miuref/Boaxxe.
Thanks: Jake Warren, FoxIT, @kafeine, @EKWatcher and @abuse_ch.
[+++] Added rules: [+++]
2019670 – ET TROJAN ABUSE.CH SSL Blacklist Malicious SSL certificate detected (Dyre CnC) (trojan.rules)
2019671 – ET TROJAN ABUSE.CH SSL Blacklist Malicious SSL certificate detected (Dyre CnC) (trojan.rules)
2019676 – ET CURRENT_EVENTS Nuclear EK Payload URI Struct Nov 07 2014 (current_events.rules)
2019677 – ET CURRENT_EVENTS Archie EK Exploit Flash URI Struct (current_events.rules)
2019678 – ET TROJAN Ursnif Checkin (trojan.rules)
2019679 – ET TROJAN Archie EK Payload Checkin POST (trojan.rules)
2019680 – ET TROJAN Possible Archie EK Payload Checkin GET (trojan.rules)
2019681 – ET CURRENT_EVENTS Operation Huyao Landing Page Nov 07 2014 (current_events.rules)
2019682 – ET CURRENT_EVENTS Operation Huyao Phishing Page Nov 07 2014 (current_events.rules)
2019683 – ET TROJAN Miuref/Boaxxe Checkin (trojan.rules)
2019684 – ET CURRENT_EVENTS Evil EK Redirector Cookie Nov 07 2014 (current_events.rules)Pro:
2809131 – ETPRO MALWARE PUP Optimizer Pro Checkin (malware.rules)
2809132 – ETPRO TROJAN Win32.Yakes.hamc Checkin (trojan.rules)
[///] Modified active rules: [///]2018998 – ET CURRENT_EVENTS Archie EK Landing Aug 24 2014 (current_events.rules)
2019666 – ET TROJAN OSX/WireLurker HTTP Request for www.comeinbaby.com (trojan.rules)
2019667 – ET TROJAN OSX/WireLurker DNS Query Domain www.comeinbaby.com (trojan.rules)
2808988 – ETPRO WEB_CLIENT Possible Internet Explorer Buffer use after free CVE-2014-4127 (web_client.rules)
[///] Modified inactive rules: [///]2001407 – ET POLICY hidden zip extension .pif (policy.rules)
2001408 – ET POLICY hidden zip extension .scr (policy.rules)
[–-] Removed rules: [–-]2807930 – ETPRO TROJAN Win32.Boaxxe Trojan Checkin (trojan.rules)
