We've been having trouble recently with a DOS attack on our main website, which is run using Apache httpd 2.2.9 and Drupal 6.35. The attack is a post to Dupal's xmlrpc.php, which is a known exploit which has been patched in recent versions of Drupal. Because it's an older version, however, the fix for the exploit isn't in our Drupal installation – and won't be because we're migrating to a hosted platform within three months.
I initially tried to counteract the DOS by renaming xmlrpc.php, which returns a 404, but that's still enough to create an apache thread for each post The result is the multiple threads combined consume a lot of memory, so there's still a problem.
So, based on some more googling, I've just modified .htaccess with the following:
<Files "xmlrpc.php">
Order Allow,Deny
deny from all
</Files>
From here on, presumably, there will no longer be an httpd thread created for each call.
Is this sufficient, do you think? I could go one step further by enabling the capability to track traffic on the VPC and find and block the originating IP address/es, but I don't know if that will be effective, because thee attacks may be coming from a bunch of hijacked systems. Although I am curious to find out. Any thoughts?
Best Answer
A Deny block still requires apache to process the request far enough to see that it matches a deny, and is most likely equal in 'cost' as a 404.
You say 'DOS' but do you mean an actual attack or is it random scanners? Random scanners don't normally drive enough traffic to make 404's/403's for those a problem.
Is this behind an ELB? If not you should be able to see the source addresses in the access logs. You could look at implementing a tool like Fail2Ban to watch for this pattern and put in a temporary iptables rule to block access to that IP for a period of time.
If it is behind an ELB you could do something similar except write a custom shim to operate against the VPC subnet ACL's that contain the ELB.