For the last couple of days I've noticed that my server's been inundated with a huge number of unwanted requests. The requests are firing what looks like SQL injection code against the server with a huge query string that tries to execute code on the server. Requests look something like this:
The attack is broad but the content is definitely gained from some previous spidering as this attack is using proper query string values and is hitting a wide swath of URLs on my site. It's hitting ASP.NET applications as well as some of my older West Wind Web Connection applications which is where I noticed this problem first.
Although I'm not terribly worried about these attacks actually getting into a database, it does end up hitting applications and so wasting CPU cycles and returning bandwidth that is effectively wasted which is annoying at least.
It also appears that these SPAM requests aren't absolutely slamming servers at least not on my end with requests using typical robot intervals with no more than a few requests every few seconds. It doesn't qualify (yet?) as a DOS attack.
Apparently I'm not the only one getting slammed. A number of other developers have been twittering all day about large swells in logs files and sluggish performance of their sites as well so this is fairly wide spread.
IIS 7 includes some request filtering tools which correspond roughly to what used to be the separate URLScan utility. The above would be easy to filter based on the fixed content, but unfortunately the <requestFiltering> feature of IIS 7 in ApplicationHost.config (in \windows\system32\inetsvr\config) does not allow for URL string filtering.
What I did however is count on the size of the above being rather large and setting up some query string length limits with the following setting in applicationhost.config:
which filters the query string length at 1k. This is probably a good idea anyway, unless of course you have applications that generate extraordinarily long query strings.
With this in place the caller receives a 404:
This is obviously not a very solid solution - as soon as a smaller query string is used this approach no longer works, but for now this works to keep these request from reaching any application code and waste CPU cycles.
There are a few other ways that you can filter such as not allowing encoded text (kinda risky if you have many apps on your server) and not allowing upper ASCII characters.
If you're using IIS 6 or earlier you can probably achieve something similar using UrlScan on which the IIS 7 functionality is based in concept.
It's really disheartening to see this sort of waste of energy - on both ends for those perpetrating these attacks as well as the hassle of having to prevent it or at least fend it off. We live in shitty times when this is somebody's way to amuse themselves.
Other Posts you might also like