This is a guest blogpost by Martin Langer, Ph.D. student for “Secured Time Synchronization Using Packet-Based Time Protocols” at Ostfalia University of Applied Sciences, Germany.
In the previous posts, I already introduced the Network Time Security (NTS) protocol and described the most important features. Although the specification process has not been completed, there are already some independent NTS implementations and public time servers (IETF106). NTPsec is one of the important representatives of this series and already offers an advanced NTS solution. In this post, I’ll give you a short guide to setting up an NTS-secured NTP client/server with NTPsec.
Continue reading Setting up NTS-Secured NTP with NTPsec
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.
Continue reading Basic NTP Client Test: ntpdate & sntp
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
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
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.
Continue reading Updating NTP Servers
Until now I generated all SSHFP resource records on the SSH destination server itself via
ssh-keygen -r <name>. This is quite easy when you already have an SSH connection to a standard Linux system. But when connecting to third party products such as routers, firewalls, whatever appliances, you don’t have this option. Hence I searched and found a way to generate SSHFP resource records remotely. Here we go:
Continue reading Generating SSHFP Records Remotely
This is actually a bad user experience problem: To generally omit the manual verification of SSH key fingerprints I am using SSHFP. With fully qualified domain names (FQDN) as the hostname for SSH connections such as
ssh nb10.weberlab.de this works perfectly. However, admins are lazy and only use the hostname without the domain suffix to connect to their servers since the domain search does the rest:
ssh nb10. Not so for SSHFP which fails since the default OpenSSH client does not use canonicalization for its DNS queries. Hence you must explicitly enable canonicalization for OpenSSH.
Continue reading SSHFP: FQDN vs. Domain Search/DNS-Suffix
If you’re running your own DNS resolver you’re probably interested in some benchmark tests against it, such as: how fast does my own server (read: Raspberry Pi) answer to common DNS queries compared to 188.8.131.52.
In this blogpost I am showing how to use two tools for testing/benchmarking DNS resolvers: namebench & dnseval. I am listing the defaults, giving some hints about them and showing examples in which I tested some private and public DNS resolvers: a Fritzbox router, a Raspberry Pi with Unbound, Quad9, OpenDNS, and Google Public DNS.
Continue reading Benchmarking DNS: namebench & dnseval
I am using Nmap every time I installed a new server/appliance/whatever in order to check some unknown open ports from the outside. In most situations I am only doing a very basic run of Nmap without additional options or NSE scripts.
Likewise I am interested in how the Nmap connections appear on the wire. Hence I captured a complete Nmap run (TCP and UDP) and had a look at it with Wireshark. If you’re interested too, feel free to download the following pcap and have a look at it by yourself. At least I took some Wireshark screenshots to give a first glance about the scan.
Continue reading Nmap Packet Capture
As a network administrator I know that there are SSH fingerprints. And of course I know that I must verify the fingerprints for every new connection. ;) But I did not know that there are so many different kinds of fingerprints such as md5- or sha-hashed, represented in base64 or hex, and of course for each public key pair such as RSA, DSA, ECDSA, and Ed25519. Uh, a bit too complicated at a first glance. Hence I draw a picture.
Continue reading SSH Key Fingerprints
To solve the chicken-or-egg problem for DNSSEC from the other side, let’s use an authoritative DNS server (BIND) for signing DNS zones. This tutorial describes how to generate the keys and configure the “Berkeley Internet Name Domain” (BIND) server in order to automatically sign zones. I am not explaining many details of DNSSEC at all, but only the configuration and verification steps for a concrete BIND server.
It is really easy to tell BIND to do the inline signing. With this option enabled, the admin can still configure the static database for his zone files without any relation to DNSSEC. Everything with signing and maintaining is fully done by BIND without any user interaction. Great.
Continue reading DNSSEC Signing w/ BIND
This is a basic tutorial on how to install BIND, the Berkeley Internet Name Domain server, on a Ubuntu server in order to run it as an authoritative DNS server. It differs from other tutorials because I am using three servers (one as a hidden primary and two secondaries as the public accessible ones), as well as some security such as denying recursive lookups and public zone transfers, as well as using TSIG for authenticating internal zone transfers. That is, this post is not an absolute beginner’s guide.
Continue reading Basic BIND Installation
I initially stored my ownCloud data on an external NTFS hard disk. (Yes, this was not a good idea at all.) After some time now I wanted to move the files to a bigger ext4 drive on the same machine. Unluckily there are many posts and articles that are really irritating on the Internet, such as: 1, 2, 3, 4, 5. At least I found some promising hints at the official GitHub forums (this and that) and gave it a try:
Continue reading ownCloud Data Directory
Some time ago I published a post introducing ntopng as an out-of-the-box network monitoring tool. I am running it on a Knoppix live Linux notebook with two network cards. However, I have a few customers that wanted a persistent installation of ntopng in their environment. So this is a step-by-step tutorial on how to install ntopng on a Ubuntu server with at least two NICs.
Continue reading ntopng Installation
Roundcube is an email webclient which is easy and intuitive to use. I am using it for my private mails, connecting via IMAP and SMTP to my hoster. One of the great advantages is the “flag” option which is synchronized via IMAP to my Apple devices.
Following is a step-by-step installation guide for Roundcube plus an update scenario. It is a kind of “memo for myself”, but hopefully, others can use it as well.
Continue reading Roundcube Installation Guide