ntp.log

Network Time Protocol (NTP) is another core protocol found in IP networks. NTP is a mechanism by which clients can adjust their local clocks to more closely match those of NTP servers. Many devices ship with NTP clients already configured to contact public NTP servers. Administrators can use Zeek logs to identify NTP clients and servers, and determine if they are operating as expected.

As with all entries in this document, for full explanation of each field in the log, see NTP::Info.

NTP via tcpdump

NTP is a request-response protocol, as demonstrated by the following exchange decoded by tcpdump:

00:29:07.927672 IP 192.168.4.49.38461 > 208.79.89.249.123: NTPv4, Client, length 48
00:29:07.995844 IP 208.79.89.249.123 > 192.168.4.49.38461: NTPv4, Server, length 48

Using the verbose feature, we see the following details:

00:29:07.927672 IP (tos 0x10, ttl 64, id 3186, offset 0, flags [DF], proto UDP (17), length 76)
    192.168.4.49.38461 > 208.79.89.249.123: [udp sum ok] NTPv4, length 48
        Client, Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3811105747.215585991 (2020/10/08 00:29:07)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3811105747.215585991 (2020/10/08 00:29:07)

00:29:07.995844 IP (tos 0x0, ttl 56, id 18045, offset 0, flags [DF], proto UDP (17), length 76)
    208.79.89.249.123 > 192.168.4.49.38461: [udp sum ok] NTPv4, length 48
        Server, Leap indicator:  (0), Stratum 2 (secondary reference), poll 3 (8s), precision -24
        Root Delay: 0.009216, Root dispersion: 0.021224, Reference-ID: 127.67.113.92
          Reference Timestamp:  3811105455.942204197 (2020/10/08 00:24:15)
          Originator Timestamp: 3811105747.215585991 (2020/10/08 00:29:07)
          Receive Timestamp:    3811105747.964280626 (2020/10/08 00:29:07)
          Transmit Timestamp:   3811105747.964314032 (2020/10/08 00:29:07)
            Originator - Receive Timestamp:  +0.748694635
            Originator - Transmit Timestamp: +0.748728040

A look at RFC 5905, explaining NTPv4, helps us understand the timestamps shown in the decoded output:

LI Leap Indicator (leap): 2-bit integer warning of an impending leap second
to be inserted or deleted in the last minute of the current month with values
defined in Figure 9.

           +-------+----------------------------------------+
           | Value | Meaning                                |
           +-------+----------------------------------------+
           | 0     | no warning                             |
           | 1     | last minute of the day has 61 seconds  |
           | 2     | last minute of the day has 59 seconds  |
           | 3     | unknown (clock unsynchronized)         |
           +-------+----------------------------------------+

                         Figure 9: Leap Indicator

VN Version Number (version): 3-bit integer representing the NTP version
number, currently 4.

Mode (mode): 3-bit integer representing the mode, with values defined in
Figure 10.

                      +-------+--------------------------+
                      | Value | Meaning                  |
                      +-------+--------------------------+
                      | 0     | reserved                 |
                      | 1     | symmetric active         |
                      | 2     | symmetric passive        |
                      | 3     | client                   |
                      | 4     | server                   |
                      | 5     | broadcast                |
                      | 6     | NTP control message      |
                      | 7     | reserved for private use |
                      +-------+--------------------------+

                       Figure 10: Association Modes

Stratum (stratum): 8-bit integer representing the stratum, with values
defined in Figure 11.

        +--------+-----------------------------------------------------+
        | Value  | Meaning                                             |
        +--------+-----------------------------------------------------+
        | 0      | unspecified or invalid                              |
        | 1      | primary server (e.g., equipped with a GPS receiver) |
        | 2-15   | secondary server (via NTP)                          |
        | 16     | unsynchronized                                      |
        | 17-255 | reserved                                            |
        +--------+-----------------------------------------------------+

                         Figure 11: Packet Stratum

Poll: 8-bit signed integer representing the maximum interval between
successive messages, in log2 seconds.

Precision: 8-bit signed integer representing the precision of the system
clock, in log2 seconds. For instance, a value of -18 corresponds to a
precision of about one microsecond.

Root Delay (rootdelay): Total round-trip delay to the reference clock, in NTP
short format.

Root Dispersion (rootdisp): Total dispersion to the reference clock, in NTP
short format.

Reference ID (refid): 32-bit code identifying the particular server or
reference clock.

Reference Timestamp: Time when the system clock was last set or corrected, in
NTP timestamp format.

Origin Timestamp (org): Time at the client when the request departed for the
server, in NTP timestamp format.

Receive Timestamp (rec): Time at the server when the request arrived from the
client, in NTP timestamp format.

Transmit Timestamp (xmt): Time at the server when the response left for the
client, in NTP timestamp format.

Destination Timestamp (dst): Time at the client when the reply arrived from
the server, in NTP timestamp format.

It makes sense that the reference, originator, and receive timestamps would be zero in the client request, but non-zero in the server reply.

NTP via tcpdump and tshark

Let’s look at tshark’s decode for the NTP-specific data, to see if tcpdump missed anything:

Client to server:

