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.
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:
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 your 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 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.
Continue reading Packet Capture: Network Time Protocol (NTP)
… 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 a 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 a battery inside. They fully rely on NTP.
This is what this blogpost series is all about. Let’s dig into it. ;)
During the last few weeks I published a couple of blogposts concerning routing protocols such as BGP, OSPFv3, and EIGRP. (Use the “Cisco Router” tag on my blog to list all of them.) They are all part of my current Cisco lab that I am using for my CCNP TSHOOT exam preparation. While I depicted only the details of the routing protocols in those blogposts, I am showing my overall lab with all of its Cisco IOS configs here. Just to have the complete picture. There are a couple of not-yet-blogged configs such as VRRP, GLBP, NTP authentication, embedded event manager (EEM), or route-maps and distribute/prefix lists though.
Following is a list of the most common Cisco device configuration commands that I am using when setting up a router or switch from scratch, such as hostname, username, logging, vty access, ntp, snmp, syslog. For a router, I am also listing some basic layer 3 interface commands, while for a switch I am listing STP and VTP examples as well as the interface settings for access and trunk ports.
This is not a detailed best practice list which can be used completely without thinking about it, but a list with the most common configurations from which to pick out the ones required for the current scenario. Kind of a template. Of course with IPv6 and legacy IP.
Second post of this little series. While I was using my CCNP SWITCH lab for testing many different protocols, I “showed” and saved the output of those protocols as well. Refer to the lab overview of my last post in order to understand those outputs.
I basically saved them as a reference for myself in case I am interested in the information revealed by them. I won’t explain any details of the protocols nor the outputs here. Just many listings. Fly over them and reflect yourself whether you would understand anything. ;) Here we go:
While preparing for my CCNP SWITCH exam I built a laboratory with 4 switches, 3 routers and 2 workstations in order to test almost all layer 2/3 protocols that are related to network management traffic. And because “PCAP or it didn’t happen” I captured 22 of these protocols to further investigate them with Wireshark. Oh oh, I remember the good old times where I merely used unmanaged layer 2 switches. ;)
In this blogpost I am publishing the captured pcap file with all of these 22 protocols. I am further listing 46 CHALLENGES as an exercise for the reader. Feel free to download the pcap and to test your protocol skills with Wireshark! Use the comment section below for posting your answers.
Of course I am running my lab fully dual-stacked, i.e., with IPv6 and legacy IP. On some switches the SDM template must be changed to be IPv6 capable such as sdm prefer dual-ipv4-and-ipv6 default .
Continue reading Wireshark Layer 2-3 pcap Analysis w/ Challenges (CCNP SWITCH)