[Emerging-Sigs] strategy of suppressing unsuccessful web attacks

Russell Fulton r.fulton at auckland.ac.nz
Mon Oct 25 19:06:09 EDT 2010

Replying to myself:

It has been pointed out that the big issue with this is that many web servers are (mis?)configured to return 200 even for page not found which certainly reduces the effectiveness of this strategy.  I did know this but it had slipped my mind.  Since these are local web servers under the organisation's control then I can use this as an incentive for admins to improve their error handling.

The other thing that was pointed out is that one should not trust any output from a potentially compromised server.   Very true. But again in our case I would be prepared to accept this risk for the sake of reducing the noise.  If an web server admin gets one or two alerts a day they are far more likely to follow them up than if they are getting twenty.

THis is very much a matter of horses for courses -- we have 100s of low value web servers on campus apart from the 'official' ones that host University and faculty stuff and it these smaller less tightly managed servers that I am trying to deal with here.

I would not recommend that the server response checking rule be turned on by default if anything like this was incorporated into a distributed rule set.


On 26/10/2010, at 11:12 AM, Russell Fulton wrote:

> It occurs to me that we could add a flow bit to various web exploit signatures and then have a rule that triggered on seeing a 200 response coming back from the server.  THis of course does not say if the attack was successful or not but will at least tell us if the server is potentially vulnerable. 
> It also seem likely that since this is not being done then there is a good reason why not :) 
> My idea would be to have a single flowbit, say "ET-web-exploit-attempt" which we set on appropriate rules and then have a single rule that fires on a "success" response from the server.  I would leave the alerting on the original sigs as they are now.  i.e. not suppressing the alert at the snort level.
> I am particularly interested in this for my automated reports that I send out to server admins.  It would allow me to suppress alerts for exploit attempt that clearly failed.  Another approach would be to alert on all server responses and then process the pcaps to figure out how the server responded  - eg. ignore sql injection attacks that resulted in error returns.
> I intend to do some experimenting with this but would like to know if I have over looked anything.  As I said above it seems an obvious thing to do.
> What would be really neat would be to be able to suppress the original alert and then report the original alert from the rule with the flow bit.  I.e. have the response rule trigger the original alert retrospectively.
> Russell
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
> http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html

More information about the Emerging-sigs mailing list