======= 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 chapter, see :zeek:see:`NTP::Info` for full explanation of each field in the log. NTP via :program:`tcpdump` ========================== NTP is a request-response protocol, as demonstrated by the following exchange decoded by :program:`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 :program:`tcpdump` and :program:`tshark` ================================================ Let’s look at :program:`tshark`’s decode for the NTP-specific data, to see if :program:`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 :program:`tshark` reveals any details that :program:`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: .. literal-emph:: { "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: .. code-block:: console $ 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: .. code-block:: console $ 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.