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.
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.
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:
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:
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:
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.
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:
In case you’re responsible for an enterprise network or data center you should care about NTP. Refer to “Why should I run own NTP Servers?“. As a hobby technician you might first think about Raspberry Pis with self soldered GPS modules. Well, good idea to play with, but not reliable at all. Way to unstable, hard to update, no alerting, no service agreements, and so on.
Hence you should use a dedicated NTP appliance such as the Meinberg LANTIME NTP Time Servers. I am using a LANTIME M200 with a DCF77 correlation receiver in my lab. With this post I am showing how to set up this NTP server, giving some insights, and listing the advantages of such an appliance compared to a Raspberry Pi or any other DIY server approach. My wish list aka feature requests to this product round things up.
As always when you’re running own services you should update them regularly to have all known bugs fixed and security issues thwarted. Same for NTP servers based on Linux, as in my case running on Raspberry Pis. Especially when you’re actively joining the NTP pool project with your NTP servers you have to update them to the latest version of ntp since you might be misused for well-known DDoS attacks or other security related bugs.
So, what’s this all about? You can simply do an “apt-get upgrade”, don’t you? Well, unluckily the ntp packages within the Linux distributions are not always updated to the latest versions. Hence you need to compile the ntp software by yourself to have the latest release running. Still not that hard, though it requires a bit more attention.
This post shows how to use a GPS receiver with a Raspberry Pi to build a stratum 1 NTP server. I am showing how to solder and use the GPS module (especially with its PPS pin) and listing all Linux commands to set up and check the receiver and its NTP part, which is IPv6-only in my case. Some more hints to increase the performance of the server round things off. In summary this is a nice “do it yourself” project with a working stratum 1 NTP server at really low costs. Great. However, keep in mind that you should not rely on such projects in enterprise environments that are more focused on reliability and availability (which is not the case on self soldered modules and many config file edits).
In this tutorial I will show how to set up a Raspberry Pi with a DCF77 receiver as an NTP server. Since the external radio clock via DCF77 is a stratum 0 source, the NTP server itself is stratum 1. I am showing how to connect the DCF77 module and I am listing all relevant commands as a step by step guide to install the NTP things. With this tutorial you will be able to operate your own stratum 1 NTP server. Nice DIY project. ;) However, keep in mind that you should only use it on a private playground and not on an enterprise network that should consist of high reliable NTP servers rather than DIY Raspberry Pis. Anyway, let’s go:
What’s the first step in a networker’s life if he wants to work with an unknown protocol: he captures and wiresharks it. ;) Following is a downloadable pcap in which I am showing the most common NTP packets such as basic client-server messages, as well as control and authenticated packets. I am also showing how to analyze the delta time with Wireshark, that is: how long an NTP server needs to respond to a request.
… since we all can use pool.ntp.org ? Easy answer: Many modern (security) techniques rely on accurate time. Certificate validation, two-factor authentication, backup auto-deletion, logs generation, and many more. Meanwhile we use an unauthenticated protocol (via stateless UDP) from unauthenticated sources (NTP pool) to rely on! Really?
If you are using couple of different NTP sources it might be not that easy for an attacker to spoof your time – though not unfeasible at all. And think about small routers with VPN endpoints and DNSSEC resolving enabled, or IoT devices such as cameras or door openers – they don’t even have a real-time clock with battery inside. They fully rely on NTP.
This is what this blogpost series is all about. Let’s dig into it. ;)
Working with Infoblox can be challenging when it comes to their naming of features, licenses, marketing slides, and GUI options. So let’s bring some clarity into this chaos. :D I have listed the most common DNS security features and their corresponding Infoblox names. I hope you folks can use it as well.
This post is not about software but hardware tools for network admins. Which network gadgets am I using during my daily business? At least three, namely the Airconsole, the Pockethernet and the ProfiShark, which help me in connecting to serial ports, testing basic network connectivity, and capturing packets in a high professional way. Come in and have a look at how I’m working.