I wouldn't say it necessarily breaks down. In situation 1, you don't care,
because you don't care about these rules anyway. In situation 2, an
attacker has to, in their initial attack, not only compromise the server,
but cause the server to change its handling of the cgi that it is *currently
running* to non-parsed-header mode, and then send back a 4xx/5xx header.
That may be possible, but I would say that it *really* raises the bar.
Situation 3 raises the bar a bit less. An attacker has to do all the normal
work of compromising a server, and has to make sure that all of the replies
he gets include that custom 404 message.
The primary utility I'm trying to get to here is this. Looking at one of my
apache webservers, in the last two weeks I've gotten 70 requests for
/scripts/..%%35c../winnt/system32/cmd.exe?/c+dir. They all got a 400
response. They all triggered an IDS alert. Those alerts weren't really
false positives. It was a real attack, but the server wasn't vulnerable. I
certainly can't ignore those alerts, but I can take my time getting to them.
However, if someone were to (unbeknownst to me) stick an unpatched IIS box
in the DMZ, and that same request came in and received a 200 OK response, I
would absolutely want to know about it immediately. That's what I see as
the primary value of these rules.
-Joe
-----Original Message-----
From: snort-sigs-admin@lists.sourceforge.net
[mailto:snort-sigs-admin@lists.sourceforge.net]On Behalf Of Jason
Sent: Thursday, December 02, 2004 10:33 PM
To: Joe Patterson
Cc: Brian; snort-sigs@lists.sourceforge.net
Subject: Re: [Snort-sigs] Suggestions for new attack response rules
The concept breaks down the moment the attacker instructs the server to
return a HTTP 404 error document with the content you need and then
spawns a shell to you.
Joe Patterson wrote:
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
-------------------------------------------------------
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
-------------------------------------------------------
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
