WordPress XML-RPC Attack & Fake PHP5-FPM Error

We talked about blocking WordPress XML-RPC and preventing DDoS attacks on Cloud IaaS. Our crime was talking about blocking WordPress XML-RPC Attack via PHP-WordPress way. The script kiddies were running the exploit on a shared server, possibly enjoying the access to the database, we probably harmed their way of spamming. Their outburst of anger on our servers did more bad. We faked as if we are not understanding the attacks. We collected a list of IP addresses. All IPs and instances are of Amazon.

WordPress XML-RPC Attack : The Fake PHP5-FPM Error Part

A newbie will think the resulting problem as problem related to Nginx PHP5-FPM unix socket or some other stuffs. The errors are same.

These Attacks Can Bring DDoS Resulting in Random 502 PHP5-FPM Errors on Nginx Server or Can Make the Database Down. Here is Fix. But we need to tell you how to diagnose it. In the case of a shared server, non-key based virtual router-less web host, it is not difficult to hack the whole database.

Not all are using HP Cloud or IBM.
If we had not faked as “we are not aware”, we could not collect any data. In very short, unless you check the Nginx access log, Error log, MySQL log; unless the PHP5-FPM Error is arriving – it will be a typical Nginx-PHP5-FPM Error with a moron like a link towards Nginx’s website for checking the log. When you will try to flush the cache manually or access the admin area – you’ll face the white page of Nginx declaring an error. You’ll think that possibly you have the wrong configuration of PHP5-FPM or there is an issue with the resource. You can give a 16GB server to face and increase the PHP memory to 50% of it – it will die sooner, exactly like a 4GB server.

WordPress XML-RPC Attack : The Fake PHP5-FPM Error Part

For a normal Nginx-PHP5 setup on Deb GNU/Linux ( read Ubuntu server and Nginx from repo ), if we cd to /var/log/nginx and use awk to list the number of access against the HTTP code against the access.log file, in this way :

if I get this kind of result :

it simply points – 502 errors are most common on the server. 499 error code is for a POST from another server, take it as 502. A server is designed for serving pages with 200 HTTP code.

WordPress XML-RPC Attack : Log Analysis

It becomes easier to directly do a cat over the error file :

I will get some logs. The log will bear this kind of error, it is a variant not :

That 52.24.47.119 is sending POST request to thecustomizewindows.com/xmlrpc.phpin this way :

NORMALLY, none sends POST requests to others’ servers without prior permission. We send GET requests, not POST – if you are a new user to server administration.

SO, EVEN before getting 502, 499, 301 etc. errors, we can do a cat on access.log file :

we will get a huge log with this type of info :

there is no http://www.google.com/bot.html at present. Google has hugely informative pages on Google bot and IPs :

Google only sends bots from googlebot.com and google.com. If you run the top command during the attacks, there will be high CPU usage plus higher RAM usage. WordPress will tend to become slower, even if does not fail. As a screening test, if we run this command over the file /var/log/nginx/access.log :

we will get a numerical value. If it is, suppose 157, definitely the server is under attack – that is the number of unique IPs! We can run this command :

We will get the list of those (for example) 157 IPs. We can create a text file out of it and put it on GitHub for easy crawl by Google when someone will search for the IPs on Google search, see here – BlackListed IPs for running XML RPC attacks.

WordPress XML-RPC Attack : Solving the Issue

If you get the IP from the log it’s great, as we have :

As they are already known, we technically should use a firewall to block plus ban via Nginx. For Nginx, we can add a include directive in the way we described before how to use include directive, add one line on /etc/nginx/nginx.conf :

then create a knownhackers.conf file in /etc/nginx/ :

against the above IPs we will add content on knownhackers.conf like this :

then run a configtest with nginx -t and restart nginx with service nginx restart. We should also use some firewall to fully reject the IPs :

BUT, where is the promise that hackers will not use a different IP? That is why, on /etc/nginx/sites-available/default or equivalent vHost file, we will add this within the server { } block :

allow IPs are whitelisted and related to WordPress. We have not discovered them – we found on website named codepie.org. Then run a configtest with nginx -t and restart nginx with service nginx restart. If you are not liking to allow the WordPress related IP, simply use :

If the server has both port 443 and port 80, we would add the directive in both places to avoid a minimal chance of escaping 301 redirects from port 80 to port 443. Finally, we need to add some extra kinds of stuff on either Child Theme’s functions.php file or its replace plugin (about which we wrote here to avoid hundreds of snippets on Child Theme’s functions.php). The snippet we will add is :

Finally, disable pingback, trackback from the WordPress admin panel.

WordPress XML-RPC Attack : Check MySQL Log

The main reason for running the attack is usually to get backlinks. It is possible to push a bad post with other methods of hacking WordPress. Those IP related instances are a kid in front of bigger powerful servers. Probably we are too good for those who never deserve kindness. We should check the MySQL log for the last commands/queries ran on it :

If you see odd kinds of stuff (like the push of hyperlinks), you should find database related forum and terminate the pregnancy. ~/.mysql_history does not depend on your settings on my.cnf.

The IPs unless manually checked, can be victims as a part of Man in the Middle Attack.

Random PHP5-FPM Error is often misinterpreted as an error of configuration. For errors of configuration, your IP can trigger the error by just visiting a page or doing an action.

Finally, you should clear the log files using our described method, in this way :