I have created a simple script that runs dnscheck regularily and sends me an email when dnscheck finds any errors. By doing this I am notified if a zone transfer breaks, DNSSec-signatures gets outdated or any other anomalies in the DNS configuration of my zones.


I have also put together a form which can be used to add monitored zones to the database. Just visit dnschecker.nat0.net and add your email address and the zone you want to monitor. After verifying your email address my script will monitor the zone(s) you´ve added and send you an email if anything fishy is found by dnscheck.



Posted in Uncategorized

ASA 9.2 and Heartbleed

Short after the openssl Heartbleed vurnearability was publiced Cisco announced that Cisco ASA was NOT affected by Heartbleed because it runs an older version of OpenSSL.


Today, 2014-04-25, Cisco updated its Feature-list of Cisco ASA software versions with the long awaited v9.2.


But w000t? From now on Cisco ASA runs OpenSSL v1.0.1e (which IS affected by Heartbleed)! What´s happening. Cisco?


Screenshot 2014-04-25 20.06.47



Edit. I posted this and sent the URL to one of my contacts at Cisco. Less than 2 hours later Cisco added a note to the Release Notes:

Screenshot 2014-04-26 17.05.08


So. Cisco did NOT add heartbleed as a new feature in ASA v9.2. My guess is that they upgraded to 1.0.1e in a beta of 9.2 and before got aware of Heartbleed just days before releasing 9.2. And instead of upgrading OpenSSL to 1.0.1g they disabled SSL heartbeat.


So what I found was probably a bug in the documentation. :)



Posted in Uncategorized

Cisco ASA Anyconnect licensing for dummies, updated!

The picture below should be self-explaining. Click it for a larger version.

Edit 2014: There was some errors in the logics around AEA-licenses. The picture below is now corrected. Please do not use the old version (v1.1).



Let me explain this.


First of all, Advanced Endpoint Assessment (AEA) is a feature where you can do advanced posture checks and remediations with AnyConnect. AEA can check if your antivirus is enabled, and if not enable it, verify if the clients software firewall is installed and enabled and other advanced remediation thingies. I have never used it and if you are not certanly sure you don´t need this license. But if you do you need to continue on the Anyconnect Premium track. No Essentials license for you, my friend.


So. The big question is: Premium licenses or Essentials? The big (simplified) answer is: do you want to use the “clientless” portal? This requires premium licenses and cannot be used if you have “anyconnect essentials” configured (which in turn require the essentials license, see below).

So, let´s say that you need premium licenses. These comes in chunks of concurrent users from 2 to 10, 25, 50 and so on. These are not additative. If you have 2 you can go to the fixed steps of 10, 25, 50 and so on. If you have 25 you can go to 50, 100, 250 et cetera. Each combination of number of license you HAVE and the number of license you WANT have a specific product number. One from 10 to 25, one from 10 to 50, one from 25 to 50 and so on. Messy? Indeed.


The cheaper track is the essentials-licens. You unlock your firewall to unlimited(*) number of concurrent vpn client with one single license. It is cheaper and easier but comes with a few downsides: If you use essentials you cannot do the portal-thingie. And you can not use AEA (which is probably not an issue, see above).

If you wanna use essentials you add the license, AND you do not forget to add the command “webvpn -> anyconnect-essentials” to enable essentials. This command cannot be entered without the license and when essentials is enabled the firewall doesnt care if there are premium licenses installed or not.


On the other hand, if you use premium licenses, you must (except for adding the licenses of course) disable essentials (webvpn -> no anyconnect-essentials). The essentials license (if it exists) will stay there but for no use and good.


So, can it be even more complicated? You bet! No matter what selections you have done above you cannot use anyconnect in your mobile device (iOS, Android). Why? Because Cisco wants to sell “Anyconnect Mobile” licenses. Don´t worry, they are cheap. But you need to add this if you want mobile clients. It is a binary one-timer. You add one mobile-license and you can also use mobile vpn clients.


So, let´s have a look at a few examples:


Example 1: We have an ASA5510 on which we want to connect numerous of anyconnect clients. We don´t care about the portal, but we want to use mobile clients.  We add these licenses:

  • one L-ASA-AC-E-5510=
  • one L-ASA-AC-M-5510=

The 5510 platform can handle 250 concurrent vpn sessions. This means that the licenses above allows us to use 250 concurrent connected vpn-clients, and among them there can be any number of mobile clients. (Dont forget to enable essentials in the config!)


Example 2: An ASA5520 on which we want to use the clientless portal as well as anyconnect clients up to a number of 45 concurrent sessions. We add this license:


  • One L-ASA5500-SSL50


Now we had raised the number of concurrent vpn-sessions from the built-in 2 to 50. Since it is premium licenses any of these 50 sessions can be clientless portal users.


