Re: NTP Sync Issue Across Tata (Europe)

[Royce Williams <royce () techsolvency com>]

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 <mel () 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 <royce () 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 <mel () 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.