White Paper
Guide to configuring a Virtual Private Network using
Cisco ASA 5500 and 5500-X to conform to
Commercial Product Assurance Security
Procedures
Cisco ASA 5500 and 5500-X security appliances are certified under CESG’s
Commercial Product Assurance (CPA) scheme at Foundation Grade for IPsec VPN
Gateway.
This guide details the steps required to configure a Virtual Private Network (VPN)
using Cisco ASA that conforms to the interim and end-state IPsec profiles and CPA
security procedure requirements.
s affiliates. All rights reserved. This document is Cisco Public.
Introduction
The purpose of this paper is to provide detailed configuration guidance for creating both remote-access and site-tosite VPNs using the Cisco ASA 5500 and 5500-X in line with the CPA security procedures published by CESG. It is
assumed that the reader has a basic understanding of network protocols and terminology, and prior experience of
configuring network devices.
The certificate awarded by CESG provides coverage for all models of the ASA 5500 and 5500-X series of security
appliances and covers the IPsec VPN functionality only. That is to say that other capabilities of the device may be
used but the CPA certificate implies no assurance of these functions. The IPsec VPN Security Characteristics
recognises two cryptographic profiles interim and end-state (also referred to as PRIME) and both profiles are
certified for use where the product supports it. For reference, the two profiles are outlined in Table 1 and 2 below:
Table 1. Interim IPsec Profile
Attribute
Key Exchange
Encryption
Pseudo Random Function
Diffie-Hellman Group
Signature
Algorithm
IKEv1
AES128_ CBC (both IKEv1 and ESP)
SHA-1
Group 5 (1536 bits)
RSA with SHA-1 with X.509 certificates
Table 2. End-State IPsec Profile
Attribute
Key Exchange
Encryption
Pseudo Random Function
Diffie-Hellman Group
Signature
Algorithm
IKEv2
AES-128_ GCM (both IKEv2 and ESP)
HMAC-SHA256-128
Group 19 (256bit random ECP)
ECDSA-256 with SHA256 on P.256 curve with X.509 certificates
The two certified series of ASA offer full support for the Interim IPsec profile but have differing support for the endstate profile defined above. This is due to the capabilities of hardware acceleration used in each of the different
ASA models. Table 3 summarises the support for the various protocols and algorithms.
Table 3. ASA support for End-State IPsec Profile
ASA 5505 , 5510, 5520,
5540 and 5550
ASA 5580
ASA 5512-X, 5515-X, 5525X, 5545-X, 5555-X, 5585-X
IKEv2
Yes
Yes
Yes
AES-GCM
No
Yes
Yes
Yes (IKEv2 Integrity and PRF
only)
Yes
Yes
Elliptic Curve Diffie-Hellman
Yes
Yes
Yes
Elliptic Curve DSA
Yes
Yes
Yes
SHA-2
Figure 1 below illustrates the network topology upon which the remainder of this guide is based. It is focussed on
two use-cases:
•
The ASA appliance as a remote-access VPN gateway terminating connections from the Cisco
AnyConnect Secure Mobility client.
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
•
The ASA appliance as a site-to-site VPN gateway terminating connections from a remote VPN gateway.
In this guide, StrongSwan v5.1.2 is used to simulate a remote VPN gateway device.
It should be noted that the CESG security procedures require that remote VPN gateways and clients must be CPA
certified and at the time of writing the StrongSwan solution has not achieved this status. A full list of CPA certified
devices can be found at http://www.cesg.gov.uk/servicecatalogue/Product-Assurance/CPA/Pages/CPA-certifiedproducts.aspx
Figure 1. Network Topology
10.1.1.0/24
inside
management
outside
172.16.1.0/24
NTP Server
192.168.1.100
192.168.1.0/24
Certificate Authority
192.168.1.50
AnyConnect Client
172.16.1.20
cpa-­‐asa.cpa.cisco.com
Syslog Server
192.168.1.200
StrongSwan VPN
172.16.1.130
Management Station
192.168.1.10
Download software for ASA Appliance
All deployments should utilise the minimum software requirements specified in the security procedures, i.e.ASA
v9.1(2). In line with guidance, later versions of ASA software are automatically certified under CPA and newer
versions of the software cane be utilised if required. All software should be downloaded directly from Cisco.com
and its authenticity should be verified prior to installation. Verification of the image should be performed by
comparing the published MD5 hash with that of the downloaded file.
There are multiple license types available for the ASA with regards IPsec VPN and full details of this can be found
at http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/license/license_management/license.html. From a
basic perspective, an AnyConnect Essentials license is required where Interim ciphers are used and an
AnyConnect Premium license is required where end-state ciphers are to be used.
Initial ASA Configuration
Upon first power up, the ASA appliance will immediately enter an automated setup process that is designed to
configure some of the basic device parameters. This process can be bypassed if required but for the purposes of
this guide, the initial setup process is followed and its output is shown below. Note that the text contained within [ ]
is the default response and will be taken if no other response is provided by the administrator.
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Pre-configure Firewall now through interactive prompts [yes]?
Firewall Mode [Routed]:
Enable password [<use current password>]:
Allow password recovery [yes]?
Clock (UTC):
Year [2014]:
Month [Mar]:
Day [14]:
Time [09:35:20]:
Management IP address [0.0.0.0]:
Management network mask [255.255.255.255]:
Host name [cpa-asa]:
Domain name [cpa.cisco.com]:
IP address of host running Device Manager:
After setup has completed, the administrator will be asked if they wish to enable Anonymous Error Reporting. This
functionality should be disabled (answer ‘No’ to the question).
Once this basic setup is completed, additional configuration can be applied using either the CLI, or the ASA Device
Manager (ADSM) GUI. For the purposes of this guide, CLI will be used. If ASDM is to be used the HTTP server
must first be enabled via the CLI.
http server enable
Access to the ASDM GUI is initially provided via the dedicated out-of-band Ethernet management interface
configured as part of the initial setup process above. The IP address of the management server running the ASDM
GUI must match that configured in the setup process, additional IP addresses can be added through:
http <server IP address> <mask> management
At this stage, there will be no active traffic-carrying interfaces configured and these must also be configured before
the VPN configuration can be completed. An example minimal configuration is shown below. Further details on
configuring ASA interfaces can be found at
http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/general/asa_91_general_config/interface_st
art.html
interface Ethernet0/0
nameif outside
security-level 0
ip address 172.16.1.1 255.255.255.0
!
interface Ethernet0/1
nameif inside
security-level 100
ip address 10.1.1.1 255.255.255.0
Once the initial configuration steps are completed, FIPS mode should be enabled. FIPS mode is enabled by
issuing the command below, which configures the ASA to run in a FIPS compliant state e.g. to run power-on self
test and bypass tests.
cpa-asa(config)# fips enable
To improve connection-per-second performance on the ASA 5510, 5520, 5540 and 5550, large modulus
acceleration can be performed in hardware. Acceleration is optional and is configured by issuing the crypto
engine large-mod-accel command.
Certificate Enrolment
One fundamental requirement for the deployment of the ASA against the CPA requirements is that X.509
certificates must be used to authenticate the IKE (v1 or v2) session. To do this a keypair must first be generated on
the device.
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
To generate a 2048 bit RSA keypair with a label of cpa-asa-rsa:
crypto key generate rsa general-keys label cpa-asa-rsa modulus 2048
To generate an ECDSA keypair on the P256 curve with a label of cpa-asa-ecdsa:
crypto key generate ecdsa label cpa-asa-ecdsa elliptic-curve 256
Accurate time is critical to successful PKI operations, as well as for other important functions such as logging and
audit. Whilst the ASA does have a battery-backed clock, it is strongly recommended that NTP be configured.
ntp
ntp
ntp
ntp
authentication-key 1 md5 <password>
authenticate
trusted-key 1
server 192.168.1.100 key 1
Certificates can be loaded on to the ASA either manually or via the Simple Certificate Enrolment Protocol (SCEP).
It should be noted that SCEP does not support the enrolment of ECDSA based certificates and they must be
manually installed.
For the purposes of this guide, manual enrolment is shown and more information on the use of SCEP can be found
at
http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/general/asa_91_general_config/aaa_certs.h
tml
The trustpoint is configured with a subject-name in the X.500 format and is bound to the keypair that was
generated in the earlier step. Revocation checking must be enabled and in this example, CRLs are used but the
ASA can also utilise OCSP if preferred. The CRL cache is configurable and defaults to 60 minutes. For the purpose
of this configuration, a value of 12 hours has been used. A value of less than 24 hours is required to meet the CPA
security procedures.
It is important that certificates issued to the ASA have the correct KeyUsage and ExtendedKeyUsage attributes set.
KeyUsage must have the Digital Signature bit set and either KeyAgreement or KeyEncipherment.
ExtendedKeyUsage (if present in the certificate) must include the serverAuth or ikeIntermediate attribute value.
crypto ca trustpoint cpa-ca
enrollment terminal
subject-name cn=cpa-asa.cpa.cisco.com, ou=cisco
fqdn cpa-asa.cpa.cisco.com
revocation-check crl
crl configure
cache-time 720
keypair cpa-asa-rsa
The certificate of the certificate authority (CA) must first be authenticated. In manual mode, this is achieved by
issuing the command crypto ca authenticate cpa-ca and then pasting the certificate contents in to the
CLI in Base-64 format:
cpa-asa(config)# crypto ca authenticate cpa-ca
Enter the base 64 encoded CA certificate.
End with the word "quit" on a line by itself
-----BEGIN CERTIFICATE----MIIERjCCAy6gAwIBAgIBATANBgkqhkiG9w0BAQUFADCBhzELMAkGA1UEBhMCR0Ix
EjAQBgNVBAgTCUJlcmtzaGlyZTEQMA4GA1UEBxMHUmVhZGluZzEOMAwGA1UEChMF
<Output Truncated>
-----END CERTIFICATE----quit
INFO: Certificate has the following attributes:
Fingerprint:
2a8f85e0 26a20b53 16446bd1 509df379
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported
Now that the CA certificate has been installed, the ASA can now be enrolled using the crypto ca enrol cpaca command
cpa-asa(config)# crypto ca enroll cpa-ca
Would you like to continue with this enrollment? [yes/no]: yes
% Start certificate enrollment ..
% The subject name in the certificate will be: cn=cpa-asa.cpa.cisco.com, ou=cisco
% The fully-qualified domain name in the certificate will be: cpa-asa.cpa.cisco.com
% Include the device serial number in the subject name? [yes/no]: no
Display Certificate Request to terminal? [yes/no]: yes
Certificate Request follows:
-----BEGIN CERTIFICATE REQUEST----MIIC0jCCAboCAQAwTjEOMAwGA1UECxMFY2lzY28xGjAYBgNVBAMTEWNwYS1hc2Eu
Y2lzY28uY29tMSAwHgYJKoZIhvcNAQkCFhFjcGEtYXNhLmNpc2NvLmNvbTCCASIw
<Output Truncated>
-----END CERTIFICATE REQUEST----The displayed certificate signing request (CSR) can be copied from the command line and imported in to the CA.
The specifics of importing the CSR and subsequent issuing of an identity certificate are beyond the scope of this
document. Once issued, the identity certificate can be manually imported as follows:
cpa-asa(config)# crypto ca import cpa-ca certificate
Would you like to continue with this enrollment? [yes/no]: yes
% The fully-qualified domain name in the certificate will be: cpa-asa.cpa.cisco.com
Enter the base 64 encoded certificate.
End with the word "quit" on a line by itself
-----BEGIN CERTIFICATE----MIID2DCCAsCgAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBhzELMAkGA1UEBhMCR0Ix
EjAQBgNVBAgTCUJlcmtzaGlyZTEQMA4GA1UEBxMHUmVhZGluZzEOMAwGA1UEChMF
<Output Truncated>
-----END CERTIFICATE----quit
INFO: Certificate successfully imported
Note that the certificate can be imported in Base-64 format (as per the above example) or PKCS#12 whereby both
the certificate and key pair can be imported to the device. Certificates can be verified by issuing show crypto ca
certificates cpa-ca command:
cpa-asa#show crypto ca certificates
Certificate
Status: Available
Certificate Serial Number: 02
Certificate Usage: General Purpose
Public Key Type: RSA (2048 bits)
Signature Algorithm: SHA1 with RSA Encryption
Issuer Name:
[email protected]
cn=CPARoot
ou=CPA
o=Cisco
l=Reading
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
st=Berkshire
c=GB
Subject Name:
hostname=cpa-asa.cpa.cisco.com
cn=cpa-asa.cpa.cisco.com
ou=cisco
Validity Date:
start date: 22:18:00 UTC Mar 17 2014
end
date: 22:18:00 UTC Mar 17 2015
Associated Trustpoints: cpa-ca
CA Certificate
Status: Available
Certificate Serial Number: 01
Certificate Usage: General Purpose
Public Key Type: RSA (2048 bits)
Signature Algorithm: SHA1 with RSA Encryption
Issuer Name:
[email protected]
cn=CPARoot
ou=CPA
o=Cisco
l=Reading
st=Berkshire
c=GB
Subject Name:
[email protected]
cn=CPARoot
ou=CPA
o=Cisco
l=Reading
st=Berkshire
c=GB
Validity Date:
start date: 22:13:00 UTC Mar 17 2014
end
date: 22:13:00 UTC Mar 17 2024
Associated Trustpoints: cpa-ca
General VPN Configuration Parameters
As described above, the ASA can be configured with either the Interim or end-state IPsec profile depending upon
the hardware model used or the capabilities of the remote VPN client or device. The following shows how to
configure the Interim profile:
crypto ikev1 policy 10
authentication rsa-sig
encryption aes
group 5
hash sha
lifetime 82800
The following configuration shows how to configure the end-state profile for IKEv2. It should be noted that when
connecting to the Cisco AnyConnect client, only the IKEv2 protocol can be used for key exchange. IKEv2 can be
configured with Interim or end-state ciphers and this ‘hybrid’ mode is acceptable under the CPA evaluation. The
example shows an end-state configuration with interim shown in []. (Note: integrity algorithm is only required for
Interim. If end-state is configured the integrity and encryption functions are performed by the AES-GCM cipher). In
both IKEv1 and v2 examples, the IKE lifetime is set to 23 hours after which time a rekey event will be triggered and
in the case of IKEv1 connections, re-authentication will also be performed forcing a check against the current
certificate revocation list (CRL) as required by the CESG security procedures. A value of 23 hours is chosen to
ensure that the rekey occurs before the 24 hours required by the CESG security procedures.
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
crypto ikev2 policy 10
encryption aes-gcm [aes]
integrity sha
group 19 [5]
prf sha256 [sha]
lifetime 82800
The IKE protocol must be explicitly enabled on the black (outside) interface, the ASA can support both protocols
concurrently if required.
crypto ikev2 enable outside
crypto ikev2 remote-access trustpoint cpa-ca
and/or
crypto ikev1 enable outside
An IPsec transform-set which defines the Interim and end-state ciphers must also be configured and these are
bound to either an IKEv1 or IKEv2 configuration.
crypto ipsec ikev1 transform-set Interim esp-aes esp-sha-hmac
crypto ipsec ikev2 ipsec-proposal PRIME
protocol esp encryption aes-gcm
crypto ipsec ikev2 ipsec-proposal Interim
protocol esp encryption aes
protocol esp integrity sha-1
VPN Configuration for use with Cisco AnyConnect Client
In order to enable AnyConnect access to the ASA, a client image file must first be loaded in to the device. There
are different client image files for different desktop operating platforms (OS X, Windows, Linux) and these must
match the client estate in use. Multiple images can be installed for a mixed client estate. Note that client image files
are not required for the mobile platforms i.e. Apple iOS and Google Android.
Details of how to load the image files in to the ASA can be found at
http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/general/asa_91_general_config/admin_swc
onfig.html#wp1625334
Once the image file has been loaded in to the ASA flash file system, AnyConnect access can then be enabled.
webvpn
anyconnect image disk0:/anyconnect-macosx-i386-3.1.04066-k9.pkg 1
anyconnect image disk0:/anyconnect-win-3.1.04063-k9.pkg 2
anyconnect enable
tunnel-group-list enable
AnyConnect clients are dynamically addressed by the ASA such that they present an appropriate IP address when
communicating with internal systems. A local IP address pool can be configured for this purpose alternatively
addresses can be allocated from an external DHCP server.
ip local pool CPA-Pool 10.1.1.10-10.1.1.50 mask 255.255.255.0
A dynamic crypto map is used to bind the IPsec policy elements together. This includes the IPsec transform-set,
the security association lifetime parameters and perfect forward secrecy (PFS) configuration. Note that the IPsec
security association lifetime is set to 23 hours after which a rekey will occur. A value of 23 hours was chosen to
ensure that a rekey event occurs before the 24 limit required by the CESG security procedures.
crypto dynamic-map CPA-Map 65535 set ikev2 ipsec-proposal PRIME
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
crypto dynamic-map CPA-Map 65535 set security-association lifetime seconds 82800
crypto dynamic-map CPA-Map 65535 set pfs group19
The dynamic crypto-map must then be applied to the black interface.
crypto map outside_map 65535 ipsec-isakmp dynamic CPA-Map
crypto map outside_map interface outside
The tunnel-group (also known as the Connection Profile) is used to define a range of connection parameters which
are detailed at
http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/vpn/asa_91_vpn_config/vpn_groups.html#w
p1062323. The below represents a minimum configuration required to enable AnyConnect access.
tunnel-group CPA type remote-access
tunnel-group CPA general-attributes
address-pool CPA-Pool
default-group-policy CPA-GroupPolicy
tunnel-group CPA webvpn-attributes
authentication certificate
group-alias CPA enable
The group policy is associated with the tunnel-group and defines a range of additional policy elements
(http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/vpn/asa_91_vpn_config/vpn_groups.html#
wp1166190). Note the vpn-session-timeout command will force a VPN session to drop after 24 hours and is
used to force a re-check of the CRL. The session has to be dropped in this way since an IKEv2 rekey event
triggered by setting the security association lifetime does not include re-authentication and the CESG CPA security
procedures require that revocation lists must be checked at least once per day and that connections associated
with revoked certificates must be terminated. The VPN session timeout is service impacting, i.e. the entire VPN
session is dropped and the user must therefore reconnect. However, since most client-to-gateway connections will
tend to be less than 24 hours in duration, this shouldn’t present a significant operational problem. If it does, an
alternative procedural approach to meeting this requirement is described in the sections titled “Manual Procedure
for Disconnecting Peers using compromised credentials” below.
group-policy CPA-GroupPolicy internal
group-policy CPA-GroupPolicy attributes
wins-server none
dns-server value 10.1.1.100 10.1.1.200
vpn-tunnel-protocol ikev2
vpn-session-timeout 1440
default-domain value cpa.cisco.com
Once configured and an AnyConnect client is connected, details of the connection can be shown by issuing the
command show vpn-sessiondb detail anyconnect
cpa-asa# show vpn-sessiondb detail anyconnect
Session Type: AnyConnect Detailed
Username
Assigned IP
Protocol
License
Encryption
(1)none
Hashing
Bytes Tx
Pkts Tx
Pkts Tx Drop
Group Policy
Login Time
Duration
:
:
:
:
:
MacClient
Index
: 1
10.1.1.10
Public IP
: 172.16.1.20
IKEv2 IPsecOverNatT AnyConnect-Parent
AnyConnect Premium
IKEv2: (1)AES128 IPsecOverNatT: (1)AES128 AnyConnect-Parent:
:
:
:
:
:
:
:
IKEv2: (1)SHA1 IPsecOverNatT: (1)SHA1 AnyConnect-Parent: (1)none
0
Bytes Rx
: 25194
0
Pkts Rx
: 298
0
Pkts Rx Drop : 0
CPA-GroupPolicy
Tunnel Group : CPA
11:44:48 UTC Mon Mar 31 2014
0h:02m:03s
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Inactivity
: 0h:00m:00s
NAC Result
: Unknown
VLAN Mapping : N/A
VLAN
: none
IKEv2 Tunnels: 1
IPsecOverNatT Tunnels: 1
AnyConnect-Parent Tunnels: 1
AnyConnect-Parent:
Tunnel ID
: 1.1
Public IP
: 172.16.1.20
Encryption
: none
Auth Mode
: Certificate
Idle Time Out: 30 Minutes
Client Type : AnyConnect
Client Ver
: 3.1.04072
IKEv2:
Tunnel ID
:
UDP Src Port :
Rem Auth Mode:
Loc Auth Mode:
Encryption
:
Rekey Int (T):
PRF
:
Filter Name :
Client OS
:
IPsecOverNatT:
Tunnel ID
:
Local Addr
:
Remote Addr :
Encryption
:
Encapsulation:
Rekey Int (T):
Idle Time Out:
Conn Time Out:
Bytes Tx
:
Pkts Tx
:
1.2
50039
Certificate
rsaCertificate
AES128
82800 Seconds
SHA1
Hashing
: none
Idle TO Left : 27 Minutes
UDP Dst Port : 4500
Hashing
: SHA1
Rekey Left(T): 81275 Seconds
D/H Group
: 5
Darwin_i386
1.3
0.0.0.0/0.0.0.0/0/0
10.1.1.10/255.255.255.255/0/0
AES128
Hashing
:
Tunnel
28800 Seconds
Rekey Left(T):
30 Minutes
Idle TO Left :
507487 Minutes
Conn TO Left :
0
Bytes Rx
:
0
Pkts Rx
:
SHA1
28675 Seconds
30 Minutes
507484 Minutes
28028
329
<Output Truncated>
Site-to-Site VPN Configuration
Configuration for the ASA to communicate to another IPsec VPN gateway follows a similar pattern to that defined
above for AnyConnect. Initially, an access-control list should be created which defines the interesting traffic, that is
the traffic to be encrypted between the local and remote gateways.
access-list remote-GW line 1 extended permit ip 10.1.1.0 255.255.255.0 10.2.1.0
255.255.255.0
The access-list, IP address of the remote gateway and the IKE and IPsec parameters should be bound together
with a crypto map. Note that this connection utilises the PRIME (end-state) IPsec cipher suite defined earlier.
crypto
crypto
crypto
crypto
crypto
crypto
map
map
map
map
map
map
remote-GW-map
remote-GW-map
remote-GW-map
remote-GW-map
remote-GW-map
remote-GW-map
1
1
1
1
1
1
set trustpoint cpa-ca
match address remote-GW
set peer 172.16.1.130
set security-association lifetime seconds 82800
set ikev2 ipsec-proposal PRIME
set pfs group19
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
A connection tunnel-group and associated group-policy should now be created:
tunnel-group remote-GW-TG type ipsec-l2l
tunnel-group remote-GW-TG general-attributes
default-group-policy remote-GW-GP
tunnel-group remote-GW-TG ipsec-attributes
isakmp keepalive threshold 10 retry 2
ikev2 local-authentication certificate cpa-ca
ikev2 remote-authentication certificate
group-policy remote-GW-GP internal
group-policy remote-GW-GP attributes
vpn-tunnel-protocol ikev2
vpn-session-timeout 1440
Note again that the vpn-session-timeout command is used to force a CRL check for an IKEv2 based VPN,
however since the session drop will be service impacting, consideration must be placed on it’s use verses the
implementation of more procedural controls that are described in the section titled “Manual Procedure for
Disconnecting Peers using compromised credentials“ below. This command is not required for an IKEv1 based
VPN since re-authentication is handled during a rekey event triggered by setting the appropriate security
association lifetime in the IKEv1 policy. Once a successful connection has been established, details can be shown
via the show vpn-sessiondb l2l
cpa-asa# show vpn-sessiondb l2l
Session Type: LAN-to-LAN
Connection
Index
Protocol
Encryption
Hashing
Bytes Tx
Login Time
Duration
:
:
:
:
:
:
:
:
172.16.1.130
8
IP Addr
IKEv2 IPsec
IKEv2: (1)AES128 IPsec: (2)AES128
IKEv2: (1)SHA1
IPsec: (2)SHA1
0
Bytes Rx
10:58:12 UTC Tue Apr 1 2014
0h:01m:21s
: 172.16.1.130
: 0
Secure Management and Monitoring
Management and administration of the ASA must be performed either via a dedicated console connection, or via a
secure remote management protocol such as SSH, IPsec, TLS or SNMPv3. For command-line interface
management, version 2 of SSH should be utilised. To enable SSHv2, the RSA keypair should first be created. Note
that no label should be used during generation otherwise the SSH daemon will not start.
crypto key generate rsa modulus 2048
Once the keypair is generated, SSHv2 can be enabled and access can be granted from specific IP addresses (or
ranges) on specific interfaces
ssh version 2
ssh 192.168.1.10 255.255.255.255 management
For ASDM access, a minimum set of security settings should be defined which limit the protocol version and cipher
suites in use. In addition, the ASDM connection should also be authenticated with a trusted certificate, in the
following configuration a new trustpoint was created and enrolled (as per the guidance earlier in this document)
called management-ca and bound to the management interface.
ssl server-version tlsv1-only
ssl encryption aes128-sha1 dhe-aes128-sha1
ssl trust-point management-ca management
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
All administrators accessing the ASA should utilise username and password based authentication. Furthermore it
is necessary to utilise role-based access control to provide differing degrees of access for administrators with
different roles. TACACS+ provides the most effective method for delivering Authentication, Authorisation and
Accounting (AAA) services permitting granular control over CLI command execution and, if required, full accounting
of administrative activity. Full configuration of TACACS+ is beyond the scope of this document but guidance on this
subject can be viewed at:
http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/general/asa_91_general_config/admin_man
agement.html#wp1145571
Logging should be enabled on the ASA and logs should be automatically exported to an external device. Typically
this export will be performed via syslog and the configuration below will enable logging and ensure that events are
sent via the management interface to the host IP address of 192.168.1.200. Events with a severity of
Informational or higher will be sent to the configured syslog server.
logging
logging
logging
logging
enable
host management 192.168.1.200
timestamp
trap informational
To assist in troubleshooting, logging information can also be sent to an internal buffer. By default this buffer is 4096
bytes and when full, old events will be overwritten by new events. Logging can also be enabled for the ASDM GUI.
The following shows how both options can be enabled.
logging buffered Informational
logging asdm Informational
Manual Procedure for Disconnecting Peers using Compromised Credentials
As discussed in the guidance above, an important requirement defined within the CPA security procedures is to
ensure that revocations lists are checked at least every 24 hours and that connections associated with any revoked
certificates are terminated. This can be achieved through the use of security association lifetimes for IKEv1 based
VPNs and through the setting of the vpn-session-timeout 1440 command in the group policy for IKEv2
based connections.
The use of the vpn-session-timeout command may be too problematic for some clients due to the fact that it
will affect traffic flow. Therefore in a case where this is not utilised, an alternative procedural mechanism must be
put in place to identify and disconnect a session associated with a revoked certificate. Further more, outside of this
case, there may well be a legitimate need for an an administrator to actively identify and disconnect a session that
is associated with a compromised certificate, for example a new VPN session that has started before an updated
CRL containing the revoked certificate has been distributed. The following procedure provides one approach to
addressing these two use-cases:
1. Manually clear the CRL cache on the ASA. This is required to ensure that any new incoming connections
that make use of the now compromised certificate are blocked. Naturally this step assumes that the
compromised certificate has been added to the published CRL. The clear crypto ca crls command
is used to manually force the ASA to retrieve a fresh copy of the CRL from the CDP.
2. Review the current connected VPN sessions to determine if the compromised certificate is in use. The VPN
session database stores information from the certificate. For a client-to-site connection, the CN value from
the certificate subject-name field is mapped to the Username field. Since the administrator will have
knowledge of the CN value of the compromised certificate, the connection can be easily identified. The
inbuilt ASA output modifiers can be used for searching e.g. show vpn-sessiondb anyconnect |
begin MacClient will filter the output of the show command and display only those entries which begin
with “MacClient”.
Username
Assigned IP
Protocol
License
:
:
:
:
MacClient
Index
: 6
10.1.1.10
Public IP
: 192.168.1.68
IKEv2 IPsecOverNatT AnyConnect-Parent
AnyConnect Premium
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.
Encryption
(1)none
Hashing
Bytes Tx
Group Policy
Login Time
Duration
Inactivity
NAC Result
VLAN Mapping
: IKEv2: (1)AES128
:
:
:
:
:
:
:
:
IPsecOverNatT: (1)AES128
AnyConnect-Parent:
IKEv2: (1)SHA1 IPsecOverNatT: (1)SHA1 AnyConnect-Parent: (1)none
0
Bytes Rx
: 1684
CPA-GP
Tunnel Group : CPA
15:41:01 UTC Fri May 30 2014
0h:00m:16s
0h:00m:00s
Unknown
N/A
VLAN
: none
3. Using the vpn-sessiondb logoff command e.g. vpn-sessiondb logoff username MacClient,
the administrator can manually disconnect the specific VPN session. This will disconnect the targeted
session and if a new attempt to connect is made, the updated CRL containing the revoked certificate will
prevent it from re-establishing. The full command syntax for the vpn-sessiondb logoff command can
be found at http://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/TZ/cmdref4/v.html#pgfId-1726098
Disposal
To securely restore an ASA to factory defaults and remove all sensitive key material the following commands
should be executed:
crypto key zeroize rsa (or ecdsa)
write erase
The first command will perform a secure overwrite of the public/private RSA or ECDSA keys and the second
command will remove the system configuration including stored certificates.
© 2014 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public.