[Snort-sigs] Suggestions for new attack response rules

Joe Patterson jpatterson at ...2901...
Sun Dec 12 13:44:07 EST 2004


A byte count operator for session tagging is *exactly* what I'm looking for.
The fact that it's undocumented is annoying, but more importantly, it
doesn't seem to work quite the way I'd want it to.  I tried a couple of
variations on it.  First off, it seems to completely ignore the direction
modifier, which makes it easy to avoid.  Second, it doesn't make a
distinction between data bytes and header bytes.  So an ack with no data is
considered 40 bytes.  That in and of itself isn't neccessarily fatal.  But
not having the direction modifier seems a big problem for me.  Maybe it just
needs to be polished a little bit, and documented.

Thanks for pointing it out.

-Joe

> -----Original Message-----
> From: Jason [mailto:security at ...704...]
> Sent: Saturday, December 11, 2004 2:24 PM
> To: Joe Patterson
> Cc: snort-sigs at lists.sourceforge.net
> Subject: Re: [Snort-sigs] Suggestions for new attack response rules
>
>
> Joe Patterson wrote:
> > Now that I've had a chace to play around with it a little more,
> I can more
> > accurately point out a problem with tagging.  The problem it
> that it's also
> > trivially evaded, due to the limitations of the tagging
> mechanism.  I think
> > it *can* be fixed.  Whether or not it *should* be fixed, and
> the mechanisms
> > for doing so, I'm curious to know what others think.
> >
> > The problem stems from the fact that you can only tag a session
> by packets
> > or seconds.  But how many packets/seconds do you tag?  At first
> blush, I'd
> > say maybe 3-4 packets, since that should contain the server's
> response and
> > some context, or maybe just a second or two, since the servers should be
> > fairly fast.  The problem is, I'd be wrong.  Take, as an example, the
> > following exchange (c-> denotes a packet from the client to the
> server, s-<
> > denotes a packet from the server to the client, text in {} is
> > meta-information):
> >
> > c-> GET /scripts/cmd.exe?/c+dir HTTP/1.1\r\n {This triggers an alert}
> > s-< {ack,tagged packet #1}
> > c-> Host: www.victim.com\r\n
> > s-< {ack,tagged packet #2}
> > c-> User-Agent: Telnet\r\n
> > s-< {ack,tagged packet #3}
> > c-> Accept: text/html,text/plain\r\n
> > s-< {ack,tagged packet #4}
> > c-> Accept-Language: en-us,en\r\n
> > s-< {ack,tagged packet #5}
> > c-> Accept-Charset: ISO-8859-1,utf-8\r\n
> > s-< {ack,are we still tagging?}
> > c-> \r\n
> > s-< HTTP/1.1 404 Not Found{...}
> >
> > If the client delays each of those packets by a few seconds,
> the response
> > will only show up if you're tagging the session for a very long time.
> > Similarly, there's no need to break these packets on newline boundaries.
> > Each character could come in its own packet.  You always could
> tag more, but
> > if the attacker can figure out how long your tagging is, he can
> adjust his
> > attack accordingly.  And if you ever get a false positive on
> the download of
> > something huge, you'll get a huge flood of tagged packets in your IDS.
> >
> > There are three solutions that I can see:
> >
> > 1) modify the tagging mechanism so that it doesn't consider a
> packet to be a
> > packet unless there's data past the tcp header.
> > 2) extend the functionality of tagging to allow it to tag all
> packets in a
> > session until a specified number of payload bytes have been seen.
> > 3) put a reasonably intelligent proxy in front of your servers to groom
> > shenanigains like this, and run the IDS behind it.
> >
> > Does anyone see any other possibilities, or reasons why my suggestions
> > really suck, etc.?
>
> Flowbits would not help here either unless you wanted to alert on every
> packet for the session and then you thresholded the rule. ( That is
> plain ugly ) I think the undocumented bytes operator for tag should do
> the trick in this case.
>
>
> from tag.c
>
>          else if(!strncasecmp(arg, "bytes", 5))
>          {
>              metric |= TAG_METRIC_BYTES;
>              bytes = count;
>          }
>
>
> so it should work something like this
>
> tag:session,1600,bytes;
>
>
>
>
>





More information about the Snort-sigs mailing list