DOS attack question

Question

We are flooded with web request on our site which appears to be DOS attack.

• it is all on port 80
• the distribution of packet sizes is NOT normal web traffic
• 33% of packets are 64 or 66 bytes
• 75% of packets are 128 bytes or less
• 99% of packets are less than 256 bytes
• we are running around 10K packets / second
• during a 5 second window, we saw web requests from 822 distinct IP addresses
• all requests are for / (the home page)

we tried switching the IP address but unfortunately attack is happening on domain name level and not IP level...

any help would be appreciated.

Answer 1

Is there anything else similar about all of the requests (other than the request for /)? I've seen some weak DoS attempts where the attacker uses the same user agent string for the whole attack.

If that's the case for you, you could just dump requests for those user agent strings using mod_rewrite (if you're using apache):

RewriteCond %{HTTP_USER_AGENT} TheBadUserAgentStringHere  
RewriteRule .* - [F,L]  

That prevents your web server from taking the time to render your home page for those requests and it returns a 403/Forbidden to the requestor.

Answer 2

If they are hitting GET / HTTP/1.0, as rackerhacker says, if you can see something similar in the UserAgent strings, you could try to filter it. If your site is dynamic, you might consider putting Varnish in front and hardcode a TTL of 5 minutes or more for the homepage which removes the load from Apache and addresses a number of other potential attack vectors.

If you're not running Apache 2.2.15+, the next attack will probably be a Vampire attack which the new request_timeout module was written to prevent. Varnish/Squid and Nginx, Lighttpd, etc already protect against it due to the way they handle traffic.

You have to withstand the attack, but, when they see their efforts aren't working, they'll change tactics.

You might also see if your hosting company has any processes in place to help identify and fight the incoming attack.

Answer 3

We actually ended up using Preventier solution from Rackspace which stopped the attack.