Example 2b: We want to raise the number of concurrent users from 50 to 100. We also want to allow iPhone-devices to connect with AnyConnect. We add these licenses:


  • One L-ASA-SSL-50-100=
  • One L-ASA-AC-M-5520=


Sounds complicated? Only the first 20 times you need to understand the licensing model. And everytime Cisco changes it. Which happens. :-)

Tagged with: , ,
Posted in Cisco Security

DNSSec Zone signing

This is what happens when a zone is signed with DNSSec:

  1. 2 Keypairs are created, named ZSK and KSK.
  2. The public keys ZSKpub and KSKpub are added to the zone file as DNSKEY RR:s
  3. All existing entries in the zone files are signed with the ZSKpriv. The signatures are added to the zone files as RRSIG RR:s.
  4. The added DNSKEY RR:s (ZSKpub and KSKpub) are signed with KSKpriv. The signatures are added to the zone file as RRSIG RR:s.
  5. A hash of KSKpub is transfered to the parent zone.


To visualize this we will sign the fictive zone net0.net. This is the unsigned zone file:

$ORIGIN net0.net.
$TTL 300

net0.net. IN SOA ns.nat0.net.  abuse.net0.net. (
3H    ; Refresh after three hours
1H    ; Retry after one hour
1W    ; Expire after one week
1D )    ; Minimum one day TTL

@                IN    3600    NS    ns.net0.net.

ns.net0.net.            IN    A

www                IN    3600    A


This zone file is heavily simplified. It contains one SOA-record, one NS-record and 2 A-records. So, let´s take a look at what happens when the zone is signed, step by step:


Step 1: 2 Keypairs are created, named ZSK and KSK.

In the configured key directory 4 files are created


Each public key is stored in the files named .key and the content looks something like this:

net0.net. IN DNSKEY 256 3 8 AwEAAdNMI9iWcmphYDJPqAHxuAkduG7uF1UNy/OKrumEXxOZfGydiEDk 7++Yx75UxOWsAvG7MIUXQWthGj59XfRAIfKxcJr+XhpnQdX2rtjPAj8v zJ2ZB/c8iKmYzUQ85pUoHM6TN+/1wfARFfWK1+FmpGPB0pYBDWpLUmDb JAJkREQz

Its private equivalent is named .private and the content of the file looks like this:

Private-key-format: v1.3
Algorithm: 8 (RSASHA256)
Modulus: 00wj2JZyamFgMk+oAfG4CR24bu4XVQ3L84qu6YRfE5l8bJ2IQOTv75jHvlTE5awC8bswhRdBa2EaPn1d9EAh8rFwmv5eGmdB1fau2M8CPy/MnZkH9zyIqZjNRDzmlSgczpM37/XB8BEV9YrX4WakY8HSlgENaktSYNskAmRERDM=
PublicExponent: AQAB
PrivateExponent: K2ftyTWGxZHBaDRy6AtW6hB/7dHdWyydZCduLSxzN5yFMe7eqa4eGBNDnTbex+uhIzV4Dy8q0js9X+7zGRT/o/KPdyxr9y4xBeruKXwHl8nKVdaUsgr21z7zDZ5emlqoPHQ9XryohQyiWgN3qYIU3Cm5de6gl5+Sx5FLaQZjnUE=
Prime1: /+S4XclcoTX2Vnz+ZOGyEdgsz+kofAZfAJazzFVMbc+GBv+7SsjB5PpDwOrxdMSBgq2SYveecjlVwDHiwAOwEw==
Prime2: 02KqZt4b6g6cEOojse02yAEclqTou6mNs+mUk7QCyQvekVGl+mnZqpa/bQ/jMMnXNPDOJTv+KKY1aZLVPUrfYQ==
Exponent1: m5nNziHCdLjmeQL6ggeHizhDT428s2YAYNBCto5rsh5NpnXcwoW++WiAyI9UkadoBTlcWVeu/lAE56Ct/AqCBw==
Exponent2: rxYbRGcWQfDl7dCxzi9IX7MkBdcD+mR/PZTsfsbsQ7A0IrO5QcgpBXYlimVNbdzRB0Wpygd+BhddSFvZihIZIQ==
Coefficient: 2PGzkxeMAtwZi9kgbq8Lb57z8q/flqC92rTU/5iymhOshvilVTX347FS9PZzcN3tsdHG2HCJ8OVAZzlpIoOcuQ==

Step 2. The public keys ZSKpub and KSKpub are added to the zone file as DNSKEY RR:s

The content of the .key-files are added to the zone files with some additional comments:

300     DNSKEY  256 3 8 (
) ; ZSK; alg = RSASHA256; key id = 8565
300     DNSKEY  257 3 8 (
) ; KSK; alg = RSASHA256; key id = 62671

Step 3: All existing entries in the zone files are signed with the ZSKpriv. The signatures are added to the zone files as RRSIG RR:s.

