Had a bit of an issue with a client site recently, and ultimately it ended up in over 24 hours of downtime due to liaising with our hosting company who suspended the hosting for this specific client.
It appears the client was subject to some form of DoS attack via a HTTP Get Flood. However after liaising with the technical support they've stated such an attack would be "doomed to fail" due to the average home connection being 1mb DSL (Yeah...) and their connection being gigabit.. They went on to suggest a visitor may have been a bit to click-happy with the refresh button!
Am I correct in stating that in a shared environment, with the nature of the pages requested, the bandwidth would only play a very small part of the mechanism of attack - as the "Per Request Effort" on behalf of the server far outweighs the client's effort of sending a simple GET Request string to the server?
I've attached some technical details below, but I fail to see any other way in which to explain the downtime - all logs are fine except the anomalies with this one IP address. Application/Framework specific logs show no anomalies, error logs are also fine. In my mind it's pretty clear cut, but the response from the hosting company staff has had me doubting my conclusion.
Now I'm aware there's server wide ways of implementing protection against these types of scenarios, however as it's obvious that this company doesn't implement such protection - is there anything for a user in a shared environment to do?
- Duration of the "flood" was 161 seconds; with approximately 1204 requests
- Averaging at 7.5 requests per second, it's clear the browser wasn't rendering the response
- 802 GET Requests for a page that is top-level/public facing (i.e accessible by navigation of the site)
- 402 GET Requests for a script that is only accessible for
- No associated assets for the page were loaded after the initial first request (could be caching, or could be due to a browser not making the requests?)
- The User Agent was mysteriously coming up as IE9..
- The requested files both relied upon multiple database queries, and the database structure is quite complex due to the nature of the site.
- Requests continued even after the account was suspended, when a 500 Internal Server Error was being returned.