Menu:

If you manage a public-facing Internet server, then you probably know that your server is constantly probed and attacked by rootkits floating around the Internet. Massively distributed botnets scan thousands of servers per second for vulnerable software. Having a cluster of public-facing Internet web servers, my servers see brute force ssh and web server attacks daily. And I am a tiny operation.

For ssh dictionary attacks, DenyHosts can be a big help. If you run a cluster of servers, you can boost the effectiveness of DenyHosts by distributing its block results across your entire server farm. Disabling remote root access (+sudo), and using keys rather than passwords are other good ways to boost remote ssh security.

For Web servers where customers are allowed to upload their own software — increasingly required in this age of dynamic Web content — vulnerabilities in poorly-written web code are a constant threat. Customers inevitably upload software that contains bugs, bugs which are then exploited to gain local access to your web server. Customers inevitably fail to maintain the software they upload, practically guaranteeing that security patches are missed. suexec and chroot jails definitely help, but even local access to a non-priveleged account can be a powerful tool to stage further attacks on other web servers.

However, I posit that a very simple technique can be enormously effective against rootkits: rename your files.

You can see attacks for common vulnerabilities if you grep through your web logs. Here is a sample probing attack:


209.172.10.41 - - [12/Jan/2007:05:02:18 +0000] "GET /a1b2c3d4e5f6g7h8i9/nonexistentfile.php HTTP/1.0" 404 302 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:18 +0000] "GET /adxmlrpc.php HTTP/1.0" 404 276 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:18 +0000] "GET /adserver/adxmlrpc.php HTTP/1.0" 404 285 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:18 +0000] "GET /phpAdsNew/adxmlrpc.php HTTP/1.0" 404 286 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:18 +0000] "GET /phpadsnew/adxmlrpc.php HTTP/1.0" 404 286 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:19 +0000] "GET /phpads/adxmlrpc.php HTTP/1.0" 404 283 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:19 +0000] "GET /Ads/adxmlrpc.php HTTP/1.0" 404 280 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:19 +0000] "GET /ads/adxmlrpc.php HTTP/1.0" 404 280 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:19 +0000] "GET /xmlrpc.php HTTP/1.0" 404 274 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:19 +0000] "GET /xmlrpc/xmlrpc.php HTTP/1.0" 404 281 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:19 +0000] "GET /xmlsrv/xmlrpc.php HTTP/1.0" 404 281 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:19 +0000] "GET /blog/xmlrpc.php HTTP/1.0" 404 279 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:20 +0000] "GET /drupal/xmlrpc.php HTTP/1.0" 404 281 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:20 +0000] "GET /community/xmlrpc.php HTTP/1.0" 404 284 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:20 +0000] "GET /blogs/xmlrpc.php HTTP/1.0" 404 280 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:20 +0000] "GET /blogs/xmlsrv/xmlrpc.php HTTP/1.0" 404 287 "-" "-"
209.172.10.41 - - [12/Jan/2007:05:02:20 +0000] "GET /blog/xmlsrv/xmlrpc.php HTTP/1.0" 404 286 "-" "-"

While there is no substitute for security by design, eliminating a highly common attack vector can measurably decrease your vulnerability. As you can see from the above sample log, a technique as simple as ensuring no file named xmlrpc.php exists will immediately render the above attacks ineffective.

Security purists love to complain about security through obscurity, but in today's Internet world of massively distributed botnets, it's a numbers game. You cannot rely solely on security by design, when you do not have complete control over the software uploaded by customers to your web servers. Bugs are inevitable in all software, in any case. Thus, any technique that can reduce a highly common attack vector is one worth looking at.

ISPs would be wise to consider banning the most commonly attacked software URLs, if you host so many web sites that you cannot possibly review all the code uploaded to your servers.