r1 - 2008-06-06 - 21:21:29 - HeikoGerstungYou are here: NTP >  Dev Web > GoogleSummerOfCode > GSoC2008snmp > NtpSnmpStatusReport01 > GSoC2008NtpSnmpMileStone01
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.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

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.

Milestone #01: Define MIB Sections to be supported

The [NTPv4 MIB RFC draft contains a large number of data objects grouped into five sections (plus notification and compliance sections). Since the to-be-created SNMP MIB handler module needs to get the values for the MIB objects it covers from a running NTP instance (ntpd process), this milestone tries to discuss which MIB objects of the current draft can be covered easily by using mode 6 packets to query the NTP instance and determine which MIB objects cannot be covered at the moment because the information required for this is not retrievable due to missing support in ntpd. That allows us to identify what we need to add to ntpd in order to provide a way to retrieve the missing information (which is either already available within ntpd and is just not accessible through mode 6 requests OR which is not collected and/or stored within ntpd).

Section 1: General NTP Entity information objects

This MIB section provides relatively static information about the instance (entity) of NTP we are looking at. It basically offers a way to tell NTP clients and network monitoring systems (NMS) what specific implementation of NTP is running here. That is particularly useful to when it comes to deal with security bugs - to identify affected systems and fix them by updating to a newer version - or to go back to a version that is known to be safe.

ntpEntSoftwareName

  • Description: The product name of the installed NTP version

  • Get Info by:
    • mode 6 request to NTP instance, variable "product" OR
    • mode 6 request to NTP instance, variable "version" (start of string until first space)

ntpEntSoftwareVersion

  • Description: The software version of the installed NTP implementation (full version string, e.g. "ntpd-4.2.0b@1.1433 ...")

  • Get Info by:
    • mode 6 request to NTP instance, variable "version" (full string if no space included, otherwise everything after the first space)

ntpEntSoftwareVersionVal

  • Description: Software version of installed NTP as an unsigned integer value

  • Get Info by:
    • mode 6 request to NTP instance, variable "versionval" (atoi) OR
    • mode 6 request to NTP instance, variable "version" (parser translating e.g. 4.2.4p5 into 4245)

  • Remarks: Parser can have a hard time once we start to release 4.2.10p23 ...

ntpEntSoftwareVendor

  • Description: The vendor/author of the installed NTP version.

  • Get Info by:
    • mode 6 request to NTP instance, variable "vendor" (full string)

  • Remarks: Currently not provided by ntpd, should be added (e.g. vendor = "ntp.org" or something like that.

ntpEntSystemType

  • Description: General hardware/os platform information.

  • Get Info by:
    • mode 6 request to NTP instance, variable "systemtype" OR
    • mode 6 request to NTP instance, variable "system"

  • Remarks: ntpd already provides the "system" variable via mode 6, if a user wants to not reveal this information or use a different text, the "systemtype" variable can be defined from within ntpd.conf

ntpEntTimeResolution

  • Description: A string describing the time resolution of the running NTP implementation

  • Get Info by:
    • mode 6 request to NTP instance, variable "resolution"

  • Remarks: The MIB draft says that the resolution should reflect the resolution as limited by either the OS or the implementation, depending on which of these involved components supports the worst resolution. This information is currently not provided by ntpd (AFAIK), I therefore would opt for giving a rough estimate based on the OS and the product name (e.g. ntp.org ntpd on Linux) or let the user define in her/his ntpd.conf whatever she/he wants to show here.

ntpEntTimeResolutionVal

  • Description: The time resolution in integer format (shows the resolution based on 1 second, e.g. "1ms" translates to 1000)

  • Get Info by:
    • mode 6 request to NTP instance, variable "resolution", parsing any unit descriptor (e.g. us, ns, ms) OR
    • mode 6 request to NTP instance, variable "resolutionval"

ntpEntTimePrecision

  • Description: A string describing the precision with which the NTP entity implementation/OS manages its time base

  • Get Info by:
    • mode 6 request to NTP instance, variable "precision" (full string, already provided by ntpd)

ntpEntTimePrecisionVal

  • Description: The entity's precision in integer format

  • Get Info by:
    • mode 6 request to NTP instance, variable "precision" (atoi, already provided by ntpd)

ntpEntTimeDistance

  • Description: The distance from this NTP entity to the root time reference (stratum 0) source.

  • Get Info by:
    • mode 6 request to NTP instance, variable "rootdelay" (atoi, already provided by ntpd)


Section 2: Current NTP status (dynamic information)

This section contains status data which represents the operational status of the NTP instance and therefore will probably be the most popular set of objects in this MIB (if you count the queries coming from the management systems of the users).

ntpEntStatusCurrentMode

  • Description: The actual mode of NTP as a string, for possible strings see the RFC.

  • Get Info by:
    • mode 6 request to NTP instance, variable "status" (parsing/interpreting)

ntpEntStatusCurrentModeVal

  • Description: The actual mode of NTP as an integer, for possible values see the RFC.

  • Get Info by:
    • mode 6 request to NTP instance, variable "status" (parsing/interpreting)

ntpEntStatusStratum

  • Description: The NTP entity's own stratum value.

  • Get Info by:
    • mode 6 request to NTP instance, variable "stratum"

ntpEntStatusActiveRefSourceId

  • Description: The association ID of the current syspeer.

  • Get Info by:
    • mode 6 request to NTP instance, variable "peer"

ntpEntStatusActiveRefSourceName

  • Description: The hostname/descriptive name of the current reference source selected as syspeer, e.g. "ntp1.ptb.de" or "GPS" or "DCFi" ...

  • Get Info by:
    • mode 6 request to NTP instance, read syspeer association variable "srcadr"

ntpEntStatusActiveOffset

  • Description: The Time offset to the current selected reference time source as a string including unit, e.g. "0.032 ms" or "1.232 s"

  • Get Info by:
    • mode 6 request to NTP instance, variable "offset"

ntpEntStatusNumberOfRefSources

  • Description: The number of reference sources configured for NTP

  • Get Info by:
    • mode 6 request "list associations" and count

  • Remarks: Should probably be described as "number of associations currently mobilized", but that IMHO sounds a bit complicated to the average NTP user

ntpEntStatusDispersion

  • Description: The root dispersion of the running NTP entity."

  • Get Info by:
    • mode 6 request "rootdispersion"

ntpEntStatusEntityUptime

  • Description: The uptime of the NTP entity in seconds, i.e. time since ntpd was (re-)started (not sysUptime!)

  • Get Info by:
    • mode 6 request "uptime"

  • Remarks: Currently not provided as a variable but is maintained within ntpd because it is written to the sysstats logfile

ntpEntStatusDateTime

  • Description: The current NTP date/time on the device, in 128-bit NTP date format. Ref: draft-ietf-ntp-ntpv4-proto-06

  • Get Info by:
    • mode 6 request "reftime"

  • Remarks: See the RFC draft for comments on how to use this.

ntpEntStatusLeapSecond

  • Description: Date the next known leap second will occur. If there is no leap second announced then this object should be 0.

  • Get Info by:
    • mode 6 request "leapsecond"

  • Remarks: Currently not provided as a mode 6 variable (AFAIK), only a flag indicating a leap second announcement is provided. Information is already present within ntpd.

ntpEntStatusLeapSecDirection

  • Description: Direction of next known leap second. If there is no leap second announced then this object should be 0.

  • Get Info by:
    • mode 6 request "leapdirection"

  • Remarks: Currently not provided as a mode 6 variable (AFAIK), only a flag indicating a leap second announcement is provided. Information is already present within ntpd.

ntpEntStatusInPkts

  • Description: The total number of NTP messages delivered to the NTP entity from the transport service.

  • Get Info by:
    • mode 6 request "in_packets"

  • Remarks: Not sure if this is already collected within ntpd. There are packet stats written into a sysstats file, collection routines probably need to be added to ntpd.

ntpEntStatusOutPkts

  • Description: The total number of NTP messages delivered to the transport service by this NTP entity.

  • Get Info by:
    • mode 6 request "out_packets"

  • Remarks: Not sure if this is already collected within ntpd. There are packet stats written into a sysstats file, collection routines probably need to be added to ntpd.

ntpEntStatusBadVersion

  • Description: The total number of NTP messages which were delivered to this NTP entity and were for an unsupported NTP version.

  • Get Info by:
    • mode 6 request "bad_packets_version"

  • Remarks: Not sure if this is already collected within ntpd. There are packet stats written into a sysstats file, collection routines probably need to be added to ntpd.

ntpEntStatusProtocolError

  • Description: The total number of NTP messages which were delivered to this NTP entity and this entity was not able to process due to an NTP protocol error.

  • Get Info by:
    • mode 6 request "bad_packets_protocol"

  • Remarks: Not sure if this is already collected within ntpd. There are packet stats written into a sysstats file, collection routines probably need to be added to ntpd.

ntpEntStatusNotifications

  • Description: The total number of SNMP notifications which this NTP entity has generated.

  • Get Info by:
    • mode 6 request "notify_packets"

  • Remarks: This is not collected within ntpd. Would have to be added to ntpd.

ntpEntStatPktModeTable

  • Description: The number of packets sent and received by packet mode.

  • Get Info by:
    • mode 6 requests "packets_modeX" (X=each possible mode)

  • Remarks: This is not collected within ntpd and would have to be added.


Section 3: The status of all currently mobilized associations

This section represents the status of each currently mobilized association and could be considered to be the "SNMP version of the ntpq -p billboard". It includes two tables, one for the general information and status information like association name, refid, type, offset, stratum and so on and one for the association statistics which means packets coming in from and going out to each association, bad packets and so on.

ntpAssociationTable:

This table has one line for each mobilized association and the following columns:

  • ntpAssocId
  • ntpAssocName
  • ntpAssocRefId
  • ntpAssocAddressType
  • ntpAssocAddress
  • ntpAssocOffset
  • ntpAssocStratum
  • ntpAssocStatusJitter
  • ntpAssocStatusDelay
  • ntpAssocStatusDispersion

All these values are provided by the association variables and will be retrieved using mode 6 packets.

ntpAssociationStatisticsTable

This table provides information about traffic statistics for each association. The following columns are defined:

  • ntpAssocStatInPkts
  • ntpAssocStatOutPkts
  • ntpAssocStatProtocolError

I am not sure if any of these values are already collected by ntpd at the moment. I am missing the "reach" value in the MIB and will try to add one or two objects showing the current status of the association in terms of reachability and filter values.


Section 4: Control objects

The control ojects have been included in the MIB to allow users to configure the SNMP functionality of ntpd. At the moment I am not planning to implement them.

Section 5: Notification objects

This defines the "alarm" or "warning" messages that will be sent when specific events occur. They are known as "SNMP traps" and should probably be handled completely within ntpd. As far as I have seen, ntpd is already prepared to send traps and it would maybe only take a few steps to overhaul the trap generator and adopt the notifications as defined in the draft.

-- HeikoGerstung - 06 Jun 2008

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