Some douchebag has been scanning my sites for a variety of potential database exploits. My sites are secure, so there is no real security threat, but the scans are extremely annoying and waste my server resources. Resources like bandwidth and memory that I would rather use for legitimate visitors. So after collecting some data and experimenting a bit, I wrote a simple .htaccess snippet to block a vast majority of these pathetic database-exploit scans.
Here are some representative examples of the types of ill requests that we’re dealing with in this post:
/INFORMATION_SCHEMA.CHARACTER_SETS /%27%29%3BWAITFOR%20DELAY%20%270%3A0%3A5%27-- /%27%20AND%208210%3D5848%20AND%20%27oNnL%27%3D%27oNnL /%20UNION%20ALL%20SELECT%20NULL%2CNULL%2CNULL%2CNULL%2CNULL%2C%2CNULL%2CNULL--%20 /%20AND%20%28SELECT%20%2A%20FROM%20%28SELECT%28SLEEP%285%29%29%29zgTF%29--%20wWOb /%25%27%3BSELECT%20DBMS_PIPE.RECEIVE_MESSAGE%28CHR%28110%29%7C%7CCHR%2888%29%7C%7CCHR%2884%29%7C%7CCHR%2882%29%2C5%29%20FROM%20DUAL-- /%29%20AND%203003%3DCAST%28%28CHR%28113%29%7C%7CCHR%28112%29%7C%7CCHR%28120%29%7C%7CCHR%28113%29%7C%7CCHR%28113%29%29%7C%7C%28SELECT%20%28CASE%20WHEN%20%283003%3D3003%29%20THEN%201%20ELSE%200%20END%29%29%3A%3Atext%7C%7C%28CHR%28113%29%7C%7CCHR%28122%29%7C%7CCHR%28112%29%7C%7CCHR%28107%29%7C%7CCHR%28113%29%29%20AS%20NUMERIC%29%20AND%20%284254%3D4254 /%20AND%208948%3DCONVERT%28INT%2C%28SELECT%20CHAR%28113%29%2BCHAR%28112%29%2BCHAR%28120%29%2BCHAR%28113%29%2BCHAR%28113%29%2B%28SELECT%20%28CASE%20WHEN%20%288948%3D8948%29%20THEN%20CHAR%2849%29%20ELSE%20CHAR%2848%29%20END%29%29%2BCHAR%28113%29%2BCHAR%28122%29%2BCHAR%28112%29%2BCHAR%28107%29%2BCHAR%28113%29%29%29
As you can see, these requests mostly include terms used in database queries, along with a bunch of encoded characters. If you are seeing requests like these in your server logs, understand that they are not friendly, but rather are probing your site to find a variety of known exploits and vulnerabilities.
Even worse, usually the douchebags who are running these malicious scans are completely clueless when it comes to conserving their own resources. Instead of logging server responses to avoid duplicate results and save time, they just keep hammering away, over and over and over.. Come on man, this isn’t a password — you can’t brute-force your way into a database exploit.
In any case, if your site is targeted with this sort of nonsense, take a minute to protect yourself with the following .htaccess snippet.
As explained in my book, .htaccess made easy, securing your site with .htaccess is efficient, fast, and flexible. Here is a perfect example. To stop a majority of the d-bag database-exploit scans, just add the following directives to your site’s root .htaccess file:
RedirectMatch 410 (NULL(.*)NULL(.*)NULL|INFORMATION_SCHEMA\.CHARACTER_SETS|SELECT(.*)CASE(.*)WHEN|AND(.*)AND(.*)oNnL|CONVERT(.*)INT(.*)SELECT|SELECT(.*)SLEEP|WAITFOR(.*)DELAY|DBMS_PIPE\.RECEIVE_MESSAGE)
Save, upload, and done. This technique is sweet because it very specifically targets database-exploits and should not interfere with anything else on your site. Still you want to keep an eye on things, but in general there should be no false positives. Just solid protection against d-bag database exploits.
410“Gone” status code as the response for this technique. It’s my new favorite. You are more than welcome to change that to the ol’ standby,
403“Forbidden”, or whatever other status you prefer.