Principles of Determining Geolocation
02 February 2015
In 2004-2005, I worked for Quova as a Network Geography Analyst.
As a practical matter, given that MLB was one of our largest customers at the time, this meant that we fielded complaints for people who were locked out of viewing baseball games where they should not have been, and a good chunk of my job was investigating those complaints.
This is intended for a mixed-level audience, so I’m going to skip deep nuance and detail. ## Simple Explanation
- When you connect to the internet, whether through cable, your cell phone, whatever, you’re assigned an IP address, where IP stands for Internet Protocol. At the point in time you connect, your IP address has a fixed location in physical space: wherever you happen to be.
- Your device connects to another, upstream device, and depending upon where you want to go, it connects to a series of other devices until it arrives at your intended destination (say, Google’s web server). Each of those devices has an IP address, and each of those IP addresses has a fixed location in physical space.
-
If you ask for a traceroute from a command line, it’ll tell you what series of hops it goes through to get from point A (you) to point B (where you want to go).
$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets- 10.0.1.1 (10.0.1.1) 10.938 ms 1.183 ms 1.032 ms
- 198.144.195.185 (198.144.195.185) 51.874 ms 52.194 ms 51.948 ms
- ge1-8.rawbw-demarc.sfo4.reliablehosting.com (216.131.94.209) 61.865 ms 57.246 ms 64.077 ms
- core2-1-1-0.pao.net.google.com (198.32.176.31) 52.671 ms 51.958 ms 55.120 ms
- 64.233.175.169 (64.233.175.169) 56.400 ms
64.233.175.171 (64.233.175.171) 54.772 ms
72.14.236.114 (72.14.236.114) 54.420 ms - google-public-dns-a.google.com (8.8.8.8) 54.663 ms 54.480 ms 94.454 ms
The first is my internal IP address. The second is our gateway address. The third is our provider’s demarc with their upstream. The fourth is where it enters Google’s servers.
- Network administrators, to make their lives easier, often label those intermediary hops with names. This is not required. Often those names have geocoding information. These are often names of cities, airport codes, weather station codes, neighborhood names, apartment complex names—all kinds of things. In core2-1-1-0.pao.net.google.com, “pao” is Palo Alto, California, which has an airport IATA code of PAO.
- If you’re very lucky, you will have a traceroute that shows very little router delay (like one hop in my example above). Then you can use actual physics to tell you where it must be in relation to the adjacent hop.
Light (and electricity) travels 300,000 km/sec, or 186,000 miles/sec. Per millisecond, 300 km or 186 miles. It’s easier to multiply by 300 than 186 in my head, so I’ve typically stayed metric at this point, but I’ll give both. Besides, it just sounds cool to drop millilightseconds in a conversation.
See that last hop? 54.420 -> 54.480 (using minimum to minimum)? That’s 6 hundredths of a millisecond, meaning the laws of physics say the packet traveled a maximum of 18 km or 11.2 miles.
Except traceroute measures time there and back, so the real numbers are 9 km or 5.6 miles.
Is it in Palo Alto? The end location is 1.808 ms from the stated Palo Alto location, which means it’s at most 262.35 km or 168.25 miles from Palo Alto. So almost certainly SF Bay Metro with some lag. This is where repetitive traceroutes at different times from different locations would be helpful. (I’d expect the location to be Mountain View, California, which is the city south of Palo Alto, and also Google’s HQ.)
That’s the Basics. Really.
So the real trick to geolocation is to have as many knowns as possible. This means having server space on fast networks around the world, being able to triangulate in on locations of interest, and getting different results over time.
You can read more about using millilightseconds in this humorous story of network diagnosis.
This four-part series about traceroute is quite good, and covers some of the wrinkles.
My Own Little Experience
I mentioned this on Twitter at the time it happened.
There are some interesting nuances here:
- I don’t have a user called admin, but that’s the default super user in WordPress.
- If you do a whois on that IP address, you’ll note it’s assigned to T-Mobile:
NetRange: 172.32.0.0 – 172.63.255.255
CIDR: 172.32.0.0/11
NetName: TMO9
[…]
Organization: T-Mobile USA, Inc. (TMOBI)
Real hackers trying to crack into your web site will not be using mobile as a rule. This was personal, not a doorknocker. - At the time, it showed up as being in LA. Once you get a dynamically-assigned IP address, such as a mobile address, to a metro area, there’s no guarantee you’ll get closer than that.
-
[I note that this screenshot shows 1) T-Mo; 2) LA](https://twitter.com/jaidblack/status/461945958104698881), and my breakin attempt was [a couple of hours after this was posted](https://deirdre.net/elloras-cave-trust-and-confidence-wtf/). Obviously, no proof, yada yada. Just: correlation.
Update to this section, May 2015: It turns out, and I’m thankful for this, that there is a far more ordinary explanation for what happened. I can’t prove it’s what happened in December, but it did happen last week. In January 2014, Rick and I were traveling and would be in some of the remotest parts of the world (in fact, we spent three days out of satellite range of Internet, believe it or not). I gave admin credentials to a friend who lives in the LA area to blogsit and make sure any security updates got applied while we were gone. It turns out that, since saving that password, she’d switched her mobile device from Verizon to T-Mobile, and I’d since changed the admin username. She doesn’t use mobile data much, so it didn’t try to access my site for a long time (or frequently). And there you are.
My apologies to Jaid Black for the insinuation.
Also, a better security method for dealing with this issue is to make a second admin user. Doh.