18,000 MySQL injection attempts per day: Stopping the attempts - php

Question

This question is not about protecting against SQL injection attacks. That question has been answered many times on StackOverflow and I have implemented the techniques. This is about stopping the attempts.
Recently my site has been hit with huge numbers of injection attacks. Right now, I trap them and return a static page.
Here's what my URL looks like:
/products/product.php?id=1
This is what an attack looks like:
/products/product.php?id=-3000%27%20IN%20BOOLEAN%20MODE%29%20UNION%20ALL%20SELECT%2035%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C%27qopjq%27%7C%7C%27ijiJvkyBhO%27%7C%7C%27qhwnq%27%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35%2C35--%20
I know for sure that this isn’t just a bad link or fat-fingered typing so I don't want to send them to an overview page. I also don’t want to use any resources on my site delivering static pages.
I’m considering just letting the page die with die(). Is there anything wrong with this approach? Or is there an HTML return code that I can set with PHP that would be more appropriate?
Edit:
Based on a couple of comments below, I looked up how to return 'page not found'. This Stack Overflow answer by icktoofay suggests using a 404 and then the die(); - the bot thinks that there isn’t a page and might even go away, and no more resources are used to display a page not found message.
header("HTTP/1.0 404 Not Found");
die();

Answer 1

Filtering out likely injection attempts is what mod_security is for.
It can take quite a bit of work to configure it to recognize legitimate requests for your app.
Another common method is to block IP addresses of malicious clients when you detect them.

Answer 2

You can attempt to stop this traffic from reaching your server with hardware. Most devices that do packet inspection can be of use. I use an F5 for this purpose (among others). The F5 has a scripting language of its own called iRules which affords great control and customization.

Answer 3

The post has been unblocked, so I thought I’d share what I’ve been doing to reduce attacks from the same ip address. I still get a half dozen a day, but they usually only try once or twice from each ip address.
Note: In order to return the 404 error message, all of this must come before any HTML is sent. I’m using PHP and redirect all errors to an error file.
<?php
require_once('mysql_database.inc');
// I’m using a database, so mysql_real_escape_string works.
// I don’t use any special characters in my productID, but injection attacks do. This helps trap them.
$productID = htmlspecialchars( (isset($_GET['id']) ? mysql_real_escape_string($_GET['id']) : '55') );
// Product IDs are all numeric, so it’s an invalid request if it isn’t a number.
if ( !is_numeric($productID) ) {
$url = $_SERVER['REQUEST_URI']; // Track which page is under attack.
$ref = $_SERVER['HTTP_REFERER']; // I display the referrer just in case I have a bad link on one of my pages
$ip = $_SERVER['REMOTE_ADDR']; // See if they are comng from the same place each time
// Strip spaces just in case they typed the URL and have an extra space in it
$productID=preg_replace('/[\s]+/','',$productID);
if ( !is_numeric($productID) ) {
error_log("Still a long string in products.php after replacement: URL is $url and IP is $ip & ref is $ref");
header("HTTP/1.0 404 Not Found");
die();
}
}
I also have lots of pages where I display different content depending on the category that is picked. In these cases I have a series of if statements, like this if ($cat == 'Speech') { } There is no database lookup, so no chance of SQL injection, but I still want to stop the attacks and not waste bandwidth displaying a default page to a bot. Usually the category is a short word so I modify the is_numeric conditional above to check for string length e.g. if ( strlen($cat) > 10 ) Since most to the attempts have more than 10 characters in them, it works quite well.

Answer 4

A very good Question +1 from me and answer is not simple.
PHP does not provide way to maintain data for different pages and different sessions, so you can't limit access by IP address unless you store access details somewhere.
If you don't want to use a database connection for this, you can of course use the filesystem. I'm sure you already know how to do this, but you can see an example here:
DL's Script Archives
http://www.digi-dl.com/
(click on "HomeGrown PHP Scripts", then on "IP/networking", then
on "View Source" for the "IP Blocker with Time Limit" section)
The best option used to be "mod_throttle". Using that, you could restrict each IP address to one access per five seconds by adding this directive to your Apache config file:
<IfModule mod_throttle.c>
ThrottlePolicy Request 1 5
</IfModule>
But there's some bad news. The author of mod_throttle has abandoned the product:
"Snert's Apache modules currently CLOSED to the public
until further notice. Questions as to why or requests
for archives are ignored."
Another apache module, mod_limitipconn, is used more often nowadays. It doesn't let you make arbitrary restrictions (such as "no more than ten requests in each fifteen seconds"). All you can do is to limit each IP address to a certain number of concurrent connections. Many webmasters seem to be advocating that as a good way to fight bot spam, but it does seem less flexible than mod_throttle.
You need different versions of mod_limitipconn depending which version of Apache you're running:
mod_limitipconn.c - for Apache 1.3
http://dominia.org/djao/limitipconn.html
mod_limitipconn.c - Apache 2.0 port
http://dominia.org/djao/limitipconn2.html
Finally, if your Apache server is hosted on a Linux machine, there's a solution you can use which doesn't involve recompiling the kernel. Instead, it uses the "iptables" firewall rules. This method is rather elegant, and is flexible enough to impose constraints such as "no more than three connections from this IP in one minute". Here's how it's done:
Linux Noob forums - SSH Rate Limit per IP
http://www.linux-noob.com/forums/index.php?showtopic=1829
I realize that none of these options will be ideal, but they illustrate what is possible. Perhaps using a local database will end up being best after all? In any case, bear in mind that simply limiting the rate of requests, or limiting the bandwidth, doesn't solve the problem of bots. They may take longer, but they'll eventually drain just as many resources as they would if they were not slowed down. It's necessary to actually reject their HTTP requests, not simply delay them or spread them out.
Good luck in the escalating battle between content and spam!