We currently host upwards of 300 wordpress sites/installations, and I am experimenting with beefing up WordPress security through some homemade efforts.
As an IT guy, I watch logs .. All the time, watching logs, and I noticed an inordinate amount of hits on xmprpc.php
-- So I thought, if we're not using it, and really given our niche nobody legitimately should be hitting the file, why disable it? Why not create a honey pot?
What I did, in the installation(s) I symlinked xmlrpc.php
to a php
file on the server backend. IE
ln -s /var/www/myScripts/honeyPot/xmlrpc.php /var/www/example_0.com/xmlrpc.php
ln -s /var/www/myScripts/honeyPot/xmlrpc.php /var/www/example_1.com/xmlrpc.php
ln -s /var/www/myScripts/honeyPot/xmlrpc.php /var/www/example_2.com/xmlrpc.php
I then made the file immutable to prevent tampering:
chmod 0 /var/www/myScripts/honeyPot/xmlrpc.php
chattr +i /var/www/myScripts/honeyPot/xmlrpc.php
My version of xmlrpc
simply collects various information via the _SERVER
_POST
_GET
and _SESSION
. It then proceeds to grab the CIDR
for that specific user's IP address via an API.
So for instance this IP 40.69.167.21
hit and the API came back with Microsoft Corporation | CIDR 40.64.0.0/13
My script then proceeds to store gathered info, and the offending CIDR
in a MySQL table, at which point a CRON script I've written inserts the rule into the UFW firewall.
ufw insert 1 deny from 40.64.0.0/13 to any
Because I am blocking entire IP blocks, over the past 2 weeks this has dramatically reduced web traffic and log entries. I have had no complaints thus far from clients and all seems well so far. Can anyone see any drawbacks of using a file that shouldn't be used on our setup anyway to trap these IPs as they come in?
Furthermore is this a viable solution for the 15 or so file names that we don't use, but get hit on a regular basis by bots looking to exploit?
This was mainly an experiment, but I think I may be onto something there.