Wordpress robot scans, several sites at same time
I'm having problems with Wordpress sites. Some scanning system accesses dozens of Wordpress sites at the same time, using 100% of the server's CPU. Even limiting to 1 or 2 PHP-FPM instances per site, since the scan occurs on dozens of sites at the same time, it ends up overprocessing the server.
Any idea on how to detect and prevent these scans, or directly in Apache?
Scans looks like (404 runs WP homepage):
20.191.203.128 - - [26/Aug/2024:11:00:02 -0300] "GET /bak.php HTTP/1.1" 301 - "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:03 -0300] "GET /wp.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:04 -0300] "GET /bak.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:05 -0300] "GET /wp-conflg.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:06 -0300] "GET /content.php HTTP/1.1" 301 - "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:07 -0300] "GET /content.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:07 -0300] "GET /bypass.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:08 -0300] "GET /404.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:08 -0300] "GET /upfile.php HTTP/1.1" 301 - "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:09 -0300] "GET /upfile.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:11 -0300] "GET /wp.php HTTP/1.1" 301 - "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:10 -0300] "GET /updates.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:13 -0300] "GET /wp.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:13 -0300] "GET /radio.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:14 -0300] "GET /wp-conflg.php HTTP/1.1" 301 - "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:16 -0300] "GET /xmrlpc.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:16 -0300] "GET /wp-conflg.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:18 -0300] "GET /ae.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:19 -0300] "GET /bypass.php HTTP/1.1" 301 - "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:20 -0300] "GET /moon.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:20 -0300] "GET /bypass.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:21 -0300] "GET /blog.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:22 -0300] "GET /404.php HTTP/1.1" 301 - "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:22 -0300] "GET /themes.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:22 -0300] "GET /404.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:23 -0300] "GET /ini.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:23 -0300] "GET /updates.php HTTP/1.1" 301 - "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:24 -0300] "GET /updates.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:24 -0300] "GET /as.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:25 -0300] "GET /radio.php HTTP/1.1" 301 - "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:25 -0300] "GET /shell.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:25 -0300] "GET /radio.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:26 -0300] "GET /ws.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:26 -0300] "GET /xmrlpc.php HTTP/1.1" 301 - "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:27 -0300] "GET /dropdown.php HTTP/1.1" 404 25340 "-" "-"
20.191.203.128 - - [26/Aug/2024:11:00:28 -0300] "GET /xmrlpc.php HTTP/1.1" 404 25340 "-" "-"
-
Hey there! Are the scans always from that same IP that you included in that log snippet? If so, I'd just block that IP address at the firewall and then they wouldn't be able to connect to the server at all.
You can also block access and only allow it from specific IPs using the details here:
https://support.cpanel.net/hc/en-us/articles/360060606074-How-to-disable-xmlrpc-php-via-htaccess
0 -
Hi @cPRex,
no, that's the problem. Each attack is from a different IP/range/country.
I already have protection against /wp-login and /xmlrpc, using Apache basic authentication, which works fine.
My current problem is: the attacker knows the WP sites hosted on the server and checks all of them at the same time, even though each one has a limitation of two PHP-FPM threads. But 20 sites means 40 PHP threads at the same time.
For example, from "top":
user1 55.9 0.2 0:00.74 php-fpm: pool website1_com
user1 65.9 0.2 0:00.74 php-fpm: pool website1_com
user2 77.9 0.2 0:00.74 php-fpm: pool website2_com
user2 81.9 0.2 0:00.74 php-fpm: pool website2_com
...
user20 69.9 0.2 0:00.74 php-fpm: pool website20_com
user20 71.9 0.2 0:00.74 php-fpm: pool website20_comAs you can see, most of the requests return "404", but this triggers the WP home page (redirect).
0 -
If all these requests don't have a user agent, what about just blocking those specific types? Details on how you could do that can be found here:
https://stackoverflow.com/questions/65497495/apache-2-4-block-requests-without-user-agent
0 -
In this case, the user agent came empty, but in other cases, it comes with a real user agent (e.g. Mozilla) or with Python headers... so unfortunately it doesn't solve the problem, especially since, to implement this, it would have to be done per account.
I'm trying to find a solution at the server level, not for each account individually. I'm really having trouble trying to find a way around this. At the moment, I've created a script that runs every minute and, if the CPU is much higher than average, it tries to find out which IP is intensively accessing the ports 80/443 via "netstat" and blocks it, which is not a long-term or secure solution.
0 -
Gotcha - I was hoping the user agent idea would catch them all.
I really don't have a good solution for this type of issue besides blocking the IP address, as the trick here is to differentiate these accesses from normal traffic.
1 -
Yes, I know it's complicated. Thanks anyway!
0 -
I'm sorry I don't have more I can offer on the cPanel side of things for this one!
1
Please sign in to leave a comment.
Comments
7 comments