r2 - 2007-01-17 - 16:15:23 - SteveKosteckeYou are here: NTP >  Support Web > ConfiguringNTP > AccessRestrictions > AccessRestrictionsDev
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.8p10 was released on 21 March 2017. It addresses 6 medium- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
AccessRestrictions needs a section dealing with adding restrict lines for time sources such as unicast, multicast and broadcast servers.

-- SteveKostecke - 10 May 2005

Problems with 'notrust' option on a LAN

Recently I've added an NTP server to my local network to maintain consistent time on each machine. Some problems arose as none of the systems on the local network were recieving replies from the local time server. By running all the servers in debug mode, it was apparent that requests were being sent out, and were also being received by the server, though no replies were being returned. This eventually led to frustration as any available discussions on similar topics that were found on Google seemed to suggest using the notrust configuration option, which ultimately was the cause of the problem in the first place. Here as an example of the working configuration file currently in use:

# Our time servers
server ntp1.example.invalid iburst
server ntp2.example.invalid iburst

# Ignore all NTP connections by default
restrict      default ignore

# Give full accessiblity to the local host
restrict 127.0.0.1

# Give full accessiblity to the two servers listed above.
# (use IP instead of domain name)
# NOTE: these IP address are *not* valid time servers
restrict 10.1.0.23
restrict 10.1.0.24

# Give accessiblity to the internal network, but don't let them change
# the settings of our NTP server.
restrict 192.168.1.0 mask 255.255.255.0 nomodify

# Set driftfile.
driftfile /etc/ntp/drift

Of particular interest here is the restrict line for the local network, 192.168.1.0/24. This is where most discussions found with Google suggested using the notrust option. When this option was enabled in the current configuration, replies were no longer returned to any local client making a request, and instead requests were simply dropped by the server. It seems a minor configuration option, but if others are having the same issue I hope this will provide some insight.

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback