[Snort-sigs] Suggestions for new attack response rules
security at ...704...
Mon Dec 6 21:20:02 EST 2004
Apologies for taking a while to respond. life...
Joe Patterson wrote:
>>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
> 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