Protecting xmlrpc.php

  • Resolved toby1kenobi

    (@toby1kenobi)


    10 years, 4 months ago

    Hi there,

    We’re running our website on a very small AWS instance, behind the pound proxy (which directs HTTP traffic to varnish, HTTPS straight to Apache). We had a problem with with a handful of IPs repeatedly POSTing to xmlrpc.php, causing the instance to run out of memory. For the moment this has been stopped by rejecting those IPs using iptables, although obviously this isn’t a particularly resilient form of defence.

    Can Wordfence (free or premium) do anything ‘smart’ in a case like this?

    Thanks,

    Toby

    https://ww.wp.xz.cn/plugins/wordfence/

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter toby1kenobi

    (@toby1kenobi)

    10 years, 4 months ago

    No?

    Plugin Author WFMattR

    (@wfmattr)

    10 years, 4 months ago

    Hi,

    Usually the POSTs on xmlrpc.php are malicious login attempts (assuming you don’t have real users using the xml-rpc interface), so you could decrease the “Lock out after how many login failures” option, so they are locked out faster.

    If you use Wordfence’s Falcon caching, on Performance Setup on the Wordfence menu, then IPs that are blocked within Wordfence will also be blocked using .htaccess for better performance during these attacks also.

    If Apache is running out of memory, you might also need to adjust Apache’s MaxClients to a lower number. The site may still respond slowly when under attack, but if the OOM killer doesn’t kick in, it could be more stable. (With a typical linux installation, mysql is usually the first process to get killed when memory is low, which generally makes the problem worse!)

    -Matt R

    Thread Starter toby1kenobi

    (@toby1kenobi)

    10 years, 4 months ago

    Ok, thanks Matt, I’ll have a look at your suggested changes.

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘Protecting xmlrpc.php’ is closed to new replies.

Tags