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.
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.
Introduction The purpose of this paper is to provide detailed configuration guidance for creating both remote-access and site-to-site 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 Algorithm
Key Exchange IKEv1 Encryption AES128_ CBC (both IKEv1 and ESP) Pseudo Random Function SHA-1 Diffie-Hellman Group Group 5 (1536 bits) Signature RSA with SHA-1 with X.509 certificates
Table 2. End-State IPsec Profile
Attribute Algorithm
Key Exchange IKEv2 Encryption AES-128_ GCM (both IKEv2 and ESP) Pseudo Random Function HMAC-SHA256-128 Diffie-Hellman Group Group 19 (256bit random ECP) Signature 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 end-state 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.
• 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-certified-products.aspx Figure 1. Network Topology
outside
StrongSwan VPN172.16.1.130
AnyConnect Client172.16.1.20
Management Station192.168.1.10
Syslog Server192.168.1.200
managementNTP Server192.168.1.100
cpa-‐asa.cpa.cisco.com
inside
192.168.1.0/24
172.16
.1.0/24
10.1.1.0/24Certificate Authority
192.168.1.50
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.
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_start.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.
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 authentication-key 1 md5 <password> ntp authenticate ntp trusted-key 1 ntp 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.html 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
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 cpa-ca 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
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.
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_swconfig.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
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#wp1062323. 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 : MacClient Index : 1 Assigned IP : 10.1.1.10 Public IP : 172.16.1.20 Protocol : IKEv2 IPsecOverNatT AnyConnect-Parent License : AnyConnect Premium Encryption : IKEv2: (1)AES128 IPsecOverNatT: (1)AES128 AnyConnect-Parent: (1)none Hashing : IKEv2: (1)SHA1 IPsecOverNatT: (1)SHA1 AnyConnect-Parent: (1)none Bytes Tx : 0 Bytes Rx : 25194 Pkts Tx : 0 Pkts Rx : 298 Pkts Tx Drop : 0 Pkts Rx Drop : 0 Group Policy : CPA-GroupPolicy Tunnel Group : CPA Login Time : 11:44:48 UTC Mon Mar 31 2014 Duration : 0h:02m:03s
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 Hashing : none Auth Mode : Certificate Idle Time Out: 30 Minutes Idle TO Left : 27 Minutes Client Type : AnyConnect Client Ver : 3.1.04072 IKEv2: Tunnel ID : 1.2 UDP Src Port : 50039 UDP Dst Port : 4500 Rem Auth Mode: Certificate Loc Auth Mode: rsaCertificate Encryption : AES128 Hashing : SHA1 Rekey Int (T): 82800 Seconds Rekey Left(T): 81275 Seconds PRF : SHA1 D/H Group : 5 Filter Name : Client OS : Darwin_i386 IPsecOverNatT: Tunnel ID : 1.3 Local Addr : 0.0.0.0/0.0.0.0/0/0 Remote Addr : 10.1.1.10/255.255.255.255/0/0 Encryption : AES128 Hashing : SHA1 Encapsulation: Tunnel Rekey Int (T): 28800 Seconds Rekey Left(T): 28675 Seconds Idle Time Out: 30 Minutes Idle TO Left : 30 Minutes Conn Time Out: 507487 Minutes Conn TO Left : 507484 Minutes Bytes Tx : 0 Bytes Rx : 28028 Pkts Tx : 0 Pkts Rx : 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 map remote-GW-map 1 set trustpoint cpa-ca crypto map remote-GW-map 1 match address remote-GW crypto map remote-GW-map 1 set peer 172.16.1.130 crypto map remote-GW-map 1 set security-association lifetime seconds 82800 crypto map remote-GW-map 1 set ikev2 ipsec-proposal PRIME crypto map remote-GW-map 1 set pfs group19
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 : 172.16.1.130 Index : 8 IP Addr : 172.16.1.130 Protocol : IKEv2 IPsec Encryption : IKEv2: (1)AES128 IPsec: (2)AES128 Hashing : IKEv2: (1)SHA1 IPsec: (2)SHA1 Bytes Tx : 0 Bytes Rx : 0 Login Time : 10:58:12 UTC Tue Apr 1 2014 Duration : 0h:01m:21s 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
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_management.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 enable logging host management 192.168.1.200 logging timestamp logging 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 : MacClient Index : 6 Assigned IP : 10.1.1.10 Public IP : 192.168.1.68 Protocol : IKEv2 IPsecOverNatT AnyConnect-Parent License : AnyConnect Premium
Encryption : IKEv2: (1)AES128 IPsecOverNatT: (1)AES128 AnyConnect-Parent: (1)none Hashing : IKEv2: (1)SHA1 IPsecOverNatT: (1)SHA1 AnyConnect-Parent: (1)none Bytes Tx : 0 Bytes Rx : 1684 Group Policy : CPA-GP Tunnel Group : CPA Login Time : 15:41:01 UTC Fri May 30 2014 Duration : 0h:00m:16s Inactivity : 0h:00m:00s NAC Result : Unknown VLAN Mapping : 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/T-Z/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.
