NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to use in a distributed denial-of-service (DDoS) attack. Please also take this opportunity to defeat denial-of-service attacks by implementing ingress and Egress filtering through BCP38.
The final two security bugs reported by Google's Security Team have been fixed as of ntp-4.2.8p1.
A new set of mode 6 vulnerabilities has been discovered and, while these vulnerabilities can be reduced by making sure you have
restrict default … noquery in your
ntp.conf file, the best and most complete way to avoid these vulnerabilities is to install and deploy
ntp-4.2.8p1 which was released on 04 February 2015.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
The Synchronization Status of
There is a need to be able to easily and consistently determine if
system clock and/or
's idea of its internal state and the system
clock are "correct" (for some definition of correct).
To offer this ability, it seems to me that the first thing we need to
nail down is the definition and specification of "correct".
The definition of 'correct' time
How about the following:
- The decoded system status bits contain
ntpd is in state
S_SYNC (which Dave is renaming to
- any slew adjustment in-process is under X (where X is configurable)
- Do we care about the root dispersion?