In my previous blogpost I talked about the true random number generator (TRNG) within the Raspberry Pi. Now I am using it for a small online pre-shared key (PSK) generator at https://random.weberlab.de (IPv6-only) that you can use e.g. for site-to-site VPNs. Here are some details how I am reading the binary random data and how I built this small website.
Last but not least I was interested which “home-calling” connections my Yamaha R-N500 Network Receiver initiates. In my previous post I already analyzed the open ports within the network, while I showed a complete Apple AirPlay capture here. This time I was only interested in outgoing TCP/UDP connections to the Internet as well as how the Yamaha App “NP Controller” communicates with the receiver.
It turned out that it was not easy for me to fully analyze such a packet trace even though only a couple of connections were made. It consists of many protocols that I am not familiar with such as UPnP, MDNS, SSDP, and RTP. Anyway, ere we go:
During my analysis of Apple AirPlay connections to my Yamaha Network Receiver I was also interested in which TCP/UDP ports are opened on this audio device at all. Hence I did a basic port scan with Nmap for both transport layer protocols. (In an upcoming blogpost I am analyzing a packet capture from the Yamaha receiver which will show more details about the used ports and outgoing connections.) At first here are the Nmap results:
If you are following the daily IT news you have probably seen many articles claiming they have scanned the whole Internet for this or that. Indeed there are tools such as the ZMap Project “that enable researchers to perform large-scale studies of the hosts and services that compose the public Internet”.
This time I was not interested in scanning something, but in the question about “how many scans happen during one day on my home ISP connection?” Or in other words: What is the Internet background noise as seen by almost any customer? For this I sacrificed my Internet connection at home for 24 hours, while a factory-resetted router established a fresh Internet connection (IPv6 & IPv4) without any end devices behind it. No outgoing connections that could confuse or trigger any scans. That is: All incoming connections are really unsolicited and part of some third-party port scans, worm activities, or whatever. Using a network TAP device I captured these 24 hours and analyzed them with Wireshark.
In this blogpost I will present some stats about these incoming port scans. Furthermore I am publishing the pcap file so you can have a look at it by yourself.
Since a couple of months I am carrying a ProfiShark 1G always with me. It’s a small network aggregation TAP that fits into my bag (unlike almost any other TAPs or switches with SPAN functionalities). It runs solely via USB 3.0, hence no additional power supply nor network port on my laptop is required to get it running.
In this post I’ll give some hints on how to use the ProfiShark 1G with Windows (read: some initial problems I had and how to solve them) as well as some use cases out of my daily work with it.
Just a few days ago I gave a talk at Troopers 18 in Heidelberg, Germany, about the problems of dynamic (non-persistent) IPv6 prefixes, as well as IPv6 VPNs in general. Following are my slides and the video of the talk:
Implementing DNSSEC for a couple of years now while playing with many different DNS options such as TTL values, I came around an error message from DNSViz pointing to possible problems when the TTL of a signed resource record is longer than the lifetime of the DNSSEC signature itself. Since I was not fully aware of this (and because I did not run into a real error over the last years) I wanted to test it more precisely.
In my last blogpost I showed how to perform a DNSSEC KSK rollover. I did it quite slowly and carefully. This time I am looking into an emergency rollover of the KSK. That is: What to do if your KSK is compromised and you must replace it IMMEDIATELY.
I am listing the procedures and commands I used to replace the KSK of my delegated subdomain dyn.weberdns.de with BIND. And as you might already suggest it, I am showing DNSViz graphs after every step since it greatly reveals the current DNSKEYs etc.
Probably the most crucial part in a DNSSEC environment is the maintenance of the key-signing key, the KSK. You should rollover this key on a regular basis, though not that often as the zone signing keys, the ZSKs. I am doing a KSK rollover every 2 years.
In the following I will describe the two existing methods for a KSK rollover along with a step-by-step guide how I performed such a rollover for my zone “weberdns.de”. Of course again with many graphics from DNSViz (with “redundant edges”) that easily reveal the keys and signatures at a glance.
Note that this blogpost is NOT about the Root Zone KSK Rollover that appears in 2017/2018. It is merely about your OWN zone that is secured via DNSSEC.
If you are already familiar with DNSSEC this is quite easy: How to sign a delegated subdomain zone. For the sake of completeness I am showing how to generate and use the appropriate DS record in order to preserve the chain of trust for DNSSEC.
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:
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.
I am intensely using the SSH Public Key Fingerprint (SSHFP, RFC 4255) in all of my environments. Since my zones are secured via DNSSEC I got rid of any “authenticity of host ‘xyz’ can’t be established” problems. As long as I am using my central jump host with OpenSSH and the “VerifyHostKeyDNS yes” option I can securely login into any of my servers without any warnings. Great!
However, I encountered a couple of daily problems when using SSHFP. One of them was the question whether SSHFP works behind CNAMEs, that is, when connecting to an alias. Short answer: yes. Some more details here:
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 126.96.36.199.
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.
Just a quick glance at the domain_analyzer script from Sebastián García and Verónica Valeros. “Domain analyzer is a security analysis tool which automatically discovers and reports information about the given domain. Its main purpose is to analyze domains in an unattended way.” Nice one. If you’re running your own DNS servers you should check e.g. whether your firewall rules are correct (scanned with Nmap) or whether you’re not allowing zone transfer, etc.