help with asa security tightening points

baselzind · ‎06-05-2017

a customer has provided me with some security concerns to resolve , im not sure how to do them as they seem advanced from basic firewall rules , also im not sure if all of them are applicable to the asa firewall? please help

1-Please install a server certificate whose Subject commonName or subjectAltName matches the server FQDN

2-IKE Aggressive mode with pre-shared keys should be avoided where possible. Otherwise a strong pre-shared key should be chosen.

3-Disable the encryption algorithm "DES" (key length of 56 bits) and the key exchange algorithm DH768 (MODP768). Secure replacements are 3DES and DH2048.

Patch:

Following are links for downloading patches to fix the vulnerabilities:

bb531150: MSFT IPSEC (https://technet.microsoft.com/en-us/library/bb531150.aspx)

##this doesn't look applicable on the asa???

4-Please obtain a 2048 bit or more public key length certificate from your Certificate Authority.

5-Please install a server certificate signed by a trusted third-party Certificate Authority.

James Leinweber · ‎06-05-2017

More context from the customer would help, but it appears that they want to set up an IPsec tunnel meeting some external security requirements; this is typical in the USA for either HIPAA compliance (health care data) or PCI compliance (credit card data).

(1), (4), (5) can be satisfied by generating a new certificate signing request on the ASA or elsewhere, having it signed by the CA of your choice, and then importing the completed certificate and its parent intermediate CA certificate into a trustpoint.

(2) and (3) are controlled by settings on the IPsec tunnel.

The Cisco commands related to IPsec tunnels and certificates are complicated enough that I find it easiest to do most of the steps using the ASDM GUI rather than 100% command line over SSH.

If you are generating the Certificate Signing Request on the ASA itself, navigate to Configuration | Device Management | Certificates | Identity Certificates, and click the "Add" button to bring up the "Add Identity Certificate" dialog.

On the Key Pair line use the "New ..." button to add a 2048 bit RSA key (or ECDSA if the other end of the IPsec tunnel can do elliptic curves). I usually set the key pair name to something indicative of the hostname of the firewall and the year the certificate will expire. It's OK to use the same name for the RSA keypair as for the trustpoint you will attach it to. Click the "Generate" button.

Back at the add certificate dialog, on the Certificate Subject DN line, click the "Select ..." button, and fill in attributes like CN, OU, O, C, St, L as needed. Use the FQDN of the outside interface of the firewall as the CN. Back at the "Add Identity Certificate" dialog turn off the "enable CA flag ..." checkbox. Click the "Add Certificate" button.

This will bring up an "Identity Certificate Request" dialog for you to save the new CSR to a file. Send the CSR to your preferred CA for signing, download the certificate and its parents in base64 encoded form.

Back at ASDM and Identity certificates, highlight the pending one and pick the "Install" button.

In the "Install Identity Certificate" dialog, paste in the "-----BEGIN CERTIFICATE---- ... ----END CERTIFICATE-----" block of text you downloaded from your CA. Click "the Install Certificate" button and you should get an information dialog saying "Certificate import succeeded."

In ASDM, switch focus to Configuration|Device Management|Certificates|CA Certificates, and click the "Add" button. In the "install certificate" dialog box fill in the identical trustpoint name that you used for your identity certificate, use either the "Install from a file" or "Paste certificate in PEM format" box to pull in the intermediate certificate that signed your identity certificate. If you downloaded the "reversed intermediate/root" layout from your CA that is probably the first certificate in the chain. I like to run the file with the PEM text through "openssl x509 -in ... -noout --text" on a nearby Linux box to verify I have the right one before doing the import. Click "install certificate".

You should now have ended up with a fully configured trustpoint containing a public/private key pair, and identity certificate, and its parent certificate. If you need to back this up, I like to use CLI "crypto ca export TRUSTPOINT_NAME pkcs12 PASSWORD" for that.

The resulting certificate can be used for TLS connections in an "ssl trustpoint ..." statement, and also for securing IPsec tunnel connections if you are using IKEv2 negotiations.

Your security-minded customer might also appreciate things like

ssl server-version tlsv1.2
ssl client-version tlsv1.2
ssl dh-group group14
ssl ecdh-group group20

ssh version 2
ssh key-exchange group dh-group14-sha1

Back on the Basic settings, you can prevent all the the weak ciphersuites by using the "Select ..." button next to "IPsec Proposal" to just include one or two good ones. With 2048-bit RSA keys, I use e.g. "ESP-AES-128-SHA". When I upgrade to newer firmware I'll probably switch to something involving EC keys instead of RSA and SHA256 instead of SHA1.

Warning: my experience with IKEv2 negotiation combined with both Time and Traffic Volume limits on SA lifetime has been that the resulting IPsec tunnels are unstable. I was having to reload firewalls every 3-7 weeks until I reverted to IKEv1 (firmware 9.4 series); your mileage may vary.

Hope this helps,

-- Jim Leinweber, WI State Lab of Hygiene, University of Wisconsin - Madison

baselzind · ‎06-06-2017

so point 2 and 3 affect the VPN that the customer already have up? and changing them would need a change at the other sites as well? also are you saying you dont recommend the 2 and 3 changes because it will make the vpn unstable?

James Leinweber · ‎06-06-2017

The instability problems I had were related to renegotiating SA's using IKEv2 instead of IKEv1. I'm not sure if the problem is fixed in newer firmware or not; I'm still running 9.4 series.

In terms of (2) IKE aggressive vs main mode, and (3) avoiding 3DES, these will not affect the stability of the IPsec tunnel, but will improve its security. As you note, both ends of the tunnel have to make the same changes.

-- Jim Leinweber, WI State Lab of Hygiene

baselzind · ‎06-07-2017

for the first point

"1-Please install a server certificate whose Subject commonName or subjectAltName matches the server FQDN"

i was told that the customer is supposed to give the certificate issuer any FQDN as long it is in this format [ "any name",customerdomain.com ] correct or is there a name i should match from the asa???

James Leinweber · ‎06-07-2017

I'm not sure what the customer is trying to do here, so my response might be unhelpful.

If they want a root CA to sign a certificate for the customer's firewall device, so that TLS or VPN connections behave better, then they need to pick a hostname which is under some DNS subdomain they control. The name is presumably up to the customer. If they want a so-called "wildcard" certificate for a name like "*.example.com" with a literal asterisk in place of the host part of the name, which can be used to do TLS for all possible subdomains, that seems like an unlikely choice for a firewall. Normally that kind of generic name would be found on some DMZ web proxy, if it exists at all.

What I do have on my own firewalls is certificates with "Subject Alternate" DNS names for each interface that TLS connections are coming in on. I use the DNS name of the outside interface as the canonical name.

-- Jim Leinweber, WI State Lab of Hygiene

baselzind · ‎06-12-2017

it turns out the customer doesn't use VPN , so i guess point [2 , 3] for IPsec are not needed , this leave me with installing a certificate on the asa firewall , should the customer buy it ? is it important ? my colleagues are telling me it is only cosmetic?