Support » Plugin: Wordfence Security - Firewall & Malware Scan » Inaccurate IP detection accompanied by brute-force attack

  • 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 - 1 through 15 (of 38 total)
  • I’m seeing very similar behavior on one of my domains. All IPs are the same and an increase in login lockouts over the past few days.

    Thread I just made:
    https://wordpress.org/support/topic/wordfence-not-finding-correct-ips/

    Do you use SiteGround as a host? Just curious if we have any commonalities.

    • This reply was modified 1 year, 6 months ago by bracked.
    Thread Starter starsknight

    (@starsknight)

    Yes, my host is SiteGround.

    The cessation in blocked login attempts yesterday turned out to be brief. Last night, the login attempts have continued at a rate of about one every 30 minutes.

    Still registering the SiteGround IP for every access, and nothing else.

    I have a feeling this might be a SiteGround configuration issue. I’m going to contact them and see if they have any ideas.

    We are also on Siteground having the same issue. Please report back what you find out. Thanks.

    Plugin Author WFSupport

    (@wfsupport)

    We were just talking about this the other day. As I recall, it is a Siteground configuration issue and they have to do something on their side to address it. The users that have reached out to them no longer have the issue.

    tim

    Thanks Tim, It would be AWESOME if someone how has resolved this would post details from their Sitegrond ticket so the rest of us can contact them with the fix. Not all Siteground techs are as knowledgable, plus it would save a mess of time.

    If I work on this today I will certainly do that.

    • This reply was modified 1 year, 6 months ago by sdagency.
    Thread Starter starsknight

    (@starsknight)

    Thanks Tim,

    I’ll check in with Siteground and see if we can get this addressed. Will post anything further I learn here.

    Thanks @sdagency and @bracked for helping to confirm this appears to be a Siteground-specific issue.

    Sure @starsknight. Going on a couple hours of Siteground’s escalation team either saying it isn’t them (contrary to what @wfsupport wrote) or not responding to ticket updates which is unusual. They are usually great about service and quickly.

    They moved my client’s site to a new server and instructed him to go to GoDaddy and change domain settings. All that went well and was done correctly, but apparently Wordfence didn’t like something about the change.

    I will surely post any informative results from Siteground once I have them so people know specifically what to ask of them.

    @wfsupport @starsknight @bracked

    Reporting back so that anyone with Siteground may benefit.

    After 4-5 hours of on again / off again chats and tickets and escalations they blame a recent migration to their Google server and DNS propagation. I’m suspicious of that because it was one A record that was changed about 4 days ago at GoDaddy to point to Siteground’s new server. Never had a propagation last that long which leads me to wonder if it is a configuration issue.

    My recommendation if you are a Siteground customer who they forced onto a new Google server and experience this issue is to put in a ticket about this and specifically ask for it to be escalated. My hope is after my incident and “assertiveness” they have some documentation for their techs to either take care of the issue or advise you about the propagation. Dimitar Dimov
    is a Technical Support Supervisor there and when he gave me the final report back on the ticket somehow magically the problem was fixed.

    • This reply was modified 1 year, 6 months ago by sdagency.
    Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    Hristo from SiteGround here 🙂

    There is no such thing as SiteGround configuration issue. We have migrated (almost) all our servers to Google Cloud Platform. There is an IP redirect in place for those customers who haven’t updated their A records. We’re fixing those with NS records pointed to us.

    This is a regular redirect, triggering a false-positive error / warning on Wordfence’s plugin. Again, the brute force is another false-positive simply because ALL the traffic will be coming from the old server’s IP unless the A record is updated accordingly.

    @hristo-sg
    “There is an IP redirect in place for those customers who haven’t updated their A records.”

    Our client properly changed their A record 4 days ago. Don’t you think an A record would have already propagated? Why would SSL be working if it hadn’t? All the DNS checkers indicated it was done, your own techs said it all looked fine, but the IP issue continued.

    Was this a redirect somehow from your old server to the new Google one that was not removed in a timely fashion? Just trying to understand here and for the benefit of everyone else who runs across this warning in Wordfence.

    • This reply was modified 1 year, 6 months ago by sdagency.

    @hristo-sg “There is no such thing as SiteGround configuration issue.”

    This almost smacks of arrogance. All I know is my client’s website stopped working properly because of a change SiteGround made to their internal configuration. Sounds like a SiteGround configuration related issue to me.

    All I’d like is to fix the problem. What specifically do I need to do to solve this for a website and domain hosted with SiteGround? Is there a knowledge base article or a support forum/blog post you can point me to?

    • This reply was modified 1 year, 6 months ago by bracked.
    • This reply was modified 1 year, 6 months ago by bracked.
    • This reply was modified 1 year, 6 months ago by bracked.
    Hristo Pandjarov

    (@hristo-sg)

    SiteGround Representative

    If the A record is pointed to the new location the request should not even go through the redirect. This means that there is some very long DNS cache on WF side probably and second there is a false-positive brute force issue detected.

    Each incorrect login attempt is logged in from the same IP address (incorrectly) so BF protections are triggered (again incorrectly).

    @bracked wasn’t my intention, really. It is a regular straight-forward procedure that we’ve done multiple times on every migration from one dc to another or any other reason why an IP change is necessary.

    I would recommend simply disabling Wordfence for at least 48 hours and re-enable it. Hopefully, they will update their DNS records and stop going through the old server.

    @hristo-sg Thanks for the help. So if I am the one who manages my client’s DNS should I sign in and “update their DNS records”? If so what do I need to update them to? I haven’t received any information on this so far.

    I’m getting the same issue (also Siteground-hosted) and have temporarily disabled Wordfence and installed Loginizer in it’s place, and it’s still incorrectly identifying my IP. Would also like to know where in my Siteground dashboard I can find what to update the A record to for my website.

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