[Snort-sigs] Suggestions for new attack response rules

Matthew Jonkman mjonkman at ...2436...
Fri Dec 3 08:30:07 EST 2004


I would go along with this myself. I tend to err on the side of more 
information being a good thing, up to the threshold of saturation of 
course.

Lets put these up in the bleeding rules for a while and see how they go 
eh? Worst thing that can happen is get get slammed with falses for a few 
minutes and have to take them back out.

I'll post the rule below shortly. Any ideas for modification welcome.

Matt

Joe Patterson wrote:

> 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 at lists.sourceforge.net
>>[mailto:snort-sigs-admin at lists.sourceforge.net]On Behalf Of Jason
>>Sent: Thursday, December 02, 2004 10:33 PM
>>To: Joe Patterson
>>Cc: Brian; snort-sigs at 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 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
>>>>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
>>>>
>>>>
>>>
>>>




More information about the Snort-sigs mailing list