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;
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
