Re: Belaboring the point of FPs

From: Martin Roesch (
Date: 08/22/03

  • Next message: Sam f. Stover: "Re: Network IDS"
    Date: Fri, 22 Aug 2003 00:13:46 -0400
    To: "Graham, Robert (ISS Atlanta)" <>

    Hey Robert,

    Nice metaphors. :)

    There's one bit of context missing from your post, and that is the
    original purpose and environments that our respective products evolved
    out of. Snort is an open source extensible software framework for
    network traffic analysis that many people use as an intrusion detection
    system, RS7/BlackICE is a purpose built commercial NIDS engine. I
    wrote Snort for the first 2.5 years solely in my spare time and on
    what could generously be termed as a shoestring budget with a Pentium
    Pro 200 and a couple Celeron 300's as my development and testing

    Snort's detection engine was designed in the way that it was as a proof
    of concept and inertia being what it is, it took a couple years to get
    to the design that we have today. Development is still ongoing, but
    suffice to say that we're working on some new stuff that'll be pretty
    cool when it comes out.

    Snort gives you what you ask for sort of like UNIX/C give you what you
    ask for. BlackICE is much more of a black box, Windows to Snort's UNIX
    perhaps (and I'm not being snotty, I actually like win2k in my
    non-partisan moments). Given the backgrounds of both systems, I think
    the reasons for this are obvious. I was building a framework for
    everyone to fiddle with and you were building something that was going
    to have to be deployed on arbitrary win32 systems, a daunting prospect
    from a tech support standpoint so user fiddling with the innards were
    to be discouraged as much as possible.

    > I don't mean to take this analogy too far, but I'd like to point out
    > the
    > stories of genies-in-bottles who give you exactly what you ask for, but
    > not quite what you want. We all know the story of king Midas who wished
    > that everything he touched turned to gold -- but then realized the
    > folly
    > of his ways when he hugged his daughter, which turned her to gold.

    Yeah, but if he had been smart about it he could have done better for

    > I'm not saying that this is a BIG problem for Snort, please don't read
    > too much into the analogy. It is indeed a good thing that Snort gives
    > you what you ask for -- I'm just trying to point that it isn't 100%
    > good.

    This is kind of a "maturity principle" issue, do we trust people to
    take responsibility for their actions and behave in reasonable ways or
    not. We would certainly like to think so but history proves otherwise.

    > The basic problem is that the Snort rules language is not expressive
    > enough to give you what you want. It's like going to a French
    > restaurant
    > and ordering only those things on the menu that you can pronounce. I
    > have friends that order bagels at the morning because they are
    > embarrassed by their poor pronunciation of the French word "croissant".
    > It's true that the coffee shop is not at fault for delivering what the
    > customer asked for, but it doesn't mean the customer is completely
    > happy
    > with his bagel.

    I'd like to amend the above sentence to "The basic problem is that the
    Snort rules language is not *always* expressive enough to give you what
    you want". This is true and its what leads us to evolve the language.
    The byte_test/byte_jump functionality is a direct result of this
    problem. The Snort language could use an overhaul sometime in the not
    too distant future, it's certainly approaching the point at which we
    need to seriously evaluate its functionality and readability as they
    relate to ongoing extension and addition to the keyword system.

    > I write lots of signatures for my IDS (RealSecure 7). I have written a
    > clone of Snort (Trons). Most of the signatures that I write cannot be
    > expressed in the Snort rules language. For example, I put an IMAP
    > protocol-decode on port 143 that explicitly recognizes what an e-mail
    > message is, and therefore won't match any patterns inside it (unless,
    > of
    > course, those patterns are supposed to be for e-mail messages).
    > You could certainly extend the Snort rules languages with plugins. The
    > 'uricontent' keyword is a good example of a limitation with
    > pattern-matching that had to be resolved. You could certainly add a
    > plugin for IMAP that resolves the false-positive discussed below, but
    > the issue is that nobody has. Such problems can easily be solved within
    > the Snort architecture, it's just that when you get Snort today, such
    > problems are not solved.

    At the same time, it's exceedingly difficult to write this simple Snort
    rule as a BlackICE user (TRONS notwithstanding):

    alert tcp $EXTERNAL_NET any -> $ANON_FTP 21 (\
    flow: to_server, established; \
    content: "USER"; nocase; \
    content; !"anonymous"; nocase; distance: 1; \
    content; !"ftp"; nocase; distance: 1; \
    msg: "Non-anonymous login to anonymous FTP server"; \
    classtype: policy-violation; \
    tag: session 30 seconds; \
    sid: 100000; rev: 1;\

    > Again, I'd like to point out that when you use my IDS, you'll get a set
    > of signatures that I wanted to give you. You can certainly add your own
    > with the Trons feature and other "protocol-field" capabilities we give
    > you, and you can sometimes adjust the signatures, but you DON'T have
    > the
    > complete ability (like Snort) to arbitrarily change the signatures that
    > I wrote for you. As you can expect, since I wrote the signatures in a
    > specific way, I believe that you'll get what you 'want' better out of
    > my
    > IDS than Snort, but it's certainly true that you have less ability to
    > 'ask' my IDS to do something slightly different.

    This is the basic difference between our approaches, I assumed that I
    know nothing about defending people's networks and you decided
    differently. My approach, for better or worse, assumes that the user
    knows what they're doing or can at least figure it out. I emphasized
    flexibility over other traits, but I thought (I believe rightly) that
    that is what people wanted.

    I think this ultimately boils down to a religious argument, but it's
    certainly a valid one.


    Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
    Sourcefire: Enterprise-class Snort-based IDS Infrastructure -
    Snort: Open Source Network IDS -
    Attend Black Hat Briefings & Training Federal, September 29-30 (Training), October 1-2 (Briefings) in Tysons Corner, VA; the worldÂ’s premier 
    technical IT security event.  Modeled after the famous Black Hat event in 
    Las Vegas! 6 tracks, 12 training sessions, top speakers and sponsors.  
    Symanetc is the Diamond sponsor.  Early-bird registration ends September 6 Visit:

  • Next message: Sam f. Stover: "Re: Network IDS"

    Relevant Pages

    • Re: IDS vs. IPS deployment feedback
      ... I personally do not care what people use to detect, even though I have been able to get snort to match performance of commercial products. ... The people we should be concerned with will not show up in an IDS however. ... signatures for the same vulnerability, ISS can protect against the ...
    • RE: IDS vs. IPS deployment feedback
      ... Juniper, CISCO, McAfee have open or semi-open signatures. ... Also, AFAIK, in ISS you can use Snort syntax or similar to create your ... why Snort is called lightweight IDS on SNORT.ORG page? ...
    • Re: IDS vs. IPS deployment feedback
      ... It is not accurate to state that the IPS ... Those two IPS technologies are NFR and Snort. ... signatures for the same vulnerability, ... Snort rules are developed by volunteers (or Sourcefire). ...
    • RE: IDS vs. IPS deployment feedback
      ... claiming that ISS uses 1. ... asked for an example in which Snort used more signatures to provide ... agree that they handle exactly what the Snort rules are doing. ... You state that Snort uses 300 rules to cover one vulnerability while ...
    • RE: IDS vs. IPS deployment feedback
      ... Where Snort needs multiple ... signatures for the same vulnerability, ISS can protect against the ... This is an IDS ...