Interesting to learn you can identify the real country/area of origin using probe latency. Though could this be simulated? Like what if the VPN IP just added 100ms-300ms of latency to all of its outgoing traffic? Ideally vary the latency based on the requesting IP's location. And also just ignore typical probe requests like ICMP (ping). And ideally all the IPs near the end of the traceroute would do all this too.
To use an example, 74.118.126.204 claims to be a Somalian IP address, but ipinfo.io identifies it as being from London based on latency. Compare `curl ipinfo.io/74.118.126.204/json` vs `curl ipwhois.app/json/74.118.126.204` to see. If that IP ignored pings and added latency to all outgoing packets, I wonder if that would stymie ipinfo's ability to identify its true origin.
[IPinfo] pings an IP address from multiple servers across the world and identify the location of the IP address through a process called multilateration. Pinging an IP address from one server gives us one dimension of location information meaning that based on certain parameters the IP address could be in any place within a certain radius on the globe. Then as we ping that IP from our other servers, the location information becomes more precise. After enough pings, we have a very precise IP location information that almost reaches zip code level precision with a high degree of accuracy. Currently, we have more than 600 probe servers across the world and it is expanding.
In my first job out of school, I did security work adjacent to fortune 50 banks and the (now defunct) startup I worked at partnered some folks working on Pindrop (https://www.pindrop.com/).
Their whole thing at the time was detecting when it was likely that a support call was coming from a region other than the one the customer was supposed to be in (read: fraudulent) by observing latency and noise on the line (the name is a play on "We're listening closely enough to hear a pin drop".)
Long story short, it's a lot more than just the latency that can clue someone in on the actual source location, and even if you introduce enough false signal to make it hard to identify where you actually are, it's easy to spot that and flag you as fake, even if it's hard to say exactly what the real source is.
Latency is only one dimension of the data we process.
We are pinging IP addresses from 1,200+ servers from 530 cities, so if you add synthetic latency, chances are we can detect that. Then the latency-related location hints score will go down, and we will prioritize our dozens of other location hints we have.
But we do welcome to see if anyone can fool us in that way. We would love to investigate that!
Do you run traceroutes and pings in both directions?
In the case of a ping you might think it shouldn't matter but I can imagine a world where a VPN provider configures a server in London to route traffic via Somalia only when a user establishes a connection to the "Somalia" address of the server. You could only test this if you did a traceroute/ping through the VPN.
And I'm not saying this is what's happening but if you just ping the IP from your infra, couldn't stuff like anycast potentially mess you up?
In the case of traceroutes, you only see the route your traffic takes to the VPN, you don't see the route it takes to get back to you, which I think is really important.
We run traceroutes and latency measurements from many different locations, so we are looking at aggregate behavior rather than any single path. When you combine data from hundreds of ProbeNet PoPs over time, asymmetric routing mostly shows up as noise. When that happens, latency based hints lose weight and we lean more on other signals.
We have seen this in practice. For example, when we deployed servers in Gambia, even traffic between local networks often left the country and came back due to limited peering and little use of the national IXP. Stil, the overall routing patterns were still learnable once you look at enough paths.
For VPNs, we are measuring the location of the endpoint IP itself, not user traffic inside a tunnel. If routing only changes after a tunnel is established, that is a service level behavior, not the network location of the IP.
Anycast and tunneling are things we explicitly detect. They tend to create clear patterns like latency clustering or unstable paths, and when we see those and flag them as anycast IPs by defaulting to their geofeed location.
If the VPN IP and the last ~4 hops in the traceroute just ignored ICMP pings, or just all
inbound traffic, it sounds like that'd make your detection harder?
I've found that this isn't even that uncommon. One of the example VPN IP's on the article had the last 3 hops in traceroute ignoring ICMP. (though TCP traceroute worked). The VPN IP itself didn't, but it easily could!
(feel free to ignore lest we not give bad actors ideas)
This can fool someone from one location and only in one way (if you are near Somalia and expect a 10ms latency, a virtual VPN can't reduce latency to simulate been in Somalia).
So it have to be dynamic to fool multiple locations to stay probable.
But anyway, *you can't fool the last-hop latency* (unless you control it, but you can control all of it), and basically it impossible to fool that.
Does this really work? I would think the ping time would not be dominated by speed of light, but by number of hops, and connection quality.
As a hypothetical example, an IP in a New York City data center is likely to have a shorted ping to a London data center, than a rural New York IP address.
It's possible to deduce password hashes by timing responses over the internet if the server isn't using constant time comparison. Noise is just that, a noise.
Only if the detection mechanism is looking at that single IP and from a single location.
Find the ASN(s) advertising that network and figure out their location.
Even within the ASN there may still be multiple hops, and those IPs may be owned by others (eg the hosting facility) who are not playing the same latency games.
We operate servers for the purpose of measuring the internet using a wide variety of methods. We have more than 1,200 of these servers distributed across 530 cities, running not only ping but traceroute and many other types of active measurements.
In addition to active measurement and research, there are many other sources of data we use. Also, we are actively investing in R&D to develop new sources. Adding just 300ms of latency at the end of an IP address would simply appear as noise to us. We have dozens of locations, hints cut through the noise.
We welcome people to try to break the system. Perhaps it is possible to dupe this system.
You could vary the additional latency based on the location of the IP you're replying to? Or just hash the requesting IP and use that as a seed to generate that particular IP's random extra latency that always stays the same for that IP. Which feels like enough to make triangulation hard. Though I'm just spitballing.
To use an example, 74.118.126.204 claims to be a Somalian IP address, but ipinfo.io identifies it as being from London based on latency. Compare `curl ipinfo.io/74.118.126.204/json` vs `curl ipwhois.app/json/74.118.126.204` to see. If that IP ignored pings and added latency to all outgoing packets, I wonder if that would stymie ipinfo's ability to identify its true origin.