Re: NTP Sync Issue Across Tata (Europe)

[Neil Hanlon <neil () shrug pw>]

This entirely discounts the fact that bcp-38 and bcp-84 which, more or
less, eliminate this "problem space" entirely.

I find it hard to believe ntp reflection is actually a problem in the year
2023, assuming you're not running a ridiculously old ntp client and have
taken really simple steps to protect your network.

On Sun, Aug 6, 2023, 15:42 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.