[Snort-sigs] Suggestions for new attack response rules

Jason security at ...704...
Thu Dec 2 19:33:01 EST 2004


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
>>
>>
> 
> 
> 
> 
> -------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> 




More information about the Snort-sigs mailing list