“The Network Time Protocol (NTP) is a protocol for distributing the Coordinated Universal Time (UTC) by means of synchronizing the clocks of computer systems over packet-switched, variable-latency data networks.” –Wikipedia
Why is NTP important?
“Time is inherently important to the function of routers and networks. It provides the only frame of reference between all devices on the network. This makes synchronized time extremely important. Without synchronized time, accurately correlating information between devices becomes difficult, if not impossible. When it comes to security, if you cannot successfully compare logs between each of your routers and all your network servers, you will find it very hard to develop a reliable picture of an incident. Finally, even if you are able to put the pieces together, unsynchronized times, especially between log files, may give an attacker with a good attorney enough wiggle room to escape prosecution.” –Thomas Akin, in Hardening Cisco Routers.
NTP provides us (the network, systems, and security guys) with an easy way to ensure that all of our network devices have the same time. In smaller networks, this is desirable; in large networks, it is a must. In this lab, we’ll configure one Cisco router as both a client (synchronizing time from hosts on the Internet) and server (providing time synchronization to other internal devices).
Our physical topology looks like this:
For our demonstration, R1 will be both an NTP client and NTP server while R2 will only be an NTP client. Because we will be synchronizing R1’s time with a host on the Internet, R1 will need connectivity to the Internet for this demonstration; R2 will not. R1’s actual connectivity to the Internet is irrelevant and out of the scope of this demonstration.
- R1 will synchronize time against nist.netservicesgroup.com (220.127.116.11).
- R2 will synchronize time against R1 (172.16.12.1).
- NTP synchronization between R1 and R2 will be authenticated, using a key of “ThereIsTimeForEverything“.
Configuring R1 as an NTP client
Before we get started, I first want to show that we currently have an unsynchronized clock:
R1# show clock detail *00:01:19.099 UTC Fri Mar 1 2002 No time source R1#
Configuring a Cisco router to act as an NTP client is extremely simple. We’ll use the “ntp server” command, followed by the IP address of the NTP server:
R1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)# ntp server nist.netservicesgroup.com Translating "nist.netservicesgroup.com"...domain server (192.168.1.12) [OK] R1(config)#
That’s about all there is to it, from the client side. Note that if you do not have DNS configured on your devices, you’ll need to use IP addresses instead of fully qualified domain names (above). If we take a look at our clock, we’ll see that the time has been updated from NTP:
R1# show clock detail 03:15:52.593 UTC Sun Nov 23 2008 Time source is NTP
Let’s verify our NTP associations and status:
R1# show ntp associations address ref clock st when poll reach delay offset disp *~18.104.22.168 .ACTS. 1 45 64 17 36.2 -2.90 1901.2 * master (synced), # master (unsynced), + selected, - candidate, ~ configured
R1# show ntp status Clock is synchronized, stratum 2, reference is 22.214.171.124 nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18 reference time is CCD34DAA.B4D97B06 (03:34:02.706 UTC Sun Nov 23 2008) clock offset is -2.8967 msec, root delay is 36.16 msec root dispersion is 909.03 msec, peer dispersion is 906.13 msec
Note that the synchronization process could take up to five minutes. If you see “Clock is unsynchronized” in the output of “show ntp status”, wait a moment and run the command again. If you so desired, you could use “debug ntp events” to watch the communications and see what is happening. Make sure that R1 becomes synchronized before beginning to configure R2 — a device providing NTP services will not do so until the device itself is fully synchronized.
Configuring R1 as an NTP server
Configuring R1 to act as an NTP server is easy enough — it’s already done! As soon as R1 becomes synchronized, it will automatically begin answering NTP requests from other hosts. This is why access lists are important; we’ll cover those in a later lab.
Configuring R2 as an NTP client
Now we’ll configure R2 as an NTP client, just as we did with R1. Let’s first show that our clock is unsynchronized, then configure R2 to synchronize with R1:
R2# show clock detail *02:16:24.771 UTC Fri Mar 1 2002 No time source
R2# configure terminal Enter configuration commands, one per line. End with CNTL/Z. R2(config)# ntp server 172.16.12.1
After a moment, we should see that R2 is now successfully synchronizing time with R1:
R2# show clock detail 04:17:06.271 UTC Sun Nov 23 2008 Time source is NTP R2# show ntp associations address ref clock st when poll reach delay offset disp *~172.16.12.1 126.96.36.199 2 17 64 377 35.9 2.41 7.8 * master (synced), # master (unsynced), + selected, - candidate, ~ configured R2# show ntp status Clock is synchronized, stratum 3, reference is 172.16.12.1 nominal freq is 250.0000 Hz, actual freq is 250.0001 Hz, precision is 2**18 reference time is CCD357B6.5807B0D4 (04:16:54.343 UTC Sun Nov 23 2008) clock offset is 2.4103 msec, root delay is 55.85 msec root dispersion is 261.81 msec, peer dispersion is 7.80 msec
Configuring NTP Authentication
As of now, we have time synchronization working between R1 and an external NTP server and between R1 and R2. Our security policy, however, dictates (hypothetically, of course) that NTP traffic between hosts inside our network must be authenticated. (For additional security, we would use authentication for requests between R1 and the external NTP server as well.)
It is important to note that configuring authentication doesn’t require clients to use authentication — it merely enables them to do so. Our NTP servers will still answer requests that are not authenticated, so we’ll want to use access lists to control access as well (coming in the next lab).
Our first step in turning on authentication is to enable it on R1. Recall from above that we’re going to use the key “ThereIsTimeForEverything” (bonus points for the first person to leave a comment below telling me who that quote is from!):
R1# configure terminal R1(config)# ntp authenticate R1(config)# ntp authentication-key 10 md5 ThereIsTimeForEverything R1(config)# ntp trusted-key 10
Likewise, we must configure the same authentication key on R2 and instruct it to use that key when “speaking” NTP to R1:
R2# configure terminal Enter configuration commands, one per line. End with CNTL/Z. R2(config)# ntp authenticate R2(config)# ntp authentication-key 10 md5 ThereIsTimeForEverything R2(config)# ntp trusted-key 10 R2(config)# ntp server 172.16.12.1 key 10
Shortly thereafter, we can check our NTP associations on R2 and we should see that the NTP exchanges between it and R1 are authenticated:
R2# show ntp associations detail 172.16.12.1 configured, authenticated, our_master, sane, valid, stratum 2 ref ID 188.8.131.52, time CCD37909.8B261140 (06:39:05.543 UTC Sun Nov 23 2008) our mode client, peer mode server, our poll intvl 128, peer poll intvl 128 root delay 20.14 msec, root disp 65.69, reach 377, sync dist 116.699 delay 7.81 msec, offset 116.2200 msec, dispersion 37.03 precision 2**18, version 3 org time CCD37929.2A38A6CA (06:39:37.164 UTC Sun Nov 23 2008) rcv time CCD37929.17DC107A (06:39:37.093 UTC Sun Nov 23 2008) xmt time CCD37929.07835CB1 (06:39:37.029 UTC Sun Nov 23 2008) filtdelay = 63.72 7.81 55.88 48.10 48.02 48.02 36.01 55.95 filtoffset = 103.59 116.22 118.39 92.51 79.64 51.89 70.94 43.87 filterror = 0.02 0.99 1.60 3.56 5.51 7.46 8.44 8.97
Did you see it? Let’s filter out some of the output and look only at the line we’re concerned with:
R2# show ntp associations detail | include 172.16.12.1 172.16.12.1 configured, authenticated, our_master, sane, valid, stratum 2
There it is: “authenticated“.
Okay, now what!?
Excellent, we’ve managed to configure R1 as an NTP client synchronizing against a public NTP server on the Internet as well as providing NTP services to internal hosts. We even enabled the ability of R1’s NTP clients to authenticate the responses they’re receiving from R1 (security of NTP is important).
Later, we’ll extend this lab to provide redundancy as well as implement access lists to increase the security of our NTP “infrastructure”.