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:
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.
I really like the kind of security features that are easy to use. The CAA “DNS Certification Authority Authorization” is one of those. 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.
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.
If you are using a Lastline device (Manager, Engine, Sensor or Pinbox) you can reach the machine via SSH after you activated it via monitoring_user_password . However, per default this uses only a password for authentication. If you want to use the key-based authentication for this “monitoring” user account you can add the public key to the authorized_keys file for that user.
This is a small record on how to add a public key to the Lastline device. However, it is quite general since the Lastline appliance is built upon a standard Ubuntu server.
This is a cool and easy to use (security) feature from Palo Alto Networks firewalls: The External Dynamic Lists which can be used with some (free) 3rd party IP lists to block malicious incoming IP connections. In my case I am using two free IP lists to deny any connection from these sources coming into my network/DMZ. I am showing the configuration of such lists on the Palo Alto as well as some stats about it.
The usage of the SSHFP resource record helps admins to authenticate the SSH server before they are exposing their credentials or before a man-in-the-middle attack occurs. This is only one great extension of DNSSEC (beside 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.
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.
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.