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.?
-Joe
-----Original Message-----
From: snort-sigs-admin@lists.sourceforge.net
[mailto:snort-sigs-admin@lists.sourceforge.net]On Behalf Of Jason
Sent: Tuesday, December 07, 2004 12:11 AM
To: Joe Patterson
Cc: Brian caswell; snort-sigs@lists.sourceforge.net
Subject: Re: [Snort-sigs] Suggestions for new attack response rules
Apologies for taking a while to respond. life...
Joe Patterson wrote:
-----Original Message-----
From: Brian caswell [mailto:bmc@snort.org]
Sent: Saturday, December 04, 2004 2:54 PM
...
Not only will you get a ton of false negatives, you can get a ton of
This seems like an odd justification to me. True, the
inclusion of the rule
will not guarantee a lack of false negatives. Some percentage
of successful
attacks will not generate alerts. The converse of this,
however is the fact
that not having the rule will be guaranteed to generate 100%
false negatives
(of this rule).
which is ultimately a false sense of security. It becomes far too easy
to discount an alert because you do not see a corresponding "validator"
alert. In a custom unpublished ruleset this has some validity because
the attacker has no way of knowing you are using this system. In a
published ruleset it only serves to provide the attacker another vehicle
to make you miss the alert or discount it all together.
false positive "you got owned" alerts. It would be rather trivial to
convert a simple CGI scan into a "Oh god, the world is falling"
generator.
Let me reiterate, the idea is a nice one. However, in practice, its
not as simple as adding a few flowbits.
It's certainly not a simple thing. So let me pull back and make a more
modest suggestion, with a bit of history. When I first started
using snort
and writing my own rules, I looked at the "tag" keyword and
though it was
really cool. Then I looked at what it actually did, and it
turned out to be
not-quite-so-great. It's improved a bit since then, but there are still
issues with it.
I would be interested in hearing what your issues with the current tag
functionality are. I suspect that there is anything wrong that cannot be
remedied easily as it relates to tag functionality. There might be
features that are desired but that is a different question.
I see flowbits as very usefull in many ways, but among them
Agreed.
is a sort of improved flow tagging.
Disagree completely. Using flowbits forces the engine to raise multiple
alerts for a clearly related issue. This places a burden on the analyst
to correlate those events unless you use another tool to do the
correlation... It also places a further burden on the system doing the
inspection when all you really want is the response logged with the alert.
As has been suggested here, my original
rules had a weakness, in that it is programmatically impossible
(or at the
very least prohibitively difficult) to write a rule that can
successfully
distinguish between a successful response and an unsuccessful response.
Fully qualified analysis requires more. It requires the application of
human intelligence, specifically that of a talented intrusion
analyst. In
order to give that analyst sufficient information to make an informed
decision, let me propose a simpler rule:
alert tcp any $HTTP_PORTS -> any any (msg:"ATTACK-RESPONSES http attack
response"; flow:from_server,established; content:"HTTP/1"; depth:6;
flowbits:isset,http-attack; classtype:misc-activity;)
Interesting out of the box thinking but why would this be preferred to
using tag?
This way, the initial attack is seen, as always. misc-activity
will likely
be a low enough priority that it doesn't trigger any "the world
is falling"
alarms. However, when the analyst is examining the attack, he
can look for
the corresponding response, and use some intelligence to
determine if the
response indicates that the attack was a success or not. This
rule *should*
catch the first packet of response in every case. If the
analyst *can't*
find the corresponding response, that is also usefull
information. It means
that whatever the attacker did prevented the server from responding. I
would categorize that as a successful DOS attack. No matter what, the
analyst has more information at his disposal with which to make
an informed
assessment of the overall severity of a particular attack.
see above for why I think this is less desirable. I still do not see how
this is better then having the packets associated with the attack itself.
Does this strike you as better, or worse?
Worse, it creates a social attack vector and doubles the amount of work
required.
-------------------------------------------------------
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
-------------------------------------------------------
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
