“Getting into Fights with Data Centres” is a zine that has a guide for finding the location of data centers, using ping
and traceroute
.
Both of these command line applications use a protocol (ICMP) that is not supported by the Tor network. Here is an adapted version of the guide that will work from Tails.
STEP 1: PICK A TARGET
Anything with a URL or IP address will work. What’s an IP address? It’s a set of 4 numbers that works like a ZIP/postal code for the vast mail system of the Internet. IP is short for Internet Protocol, which are a bunch of rules written in the early days of the Internet to ensure that your requests and replies all eventually go where they should, even if they take different paths across the middle of the network
STEP 2: GET YOUR IP
If you don’t already have an IP address, we’ll start with that. This is a way to sort of ‘knock on the door’ of a website, get that IP address, and see if someone’s home.
We can get the IP address by visiting a website that runs ping for us and entering the URL there.
- Visit a website like https://check-host.net/check-ping that runs ping for you from a server. Note that sometimes multiple IP addresses are returned, depending on what location ping was run from. If this is the case, your target serves their website from a different data center depending on their visitor’s location.
- Enter castlefieldgallery.co.uk (or a different website you’re interested in examining) and press “Ping”.
- The 4 numbers punctuated by periods (51.89.229.122 is Castlefield’s) is the IP address. You now have their digital postal address!
STEP 3: GEOLOCATING IP ADDRESSES
Unlike the postal system, however, IP addresses don’t point to an obvious physical place where you can dump your physical mail. However, there’s also a trail of domain registration info that we can poke at to get some clues of where in the world this data might be hosted. To do so, we’ll turn to a few free look up services.
- Go to https://www.ipaddress.com/ip-lookup, https://www.ip2location.com/demo, or https://www.maxmind.com/en/geoip-demo. Enter the IP into their search field.
- Find the latitude and longitude (51°30′31″ N 0°5′34″ W is Castlefield’s) and enter it into GoogleMaps (or other mapping program like https://www.openstreetmap.org).
- This will likely probably plunk you in the middle of somewhere without an obvious data center in view. So, with your map zoomed around these general coordinates, search for ‘data centre,’ ‘cloud,’ or ‘web hosting’ until you find a business that looks like a plausible match.
Note: Be skeptical of addresses located right in the middle of expensive city real estate. Unless there’s an IXP or submarine cable landing station nearby, chances are the IP address website has given you the location of the corporate offices of company that registered the website, not necessarily the location hosting its content. Sometimes, to offer a bit of privacy, IP look up tools will also simply point to the address of the closest city centre. If you’re not finding anything, or if you’re only finding financial centre boutique businesses, check your look up tool of choice for ISP (internet service provider) names. Pick up the trail on GoogleMaps with that info.
For instance, in the case of Castlefield Gallery, the geographic coordinates plunked me right in the middle of the Thames in a very posh part of London. The chances of a data center being built here are slim—I’ll need to widen my search. Looking back at my IP location lookup site, I can see that something called OVH is listed in the fields for both Castlefield’s ISP and domain. Using this as my search term points me to OVH’s London headquarters in a swanky skyscraper. The company probably used this address to register their domain info, but it’s again pretty unlikely that they’ve stuffed all their servers into a pricy and fairly vertical office.
When poking around a site I like to use Google Street View to confirm whether or not the vibes are off. Anything with outwards facing glint (sleek windows, lobby art, a property manager’s stylish website for prospective tenants, etc.) or even just a fair bit of height is cause for suspicion. Your data center is much more likely to be a beige, sprawling warehouse, fenced off from the world (but also trying to look sort of unassuming about it).
So, let’s keep looking. Zooming out of the London city center reveals another hit for OVH further down the Thames in a slightly more inglorious borough called Erith. This site is located on a one way street next to a busy traffic artery and a set of factories and distribution centers. This is much more like it! Seen on Street View, it’s an obvious match: there’s a telecommunications tower out front chock full of antennas, next to a bunch of modified shipping containers stacked on top of each other (almost surely full of server racks). Other tells include security gates, two massive power boxes with electrocution warnings, and a ‘thieves beware’ sign explaining how clever forensic devices in the cables, metals, and equipment on the site will thwart efforts to steal and sell any stolen goodies. Oh yes—we’ve got a data center on our hands. A quick search across OVH’s own website confirms that they have only one data center location in the UK, and it’s in Erith. We’ve found our match.
Troubleshooting with traceroute
Of course, this might not be so simple. Maybe your IP geolocation data is absolutely in the middle of nowhere, or it’s proving tricky to make the jump from the offices of the folks who registered the IP address to the digital warehouse where the digital stuff actually is. We have another trick up our sleeve: we can run a traceroute.
This is a diagnostic tool used by clever IT people (and malicious hackers) looking to trace the route data takes across the network to get from point A or point B. Internet traffic can change its paths dynamically as stuff goes offline or comes back up after maintenance, so you may not get the same results from one day to the next. In general, though, you can often find some useful hints about the sea of routers and exchange points your data moves across, all of which can help you zero in on where your target must be located, relative to the rest of your traceroute.
STEP 1: RUN YOUR TRACEROUTE COMMAND
Traceroute works by sending a message to each router in the path to reaching your destination, and then getting those routers to send little messages back to your computer identifying who they are. If all works well, you’ll end up with a list of all the steps (called ‘hops’), how long it took each of them to respond, and their IP addresses. It’s this latter information that we’re interested in, since we already have some tools to translate those IP addresses into approximate geographic coordinates. Taken altogether, this can draw a map of how your data actually moves across the planet (and thus where it ultimately comes from).
STEP 2: INTERPRETING THE RESULT
Reading the output of a traceroute takes a bit of practice. Your computer will output a series of lines showing hop numbers, times, and IP/domain information. Each hop represents a location in the network that your request passes through. The first few lines are always going to be your local network with a lot of private IP addresses (and so, not terribly insightful).
Next you’ll probably hit an internet exchange point (IXP). These sometimes have names of cities in the information that comes before the IP addresses (or at least, abbreviations thereof. ‘Toro’ can mean Toronto, and so on).
The exciting stuff comes next: lots of seemingly random IP addresses. Try piecing together the geographic path of your data by looking up the locations of each IP address using the same tools as before. You might write down the cities in a list, or try putting down pins on a map. In this way, even if you can’t determine the location of the final IP, the path leading up to it can offer useful clues.
If you’re still stuck, or if you want to cross reference, a few other tools you could play around with are https://traceroute-online.com/mtr/, https://geotraceroute.com, or https://hackertarget.com/online-traceroute/. I personally find them a little more error prone and hard to parse, but you might be built different! You could also try on a different day (and so maybe a different route through the network).
Submitted anonymously