I told you, read the paper. But I’ll show you an example.
Let’s say someone who is trying to find the “harvesting” NTP servers can use an IPv6 prefix 2001:db8:aaaa:bbbb::/64. This means they can use IP addresses between 2001:db8:aaaa:bbbb:0:0:0:0 and 2001:db8:aaaa:bbbb:ffff:ffff:ffff:ffff for this work. This means there are 2^64 or 18446744073709551616 available addresses they can use.
Now, an NTP query is sent to server A from address 2001:db8:aaaa:bbbb:0:0:0:1, another NTP query to server B from address 2001:db8:aaaa:bbbb:0:0:0:2, the third one to server C from 2001:db8:aaaa:bbbb:0:0:0:3 and so on. At some point they may have reached 2001:db8:aaaa:bbbb:3351:3343:a4f6:a4b4 when querying server Q.
Then if all of sudden someone tries to SSH into 2001:db8:aaaa:bbbb:3351:3343:a4f6:a4b4 without trying any of the other IP addresses in the 2001:db8:aaaa:bbbb::/64 range first, they can determine that Q is the one leaking the clients’ IP addresses. For extra certainty, the test can be repeated by sending the query again to Q from a new address, say 2001:db8:aaaa:bbbb:4444:5555:6666:7777. If there’s again an SSH connection attempt to 2001:db8:aaaa:bbbb:4444:5555:6666:7777 without any other connection attempts to the 2001:db8:aaaa:bbbb::/64 network it’s very clear that Q is the bad guy in this example.
The key is that none of these source IP addresses are reused for queries to other servers, and all the queries that were sent are logged for later analysis.
Yes, it would be dumb of the bad guys to try to SSH (as an example service) from the NTP server’s address or network. However, nothing prevents the bad guys from shipping the list of determined NTP client addresses to some other server they control. This way the NTP server and the attacking server can be in entirely different networks.
Here the prober sends NTP queries to two NTP servers using source addresses 2001:a::92a1:4c10:eb04:377d and 2001:a::f55a:86bb:e921:d4e1.
Then later on, someone from a different network tried to do a TCP port scan of 2001:a::92a1:4c10:eb04:377d, suggesting that the topmost NTP server has somehow leaked the client’s address to the bottom server doing the TCP port scan.
Many NTP clients are unwitting users of the pool and are not necessarily able to protect themselves. A prime example, as we discuss in our paper, are IoT devices, e.g., thermostats, lightbulbs, cameras, printers, etc that are running embedded Linux and configured to use the pool for time. As our closely related work has shown, many residential networks use CPE that do not provide any firewall or statefull firewall for IPv6. As the IPv6 addresses within the home are public and globally routable, they are externally reachable.
Yes, we were disappointed that a purely technical post highlight a potential issue of community interest was flagged as spam. I messaged the moderators, but did not receive a reply. Happy to share the URL again: Backscanning IPv6 NTP Clients
Thanks for sharing the update. Greater transparency around IPv6 backscanning is definitely appreciated, especially since many operators want to understand what traffic is being generated and why. It would also be helpful if there were clear documentation describing the scanning methodology, expected traffic patterns, and any opt-out or reporting process. That would make it easier for pool operators to distinguish legitimate research from unexpected activity and build trust in the project.
It seems it was the forum bot that was responsible for the flagging, enforcing a rule intended to keep new users from spamming, but where it is unclear upon manual inspection how it was supposedly broken…
You want to rewrite the entire NTP-protocol just because of this? That will give a mess.
Also, who prevents then bad-guy from using the old protocols that do not have a part of the IP?
As you can not force the entire NTP-network to move to a new protocol and shutdown the old ones.
I fail to see why the pool must address this to ‘secure’ poorly managed IP-devices.
The NTP protocol is not the problem here, and no NTP protocol rewrite would fix this issue. This is essentially an IP level issue. For example, another way to collect client IPv6 addresses would be to set up a Linux distribution mirror and register it as a publicly available mirror. Then when some IPv6-enabled Linux box tries to get updates, the mirror server would find out that there’s a Linux box (or a proxy) at some specific IPv6 address, with the added bonus of knowing which particular Linux version the client uses.
As for securing devices, remember that there can be multiple layers of security. If we take SSH as an example, ways to secure the device could include:
No direct access for root user
Use keys instead of passwords
Use good passwords
Block IP addresses or networks that have tried to log in unsuccessfully too many times
Blocking of specific countries/continents
Or just whitelist some specific IP addresses and block the rest
Restrict which users can ssh in
Port knocking
Use a non-default SSH port
MFA
Connection rate limiting
etc.
The large IPv6 address space would just add one layer of security on top of the other layers, and it comes for free, ie. it does not need any specific configuration on the device. I won’t mind added security for my devices.
Well I do that, and I wouldn’t even need a password at all. You simply set the IP’s that may access it in hosts.allow and deny all others.
Or use fail2ban and set good passwords.
I use both, but the last one just to see what idiots try to hack my server
Give it a go if you like: ssh sprintweb.be
It will disconnect you even before you can enter anything
BTW, it accepts root-password and let you enter. It just doesn’t accept unknown IP’s.
@avij, maybe you should explain the problem better
As there is no problem, apart from some people that seem to be unable to protect their server properly.
You can harvest IP’s almost everywhere, in fact even use them randomly.
Please stop making a mosquito into a elephant, as it’s not a pool problem.
Ok, fine. Trying to veer this discussion back to the actual topic now.
As for me, there are two reasons why I might want to connect back to the client or to collect IP addresses, namely diagnostics and abuse prevention. This is not specific to IPv6.
An example for diagnostics: One of my NTP servers is in Poland, and it appears that my provider there does not always have direct routes to destinations within Poland. It might be that the packets get routed through Amsterdam, for example. It is also possible that there’s asymmetry in routing, ie. requests to my server get routed directly, but the responses take a detour. This is suboptimal for NTP. I’ve been planning to collect a number of IP addresses (like 1000), check their geolocation status that they’re in Poland and then ping them to determine the RTT. If the client responds to ping and the RTT is higher than expected, I could then run a traceroute to the client to see which networks the packets go through. Armed with this knowledge, I could then ask the ISP if they could arrange better peering with AS xxx.
An example for abuse prevention: If something sends tons of NTP requests towards me, I would not feel too bad if I tried connecting to the client’s ports 22, 80 and 443 to see what the device might be running.
