RE: "trons" Rules

["Kohlenberg, Toby" <toby.kohlenberg () intel com>]

All opinions are my own and in no way reflect the views of my employer.

> -----Original Message-----
> From: Fyodor [mailto:fygrave () tigerteam net]
> Sent: Saturday, March 02, 2002 3:33 AM
> To: counter.spy () gmx de
> Cc: Snort-users () lists sourceforge net
> Subject: Re: [Snort-users] "trons" Rules
>
>
> My understanding (not what mr. Graham probably thinks, but could be
> similar): protocol analysis is when you take apart a protocol, analyse
> each field within the communication, track the state of the protocol
> communication with 'watched' hosts, and yell an alert if 
> something that
> you notice, looks fishy. i.g. erroneously long fields in protocol
> 'values' (long usernames in FTP, community strings in snmp), 
> binary data
> where ascii-only is expected, ascii data, where numeric only data is
> expected, unusual occurences/sequences of commands within the protocol
> (i.g. smtp is usually helo --> mail from--> rcpt to-->data-->quit, if
> someone has sequential helo, mail from, vrfy, quit chances that he is
> pockinga round with smth). etc.. protocol analysis (imho) is a module
> which takes alot of work (and cpu(!)) and is somewhere in between the
> signature matching and anomaly detection methods..

Yup, that jibes with my understanding as well- the issues that come up are
doing it fast and without sucking all your resources up (especially on
highly
utilized high speed links. Keeping track of tens of thousands of sessions
can
be hard). You get the benefit of not needing a specific signature, but you
also fall prey to the developers who don't implement according to RFC or
missing
a packet somewhere.
I thought the TRONS module was cool to hear about but personally I think it
reinforces a conclusion I've reached- Don't try to make one product do
everything.
If IDS is really important to you, use best-of-breed products for as many
technologies as you need to feel comfortable- Something from protocol
analysis,
something signature-based, maybe even a traffic analysis tool as well. Then
correlate them all in a central console that has the flexibility to actually
understand when two similar events from different products are a validation
of
a problem or a proof of false positive.

> Wouldn't know whether BlackICE actually does what it claims, but true,
> currently snort mostly 'normalizes' some application-level protocols
> data, before the signatures could be matched, without keep a track on
> the protocol state, or anything that bad guys could mock around.

Since it is a black box, I guess it is a matter of faith to some extent, but
if you look at the fact that Rob was able to announce that BlackICE caught
the
PROTOS SNMP tests without modifications and the alert names he gave (which
described problems with the protocol), it does suggest that he is doing
protocol
modeling/analysis.

> Snort2.x will be able to do more here, but as of the moment 
> it is still coming(tm)! :-)

I'll be interested to see it, my experience has been that it can be hard to
get it working right (fast, accurate, not a resource hog) the first time. Of
course, if anyone can do it I'd bet it would be Marty & Co.

All opinions are my own and in no way reflect the views of my employers

Toby

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users