NinjaFirewall v1.2.3 vs Brute force attacks on the xmlrpc.php script
For the past weeks, we started to see hackers running small and discreet brute force attacks against the WordPress xmlrpc.php script (a.k.a XML-RPC API). Because that API can be used, for instance, by a user to create blog posts, it contains an authentication process quite similar to the admin login page which makes it very suitable for a brute force attack.
We have released today NinjaFirewall v1.2.3 and its brute force protection was extended to the XMLRPC script as well.
You can find it in the “NinjaFirewall > Login Protection” menu.
Although it will share the same configuration with the wp-login.php page, they won’t interfere with each other: if the protection is triggered for the XMLRPC script, it won’t affect the wp-login.php and vice versa.
1. If you don’t use/need the XML-RPC API:
You can enable the brute force protection from the “Login Protection” menu” and/or enable the “Firewall Policies > Block access to WordPress XML-RPC API” option.
Some blogs mention to simply delete the xmlrpc.php file, but this is a very bad idea: if the WP developers made changes to it, WP would re-install a new one during the next update and you would not be protected anymore.
2. If you use/need the XML-RPC API:
We recommend to enable the protection but to keep the banning period to a low value (e.g. 5mn) and to select “Yes, if under attack”. Avoid using “Always ON” otherwise any application you may use to access the API would need to authenticate itself with the user/password you selected or it would be denied.
- The topic ‘NinjaFirewall v1.2.3 vs Brute force attacks on the xmlrpc.php script’ is closed to new replies.