Bill, You’re mistaking targeted NTP attacks with global ones. Yes, to attack your specific NTP client, the attacker has to know which NTP servers you’re using. But to simply succeed at random attacks, the attacker need only spoof popular servers. This is how time-shifting attacks work. Once an attack succeeds with a random victim, the hacker goes to work compromising time-sensitive security services. And don’t forget that anyone can join pool.ntp.org. Including hackers. There is no credentialed vetting process. -mel
On Aug 6, 2023, at 4:30 PM, William Herrin <bill@herrin.us> wrote:
On Sun, Aug 6, 2023 at 1:19 PM Royce Williams <royce@ .com> wrote:
Wouldn't a robust implementation of peering - say, seven peers, with the NTP algorithm handily selecting a subset to peer with for each cycle - require an attacker to know and overwhelm not just one, but a majority of the peer IPs?
Hi Royce,
More or less, yes. There are some corner cases where that may not be true, but in terms of designing a useful attack, the attacker has to be able to figure out which NTP servers you're talking to, flood you with enough packets forged from all of them that the forged packet arrives ahead of the real one, generally no more than 10s of milliseconds behind the sent packet that only happens once every 15 minutes or so. And then it has to move you off real time gradually enough for the NTP daemon not to decide the peer has become a false ticker.
It's like DNS cache poisoning but a few orders of magnitude harder.
This is *not* to say that I'm advocating against maintaining local stratum 0s as part of a proper operator-grade NTP mesh. (My definition of "robust implementation" would include both local stratum 0 and a healthy serving of Internet stratum 1s). I'm just suggesting "don't peer with public servers" seems draconian given the deliberate design choices of the protocol.
For this audience, this would recommend a tiered system where multiple mixed-stratum internal stratrum 0+1s would peer with each other, and maintain internal-facing consensus for all other downstream internal devices - such that the vast majority of internal peers would indeed not be talking to the public Internet (but the "parent" peers would, and have the mesh and mix that I describe).
Well, it's not really one-size-fits-all.
Some systems consist of a well defined network containing routers and servers with clear boundaries between self and Internet. Your approach would work well there.
Some systems consist of equipment scattered at various data centers, interconnected by the Internet itself. Implementing a GPS time receiver at every one could get very expensive very fast. Standard security rules apply: don't spend more protecting yourself than the risk-cost. Risk is threat times vulnerability. Given the complexity of the attack, you have to consider whether you're enough of a target (threat) for anyone to bother.
Some systems are heavily virtualized, scattered over many vendors and locations. You could -try- to track down a "secured" NTP source from the vendor at each location, but that way lies configuration insanity.
Some systems are air-gapped from the Internet. You're going to get time from GPS or the cellular phone network. GPS devices like the one Mel pointed out are probably cheaper and more accurate.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/