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. See JavaSntpClientDev for discussion of this topic.
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.
13.3. Java SNTP Client
This is a Java implementation of an NTP client, and is released under the GPL license. It handles NTP parameters as native Java types, making it Java-programmer-friendly. The algorithm used to calculate the local clock offset is the SNTP algorithm as specified in RFC2030. However, this code may be easily updated to use the more complex RFC 1305 NTP algorithms with no change to NtpMessage class.
The Java implementation consists of the following two classes:
Represents an NTP message, exposing members as native java types. Include a
NtpMessage(byte array) constructor to import a raw NTP message, and a
toByteArray() method to export a raw NTP message.
File like the original "NtpMessage.java" adjustments made in order to reconcile the class to run on embedded devices with J2ME .
NTP client which instances an NtpMessage and uses the SNTP algorithm to calculate local clock offset. Note that this class merely performs the NTP process and displays the results - it does not actually modify the system clock.
This implementation is a first attempt, and is possibly naïve in its approach. In particular, it is subject to the following issues:
SntpClient.java determines the current time of day using
System.currentTimeMills(). Firstly, the value returned is of millisecond accuracy. How accurate should the client timestamps be? Secondly, under Win32 the value is limited to a precision of 10ms. What impact does this have on precision?
- Timestamps are maintained as
double values. Timestamps are converted from fixed point format to double during NtpMessage creation and back to fixed point format again during
toByteArray(). How much error does this introduce?
- 22 Jan 2004