Multiple attempted logins originating from the server IP itself?

Question

I have recently migrated several sites to a new server using easyengine, which created a separate set of docker images for each WP website. Internally on my server, each of these sites gets a private IP (172.x.x.x) and externally of course domains are routed via dns to the external server named and served up normally. I noticed that a couple of my migrated sites are experiencing failed logins (shown in the activity log plugin) that have no referrer and seem to come from the private IP of the server itself. When I examine the logs I see entries like this at the exact time of failure:

172.19.0.1 - - [29/Oct/2021:10:20:27 +0000] "POST /wp-cron.php?doing_wp_cron=1635502827.4259769916534423828125 HTTP/1.1" 200 31 "https://mysitename.com/wp-cron.php?doing_wp_cron=1635502827.4259769916534423828125" "WordPress/5.8.1; https://mysitename.com"

Sometimes the logs show the same internal IP trying to POST to xmlrpc and a couple of other files.

Even though I have wordfence set up and it should block failed login attempts, it ignores these (I assume because they are local, private IPs) so they never get blocked. It does not yet appear that someone has been able to login, but this is very concerning and I can't track it down yet. Here are the things I notice and the questions I have about this activity:

• Could someone possibly spoof an internal IP from an outside request? This seems unlikely as it is only happening on the two sites that came from the same old server, the other sites still seem unaffected.
• I have combed through all of the files and can't find any malicious code. And I have completely reinstalled WP on one of them and exported and reimported using the WP importer (instead of directly copying the db), but still have these attempts
• I can't find any reference to a hack like this, does anyone have any idea how it could be tracked down?
• So far, none of these attempts has guessed an existing username, and they have all failed to login

Thanks!

Answer 1

Well it took a while, but I figured out what was happening here, and the upshot is: no good deed goes unpunished.

• When setting up my server, I enabled IPv6 because I want to be a good internet citizen and help our collective migration to IPv6
• I chose easyengine to manage my WP sites, which uses nicely isolated docker containers for each web site
• Easyengine sets up an nginx reverse proxy container that passes off all requests to the appropriate site/container
• The problem with the reverse proxy setup is that if the originating request is from an IPv6 address, the proxy will change that address to a local IPv4 IP before passing it along to the container website.

What this means is that any wordpress hacker sending commands, bad login attempts, what have you from an IPv6 address will not be blocked by any security software (such as wordfence) because it sees a LOCAL IP AND THEREFORE WILL NOT BLOCK IT

And enabling IPv6 support on the ee docker containers is far from straightforward, I have not been able to do it yet. So for now anyway I have disabled IPv6 on the server to stop these attacks. I will come back here with more info when/if I find a simple(ish) way to enable IPv6 reverse proxy on docker containers running on easyengine.

I should note here that as a test, I set up a small server using a single apache site and no proxy and everything read and worked as expected with IPv6 addressing and blocking. But I have to manage several sites and I really like easyengine's management tools and docker isolation (in theory), so that was why I made that choice. Hope all this helps someone else.