Safeguards against pool poisoning/abuse/exploitation

Hi,

I was wondering if there are any existing/recommended mechanisms/protocols/procedures to prevent malicious attackers to add malicious ntp servers to a pool in case of a zero-day exploit in either the client or server code. What is the normal procedure to detect and remove such malicious servers from existing public ntp pools? Or prevent them from being added in the first place?

Reason for my question is that I’ve been doing some digging, and of the +/- 650 ntp servers that I found in an existing NTP pool, around 35 (i.e. roughly 5%) of them were listed at AbuseIPDB with a 100% malicious status. Now most of these are probably ‘abused’ TOR exit nodes. But what in the case of an actual exploitable bug in ntp client/server code. Would a malicious attacker be able to abuse such an exploit by poisoning existing ntp pools with malicious IPs?

1 Like

Hi and welcome.

I think it depends what you mean by “a malicious ntp server”.

The pool checks that a server is consistently providing accurate time on port 123. If it is then it gets added to the pool. If it’s not then it doesn’t. AFAIK it’s not interested in anything else the server may or may not be doing.

They could be flagged because they are a shared host, or like you said a TOR exit node, in which case the anonymous traffic could be doing bad things. You would have to look at the IPDB logs yourself and make that determination.

As elljay said, there is a monitor server which is constantly querying time to ensure that the server is delivering accurate time, and if it is too far off, or doesn’t respond, then it gets pulled from rotation very quickly.

As for “exploits”… That’s a loaded question since it is so very vague, and since there are numerous NTP packages in use, all of which have very different code bases…

The whole point of having multiple NTP servers listed is so that no one source can tell you what time it is.

The general rule of thumb is for 2n+1 servers to protect against “n” falsetickers. Five upstreams will protect you against two falsetickers, seven will protect you against three falsetickers, etc…

With most people’s default configuration of four servers, you are really only protected against losing one server (either with bad time or it stops responding). As soon as you lose a second server, then all bets are off. With many distro’s out there still running older versions of NTPD that don’t have the ‘pool’ directive implemented, they can’t refresh a server if it goes stale.

Bandwidth is cheap, and NTP packets are extremely small and sent at long intervals, so the difference in bandwidth between having 4 servers listed, and having 7 servers is more of less non-existent. Yet the redundancy you gain is priceless…

I always try to use a mix of pool servers, ISP NTP servers, and other public servers (Apple & Cloudflare to name a couple.) You never want to trust one source if time is of critical importance.

Absolutely. I’ve got a local GPS receiver for my home network of a handful of machines but I also have my ISP and three other servers in my config file just in case.

I’m just going to point at pool.ntp.org: How do I setup NTP to use the pool?, say “hmm” and quickly run away :stuck_out_tongue:

You can stop bad people by using fail2ban and let its monitor logs.
However, if you use it too tight it may stop the monitor and your system can’t be reached.
Fail2ban is very effective against attackers that try to hack/abuse your system.
I do know a few NTP-servers that use it against people that poll their NTP too often.

Hi @tofusp,

We have sometimes done projects to look for specific behaviors on servers and I’ve from time to time worked with researchers doing that sort of work.

If there’s a client vulnerability then yes, it’d definitely be a HUGE problem for the internet in general.

Depending on the specific problem the pool system might be able to help because not having IPs hardcoded we at least have some mitigation options in helping how clients are directed (for example: lock down adding new servers to the system and we could run probes on the existing servers to find any abusing the system and removing them).

The general attitude we’ve had is that the pool system just checks if the server is serving accurate time in correct NTP responses and not what other attributes the server might have that we might or might not be able to know anyway (does it run a mail server, VPN? Is it stratum 1 or 2? Is it in a data center or on a cable modem?).

I’m planning to add options for vendor zones to exclude servers that are in lists such as the one you mentioned, but it wouldn’t be the default option.