What is the biggest problem of PGP? The key distribution. This is well-known and not new at all. What is new is the OPENPGPKEY DNS resource record that delivers PGP public keys for mail addresses. If signed and verified with DNSSEC a mail sender can get the correct public key for his recipient. This solves both key distribution problems: 1) the delivery of the public key and 2) the authenticity of the key itself, i.e., that you’re using the correct key to encrypt a mail.
The “DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP” is specified in the experimental RFC 7929. Let’s have a look on how you can add your public key into the zone file of your DNS server.
Continue reading PGP Key Distribution via DNSSEC: OPENPGPKEY
I really like the kind of security features that are easy to use. The CAA “DNS Certification Authority Authorization” is one of those, specified in RFC 6844. As a domain administrator you must only generate the appropriate CAA records and you’re done. (Unlike other security features such as HPKP that requires deep and careful planning or DANE which is not used widely.) Since the check of CAA records is mandatory for CAs since 8. September 2017, the usage of those records is quite useful because it adds another layer of security.
Continue reading CAA: DNS Certification Authority Authorization
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
It is probably one of the most used protocols in my daily business but I have never captured it in detail: IKE and IPsec/ESP. And since IKEv2 is coming I gave it a try and tcpdumped two VPN session initiations with IKEv1 main mode as well as with IKEv2 to see some basic differences.
Of course I know that all VPN protocols are encrypted – hence you won’t see that much data. But at least you can see the basic message flow such as “only 4 messages with IKEv2” while some more for legacy IKEv1. I won’t go into the protocol details at all. I am merely publishing two pcap files so that anyone can have a look at a VPN session initiation. A few Wireshark screenshots complete the blogpost.
Continue reading IKEv1 & IKEv2 Capture
I still like the Juniper ScreenOS firewalls such as the SSG 5 or the SSG 140. However, they are End of Everything (EoE) and not used at the customers anymore. But they still do their job in basic networking (static/dynamic routing such as OSPF & BGP, IPv6, NAT), basic firewalling (access policies), and IPsec VPN. Hence I am using a couple of SSGs in my lab when playing with routing protocols and so on.
After a factory reset of those firewalls there are some default settings such as zones at a few interfaces and default IP addresses. Therefore I put the following commands together in order to cleanup the default config to have only IP addresses and default routes which is a good starting point for lab configurations. Let’s go:
Continue reading Juniper ScreenOS Initial Cleanup Config
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 once required for the current scenario. Kind of a template. Of course with IPv6 and legacy IP.
Continue reading Basic Cisco Configuration
I wanted to configure a weekly email report on a Palo Alto Networks firewall. “Yes, no problem”, I thought. Well, it was absolutely not that easy. ;(
While the PAN firewalls have a great GUI and a good design at all they lack an easy-to-use email reporting function, especially when compared to the FortiGate firewalls which have a great local report feature. –> If you want some stats on a weekly basis you must configure it completely from scratch. Unluckily this is not that easy since you must pass several steps for that. Therefore, I drew an outline of the Palo Alto reporting stages to have an overview of them.
Continue reading Palo Alto Reporting
Yes I know, ScreenOS is “End of Everything” (EoE). However, for historical reasons I am still managing many Netscreen/ScreenOS firewalls for some customers. Similar to my troubleshooting CLI commands for Palo Alto and Fortinet I am listing the most common used commands for the ScreenOS devices as a quick reference / cheat sheet. These are only the commands that are needed for deep troubleshooting sessions that cannot be done solely on the GUI.
Continue reading CLI Commands for Troubleshooting Juniper ScreenOS Firewalls
By default DNSSEC uses the next secure (NSEC) resource record “to provide authenticated denial of existence for DNS data”, RFC 4034. This feature creates a complete chain of all resource records of a complete zone. While it has its usage to prove that no entry exists between two other entries, it can be used to “walk” through a complete zone, known as zone enumeration. That is: an attacker can easily gather all information about a complete zone by just using the designed features of DNSSEC.
For this reason NSEC3 was introduced: It constructs a chain of hashed and not of plain text resource records (RFC 5155). With NSEC3 enabled it is not feasible anymore to enumerate the zone. The standard uses a hash function and adds the NSEC3PARAM resource record to the zone which provides some details such as the salt.
Continue reading DNSSEC with NSEC3
One important maintenance requirement for DNSSEC is the key rollover of the zone signing key (ZSK). With this procedure a new public/private key pair is used for signing the resource records, of course without any problems for the end user, i.e., no falsified signatures, etc.
In fact it is really simply to rollover the ZSK with BIND. It is almost one single CLI command to generate a new key with certain time ranges. BIND will use the correct keys at the appropriate time automatically. Here we go:
Continue reading DNSSEC ZSK Key Rollover
This is really cool. After DNSSEC is used to sign a complete zone, SSH connections can be authenticated via checking the SSH fingerprint against the SSHFP resource record on the DNS server. With this way, administrators will never get the well-known “The authenticity of host ‘xyz’ can’t be established.” message again. Here we go:
Continue reading SSHFP: Authenticate SSH Fingerprints via DNSSEC
DNS-based Authentication of Named Entities (DANE) is a great feature that uses the advantages of a DNSSEC signed zone in order to tell the client which TLS certificate he has to expect when connecting to a secure destination over HTTPS or SMTPS. Via a secure channel (DNSSEC) the client can request the public key of the server. This means, that a Man-in-the-Middle attack (MITM) with a spoofed certificate would be exposed directly, i.e., is not possible anymore. Furthermore, the trust to certificate authorities (CAs) is not needed anymore.
In this blog post I will show how to use DANE and its DNS records within an authoritative DNS server to provide enhanced security features for the public.
Continue reading How to use DANE/TLSA
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
To overcome the chicken-or-egg problem for DNSSEC (“I don’t need a DNSSEC validating resolver if there are no signed zones”), let’s install the DNS server Unbound on a Raspberry Pi for home usage. Up then, domain names are DNSSEC validated. I am listing the commands to install Unbound on a Raspberry Pi as well as some further commands to test and troubleshoot it. Finally I am showing a few Wireshark screenshots from a sample iterative DNS capture. Here we go:
Continue reading DNSSEC Validation with Unbound on a Raspberry