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:
Continue reading NTP Authentication at Juniper ScreenOS
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:
Continue reading NTP Authentication on Pulse Connect Secure
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.
Continue reading Infoblox Grid Manager NTP Authentication
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!
Continue reading Fortinet FortiGate (not) using NTP Authentication
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:
Continue reading Palo Alto Networks NGFW using NTP Authentication
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:
Continue reading NTP Authentication on Cisco IOS
Now that we have enabled NTP authentication on our own stratum 1 NTP servers (Linux/Raspbian and Meinberg LANTIME) we need to set up this SHA-1 based authentication on our clients. Here we go for a standard Linux ntp setup:
Continue reading NTP Authentication: Client Side
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.
Continue reading Meinberg LANTIME NTP Authentication
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.
Continue reading NTP Authentication: Server Side
Infoblox offers a nice product which completely serves the DHCP/DNS/IPAM aka DDI area. I really love it. Especially the centralized management aka Grid works quite stable and is easy to use (though the GUI looks a bit outdated).
However, sometimes I am little beyond the daily business and labbing with next-generation features such as #IPv6, #DNSSEC, #NTP authentication, CAA, SSHFP, and so on. Not everything within these topics is included, hence a couple of feature requests. Just a living list from my perspective.
Continue reading Infoblox Feature Requests
With Infoblox you’re almost doing everything through the WebUI on the Infoblox Grid Master. At least the daily business such as adding/changing/deleting/moving/whatever DNS, DHCP, and IPAM stuff. Even troubleshooting is almost done through this HTTPS-based GUI. However, some circumstances require the use of the CLI on an Infoblox appliance/VM, called “Remote Console Access” aka SSH. Here are the most common troubleshooting CLI commands for Infoblox DDI. Samples on how to use the IPMI/LOM features round things up:
Continue reading CLI Commands for Troubleshooting Infoblox
IPv6 brings us enough addresses until the end of the world. Really? Well… No. There was an interesting talk at RIPE77 called “The Art of Running Out of IPv6 Addresses” by Benedikt Stockebrand that concludes that we will run out of IPv6 addresses some day.
Luckily Palo Alto Networks has already added one feature to expand the IPv6 address space by making them case sensitive. That is: you can now differentiate between upper and lower case values “a..f” and “A..F”. Instead of 16 different hexadecimal values you now have 22 which increases the IPv6 space from to about . Here is how it works on the Palo Alto Networks firewall:
Continue reading Using Case Sensitive IPv6 Addressing on a Palo Alto
What failover times do you expect from a network security device that claims to have high availability? 1 ms? Or at least <1 second? Not so for a fully featured Infoblox HA cluster which takes about 1-2 minutes, depending on its configuration. Yep. “Works as designed”. Ouch. Some details:
Continue reading Infoblox Failover Debacle (Works as Designed)
When configuring a pool of NTP servers on a F5 BIG-IP load balancer you need to choose how to check if they are still up and running. There is no specific NTP monitor on a F5 BIG-IP that does an application layer health check (like there is for http or radius). The out-of-the-box options that can be used are only ICMP and UDP monitoring. Let’s first look at the pros and cons of using either (or both) of these monitors. Then let’s build a custom UDP monitor that does a better job at checking whether the NTP servers are still healthy.
Continue reading F5 BIG-IP Application Level NTP Health Checks
As you hopefully already know, you should use at least three different NTP servers to get your time. However, there might be situations in which you can configure only one single NTP server, either via static IP addresses or via an FQDN. To overcome this single point of failure you can use an external load balancing server such as F5 LTM (in HA of course) to forward your NTP queries to one of many NTP servers. Here are some hints:
Continue reading Load Balancing NTP via F5 BIG-IP LTM