Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl <rubensk () gmail com>]

The paper suggests the compromise of critical infrastructure. So, besides
not using NTP, why not stop using DNS ? Just populate a hosts file with all
you need.

BTW, the stratum-0 source you suggested is known to have been manipulated
in the past (https://www.gps.gov/systems/gps/modernization/sa/), so you
need to bet on that specific state actor not returning to old habits.

OTOH, 4 of the 5 servers I suggested have their own atomic clock, and you
can keep using GPS as well. If GPS goes bananas on timing, that source will
just be disregarded (one of the features of the NTP architecture that has
been pointed out over and over in this thread and you keep ignoring it).

Rubens



Rubens



On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman <mel () beckman org> wrote:

> Or one can read recent research papers that thoroughly document the
> incredible fragility of the existing NTP hierarchy and soberly consider
> their recommendations for remediation:
>
> [image: preview.png]
>
> ndss2021_1A-2_24302_paper
> <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf>
> PDF Document · 1.7 MB
> <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf>
>
> <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf>
>
> Or simply use non-Internet NTP servers based on a Stratum-0 GPS source for
> mission-critical network timing.
>
> Until then, we may all wake up one morning and discover massive data
> breaches traced to an unfounded reliance on insecure public NTP servers.
> Then the game truly will be over, but not in our favor.
>
>  -mel
>
> On Aug 6, 2023, at 2:35 PM, Rubens Kuhl <rubensk () gmail com> wrote:
>
> Or one can select NTS-capable NTP servers, like those 5:
> a.st1.ntp.br
> b.st1.ntp.br
> c.st1.ntp.br
> d.st1.ntp.br
> gps.ntp.br
>
> Or any other NTP server that has NTS deployed. Game-over for NTP
> impersonation.
>
>
> Rubens
>
> On Sun, Aug 6, 2023 at 4:41 PM 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#
>
>
>
> -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.