2

I read near the end of this guide regarding utilizing SSHguard to protect WordPress from Brute force attacks that after configuring SSHguard the relevant way, one must:

disable XML-RPC by blocking all remote access to /xmlrpc.php in your web server configuration.

  • I don't use XML-RPC in any of my websites.

  • I use Nginx as my web server.

I'm not sure what is the best way to totally block XML-RPC. Nginx conf for each site? WP-CLI operation per site?

What is the common way to do so?

Improve this question
6
  • 4
    Disabling XMLRPC is one of those security myths. Maybe in the days of WordPress 2.x, or in 2007, but those days are long gone. Sadly people keep parroting the issue. You'd get more out of an article on escaping output and adding esc_html etc to your themes and plugins
    – Tom J Nowell ♦
    Jan 23 '18 at 19:56
  • Escape output of themes and plugins with esc_html? Never heard of this before. If I understand correct, one should do that instead disabling XML-RPC, and than add the relevant conf to the Nginx global conf file, or specific site conf?
    – Arcticooling
    Jan 23 '18 at 20:00
  • 1
    Personally, unless I need XMLRPC, I'll always block it, simply because I don't care for the unnecessary load that comes with bypassing the cache to provide access to the API so bots can try their exploit scanners. Is XMLRPC secure? Possibly. Do you gain security by shrinking the attack surface? Absolutely. Slap a location with deny all; onto it if you don't need it.
    – janh
    Jan 23 '18 at 20:10
  • 2
    Don't bother with the XMLRPC rabbit hole, it's a problem that doesn't exist anymore, all you'll do is break functionality ( e.g. apps that integrate with WP, ifttt, Jetpack connections, etc ). There are plenty of things you can do to improve security, disabling XMLRPC is not one of them, and in the grand scheme of things was only popular because it was low hanging fruit
    – Tom J Nowell ♦
    Jan 23 '18 at 23:25
  • 2
    +1 If you do not use it, XML-RPC should just be disabled, it is a security risk, spam annoyance generator and the brute force attack on it is CPU heavy.
    – Mark Kaplun
    Jan 24 '18 at 4:54
4

On nginx, to block access to the xmlrpc.php file, add this location block to the server block of your configuration file:

location ~ ^/(xmlrpc\.php) {
  deny all;
}
Improve this answer
0

Here's a better way to handle it on NginX (and how my employer does it). This actually returns a "Forbidden" message.

location /xmlrpc.php { return 403; }

Anyone that says it's not a security risk is blithely unaware of the hacks that started happening with Wordpress 4.7.2 (It might be a 4.5x release), where there was an actual exploitable risk in Wordpress because of how xmlrpc.php requests were not properly being sanitized.

Realistically, the only time anyone should not disable access to xmlrpc.php is if they're using the Jetpack plugin from Wordpress.com.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.