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).

ASA-licensing

 

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. (
2014020320
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    89.160.63.216

www                IN    3600    A    89.160.63.217

 

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


Knet0.net.+008+08565.key
Knet0.net.+008+08565.private
Knet0.net.+008+62671.key
Knet0.net.+008+62671.private

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 (
AwEAAdNMI9iWcmphYDJPqAHxuAkduG7uF1UN
y/OKrumEXxOZfGydiEDk7++Yx75UxOWsAvG7
MIUXQWthGj59XfRAIfKxcJr+XhpnQdX2rtjP
Aj8vzJ2ZB/c8iKmYzUQ85pUoHM6TN+/1wfAR
FfWK1+FmpGPB0pYBDWpLUmDbJAJkREQz
) ; ZSK; alg = RSASHA256; key id = 8565
300     DNSKEY  257 3 8 (
AwEAAd8BTQ9YX9b+Ve4bYhOCdtAC9AzVkb4q
eTc0dlXXcv2ALeOb2sdPmMS6DNSjCorFx0zH
ZhUxYVMh1Mtg975wgkUa3mLEWExq7F2+1kPR
h5yDdmNjJnrNypTcXfr6gJ0rZs+nm8BItLeU
hwLZ8YfIK6zZzKWTKa6DgR40GTt0jyjy9wfY
VxIp/bB7HIcMsRrooDG5ZiwGmLPF72oNwN1r
/C+uDCoeaPKghbStjnbcu6I+O5+dcvm9AWA3
cPhwCacSJLGdPxCGeGu5JBDMAjOjXAqeWAcG
yqn3JX85s4pII8hwIqRalFjpgZihfBJw8PME
BWSIO0/h+AQp/e3coWkNy5U=
) ; 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.
wLckeJ1hagRD6oKQN49FBJl8Z5OURJWvNvqV
KkjI4F31XUQPRVBxc1uO9yOuyznf7L6UnaPx
ltyCoFZ2hZukm4T/I8CMQ4KIDb5tSj51n8uO
oNyC764ACd3y3BEa/yNrIzjTnrlWQYvDtGP1
ifd1ZN3ytmwK2+mAJzEnwt8meFs= )
3600    NS    ns.net0.net.
3600    RRSIG    NS 8 2 3600 (
20140504081944 20140404071944 8565 net0.net.
R2KDBRWRq5IJkQVGSR/3L23aGGwJPof7/E7T
LKMkYvpfdIRN6Ftq3armgB7n8i9VYDYf5p+4
k7cBDp6X/Fkk/P0H3jWpqACjRfXR/8mdtZhC
9tfxDTo7GVZE0Nj+ieDiStcDU6MU8YQ5l78B
t5VxrQ7mJjSt0MMZImiUaI4XkfM= )

