Suricata replaces exactly what?



  • I understand that Suricata is acting as a "Snort replacement", but before I install it, are are there things besides Snort that I should remove first? Any conflicts with Dansguardian? Other packages?



  • No, there are no other conflicting packages.  You can even install Snort and Suricata together, but it is not recommended (and only one of them can be configured for blocking at the time).

    Think of Suricata more as a Snort alternative rather than a replacement.

    Bill



  • @bmeeks:

    No, there are no other conflicting packages.  You can even install Snort and Suricata together, but it is not recommended (and only one of them can be configured for blocking at the time).

    Think of Suricata more as a Snort alternative rather than a replacement.

    Bill

    Thanks. The reason why I said "snort replacement" is that my understanding is that it's better performing, better scaling, and generally much more modern in its architecture, while still being able to use snort rulesets. Am I wrong in these basic assumptions? I know it's not a plug-in replacement for Snort, but anything that uses less resources, scales better and is more future proof seems to be a good way forward.



  • Well, a few months ago you would have been pretty much correct.  However, with the recent release of the Snort 3.0-BETA code by the Snort VRT, things may become more "balanced" between Snort and Suricata.  The new Snort will be multithreaded and a lot more "auto-configuring" according to the notes.  We will have to wait and see.  Another new feature just released as open source in Snort 2.9.7.0 is the OpenAppID Layer 7 application detectors.  This is a feature Suricata currently lacks.

    As for using Snort VRT rules in Suricata, be prepared for a significant fraction to not load due to syntax errors.  There are a number of newer keywords and rule options that Snort uses that Suricata does not yet recognize.  For example, if you enable something like the IPS Balanced Security Policy rules in Suricata, be prepared for several hundred rules (I think near 750 at last count) to not compile and produce syntax errors.

    Nothing against Suricata, but it is better suited for the Emerging Threats rule sets since they produce a Suricata-only version of those rules.

    Bill



  • Thanks for the update on Suricata vs. Snort. Good to know.

    I did notice that Suricata seems to use a lot less resources: Snort seemed to push my CPU and memory usage up quite a bit, and with Suricata active on four NICs, I'm barely at the 10% mark.

    Is that problem also solved with Snort 3.0 or is it the same (or worse) resource hog (pun intended) as Snort 2.x?



  • @bmeeks:

    Another new feature just released as open source in Snort 2.9.7.0 is the OpenAppID Layer 7 application detectors.  This is a feature Suricata currently lacks.

    Just a question: Suricata does, I thought, L7 inspection of HTTP streams. Is that "hard coded" and limited to HTTP, i.e. no plug-in architecture for other protocols, or how does this differ from the OpenAppID Layer 7 app detectors that you mention?
    Just trying to learn as much as I can, although given the performance advantage Suricata holds right now, I likely will use that at least until Snort 3.0 is out and available as a pfSense package…



  • @rcfa:

    Just a question: Suricata does, I thought, L7 inspection of HTTP streams. Is that "hard coded" and limited to HTTP, i.e. no plug-in architecture for other protocols, or how does this differ from the OpenAppID Layer 7 app detectors that you mention?
    Just trying to learn as much as I can, although given the performance advantage Suricata holds right now, I likely will use that at least until Snort 3.0 is out and available as a pfSense package…

    Suricata does L7 inspection for a handful of things.  These are currently hard-coded.  You can see them on the APP PARSERS tab.  The OpenAppID feature is something Cisco (formerly Sourcefire) open-sourced that was previously proprietary.  It can detect over 2400 applications at present (Facebook, various chat, peer-to-peer and TOR services, for example).  It even works for HTTPS by watching the SSL cert exchanges to glean host/domain names (this is how it can block Facebook apps).  Here is a link to the Snort VRT Blog describing the feature:  http://blog.snort.org/2014/03/firing-up-openappid.html

    Since the OpenAppID detector package has been released to open-source, I suspect it will eventually find its way into the Suricata code base.  Cisco did this to promote user-contributions to the OpenAppID detector library.

    Bill



  • Interesting stuff, when used for getting rid of unwanted junk on the internet, but it sounds like OpenAppID is also sort of what China, Iran, etc. use to filter the internet  ::)



  • @rcfa:

    Interesting stuff, when used for getting rid of unwanted junk on the internet, but it sounds like OpenAppID is also sort of what China, Iran, etc. use to filter the internet  ::)

    Personally I am not a huge fan of such filtering (attempting to block various applications).  My thoughts are to set appropriate polices and expectations for your employees, and then cut off the limbs (figuratively speaking) of violators.  The problem with trying to filter such things is that you generally wind up playing whack-a-mole and you can unintentionally block legitimate traffic in the quest to block some undesirable traffic.

    However, I know that some corporate structures are iron-clad in their policies; so I don't fault the admins at those locations for trying to block applications.  You can be successful to a point, but you will never be 100% effective.  For those folks that absolutely need to block certain stuff, OpenAppID can be a useful tool.  Just remember it is not infallible.

    Bill



  • Yeah, sure. Point taken, although I'd be mostly filtering myself, anyway, if I wanted to restrict the users…

    More interested in doing things like ad filtering, or detecting/blocking various phone-home type things, because open ports can be abused, monitoring whether the ports are actually used by the protocols/apps for which they were opened would be my main concern.
    I neither trust ISPs nor closed-source software vendors  further than I can throw them (which given their abstract nature is a distance of zero)...


Log in to reply