How to nuke attackers via httpd.conf?That can be accomplished using mod_access “Deny from <envar>” with mod_setenvif testing REQUEST_URI or by using mod_rewrite:
RewriteRule (awstats.pl¦xmlrpc.php¦includer.cgi¦hints.pl)$ - [F]
Of course, the problem is that you’ll still be wasting bandwidth sending your custom 403 error page to these idiots.A work-around (stay with me here) is to do the following:Create a new subdirectory below web root.Place a custom 403 error page in that subdirectory. Lets call it “403.html” for now. Leave out all the HEAD content, and just put a few characters in this file, so you can recognize it by filesize when fetched — I use just the text “No.”Now create an .htaccess file in that subdirectory that contains the following:
ErrorDocument 403 /path_to_this_subdirectory/403.html
Options +FollowSymLinks
RewriteEngine onRewriteRule !^403.html$ - [F]
Now, instead of the first code snippet I posted above, use the following in httpd.conf or in your web root .htaccess file:
RewriteRule (awstats.pl¦xmlrpc.php¦includer.cgi¦hints.pl)$
/path_to_subdirectory/$1 [L]
Now when a bad-bot attempts to fetch one of those files, it gets rewritten to the subdirectory. But no files in that subdirectory are allowed to be fetched except for 403.html. So, the 403 error handler is invoked, and returns only a 403-Forbidden server response header and the three-byte response from 403.html, thus minimizing your bandwidth loss.