Question 1: Am I understanding correctly that this E-mail is triggered only when an Admin’s account is signed into from a distant IP? These E-mails are not being sent to non-Admin users, right?
Question 2: Is anyone else getting these from bizarre locations? I know the logins triggering the E-mails are me, but recently I’ve been located in distant locations I’ve never visited, especially not at the date and time given.
If I’ve understood Q1 correctly, then Q2 is not that big a deal. I’m a little more concerned only if any user might get such an E-mail, as we do have some who would panic.
If you have gotten these notifications and they are not from locations, and especially times, that you do not recognize, then you should, in fact, be very worried.
Correct this is admin-only, so we can make sure it’s working properly, also these are by far the most risky accounts to have compromised.
The question to ask, is why your IP address is geolocating to such a weird and/or incorrect area. What IP address was it? Did you at least recognize the operating system and browser reported, are those operating systems and browsers you regularly use?
I know these logins are me. Yes, I’ve asked myself those questions, and confirmed I logged in on the browser and device indicated at the time indicated. The location is what’s strange.
I’ve never been to Seattle, don’t think I’ve been to Newark, but definitely haven’t been there today.
No.
The Windows login in Seattle currently is 174.24.132.70, and I’m in North Carolina.
The Android login in New Jersey just 6 hours ago was 66.87.30.249, one mile from my current location.
So this is why I was wondering if it’s happening to other people. Surely I can’t be the only person whose IP addresses resolve to the ISPs’ regional office or corporate HQ?
Yep, there are no real geographical constraints for subnets. They’re allocated to providers and in a lot of cases the networks will only update their records once or twice a year.
On top of that mess, all of the IP lookup databases who compile that data are effectively best-effort.
There was a time that certain providers gave each customer a static address with lookup data that was too accurate. Of the two approaches I guess the former is preferable?
IIt hapened to me too, Weird places, mostly Africa. I just ignored it, didn’t know what to do. Now I don’t get these login emails anymore. But would still like to understand what was the problem.
The issue here is that we are in 2-3 month cadence for updating maxmind, and this data is going stale real fast, this is probably the second or third time this happened.
This issue does not exist in today’s maxmind db.
We do not want to be downloading 60mb from 200 or so containers every day, I will not be surprised if maxmind just burn our IP if we do this.
What we can do though is have some sort of middle ground here that forces an update in a slightly more aggressive cadence without risking getting our infrastructure IPs burnt or get a terrible reputation with maxmind.
My proposal would be:
Add site setting for refresh_maxmind_db_during_precompile_days default to say 2 days.
During assets:precompile if we did not download maxmind in refresh_maxmind_db_during_precompile_days then spin a thread to download maxmind and join on it prior to finishing assets:precompile
End result is that in our infrastructure maxmind will only be up to 2 days old, but we will need to deploy sites to update it.
Also for self hosters, rebuilds will always ensure maxmind is pretty fresh.
