Preventing xlmrpc.php server-side?

[Arkaic]

Hi there,

We're seeing an increase on xmlrpc.php attacks recently which are flooding and overloading the server to the point it's consuming all resources and we're unable to even login without rebooting the server first.

Any advice on whether it's possible to block xmlrpc.php - completely - from the server side of things rather than going into each Wordpress? As there could be several hundred wordpress sites on a single server so modifying each wordpress install would not be feasible.

Alternatively, what can be done to prevent a single script or file from consuming so much resources that it overloads the server? I thought this is what PT_USERMEM kill in CSF would do but this doesn't seem to pick it up.

Any recommendations would be greatly appreciated.

 

[Dave Smith]

Hi Arkaic,
You could try adding the following to your httpd.conf

<FilesMatch "^(xmlrpc\.php)">
Order Deny,Allow
Deny from all
</FilesMatch>

 

[Arkaic]

Hi Dave,

This looks to have done the trick, thank you.

 

[24x7server]

Hello ,

Also you can add following mod_securoty rules on your server to prevent xmlrpc attack.

<FilesMatch "xmlrpc.php">
    SecRule RESPONSE_BODY "faultString" "id:19301,nolog,phase:4,\
        t:none,t:urlDecode,setvar:RESOURCE.xmlrpc_bf_counter=+1,\
        deprecatevar:RESOURCE.xmlrpc_bf_counter=1/300,pass"

    SecRule STREAM_INPUT_BODY "<methodCall>wp\." "id:19302,log,chain,\
        deny,status:406,phase:4,t:none,t:urlDecode,\
        msg:'Temporary block due to multiple XML-RPC method call failures'"

    SecRule RESOURCE:xmlrpc_bf_counter "@gt 4" "t:none,t:urlDecode,\
        t:removeWhitespace"
</FilesMatch>

 

[Dave Smith]

Hi Dave,

This looks to have done the trick, thank you.

No problem. Happy it helped.

 

[cPanelMichael]

Hello,

I'm happy to see the information provided to you helped. You may also find this thread helpful:

Modsec & Wordpress

Thank you.

 

[linux4me2]

We were having an issue with this as well, though not to the degree you describe. It sounds like you've resolved it, but I thought I'd pass along a couple of other options.

One is to add the Comodo WAF rules as a vendor in ModSecurity. It includes an XMLRPC rule, though it wasn't preventing all the attacks we were experiencing.

The other thing that seems to work very well is to add the following to an individual site's .htaccess:

<IfModule mod_rewrite.c>
    # Null route XMLRPC to disable it.
    RewriteRule ^xmlrpc.php$ "http://0.0.0.0/" [R=301,L]
</IfModule>

I haven't tried adding it globally, because I wanted to leave the option open for some sites to use the WordPress functions that require it, but you could probably add the above via Service Configuration -> Apache Configuration -> Include Editor -> Pre VirtualHost Include -> All Versions and have it work globally.

 

[dazeck]

Hi Arkaic,
You could try adding the following to your httpd.conf

<FilesMatch "^(xmlrpc\.php)">
Order Deny,Allow
Deny from all
</FilesMatch>

I'm still a bit new to this, but doesn't httpd.conf get rebuilt and this change would be removed.

Is it best to add to pre_main_global.conf or pre_virtualhost_global.conf or post_virtualhost_global.conf ?

Regards
Darren

 

[cPanelMichael]

Is it best to add to pre_main_global.conf or pre_virtualhost_global.conf or post_virtualhost_global.conf ?

Yes, you must add custom entries to those files or through the WHM options referenced in the post before yours to ensure modifications are preserved.

Thank you.