Respectfully, that Wikipedia article (which is mostly about legit but unauthorized clients overwhelming a given peer) and your cites don't seem to cover what I was responding to - the "don't peer with public NTP because someone can flood your firewall and spoof the responses" problem. I just want to make sure that I'm understanding the distinction betwen this class and other classes of attack.
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? 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). And I'm well aware of who I'm saying this to ... so I expect to find out where I'm wrong, as I keep digging. :D -- Royce On Sun, Aug 6, 2023 at 11:40 AM Mel Beckman <m...@beckman.org> wrote: > In a nutshell, no. Refer to my prior cites for detailed explanations. For > a list of real-world attack incidents, see > > https://en.m.wikipedia.org/wiki/NTP_server_misuse_and_abuse# > <https://en.m.wikipedia.org/wiki/NTP_server_misuse_and_abuse#:~:text=NTP%20server%20misuse%20and%20abuse%20covers%20a%20number%20of%20practices,the%20NTP%20rules%20of%20engagement.> > > > -mel > > On Aug 6, 2023, at 12:03 PM, Royce Williams <ro...@techsolvency.com> > wrote: > > > Naively, instead of abstaining ;) ... isn't robust diversity of NTP > peering a reasonable mitigation for this, as designed? > > Royce > > On Sun, Aug 6, 2023 at 10:21 AM Mel Beckman <m...@beckman.org> wrote: > >> William, >> >> Due to flaws in the NTP protocol, a simple UDP filter is not enough. >> These flaws make it trivial to spoof NTP packets, and many firewalls have >> no specific protection against this. in one attack the malefactor simply >> fires a continuous stream of NTP packets with invalid time at your >> firewall. When your NTP client queries the spoofed server, the malicious >> packet is the one you likely receive. >> >> That’s just one attack vector. There are several others, and all have >> complex remediation. Why should people bother being exposed to the risk at >> all? Simply avoid Internet-routed NTP. there are many solutions, as I’ve >> already described. Having suffered through such attacks more than once, I >> can say from personal experience that you don’t want to risk it. >> >>
