[Snort-sigs] Suggestions for new attack response rules

Joe Patterson jpatterson at ...2901...
Sat Dec 4 22:28:01 EST 2004

> -----Original Message-----
> From: Brian caswell [mailto:bmc at ...95...]
> 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).

> 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 see flowbits as very usefull in many ways, but among them
is a sort of improved flow tagging.  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;)

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.

Does this strike you as better, or worse?


More information about the Snort-sigs mailing list