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
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…
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.
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.
@Bas Having not even glanced at the paper, I think I have a better grasp of the subject than you do.
Suppose Asshole A sets up a valid NTP server and attaches it to the pool for the purpose of getting Client Chums C0…Cn IPv6 address, which it then passes to Bastard Botnet Builder B, with the premise being that scanning the 260ish quadrillion[1] addresses in each of the septillionish[2] possible subnets is somewhat infeasible.
So, the researchers set up a Faker pretending to be IPv6 clients F0…Fn with pseudo-random addresses; each IPv6 pool server P0…Pn gets pinged from one address. Anything returned to F0…Fn other than ICMP or an NTP packet gets logged for possible action.
It would be great if all of the devices on the Internet had decent security, and we could economically disincentivize botnets, adware, and malware. It has not happened yet, and I will not hold my breath.
The worst security would probably be on fleets of stupid-little-boxes mostly built around open-source software and probably not well configured because people only care about cheap.
This will probably be the point where I get kicked, and Bas gloats.
And how should the pool process these reports?
Do you have any clue how much logging needs to be send to the pool, then processed to find the bastard.
You are talking about billions of requests a second, that have to be send back, compared to requests to find the few machines that ‘attack’ clients.
As from the starting point you do not know who the NTP-client-collector is, and you do not know the IP’s of the attacking network.
Meaning you must have ALL logging from ALL NTP-servers and their client-logs.
