And again the attack on Wordpress sites - brute force + XMLRPC
From Saturday noon on my server, where about 25 Wordpress sites are hosted, wild brakes started. Since I managed to survive the previous attacks ( attack 1 - exactly a year ago , attack 2 - in March ) not noticed, I did not immediately understand what was the matter.
When I figured it out, it turned out that passwords were being sorted out + multiple requests to XMLRPC.
As a result, we managed to cut it all off, although not immediately. There are three simple methods for avoiding this.
These techniques are most likely known to everyone, but I stepped on a pair of rakes, which I did not find in the descriptions - all of a sudden it will save someone time.
')
1. Stop brute force, Limit Login Attempts plugin - we put it exactly, since other protections heavily suspend the server, for example, when using the Login Security Solution plugin the server died after half an hour, the plugin loads the base heavily.
In the setup, be sure to enable the checkbox “For proxy” - otherwise it will determine for everyone the ip of your server and automatically block all.
UPDATE, thanks DarkByte , the details are lower in the comments - we ’ll enable the checkbox “For proxy” only if the definition doesn’t work when the “Direct connection” is on
2. Disable XML-RPC - Disable XML-RPC plugin (just activate it and that's it).
3. Close wp-login.php - if you access the site via ip, the plugin does not work and the pick-ups continue to hammer the site. To avoid this, in .htaccess add:
The wp-login file is copied, renamed to any strange name, for example poletnormalny.php and within the auto-replace file we change all the wp-login.php inscriptions to poletnormalny.php.
Everything, now the admin panel can be accessed only by your file.
After these 3 simple steps, the websites began to fly again and calm came.
One of the options is to see what attacks you. This can be seen in the nginx logs (for example, here is the path for Debian / var / log / nginx access.log file).
If there is a search, then you will see many lines of the form:
87.230.87.xx - - [04 / Aug / 2014: 06: 35: 53 +0400] “POST /wp-login.php HTTP / 1.0” 200 5791 "-" "-" "
XMLRPC Requests:
95.0.83.xx - - [04 / Aug / 2014: 06: 48: 03 +0400] "POST /xmlrpc.php HTTP / 1.0" 499 0 "-" "Mozilla / 4.0 (compatible: MSIE 7.0; Windows NT 6.0 ) "
When I figured it out, it turned out that passwords were being sorted out + multiple requests to XMLRPC.
As a result, we managed to cut it all off, although not immediately. There are three simple methods for avoiding this.
These techniques are most likely known to everyone, but I stepped on a pair of rakes, which I did not find in the descriptions - all of a sudden it will save someone time.
')
1. Stop brute force, Limit Login Attempts plugin - we put it exactly, since other protections heavily suspend the server, for example, when using the Login Security Solution plugin the server died after half an hour, the plugin loads the base heavily.
In the setup, be sure to enable the checkbox “For proxy” - otherwise it will determine for everyone the ip of your server and automatically block all.
UPDATE, thanks DarkByte , the details are lower in the comments - we ’ll enable the checkbox “For proxy” only if the definition doesn’t work when the “Direct connection” is on
2. Disable XML-RPC - Disable XML-RPC plugin (just activate it and that's it).
3. Close wp-login.php - if you access the site via ip, the plugin does not work and the pick-ups continue to hammer the site. To avoid this, in .htaccess add:
<Files wp-login.php> Order Deny,Allow Deny from all </Files> The wp-login file is copied, renamed to any strange name, for example poletnormalny.php and within the auto-replace file we change all the wp-login.php inscriptions to poletnormalny.php.
Everything, now the admin panel can be accessed only by your file.
After these 3 simple steps, the websites began to fly again and calm came.
Well, suddenly interesting
One of the options is to see what attacks you. This can be seen in the nginx logs (for example, here is the path for Debian / var / log / nginx access.log file).
If there is a search, then you will see many lines of the form:
87.230.87.xx - - [04 / Aug / 2014: 06: 35: 53 +0400] “POST /wp-login.php HTTP / 1.0” 200 5791 "-" "-" "
XMLRPC Requests:
95.0.83.xx - - [04 / Aug / 2014: 06: 48: 03 +0400] "POST /xmlrpc.php HTTP / 1.0" 499 0 "-" "Mozilla / 4.0 (compatible: MSIE 7.0; Windows NT 6.0 ) "
Source: https://habr.com/ru/post/232129/
All Articles