Downloads |
This guide describes the deployment of different security features based on Cisco IOS® Software used in a Cisco Systems® internal Enterprise-Class Teleworker (ECT) VPN deployment. This deployment can be used as a baseline for similar remote-access, site-to-site VPN, and managed service provider VPN deployments.
Purpose and Scope
This guide explains how the layered security approach has been implemented in the Cisco® internal ECT solution. This document does not explain all the alternative designs or different configurations.
Introduction
Following are the major features included in this guide:
User and Device Security and Authentication
• Authentication Proxy
• IEEE 802.1x-based user authentication
• Secure Address Resolution Protocol (ARP)
Router Security and Authentication
• RSA keys and certificates
• Public key infrastructure (PKI) with authentication, authorization, and accounting (AAA)
• RSA key erase on password recovery
• RSA key locking
• Disabling password recovery
• Restricting Console Access
• Disabling Console Access
Network Security
• Stateful Firewall-Legacy
• Stateful Firewall-Zone Based
• Intrusion Prevention System (IPS)
Domain Separation
• Split Domain Name System (DNS)
Network Architecture
Figure 1 shows the basic architecture of the ECT solution.
Figure 1. Basic Architecture of the ECT Solution
The spoke router maintains two VPN connections to the corporate network. The first connection is called the management tunnel and is used exclusively for managing the network. The management network hosts all the servers and tools needed for maintaining the network (AAA server, certificate server, provisioning/management tools, and so on). The second connection carries the data traffic to the corporate network. Most of the security features are configured on the spoke router. The spoke can be configured in split-tunneling or non-split-tunneling mode. In split-tunneling mode, only the traffic destined for the corporate network is routed to the VPN tunnel; the remaining traffic is routed directly to the Internet service provider (ISP). In non-split-tunneling mode, all the traffic is routed via the corporate network regardless of the traffic's destination.
The security features work at different layers, and they can be loosely classified into three categories: user/device authentication, router security, and network security.
Hardware and Software
This guide is written based on a Cisco 871 Integrated Service Router (ISR) with wireless running Cisco IOS Software Release 12.4(15)T1 (c870-advipservicesk9-mz.124-15.T1). The FastEthernet4 interface connects to the ISP. Two internal networks are configured using Bridged Virtual Interface (BVI), namely BVI1 and BVI2. They are called as "Home" network and "Guest" network in the rest of the document. The devices like IP phone, computer etc. which needs corporate access is connected to Home network. Other devices which do not need corporate access are connected to Guest network. Guest network is optional. For other Cisco router platforms, the sample configurations may need minor modifications.
User and Device Security and Authentication
The security and authentication features mainly ensure that only authorized users and devices get access to the corporate network.
Authentication Proxy
A remote office network may not be physically as secure as the corporate environment. This means that non-employees also may have access to the devices connected to the spoke router. Authentication proxy provides a way to identify legitimate users and limit access to the corporate network only to them. Auth-proxy can be used to provide role based access permissions to the users.
All access to the corporate network is denied by an inbound access control list (ACL) applied on the inside interface of the router. To initiate the authentication process user will have to first access a corporate website using a Web browser. This access will be intercepted by the router and will be replaced with a web based user authentication prompt. The user will be allowed to have access to the corporate site only if correct credentials are provided. The credentials are verified by a RADIUS server. Upon verification of the credentials, appropriate permit access control entries (ACEs) are downloaded and applied on the spoke router, based on the credentials. It is possible to download a "permit ip any any" for all users or to download specific ACEs based on the group to which the user belongs. This way the network administrator can implement role-based access control.
The authentication process begins when a user makes an HTTP access. FTP and Telnet can also be configured to initiate the authentication. The traffic that initiates authentication process is defined by an intercept ACL.
The authenticated sessions can be configured to time out after an absolute timeout or inactivity timeout, whose values are configurable. An inactivity timer will trigger if there is no traffic from the client computer for the configured period of time. Once any of the timers is triggered, the authentication cache will be cleared, and the user will have to re-authenticate.
If a computer is disconnected from the network, the authentication cache will remain until the inactivity timeout occurs. Before the cache is expired, a different computer can use the same IP address and continue to use the authenticated session that already exists for that address. A smaller inactivity time reduces the chance of this happening.
Authentication Proxy Sample Configuration
aaa new-model
aaa group server radius authproxy
server-private <ip address> auth-port 1812 acct-port 1813 key 0 <key>
ip radius source-interface BVI1
!
aaa authorization auth-proxy default group authproxy
!
ip inspect fw test tcp
ip inspect fw test udp
ip inspect fw test rtsp
ip inspect fw test tftp
ip inspect fw test skinny
ip inspect name test sip
ip inspect name test sip-tls
!
ip admission auth-proxy-banner file http://10.34.250.98/disclaimer.htm
ip admission auth-proxy-banner http ^
This is the authentication proxy challenge
^
ip admission max-login-attempts 6
! Configure 30 minutes of inactivity timeout.
! proxy_acl is the intercept ACL
ip admission name pxy proxy http inactivity-time 30 list proxy_acl
!
ip admission name test_proxy proxy http list proxy_acl
interface BVI1
description inside interface
ip inspect fw in
ip access-group proxy_inbound_acl in
ip admission test_proxy
!...
ip access-list extended proxy_acl
remark --- Auth-Proxy ACL -----------
! Deny lines are used to bypass auth-proxy
deny tcp any host 10.10.200.1 eq www
! auth-proxy will intercept http access matching the below permit lines
permit tcp any 10.10.30.0 0.0.255 eq www
...
!
ip access-list extended proxy_inbound_acl
remark --- Auth-Proxy Inbound ACL which blocks the traffic ---
! Allow access to certain protcols
permit udp any any eq domain
permit udp any any eq netbios-ns
permit udp any any eq netbios-dgm
permit udp any any eq 5445
permit tcp any any eq 5060
permit tcp any any eq 5061
permit tcp any any eq 2000
permit tcp any any eq 2443
permit udp any any eq tftp
! Block corporate subnets. If split tunneling is not enabled denying
! all traffic using
! "deny any any" is sufficient
deny ip any 10.0.0.0 0.255.255.255
...
...
Permit ip any any ! if split tunneling is enabled
!
IP Phone Consideration
IP phones cannot display authentication proxy prompt. Therefore it cannot be authenticated using auth-proxy. One solution to this is to use Context Based Access Control (CBAC). IP phones usually download initial configuration using TFTP. In that case TFTP needs to be opened in the inbound ACL. If the IP phone is using Skinny Client Control Protocol (SCCP), then UDP port 2000 needs to be opened. IP inspection will dynamically open holes for RTP streams when a phone call is made. By opening only UDP 2000, access control is not diluted much and IP phone works without doing auth-proxy. Same thing works for SIP phones. For SIP phones open UDP 5060 and 5061.
UDP port 5445 needs to be opened if Cisco Unified Video Advantage (CUVA) is enabled on the IP Phone.
Important Authentication Proxy Diagnostics Commands
IEEE 802.1x Based Device Authentication
Using this feature, all IP devices connecting to the router are subject to 802.1x based credential validation. This works only on the switch ports of the ISR router platforms. The device will not get IP address until the credentials are validated. Once validated, the port becomes active and the device gets network access. If the validation fails the port is shut down.
This authentication requires an 802.1x client (called supplicant) running on the device. Many devices like IP phones do have 802.1x supplicant. In order to accommodate client less device, guest VLAN feature can be enabled. Guest VLAN typically has less access privilege than the primary VLAN. In the case of ECT guest VLAN will be part of BVI2.
Cisco IP Phones has the capability to request for voice VLAN. If voice VLAN is enabled on the router, Cisco IP phone will be automatically placed in that VLAN and bypass 802.1x authentication.
If just user authentication is the goal, then auth-proxy will be sufficient. The following table gives a brief comparison of Authentication Proxy and 802.1x authentication feature.
Authentication Proxy Vs. 802.1x Comparison
For more information about this feature and its configuration on ECT, refer the deployment guide named "Deploying 802.1x-Based Port Authentication on the Cisco ECT Solution" (Reference 6). All the ECT deployment guides can be found at http://www.cisco.com/go/ect.
Secure ARP
Secure ARP locks the DHCP assigned IP address to a MAC address. The DHCP server will not re-assign this IP address to another device unless it has received a DHCP release. During an active lease a different IP address cannot overwrite the ARP entry. This reduces the possibility of IP address spoofing. With this a second computer cannot take control of the IP address by manually configuring it on the interface.
Secure ARP Configuration
ip dhcp pool client
update arp
Router Security and Authentication
It is assumed that the router at a remote office or a home office has a certain level of physical security. But it is not as safe as sitting inside an office building where the access is limited to only employees. The following features add some extra security to the routers to compensate.
RSA Keys and Certificates
The routers are configured with RSA key pairs for the purpose of VPN. Digital certificates are issued to each router. Digital certificates are very difficult to spoof. Since the certificates are used for PKI authentication, it gives an assurance that no un-authorized spokes will be connected to the VPN. Unless marked as exportable, the RSA keys cannot be exported. This means RSA keys cannot be transferred to another router. Cisco IOS Software supports certificate servers from many vendors, including one based on Cisco IOS Software.
Given below is the basic explanation of the feature. For more details about the configuration and deployment options refer the deployment guide "Public Key Infrastructure Integration with Cisco Enterprise-Class Teleworker Solution" (Reference 8) and "Public key Infrastructure Resource Page" (Reference 9).
Certificate Authority (CA) Trust Point Configuration for Cisco IOS Software Certificate Server
ip host test-ca <ip address>
crypto pki trustpoint testtp
enrollment url http://test-ca:80
! Include serial number in the certificate request
serial-number
! Do not check CRL for peer certificates
revocation-check none
! Source the traffic from Ethernet0 for any communication with
! Cert server
source interface BVI1
! Re-enroll automatically when the current cert is 75% of its age
auto-enroll 75
Generating RSA Keys
This command is executed in configuration mode.
crypto key gen rsa general-keys modulus 1024
! Refer the documentation guide for other options.
Authenticating the CA Server
This command is executed in configuration mode. The CA server's root certificate is downloaded as a result of this command.
crypto pki authenticate testtp
Enrolling with the New CA Server
This is also executed in configuration mode. After this the router gets its public key signed by the CA server, which will be its certificate.
cry pki enroll testtp
Conditional CRL Checking
In some cases CRL checking may need to be skipped for some peer routers. ECT is an example. On ECT solution, if the CRL is hosted on the management network, the spoke router will not be able to download the CRL without first establishing the management VPN tunnel. So the CRL checking needs to be skipped when establishing management VPN tunnel. All future VPN establishment with other hubs and spokes (in the case of spoke to spoke tunnel is enabled) will continue to check CRL once it is downloaded though management tunnel.
Below configuration example skips CRL validation for a peer certificate, if the "subject-name" of the certificate contains "mgmthub1.mydomain.com" or "mgmthub2.mydomain.com".
crypto pki trustpoint testtp
...
revocation-check crl
match certificate mgmt-hub skip revocation-check
!
crypto pki certificate map mgmt-hub 1
subject-name co mgmt-hub1.mydomain.com
crypto pki certificate map mgmt-hub 2
subject-name co mgmt-hub2.mydomain.com
Note: Instead of subject-name, other fields in the certificate can also be matched in the rule. "match certificate ..." command has other options also which are not mentioned in this document.
Some Important Diagnostic Commands
Some basic diagnostic and show commands for PKI.
PKI-AAA Authentication and Authorization
The hub router can be configured to do certificate revocation list (CRL) validation for each peer certificate. PKI-AAA authorization is an alternative way to validate the peer certificates. This can also work as an additional check along with CRL validation. The router will extract a specified field from the peer certificate's subject and send it to a RADIUS server. This is sent as the username, and the password is fixed as "cisco." Which field should be sent as the username is specified in the trustpoint configuration.
If the RADIUS server has an entry for this username with password set as "cisco," the query will return success along with the following Cisco AV pairs configured for that username:
• Certificate usage (cert-application)
• Certificate trust point (cert-trustpoint)
• Serial number (cert-serial)
• Certificate lifetime (cert-lifetime-end)
Following is a sample Cisco AV pair configuration which can be configured on a Cisco Secure ACS:
cisco-avpair = "pki:cert-application=all"
cisco-avpair = "pki:cert-trustpoint=msca"
cisco-avpair = "pki:cert-serial=16318DB7000100001671"
cisco-avpair = "pki:cert-lifetime-end=1:00 jan 1, 2003"
The RADIUS server will return failure if the record is not found or password is not "cisco." The peer certificate will not be accepted if the RADIUS request failed.
Among the above AV pairs only cert-application is mandatory. If this AV pair not returned or the value of the AV pair is "none," then the certificate is rejected. For the certificate to be accepted, the value of the cert-application should be "all" (more specific keys words may be supported in future; "all" means the certificate can be used for any purpose including PKI).
If any or both of "cert-trustpoint" and "cert-serial" are specified, the router will compare these values with the trust-point name and serial number extracted from the peer certificate. The certificate will be accepted only if these fields match.
The "cert-lifetime-end" value can be used to bypass the actual expiry date of the certificate. This is useful if an expired peer certificate needs to be accepted. A different date can be specified in the AV pair and the router will use this for the expiry date calculation.
With the PKI-AAA feature the hub will accept a certificate only if it has an entry on the RADIUS server. The certificate can be temporarily disabled by setting the "cert-application" value to "none."
PKI-AAA Configuration
aaa new-model
aaa group server radius pki-aaa-server
server <ip addr> auth-port 1812 acct-port 1813
!
aaa authorization network pkiaaa group pki-aaa-server
!
crypto pki trustpoint testtp
enrollment mode ra
enrollment url http://test-ca:80/certsrv/mscep/mscep.dll
authorization list pkiaaa
authorization username subjectname commonname
Diagnostics
Use "debug crypto pki transactions" regular AAA and RADIUS debugs to diagnose problems. The logs on the RADIUS server also help.
For more details about this feature refer deployment guide named "Public Key Infrastructure Integration with Cisco Enterprise-Class Teleworker Solution" (Reference 8).
RSA Key Erase on Password Recovery
The spoke routers are centrally managed. Therefore there is no need for the end user to know the router administrator password. If any user tries to do a password recovery, then the RSA key becomes un-usable. The password recovery process involves booting the router without loading the router configuration and then copying the start-up configuration to running configuration. During this process, the RSA private key will not be copied to running configuration. Without the private key the router will not be able to establish the VPN session. If the user issues a "write mem" at this point, the RSA private key will be permanently lost. User will need to contact the administrator to restore VPN connectivity.
This does not have any specific configurations. It is enabled by default and cannot be disabled.
RSA Key Locking
This feature locks RSA key using the specified password. Once locked it needs to be unlocked before it can be used for negotiating VPN sessions. The key will be automatically locked after a reboot. This feature is useful if the router is to be installed in insecure places or needs to be shipped fully configured. If the router gets stolen, it cannot be used to establish VPN to corporate without giving the correct unlock password. If the router falls into wrong hands, this will act as a deterrent from getting illegal access to VPN.
Generating an RSA Key Pair
test-router(config)#crypto key generate rsa general-keys modulus 1024
The name for the keys will be:
test-router.cisco.com
test-router.cisco.com
% The key modulus size is 1024 bits
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
test-router(config)#
Encrypting the RSA Key
test-router(config)#crypto key encrypt rsa passphrase <pass-phase>
Encrypting keypair labeled test-router.cisco.com
WARNING: Configuration with encrypted key not saved.
Please save it manually as soon as possible to
save encrypted key
test-router(config)#
Now the key is encrypted. The output of "sh cry key my rsa" will have the string "*** The key is protected and UNLOCKED. ***."
Locking the RSA Key
test-router>crypto key lock rsa passphrase <pass-phase>
Now the key is locked. The output of "sh cry key my rsa" will have the string "*** The key is protected and LOCKED. ***."
Unlocking the RSA Key
test-router>crypto key unlock rsa passphrase <pass-phase>
If there are more than one set of keys on the router, it can be selectively locked/unlocked by specifying the name of the set in the command line.
crypto key encrypt rsa name <key name> passphrase <pass-phrase>
The user can also use the Web interface to unlock the RSA key. User needs to access the URL http://<router's ip address>/exec/crypto/key to do this. The locking/unlocking can be done by a privilege 1 user. If the user who is unlocking the key is different from the administrator, a privilege 1 user account can be created on the router. This will have to access the URL http://<router's ip address>/level/01/exec/crypto/key/.
user <username> priv 1 pass <password>
ip http server
ip http authentication local
Diagnostics
show crypto key mypubkey rsa - Displays the RSA key status.
Disabling Password Recovery
Cisco IOS router provide the facility to recover from a forgotten password. An IOS savvy end user may be able to look at the router configuration using this method. This can be prevented by disabling password recovery. This is done by configuring "no service password-recovery" on global configuration.
config terminal
test-router(config)#no service password-recovery
WARNING:
Executing this command will disable password recovery mechanism.
Do not execute this command without another plan for password recovery.
Are you sure you want to continue? [yes/no]:yes
test-router(config)#
Restricting Console Access
Security policy of some customers may require controlling the access to the console port. There are two ways to control the console access, password protection and locking down.
By enabling console access authentication the console access will be password protected. User will be prompted for username and password. Access is granted only if the correct credentials are entered. The router can be configured to verify with the local credentials configured on the router or with a RADIUS or TACACS server. Doing local authentication will ensure that console access is possible even if the network connectivity is down.
Configuration for Local authentication
aaa authentication login default local
username <username> password <password>
!
Configuration for RADIUS based authentication
aaa group server radius myradius
server-private 10.32.227.161 auth-port 1812 acct-port 1813 key <server password>
!
aaa authentication login default group myradius
! "aaa authentication login default local group myradius" will check
! with both local and RADIUS user database.
Disabling Console Access
This method completely locks down the console. Once it is enabled the only way to access the router will be network based mechanisms like ssh or telnet. This means once the network access is gone router becomes inaccessible. Therefore extreme caution should be taken when deploying on router which can loose its network access often. E.g. a user who changes his ISP to a different IP address assignment, like DHCP to static. On 870 platforms pressing the reset button for six to ten seconds while the router is rebooting, will reset the router to factory default configuration. Other platforms do not provide this option. This means 870 platforms can be recovered by using this reset procedure.
Configuration for Locking the Console Port
menu disable clear-screen
menu disable title %Console Disabled%
line con 0
autocommand menu disable
! "clear line 0" will clear the console connection if a connection
! is active. But this needs to be done from a ssh or telnet window.
Network Security
Stateful Firewall-Legacy Configuration
The spoke router and the network behind the spoke should be considered as part of the corporate network. So an attempt should be made to provide the same level of security as for the corporate firewall.
An access list is configured on the outside interface (which is connected to ISP) such that no traffic initiated from outside (Internet) is permitted into the network. Only VPN traffic and some basic traffic like ICMP, DHCP, NTP, and so on are permitted into the router.
PAT is configured on the outside interface such that all traffic originated from inside network to Internet is translated into single public IP address. PAT is configured so that multiple devices behind the router can share the same IP address assigned by the ISP.
IP inspection (context-based access control, or CBAC) is configured on the inside interface. When traffic is originated from inside toward the public network, CBAC selectively opens holes in the firewall ACL for the return traffic.
CBAC and PAT are needed on the spoke router only if split tunneling is allowed. Otherwise all traffic is directed via the corporate network. No firewall or address translation is configured between the corporate network and home network (which is the tunnel interface).
Stateful Firewall Configuration
ip inspect name fw tcp
ip inspect name fw udp
ip inspect name fw realaudio
ip inspect name fw rtsp
ip inspect name fw tftp
ip inspect name fw ftp
ip inspect name fw h323
ip inspect name fw smtp
ip inspect name fw skinny
ip inspect name fw sip
!
interface BVI1
description inside interface - Secure network with corporate access
ip address 10.10.100.1 255.255.255.240
ip nat inside
ip inspect fw in
!
interface BVI2
description inside interface - Gust network without corporate access
ip address 10.10.200.1 255.255.255.240
ip nat inside
ip inspect fw in
!
interface FastEthernet4
description outside interface
ip address dhcp
ip access-group fw_acl in
ip nat outside
!
ip nat inside source list nat_acl interface Fastethernet4 overload
ip access-list extended nat_acl
permit ip 10.100.100.0 0.0.0.15 any
permit ip 10.100.200.0 0.0.0.15 any