SoylentNews

upstart writes:

Pinging Locations - The Hacker Factor Blog:

Honeypots provide a great opportunity for identifying how attackers operate, how to defend your servers, and how to protect your privacy. They allow the operators to evaluate new threats and test different response options without putting the production servers at risk.

My honeypots have been collecting a lot of data. Interestingly, most of the logs show ICMP echo-request packets (aka "ping"). Ping is one of the simplest diagnostic tools. You send an echo-request (ping) packet to a server and the server reponds with an echo-reply (pong) packet. If you receive a packet back, then you can identify the latency and determine if there is some kind of unexpected delay or networking issue. And if you get nothing back, then either the server is down or the network is unreachable.

On the open internet, ping is usually used for reconnaissance or attacks. However, this time the majority of ping packets appear to have a different purpose: geolocation.

[...] Here are two sample packets that I received. I've redacted my IP addresses and highlighted the payload's timestamp:

14:00:05.241484 IP 15.228.95.55 {ipv4}: ICMP echo request, id 15, seq 5256, length 16
0x0000: 4528 0024 3783 4000 f001 xxxx 0fe4 5f37 E(.$7.@......._7
0x0010: xxxx xxxx 0800 9fef 000f 1488 1759 947e xxxx.........Y.~
0x0020: 2082 771f 0000 0000 0000 0000 0000 ..w...........

09:56:04.114187 IP6 2600:1f13:b75:1c01:e121:1e4c:7569:34af {ipv6}: ICMP6, echo request, seq 3428, length 16
0x0000: 6002 1cab 0010 3af1 2600 1f13 0b75 1c01 `.....:.&....u..
0x0010: e121 1e4c 7569 34af xxxx xxxx xxxx xxxx .!.Lui4.&..@xxxx
0x0020: xxxx xxxx xxxx xxxx 8000 c8ac 0007 0d64 xxxx...4.......d
0x0030: 1759 d5c1 b532 ceff .Y...2..

With both the IPv4 and IPv6 packets, you'll see the payload contains an 8 byte hex value that begins with "1759". That's the embedded timestamp. It's encoded as Unix epoch time in nanoseconds. (Number of billionths of a second since 1-Jan-1970.)

[...] So what are they doing? It looks like they are doing packet-based geolocation.

[...] Remember: Speed of light × elapsed time = distance. Now they have a radius for how far away my server is. By doing the same test over and over and from a wide range of sources, all of the distances begin to overlap (triangulate) in a specific location. At the rate they are scanning, they have probably located my server to within a 25 mile (40km) radius.

But why stop there? They are using a wide range of sources and are querying every pingable server. They can use these known locations to help fine-tune the geolocation for lots of other subnets. This is how you geolocate every network on the entire internet.

[...] Stopping pings does block this group from doing geolocation. However, I want ping enabled for my honeypots. For those systems, I came up with another creative solution:

sudo tc qdisc add dev eth0 root netem delay 100ms 50ms 75%

(You might need to install niceshaper: sudo apt install niceshaper.)

The "tc" program does traffic control. Usually administrators use it to throttle the throughput so that one host doesn't dominate all of the building's bandwidth. However on my honeypot, I just added in a random delay of 100 +/- 50ms. Suddenly those measured delays and computed distances are unreliable. Things that should be 1,800 miles away can now appear to be over 100,000 miles away. (That computed example of 69,000 miles was due to this random delay.) This doesn't stop them from pinging my server, but it does poison their geolocation computations.

I haven't yet figured out how to only add delays to ICMP and ICMPv6 echo-request packets. But this solution is definitely good enough for now. Nothing stops them from slinging their echo-request packets all over the internet. However, my production servers don't respond and my honeypots mess them up.

Original Submission