[Snort-users] "trons" Rules
toby.kohlenberg at ...1966...
Sat Mar 2 21:09:22 EST 2002
All opinions are my own and in no way reflect the views of my employer.
> -----Original Message-----
> From: Fyodor [mailto:fygrave at ...121...]
> Sent: Saturday, March 02, 2002 3:33 AM
> To: counter.spy at ...348...
> Cc: Snort-users at 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
utilized high speed links. Keeping track of tens of thousands of sessions
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
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
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
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
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
PROTOS SNMP tests without modifications and the alert names he gave (which
described problems with the protocol), it does suggest that he is doing
> 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
More information about the Snort-users