[Snort-sigs] Suggestions for new attack response rules

Joe Patterson jpatterson at ...2901...
Thu Dec 2 08:09:37 EST 2004

It's not simple, and it's certainly not perfect.  (if we only allowed
perfect rules, we'd have a lot fewer rules than we do)  But even given that,
I think it could be usefull.  The primary utility lies in setting the
flowbit for the http-based attacks.

Given the following situations:
1) you don't have any web servers, you're just monitoring traffic out to the
net in general.
Then you would probably want to disable the 4 attack response rules, because
the web servers "out there" aren't under your control, and you don't
necessarily care if they're actually compromised, you primarily care if
someone in the network that *is* under your control is trying to hack other
people's boxes.

2) you do have webservers, all of which are well-behaved and use http status
codes in appropriate ways.
Wonderful, now you'll not only know when people attack, but when they

3) you have webservers that aren't quite standards compliant.  For instance,
I believe that IIS servers with a custom 404 page actually give a status of
200, but return the custom 404.
This isn't too big a deal.  Edit the 4 signatures for attack responses so
that they will match anything that isn't your custom 404 page.  Perhaps
something like 'content:!"404 page not found"' or whatever suits your

4) most of your webservers are compliant, but one or two are smoking crack,
and can't be trusted to return meaningful status codes for anything.
Add a suppression by_src for these rules, and only care about the alerts
from your more well-behaved webservers.

I just can't think of a case where these rules would actually be *bad*, and
there are certainly quite a few places where they would be usefull.

I guess the alternative is to use oinkmaster with a modification map for the
1K or so rules that I think need it to add the flowbits chunk.  But I felt
like this was a usefull enough thing that it would be worth adding to the
main distribution.


> -----Original Message-----
> From: Brian [mailto:bmc at ...95...]
> Sent: Wednesday, December 01, 2004 4:02 PM
> To: Joe Patterson
> Cc: snort-sigs at lists.sourceforge.net
> Subject: Re: [Snort-sigs] Suggestions for new attack response rules
> On Wed, Dec 01, 2004 at 03:51:25PM -0500, Joe Patterson wrote:
> > alert tcp any $HTTP_PORTS -> any any (msg:"ATTACK-RESPONSES
> User attack OK
> > response"; flow:from_server,established; pcre:"/^HTTP/1.1 (2|3)\d\d/";
> > flowbits:isset,http-user-attack; classtype:successful-user;)
> Yes, I've thought about this for a long time.  Its not anywhere near
> as simple as you suggest.
> Look at how nessus handles error codes.  MANY websites no longer use
> 200s for "good", and 300s & 400s for various errors, they use 200s for
> Sure, you might get a good feeling for the one or two sites you are
> looking at for reducing false positives.  In the rest of the world,
> just looking at HTTP codes is NOT enough.
> Brian

More information about the Snort-sigs mailing list