• Resolved starsknight

    (@starsknight)


    Hi there,

    Over the past few days, I’ve gotten an increasing number of “User locked out from signing in” messages, all with the same IP address. But when I went to block it, I realized that WordFence identified it as my IP address. It’s not my IP address. I tried accessing from another IP address, and again, WordFence recorded it as the same incorrect IP address. (In case it is helpful, the IP address WordFence is consistently identifying is 173.236.11.190.)

    I tried changing the IP detection method, but no option yields any other result. Every time, it identifies my IP address as the 173 one.

    WordFence says it blocked over 25,000 brute-force attacks today, all from this same IP. I don’t know whether this was a real attack, or whether it’s a glitch in the plugin. Stopped seeing new login attempts after I changed the IP detection method a couple times, but it’s now right back where it started (REMOTE_ADDR). Don’t know if the cessation of activity was related, or a coincidence.

    Final (possibly relevant) bit of information: While WordFence was misidentifying my IP as of yesterday, it wasn’t until today that I got an error message from it that was unable to accurately detect IPs. After I switched IP detection methods around, the alert disappeared . . . despite the fact that the detection method is right back where it started.

    I’ve perused the forums and help pages, but haven’t been able to find anything that’s helped in this particular situation. I’d appreciate any advice you can offer.

    Thanks in advance for your time and help!

