Mobile app version of vmapp.org
Login or Join
Heady270

: WordPress: Many IPs issuing wp-login redirect + wp-login register + xmlrpc. Problem or not? My WordPress instance is hosted at my own domain and is installed in subdirectory xxxx (i.e. not in

@Heady270

Posted in: #WebCrawlers #Wordpress

My WordPress instance is hosted at my own domain and is installed in subdirectory xxxx (i.e. not in the root directory). 5 days ago I added a WP blog, and also started commenting in social media about the blog posts.

In 36 hours from noon 20 Dec to midnight 21/22 Dec (both UTC) I was visited from 85 separate IPs each issuing 5 identical requests, 2 of which always failed because the requested file was in subdirectory xxxx and not in the root directory as expected by the visitor. Although the IPs were distributed around the world, most were in the Buffalo area of the US.

Should I be worried about these visits? If not, should I try to be helpful and redirect the failing requests to the correct subdirectory?

The 5 requests issued by each visitor were:


GET / (successful)
GET /wp-login.php?redirect_to=/ (failed 404 because wp-login is in directory xxxx)
GET /wp-login.php?action=register (failed 404, as above)
GET / (successful)
POST /xxxx/xmlrpc.php (successful, but no $_POST data provided)


A sample set of Apache log records is listed below. All 85 visits had identical referer, UserAgent, Accept and Accept-Language EXCEPT that the UA for the POST contained different PHP version numbers, presumably matching each visitor's installed PHP version.

NB: Because of the stackexchange limit for new members of 2 links per post, I have changed the referer value within 3 of the records below to "referer as 1st log record".

192.3.124.131 - - [21/Dec/2015:13:04:10 +0000] "GET / HTTP/1.1" 200 44884 "http://www.example.com/" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
192.3.124.131 - - [21/Dec/2015:13:04:12 +0000] "GET /wp-login.php?redirect_to=/ HTTP/1.1" 404 336 "referer as 1st log record" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
192.3.124.131 - - [21/Dec/2015:13:04:15 +0000] "GET /wp-login.php?action=register HTTP/1.1" 404 336 "http://www.example.com/wp-login.php?redirect_to=/" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"
192.3.124.131 - - [21/Dec/2015:13:04:19 +0000] "GET / HTTP/1.1" 200 44886 "referer as 1st log record" "PHP/5.{3|2}.{1|2|3|4|5|6|7|8|9|0}{1|2|3|4|5|6|7|8|9|0}"
192.3.124.131 - - [21/Dec/2015:13:04:20 +0000] "POST /xxxx/xmlrpc.php HTTP/1.1" 200 370 "referer as 1st log record" "PHP/5.3.90"

10.01% popularity Vote Up Vote Down


Login to follow query

More posts by @Heady270

1 Comments

Sorted by latest first Latest Oldest Best

 

@Ogunnowo487

Unfortunately this behaviour is "normal". These bots are probably looking for "known" vulnerabilities in outdated WordPress installs and 3rd party plugins.

You can try manually blocking these IP addresses, but that is probably going to be a fruitless task as they could be forever changing - so will quickly become a maintenance nightmare.

You could automate the blocking of these IP addresses, by logging the IP addresses of such malformed requests and then blocking them (essentially a "honeypot"). You also need a system of quickly unblocking them if need be. Other methods to create a "honeypot" involve embedding a hidden link to a page that is blocked by robots.txt. Real users and good bots should never visit this page, but "bad" bots might - so block them! However, there is always the danger of false positives.

You can try blocking user-agents, but most of the time these "bad" bots aren't going to advertise themselves and are likely to pretend to be normal browsers - so they can't necessarily be blocked by this method.

Primarily you need to make sure your WordPress install and any "trusted" 3rd party plugins are kept bang up to date.

10% popularity Vote Up Vote Down


Back to top | Use Dark Theme