During my work with a couple of NTP servers, I had many situations in which I just wanted to know whether an NTP server is up and running or not. For this purpose, I used two small Linux tools that fulfill almost the same: single CLI command while not actually updating any clock but only displaying the result. That is: ntpdate & sntp. Of course, the usage of IPv6 is mandatory as well as the possibility to test NTP authentication.
Yes, ScreenOS is end-of-everything (EoE), but for historical reasons I still have some of them in my lab. ;D They simply work, while having lots of features when it comes to IPv6 such as DHCPv6-PD. However, using IPv6-only NTP servers is beyond their possibilities. :(
Anyway, I tried using NTP authentication with legacy IP. Unfortunately, I had some issues with it. Not only that they don’t support SHA-1 but MD5, this MD5 key was also limited in its length to 16 characters. Strange, since ntp-keygen per default generates 20 ASCII characters per key. Let’s have a look:
I initially wanted to show how to use NTP authentication on a Pulse Connect Secure. Unfortunately, it does not support NTP over IPv6, which is mandatory for my lab. Ok, after I calmed down a bit, a configured it with legacy IP and got NTP authentication running. ;) Here’s how:
Configuring NTP authentication on the Infoblox Grid Master is quite simple. Everything is packed inside the single “NTP Grid Config” menu. You just have to enter the NTP keys respectively key IDs and enable authentication on the appropriate servers. In the case of incorrect authentication values an error message is logged. Very good, since this is not the case on some other network security devices (Palo, Forti).
Too bad that it only supports MD5 while SHA-1 should be used instead of.
A security device such as a firewall should rely on NTP authentication to overcome NTP spoofing attacks. Therefore I am using NTP authentication on the FortiGate as well. As always, this so-called next-generation firewall has a very limited GUI while you need to configure all details through the CLI. I hate it, but that’s the way Fortinet is doing it. Furthermore the “set authentication” command is hidden unless you’re downgrading to NTPv3 (?!?) and it only supports MD5 rather than SHA-1. Not that “next-generation”!
Finally, you have no chance of knowing whether NTP authentication is working or not. I intentionally misconfigured some of my NTP keys which didn’t change anything in the NTP synchronization process while it should not work at all. Fail!
Everyone uses NTP, that’s for sure. But are you using it with authentication on your own stratum 1 servers? You should since this is the only way to provide security against spoofed NTP packets, refer to Why should I run own NTP Servers?. As always, Palo Alto has implemented this security feature in a really easy way, since it requires just a few clicks on the GUI. (Which again is much better than other solutions, e.g., FortiGate, which requires cumbersome CLI commands.) However, monitoring the NTP servers, whether authentication was successful or not, isn’t implemented in a good way. Here we go:
This is how you can use NTP authentication on Cisco IOS in order to authenticate your external NTP servers respectively their NTP packets. Though it is not able to process SHA-1 but only MD5, you’re getting an authentic NTP connection. Let’s have a look:
Operating NTP in a secure manner requires the usage of NTP authentication, refer to my Why should I run own NTP Servers? blogpost. Using the Meinberg LANTIME NTP appliance with NTP authentication is quite simply since it requires just a few clicks. Even adding more and more keys (which requires manual work on any other Linux ntp installation) is done within clicks. That’s the way it should be.
As already pointed out in my NTP intro blogpost Why should I run own NTP Servers? it is crucial to leverage NTP authentication to have the highest trustworthiness of your time distribution all over your network. Hence the first step is to enable NTP authentication on your own stratum 1 NTP servers, in my case two Raspberry Pis with DCF77/GPS reference clocks.
Yet another routing protocol I played with in my lab. ;) This time: EIGRP, Enhanced Interior Gateway Routing Protocol, the
proprietary distance-vector routing protocol developed by Cisco, which is now public available (RFC 7868). However, no third-party products in here but only Cisco routers. I am using named EIGRP for both Internet Protocols, IPv6 and legacy IP, along with MD5 authentication and redistribution from OSPF.
Here comes a small lab consisting of three Cisco routers in which I used OSPFv3 for IPv6 with IPsec authentication. I am listing the configuration commands and some show commands. Furthermore, I am publishing a pcapng file so that you can have a look at it with Wireshark by yourself.
I already had an OSPFv2 for IPv4 lab on my blog. However, I missed capturing a pcap file in order to publish it. So, here it is. Feel free to have a look at another small lab with three Cisco routers and OSPFv2. Just another pcapng file to practise some protocol and Wireshark skills.
While playing around in my lab learning BGP I configured iBGP with Multiprotocol Extensions (exchanging routing information for IPv6 and legacy IP) between two Cisco routers, a Palo Alto Networks firewall, and a Fortinet FortiGate firewall. Following are all configuration steps from their GUI (Palo) as well as their CLIs (Cisco, Fortinet). It’s just a “basic” lab because I did not configure any possible parameter such as local preference or MED but left almost all to its defaults, except neighboring from loopbacks, password authentication and next-hop-self.
It is widely believed that public/private keys or certificates are “more secure” than passwords. E.g., an SSH login via key rather than using a password. Or a site-to-site VPN with certificate authentication rather than a pre-shared key (PSK). However, even certificates and private keys are not unlimited secure. They can be compromised, too, since the public-key cryptography only implies that private keys won’t be exposed if a brute-force attack is nearly impossible.
So, what’s the real security level of passwords compared to public keys/certificates?