Archive for the ‘NTP’ Category
Securing NTP
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
Who’s got the time? NTP – Network Time Protocol
Anyone who has ever had to troubleshoot any type of issue on a Cisco router knows they have to look through log messages, and anyone who has ever done this knows what’s it’s like to look through a log where the time is off by minutes, hours, days, or even years. It tends to add on another layer of complexity in itself & typically you are going to be in this type of situation:
- Ok, I’ve got a problem let’s troubleshoot
- Lets look at the logs
- HHmm those dates/times are all wrong
- Ok let’s issue the sh clock command to see what time the router thinks it is
- Now how far off is the router’s internal clock from the real world current time
- Alright now what what time did the problem occur in the real world and what time did the problem occur in the router’s time zone
- There we go!
It’s not overly complex but it can be a little time consuming and it can cost you a good amount of time depending on the type of issue you are troubleshooting. In my mind this is completely unnecessary and should just be corrected. How do we correct this though? Well we configure our devices to check in with a time server and get the correct time using NTP (Network Time Protocol).
The first thing we will want to do is pick one (or more) of your routers to be the NTP master for the network, and the other routers will connect to this NTP master for the correct time, this will provide us with some type of hierarchical NTP design. Before we configure any clients to check in with the NTP master we decide on we’ll need to get the correct time on the master. To do this we can peer to some of the Stratum 1 public NTP servers. In terms of NTP and Stratum levels, Stratum 1 will be the most accurate time sources, these Stratum 1 servers are directly attached to some type of GPS, WWV, or CDMA device which are stratum 0 devices and are known to have the most accurate time. (Note: Cisco devices do not support the use of these devices if directly attached)
Here is our current topology:
Now let’s configure our router:
From here we configured a timezone for our router, I named the timezone EST I figured I’d keep it simple and set it to -5 which is where the Eastern time zone fits in the world. Then I set daylight saving time with the clock summer-time EST recurring command. After that I start configuring some NTP parameters I start by turning on NTP logging, I did this just for the sake of showing off some of the NTP logging messages. Then I configure the router to update it’s hardware clock with the time it receives from the server with the command ntp update-calendar, the hardware clock runs off an internal battery and will keep the correct time even when the router loses power. Now we configure our router to check in with ntp.you.org this is just one of the stratum 1 servers I pulled off the webpage mentioned earlier.
Now, shortly after I finish with those commands I see some of the NTP logging messages flash through the console:
The messages are simply telling us the clock was reset, and synchronized successfully with the server we configured. We can verify this by looking at the sh ntp status & sh ntp associations output.
You can see from the sh ntp status output, that our time is synchronized, our stratum level is 2, and when the last update was. From the sh ntp associations we can see we are peered with the NTP server 204.9.54.119 (Confirmed with the * before the IP address) and the NTP server we are peering with is using a CDMA device for it’s clock source. Also notice the 127.127.1.1 address, which is the local router.
So now in SW1 and SW2 I am going to issue the following commands:
This tells the other devices to check in with the router we configured as the NTP master, very similar to the commands we issued earlier on the master. We can verify this again by issuing the sh ntp status & sh ntp associations:
Notice there is less information, but it still tells us what we need to know. We see our clock is synchronized and to whom, as well as our stratum level. Our stratum level here is 3, since we got our time from a stratum 2 source and we are one more “time hop” away from the stratum 1 source.
So essentially our NTP design looks like this:
We can do the same thing with even more complex designs:
However NTP would be behave like this:
RFC 1305 goes into NTPv3 much more in depth if you want to read about it, also keep in mind NTP runs off UDP Port 123. (I just had to throw that in there somewhere before I ended this post)
CCIE or Null! 