In WordPress 4.4 and later, system.multicall
XML-RPC callback is disabled since Sucuri had discovered brute force amplification attacks using this callback which can attempt thousands of authentification only by a single HTTP request. Thanks to the core team, we don’t need to worry about this type of attacks. But we still need to take care of the side issue of DoS attack that causes exhausting of our server resources.
XML-RPC system.multicall
Since the core team wants to make WordPress be compliant to the specification of XML-RPC, the core class processes all the methods in the system.multicall
.
For example, if 10 methods in system.multicall
require 10 times of authentication, and if the first one fails, the WordPress core class is smart to make all the subsequent methods fail, but still responds to the each request as follows:
This behavior is the same even if you use Disable XML-RPC plugin or add the following code into your functions.php
.
Definitely, we don’t need to be compliant against the attackers. So from this release, IP Location Block immidiately returns the status code when the authentication fails so as not to wastefully spend our server resources.
system.multicall
will be processed in order. But once the illegal authentication is fetched, this plugin counts up the “number of login fails” with the corresponded IP address. And if it reaches to the “Maximum number of login attempts“, then this plugin will block any requests to the back-end from that IP address. XML-RPC “Completely close”
Now you can select “Completely close” for XML-RPC at “Validation target settings” on “Settings” tab.
Same reason as the previous section, this feature will block more effectively than Disable XML-RPC plugin.
Benchmark
I updated the ApacheBench test script to measure load of brute force amplification attacks by XML-RPC sys.multicall
which includes one hundred pairs of username and password. The test environment is almost same as previous test but install Disable XML-RPC plugin (“DXR” in the following table) by way of comparison.
DXR | IGB | Requests/sec | Time/req [ms] |
---|---|---|---|
OFF | OFF | 5.64 | 177.395 |
ON | OFF | 5.67 | 176.217 |
OFF | Completely close | 6.63 | 150.784 |
OFF | Block by country | 6.84 | 146.269 |
The reason why “Block by country” is better than “Completely close” is that the former has less filter hook. Anyway, IP Location Block can cut a little less than 20% of the server load.
Changing the “Maximum number of login attempts”
You can also become to control the “Max number of failed login attempts per IP address” which was fixed as 5 by default in the previous version.
The smaller number you choose, the lower risk of breaking authentication you get.
Fallback at activation
This plugin needs write permission on /wp-content/
or /wp-content/plugins/ip-location-block/
where the class library “ip-geo-api
” is installed at activation phase. But some of the servers does not permit this by means of PHP safe mode or something similar policy mainly for the security reason. In this case, the previsous version fails to download the geo-location databases from MaxMind and IP2Location. But this was not good because some users need to grant permission manually.
This issue was reported at the support forum. (Thanks to hai3009. He made a great effort to identify the cause.)
So in this release, /wp-content/uploads/
where every WordPress has write permission will be adopted instead of /wp-content/
and /wp-content/plugins/ip-location-block/
if those were not writable.
There are potentially a few caveats against this fallback. One is Wordfence options “Disable Code Execution for Uploads directory” which is OK.
Another possible case is that whole /wp-content/uploads/
is mapped to CDN. If you have a trouble in such a case, please change the directory with filter hook and give it proper permission.
Graph of “Blocked per day”
In addition to the pie chart at “Blocked by countries” on “Statistics” tab, the Graph of “Blocked per day” for the last 30 days has been added.
Bug fix: Jetpack Bulk Actions
On the settings page of Jetpack, “Activation” and “Deactivation” by “Apply” button didn’t work because this plugin would block the request. Now this bug was fixed in this release.
Conclusion
Thanks to my users, the “Active Installs” is now 6000+. At every revision I released, I’ve dedicated to keep this plugin so simple enough to make you relaxed against to the attacks.
If you have something to say all about this plugin, please feel free to open your issue at support forum. At any time, I’m open to your suggestions.