[prev in list] [next in list] [prev in thread] [next in thread] 

List:       snort-devel
Subject:    Re: [Snort-devel] Added features for Snort decoder?
From:       Jason Brvenik <jasonb () sourcefire ! com>
Date:       2009-05-08 17:40:57
Message-ID: 910b913d0905081040h29eaa25bu43a13ccfb60aa8a5 () mail ! gmail ! com
[Download RAW message or body]

I'll provide mt .$02 in line

On Fri, May 8, 2009 at 1:09 PM, Soumyadipta Das
<soumyadipta_das@yahoo.com> wrote:
> Hi Everyone,
>
> Following are two school of thoughts regarding the packet decoding:
>
> 1) The snort decoder engine(decode.c) decodes a packet and puts the
> different layer headers in different structures starting from the data link
> layer until layer 4(OSI-model). Contents of the upper layers are not
> directly segregated in structures and are left for preprocessors and rules
> to take care of. Benefit of this approach is the flexibility while writing
> rules to match for any particular pattern above layer 4. However, on the
> other hand it also opens up the possibility of a mistake in writing a rule.
>

It also does not impose overhead of decoding where it is not needed or
introduce complexity where it is not needed. The rules language is
itself is a a state machine and can track and decode a majority of
protocols. Where rules cannot effectively model to detect attack there
is a clear need to move to preprocessors and further normalization,
you can see evidence of this is the preprocessors already around. Some
say # of protocols supported is a key metric in assessing the
completeness of detection. I would argue that snort supports unlimited
protocols and that having to rely on a developer to add protocol
support is inherently flawed for reasons I will call out for #2

There are definitely some drawbacks in this approach in that you
cannot share a decode across multiple consumers of that information
but the problem set seems to be generally small so I wouldn't consider
it a significant area of concern.

> 2) A lot of commercial IPS/IDS tries to decode different application layer
> protocols. This approach provides more easy accessible granularity while
> writing a rule particularly for given protocol. For instance, a rule for a
> given function on a MSRPC named pipe distinguished by its UUID would be
> easier to write.

I would contend that t provides accessibility at the cost of
granularity and flexibility. You are beholden to the developers
thoroughness and understanding of the protocol and the added
complexity is likely to introduce unnecessary overhead and will
inevitably introduce a vulnerability. Simple and easy only works up to
the bounds of the person that implemented it.

A good example of this is ISS and the protocol decodes they use for
many things, all closed and developed in code. Some number of years
ago the ICQ protocol decoder was found to have an overflow and it
resulted in the most rapidly spread worm in all of history ( Check my
data here, I could be recalling incorrectly ) -
http://secunia.com/advisories/11073/

In the snort world it is just a rule, using a proven code base, not
requiring a recompile or regression, and unlikely to introduce a
vulnerability. The cost is that the rule writer must understand hte
protocol and triggering conditions. The reality is that this is the
case regardless of the implementation used to detect it. If you accept
that in order to detect you must understand then it is not a far reach
to know that armed with a rules language and the knowledge of the
vulnerability you can handle things just as well if not better.

Snort has had issues with in the past in much the same as the above
referenced case. Bottom line, new code = new complexity = potential
new vulnerability. Rules = new detection without new code without
potential for new vulnerability. Both methods still require intimate
knowledge of the tool and vulnerability.

>
> Please share your views on which would be a preferred approach.
>
> Regards,
> Soum
>
> ________________________________
> Now surf faster and smarter ! Check out the new Firefox 3 - Yahoo! Edition *
> Click here!
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Snort-devel mailing list
> Snort-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>
>

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Snort-devel mailing list
Snort-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-devel
[prev in list] [next in list] [prev in thread] [next in thread]