It seems like many aren't quite getting what's going on here...here's a brief overview:<p>Shodan.io fancies itself as a search engine where you can search for IOT things (webcams, refrigerators, etc) that are on the internet.<p>They have no technical issues doing this in the IPV4 space, because it's easy enough to scan every single address in the space.<p>This isn't practical for IPV6. So, it seems they wanted a way to identify every IOT device in the IPV6 space without having to scan all of it.<p>At least one approach they found was to join the ntp.org pool[1], and effectively donate server time. Since pool.ntp.org is the default NTP server listed for many linux distros (and thus, probably IOT devices), they now are getting live connections from the exact devices they want to index on their search engine.<p>Once you connect, they scan you back on 100 ports on so (ports unrelated to NTP) to see if you are a webcam, router, or whatever else they want to put in their index.<p>Pretty shady. Kind of like volunteering for a charity so that you can raid their internal mailing list for spam purposes.<p>[1]<a href="http://www.pool.ntp.org/join.html" rel="nofollow">http://www.pool.ntp.org/join.html</a>
The lesson here, I think, is that security intuitions developed in an IPv4 world with NAT everywhere may need re-examining in an IPv6 world.<p>If your device has a publicly routable IP address, it should probably be behind a firewall. If it's not behind a firewall, it's going to get scanned. Relying on security through address space size is stupid.<p>> What was most puzzling was the fact that the devices that were targeted had randomized IPv6 addresses and were not published in DNS or any public record. For all intents and purposes they were hidden safely within my lab network.<p>That is just wrong, and it's wrong in a very glaring, obvious way: The devices were not "hidden safely within [his] lab network", because he was not using NAT. They were connected to the internet with publicly routable IP addresses, which they were using to communicate with other hosts on the internet.<p>Edit: That being said, it's a great writeup, and some good technical work was done to figure out what was going on, and I enjoyed reading it. But the starting premise seemed to be "how could this be happening, my devices are hidden!" and I feel like it should have been "oh, it makes sense that someone would do this since my devices are no longer hidden".
I'm not really seeing a vulnerability here. The entire IPv4 internet is scanned probably hundreds of times a day. Was anyone really counting on IPv6 addresses being longer to add security?<p><a href="http://www.internetsociety.org/deploy360/blog/2015/02/ipv6-security-myth-4-ipv6-networks-are-too-big-to-scan/" rel="nofollow">http://www.internetsociety.org/deploy360/blog/2015/02/ipv6-s...</a>
Very interesting post, I've suggested to Brad that he consider probes with a decreasing ttl in the packet to see if the harvesting is happening at an interstitial node or directly on the ntp server. If you had access to a compromised Juniper router it would be straight forward to add a rule to mirror packets which were headed to the NTP pool addresses.<p>Oddly after being an unwitting participant in one of the NTP amplification attacks I set up my own stratum 0 NTP server based on the beaglebone black, the adafruit GPS module, and the PPS time keeper code. So all of my machines only talk internally for time, although initial installs still use what ever the distro packed into them. I brought up Debian on a Dragonboard 410c and it sets the time via an NTP call during the initial startup process. (or fails to set the time as NTP is blocked egress/ingress from the firewall)
If someone is detecting which IPv6 addresses are in use in your range from NTP requests, that implies they are all talking to the external NTP servers directly.<p>Surely if all your internal hosts are talking directly to the external NTP servers you are doing it wrong? My gateway box sets itself by pool.ntp.org and the internal ones set themselves by it. I thought that was how you <i>should</i> do things (even if it isn't a rule, it is only polite to try not overuse a public resource).<p><i>> These addresses are 128 bits in length</i><p>Only 64 are relevant here: once you make outgoing connections from any address a scanner knows there is at least one active host in that /64 and there may be more. Though of course a 64 bit address space is still impractical to scan.
While it is pretty freaky, I think the point of Shodan scanning IPV6 devices that use the default pool is to detect linux-based IoTs that use the default NTP settings, which is kind of the reason why Shodan exists.<p>It is unlikely that Shodan is going to hack your Raspberry Pi specifically because then people will go after them. But hackers of many hat colors will use the freely available information it gathers for their own purposes, so act with this in mind.
Isn't this article just saying that "security through obscurity" doesn't work, and you can't count an obscure IPv6 address to keep you hidden?<p>If your server isn't meant to be contacted by the world, then put it behind a firewall. Don't count on an obscure address to keep you hidden.
There is (starting to be) discussion on a few mailing lists as well, including pool@lists.ntp.org [0].<p>[0]: <a href="http://lists.ntp.org/pipermail/pool/2016-January/007758.html" rel="nofollow">http://lists.ntp.org/pipermail/pool/2016-January/007758.html</a>
Nice evidence for why site operators should be running their own NTP servers. If you run 1 server set per site which doesn't even need a strong local clock, you mitigate this information leakage.<p>I'd think this is something that most network designers/engineers would get. That said, I'd be a rich man if I had a nickel for every time I saw NTP misconfigured.
Unless I missed something in the article, I'm not sure this is odd or malicious behavior. The NTP servers know your IPs because you sent packets to them from those IPs. So you basically told them what your big random 128-bit IPv6 address is.<p>And the fact that they sent packets back to you (after you sent them packets) is not surprising either. However, if you can show that a full-blown port scan occurred after you sent them packets, then that would be odd. I did not see evidence of that in the article... did I miss that?
We've gone from anonymous people scanning you, to semi-trusted people scanning you.<p>The mantra of the new Internet is "Trust no one". :(