Only the server operator can define what abuse is. Operating a server in the pool is proving to be a liability to me, exposing my resources to frequent abuse. It’s probably time to leave the pool.
1 Like
I think your definition of abuse is much too low to be realistic. I would say if providing quality NTP service to the pool is so abusive to your network then it’s probably not right for you.
3 Likes
There are many reasons for the monitor IP’s to not be public. Besides possible DOS attacks there is just the simple possibility of monitor traffic being treated different which defeats the whole purpose of monitoring. If you treat the monitors different to get good scores to be in the pool but then don’t treat the pool traffic the same, it doesn’t help the pool at all.
3 Likes
Abuse is a lot of clients that make your system go into DDOS mode or so.
Most clients behave.
However, the ammount of traffic can become a problem for some.
All my systems have unlimited traffic but I limit them via the NTP-pool system, works well, but still clients can ‘abuse’ it.
If the load is too high for you, then you should not join the pool.
To give an idea of a normal load, look at my Belgian friend in the University of Leuven:
He serves about 14000 clients constantly.
No clue what I serve, never checked it, but it’s a lot.
As I said, there is frequent abuse, not that regular use is a burden, on the contrary, even with thousands of clients. As a matter of fact, the pool is a prime target for hacking exploits. Not always, but, when it happens, it requires immediate attention. Given the severity of the attacks, though infrequent, I put in place measures to mitigate them based on the past patterns that make sense considering my resources. Your resources likely differ, but no one can tell me what my threshold should be with complete lack of knowledge of my particular situation.
Since participating in the pool became more of a liability for me, I ended my participation of more than a decade.
If you don’t mind, what do you mean? Who’s getting hacked? With what sort of exploits?
1 Like
Besides the usual bad behaved clients that storm NTP, there are other more malicious actors. The amplification attack using NTP a few years ago was a foretaste of it, which used the pool as a source to harvest the addresses of potential targets.
Examining the logs, i came across other instances of baddies possibly using the pool to find their targets.
For instance, I’ve once noticed the same abusive NTP client probing other common ports and attempting common vectors at those facing outside. Looking back in the log history, I’ve found similar attacks, sometimes not from a single address, but from addresses in the same subnet. All that it takes for a breach then is a convenient zero day attack.
Of course, any server open to the outside world is vulnerable, but the pool may just be a quite convenient way to harvest the addresses of potentially valuable targets.
This is something that happens regardless if you’re part of the pool or not. It loos like an easier approach to use the pool at first glance, but scanning the whole IPv4 internet for a single port takes less than 15 minutes on a 1 Gbps line.
So this basically only proves, that a system that scans your system is also using the NTP pool.
Or the same home / CGNAT network has clients that use your pool and also, probably infected, clients that scan systems on the internet.
I beg to differ. Do you want to see the amount of portscan traffic (“background noise”) I receive on a completely unused /24 ?
The whole internet is scanned all the time and it takes more effort to find presumably “valuable” targets.
To simply scan the internet or using search engines like shodan.io is faster than trying to harvest through the NTP pool.
4 Likes
As soon as i removed a server from the pool, it wasn’t probed anymore after just a couple of days. As a norm, I do not have any service on IPv4, but only on IPv6, which is infeasible to scan. However, the pool is a convenient source of both IPv4 and IPv6 addresses, which is cheaper to obtain than scanning address ranges all over the world with latency of over 100ms each probe.
That is right, IPv4 and IPv6 are quiet different in respect of harvesting target adresses. My experience is the following: as I put the IPv6 address of the device in the DNS reverse zone ip6.arpa, soon the scanning of the device started. Since then, I do not put any more client IPv6 addresses into the DNS reverse zone.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.