So, which is which above? Take a look at the number following directly after “DNSKEY”. 256 and 257. The one with the odd number is the KSK. So Key with ID 8065 is our ZSK and 62671 is the KSK. Now, dive into the signed file and have a look. Directly below each original record (SOA, NS, A, A) we have new RRSIG:s:


net0.net.        300    IN SOA    ns.nat0.net. abuse.net0.net. (
2014020320 ; serial
10800      ; refresh (3 hours)
3600       ; retry (1 hour)
604800     ; expire (1 week)
86400      ; minimum (1 day)
300    RRSIG    SOA 8 2 300 (
20140504081944 20140404071944 8565 net0.net.
ifd1ZN3ytmwK2+mAJzEnwt8meFs= )
3600    NS    ns.net0.net.
3600    RRSIG    NS 8 2 3600 (
20140504081944 20140404071944 8565 net0.net.
t5VxrQ7mJjSt0MMZImiUaI4XkfM= )

ns.net0.net.        300    IN A
300    RRSIG    A 8 3 300 (
20140504081944 20140404071944 8565 net0.net.
eUfdRHjeBCKb6w6CWgPlpx4x0AM= )
www.net0.net.        3600    IN A
3600    RRSIG    A 8 3 3600 (
20140504081944 20140404071944 8565 net0.net.
kKKPWYK9GHbMWE3z4Hxwdu4PC5w= )

Note that each RRSIG has the key-id 8565 included in the record to show which key the signature is created with (the ZSK)).


Step 5: The added DNSKEY RR:s (ZSKpub and KSKpub) are signed with KSKpriv. The signatures are added to the zone file as RRSIG RR:s.

300    RRSIG    DNSKEY 8 2 300 (
20140504081944 20140404071944 8565 net0.net.
QyLcEBUibhpRStop32tOrImXjsU= )
300    RRSIG    DNSKEY 8 2 300 (
20140504081944 20140404071944 62671 net0.net.
6yNf6Rlvg7vNmfpZeA== )

Step 5: A hash of KSKpub is transfered to the parent zone.


Instead of sending the entire KSKpub to the parent zone, a hash called DS-set is created. This is smaller than the key itself and the reason for making a smaller DS-set is to save space in the parents zone files. This DS-set is created as a separate file named dsset-<zonename>. in the same directory as the keys. The content of this file is to be sent to the parent. The routine how to do this can differ depending on which registrar your zone is connected to. I have seen situations where the ds-set is sent to the registrar with email but the most common way to do this is to upload the DS-set to the registrar in a web form. This is how the DS-set can look like:

net0.net.        IN DS 62671 8 1 99511969D3C5A88E49533476E401A6C9FF0FC5C2
net0.net.        IN DS 62671 8 2 6F355545ECDB637BA287C62A075DC28A224AAEDEC6233AA28FC3035C 33557A8D

Disclaimer: This post explains the basic of zone signing. In reality there are a few more things that complicates this even more, like NSEC and double ZSK:s. These topics are to be explained elsewhere. :-)

So, the chain of trust gives that


  • A specific DNS-record is protected with a signature made with ZSK
  • The ZSKpub is protected with a signature made with KSK
  • The KSKpub is protected with the DS-set stored by the parent.

“Above” that the chain of trust continues all the way up to the root zone “.”.



Posted in Uncategorized

Site refreshments

This site has gone thru a number of changes. First of all the look&feel has been modified slightly, but the most changelling changes are in visible, and was done to tighten and raise the security level. This is what happened:


In order to secure the domain nat0.net we have implemented DNSSec. This is done in a “Hidden Master” fashion and the private keys are kept somewhere without direct contact with internet.

Screenshot 2014-03-26 13.36.21

Results from .SE dnscheck validating the domain nat0.net.



The site is SSL only. Not that you can find any secret information here that needs to be protected, but the overall gut feeling that there is an end-to-end security between your browser and this server hopefully makes us all feel better. Of course the cipher suite uses Perfect Forwarding Secrecy. :)


Output from the Firefox plugin "Calomel SSL Validation"

Output from the Firefox plugin “Calomel SSL Validation”

WordPress hardening

A number of action has been taken to make sure that all software run here are as secure as possible. This includes running vurneability scanners to find holes to tighten, as well as a number of best practice security tweaks for Apache and WordPress.

Screenshot 2014-03-26 13.35.48

Besides from specific hardening steps the most crucial thing to keep in mind is to make sure that WordPress as well as all plugins are recent and updated as possible. This is an ongoing step and I try to have a look in the admin panel as often as possible to see if it notifies me about available update for as well WordPress core as the active themes and and plugins.

Network Design

This site is run on a VM. It is placed on a separate DMZ separated from everything else. A full backup is run and securely moved off-site every night for fast recovery if something would happen.

A disaster backup machine is available elsewhere and in case of a major fault everything can be restored to this machine relatively easy.


Posted in Uncategorized