ns.net0.net.        300    IN A    89.160.63.216
300    RRSIG    A 8 3 300 (
20140504081944 20140404071944 8565 net0.net.
D50NhRl2SWmBgGjTrCbUfBG/Vubbn7AWzBT+
ApwWYNG+AvjVOxcGH0Cn/ghABp3VtLFDlEVq
zwhea3A4A/qwRCN2VEKoBg06Z2yGBcg+oC3f
/TcH1mIEcIcaOi/j59o5p0W3TeLV1lOVAdTY
eUfdRHjeBCKb6w6CWgPlpx4x0AM= )
www.net0.net.        3600    IN A    89.160.63.217
3600    RRSIG    A 8 3 3600 (
20140504081944 20140404071944 8565 net0.net.
jN80xlpzHnEt0A/H4lX//RC9coqRUPDpe1Lf
6k9SJRmJHg60MbIIlwGmIHjMhWq5VtTZQPIz
HpTbqVIxukJSLLWXTkXykZLPCRE2Xnm3QlTv
hMYPFX1LUqYaGzdbcjRnFFGmq44lOiCSYAre
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.
TSEt2dwC3EU1oUibSnA7wLjUgseTrt3/VpRZ
0wv0pTQ3ikTvYB6q0iHPzZuWDGvLKUf8wqMS
mG6RpbVRu16gFuAjsDDmc3JXdhbBOGj0dRQW
PZVH++NkFJYDe2E8z3T5dcu7EdvN7iPKWlKJ
QyLcEBUibhpRStop32tOrImXjsU= )
300    RRSIG    DNSKEY 8 2 300 (
20140504081944 20140404071944 62671 net0.net.
1kg2TK6JVOOiziies2qPRi8mDFPkgM2kiq5c
+tOj1oQoDX+RySxxW9GpKYKdOJJQVAh63nL4
gekJEmGrLEHot68tzhA1UBbIABHSezjlj6z6
NKy/xAzKl6Rc0u1eoNaWEX/kw4dkY4dVqc9i
71N617FLQI0lD1rzF/7KTc94F+49n/9dvzg+
LSvqdIPovwhruIZoU5i/XDwVai/pu2eYEPw9
uGD5KShoCCefJh+UBemHLKtB/PpOhEgRx4hn
ud1ezfyO/KJAyi0dvEDo7UHfbxpW60zEZEC2
tYH9ycLO1snLJvCZ6jz6URUiK8QqP/UicpEp
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:

DNSSec

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.

 

SSL

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

Sha1 is dead! Or at least dying…

As you all hopefully know by now, Microsoft released a security update that disallow the use of RSA keys with a key lenght below 1024 bits. And now there is a new important security advisor from MS with news on certificates in the platform.

This time they are issuing a recommendation to discontinue the use of SHA-1 as a hash algorithm in certificates. SHA-1 was published in 1995 and as we all know, a lot of things have happend in the IT industry since then. And considering that NIST recommended to move away from SHA-1 as early as 2005 we probably should have done this a long time ago. But as a matter of fact, up to 98% of the certificates in use today uses SHA-1 tells us that is not the case.

So how will this security advisory impact us? Well nothing will happen right away, it will take a couple of years before MS will stop the use of these certificates. But the SHA-1 deprecation policy says the following:

Will apply to Windows Vista and later, and Windows Server 2008 and later. (All supported OS)
CAs must stop issuing new SHA-1 SSL and Code Signing certs by 1 January 2016.

SSL Certificates
Windows will stop accepting SHA-1 end entity certificates by 1 january 2017. This means that all valid SHA-1 SSL certificates must be replaced at this date.

Code Signing Certificates
After 1 January 2016 Windows will stop accepting SHA-1 code signing certificates. But there will be an exception. If the signed code have a time stamp it will still be accepted until further notice. So the first step is to make sure that all code from now on should be time stamped when signed. And then you should issue a new code signing cert with SHA-2 as soon as possible.

Microsoft Root Certificate Program
Members in the Root Certificate Program will not be allowed to issue certificates using the SHA-1 hashing algoritm for the purpose of SSL and code signing after January 1 2016

MS Security Advisory 2880823 (http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2880823-recommendation-to-discontinue-use-of-sha-1.aspx)

The effect on Microsoft Root Certificate Program. (http://technet.microsoft.com/en-us/security/advisory/2880823)

Tagged with: , , ,
Posted in Uncategorized

Ironport WSA https-certificate import

Memento: When exporting a root certificate (with its private key) from a Microsoft Root CA you get a pkcs#12-file (.pfx). In order to import this cert and key into the Cisco Ironport WSA as a root certificate you need to do this:

 

  1. Move the .pfx-file to a machine with openssl installed
  2. Run “openssl pkcs12 -in myinfile.pfx -out myoutfile.pem -nodes
  3. When prompted enter the password you used when exporting the cert/key on the CA server.
  4. Open the myoutfile.pem file in a texteditor.
  5. Copy the lines beginning with (and including!) the line “—–BEGIN CERTIFICATE—–” and until the end of the line “—–END CERTIFICATE—–”.
  6. Paste that content to a new file and save it to something like cert.pem
  7. Open the myoutfile.pem again in a text editor.
  8. Copy the lines beginning with line “—–BEGIN RSA PRIVATE KEY—–” and ending with the line “—–END RSA PRIVATE KEY—–”.
  9. Paste the content to a new file and save it to something like key.pem.
  10. Select the files as Certificate and Key respective in the WSA GUI under Security Services-HTTPS Proxy-Edit Settings…-Root Certificate for signing-Use Generated Certificate and Key.

I have googled this so many times now. Hopefully google will index this rapidly and next time I google it I will see my own blog post as the first search result. :-)

Memento is… oh sorry, forgot what to write here…

Posted in Uncategorized