CCIE or Null!

Like all technologies in a network there are ways to secure it from being used maliciously, and NTP is no acception. We actually have a few different ways to secure the communication between our NTP peers and servers.

• Authentication

Yep, we can configure our NTP clients to authenticate to our NTP server/master and make sure we only accept the time from NTP servers that we have control over. This ensures our routers will not get the time from any unauthorized sources and prevents a malicious user from spoofing their own NTP server and changing the time on the network. Do keep in mind NTP authentication only supports a PSK type authentication method and will use an MD5 hash so were not doing anything over the top here. Configuration below:

NTP authentication on the NTP master.

NTP authentication on the client

Do keep in mind, I’ve built this configuration off my previous NTP lab post so not every NTP command is shown above.

Now, when I configured this I forgot the command ntp trusted-key 1 on the NTP server, but I did specify the key for the ntp server on the NTP client, so obviously my configuration did not work right off the bat. I ended up debugging NTP to troubleshoot, so I issued the debug ntp packet and debug ntp auth, which provided me the following:

NTP debug with wrong key on the master.

From there you can see we transmitted a packet to 172.31.1.1 (our NTP master) with authentication key 1, however the packet we received from 172.31.1.1 had an authentication key 0 (No authentication). So once I saw that I quickly realized where my problem was. I went back to the NTP master and issued the command ntp trusted-key 1 and then went back to client check the ntp status.

After reviewing the debug output again, both packets are using an NTP authentication key. Keep in mind the NTP key # does not have to match but the MD5 password within the keys has to match.

• Access Control Lists

Good old ACLs what can’t they do for us? Well NTP can be configured with an ntp access-group command, this command will limit the number NTP peers we perform transactions with, which can be useful and if you consider the IP Scheme during your design this won’t be hard to implement (Especially if you source NTP packets from loopback address). Here is my configuration:

NTP access group on the NTP Master

NTP access group on the NTP client

I’m a big fan of using named ACLs whenever possible, it just makes it easier to manage in my opinion. My NTP client is a Cisco Catalyst 2960 and NTP on this device only supports numbered ACLs, which is why I had to use a normal numbered ACL there and not a named ACL. The only slightly complex portion of  NTP access-groups is the fact we can have different types of access-groups:

• Peer: Peer access-groups allow both request and control queries to be processed meaning the router will be allowed to update its time from the allowed peers.
• Query-only: This only allows control queries to be accepted, control queries don’t actually the effect the date/time so I’m going to skip this one. See RFC 1305 for addition information about this.
• Serve: Allows the router to reply to request as well as control queries.
• Serve-only: Does not allow control queries and only replies to NTP requests.

So from our example our NTP master is setup to serve-only our NTP clients, and our NTP master has full access to our NTP clients.

One last thing I want to touch on concerning NTP access-groups is the fact if your setup an ACL between 2 NTP servers, you must remember to allow the local NTP server address, in this case it is 127.127.1.1 this address might different depending on the router model and IOS version so it’s always a good idea to check it out.

The NTP Master Internal IP 127.127.1.1