NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p15
was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
See ProxiesTunnelsAndVPNsDev for discussion of this topic.
2. Proxies, Tunnels, and VPNs
Proxies, Tunnels, and VPNs -- Oh, My!
Proxies, Tunnels, and VPNs -- Oh, My!
Shamelessly stolen from The Wizard of Oz.
Table of Contents
2.1. UDP vs. TCP
Most proxies and tunnels support only TCP/IP protocols -- i.e., protocols that require setting up a relatively long-lived connection, doing buffering, handling two-way communications, dealing with packet loss, retransmissions, and re-ordering, etc....
However, NTP is inherently a UDP/IP protocol. This has been done for a variety of reasons, but one of the most important is that TCP is ... well ... TCP, and it would be impossible for a program to accurately determine the true delay between two given systems with such a heavy protocol. It would be impossible for a program to create or maintain an accurate system clock based on external input from other machines across a TCP/IP network.
2.2. Proxies and Tunnels
Unless you can guarantee that your proxy or tunnel supports UDP as well as TCP packets, you're not going to get it to carry NTP. One tunnel that is believed to be capable of carrying UDP traffic is
rq2proxy. However, configuring a tunnel or proxy to carry UDP and support NTP is an exercise left to the reader.
Some proxies or tunnels require compiling and/or linking with an alternative networking library, in order to get your binary to transmit your packets across their alternative network connection (e.g., SOCKS). Compiling and/or linking
ntpd
and all related utilities to support such an alternative network connection is another exercise left to the reader.
2.2.1. ssh
Tunnels
If all you've got is an
ssh
tunnel to a remote server and you want to try to sync the time across that tunnel, then NTP is not the protocol you should be looking at. Try
rdate
or
daytime
instead.
Note that these are much less accurate and precise than NTP, and do not have any of the features for detecting
falsetickers or selecting
truechimers, etc.... But, they are programs/protocols that use TCP, and you should be able to get them to work over an
ssh
tunnel without too much trouble.
2.3. VPNs
VPNs (Virtual Private Networks) are a different kind of beast. By definition, they attempt to provide a complete alternative network solution, and should carry all types of IP packets, including TCP and UDP.
You will likely suffer higher jitter and reduced clock accuracy/precision, but once you get the underlying network up and running, it should not be too difficult to get NTP working across that network -- after all, NTP is about as simple as an UDP protocol can get.
--
BradKnowles - 03 Mar 2005