jrivett

Wow. I’ve had some bad support experiences, but that’s just terrible. I mean, especially given the potential seriousness of the problem from their perspective. It seems like they’re probably in transition from Albacom to BT Italy, so maybe things are a bit chaotic, but it’s still no excuse. Did you talk to BT or Albacom?

I’ve reported this to SANS. I’m also continuing to try reporting to the Albacom (BT Italy) abuse email.

Meanwhile, the attacks continue unabated. If nothing changes soon, I plan to block all IP ranges originating in Italy at my router.

253david, these all give me login screens:
78.5.68.234
78.4.210.202
78.5.41.50
I’m starting to think these devices are the problem. I was able to log into one using a rather obvious username/password. Presumably I’m not the first person to learn this, and they may all be compromised.

These IP addresses could be spoofed, but as far as I know, that would make the login attempts only useful as a way to generate traffic. I can’t see how the ‘attacker’ could obtain any useful information, since any information returning from the site would not go to the actual attacking system. Or, you know, I may be wrong.

I pointed my web browser at a few of these IPs, and was rather alarmed to be (for all IPS I tested) presented with the login screen for a particular network device: the Aethra BG1242W. It’s generally not a good idea for the admin interface of Internet-connected devices to be accessible from the Internet. Is this evidence of ISP incompetence?

I can’t determine whether the login traffic is coming from the Aethra network devices or – more likely – from devices connected to the LAN side of these devices. Either way, these IPs appear to be associated with systems that have been compromised and are being used as zombies in attacks against my (and presumably other) web sites.

The BG1242W may have a known vulnerability that is being used by the attackers. In any case, I’ve heard nothing at all from Albacom or BT Italy.

I’m seeing this as well, but only on one particular WordPress site (out of several I manage). It started over a week ago. I get between nine and twelve admin login attempts every four hours, always from different IP addresses, but all from static.albacom.net and fastwebnet.it.

I tried to report the attacks from Albacom to [email protected], but their inbox was full. I reported to [email protected] as well, but so far no reply.

I have Wordfence configured to immediately lock out attempts to log in as ‘admin’ and keep them locked out for 60 days, but since the attacks rarely seem to use an IP more than once, this doesn’t do much to stem the flow.

I understand that Wordfence is doing its job, so I’m not concerned about potential damage to my site. But something funny is clearly going on in Italy, and someone needs to know about it so they can fix it.

Additional testing shows that Wordfence behaves the same regardless of whether the additional security plugins are enabled.

Wordfence doesn’t seem to notice or care about automated attacks that repeatedly issue POSTs for wp-login.php, and although it does log attempts to log in with blank passwords, it does not count them as failed login attempts and never blocks the IPs from which they are issued. Presumably these things are by design, so I’ll adjust my expectations accordingly.

Further testing shows some interesting things:

[1] Wordfence doesn’t seem to notice, log, show or block traffic that consists only of repeated requests like these:
/wp-login.php?action=lostpassword
/wp-login.php?action=register
/wp-login.php
I’m not sure what the attacker is trying to accomplish by sending these requests – several times per second – for long periods. But regardless, Wordfence doesn’t seem to care about them.

[2] Wordfence also doesn’t seem to care about login attempts where no password is specified. I tried repeatedly to log in with a valid username and a blank password, and Wordfence again didn’t seem to notice, log, show or block this traffic. But as soon as I started trying to log in with a valid username with a non-blank but incorrect password, Wordfence’s login security settings kicked in and blocked the IP I was testing from.

Are these behaviours intentional in Wordfence? If so, then I guess the problem is that I failed to understand what Wordfence was supposed to be doing. If not, then again I may be dealing with an incompatibility with another plugin. I’ll repeat the tests with those plugins disabled and report back here.

Another wp-login.php based attack this morning, and again Wordfence seems oblivious. Nothing in the Live Traffic view, and no login blocking was triggered. Eventually the IP was blocked via the Wordfence network. I checked the IP and found nothing special about it; for example, it’s not a crawler like MJ12bot.

So I’m still trying to figure this out. It’s looking increasingly like an incompatibility with one of my other security plugins. Testing continues…

This problem seems to have mysteriously resolved itself. I have no idea how that happened. I will continue to monitor things and I learn anything I’ll post it here.

On the Wordfence IP Blocking page:

IPs that are blocked from accessing the site
– currently all I see here are IPs I’ve blocked manually
– yesterday there was also a ten minute block that happened because of information from the Wordfence network

IPs that are Locked Out from Login
– one entry from two months ago
– there was a second one that expired yesterday

IPs who were recently throttled for accessing the site too frequently
– one entry from over a year ago

Some kinds of blocking are working: manual blocks, and blocks based on the Wordfence network. But the login lockouts seem to have stopped working at some point in the last two months.

Is there some way to put Wordfence into a diagnostic mode, so I can see what it’s doing?

Two questions.

1. When you say ‘while on that page’, to which page are you referring? The Wordfence live traffic monitor? The Wordfence IP blocks page?

2. Are you sure you meant Java? I wasn’t aware that Wordfence uses Java. I’m pretty sure it uses Javascript, however. Maybe you wanted me to look at the Javascript console? I did enable the Java console, and I did watch it while working with Wordfence, but saw nothing at all. On the other hand, when I run a Java application, the Java console is full of stuff.

I saw that post as well, which was what allowed me to recognize when Wordfence is actually blocking an IP. I watch my access log constantly now, and I can definitely see when Wordfence is blocking.

However, while the ‘Blocked by Wordfence Security Network’ blocking is working as expected (the block appears in the relevant tab, and the access log shows evidence of the blocking), the blocking based on the login/forgotpassword security settings is apparently not working at all, based on the fact that even when I see a lot of login attempts, the attacking IP never appears in the Wordfence IP block lists, and I see no evidence of blocking in the access log.

I just updated the site in question to Wordfence 5.2.7, so I’ll watch things and post any new information here.

My question about the ‘Blocked by Wordfence Security Network’ blocking was actually just asking to confirm that that type of blocking is distinct from the login security blocking that Wordfence applies when it detects rapid login/forgotpassword attempts.

As for the original problem: although I mentioned the lack of alert emails, that is not the issue. Watching the access log shows attacks happening, but looking at the Wordfence ‘Blocked IPs/IPs that are locked out from login’ tab shows that Wordfence isn’t blocking them. The related settings are all set to the defaults.

I tried disabling New User Approve, Registration Honeypot, and one other security-related plugin, Stop Spammer Registrations. It made no difference.

While I was watching the access log, another IP address started hitting the wp-login URL several times per second. Then I noticed that IP’s requests suddenly became intermingled with responses from 69.46.36.10, which I’ve noticed in the past happens when Wordfence blocks an IP. Checking Wordfence, I saw that the IP address was shown as blocked in ‘IPs that are blocked from accessing the site’, with the reason being ‘Blocked by Wordfence Security Network’. But that’s separate from the automatic login blocking that should be occurring and isn’t, right?

Thanks for the offer, Mika, but like I said, the original problem was actually unrelated to performance, and it has since been resolved in any case. However, I’ll keep all this in mind if and when I encounter performance issues on any of my Dreamhost-hosted WordPress/Wordfence sites.