Esmi – right, so if you just look through them you can search for xmlrpc and if lots of stuff comes up in a certain time period that implies a lot of hits?
Pretty much, yes – although when these bots are active, I don’t have to “look” very much. They’re hitting the site about every 5 seconds or less, so there are tons of them in the last 1,000 log entries.
The FILES directive only tells your server to issue a 403 “Forbidden” response to any attempt to connect to that specific file. And I believe you need to put quote marks around the file name (although that may be optional if you’re not getting an Error 500).
You need to block the IP addresses of the Web servers that are trying to reach out to your XMLRPC.PHP file. But blocking individual IP addresses is inefficient.
You want to block groups of IP addresses as they are assigned to Web hosts. You can use this tool (Cf. http://bgp.he.net/) to do the lookups. Your deny list will look like:
Deny from aaa.bbb.ccc.ddd/nn
Deny from eee.fff.ggg.hhh/nn
You should also look for IP addresses that are trying to access wp-login.php as no legitimate user would do that unless you require them to login to leave comments.
You want to block groups of IP addresses as they are assigned to Web hosts.
I’m blocking via IP blocks atm but long term,. I still don’t see this as sustainable.
You should also look for IP addresses that are trying to access wp-login.php
I’m not getting anything worth noting accessing wp-login.php myself but then I’ve got wp-admin locked down by IP.
They’ll probe for different things on different Websites. There is no rhyme or reason in the probing. On my server I have several WordPress installations next to static HTML Websites. Some of the static sites are hit with probes for “index.php”, “wp-login.php”, and “xmlrpc.php”. Nearly all of the sites have been probed for “phpMyAdmin” at one time or another.
They do tend to congregate on some sites more than others so I believe there is a reporting mechanism built in to these scripts so that they tell one or more command servers which sites have which files. I have noticed they may come in with 1 or 2 probes on one day and then about two weeks later I see thousands of hits from the previously used IP addresses.
The sites that are hit the most are my most popular sites. They have the most content, the most inbound links, and the most real visitor traffic.
Just wanted to add another two cents to the convo. 5 days later and we’re still cruising, everything is nice and fast. I’m going to keep monitoring it, but man, blocking this xmlrpc thing was a godsend, no IP addresses needed. I would hope WP can make this standard in some way!
xmlrpc.php is the filed used for pingbacks and trackbacks. Blocking access to it means your blog won’t receive notifications from other blogs.
xmlrpc.php is also required if you use JetPack, or any of the iOS WordPress apps. There are some other plugins and tools that use that file as well. (Things like auto posting from Diigo/Delicious, and IFTTT, for example) Flat blocking it limits your own ability to interact with your site. It’s unfortunate, I’ve been struggling with the same issue, blocking by IP still generates a ton of 403 messages, which is dragging my site’s response time. MY host’s suggestion was to route all requests for xmlrpc.php to 0.0.0.0, but that breaks all the other functionality that I just mentioned.
I use Jetpack but I only need it to activate the statistics (so far). Jetpack seems to be able to get along without it after that but you raise a good point.
Clearly the script is included in the distribution because it is useful.
If you use iptables then you can/should DROP requests coming from the compromised servers. That gets rid of the 403 errors.
But no matter what you do you’ll have to constantly update your list of moderated IP addresses and the problem when only get worse when all servers are configured to only work with IPv6 addresses.
Very interesting, but it sounds like the average user doesn’t really need it. I’d think WP would find a way to rename it or something to drive away these spammers -might be a little work requiring changes to some of those apps, but still.
Anyway, it’s been two weeks and we’re still cruising with a simple htaccess block. I’m happy for now!
I modified htaccess to block access to xmlrpc.php as mentioned earlier. When I then looked at apache error log, all the ips (there were many) seem to belong to Google Cloud. Any ideas what that means? I don’t want to restrict google from accessing the site.
From what I can gather, Google Cloud ips are distinct from googlebot ips, so I *believe* there’s no cause for concern, but I’m still curious.
