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
succeed.
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
environment.
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.
-Joe
-----Original Message-----
From: Brian [mailto:bmc@snort.org]
Sent: Wednesday, December 01, 2004 4:02 PM
To: Joe Patterson
Cc: snort-sigs@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
EVERYTHING.
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
-------------------------------------------------------
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
