Stories
Slash Boxes
Comments

SoylentNews is people

posted by hubie on Wednesday May 10, @06:52AM   Printer-friendly
from the machine-that-goes-"ping" dept.

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

This discussion was created by hubie (1068) for logged-in users only. Log in and try again!
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 5, Informative) by Barenflimski on Wednesday May 10, @07:13AM (4 children)

    by Barenflimski (6836) on Wednesday May 10, @07:13AM (#1305663)

    That may be one of the coolest things I've heard in awhile.

    Appreciate you sharing that.

    • (Score: 5, Interesting) by zocalo on Wednesday May 10, @07:51AM (3 children)

      by zocalo (302) on Wednesday May 10, @07:51AM (#1305665)
      Definitely cool, but worth pointing out that you can't assume the traffic travels at the speed of light C as it's traversing fibre (or maybe even copper), not a vacuum so it's going be around 60-70% of that. I'd expect that the people behind this have thought of that, and maybe even added in a fudge factor based on the likely number of hops as well to allow for routing delays and the like. That'll reduce the margin of error the induced latency will be adding to their data somewhat, and the precise velocity will be depend on the frequency of light and type of each fibre being used as well. This is not going to be anywhere close enough to being precise enough to target a cruise missile or drone, so you can sleep easy. Well, unless you are up to something so nefarious they might just nuke you from orbit - it's probably good enough for that. :)

      FWIW, I've seen this kind of traffic too. Almost all of the the IPs I've seen are hosted on cloud providers rather than eyeball network botnets, with a broad spectrum from the big players down to the really sketchy providers you'd probably be better off just null routing, so my guess is that multiple operations are doing this kind of thing, and with varying shades of hat being worn. Several of the IPs I saw had RDNS that implied a connection to CDN provision, which perhaps makes sense as they wouldn't need pinpoint accuracy, just good enough to assign the optimum node to serve data to the target IP/subnet the most efficiently. So, caveat emptor, while not an issue for a dedicated honeypot, screwing with the latency like this might also degrade your Netflix/Steam/Whatever experience.
      --
      UNIX? They're not even circumcised! Savages!
      • (Score: 2) by Gaaark on Wednesday May 10, @01:57PM (2 children)

        by Gaaark (41) Subscriber Badge on Wednesday May 10, @01:57PM (#1305700) Journal

        Plus, not sure if it really applies here, but doesn't a time server add a fudge number of it's own? I read somewhere that something like a command of 'date' will not return ACTUAL 'atomic server time', but will return a server time of +/- of milli-seconds due to the 'traversing fibre...' you mention.

        But i may just be tired.

        --
        --- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
        • (Score: 3, Informative) by zocalo on Wednesday May 10, @02:36PM (1 child)

          by zocalo (302) on Wednesday May 10, @02:36PM (#1305706)
          Been a while since I configured chronyd, but I'm pretty sure there is a mechanism in NTP to approximate the time delay between the NTP client and server as well as a query burst mode that will send a number of queries in case of any outlier response times. The preference is definitely still to minimise latency though, and with relatively cheap USB GPS dongles readily available there's really no excuse for not having a local GPS source if you are doing anything especially time sensitive (or just bite the bullet and deploy a Wharton clock or similar if your budget will stretch to it). If your tolerance is a few ms, e.g. pretty much everyone not doing SCADA or other time-critical telemetry, then your NTP daemon of choice will almost certainly be more than good enough.
          --
          UNIX? They're not even circumcised! Savages!
          • (Score: 2) by Gaaark on Wednesday May 10, @04:50PM

            by Gaaark (41) Subscriber Badge on Wednesday May 10, @04:50PM (#1305742) Journal

            Modded you 'Informative'. Was thinking "Wubbah?"

            But really thinking "I should have taken a nap today".

            --
            --- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
  • (Score: 2, Interesting) by shrewdsheep on Wednesday May 10, @09:00AM (8 children)

    by shrewdsheep (5215) on Wednesday May 10, @09:00AM (#1305668)

    Very interesting indeed. I am wondering whether this is necessarily malicious intend. Maybe somebody wants to create a more accurate mapping than achievable through the (paywalled) curated subnet mappings. I am still trying to figure out why you would want to know the physical location unless you need physical access. DDos'ing should be content with latency and throughput. Jurisdiction is defined by the IP address. Any thoughts?

    Also I believe that the current implementation is maybe easiest to analyze but not the stealthiest. Just relying on round-trip times or maybe locally time-stamping package send and receive would do the same trick but would be undetectable. Did I overlook something?

    Systematically performing triangulation of the whole internet would create a map based on the round trip metric. That would be cool to see.
     

    • (Score: 1, Interesting) by Anonymous Coward on Wednesday May 10, @10:52AM

      by Anonymous Coward on Wednesday May 10, @10:52AM (#1305676)

      I am still trying to figure out why you would want to know the physical location unless you need physical access.

      Plenty of reasons. For example maybe you have 30 suspects, but with the physical location info you've now narrowed it down to 5 locations. So you go visit the places and then you do some parallel reconstruction so that you don't actually reveal what method you actually used in the first place.

      Another example say if you use Google DNS, visit www.google.com, gmail, youtube and "coincidentally" on various days all these destinations are all at different physical locations. After gathering enough samples (probably need a lot) Google might be able to work out roughly where you physically are. Not saying Google is actually doing this. There's normally no need to do such stuff if they already know your IP and have leverage over the relevant ISP...

    • (Score: 3, Interesting) by Gaaark on Wednesday May 10, @02:03PM (4 children)

      by Gaaark (41) Subscriber Badge on Wednesday May 10, @02:03PM (#1305701) Journal

      I was thinking, for example, someone wanting to dox.
      Find location, collect other data...profit?

      Damn... i gotta get off this internetty thing... I can't keep up... too fecking old...too little time.... got a son we had to take to the hospital 'cos he fell out of the shower..... never get enough sleeep.....somebody shoot me.... :()

      *****************I think we need a tutorial section!!!!! Info like this^ (original article) is needed! ********************************

      --
      --- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
      • (Score: 3, Informative) by janrinok on Wednesday May 10, @03:35PM (2 children)

        by janrinok (52) Subscriber Badge on Wednesday May 10, @03:35PM (#1305718) Journal

        I think we need a tutorial section!!!!! Info like this^ (original article) is needed!

        I agree, but there are very few sites covering such things nowadays, and thus even fewer submissions to our site.

        I have added the RSS feeds to our bots so hopefully we might see a few more articles from them in the future.

        • (Score: 3, Interesting) by Gaaark on Wednesday May 10, @04:56PM (1 child)

          by Gaaark (41) Subscriber Badge on Wednesday May 10, @04:56PM (#1305743) Journal

          You are a gem.

          Did that sound gay to you? :)

          I know the internets is full of tutorials, but i believe the people who occupy this site have lots of information to give and lots my mind would love to in-take (when i'm fully awake and probably retired in a couple/few years) and would give 'REAL' information.

          I think intelligent info here would be nothing but a plus.

          And thank you for your 'gem-inus'. You and the other editors and submitters.
          And 'spank you' to @Hubie as well.
          Spank you. :)

          --
          --- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
          • (Score: 2) by hubie on Thursday May 11, @02:42AM

            by hubie (1068) Subscriber Badge on Thursday May 11, @02:42AM (#1305822) Journal

            And 'spank you' to @Hubie as well.

            You are quite welcome, and I gratefully accept your thanks, though I will endeavor to keep my backside pointed away from you, if you don't mind. :)

      • (Score: 2) by corey on Thursday May 18, @11:07AM

        by corey (2202) on Thursday May 18, @11:07AM (#1306828)

        Yeah agree, fun to read this. Last time I read stuff like this was in 2600 magazine. Or Phrack. I actually bought all the 2600s in pdf, I should go read them sometime.

    • (Score: 3, Insightful) by zocalo on Wednesday May 10, @02:54PM

      by zocalo (302) on Wednesday May 10, @02:54PM (#1305711)
      This is probably a side-effect of all the IPv4 block trading going on. You used to be able to assume that a given subnet was within the region of a given RIR (continent, basically) with a relatively low margin of error, e.g. some legacy IPs, etc. that pre-date the RIRs, but the IP market has now blown that out of the water and sub-allocated netblocks can now pretty much be anywhere on the planet.

      Possible white hat use:
      There are IP geolocation DBs already, but they need to get their data somehow, especially now specific WHOIS and SWIP'd IP range data is either questionable or absent entirely, assuming it contained geolocation data in the first place. The bigger CDNs also have a *lot* of nodes, so just getting the right country (or state/province) might not be the optmimum solution anymore. As I noted in my post above, RDNS indicates at least some CDN providers are generating this traffic, so it seems likely that both would need to map out the Internet somehow, and it's probably cheaper to DIY than license the data from a third party.

      Possible black hat use:
      Certain country's APT teams have been documented as not targetting their state's allies (some presumed-Russian malware will not install if the target is likely to be in former Soviet Republic, for instance), and state-sponsored teams will almost certainly want to know who they are targetting before disrupting national infrastructure or the like. Knowing a quite specific location for a potential victim could also be very useful in spear phishing campaigns as it would add an additional layer of credibilty to the baited hook, e.g. by pretending to your utility company/bank/whatever's local branch office.
      --
      UNIX? They're not even circumcised! Savages!
    • (Score: 2) by ChrisMaple on Thursday May 11, @08:04PM

      by ChrisMaple (6964) on Thursday May 11, @08:04PM (#1305933)

      Locations are used for targeted advertising, especially "Hot babes want to **** you in <your town> tonight!"

  • (Score: 2) by Gaaark on Wednesday May 10, @02:05PM (1 child)

    by Gaaark (41) Subscriber Badge on Wednesday May 10, @02:05PM (#1305702) Journal

    Please post tutorial!

    Please editors add a tutorial section.

    Sorry, but this is so interesting. Never thought this deeply into logs, etc.

    --
    --- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
  • (Score: 2) by istartedi on Wednesday May 10, @05:08PM

    by istartedi (123) on Wednesday May 10, @05:08PM (#1305746) Journal

    Perhaps the majority of the ping packets on the network are up to no good, but I hope they don't stop routing them just because of that.

    I frequently use ping to make see if it's the network having problems, or the service. Something like an HTTP server can go down, but if you can still ping the location you know it's not the network. Sometimes all the servers are down, I can ping the DNS, but can't resolve anything--the DNS server is up, but the DNS service itself has somehow gone down.

    If we allow bad actors to take this away, problems will become harder to diagnose.

    --
    Appended to the end of comments you post. Max: 120 chars.
(1)