Viewing 15 replies - 16 through 30 (of 38 total)
  • Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    @bracked If you’re having such issue it means that your domain is pointed to our server IP via A record and not through NS records. You need to update that IP to the new one. Account owner should have received email with the new IP address and migration data a week before it has happened.

    @wp510 are you sure your domain is registered with us? Please, contact our team via a ticket in the Help Desk if so.

    @starsknight my limited understanding is Siteground has some sort of redirect from old server to new in case owners are slow to get domain records changed. It sounds like during that time a flood of traffic could come from the old server location to the new and appear as a brute force attack. I’m piecing that together from Siteground’s updates.

    @hristo-sg you recommend disabling Wordfence 48 hours, but as I stated before, this client had the A record properly changes for 4 DAYS!

    @wfsupport can you speak to whether that is indeed a WordFence long caching issue? I kind of doubt it because I removed and reinstalled Wordfence and the problem persisted. Until I pressed SiteGround’s escalation team and then it magically went away.

    • This reply was modified 4 years, 8 months ago by sagency.
    Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    @sdagency you are highjacking 4 different threads, I can’t say what is wrong in your case, I am replying to the thread author. Please, give me your domain name so I can look into it too.

    @wp510 very insightful a different IP analyzer had the same issue. We had our A record changed for 4 days and even removed and reinstalled Wordfence and had the issue until we persisted with the Siteground escalation team. Then *poof* the error went away.

    Still find it interesting the Wordfence plugin author says other people contacted Siteground and the problem went away. For me it was hours of chats and tickets. Hoping this trail of info will help Wordfence users and Siteground. Gotta be a way to improve this situation. Siteground is a great host.

    • This reply was modified 4 years, 8 months ago by sagency.
    Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    @sdagency maybe they are deleting Wordfence’s rules blocking traffic from the old server IP making the site poof live again…

    I am telling you the facts and what is causing this. I am afraid, there is nothing on SiteGround’s side that can prevent this from happening. It is just a false-positive blocking the server forwarding all the traffic. Afterwards, probably the plugin fails to clear its block rules because it has blocked itself from working.

    @hristo-sg Thanks. I’ll investigate further and create a support ticket if necessary for any further questions.

    Well, I switched the nameservers over to SG in the DNS (was originally set with just the A record pointing to SG), applied an SSL certificate and reinstalled WF and that seems to have partially fixed the issue for my site (it’s at least correctly identifying *my* IP)…

    Thread Starter starsknight

    (@starsknight)

    Thanks, all, for the info. This is very helpful.

    @hristo-sg, we’re switching over management of the site, so I didn’t receive that email, thus hadn’t changed the A record. Now that I know, I’ll update the DNS settings and hope that fixes the issue. Will reply back here if there are any further problems.

    As for the 25,000 administrative login attempts in a single day, though, that still looks like a brute-force access attack to me, albeit an unsophisticated one. We haven’t seen anywhere near that volume before or since, despite IP identification still being an issue. So I see no reason to think that was a false positive, despite the fact that there were likely a number of different IPs involved.

    Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    A brute force attack is possible and might be happening indeed. The problem here is that it originates from the proxying old server and WF blocks it so the entire traffic is blocked shutting the site down practically.

    Thread Starter starsknight

    (@starsknight)

    Hey @hristo-sg

    To be clear, no one is having trouble viewing/navigating our website. The only thing WF is blocking is access to the administrative login page, and since they provide an alternative method for a legit admin to log in, the only problem in practical terms is that this costs us a little extra time.

    I want IP detection working for a variety of reasons, but this “the entire traffic is blocked shutting the site down practically” idea is not in fact what’s happening, and overstates the severity of the problem by a couple degrees of magnitude.

    I’m stating this here so if someone with a similar problem encounters this thread, they don’t freak out and assume their site is inaccessible. ??

    Thanks for helping out @hristo-sg, however we heard through other customers that it’s caused by a migration to new servers, and the site’s DNS records needed to be updated to point to the new server. If a user registered their domains somewhere other than SiteGround, they would need to change their own DNS records. SiteGround support can give them the new IP for their domains to change it to. If the DNS records are not updated yet, they’re going through a proxy at SiteGround that doesn’t pass the original IP through, which would cause all IPs to be the same.

    For the record, Wordfence doesn’t cache anything. Saying that we do is just silly. We’re just reporting the IPs of visitors that come to the site. Perhaps looking at the access logs of a site that is having the issue might be helpful to illustrate what is going on.

    Lastly, asking someone to disable their security just so you don’t have to properly show or pass through the actual IP of the visitor through the redirect sounds a little reckless, wouldn’t you agree?

    Tim

    @wfsupport

    And like we said before, we DID change the A record correctly to Siteground specifications (verified by Siteground) and after 4 days the IP detection was still off. Still think it’s highly unlikely that it wasn’t fully propagated.

    We removed and reinstalled Wordfence, same problem. Another user here tried a different plugin and it STILL indicated IP detection issues.

    Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    @wfsupport I mentioned DNS cache which is not really stupid if you think about it. Not sure how you apply rules here. Plus, @sdagency mentioned numerous times that they’ve had switched the IP over to the new server. I get it that you don’t have meaningful access to your customers and you can easily block the plugin out in such cases.

    We protect our customers with a WP speciffic WAF and an Antibot AI that scans for brute force attacks and much more so disabling WF for couple of days isn’t really reckless.

    Last but not least, when you migrate thousands of servers and entire host nodes you can’t affort to slow down those redirects so they are done on the lowest possible level which does not allow us to pass any additional headers along the way.

    Again, I understand that there’s nothing wrong with the way your plugin works but actually tracerouting a request to the domain and trobleshooting it would be much better than blaming a “Siteground configuration issue”.

    We’re almost done with the migration and such issues will be over in the upcoming weeks. If you have some real configuration issues – please email me directly at [email protected] I will open test accounts for you and we can discuss how to make WF run without having to do speciffic configurations on our and and generally make it a better experience for everyone.

    @hristo-sg I never said “stupid”, did I?

    when you migrate thousands of servers and entire host nodes you can’t affort to slow down those redirects so they are done on the lowest possible level which does not allow us to pass any additional headers along the way.

    That is the problem. You aren’t passing the correct IP of the visitor. Stop beating around the bush and trying to push the blame elsewhere since that is the problem. It’s not Wordfence caching the DNS records as you said before. You aren’t passing the correct IP address.

    I understand that there’s nothing wrong with the way your plugin works but actually tracerouting a request to the domain and troubleshooting it would be much better than blaming a “Siteground configuration issue”.” (wfs edit spelling corrected)

    It is a SiteGround issue if your server is not sending the data through, regardless of the reason why you aren’t. Wordfence is doing its job as it is supposed to.

    I appreciate your confidence in your company’s ability to protect its customers. You are usually one of the recommendations I give to people who ask about a good hosting company to use. However, leaving a site unguarded is reckless. It is dangerous. We’ve cleaned enough sites from hosting companies that swear ‘nothing will get past our security’ to want to err on the side of caution.

    Since you are taking this discussion offline I am marking the post resolved.

    Tim

Viewing 15 replies - 16 through 30 (of 38 total)
  • The topic ‘Inaccurate IP detection accompanied by brute-force attack’ is closed to new replies.