What kind of protection at the web application level could be good enough if the requests reach the default php file? I guess none.
Renaming the php file could work, but then you’d have to do this every time wp is upgraded.
Adding basic authentication at the web server level (including .htaccess), could be a solution, unless those ‘blog api clients’ don’t support this extra authentication method.
IMHO, unless there is a blog api client that is open source, cross platform, actively developed and has a decent community behind it, totally forbidding access to that file at the web server level sounds like a wise idea.
George
Renaming the php file could work, but then you’d have to do this every time wp is upgraded.
Of course, this presupposes that the head section of the page wouldn’t have any reference to the actual file for the auto discovery of the new xmlrpc interface.
Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
It is my impression that WordPress core doesn’t prevent XMLRPC attacks is that it doesn’t happen to the majority of users. So it is considered plugin territory; https://wordpress.org/plugins/search.php?type=term&q=XMLRPC+attack
BTW, I just tested semagic (http://semagic.sourceforge.net/index.html) on windows and handling both the basic authentication by apache and the user authentication by wp was possible. So, I guess this double authentication concept works (but may depend on the client).
However, what is not going to work after protecting xml-rpc.php with basic authentication is pingbacks. So, you will have to see what is more important to you.
George
Well, the issue is: I have many WordPress sites running on my server, which I maintain. I have more than 100 POST/GET requests for this XMLRPC file for each site every single day. I do have Wordfence / login security plugins but they don’t seem to be doing much when the admin / password strings are empty.
The bots can’t go in but thats a HTTP request every minute possibly even more.
As a temporary solution I have disabled access to that file for the outside world via htaccess but I don’t think that is a permanent solution as this file is needed for blog clients or something?
Seriously, this has been on going for many years yet a permanent fix is to be found.
Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
I would recommend creating a thread on the Troubleshooting forum, as this feedback thread is being mixed into a support thread: https://wordpress.org/support/forum/how-to-and-troubleshooting#postform