Network Time Protocol (NTP Version 4, client)
    Flags: 0x23, Leap Indicator: no warning, Version number: NTP Version 4, Mode: client
        00.. .... = Leap Indicator: no warning (0)
        ..10 0... = Version number: NTP Version 4 (4)
        .... .011 = Mode: client (3)
    Peer Clock Stratum: unspecified or invalid (0)
    Peer Polling Interval: invalid (0)
    Peer Clock Precision: 1.000000 sec
    Root Delay: 0 seconds
    Root Dispersion: 0 seconds
    Reference ID: NULL
    Reference Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Origin Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Receive Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Transmit Timestamp: Oct  8, 2020 00:29:07.215585991 UTC

Server to client:

Network Time Protocol (NTP Version 4, server)
    Flags: 0x24, Leap Indicator: no warning, Version number: NTP Version 4, Mode: server
        00.. .... = Leap Indicator: no warning (0)
        ..10 0... = Version number: NTP Version 4 (4)
        .... .100 = Mode: server (4)
    Peer Clock Stratum: secondary reference (2)
    Peer Polling Interval: invalid (3)
    Peer Clock Precision: 0.000000 sec
    Root Delay: 0.00921630859375 seconds
    Root Dispersion: 0.0212249755859375 seconds
    Reference ID: 127.67.113.92
    Reference Timestamp: Oct  8, 2020 00:24:15.942204197 UTC
    Origin Timestamp: Oct  8, 2020 00:29:07.215585991 UTC
    Receive Timestamp: Oct  8, 2020 00:29:07.964280626 UTC
    Transmit Timestamp: Oct  8, 2020 00:29:07.964314032 UTC

It does not appear that tshark reveals any details that tcpdump did not. One difference is that for the client reference, origin, and receive timestamps, Tshark renders the 0 values as the Unix epoch, i.e., Jan  1, 1970 00:00:00.000000000 UTC.

NTP via Zeek

Here is how Zeek summarizes this NTP activity:

{
  "ts": "2020-10-08T00:29:07.977170Z",
  "uid": "CqlPpF1AQVLMPgGiL5",
  "id.orig_h": "192.168.4.49",
  "id.orig_p": 38461,
  "id.resp_h": "208.79.89.249",
  "id.resp_p": 123,
  "version": 4,
  "mode": 3,
  "stratum": 0,
  "poll": 1,
  "precision": 1,
  "root_delay": 0,
  "root_disp": 0,
  "ref_id": "\\x00\\x00\\x00\\x00",
  "ref_time": "1970-01-01T00:00:00.000000Z",
  "org_time": "1970-01-01T00:00:00.000000Z",
  "rec_time": "1970-01-01T00:00:00.000000Z",
  "xmt_time": "2020-10-08T00:29:07.215586Z",
  "num_exts": 0
}

{
  "ts": "2020-10-08T00:29:08.081209Z",
  "uid": "CqlPpF1AQVLMPgGiL5",
  "id.orig_h": "192.168.4.49",
  "id.orig_p": 38461,
  "id.resp_h": "208.79.89.249",
  "id.resp_p": 123,
  "version": 4,
  "mode": 4,
  "stratum": 2,
  "poll": 8,
  "precision": 5.960464477539063e-08,
  "root_delay": 0.00921630859375,
  "root_disp": 0.0212249755859375,
  "ref_id": "127.67.113.92",
  "ref_time": "2020-10-08T00:24:15.942204Z",
  "org_time": "2020-10-08T00:29:07.215586Z",
  "rec_time": "2020-10-08T00:29:07.964281Z",
  "xmt_time": "2020-10-08T00:29:07.964314Z",
  "num_exts": 0
}

By looking at the mode field in each log, we see that the first entry is a NTP client request (mode 3), and the second is the server’s reply (mode 4).

These log entries make an interesting comparison with those for DHCP. Zeek’s DHCP logs seek to summarize potentially up to four individual datagrams (for the DORA exchange) into one log entry. In contrast, Zeek’s NTP logs create an entry for each NTP message.

Identifying NTP Servers

As with DHCP servers, Zeek can help identify NTP servers used by clients. The following query shows a subset of systems and the NTP servers they have queried:

$ find . -name "ntp**.gz" | while read -r file; do zcat -f "$file"; done | jq -c '[."id.orig_h", ."id.resp_h"]' | sort | uniq -c | sort -nr | head -10
570 ["192.168.4.48","193.0.0.229"]
271 ["192.168.4.76","91.189.91.157"]
271 ["192.168.4.76","216.229.0.50"]
270 ["192.168.4.76","74.6.168.73"]
270 ["192.168.4.76","72.30.35.88"]
270 ["192.168.4.76","38.229.71.1"]
216 ["192.168.4.149","84.16.73.33"]
206 ["192.168.4.48","50.205.244.21"]
164 ["192.168.4.57","216.239.35.12"]
162 ["192.168.4.57","216.239.35.8"]

The following query summarizes only the NTP servers seen by Zeek:

$ find . -name "ntp**.gz" | while read -r file; do zcat -f "$file"; done | jq -c '[."id.resp_h"]' | sort | uniq -c | sort -nr | head -10
570 ["193.0.0.229"]
470 ["17.253.20.253"]
468 ["17.253.20.125"]
357 ["91.189.91.157"]
287 ["216.229.0.50"]
286 ["74.6.168.73"]
276 ["72.30.35.88"]
270 ["38.229.71.1"]
221 ["84.16.73.33"]
206 ["50.205.244.21"]

Security and network administrators can use queries like this to identify systems that are polling unauthorized NTP servers.

Conclusion

NTP is an important protocol for modern network administration. Without accurate clocks, many systems will not be able to complete cryptographic exchanges. Be sure systems are kept up to date using the NTP servers you expect them to query.