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 8.8.8.8.
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.
I am testing a lot with my own DNS servers as well as with third-party DNS implementations such as DNS proxies on firewalls, DNSSEC validation on resolvers, etc. While there are a number of free DNS online tools around the Internet I was lacking some DNS test names with certain properties or resource records. Hence I configured a couple of them on my own authoritative DNS servers and its zone weberdns.de.
For example, we encountered a bug on the Palo Alto DNS proxy that has not stored the TTL value correctly – hence some test names with different TTL values. Or we had some problems when a single DNS name has more than 15 IPv4/IPv6 addresses – hence some test names with lots of addresses. And many more: Continue reading DNS Test Names & Resource Records
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
Haha, do you like acronyms as much as I do? This article is about the feature from Palo Alto Networks’ Next-Generation Firewall for Internet Protocol version 6 Neighbor Discovery Protocol Router Advertisements with Recursive Domain Name System Server and Domain Name System Search List options. ;) I am showing how to use it and how Windows and Linux react to it.
I know that BIND correctly changes the serial numbers of zones when it is enabled with inline signing and auto-dnssec. However, I got confused one more time as I looked at some of my SOA records. So, just for the record, here is an example of how the serial numbers increase while the admin has not changed anything manually on the zone files.
Continue reading BIND Inline-Signing Serial Numbers Cruncher
The usage of the SSHFP resource record helps admins to authenticate the SSH server before they expose their credentials or before a man-in-the-middle attack occurs. This is only one great extension of DNSSEC (besides DANE whose TLSA records can be used to authenticate HTTPS/SMTPS servers).
While there are some great online tools for checking the mere DNS (1, 2), the correct DNSSEC signing (3, 4), or the placement of TLSA resource records for DANE (5, 6, 7), I have not found an online SSHFP validator. That’s the idea:
It is quite common that organizations use some kind of TLS decryption to have a look at the client traffic in order to protect against malware or evasion. (Some synonyms are SSL/TLS interception, decryption, visibility, man-in-the-middle, …) Next-generation firewalls as well as proxies implement such techniques, e.g., Palo Alto Networks or Blue Coat. To omit the certificate warnings by the clients, all spoofed certificates are signed by an internal root CA that is known to all internal clients. For example, the root CA is published via group policies to all end nodes.
But what happens if the DNS-based Authentication of Named Entities (DANE) is widely used within browsers? From the CA perspective, the spoofed certificates are valid, but not from the DANE perspective. To my mind we need something like an on-the-fly TLSA record spoofing technique that works in conjunction with TLS decryption.
Another great tool from Babak Farrokhi is dnstraceroute. It is part of the DNSDiag toolkit from which I already showed the dnsping feature. With dnstraceroute you can verify whether a DNS request is indeed answered by the correct DNS server destination or whether a man-in-the-middle has spoofed/hijacked the DNS reply. It works by using the traceroute trick by incrementing the TTL value within the IP header from 1 to 30.
Besides detecting malicious DNS spoofing attacks, it can also be used to verify security features such as DNS sinkholing. I am showing the usage as well as a test case for verifying a sinkhole feature.
The third tool out of the DNSDiag toolkit from Babak is dnseval. “dnseval is a bulk ping utility that sends an arbitrary DNS query to a given list of DNS servers. This script is meant for comparing response times of multiple DNS servers at once”. It is not only listing the response times but also further information about the DNS responses such as the TTL and the flags. Really great for comparison and troubleshooting different DNS forwarders as well as own authoritative DNS server responses as seen by others.
Continue reading Compare & Troubleshoot DNS Servers: dnseval
After the implementation of DNS and DNSSEC (see the last posts) it is good to do some reconnaissance attacks against the own DNS servers. Especially to see the NSEC or NSEC3 differences, i.e., whether zone walking (enumeration) is feasible or not.
For many different kinds of DNS reconnaissance the tool dnsrecon can be used. In this post I will focus on the -z option which is used for DNSSEC zone walking, i.e., walk leaf by leaf of the whole DNS zone.