Preventing xlmrpc.php server-side?

Arkaic

• August 29, 2016 04:45

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

  • August 29, 2016 10:03

  Hi Arkaic, You could try adding the following to your httpd.conf
  Order Deny,Allow Deny from all
  

  0
• 

  Arkaic

  • August 29, 2016 10:33

  Hi Dave, This looks to have done the trick, thank you.

  0
• 

  24x7server

  • August 29, 2016 11:27

  Hello :), Also you can add following mod_securoty rules on your server to prevent xmlrpc attack.
  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 "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"
  

  0
• 

  Dave Smith

  • August 29, 2016 11:30

  Hi Dave, This looks to have done the trick, thank you.

  
  No problem. Happy it helped.

  0
• 

  cPanelMichael

  • August 29, 2016 20:58

  Hello, I'm happy to see the information provided to you helped. You may also find this thread helpful: Modsec & Wordpress Thank you.

  0
• 

  linux4me2

  • August 30, 2016 18:20

  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:
  # Null route XMLRPC to disable it. RewriteRule ^xmlrpc.php$ "http://0.0.0.0/" [R=301,L]
  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.

  0
• 

  dazeck

  • August 31, 2016 08:34

  Hi Arkaic, You could try adding the following to your httpd.conf
  Order Deny,Allow Deny from all
  

  
  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

  0
• 

  cPanelMichael

  • September 01, 2016 17:48

  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.

  0

Please sign in to leave a comment.