0

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.

Zak
  • 354
  • 4
  • 17
  • 2
    So you've essentially reimplemented a limited version of [fail2ban](https://www.fail2ban.org/)? With the addition that you've given php the (indirect) ability to ban IPs which worsens exploit scenarios. – Ginnungagap Aug 10 '23 at 22:24
  • Not quite on the `php` end .. PHP just stores the CIDR in a database .. I have written a `bash` script run by a CRON job that enters the UFW rules .. So there is a handoff there. So what sort of issue do you see? A blanket statement *"worsens exploit scenarios"* -- Can you give me an example? – Zak Aug 10 '23 at 22:27
  • 1
    If php has the ability to write CIDRs that get banned to a database, php has the ability to ban IPs since all it needs to do is write to a database and boom, banned. Granted an attacker who exploits a vulnerability in WP would have to realise that but he could theoretically ban whoever he wants, including 0/0 amounting to a DOS. I'm not saying it's likely given there are for easier ways to wreck WP but I see no value in the way it currently works when fail2ban does this better by being out of band. – Ginnungagap Aug 11 '23 at 08:27
  • nitpicking: `chmod 0 ` will prevent the file to do much. If it works at all, that means the application reading it is running as root. About security... – A.B Aug 12 '23 at 07:20

0 Answers0