r5 - 2007-02-25 - 08:09:02 - HarlanStennYou are here: NTP >  Dev Web > DevelopmentIssues > NtpdProcessResidencyIssues
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.

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.8 which was released on 18 December 2014.

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

NTF needs your help to qualify to participate in the Combined Federal Campaign so we can continue our mission to improve Network Time. We only need a few thousand dollars more by December 31st - any sized donation helps! Please join an NTF Consortium or make a donation to NTF now! THANKS!

ntpd Process Residency Issues

Introduction

In general, it is best for ntpd to get time packets with the smallest possible latency on the receive timestamp.

Over the years we have learned that on some (versions of some) OSes we can obtain better results with ntpd through the use of techniques like:

  • using a non-default scheduling priority
  • locking the process in memory
  • keeping sections of memory permanently resident

Originally, there was no ability to use any of these mechanisms to improve the performance of ntpd. As they became available we added existence checks to configure.ac so we could use these features if they were available.

As OS technology has matured, newer kernels have developed better ways to obtain the receive timestamp, and techniques like memory locking under these kernels have new problems or unexpected consequences or behaviors.

The previous memory locking (for example) interfaces are still provided for backward compatibility, but now there are times where they should no longer be used.

Related Bugs

Moving forward

  • If SO_TIMESTAMP exists:
    • we do not need to use (any of?) these techniques to get better receive timestamps.
    • Are there any other reasons to use any of these techniques?
      • Yes, refclocks (other than LOCAL) have no timestamp capability, so prio/mlock is useful for them.
      • So, if no refclocks (other than LOCAL) are used then there is no need for prio/mlock.
      • Also, possibly even with refclocks, if kernel stream module used.

Also see: LockingNtpdInMemory

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r5 < r4 < r3 < 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-2014 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