[Snort-sigs] Suggestions for new attack response rules

Jason security at ...704...
Mon Dec 6 21:20:02 EST 2004

Apologies for taking a while to respond. life...

Joe Patterson wrote:
>>-----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).

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"
>>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


> 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 

More information about the Snort-sigs mailing list