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.