[Snort-users] Auto rules update

Max Vision vision at ...4...
Tue Jan 23 20:49:10 EST 2001

On Tue, 23 Jan 2001, Dr SuSE wrote:
> sed -e '/IDS226/d' -e '/IDS259/d' /tmp/vision.rules > /etc/snort/vision.rules
There were some great responses to this already, but I wanted to touch on
another aspect - the rules that are being filtered :)  Although I'm sure
that the wide variety of environments out there necessitate customization
of the rules, I would like to minimize the need as much as possible.
Perhaps the best approach to this end would be the make sure that each
signature detects an actual "attack", and not something that could easily
be ligitimate use.  Ok, I know that varies widely from site to site too,
but there are some things that could be improved.

Both of these example rules are really sadly complicated by a reliance of
a new/experimental/heroic preprocessor... the first rule IDS226 is a
content-based situation where a tweaked tcp stream assembly would come in
very handy.  For example, take a look at the session text of a sample
formmail exploit below first:

POST /cgi-bin/formmail.pl HTTP/1.0
Content-length: 79

recipient=root at ...274...%0Acat%20/etc/passwd&email=g23 at ...274...&subject=test


Now I would probably want to match on "POST " (although some formmail that
are vulnerable probably allow GET), "formmail" (using nocase and without
the extension because formmail, FormMail, Formmail.pl, FormMail.cgi are
all seen in the wild for some reason), and "%0a" (the actual exploit).

In some cases this will all be in the same packet, but have a look at the
interaction of the Snort plugins... how they affect this seemingly simple

If we use the http_decode plugin then it will turn the %0a into the binary
equivelent |0a| before our rule can work on it.  So instead of:
alert TCP $EXTERNAL any -> $INTERNAL 80 (msg: "IDS226/http-cgi-formmail";
flags: AP; content: "formmail"; nocase; content: "%0a";)
we would instead need:
alert TCP $EXTERNAL any -> $INTERNAL 80 (msg: "IDS226/http-cgi-formmail";
flags: AP; content: "formmail"; nocase; content: "|0a|";)

If we aren't using the stream plugin then someone can sneak this right by
with shorter tcp packets (when done on purpose it's called "session
splicing" but it's quite natural for large HTTP requests to be broken into
multiple packets.
But if we do use the stream plugin, then it will split the packet at the
"enter key", which translates to a newline in our HTTP session.
(StreamData.prunetime = 10;)  Note that there are several newlines
conveniently placed directly between "formmail" and "%0a".  Argh!

The solution is that everyone should use both plugins, and the
spp_tcp_stream processor should be tweaked to allow a stream to exclude
the newline separation (appropriate for telnet but not http)...  I'm sure
the author could do this faster and more gracefully than I could kludge
it, so I'll cc Christopher.

I will then go back through http attack detection alerts and set them

AH! But it's not over... the second example rule that you mention is
exctly the opposite.  In the case of IDS259/http-alibaba-overflow, we want
the stream preprocessor to cut at the newline character!  Here check out
another impromptue sample exploit (these are made up but should be close):
POST xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxx <*LOTS* more of this> xxxxxxxxxxxxx / HTTP/1.0
Note that the published exploit for this (AlibabaDoS.c) uses GET instead
of POST and doesn't bother with the HTTP/1.0 at the end....

Ok so this attack is definately going to be broken into multiple packets,
but without any carriage return.  If we have stream assembly rocking and
watch for "POST " or "GET " with an overall assembled packet length of
like >8000 bytes, then this will be a good signature that rarely false
positives.  It may not be specific to the Alibaba server, but this is what
was published first and in either case will detect the "too much data"

So to really win we should be able to tell the stream assembly plugin
whether we want to cut packets with newlines or not.

Another challenge is that there isn't any parsing of the protocol at all -
it would be great if we could inspect some of these more popular protocols
(smtp, http, pop, imap, etc) and write rules based on certain states or
commands (certain other commercial IDS tout this as a big win and they are

Anyhow, I'm sure there are rules that no matter how well designed might be
unnecesary on a particular network, so the filtering thread is valuable..
I just wanted to discuss some of the problem rules that folks may be
filtering and why they aren't better (yet).

Have fun!

More information about the Snort-users mailing list