Chapter 12: Case Studies

admin — Mon, 15 Mar 2010 10:24:42 +0000

Having Defense-in-Depth mechanisms and tools in place is important to any organization regardless of its size. This chapter includes three different case studies explaining how a small (Company-A), medium (Company-B), and large enterprise (Company-C) apply the best practices learned in all previous chapters. These case studies provide you with an in-depth and objective analysis of security technologies and techniques applied in different environments. The intent is to help you identify and implement practical security strategies that are both flexible and scalable.

Case Study of a Small Business

This section uses Company-A as an example. Company-A is a small web development company based in Raleigh, North Carolina. Its office in Raleigh hosts 35 employees. The user population is composed of sales, marketing, finance personnel, and several web developers. Figure 12-1 illustrates the network architecture and topology of the Raleigh office of Company-A.

The Raleigh office has a simple network architecture. Client workstations are connected to an access switch and then connected to the Cisco Adaptive Security Appliance (ASA) inside interface. The Cisco ASA outside interface connects directly to a router provided by the Internet service provider (ISP) of Company-A. The ISP completely manages this router; Company-A has no control over it. A third interface on the Cisco ASA hosts a demilitarized zone (DMZ) hosting several servers. These servers include web, e-mail, and FTP applications.



	342 Chapter 12: Case Studies

	Figure 12-1 Raleigh Office of Company-A

	Г Internet j



	Because this is a simple topology, all security policies are enforced in the Cisco ASA. The goal is to protect the internal and DMZ hosts from external threats, while allowing the following: • Client workstations must be able to access the web server at the DMZ (10.10.20.10) over HTTP and HTTPS. Clients should also be able to put and get files via FTP to the same server at 10.10.20.10. • Client workstations must be able to access the Internet over HTTP and HTTPS. No other protocol access is allowed to the Internet. • Client workstations must be able to check their e-mail on the e-mail server at the DMZ (10.10.20.20). • The web server should be reachable from outside Internet clients over HTTP and HTTPS only. The Cisco ASA should do static Network Address Translation (NAT) for the web server to be reachable via a public IP address from the Internet.



	Case Study of a Small Business 343

	The e-mail server should be able to receive e-mail from external hosts over the Simple Mail Transfer Protocol (SMTP). The Cisco ASA should do static NAT for the e-mail server to be reachable via a public IP address from the Internet. The client workstations will be translated to the external public IP address of the Cisco ASA using Port Address Translation (PAT).

	Raleigh Office Cisco ASA Configuration The following sections cover the steps necessary to complete the goals listed earlier.

	Configuring IP Addressing and Routing This section demonstrates how to configure the interfaces and default gateway on the Cisco ASA using the Adaptive Security Device Manager (ASDM). The following are the configuration steps: Step 1 Working with a new Cisco ASA installation, the administrator logs in via the command-line interface (CLI) and sets the management interface IP address (10.10.30.1) and other interface configuration with the following commands. Co-A-ASA1# configure terminal Co-A-ASA1(config)# interface Management0/0 Co-A-ASA1(config-if)# nameif management CoAASA1(configif)# security-level 80 CoAASA1(configif)# ip address 10.10.30.1 255.255.255.0 CoAASA1(configif)# no shutdown Co-A-ASA1(config-if)# exit Co-A-ASA1(config)# Step 2 The administrator enables ASDM access only from machines on the management network with the following commands: CoAASA1(config)# http server enable CoAASA1(config)# http 10.10.30.0 255.255.255.0 management CoAASA1(config)# asdm location 10.10.30.0 255.255.255.0 management Step 3 The next step is to configure the outside, inside, and DMZ interfaces. The administrator connects to the Cisco ASA via ASDM and clicks Configuration > Device Setup > Interfaces, as illustrated on Figure 12-2. Step 4 The administrator selects the GigabitEthernet0/0 interface and clicks the Edit button. The screen illustrated in Figure 12-3 is shown. The administrator enters the interface name (outside), the IP address configuration (209.165.200.225), subnet mask (255.255.255.0), and a description for the outside interface.



	344 Chapter 12: Case Studies

	Figure 12-2 Configuring the Cisco ASA Interfaces on ASDM



	Figure 12-3 Outside Interface Configuration



	Case Study of a Small Business 345

	Step 5 Similarly, the GigabitEthernet0/1 interface is configured as the inside interface, as shown in Figure 12-4. The security level for the inside interface is set to 100. Figure 12-4 Inside Interface Configuration



	Step 6 The GigabitEthernet0/2 interface is configured as the dmz interface, as shown in Figure 12-5. The security level of the dmz interface is set to 50. Step 7 The next step is to configure the default route of the Cisco ASA to point to the ISP router (209.165.200.226). To configure the default route, navigate to Configuration > Device Setup > Routing > Static Routes and click Add. The screen shown in Figure 12-6 is displayed. Choose the outside interface from the drop-down menu, and enter 0.0.0.0 for the IP address and 0.0.0.0 for the Mask. The Gateway IP is 209.165.200.226, and the metric is 1. Leave all the other options with their default value.



	346 Chapter 12: Case Studies

	Figure 12-5 DMZ Interface Configuration



	Figure 12-6 Inside Interface Configuration



	Case Study of a Small Business 347

	Configuring PAT on the Cisco ASA The next step is to configure PAT for internal users to be able to communicate to the Internet. Complete the following steps to configure PAT on the Cisco ASA. Step 1 To configure PAT, go to Configuration > Firewall > NAT Rules, click Add, and choose Add Dynamic NAT Rule from the drop-down menu, as illustrated in Figure 12-7.

	Figure 12-7 Configuring PAT for Internal Users



	Step 2 The screen shown in Figure 12-8 is displayed. Under the Original section, choose the inside interface from the drop-down menu. Step 3 Expand the Source option to select the inside source address space. This is illustrated in Figure 12-9. Select the inside network (10.10.10.0/24) and click OK.



	348 Chapter 12: Case Studies

	Figure 12-8 Adding a Dynamic NAT Rule



	Figure 12-9 Selecting the Source

Case Study of a Small Business 349

Step 4 Under the Translated section, click the Manage button to add a global address pool.

Step 5 The screen shown in Figure 12-10 is displayed. Under the IP Addresses to Add section, click Port Address Translation (PAT) using IP Address of the interface and click the Add button to include it under the Address pools, as shown in Figure 12-10.

Figure 12-10 Configuring PAT to Use the Outside Interface Address


	rf: Add Global Address Pool	E
	Interface: \| outside Pool ID: \|l
	IP Addresses to Add О Range Starting IP Address: \| Eoding IP Address: \|	Addresses Pud
	Netmask (optiooal): Q \| _>> jj
	О Port Address Translation (PAT) \| ^ *о_в\^_в* j IP Address: Netmask (optional): \| л Port Address Translation (PAT) using IP ^ Address of the Interface I 1
	OK 1 Cancel Help

Step 6 Click OK and apply your changes to the Cisco ASA.

Configuring Static NAT for the DMZ Servers

The DMZ servers must be statically translated with a public IP address. Table 12-1 lists the IP address mapping of the DMZ servers.

Table 12-1 IP Address Mapping of DMZ Servers


Server	Inside IP Address	Translated Address
Web server	10.10.20.10	209.165.200.227
E-mail server	10.10.20.20	209.165.200.228

Complete the following steps to configure static NAT for the DMZ web and e-mail servers.

Step 1 Navigate to Configuration > Firewall > NAT Rules, click Add, and choose Add Static NAT Rule from the drop-down menu, as illustrated in Figure 12-11.



	350 Chapter 12: Case Studies

	Figure 12-11 Adding a Static NAT Rule



	Step 2 The screen shown in Figure 12-12 is displayed. First configure static NAT for the web server. Under the Original section, choose the dmz interface from the drop-down menu, and enter the web server physical IP address (10.10.20.10) as the source.

	Figure 12-12 Adding a Static NAT Rule



	Case Study of a Small Business 351

	Step 3 Under the Translated section, choose the outside interface from the drop-down menu. Step 4 Click the Use IP address option, and enter the public address to which the web server will be translated (209.165.200.227). Step 5 Click OK. Step 6 Repeat the same procedure for the e-mail server.

	Configuring Identity NAT for Inside Users The inside users must be able to communicate with the DMZ servers. The goal is to configure identity NAT for inside users when communicating to the DMZ servers. Complete the following steps to configure identity NAT for inside users. Step 1 Navigate to Configuration > Firewall > NAT Rules, click Add, as illustrated in Figure 12-13. Figure 12-13 Configuring Identity NAT for the Inside Network on the DMZ a



	Step 2 Under the Original section, choose the inside interface from the dropdown menu, and the inside network as the source (10.10.10.0/24). Step 3 Under the Translated section, choose the dmz interface from the drop-down menu, and select the same inside network (10.10.10.0/24) as the translated IP address, as shown in Figure 12-13.



	352 Chapter 12: Case Studies

	Step 4 Click OK. Step 5 Apply the changes to the Cisco ASA.

	Controlling Access Next, you need to configure policies on the Cisco ASA to control access and achieve the following goals. • The web server should be reachable from outside Internet clients over the HTTP and HTTPS protocols only. • The e-mail server should be able to receive e-mail from external hosts over the SMTP only. Complete the following steps to configure access rules on the Cisco ASA. Step 1 Navigate to Configuration > Firewall > Access Rules, click Add. In Figure 12-14 the Access Rule configuration is displayed. Figure 12-14 Configuring Access Rules



	Step 2 First, the access rule to allow Internet users to reach the web server at the DMZ is configured. Under Action, click Permit. Step 3 Under source, select any.



	Case Study of a Small Business 353

	Step 4 Under destination, enter the IP address of the web server 209.165.200.227. Step 5 Select HTTP (TCP/HTTP) under the service. Step 6 Optionally, you can enter a description for this access rule, as illustrated in Figure 12-14. Step 7 Click OK. Step 8 Repeat the same steps to allow HTTPS (TCP port 443) access to the web server and SMTP (TCP port 25) access to the e-mail server.

	Cisco ASA Antispoofing Configuration The Company-A security administrator wants to protect the infrastructure from spoofed sources. The administrator enables Unicast Reverse Path Forwarding (Unicast RPF) to protect against IP spoofing attacks by ensuring that all packets have a source IP address that matches the correct source interface according to the routing table. To enable Unicast RPF, navigate to Configuration > Firewall > Advanced > Anti-spoofing. Select the desired interface, and click Enable, as illustrated in Figure 12-15.

	Figure 12-15 Configuring Unicast RPF



	354 Chapter 12: Case Studies

	Blocking Instant Messaging

	The security administrator is now tasked by his management to come up with a solution to prevent internal users from using Yahoo! and MSN instant messaging (IM) programs. The solution is to configure the Cisco ASA to block this traffic and log it. The security administrator completes the following steps to achieve this goal. Step 1 The first step is to configure an inspect map on the Cisco ASA. To do this, navigate to Configuration > Firewall > Objects > Inspect Maps > Instant Messaging (IM). Step 2 ClickAdd. Step 3 The Add Instant Messaging (IM) Inspect screen is displayed. Step 4 Enter a name and an optional description for the new inspect map configuration. In this example, the inspect map name is IM. Step 5 Click Add to add a new inspection criterion. Step 6 The screen is shown in Figure 12-16 is displayed.

	Figure 12-16 Adding	an Instant Messaging Inspect Map



	Step 7	Under Match Criteria, click Single Match.

	Step 8	Under Match Type, click Match.

	Step 9	Under Criterion, select Protocol.

	Step 10 Check both protocols (Yahoo! Messenger and MSN Messenger).



	Case Study of a Small Business 355

	Step 11 Under the Actions sections, leave the default of Drop Connection and Log enabled. Step 12 Click OK. Step 13 Navigate to Configuration > Firewall > Service Policy Rules and click Add. The first screen of the Configuration Wizard is displayed, as illustrated in Figure 12-17. Figure 12-17 Adding a New Service Policy Rule

		16

	Step 14 In this example, the service policy will be applied only to the inside interface. To do this, click Interface under the Create a Service Policy and Apply To section. Step 15 Select the inside interface, and enter a name, as shown in Figure 12-17. Step 16 Click Next. Step 17 The Traffic Classification Criteria screen is displayed, as shown in Figure 12-18. Click Use class-default as the traffic class.

	Step 18 Click Next.



	356 Chapter 12: Case Studies

	Figure 12-18 Traffic Classification Criteria Screen



	Step 19 The Rule Actions screen is shown, as illustrated in Figure 12-19. Figure 12-19 Rule Actions Screen



	Case Study of a Small Business 357

	Step 20 Under the Protocol Inspection tab, check IM and click Configure. Step 21 Select the previously configured inspection map (IM). Step 22 Click OK on the Select IM Inspect Map screen. Step 23 Click Finish to end the wizard. Step 24 Apply the configuration to the Cisco ASA. Example 12-1 shows the Cisco ASA CLI configuration for Company-A. Example 12-1 CLI Configuration of the Cisco ASA at the Raleigh Office Co-A-ASA1# show running-config : Saved ASA Version 8.0(1) ! hostname Co-A-ASA1 enable password 8Ry2YjIyt7RRXU24 encrypted names _! !outside interface configuration interface GigabitEthernet0/0 description outside interface connected to the Internet nameif outside security-level 0 ip address 209.165.200.225 255.255.255.0 _! !inside interface configuration interface GigabitEthernet0/1 description inside interface connected to corporate network nameif inside security-level 100 ip address 10.10.10.1 255.255.255.0 _! !dmz interface configuration interface GigabitEthernet0/2 description dmz interface where web, email, and FTP servers reside nameif dmz security-level 50 ip address 10.10.20.1 255.255.255.0 _! interface GigabitEthernet0/3 shutdown no nameif no security-level no ip address _! !management interface configuration interface Management0/0 nameif management security-level 80 continues



	358 Chapter 12: Case Studies

	Example 12-1 CLI Configuration of the Cisco ASA at the Raleigh Office (Continued) ip address 10.10.30.1 255.255.255.0 _! !ACL controlling access to the web and e-mail server access-list outside_access_in extended permit tcp any host 209.165.200.228 eq smtp access-list outside_access_in_ remark Allowing HTTP to the webserver access-list outside_access_in_ extended permit tcp any host 209.165.200.227 eq www access-list outside_access_in_ remark Allowing HTTPS to the webserver access-list outside_access_in_ extended permit tcp any host 209.165.200.227 eq https access-list outside_access_in_ remark Allowing SMTP to the email server access-list outside_access_in_1 extended permit tcp any host 209.165.200.228 eq smtp _! pager lines 24 mtu outside 1500 mtu inside 1500 mtu dmz 1500 mtu management 1500 _! !Unicast RPF Configuration ip verify reverse-path interface outside ip verify reverse-path interface inside ip verify reverse-path interface dmz _! no failover icmp unreachable rate-limit 1 burst-size 1 no asdm history enable arp timeout 14400 _! !PAT Configuration for inside users nat-control global (outside) 1 interface nat (inside) 1 10.10.10.0 255.255.255.0 _! 'Static NAT configuration for web and e-mail servers static (dmz,outside) 209.165.200.227 10.10.20.10 netmask 255.255.255.255 static (dmz,outside) 209.165.200.228 10.10.20.20 netmask 255.255.255.255 _! 'Static identity NAT configuration for inside network at the DMZ static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0 _! !ACL is applied to the outside interface access-group outside_access_in_1 in interface outside route outside 0.0.0.0 0.0.0.0 209.165.200.226 1 timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02 timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00 timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00 timeout uauth 0:05:00 absolute dynamic-access-policy-record DfltAccessPolicy http server enable http 10.10.30.0 255.255.255.0 management no snmp-server location no snmp-server contact



	Case Study of a Small Business 359

	Example 12-1 CLI Configuration of the Cisco ASA at the Raleigh Office (Continued) snmp-server enable traps snmp authentication linkup linkdown coldstart no crypto isakmp nat-traversal telnet timeout 5 ssh 10.10.30.0 255.255.255.0 management ssh timeout 5 console timeout 0 threat-detection basic-threat threat-detection statistics access-list _! class-map inspection_default match default-inspection-traffic _{! !} policy-map type inspect dns preset_dns_map parameters message-length maximum 512 _! 'policy map to block Yahoo! and MSN IM. policy-map type inspect im IM description Blocking Instant Messanging parameters match protocol msn-im yahoo-im drop-connection log policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect netbios inspect rsh inspect rtsp inspect skinny inspect esmtp inspect sqlnet inspect sunrpc inspect tftp inspect sip inspect xdmcp ! 'Service policy map to block IM policy-map inside-policy description Service Policy to block IM for Inside Users class class-default inspect im IM ! 'global service policy service-policy global_policy global 'service policy for IM applied to the inside interface only service-policy inside-policy interface inside



	360 Chapter 12: Case Studies

	Atlanta Office Cisco IOS Configuration Company-A opened a small branch office in Atlanta, Georgia. This new office has only 4 salesmen and 12 web developers. The Atlanta office network topology is simple. A Cisco IOS Software router with the IOS Firewall features set is configured to protect the internal network. This is illustrated in Figure 12-20. Figure 12-20 Atlanta Office Network Topology





	The router has only two interfaces enabled. The inside interface resides on the 10.100.10.0/ 24 network, and the outside interface faces the Internet.

	Locking Down the Cisco IOS Router The security administrator at Company-A must configure the router appropriately to increase the security of the Atlanta office network. The administrator uses the Security Device Manager (SDM) to configure the router and perform a security audit. Using SDM, the administrator can configure the router quickly using the best practices recommended in Chapter 2, "Preparation Phase."



	Case Study of a Small Business 361

	You can complete the following steps to perform a security audit and fix any discrepancies found on the Cisco IOS router. Step 1 Log in to the Cisco IOS router using SDM. Step 2 Navigate to Configure > Security Audit, and click the Perform security audit button, as illustrated in Figure 12-21. Alternatively, you can perform a one-step lockdown to configure default recommendations by clicking the One-step lockdown button. In this example, the step-by-step option is selected, which allows you to customize your configuration. Figure 12-21 Performing a Security Audit with SDM

		34

	Step 3 The Security Audit Wizard welcome screen shown in Figure 12-22 is displayed. Step 4 Click Next. Step 5 The Security Audit Interface Configuration screen shown in Figure 12-23 is displayed. In this example, a Cisco 871 router is used. The outside interface is FastEthernet4, and the inside interface is Vlan 1.



	362 Chapter 12: Case Studies

	Figure 12-22 Security Audit Wizard Welcome Screen Security Audit



	Figure 12-23 Security Audit Wizard Interface Configuration Screen Security Audit

Case Study of a Small Business 363

Step 6 Click Next.

Step 7 SDM performs the audit to make sure that the recommended settings are configured on the router. As illustrated in Figure 12-24, the router fails on numerous items.

Figure 12-24 Security Audit Wizard Interface Configuration Screen

Security Audit

Please wait while Security Audit checks if the recommended security settings are configured on the router.


No	Item Nama	Status
1	Disable Finger Service	*S Passed
2	Disable PAD Service	*S Passed
a	Disable TCP small servers Service	*S Passed
4	Disable UDP small servers Service	*S Passed
5	Disable IP bootp server Service	X Not Passed
Б	Disable CDP	X Not Passed
7	Disable IP source mute	X Not Passed
8	Enable Password encryption Service	X Not Passed
S	Enable TCP Keepalives for inbound telnet sessions	X Not Passed
1D	Enable TCP Keepalives for outbound telnet sessions	X Not Passed
11	Enable Sequence Numbers and Time Stamps on Debugs	X Not Passed
12	Enable IP CEF	*S Passed
13	Disable IP Gratuitous Arps	*S Passed
1 +	Set Scheduler Interval	X Not Passed
15	Set TCP Synwalttlme	X Not Passed

Click "Close" to continue fixing the identified security problems or undoing the configured security configurations in the router.

Close Save Report

SDM allows you to save a report that lists all the configuration checks that have passed or failed. The report is illustrated in Figure 12-25.

364 Chapter 12: Case Studies

Figure 12-25 Security Audit Report

I Hosmame |con^any-A-io5-fw

Report Saiuruary


No	Item Name	Status
1	Disable Finger Service	Passed
2	Disable PAD Service	V Passed
3	Disable TCP small servers Service	^ Passed
-1	Disable LDP small servers Service	V Passed
5	Disable ГР bootp server Service	" Not Passed
6	Disable CDP	* Not Passed
7	Disable ГР source route	" Not Passed
S	Enable Password encryption Service	* Not Passed
9	Enable TCP Keepalives for inbound telnet sessions	" Not Passed
10	Enable TCP Keepalives for outbound telnet sessions	* Not Passed
11	Enable Sequence Numbers and Time Stamps on Debugs	" Not Passed
12	Enable IP CEF	V Passed
13	Disable IP Gratuitous Arps	Passed
14	Set Scheduler Interval	* Not Passed
15	Set TCP Synwait time	^ Not Passed
16	Set Banner	* Not Passed
17	Enable Logging	^ Not Passed
1S	Set Enable Secret Password	* Not Passed
19	Disable SNMP	ч/ Passed
20	Set Scheduler Allocate	* Not Passed
21	Set Users	" Not Passed
	Enable Telnet settings	* Not Passed
23	Enable NetFlow Monitoring	" Not Passed
2-1	Disable TP Redirects.	* Not Passed
	Disable TP Proxy Arp	" Not Passed
26	Disable TP Directed Broadcast	V Passed
	Disable TP Unreachables	^ Not Passed
2S	Disable IP Mask Reply	V Passed
29	Disable ГР Unreachables on Null interface	" Xot Passed
30	enable Unicast RPF on all outside interfaces	* Not Passed.
31	Enable Firewall on all outside interfaces	^ Not Passed
32	Set Access class on Hi'IP server service	^x Not Passed
33	Set Access class on VTY lines	X Not Passed
34	Enable SSH for access to the router	" Xot Passed
35	enable AAA	* Not Passed

Step 8 SDM asks you to enter a new enable secret password and to configure a login banner, as illustrated in Figure 12-26.

Step 9 After you enter the new enable secret password and login banner, click Next.

Step 10 SDM allows you to configure an administrative account, as shown in Figure 12-27. To configure a new account, click Add.



	Case Study of a Small Business 365



	366 Chapter 12: Case Studies

	Step 11 Enter the username and password, as shown in Figure 12-27. In this example, a user named companyAadmin is created. Step 12 Click OK after entering the username and password. Step 13 Click Next to continue with the Security Audit Wizard. Step 14 In the next screen, SDM allows you to enable logging and configure a system log (SYSLOG) server, as illustrated in Figure 12-28.

	Figure 12-28 Configuring Logging



	Step 15 In this example, the logging level is set to informational (level 6), and the SYSLOG server IP address is 10.100.10.222. Step 16 Click Next. Step 17 The Advanced Firewall Configuration Wizard welcome screen is displayed, as shown in Figure 12-29. Step 18 Click Next. Step 19 Check the inside and outside interfaces. In this example, FastEthernet4 is the outside interface, and Vlan1 is the inside interface. This is illustrated in Figure 12-30.



	Case Study of a Small Business 367

	Figure 12-29 Advanced Firewall Configuration Wizard Welcome Screen



	Figure 12-30 IOS Firewall Inside and Outside Interface Selection



	Step 20 Click Next.



	368 Chapter 12: Case Studies

	Step 21 The screen shown in Figure 12-31 is displayed. In this screen, SDM allows you to enable predefined application security policies. You can use the slider to select the security level. In this example, the security level is set to High. Figure 12-31 Application Security Policies



	Step 22 Click Next. Step 23 The SDM Wizard allows you enter the primary and secondary DNS servers for name resolution, as illustrated in Figure 12-32. In this example, the primary DNS server is 10.100.10.21, and the secondary DNS server is 10.100.10.22. Step 24 Click Next after entering the DNS server information. Step 25 A summary screen lists the configuration changes, as illustrated in Figure 12-33. Click Finish to send the configuration changes to the Cisco IOS router.



	Case Study of a Small Business 369



	370 Chapter 12: Case Studies

	Example 12-2 shows the CLI configuration of the router at the Atlanta office after completing the previous steps. Example 12-2 CLI Configuration of the Cisco IOS Router at the Atlanta Office company-A-ios-fw#show running-config Building configuration... Current configuration : 8080 bytes ! version 12.4 no service pad service tcp-keepalives-in service tcp-keepalives-out service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption service sequence-numbers _! hostname company-A-ios-fw _! boot-start-marker boot-end-marker _! no logging buffered logging console critical enable secret 5 $1$XlSV$Pa0oIYeuSY5CZOGXXOJjF/ _! aaa new-model _! aaa authentication login local_authen local aaa authorization exec local_author local _! aaa session-id common no ip source-route ip cef _! _! ip tcp synwait-time 10 no ip bootp server ip name-server 10.100.10.21 ip name-server 10.100.10.22 ip ssh time-out 60 ip ssh authentication-retries 2 _! parameter-map type protocol-info msn-servers server name messenger.hotmail.com server name gateway.messenger.hotmail.com server name webmessenger.msn.com _! parameter-map type protocol-info aol-servers server name login.oscar.aol.com server name toc.oscar.aol.com server name oam-d09a.blue.aol.com _!

Case Study of a Small Business 371

Example 12-2 CLI Configuration of the Cisco IOS Router at the Atlanta Office (Continued) I parameter-map type protocol-info yahoo-servers


server	name	scs.msg.yahoo.com
server	name	scsa.msg.yahoo.com
server	name	scsb.msg.yahoo.com
server	name	scsc.msg.yahoo.com
server	name	scsd.msg.yahoo.com
server	name	cs16.msg.dcn.yahoo.com
server	name	cs19.msg.dcn.yahoo.com
server	name	cs42.msg.dcn.yahoo.com
server	name	cs53.msg.dcn.yahoo.com
server	name	cs54.msg.dcn.yahoo.com
server	name	ads1.vip.scd.yahoo.com
server	name	radio1.launch.vip.dal.yahoo.com
server	name	in1.msg.vip.re2.yahoo.com
server	name	data1.my.vip.sc5.yahoo.com
server	name	address1.pim.vip.mud.yahoo.com
server	name	edit.messenger.yahoo.com
server	name	messenger.yahoo.com
server	name	http.pager.yahoo.com
server	name	privacy.yahoo.com
server	name	csa.yahoo.com
server	name	csb.yahoo.com
server	name	csc.yahoo.com

parameter-map type regex sdm-regex-nonascii pattern ["\x00-\x80]

username companyAadmin password 7 02050D4808095E731F

class-map type inspect smtp match-any sdm-app-smtp

match data-length gt 5000000 class-map type inspect http match-any sdm-app-nonascii

match req-resp header regex sdm-regex-nonascii class-map type inspect imap match-any sdm-app-imap

match invalid-command class-map type inspect match-any sdm-cls-insp-traffic

match protocol dns

match protocol https

match protocol icmp

match protocol imap

match protocol pop3

match protocol tcp

match protocol udp class-map type inspect match-all sdm-insp-traffic

match class-map sdm-cls-insp-traffic class-map type inspect match-all sdm-protocol-pop3

match protocol pop3

continues

372 Chapter 12: Case Studies

Example 12-2 CLI Configuration of the Cisco IOS Router at the Atlanta Office (Continued)

class-map type inspect match-any sdm-cls-icmp-access

match protocol icmp

match protocol tcp

match protocol udp class-map type inspect match-any sdm-cls-protocol-im

match protocol ymsgr yahoo-servers

match protocol msnmsgr msn-servers

match protocol aol aol-servers class-map type inspect pop3 match-any sdm-app-pop3

match invalid-command class-map type inspect http match-any sdm-http-blockparam

match request port-misuse im

match request port-misuse p2p

match request port-misuse tunneling

match req-resp protocol-violation class-map type inspect match-all sdm-protocol-im

match class-map sdm-cls-protocol-im class-map type inspect match-all sdm-icmp-access

match class-map sdm-cls-icmp-access class-map type inspect match-all sdm-invalid-src

match access-group 100


class-map type inspect			http match-any sdm-app-httpmethods
match	request	method	bcopy
match	request	method	bdelete
match	request	method	bmove
match	request	method	bpropfind
match	request	method	bproppatch
match	request	method	connect
match	request	method	copy
match	request	method	delete
match	request	method	edit
match	request	method	getattribute
match	request	method	getattributenames
match	request	method	getproperties
match	request	method	index
match	request	method	lock
match	request	method	mkcol
match	request	method	mkdir
match	request	method	move
match	request	method	notify
match	request	method	options
match	request	method	poll
match	request	method	post
match	request	method	propfind
match	request	method	proppatch
match	request	method	put
match	request	method	revadd
match	request	method	revlabel
match	request	method	revlog
match	request	method	revnum
match	request	method	save
match	request	method	search

Case Study of a Small Business 373

Example 12-2 CLI Configuration of the Cisco IOS Router at the Atlanta Office (Continued)


match	request	method	setattribute
match	request	method	startrev
match	request	method	stoprev
match	request	method	subscribe
match	request	method	trace
match	request	method	unedit
match	request	method	unlock
match	request	method	unsubscribe
class-map type		inspect	match-all sdm-protocol-http
match	protocol	http

class-map type inspect match-all sdm-protocol-smtp

match protocol smtp class-map type inspect match-all sdm-protocol-imap

match protocol imap

_{! !}

policy-map type inspect sdm-permit-icmpreply class type inspect sdm-icmp-access

inspect class class-default pass

policy-map type inspect http sdm-action-app-http class type inspect http sdm-http-blockparam log reset

class type inspect http sdm-app-httpmethods log reset

class type inspect http sdm-app-nonascii

log

reset class class-default policy-map type inspect smtp sdm-action-smtp class type inspect smtp sdm-app-smtp

reset class class-default policy-map type inspect imap sdm-action-imap class type inspect imap sdm-app-imap

log

reset class class-default policy-map type inspect pop3 sdm-action-pop3 class type inspect pop3 sdm-app-pop3

log

reset class class-default policy-map type inspect sdm-inspect class type inspect sdm-invalid-src

drop log

class type inspect sdm-protocol-http inspect

service-policy http sdm-action-app-http

continues



	374 Chapter 12: Case Studies

	Example 12-2 CLI Configuration of the Cisco IOS Router at the Atlanta Office (Continued) class type inspect sdm-protocol-smtp inspect service-policy smtp sdm-action-smtp class type inspect sdm-protocol-imap inspect service-policy imap sdm-action-imap class type inspect sdm-protocol-pop3 inspect service-policy pop3 sdm-action-pop3 class type inspect sdm-protocol-im drop log class type inspect sdm-insp-traffic inspect class class-default policy-map type inspect sdm-permit class class-default _! zone security out-zone zone security in-zone zone-pair security sdm-zp-self-out source self destination out-zone service-policy type inspect sdm-permit-icmpreply zone-pair security sdm-zp-out-self source out-zone destination self service-policy type inspect sdm-permit zone-pair security sdm-zp-in-out source in-zone destination out-zone service-policy type inspect sdm-inspect interface Null0 no ip unreachables _! interface FastEthernet0 _! interface FastEthernet1 _! interface FastEthernet2 _! interface FastEthernet3 _! interface FastEthernet4 description $FW_OUTSIDE$ ip address 209.165.200.231 255.255.255.0 no ip redirects no ip unreachables no ip proxy-arp zone-member security out-zone ip route-cache flow duplex auto



	Case Study of a Small Business 375

	Example 12-2 CLI Configuration of the Cisco IOS Router at the Atlanta Office (Continued) speed auto _! interface Vlan1 description $FW_INSIDE$ ip address 10.100.10.1 255.255.255.0 no ip redirects no ip unreachables no ip proxy-arp zone-member security in-zone ip route-cache flow _! ip route 0.0.0.0 0.0.0.0 209.165.200.225 _! ip http server no ip http secure-server _! logging trap informational logging 10.100.10.222 access-list 100 remark SDM_ACL Category=128 access-list 100 permit ip host 255.255.255.255 any access-list 100 permit ip 127.0.0.0 0.255.255.255 any access-list 100 permit ip 209.165.200.0 0.0.0.255 any access-list 101 remark VTY Access-class list access-list 101 remark SDM_ACL Category=1 access-list 101 permit ip 10.100.10.0 0.0.0.255 any access-list 101 deny ip any any no cdp run control-plane _! banner login "C*** THIS IS A RESTRICTED SYSTEM, UNAUTHORIZED ACCESS"C _! line con 0 login authentication local_authen no modem enable transport output telnet line aux 0 login authentication local_authen transport output telnet line vty 0 4 access-class 101 in authorization exec local_author login authentication local_authen transport input telnet ssh _! scheduler max-task-time 5000 scheduler allocate 4000 1000 scheduler interval 500 end



	376 Chapter 12: Case Studies

	Configuring Basic Network Address Translation (NAT) The router administrator needs to configure basic NAT for internal users to access the Internet. The following steps are completed to enable basic NAT on the Cisco IOS router. Step 1 Log in to the router using SDM. Step 2 Navigate to Configure > NAT and click Basic NAT, as illustrated in Figure 12-34. Figure 12-34 Configuring Basic NAT

		34

	Step 3 Click the Launch the selected task button to start the NAT Configuration Wizard. Step 4 The NAT Configuration Wizard welcome screen appears. Click Next. Step 5 The screen shown in Figure 12-35 is displayed.



	Case Study of a Small Business 377

	Figure 12-35 Basic NAT Configuration Wizard



	Step 6 Choose the interface that connects to the Internet from the drop-down menu. FastEthernet4 is selected in this example. Step 7 In this example, the inside network will be translated to the public IP address of the outside interface. Step 8 Click Next. Step 9 The wizard displays a summary screen listing the configuration changes. Click Finish.

	Configuring Site-to-Site VPN Users at the office in Atlanta need to securely access resources in the Raleigh office. The security administrator configures a site-to-site IPsec tunnel between the Cisco ASA in Raleigh and the Cisco IOS router in Atlanta. The following are the steps that need to be completed to configure the Cisco IOS router in Atlanta to terminate a site-to-site IPsec tunnel with the Cisco ASA in Raleigh. Step 1 Log in to the router using SDM. Step 2 Navigate to Configure > VPN and choose Site-to-Site VPN, as illustrated in Figure 12-36.



	378 Chapter 12: Case Studies

	Figure 12-36 Configuring a Site-to-Site VPN Using SDM

		34

	Step 3 Click Create a Site to Site VPN and click the Launch the selected task button. Step 4 The Site-to-Site VPN Wizard welcome screen is displayed, as illustrated in Figure 12-37. The Quick setup option allows you to easily configure a site-to-site VPN tunnel to another Cisco router with minimal interaction. In this case, the router will be creating a site-to-site VPN tunnel to a Cisco ASA, then the Step by step wizard is selected. This option lets you customize the configuration. Step 5 Click Next. Step 6 The screen shown in Figure 12-38 is displayed. Select the interface that will terminate the VPN tunnel. In this example, FastEthernet4 (the outside interface of the router) is selected.



	Case Study of a Small Business 379

	Figure 12-37 SDM Site-to-Site VPN Wizard Welcome Screen



	Figure 12-38 Configuring the VPN Interface, Remote Peer, and Preshared Keys



	380 Chapter 12: Case Studies

	Step 7 In this case, the VPN peer (Cisco ASA) is configured with a static IP address. Choose Peer with static IP address from the drop-down menu and enter the IP address of the peer (209.165.200.225). Preshared keys are used in this example for tunnel authentication. Step 8 Click Next. Step 9 The next screen allows you to configure an Internet Key Exchange (IKE) (as illustrated in Figure 12-39). This policy must match the IKE policy on the Cisco ASA. Click Add to enter a new IKE policy.

	Figure 12-39 Configuring the IKE Policy with SDM



	Step 10 In this case, a new policy is configured to use preshared keys for authentication. The selected encryption protocol is Advanced Encryption Standard AES_256. Diffie-Hellman (DH) Group 2 is used. The IKE hashing algorithm is Secure Hash Algorithm SHA_1. The default 24-hour lifetime for IKE is selected. Step 11 Click Next. Step 12 The next screen enables you to configure the IPsec policies. Click Add to add a new transform-set (IPsec phase two policies). Step 13 The dialog box illustrated in Figure 12-40 appears allowing you to configure the IPsec policies.



	Case Study of a Small Business 381

	Figure 12-40 Configuring the IPsec Phase Two Policies with SDM



	Step 14 Enter a name for the new transform set. In this case, the name is tunnel-to-asa. Step 15 The Encapsulatation Security Payload (ESP) protocol is used in this example. The integrity algorithm used in this example is ESP_SHA_HMAC, and the encryption algorithm is ESP_AES_256. The Cisco ASA configuration must match these settings to establish the site-to-site IPsec VPN tunnel. Step 16 Tunnel mode is used in this example to encrypt both the payload (data) and IP header. Step 17 Click OK to add the new transform-set. Step 18 Click Next. Step 19 The screen shown in Figure 12-41 is displayed. It allows you to select the traffic you would like to protect. Step 20 Click Protect all traffic between the following subnets. Step 21 Configure the local and remote networks (the networks that will be able to communicate over the VPN tunnel). In this case, the local network is 10.100.10.0/24, and the remote network is 10.10.10.0/24. Step 22 Click Next.



	382 Chapter 12: Case Studies

	Figure 12-41 Traffic to Protect



	Step 23 A summary screen listing the configuration changes is displayed. Click Finish to apply the changes. Step 24 Because NAT/PAT was configured on the router, SDM shows a warning message asking you if you would like to bypass NAT for the traffic over the VPN tunnel. The warning screen is shown in Figure 12-42.

	Figure 12-42 SDM Warning Screen



	Step 25 Click Yes to bypass NAT for the tunnel traffic.



	Case Study of a Small Business 383

	Example 12-3 shows the CLI VPN configuration of the router. Example 12-3 CLI VPN Configuration of the Router !Phase 1 IKE policy crypto isakmp policy 2 encr aes 256 authentication pre-share group 2 crypto isakmp key cisco123 address 209.165.200.225 ! !Phase 2 policy crypto ipsec transform-set tunnel-to-asa esp-aes 256 esp-sha-hmac _! !crypto-map configuration for the Tunnel to the Cisco ASA crypto map SDM_CMAP_1 1 ipsec-isakmp description Tunnel to209.165.200.225 set peer 209.165.200.225 set transform-set tunnel-to-asa match address 102 _! !ACL defining tunnel traffic access-list 102 remark SDM_ACL Category=4 access-list 102 remark IPSec Rule access-list 102 permit ip 10.100.10.0 0.0.0.255 10.10.10.0 0.0.0.255 _! !Outside Interface Configuration interface FastEthernet4 description $FW_OUTSIDE$ ip address 209.165.200.231 255.255.255.0 ip nat outside crypto map SDM_CMAP_1 _! !NAT Configuration - bypassing NAT for tunnel traffic ip nat inside source route-map SDM_RMAP_1 interface FastEthernet4 overload _! route-map SDM_RMAP_1 permit 1 match ip address 105 access-list 105 remark SDM_ACL Category=2 access-list 105 remark IPSec Rule access-list 105 deny ip 10.100.10.0 0.0.0.255 10.10.10.0 0.0.0.255 access-list 105 permit ip 10.100.10.0 0.0.0.255 any

	The next task is to configure the Cisco ASA in the Raleigh office to terminate the site-to-site VPN tunnel. Complete the following steps to complete this task. Step 1 Log in to the Cisco ASA using ASDM. Step 2 From the main ASDM menu, choose Wizards > IPsec VPN Wizard, as shown in Figure 12-43. Step 3 The VPN Wizard starts by allowing you to select the tunnel type, as illustrated in Figure 12-44. Click Site-to-Site.



	384 Chapter 12: Case Studies

	Step 4 Choose the outside interface as the VPN tunnel interface from the drop-down menu. Figure 12-43 Launching the ASDM IPsec VPN Wizard



	Figure 12-44 ASDM VPN Wizard—VPN Tunnel Type



	Case Study of a Small Business 385

	Step 5 In this example, the Cisco ASA will be configured to allow inbound IPsec sessions to bypass all configured access control lists (ACL). Step 6 Click Next. Step 7 The screen shown in Figure 12-45 is displayed. Here you can enter the remote site peer information. Figure 12-45 ASDM VPN Wizard—Remote Peer Information



	Step 8 Enter the peer IP address (209.165.200.231 in this example). Step 9 Under Authentication Method, click Pre-shared key and enter the preshared key. In this example, the preshared key is 1qazXSW2. Step 10 By default, the IP address of the remote peer is used as the tunnel group name. Leave the default configuration. Step 11 Click Next. Step 12 The screen shown in Figure 12-46 is displayed. Here you can enter the IKE policy information. Step 13 The IKE policy parameters must match those configured in the router. In this case, the same encryption protocol, authentication hashing algorithm, and DH group are configured. Step 14 Click Next.



	386 Chapter 12: Case Studies

	Figure 12-46 ASDM VPN Wizard—IKE Policy



	Step 15 The screen shown in Figure 12-47 is displayed. Here you can enter the IPsec phase 2 information.

	Figure 12-47 ASDM VPN Wizard—IPsec Encryption and Authentication



	Case Study of a Small Business 387

	Step 16 The IPsec encryption and authentication protocol parameters must match those configured in the router, as shown in Figure 12-47. Step 17 Click Next. Step 18 The screen shown in Figure 12-48 is displayed. This screen allows you to enter the local and remote networks that will communicate over the IPsec site-to-site VPN tunnel. Figure 12-48 ASDM VPN Wizard—Hosts and Networks



	Step 19 Under Action, click Protect. Step 20 Enter the local network information. In this case, the inside-network/24 is selected. Step 21 Enter the remote network information. The 10.100.10.0/24, atlanta-office remote network is selected in this example. Step 22 Check the Exempt ASA side host/network from address translation option and choose the inside interface from the drop-down menu to bypass NAT for tunnel traffic. Step 23 Click Next. Step 24 The summary screen shown in Figure 12-49 is displayed. Step 25 Click Finish to apply the changes to the Cisco ASA.



	388 Chapter 12: Case Studies

	Figure 12-49 ASDM VPN Wizard—Summary Screen





	Example 12-4 shows the Cisco ASA CLI site-to-site VPN configuration. Example 12-4 Cisco ASA CLI Site-to-Site VPN Configuration !IKE Enabled on the outside interface crypto isakmp enable outside _! !IKE Policy (phase one policy) crypto isakmp policy 10 authentication pre-share encryption aes-256 hash sha group 2 lifetime 86400 _! !Phase 2 policy and crypto map configuration crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac crypto map outside_map 20 match address outside_20_cryptomap crypto map outside_map 20 set peer 209.165.200.231 crypto map outside_map 20 set transform-set ESP-AES-256-SHA _! !Crypto map is applied to the outside interface crypto map outside_map interface outside



	Case Study of a Medium-Sized Enterprise 389

	Example 12-4 Cisco ASA CLI Site-to-Site VPN Configuration (Continued) _! !ACL used by the crypto map to define the traffic that will be encrypted access-list outside_20_cryptomap extended permit ip 10.10.10.0 255.255.255.0 object-group atlanta-office _! !Tunnel group configuration for the site-to-site tunnel tunnel-group 209.165.200.231 type ipsec-l2l tunnel-group 209.165.200.231 ipsec-attributes pre-shared-key * _! 'Bypassing NAT for the VPN tunnel traffic nat (inside) 0 access-list inside_nat0_outbound access-list inside_nat0_outbound extended permit ip 10.10.10.0 255.255.255.0 object-group atlanta-office _! 'Object Group defining the Atlanta office remote network object-group network atlanta-office network-object 10.100.10.0 255.255.255.0

	Case Study of a Medium-Sized Enterprise Company-B is a medium-sized software development company based in Chicago, Illinois. This organization has 1200 employees and 75 contractors at a call center in a partner office (Partner-A). Figure 12-50 illustrates a high-level overview of the Chicago office for Company-B. Two routers (R1 and R2) reside at the Internet Edge followed by two Cisco ASAs with the Advanced Inspection and Prevention Security Services Module (AIP-SSM). The AIP-SSM provides intrusion prevention system (IPS) functionality. Web, e-mail, and DNS servers reside at a DMZ network. A Cisco Secure Monitoring, Analysis, and Response System (CS-MARS), a Cisco Secure Access Control Server (ACS), and a Simple Network Management Protocol (SNMP) server reside in the management network. Company-B has three major user groups in the Chicago office: • Sales • Engineering • Finance Company-B's security manager has learned the techniques and methodologies discussed earlier on this book. The security manager develops a strategic plan to implement best practices to increase the security of their network infrastructure. The following sections include several tasks that the security manager of Company-B completes to increase the security of the network and its components.



	390 Chapter 12: Case Studies

	Figure 12-50 High-Level Overview of Company-B Chicago Office



Case Study of a Medium-Sized Enterprise 391

Protecting the Internet Edge Routers On the Internet edge routers (R1 and R2), the administrator configures an ACL to deny packets from illegal sources (RFC 1918 and RFC 3330 addresses). In addition, this ACL denies traffic with source addresses belonging within the internal address space of Company-B (that is, 209.165.201.0/24) that is entering from an external source. Example 12-5 shows the ACL configuration. Example 12-5 Antispoofing ACL access-list 100 deny ip host 0.0.0.0 any access-list 100 deny ip 127.0.0.0 0.255.255.255 any access-list 100 deny ip 192.0.2.0 0.0.0.255 any access-list 100 deny ip 224.0.0.0 31.255.255.255 any access-list 100 deny ip 10.0.0.0 0.255.255.255 any access-list 100 deny ip 172.16.0.0 0.15.255.255 any access-list 100 deny ip 192.168.0.0 0.0.255.255 any access-list 100 deny ip any 209.165.201.0 0.0.0.255 access-list 100 permit ip any any

NOTE In addition, the administrator performs a security audit using SDM and makes the necessary changes, as the Company-A administrator.

Configuring the AIP-SSM on the Cisco ASA Two Cisco ASAs protect the Chicago office internal network. The IP address configuration of both Cisco ASAs is illustrated in Figure 12-51. Figure 12-51 Cisco ASAs at the Chicago Office

	SSM Management 10.200.30.3			SSM Management 10.200.30.4
	ASA-2		Outside 209.165.201.2
	Management 10.200.30.2		AIP-SSM
	DMZ 10.200.20.2		AIP-SSM
	DMZ 10.200.20.2	Inside 10.200.10.2



392 Chapter 12: Case Studies

The following are the IP addresses of each of the interfaces of the primary Cisco ASA (ASA-1): • Outside: 209.165.201.1 • Inside: 10.200.10.1 • DMZ: 10.200.20.1 • Management: 10.200.30.1 • AIP-SSM Management interface: 10.200.30.3 The following are the IP addresses of each of the interfaces of the secondary Cisco ASA (ASA-2): • Outside: 209.165.201.2 • Inside: 10.200.10.2 • DMZ: 10.200.20.2 • Management: 10.200.30.2 • AIP-SSM management interface: 10.200.30.4 The administrator configures the necessary access and address translation for internal services in a procedure that is similar to the steps you learned previously in this chapter. After performing these basic configuration steps, the security administrator initializes the AIP-SSM. To verify that the ASA-1 recognizes the AIP-SSM, the administrator uses the show module command, as shown in Example 12-6. Example 12-6 Output of the show module Command

companyB-ASA1# show module Mod Card Type			Model	Serial No.

0	ASA 5520 Adaptive Security Appliance ASA5520-K8 ASA 5500 Series Security Services Module-10 ASA-SSM-10			JMX1113L0Y4 JAB101502D9

Mod MAC Address Range		Hw Version Fw Version Sw Version

0	001a.6d7c.8c95 to 001a.6d7c.8c99 2.0 0016.c79f.78c1 to 0016.c79f.78c1 1.0 SSM Application Name Status		1.0(11)2 8.0(2) 1.0(10)0 6.0(2)E1 SSM Application Version
Mod			1.0(11)2 8.0(2) 1.0(10)0 6.0(2)E1 SSM Application Version

1 IPS Mod Status		Up Data Plane Status	6.0(2)E1 Compatibility

Up Sys Up		Not Applicable Up

The highlighted lines show that the module is running IPS Software Version 6.0(2)E1 and that it is operational. The administrator logs into ASA-1 via the CLI and connects to the AIP-SSM using the session 1 command. This puts him on the AIP-SSM CLI. To initialize the AIP-SSM, the administrator uses the setup command, as demonstrated in Example 12-7.



	Case Study of a Medium-Sized Enterprise 393

	Example 12-7 Initializing ASA-1 AIP-SSM sensor# setup — System Configuration Dialog — At any point you may enter a question mark '?' for help. Use ctrl-c to abort configuration dialog at any prompt. Default settings are in square brackets '[]'. Current Configuration: service host network-settings host-ip 10.1.9.201/24,10.1.9.1 host-name sensor telnet-option disabled ftp-timeout 300 login-banner-text exit time-zone-settings offset 0 standard-time-zone-name UTC exit summertime-option disabled ntp-option disabled exit service web-server port 443 exit Current time: Mon May 14 18:26:51 2007 Setup Configuration last modified: Mon May 14 17:45:30 2007 Continue with configuration dialog?[yes]: yes Enter host name[sensor]: companyB-AIP-SSMI Enter IP interface[10.1.9.201/24,10.1.9.1]: 10.200.30.3/24,10.200.30.1 Enter telnet-server status[disabled]: Enter web-server port[443]: Modify current access list?[no]: yes Current access list entries: No entries Permit: 10.200.30.0/24 Permit: Modify system clock settings?[no]: no Modify virtual sensor "vs0" configuration?[no]: yes Current interface configuration Command control: GigabitEthernet0/0 Unused: GigabitEthernet0/1 Monitored: None Add Monitored interfaces?[no]: yes Interface[]: GigabitEthernet0/1 Interface[]: The following configuration was entered. service host network-settings continues



	394 Chapter 12: Case Studies

	Example 12-7 Initializing ASA-1 AIP-SSM (Continued) host-ip 10.200.30.3/24,10.200.30.1 host-name companyB-AIP-SSM1 telnet-option disabled access-list 10.200.30.0/24 ftp-timeout 300 no login-banner-text exit time-zone-settings offset 0 standard-time-zone-name UTC exit summertime-option disabled ntp-option disabled exit service web-server port 443 exit service analysis-engine virtual-sensor vs0 physical-interface GigabitEthernet0/1 exit exit [0] Go to the command prompt without saving this config. [1] Return back to the setup without saving this config. [2] Save this configuration and exit setup. Enter your selection[2]: 2 Configuration Saved.

	In Example 12-7, the administrator configures the AIP-SSM hostname, IP address, and subnet mask of the management interface, in addition to the default gateway. The administrator allows management access only from machines in the 10.200.30.0/24 management network. Also, the GigabitEthernet0/1 interface is enabled for traffic inspection. Finally, the administrator saves the configuration and exits the interactive setup session. Configuring Active-Standby Failover on the Cisco ASA Maintaining appropriate redundancy mechanisms within infrastructure devices is extremely important for any organization. The Cisco ASA supports active-active and active-standby failover.

	NOTE When the active unit fails, it changes to the standby state while the standby unit changes to the active state. The unit that becomes active takes ownership of the IP addresses and MAC addresses of the failed unit. The unit that is now in standby state takes over the standby IP addresses and MAC addresses. Because network devices see no change in the MAC-to-IP address pairing, no ARP entries change or time out anywhere on the network.



	Case Study of a Medium-Sized Enterprise 395

	When a pair of Cisco ASAs is configured in active-active failover mode, both appliances are actively passing traffic at the same time. In contrast, when configured in active-standby mode, the primary appliance is the active one and the secondary appliance is in standby and does not pass traffic. After the primary fails, the secondary takes over and begins to pass traffic. The network security team of Company-B evaluates both options. They decide to implement active-standby failover because, for active-active to work, the appliances must be configured in multicontext mode. Active-active requires a minimum of two security contexts on each appliance. Company-B has a site-to-site VPN tunnel to a business partner (Partner-A). The Cisco ASA does not support VPN when configured in multicontext mode. The following are the steps taken to configure active-standby failover on the Cisco ASAs. Step 1 Log in to the Cisco ASA using ASDM. Step 2 On the main toolbar, click Wizards and choose High Availability and Scalability Wizard, as illustrated in Figure 12-52.

	Figure 12-52 Launching the High Availability and Scalability Wizard

	16


	Step 3 The screen shown in Figure 12-53 is displayed. Click Configure Active/Standby failover.



	396 Chapter 12: Case Studies



	Step 4 Click Next. Step 5 Enter the IP address of the secondary appliance, as shown in Figure 12-54. The IP address of the secondary appliance management interface is 10.200.30.2 in this case. ASDM completes several compatibility and connectivity checks on the secondary appliance. These steps are listed within the ASDM screen shown in Figure 12-54. If successful, ASDM allows you to proceed to the next step. However, if issues exist, ASDM marks each check that failed. You must fix any errors before proceeding further. Step 6 Click Next. Step 7 The screen shown in Figure 12-55 is displayed. This screen allows you to configure a dedicated interface for failover communication between the two appliances. Choose an available interface from the drop-down menu. In this case, the interface selected is GigabitEthernet0/3. Step 8 Enter a name for the failover interface. In this example, the interface is called failover for simplicity. This is an arbitrarily name.



	Case Study of a Medium-Sized Enterprise 397

	Figure 12-54 Failover Peer Connectivity and Compatibility Check



	398 Chapter 12: Case Studies

	Step 9 Assign an IP address for this interface, in addition to a standby IP address, as shown in Figure 12-55. In this example, the active IP address is 10.200.40.1, and the secondary is 10.200.40.2. Step 10 Configure a subnet mask for this interface. A 30-bit (255.255.255.252) subnet mask is configured in this example. Step 11 You can optionally encrypt the failover communication data exchanged by both appliances. To enable encryption, select the Use 32 hexadecimal character key option under Communication Encryption. Step 12 Enter a 32 hexadecimal character key. Step 13 Click Next. Step 14 You can configure stateful failover to maintain connection status, translation, and other information on the standby appliance to avoid interruption of services when a failover occurs. You can configure a dedicated interface or use the previously configured failover interface for this communication. On busy networks where numerous connections are built and torn down at a fast pace, a dedicated interface is suggested. In this case, all other interfaces on the Cisco ASAs are used for other purposes, and the stateful failover traffic of Company-B does not present an oversubscription risk based on tests that the administrator performed in the lab prior to deployment. The administrator configures the failover LAN link interface as the stateful failover link, as shown in Figure 12-56. Figure 12-56 Configuring the Stateful Failover Link



	Case Study of a Medium-Sized Enterprise 399

	Step 15 You must configure a standby IP address for each interface that is enabled on the Cisco ASA. The standby appliance uses these IP addresses. The screen shown in Figure 12-57 allows you to configure the standby IP address for each interface.

	Figure 12-57 Configuring the Standby IP Addresses



	Step 16 Click Next. Step 17 A summary screen showing the configuration items to be sent to the security appliance is displayed. Click Finish to apply the changes. Example 12-8 includes the CLI commands sent to the primary appliance. Example 12-8 Failover Configuration on the Primary ASA failover failover lan unit primary failover lan interface failover GigabitEthernet0/3 failover key ***** failover link failover GigabitEthernet0/3 failover interface ip failover 10.200.40.1 255.255.255.252 standby 10.200.40.2 interface GigabitEthernet0/3 description LAN/STATE Failover Interface monitor-interface dmz monitor-interface inside monitor-interface outside monitor-interface management



	400 Chapter 12: Case Studies

	Example 12-9 includes the CLI commands sent to the secondary appliance. Example 12-9 Failover Configuration on the Secondary ASA failover failover lan unit secondary failover lan interface failover GigabitEthernet0/3 failover key ***** failover interface ip failover 10.200.40.1 255.255.255.252 standby 10.200.40.2 interface GigabitEthernet0/3 no shutdown

	You will see the message shown in Example 12-10 after the secondary appliance is configured and the configuration replication is performed. Example 12-10 Failover Configuration Replication Confirmation companyB-ASA1#.. Detected an Active mate Beginning configuration replication from mate. companyB-ASA1# End configuration replication from mate.

	Configuring AAA on the Infrastructure Devices The network administrator configures authentication, authorization, and accounting (AAA) for administrative access to all routers within the network. The network administrator uses command authorization to enforce which commands users can invoke and execute in the routers. Example 12-11 shows a AAA configuration template used for all routers within the organization: Example 12-11 AAA Configuration on Routers aaa new-model aaa authentication login default group tacacs+ local tacacs-server host 172.18.85.181 tacacs-server key 1qaz2wsx

	The aaa new-model command enables the AAA security services. The aaa authentication command defines the default method list. Incoming logins on all interfaces (by default) use TACACS+ for authentication. If no TACACS+ server responds, the network access server uses the information contained in the local username database for authentication. The tacacs-server host command identifies the TACACS+ server as having an IP address of 172.18.85.181. The tacacs-server key command defines the shared encryption key to be 1qaz2wsx. The administrator also configures AAA on the Cisco ASAs for Telnet, Secure Shell (SSH), HTTPS, and serial console access. The commands used are shown in Example 12-12.



	Case Study of a Large Enterprise 401

	In this example, authentication is performed using an external TACACS+ server (that is, Cisco Secure ACS). Example 12-12 Cisco ASA AAA Configuration !The following commands define a TACACS+ server and limit the number of failed attempts to 4.The server group name is svrgrp ! aaa-server svrgrp protocol tacacs+ max-failed-attempts 4 _! !The TACACS+ server (172.18.85.101) and a shared secret (1qaz2wsx) are defined. The timeout is set to 5 seconds. aaa-server svrgrp host 172.18.85.101 1qaz2wsx timeout 5 _! !Telnet authentication aaa authentication telnet console svrgrp _! !Serial console port authentication aaa authentication serial console svrgrp _! !HTTPS authentication for ASDM connections aaa authentication secure-http-client

	Cisco Secure ACS is used as the TACACS+ server. The following steps are taken to add the routers and the Cisco ASAs as authentication clients on Cisco Secure ACS: Step 1 Log in to the Cisco Secure ACS web admin console. Step 2 Choose Network Configuration on the left, and click Add Entry to add an entry for the Cisco ASAs or routers in either the TACACS+ or RADIUS server database. Step 3 Choose the server database according to the routers and Cisco ASA configurations. Because TACACS+ is used in this example, choose TACACS+ (Cisco IOS) under the Authenticate Using drop-down menu. Step 4 Configure the shared key. This key is used for authentication between the authentication client (router or Cisco ASA) and Cisco Secure ACS.

	Case Study of a Large Enterprise Company-C is a large enterprise that offers numerous information technology products and services. Over the past few years, this company has been growing at a fast pace. Recently, Company-C acquired Company-A and Company-B. The Raleigh and Atlanta offices of Company-A became branch offices, and the Chicago office of Company-B became a regional office, as illustrated in Figure 12-58. The headquarters is located in New York City.





	Call Center



	Case Study of a Large Enterprise 403

	The following is a high-level explanation of the New York office topology: • At the Internet edge, a pair of Cisco Catalyst 6500 switches is deployed with FWSMs. • A cluster of Cisco ASAs is configured for IPsec- and SSL-based remote access VPN. • Cisco routers are configured to terminate IPsec site-to-site VPN tunnels to the branch offices and the regional office. • The user population includes the following: — A call center of more than 100 customer service representatives — The executive floor — Sales representatives — Engineering — Finance • A large data center is also located at the New York office. With the dramatic growth, Company-C staff members initiate several corporate initiatives and projects to increase the security of the network. The following sections include information about different techniques and methodologies that Company-C staff members use.

	Creating a New Computer Security Incident Response Team (CSIRT) Company-C management starts the process to create a Computer Security Incident Response Team (CSIRT). The CSIRT will comprise staff members from different departments within an organization: • Global information technology (IT) • Information Security (InfoSec) • Operation Security (OpSec) • Business analysis team

	TIP In some large organizations, the CSIRT may be a full-time staff. Deciding whether the staff members should be full-time or not depends on your organizational needs and budget. What is important is to clearly identify who needs to be involved at each level of the CSIRT planning, implementation, and operation. For instance, one of the most challenging tasks is the process of identifying the staff members who will be performing security incident response functions. In addition, you must identify which internal and external organizations will interface with the CSIRT. Evangelize and communicate the CSIRT responsibilities accordingly with these entities.



	404 Chapter 12: Case Studies

	The new CSIRT team develops and documents roles and responsibilities for all CSIRT members and their functions. Each member has a different background and qualifications. These roles and responsibilities are assigned based on the experience and strengths of each member.

	Creating New Security Policies The executive team of Company-C also delegates the tasks of creating new security policies within the organization. Since Company-C acquired Company-A and Company-B new policies need to be defined and followed. The following are the new policies that are created: • Physical security • Perimeter security • Device security • Remote access VPN • Patch management • Change management • Internet access policy

	Physical Security Policy The physical security policy is created to protect and preserve information, physical assets, and human assets by reducing the exposure to various physical threats. A new employee badge system is deployed to deny unauthorized access and to track authorized entry. Card access and monitoring devices will be used to ensure that sensitive information is not compromised and access to control office work areas is monitored. The building facility manager will ensure that appropriate monitoring devices allow monitoring of primary accesses and that each individual is screened for access. In addition, a video surveillance system must be implanted and appropriately managed. This video system should function with an existing Ethernet switched environment, and it should reduce the complexity while lowering the cost of deploying video surveillance. It also provides video surveillance system owners with the flexibility to design solutions tailored to their unique requirements.

	Perimeter Security Policy The company already has perimeter configuration guidelines that are implemented within the organization. However, these guidelines were never documented in an organized fashion. The staff members at Company-C create a detailed perimeter security policy.



	Case Study of a Large Enterprise 405

	Device Security Policy Just as with perimeter security, the company already has device configuration guidelines that are implemented within the organization. However, these guidelines were never documented in an organized fashion. The staff members at Company-C create a detailed device security policy. These devices include infrastructure devices such as routers, switches, and other equipment. Remote Access VPN Policy The remote access VPN policy defines the appropriate use of remote access VPN (including IPsec and SSL-based remote access VPNs). The policies include the process of how employees request remote access VPN and how administrators create, modify, and delete remote access accounts. In this case, Company-C uses generic token cards with one-time passwords (OTP) for remote access. When Company-C staff members start developing the remote access VPN policy, they are trying to clarify answers to the following questions: • Does a remote access security policy exist? • Is the security policy frequently reviewed and revised to reflect technology changes, outmoded approaches, or new product or service offerings affecting company/ customer relationships and system interaction? • Does the remote access policy specify guidelines for the selection and implementation mechanisms that control access among authorized users and corporate computers and networks? • Does the remote access policy conform to all existing corporate communications guidelines? • Does the remote access policy address the physical protection of the communications medium, devices, computers, and data storage at the remote site? • Does the security policy require the classification of the functions, applications, and data to determine the levels of security needed to protect the asset? • Does a policy exist to obtain access to important proprietary information at remote sites? • Does a policy exist for reporting unauthorized activity? • Does a policy exist that defines appropriate personal use of company equipment? • Do remote access users have to sign a form stating they know and understand the remote access policies? • Is there a formal, complete, and tested disaster recovery plan in place for the remote sites?



	406 Chapter 12: Case Studies

	Patch Management Policy The patch management policy establishes requirements for a secure patch management program for all Company-C networks to prevent disruption of service and unauthorized use because of vulnerabilities in unpatched systems. The patch management program shall be used to create a consistently configured environment that ensures security against known vulnerabilities in operating systems and application software. A key component of patch management is the intake and selection of information regarding both security issues and patch release. The patch cycle shall be used to facilitate the application of standard patch releases and updates. This cycle can be time or event based. For example, the schedule can mandate that system updates occur quarterly, or a cycle may be driven by the release of service packs or maintenance releases. Testing of software patches is crucial. Company-C creates a patch test process within this policy. After a patch has been determined valid, it shall be placed in a test environment that closely mirrors the production environment. Critical applications and supported operating platforms must be fully accounted for while testing the patch infrastructure.

	Change Management Policy Change management practices are applied to the patch management process and any other configuration or system changes within the whole infrastructure. After a configuration or a system has been identified for change, a request-for-change must be submitted, and the configuration should be modified according to the procedures that the change management process has established.

	Internet Usage Policy The Internet usage policy allows for reasonable use of the Internet by outlining the permitted and prohibited behaviors and defining violations. This policy should apply to all Internet users who access the Internet through the computing or networking resources. This includes permanent, full-time, and part-time employees; contract workers; temporary agency workers; business partners; and vendors. The Internet users of your organization are expected to be familiar with and to comply with this policy, which should also require the use of common sense and good judgment while using Internet services.

	Deploying IPsec Remote Access VPN Company-C deploys a cluster of Cisco ASAs to provide IPsec remote access VPN services. Figure 12-59 illustrates the topology listing the Cisco ASAs and their corresponding IP addresses.



	Case Study of a Large Enterprise 407

	Figure 12-59 Remote Access VPN Cisco ASAs



	Remote Access VPN ASA Cluster Virtual IP 209.165.202.131

	ASA-1	ASA-2 d Management IP: 10.250.30.2 Outside: 209.165.202.130 Inside: 10.250.10.2
	Management IP: 10.250.30.1 Outside: 209.165.202.129 Inside: 10.250.10.1

	Corporate

	The following are the IP addresses of each interface on the first Cisco ASA (ASA-1): • Management interface: 10.250.30.1 • Inside interface: 10.250.10.1 • Outside interface: 209.165.202.129 The following are the IP addresses of each interface on the second Cisco ASA (ASA-2): • Management interface: 10.250.30.2 • Inside interface: 10.250.10.2

	Outside interface: 209.165.202.130



	408 Chapter 12: Case Studies

	The following sections demonstrate how the Cisco ASAs are configured for IPsec and SSL remote access VPN.

	Configuring IPsec Remote Access VPN The administrator completes the following steps to configure IPsec remote access VPN on the Cisco ASAs: Step 1 Log in to the Cisco ASA using ASDM. Step 2 On the main menu, choose Wizards. Step 3 Select the IPsec VPN Wizard. Step 4 The IPsec VPN Wizard starts. Specify the tunnel type as shown in Figure 12-60. Figure 12-60 Configuring the Tunnel Type



	Step 5 All remote access VPN clients will be connecting to the outside interface. Choose the outside interface from the VPN Tunnel Interface drop-down menu, as shown in Figure 12-60. Step 6 Enable inbound IPsec sessions to bypass all configured ACLs, as shown in Figure 12-60.

Case Study of a Large Enterprise 409

Step 7 Click Next.

Step 8 The screen shown in Figure 12-61 is displayed. Under VPN Client Type, click Cisco VPN Client, Release 3.x or higher, or other Easy VPN Remote product.

Figure 12-61 Remote Access VPN Client Type


	i'J'JU'JISi'li
	*Ш Щ*	REmote access users of various types can open VPN tunnels to this ASA, Select the type of VPN client for this tunnel.

	'------" W	VPN Client Type:
	- \	(+) Cisco: VPN Client, Release З.к or hlaher,\| or other Easy VPN Remote product
		0 Microsoft Windows client using L2TP over IPsec
		Specify the PPP authentication protocol. If a protocol is not specified on the remote client, do not specify it. ? PAP 0 CHAP R7] MS-CHAP-V1 ? M5-CHAP-V2 ? EAP-PROXY Specify if the client will send tunnel group name a? - usernarne@tunnelgroup.
		r~J Client will send tunnel group name as username@tunnelgroup.
		If рге-shared authentication is used with this option then DefaultRAGroup's pre-shared key and ppp authentication are also modified.
	\| \|\| Nnnts ]\| Finish \| [ Cancel \| \| Help \|

Step 9 Click Next.

Step 10 The screen shown in Figure 12-62 is displayed. Configure a preshared key and a VPN tunnel group, as shown in Figure 12-62. In this example, the preshared key is 1qaz2wsx, and the tunnel group is IPSEC-RA-GROUP.

Step 11 Click Next.

Step 12 The screen shown in Figure 12-63 is displayed. In this example, the Cisco ASAs are configured for external authentication to a RADIUS server. The AAA server group name is RADIUS-Server, as shown in Figure 12-63.



	410 Chapter 12: Case Studies

	Figure 12-62 VPN Client Authentication Method and Tunnel Group Name



	Figure 12-63 Client Authentication



	Case Study of a Large Enterprise 411

	Step 13 Click Next.

	Step 14 The screen shown in Figure 12-64 is displayed. This screen allows you to configure an IP address pool used for remote access VPN connections. Click New to add a new pool. Figure 12-64 IPsec Remote Access VPN IP Address Pool



	Step 15 Specify a name for the IP address pool. In this example, the name of the pool is IPSec-Pool. Step 16 Configure the starting and ending IP addresses, in addition to a subnet mask. In this example, the address range in the pool is from 10.250.50.1 to 10.250.50.254, with a 24-bit subnet mask (255.255.255.0). Step 17 Click Next. Step 18 The screen shown in Figure 12-65 is displayed. This screen allows you to configure the primary and secondary DNS and WINS servers, in addition to the domain name. In this example, the primary DNS server is 172.18.124.12; the secondary DNS server is 172.18.124.13; the primary WINS server is 172.18.124.14; and the secondary WINS server is 172.18.124.15. The domain name is companyc.com.



	412 Chapter 12: Case Studies

	Figure 12-65 DNS and WINS Server Configuration



	Step 19 Click Next. Step 20 The screen shown in Figure 12-66 is displayed. This screen allows you to configure the IKE policy used by remote access VPN connections. In this example, the encryption algorithm used is AES-256. SHA is used for authentication, and the Diffie-Hellman (DH) group used is 5. Step 21 Click Next. Step 22 The screen shown in Figure 12-67 is displayed. This screen allows you to configure the IPsec encryption and authentication parameters. In this example, the encryption protocol used is AES-256, and SHA is used for IPsec Phase 2 authentication.



	Case Study of a Large Enterprise 413



	414 Chapter 12: Case Studies

	Step 23 Click Next. Step 24 The screen shown in Figure 12-68 is displayed. This screen allows you to configure the Cisco ASA to bypass NAT for remote access VPN connections. In this case, the inside network is selected (10.250.10.0/24). The inside 10.250.10.0/24 network will not be translated when communicating with remote access VPN clients. Figure 12-68 Bypassing NAT and Configuring Split Tunneling



	Step 25 The screen shown in Figure 12-68 also allows you to configure split tunneling for remote access VPN connections. To enable split tunneling, select Enable split tunneling to let remote users have simultaneous encrypted access to the resources defined earlier, and unencrypted access to the Internet option. Step 26 Click Next. Step 27 A summary screen appears. Click Finish to apply the changes to the Cisco ASA.



	Case Study of a Large Enterprise 415

	Configuring Load-Balancing The administrator configures load-balancing on each security appliance. The following are the steps to configure load-balancing for remote access VPN. Step 1 Log in to the Cisco ASA using ASDM. Step 2 On the main menu, choose Wizards. Step 3 Choose the High Availability and Scalability Wizard. Step 4 The High Availability and Scalability Wizard starts. The screen shown in Figure 12-69 is displayed. Click Configure VPN Cluster Load Balancing, as shown in Figure 12-69. Figure 12-69 High Availability and Scalability Wizard



	Step 5 Click Next. Step 6 The screen shown in Figure 12-70 is displayed. Enter the cluster IP address. The cluster IP address is the virtual address that VPN clients will use to connect to the cluster. In this example, the cluster IP address is 209.165.202.131.



	416 Chapter 12: Case Studies

	Figure 12-70 VPN Cluster Load-Balancing Configuration



	Step 7 Enter a UDP port for load-balancing communication between all Cisco ASAs within the cluster. In this example, the default UDP port (9023) is used. Step 8 Optionally, you can encrypt all VPN load-balancing traffic. Check the Enable IPsec encryption option to enable encryption. Step 9 Configure a preshared secret. In this example, the preshared secret is 2wsx1qaz. Step 10 The priority is set to 5. The higher the priority, the more commonly that this ASA will become the master of the cluster. Step 11 The public interface is the outside interface in this example. The private interface is the inside interface, as shown in Figure 12-70. Step 12 Click Next. Step 13 A summary screen is displayed. Step 14 Click Finish to apply the configuration to the Cisco ASA.



	Case Study of a Large Enterprise 417

	Example 12-13 shows the Cisco ASA remote access VPN and load-balancing CLI configuration. Example 12-13 Cisco ASA Remote Access VPN and Load-Balancing Configuration hostname asa-1 ! interface GigabitEthernet0/0 description Outside interface connected to the Internet nameif outside security-level 0 ip address 209.165.202.129 255.255.255.0 _! interface GigabitEthernet0/1 description Inside interface connected to corporate network nameif inside security-level 100 ip address 10.250.10.1 255.255.255.0 _! interface Management0/0 nameif management security-level 0 ip address 10.250.30.1 255.255.255.0 management-only _! !Split tunneling ACL access-list IPSEC-RA-GROUP_splitTunnelAcl standard permit 10.250.10.0 255.255.255.0 !ACL to bypass NAT for remote access VPN connections access-list inside_nat0_outbound extended permit ip 10.250.10.0 255.255.255.0 10.250.50.0 255.255.255.0 _! !IP address pool for remote access VPN clients ip local pool IPSec-Pool 10.250.50.1-10.250.50.254 mask 255.255.255.0 _! !NAT configuration nat (inside) 0 access-list inside_nat0_outbound _! !RADIUS Configuration for remote access VPN authentication aaa-server RADIUS-Server protocol radius aaa-server RADIUS-Server (management) host 172.18.85.181 timeout 5 key cisco123 _! !Crypto map configuration crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set transform-set ESP-AES-256- SHA crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP crypto map outside_map interface outside continues



	418 Chapter 12: Case Studies

	Example 12-13 Cisco ASA Remote Access VPN and Load-Balancing Configuration (Continued) _! !ISAKMP enabled on the outside interface crypto isakmp enable outside !ISAKMP policy for Remote Access VPN crypto isakmp policy 10 authentication pre-share encryption aes-256 hash sha group 5 lifetime 86400 _! !Load-balancing Configuration vpn load-balancing cluster key 2wsx1qaz cluster ip address 209.165.202.131 cluster encryption participate _! !Remote Access Group Configuration group-policy IPSEC-RA-GROUP internal group-policy IPSEC-RA-GROUP attributes wins-server value 172.18.124.14 172.18.124.15 dns-server value 172.18.124.12 172.18.124.13 vpn-tunnel-protocol IPSec split-tunnel-policy tunnelspecified split-tunnel-network-list value IPSEC-RA-GROUP_splitTunnelAcl default-domain value companyc.com tunnel-group IPSEC-RA-GROUP type remote-access tunnel-group IPSEC-RA-GROUP general-attributes address-pool IPSec-Pool authentication-server-group RADIUS-Server default-group-policy IPSEC-RA-GROUP tunnel-group IPSEC-RA-GROUP ipsec-attributes pre-shared-key *

	Reacting to a Security Incident It is 4:00 a.m. (0400) on Christmas day, and the CSIRT team hotline rings with a call from one of the database administrators. The network is congested, and no transactions are possible to the most critical application in the organization from different sections of the organization. The CSIRT collects all available information from the database administrator and completes the steps described in the following sections.



	Case Study of a Large Enterprise 419

	Identifying, Classifying, and Tracking the Security Incident or Attack One of the members of the CSIRT collects NetFlow data from the data center distribution switch and correlates this data with CS-MARS. He notices that most of the traffic is HTTP (TCP port 80). This traffic is originating from known sources in the sales department (floor) in the New York office and from unknown sources. The CSIRT team works with a network administrator and discovers that the unknown sources are IP addresses belonging to the Atlanta branch office network. However, this process took almost an hour. Reacting to the Incident The CSIRT team works with the network administrators in the Atlanta and New York offices to configure an ACL on the router in the Atlanta office and a VACL on the access switch in the sales floor. This ACL only blocks HTTP traffic from the offending machines. The malicious traffic has been contained, but it is possible that other machines have been infected. The CSIRT team works with the desktop support group and server administrators. After doing research and forensics on the traffic, they discover that the traffic pattern is similar to a published vulnerability on security intelligence sites such as Cisco Security Center and US-CERT. However, their network IPS and other mechanisms were not able to detect the threat because the necessary signatures were not installed. The server administrators and desktop support representatives download a security patch from the operating system vendor. Subsequently, they install this operating system patch on the affected machines. They also push this update via their patch management system to all machines within the organization. In addition, the correct signatures are installed on the IPS systems within the organization.

	Postmortem The	CSIRT creates a postmortem including the following information: Total amount of labor spent working on the incident Elapsed time from the beginning of the incident to its resolution Elapsed time for each stage of the incident-handling process Time it took the incident response team to respond to the initial report of the incident Estimated monetary damage from the incident Lessons learned Action plan



	420 Chapter 12: Case Studies

	The lessons learned section in the postmortem is documented, including all items that will improve the incident response process and the proactive preparation of resources and processes to better defend against new threats. In this example, the following are areas that should be improved and are taken into an action plan: • The incident identification process was successful because the correct tools and mechanisms were in place. However, the identification of the Atlanta office IP address space was not obvious, and the process was delayed for more than an hour. Better documentation and diagrams should be prepared to avoid this in the future. The CSIRT team, in addition to network administrators, should have this information accessible when responding to an attack. • IPS signatures were not upgraded because of a bad tuning and update process. A new process is developed to address this caveat. • ACLs were deployed manually to contain and mitigate the attack. The network engineering teams will evaluate and create other tools and technologies, such as remotely triggered black holes (RTBH) or more appropriate mechanisms, to quarantine infected sources in a more effective fashion. Each item on this action plan is assigned an owner and a due date.

	Summary This chapter covered three case studies: a small business, a medium-sized enterprise, and a large enterprise. It demonstrated some of the most common applications and procedures discussed within this book. However, each of the previous chapters presented detailed instructions on how to proactively and reactively defend against security threats. Various configuration examples were included in this chapter. The examples included infrastructure protection mechanisms and practices, basic firewall configuration, site-to-site and remote access VPNs, and a basic example of a CSIRT responding to a security incident. Security threats such as distributed denial of service (DDoS) attacks, worms, and others can result in significant loss of time and money for many organizations. It is highly recommended that you consider the extent to which the organization could afford a significant service outage and take steps commensurate with the risk.

Chapter 11: IPv6 Security

admin — Fri, 12 Mar 2010 10:23:09 +0000



	Summary 421

	The network security lifecycle requires specialized support and a commitment to best practice standards. In this book, you learned best practices drawn upon disciplined processes, frameworks, expert advice, and proven technologies that will help you protect your infrastructure and organization. You learned the complete security lifecycle of a network, from strategy development to operations and optimization. You must take a proactive approach to security, an approach that starts with an assessment to identify and categorize your risks. In addition, you need to understand the network security technical details relating to security policy and incident response procedures. This book covered numerous best practices that will help you orchestrate a long-term strategy for your organization.	Internet Protocol Version 6 (IPv6) is often called the next generation protocol and is designed to replace the widely deployed Internet Protocol Version 4 (IPv4). Despite that, IPv6 has only been implemented in a few places, but it is expected to grow over time. For example, Microsoft Windows Vista includes support for IPv6. IPv6 enables easier support and maintenance of service provider networks than previous versions. The large address space improves the usage of online support systems and enables the inexpensive provision of address space to end users. Many service providers in Europe, Asia, and the United States are currently working on providing IPv6 services to enterprises and small businesses. This chapter includes several IPv6 security topics. It also provides a comparison with IPv4 from a threat and mitigation perspective.

	NOTE	This chapter requires a basic knowledge of the IPv6 protocol.

	IPv6 is defined in RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification." The following are some of the main differences between IPv6 and IPv4: • Expanded addressing: The IP address size is increased in IPv6 to 128 bits from the 32 bits supported in IPv4. This introduces considerable flexibility while supporting more levels of addressing hierarchy. Multicast routing scalability is also improved by the addition of a "scope" field to multicast addresses. • Simplified header format: Several of the header fields used in IPv4 are not used in IPv6. These fields include check sum, Internet header length (IHL), identification flag, and fragment offset. • Improved support for extensions and options: IPv6 encodes information into separate headers. • Fragmentation performed at the end hosts: Unlike IPv4 packets, routers do not perform packet fragmentation on IPv6 packets. IPv6 supports payloads that are longer than 64 Kilobytes (KB). • Authentication: IPv6 supports built-in authentication and confidentiality.



	330 Chapter 11: IPv6 Security

	TIP Several sites include good information about IPv6, including the following: • Cisco IPv6 information on IOS: http://www.cisco.com/go/ipv6 • IPv6 Forum: http://www.ipv6forum.com • 6Net IPv6 International Research: http://www.6net.org • Internet2 IPv6 Working Group: http://ipv6.internet2.edu

	The first thing you need to learn about IPv6 security is the different types of security threats that may affect your IPv6 deployment. This chapter covers the most common types of threats in IPv6 and other security topics, such as: • Reconnaissance • Filtering in IPv6 • Spoofing • Header manipulation and fragmentation • Broadcast amplification or smurf attacks • IPv6 routing security • IPsec and IPv6 Reconnaissance Reconnaissance in IPv6 is not as easy to perform as in IPv4 networks. Do not forget that IPv6 has many more addresses than IPv4 (2^Л64 to be exact, or 128-bit addresses). Performing a network scan for that many addresses is not feasible for an attacker because it takes a considerable amount of time to scan millions of addresses. Attackers use different techniques to gain more visibility of your network. Inevitably, many network administrators may adopt addresses that are easy to remember to assign to network devices (for example, ::10, ::20, ::F00D). Attackers may use these types of addresses in specific scans or reconnaissance methodologies. Instead of standardizing on host addresses, try something that is more difficult for attackers to guess. For example, you may want to use something like ::DEE1 for default gateways. Some people refer to this technique as security through obscurity. That technique can be beneficial, because it does not require administrative complications. Standardizing on a short, fixed pattern for interfaces that should not be directly accessed from the outside allows for a short filter list at the border routers. Because Domain Name System (DNS) is still used to map systems to IPv6 addresses on external and internal networks, an attacker can obtain information on your IPv6 network addresses if he compromises the DNS infrastructure/application.



	Filtering in IPv6 331

	Just as for IPv4, it is recommended that you filter all IPv6 services at the perimeter router or firewall in an effort to protect the internal networks. Privacy becomes a problem when you use DHCPv6 on an IPv6 network. An IPv6 address has two parts. The first part is the subnet prefix, and the second part is a local identifier. This identifier is typically derived from your MAC address. The subnet prefix is a fixed 64-bit length for all current definitions. DHCP is not suitable for some IPv6 environments because you can technically get an IPv6 address via DHCPv6 in your corporate network and then get the same address when you are at home or at a hotel. Attackers can track you down with the use of web cookies that can retain your address information. That is why it is recommended that you use IPv6 Privacy Extensions for external communication. RFC 3041 defines the use of IPv6 Privacy Extensions. Filtering in IPv6 Filtering of unauthorized access in IPv6 is similar to IPv4. This section includes examples of IPv6 access control lists (ACL), in addition to best practices when filtering ICMPv6 unnecessary packets and extension headers. Filtering Access Control Lists (ACL) You can configure the filters or ACLs using Layer 3 and Layer 4 information. You can configure an IPv6 ACL in a Cisco IOS router using the ipv6 access-list command. The command uses the permit and deny subcommands with the following options: ipv6 access-list command and its subcommands permit *protocol* *{source-ipv6-prefix/prefix-length* I any I host *source-ipv6-address}* *[operator* *[port-number]]* *{destination-ipv6-prefix/prefix-length* I any I host *destination-ipv6-address}* *[operator* *[port-number]]* [dest-option-type *[doh-number* I *doh-type]]* [dscp *value]* [flow-label *value]* [fragments] [log] [log-input] [mobility] [mobility-type *[mh-number* I *mh-type]]* [reflect *name* [timeout *value]]* [routing] [routing-type *routing-number]* [sequence *value]* [time-range *name]* deny *protocol* *{source-ipv6-prefix/prefix-length* I any I host *source-ipv6-address}* *[operator* *[port-number]]* *{destination-ipv6-prefix/prefix-length* I any I host *destination-ipv6-address}* *[operator* *[port-number]]* [dest-option-type *[doh-number* I *doh-type]]* [ dscp *value]* [ flow-label *value]* [ fragments] [ log] [ log-input] [ mobility] [ mobility-type *[mh-number* I *mh-type]]* [ routing] *[routing-type* *routing-number]* *[sequence* *value]* *[time-range* *name]* *[undetermined-transport]* Example 11-1 shows an ACL in a Cisco IOS router allowing HTTP traffic (TCP port 80) from a trusted IPv6 host and denying all other traffic. Example 11-1 IPv6 Access Control List ipv6 access-list outside_acl permit tcp 2001:1234:0300:0101::/32 any eq 80 interface FastEthernet 0/0 ipv6 traffic-filter outside_acl in



	332 Chapter 11: IPv6 Security

	In the previous example, the ACL name is outside_acl, and it is applied inbound to the FastEthernet 0/0 interface.

	NOTE Standard IPv6 ACLs are supported starting with Cisco IOS Version 12.2(2)T and 12.0(21)ST and later.

	In the Cisco ASA and Cisco PIX security appliances, the IPv6 ACLs are similar to IOS. To create an IPv6 ACL to allow the same host to pass HTTP traffic on the Cisco ASA or Cisco PIX, use the ipv6 access-list command, as shown in the following example: ipv6 access-list asa_outside_acl permit tcp 2001:1234:0300:0101::/32 any eq www -access-group asa_outside_acl in interface outside Notice that the IPv6 access list is applied to the outside interface using the access-group command just as for IPv4 access lists.

	NOTE IPv6 has been supported on the Cisco PIX since Version 7.0. The Cisco ASA supports IPv6 in all versions, because the first version of Cisco ASA software is 7.0.

	ICMP Filtering You may also want to filter unnecessary ICMPv6 messages, just as with ICMPv4. It is recommended that you configure your ICMPv6 filters and policies in a manner that is similar to your ICMPv4 policies, with the following additions: • ICMPv6 Type 2: Packet too big • ICMPv6 Type 4: Parameter problem • ICMPv6 Type 130-132: Multicast listener • ICMPv6 Type 133/134: Router solicitation and router advertisement • ICMPv6 Type 135/136: Neighbor solicitation and neighbor advertisement Make sure that, if you need to allow these options, you only allow trusted sources and deny everything else. Extension Headers in IPv6 In IPv6, IP options are replaced with extension headers. An attacker may use these extension headers to evade your security configuration. All devices running IPv6 must accept packets with a routing header. In some cases, it may be possible for end-host devices



	Header Manipulation and Fragmentation 333

	to also process routing headers and forward the packet somewhere else. Attackers can take advantage of this and use routing headers to evade the ACLs configured on your routers and firewalls. As a best practice, you should designate specific devices that are allowed to act as Mobile IPv6 (MIPv6) home agents. MIPv6 is a protocol developed as a subset of IPv6 to support mobile connections. You should typically only assign the default router for a specific subnet to act as an MIPv6 home agent. If MIPv6 is not needed, packets with the routing header can easily be dropped at your firewalls and routers without relying on the end host not to forward the packets. Spoofing One of the most common techniques that attackers use is spoofing. Spoofing is the technique of modifying your source IP address or the ports to appear as your packets are initiated from another location. From a Layer 3 spoofing perspective, IPv6 presents a huge benefit because the allocations of IPv6 addresses are designed to easily be summarized allowing service providers to at least ensure that their own customers are not using addresses outside their allocated range. You can use filtering techniques such as those defined in RFC 2827. The following are the most common best practices suggested to protect against IPv6 Layer 3 and Layer 4 spoofing: • Implement filtering techniques as defined in RFC 2827. In Chapter 2, "Preparation Phase," you learned how to create antispoofing ACLs for your IPv4. You should do the same for your IPv6 addresses by denying all traffic from your own network range to be sourced from outside your networks. • In an IPv6 subnet, an attacker has numerous options to select an IP address to spoof. It is critical to have tools to determine the true physical source of the traffic within your network. This generally entails some combination of Layer 2 and Layer 3 information gleaned from switches and routers. Header Manipulation and Fragmentation IPv6 is susceptible to fragmentation and other header manipulation attacks. With these types of attacks, the attacker uses fragmentation to evade network intrusion detection systems (IDS), intrusion prevention systems (IPS), and firewalls. An attacker can also use out-of-order fragments to try to avoid an IDS/IPS device that is deployed to detect attacks based on the enabled signatures on the system. RFC 2460 prohibits fragmentation of IPv6 packets by intermediary network devices.



	334 Chapter 11: IPv6 Security

	As is the case with IPv4, you should always deny IPv6 fragments destined to an internetworking device whenever possible. On the other hand, you should test this in the lab and make sure that this does not cause problems with specific applications in your particular network environment. The combination of multiple extension headers and fragmentation in IPv6 creates the potential that the Layer 4 protocol will not be included in the first packet of a fragment set. Make sure that your IDS/IPS system or any other security monitoring device accounts for this possibility and reassembles fragments. Today, Cisco IPS/IDS devices support multiple extension headers and fragmentation. Broadcast Amplification or Smurf Attacks Broadcast amplification attacks are typically referred to as smurf attacks. These are denial of service (DoS) attacks where the attacker sends an echo-request message with a destination address of a subnet broadcast and a spoofed source address using the host IP address of the victim. This causes all the devices on the subnet to respond to the spoofed source IP address and flood the victim with echo-reply messages. RFC 2463 prohibits IP-directed broadcasts within IPv6. In addition, it states that an ICMPv6 message should not be generated as a response to a packet with an IPv6 multicast destination address, a link-layer multicast address, or a link-layer broadcast address. Smurf attacks should not be a threat if all the devices within your network are compliant with RFC 2463. On the other hand, you should always implement ingress filtering of packets with IPv6 multicast source addresses. IPv6 Routing Security Some routing protocols change in respect to security in IPv6; however; others do not. This section lists the routing protocols that change as well as those that remain the same. Border Gateway Protocol (BGP) continues to have authentication mechanisms such as MD5 authentication but what, if anything, changes with IPv6? The Intermediate System-to-Intermediate System (IS-IS) protocol was extended in a draft specification to support IPv6. In IPv4, the simple password authentication of IS-IS was not encrypted. However, RFC 3567 defines the IS-IS cryptographic authentication. IS-IS in IPv6 also supports this cryptographic authentication mechanism. The Open Shortest Path First Version 3 (OSPFv3) protocol changed to support IPv6. The authentication fields were removed from the header of OSPF messages/packets. Another protocol that removed authentication capabilities was the Routing Information Protocol Next-Generation (RIPng). For this reason, it is recommended that you use traditional

IPsec and IPv6 335

authentication mechanisms for BGP and IS-IS. OSPF for IPv6 requires the use of IPsec to enable authentication. It is always a best practice to use OSPF in conjunction with IPsec to secure routing protocol updates in OSPF for IPv6.

NOTE Cisco IOS routers support the use of IPv6 IPsec to authenticate OSPFv3 starting with Versions 12.3(4)T, 12.4, and later.

IPsec and IPv6

IPsec is available with IPv6. IPv6 headers have no security mechanisms themselves, just as in IPv4. Administrators rely on the IPsec protocol suite for security. The same security risks for man-in-the-middle attacks in Internet Key Exchange (IKE) in IPv4 are present in IPv6. Most people recommend using IKE main mode negotiations when the use of preshared keys is required. On the other hand, IKE Version 2 (IKEv2) is expected to address this issue in the future. IKEv2 supports different peer authentication options with built-in support for asymmetric user authentication through the Extensible Authentication Protocol (EAP).

The IPv6 IPsec packet format is basically the same as in IPv4. Figure 11-1 illustrates an IPv6 packet where Authentication Header (AH) and Encapsulation Security Payload (ESP) protocols are used. IPv6 AH and ESP extension headers are used to provide authentication and confidentiality to IPv6 packets.

Figure 11-1 IPv6 IPsec Packet


IPv6	AH	ESP	IPv6	Payload	Padding	ESP
Header	Header	Header	Header	Payload	Padding	Auth

-ESP Encrypted

ESP HMAC Authenticated — — AH Authenticated-

Cisco IOS supports IPv6 IPsec for VPN tunnels starting with IOS Version 12.4(4)T. Figure 11-2 illustrates a topology where two Cisco IOS routers are configured to terminate a site-to-site IPv6 IPsec tunnel. The IPv6 address of the router in New York is 2EEE:1001::DCBA:BBAA:DDCC:4321, and the IPv6 address of the router in London is

2EEE:2002::ABCD:AABB:CCDD:1234.



	336 Chapter 11: IPv6 Security

	Figure 11-2 IPv6 IPsec Configuration Example

	2EEE:2002::ABCD:AABB:CCDD:1234



	Virtual tunnel interfaces (VTI) are configured on each router in this example. Example 11-2 shows the configuration of the router in New York. Notice that the configuration is almost identical to the IPv4 VTI implementation. In this example, routers use preshared keys with SHA for hashing, and Diffie-Hellman group 1 for Phase 1. AH-SHA-HMAC and ESP-3DES are used for Phase 2. Example 11-2 New York Router Configuration crypto isakmp policy 1 authentication pre-share ! crypto isakmp key 1qaz2wsx address ipv6 2EEE:2002::ABCD:AABB:CCDD:1234/128 _! crypto ipsec transform-set 3des ah-sha-hmac esp-3des _! _! crypto ipsec profile myprofile set transform-set 3des _! ipv6 cef _! interface Tunnel0 ipv6 address 2EEE:1001::/64 eui-64 ipv6 enable ipv6 cef tunnel source FastEthernet0 tunnel destination 2EEE:2002::ABCD:AABB:CCDD:1234 tunnel mode ipsec ipv6 tunnel protection ipsec profile myprofile

	Example 11-3 shows the configuration of the router in London. Notice that the configuration is almost identical for the exception of the IP addresses.

Chapter 10: Data Center Security

admin — Tue, 09 Mar 2010 10:10:26 +0000



	Summary 337

	Example 11-3 London Router Configuration crypto isakmp policy 1 authentication pre-share _{! !} crypto isakmp key 1qaz2wsx address ipv6 2EEE:1001::DCBA:BBAA:DDCC:4321/128 _! crypto ipsec transform-set 3des ah-sha-hmac esp-3des _! crypto ipsec profile myprofile set transform-set 3des _! ipv6 cef _! interface Tunnel0 ipv6 address 2EEE:2002::/64 eui-64 -ipv6 enable ipv6 cef tunnel source FastEthernete tunnel destination 2EEE:1001::DCBA:BBAA:DDCC:4321 tunnel mode ipsec ipv6 tunnel protection ipsec profile myprofile

	The IKE and IPsec Security Associations (SA) are negotiated and established before the line protocol for the tunnel interface is changed to the UP state. The remote IKE peer is the same as the tunnel destination address; the local IKE peer will be the address picked from the tunnel source interface, which has the same IPv6 address scope as the tunnel destination address. Summary This chapter introduced security topics in IPv6. Although it is assumed that you already have a basic understanding on IPv6, this chapter covered fundamental topics of IPv6 including how to filter IPv6 traffic in infrastructure devices such as the Cisco ASA and Cisco IOS routers. When deploying IPv6 on your network, you should pay attention to several security considerations. These considerations include the use of authorization for automatically assigned addresses and configurations, protection of IP packets, host protection from scanning and attacks, and control of traffic that is exchanged with the Internet. In many cases, these security considerations also exist for IPv4 traffic. Understanding the IPv6 security threats is a must for every security professional. This chapter included the most common IPv6 security threats and the best practices adopted by many organizations to protect their IPv6 infrastructure. Many IPv6-enabled devices also support IPsec. This chapter covered how to configure Cisco IOS routers to terminate IPsec in IPv6 networks. It provided sample configurations to enhance the learning.	Protecting Cisco Unified CallManager Server and operating system best practices apply when protecting the Cisco Unified CallManager. Just as with any other critical application, you should make major configuration changes within a maintenance window to avoid the disruption of voice services. However, some standard security policies for application servers might not be adequate for IP telephony servers. For example, on e-mail and web servers, you can easily resend an e-mail message or refresh a web page. On the other hand, voice communications are real-time events. Consequently, your user population will quickly notice any disruption of service. The first step is to restrict activities on IP telephony servers (such as the Cisco Unified CallManager) that might be considered normal on application servers within a network. For instance, you should browse the Internet on CallManager servers. This sounds obvious, however, many administrators fail to do this. Patch management is one of the most crucial aspects of application security. Cisco provides a well-defined patch system for the Cisco Unified CallManager solution. You should apply only patches that Cisco provides and not patch the system using an operating system vendor patch (unless Cisco has approved it).

	NOTE You can download all Cisco Unified CallManager patches from http://www.cisco.com/kobayashi/sw-center/sw-voice.shtml.

	Additional information templates show you how to increase the hardening of the operating system in the Utils\SecurityTemplates directory on your Cisco Unified CallManager server. It is important to know that Cisco Unified CallManager 5.x does not support the use of antivirus software. However, an unmanaged version of the Cisco Security Agent provides security features above and beyond traditional antivirus solutions. As you learned in previous chapters, CSA looks at the server traffic and the way the running applications behave. It then enforces security mechanisms when something is considered abnormal. For instance, CSA prevents any virus or malware that tries to be installed on the system. It prevents the infection before it happens. You can also deploy the full version of CSA to provide granular configuration of security policies within the servers. In addition, you can monitor all CSA event logs from a centralized location (from the CSA Management Control, or CSA-MC).

	NOTE Use of CSA is highly recommended not only for Cisco Unified CallManager but to protect any servers and endpoints within your organization.



	Securing the IP Telephony Applications 277

	In addition, you may want to protect all your servers in your data center with a firewall. The FWSM for the Cisco Catalyst 6500 series switches is typically deployed at the data center. You should configure strict policies on the specific traffic that is allowed to communicate to the Cisco Unified CallManager servers. As a best practice, only allow traffic from your voice VLANs/subnets and traffic from your administrative subnets.

	NOTE Detailed information on how to protect your data center is covered in Chapter 10, "Data Center Security."

	Protecting Cisco Unified Communications Manager Express (CME) As previously discussed in this chapter, the Cisco Unified CME is an entry-level VoIP solution that runs on Cisco IOS Software routers. It is designed for small businesses and autonomous small enterprise branch offices. CME enables you to provide voice, data, and IP telephony services on a single platform. Because it is an integrated solution within Cisco IOS Software routers, all the best practices of router security that you learned in Chapter 2 apply when securing the Cisco Unified CME solution. These best practices include the following: • Configure enable secret passwords or encrypted passwords within the configuration. • Configure administrator access privileges within Cisco IOS Software. • Restrict access to VTY lines for remote administration access. • Use RADIUS or TACACS+ servers for authentication and authorization of administrative sessions. • Configure RADIUS or TACACS+ accounting. • Configure a fallback user account for administrative access when the external authentication server is not available. • Configure Secure Shell (SSH) access instead of Telnet. • Control the access of Simple Network Management Protocol (SNMP) sessions. • Use all other best practices listed in Chapter 2 that protect the control plane and management plane. In addition to the common infrastructure protection best practices, you should only allow IP phones in the trusted domain for registration. You can use the strict-match option in the ip source-address command if your local segment is a trusted domain. This allows only locally attached IP phones to register, as demonstrated in the following example: CME(configtelephony)#ip source-address 192.168.10.1 port 2000



	278 Chapter 9: IP Telephony Security

	Another good practice is to block port 2000 (from external untrusted networks) to prevent unauthorized Skinny Call Control Protocol (SCCP) phones from registering to your Cisco Unified CME. You can use an ACL as demonstrated in the following example: access-list 100 deny tcp any any eq 2000 Always use Secure Socket Layer (SSL) and HTTPS to access the web-based admin console, as shown in the following: ip http server ip http secure-server

	TIP You can also use ip http authentication to perform external RADIUS or TACACS+ server for HTTPS authentication.

	Configure Class of Restrictions (COR) is used to prevent toll fraud. Typically, it is recommended that you configure different classes of service to control the destinations that users can call. For example, you can configure different levels of permissions that allow specific users to dial only local numbers and 911 for any emergencies. In the following example, two different types of users are configured (users and superusers). Superusers are allowed to dial any numbers, and regular users have access to all resources with the exception of toll (1-900 numbers), directory assistance (411), and international calling. This is achieved with the configuration shown in Example 9-4. Example 9-4 Protecting Against Toll Fraud Using COR

	dial-peer cor custom name 911 name 1800 name local-call name ld-call name 411 name int-call name 1900 !different dial-peer names are assigned for the different services; additionally, different COR !lists for each service are configured below. ! dial-peer cor list call911 member 911 _! dial-peer cor list call1800 member 1800 _! dial-peer cor list calllocal member local-call _! dial-peer cor list callint member int-call



	Securing the IP Telephony Applications 279

	Example 9-4 Protecting Against Toll Fraud Using COR (Continued) _! dial-peer cor list callld member ld-call _! dial-peer cor list call411 member 411 _! dial-peer cor list call1900 member 1900 _! dial-peer cor list user member 911 member 1800 member local-call member ld-call !the previous COR list allows regular users (user) to access/use 911, 1800, local calls, and !caller ID services _! dial-peer cor list superuser member 911 member 1800 member local-call member ld-call member 411 member int-call member 1900 dial-peer voice 9 pots corlist outgoing callld destination-pattern 91.......... port 1/0 prefix 1 !the previous COR list allows superusers to access/use all available services _! dial-peer voice 911 pots corlist outgoing call911 destination-pattern 9911 port 1/0 prefix 911 _! dial-peer voice 11 pots corlist outgoing callint destination-pattern 9011T port 2/0 prefix 011 _! dial-peer voice 732 pots corlist outgoing calllocal destination-pattern 9732....... port 1/0 prefix 732 _! continues



	280 Chapter 9: IP Telephony Security

	Example 9-4 Protecting Against Toll Fraud Using COR (Continued) dial-peer voice 800 pots corlist outgoing call1800 destination-pattern 91800....... port 1/0 prefix 1800 _! dial-peer voice 802 pots corlist outgoing call1800 destination-pattern 91877....... port 1/0 prefix 1877 _! dial-peer voice 805 pots corlist outgoing call1800 destination-pattern 91888....... port 1/0 prefix 1888 _! dial-peer voice 411 pots corlist outgoing call411 destination-pattern 9411 port 1/0 prefix 411 _! dial-peer voice 806 pots corlist outgoing call1800 destination-pattern 91866....... port 1/0 prefix 1866 ephone-dn 1 number 2000 cor incoming user Ephone-dn 2 number 2001 cor incoming superuser

	You can configure the Cisco IOS Software Firewall on the same router that runs Cisco Unified CME. On the other hand, you must pay attention to certain requirements needed for Cisco Unified CME to work in your environment. For example, SCCP support is needed for locally generated Skinny traffic. SCCP is a Cisco proprietary lite-version of H.323 for call signaling, control, and media communication. H.323 uses Q.931, H.225, and H.245 for call setup, management, and control. H.323 requires a TCP connection for H.245 signaling that does not have a well-known port associated with it. The H.245 port is dynamically negotiated. NAT and stateful firewalls can break H.323.



	Securing the IP Telephony Applications 281

	NOTE Cisco IOS Software supports unidirectional firewall policy configurations between groups of interfaces which have been known as zones since Version 12.4(6)T. Previously, all inspect rules had to be applied to specific interfaces on routers running the Cisco IOS Firewall feature set. All inbound and outbound traffic was inspected based on the direction to which the inspect rule was applied. Since Version 12.4(11)T, Cisco IOS Software Firewalls have supported H.225 Registration, Admission, and Status (RAS) signaling. H.323 uses the H.225 standard for call setup.

	Protecting Cisco Unity The Cisco Unity solution provides advanced voice mail and messaging features. In this section, you will learn tips for increasing the security of the Cisco Unity solution. Cisco Unity runs over the Microsoft Windows operating system (OS). The first step in protecting the Cisco Unity system is to have a good patch management procedure. Microsoft has different recommendations for installing and securing Windows Server 2003 and Windows 2000 Server systems. For Windows Server 2003, refer to the article "Checklists; Windows Server 2003, Standard Edition" at http://technet.microsoft.com/en-us/default.aspx. For the Windows 2000 Server, refer to the article "Installing and Securing a New Windows 2000 System," which is available on the same website.

	TIP Make sure that the latest supported Cisco Unity service pack and all updates recommended by Microsoft are installed on the server. All supported service packs and recommended updates are listed at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/cmptblty/msupdate.htm.

	You can use security templates to help increase the security of the system. On the other hand, you should always apply all security policies to the Windows server only after the Cisco Unity installation is completed. Some security templates can affect the operation of Cisco Unity. The following Windows 2000 Server settings are recommended to restrict and audit access to the Cisco Unity server. To change these settings, go to Start > Programs > Administrative Tools > Local Security Policy on the Windows 2000 server, and perform the following functions: Step 1 Set the Audit account login events option to Failure. Step 2 Set the Audit account management option to Success, Failure.

282 Chapter 9: IP Telephony Security

Step 3 Select Failure under the Audit directory service access option.

Step 4 Set the Audit login events option to Failure.

Step 5 Under Audit object access, select No auditing.

Step 6 Under the Audit policy change, select Success, Failure.

Step 7 Under the Audit privilege use option, select Failure.

Step 8 Under Audit system events, select No auditing.

Step 9 Under the Act as part of the operating system option, enter the account used to install Cisco Unity.

Step 10 Under the Access this computer from the network, select the following options: Backup Operators, Power Users, Users, Administrators, servername\IWAM, domainname\ISUR_servername.

Step 11 Only allow Backup Operators and Administrators under the Shut down the system option.

It is important that you know the TCP and User Datagram Protocol (UDP) ports used by Cisco Unity. Table 9-1 lists all the TCP and UDP ports and their usage.

Table 9-1 TCP and UDP Ports Used by Cisco Unity


Protocols/Ports	Service	Usage
TCP 25	Simple Mail Transfer Protocol (SMTP)	Allowed inbound and outbound by Microsoft Exchange when installed on the Cisco Unity server.
TCP and UDP 53	Domain Name System (DNS)	Allowed outbound for access name resolution. Used inbound if the DNS server is running on the Cisco Unity server. It is recommended that for your DNS server, you use a server other than the system on which Cisco Unity is installed.
UDP 67	DHCP/Bootstrap Protocol (BOOTP)	Allowed outbound if you are using DHCP instead of static IP addresses. It is recommended that you use static addressing for the server.

Securing the IP Telephony Applications 283

Table 9-1 TCP and UDP Ports Used by Cisco Unity (Continued)


Protocols/Ports	Service	Usage
UDP 68	DHCP/BOOTP	Allowed inbound if you are using DHCP instead of static IP addresses, which is used by the Cisco Unity server to receive DHCP or BOOTP replies.
TCP 80	HTTP	Allowed bidirectional to access the Cisco Unity web console. HTTPS access is recommended.
TCP 135	Microsofts Remote Procedural Call (MS-RPC)	Used to negotiate access to the Media Master, Cisco Unity ViewMail for Microsoft Outlook, the Exchange server, and other Distributed Component Object Model (DCOM) services.
UDP 137	Network Basic Input/Output System (NetBIOS)	NetBIOS Name Service. Used for NetBIOS name resolution or WINS resolution.
UDP 138	NetBIOS	NetBIOS Datagram Service. Used when browsing Windows networks.
TCP 139	NetBIOS	Used to access Windows file shares and perform NetBIOS over TCP/IP connections.
UDP 161	SNMP	Used to send SNMP notifications and to provide SNMP information when the host agent is queried.
UDP 162	SNMP Trap	Used to send SNMP traps.
TCP 389	Lightweight Directory Access Protocol (LDAP) with AD-DC	Allowed outbound to access LDAP directory services.
Configurable (typically it is set to TCP 390 or any unused TCP port)	LDAP with Exchange 5.5	Used to access LDAP directory services.

continues

284 Chapter 9: IP Telephony Security

Table 9-1 TCP and UDP Ports Used by Cisco Unity (Continued)


Protocols/Ports	Service	Usage
TCP 443	HTTP/SSL	Used to perform system administration on a remote Cisco Unity server when it is configured for HTTP/SSL.
TCP 445	SMB	Used outbound to access Windows file shares and perform NetBIOS over TCP/IP connections. Used inbound to access Cisco Unity reports and Microsoft Windows file shares.
TCP 636	LDAP/SSL	Used to access LDAP directory services over SSL.
TCP 691	SMTP/link-state advertisement (LSA)	Used when the Exchange server is running on the Cisco Unity server and the Exchange server is accepting SMTP with LSA.
TCP 1432	Telecommunications Development Symposium (TDS) proxy (CiscoUnityTdsProxy)	Used by local processes to access the SQL Server or Microsoft SQL Server Desktop Engine (MSDE) database.
TCP 1433 (default)	MS-SQL-S	Used to access the SQL Server or MSDE database and to perform replication when Cisco Unity failover is configured.
UDP 1434	MS-SQL-M	Used to access the SQL Server or MSDE database.
TCP 2000	Skinny (SCCP)	Used to access Cisco CallManager.
TCP 2443	Secure Skinny (SCCPS)	Used to access Cisco CallManager via an encrypted channel.
TCP 3268	LDAP with AD-GC	Used to access LDAP directory services when the global catalog server is on another server.

Securing the IP Telephony Applications 285

Table 9-1 TCP and UDP Ports Used by Cisco Unity (Continued)


Protocols/Ports	Service	Usage
TCP 3269	LDAP/SSL with AD-GC	Used to access LDAP directory services over SSL when the global catalog server is on another server.
TCP 3372	Microsoft Distributed Transaction Coordinator (MSDTC)	Used to access the SQL Server or MSDE database when Cisco Unity failover is configured.
TCP 3389	Windows Terminal Services	Used to remotely perform system administration on a Cisco Unity server.
TCP 3653	Node Manager	Used to send manual keepalive packets (or "pings") between the primary and secondary servers when Cisco Unity failover is configured.
TCP 4444	Kerberos authentication	Used to perform Kerberos authentication.
TCP 5060 (default)	Session Initiation Protocol (SIP)	Used when the Cisco Unity server is connecting to SIP endpoints or SIP proxy servers.
TCP 8005	Server Life Cycle (JMX)	Used to access the Tomcat server.
TCP 8009	Apache JServ Protocol (AJP)	Used by Internet Information Server (IIS).
TCP and UDP dynamic (in the range of 1024 through 65535)	DCOM	Used by the Media Master to play and record voice messages, and used when the Cisco Unity server is a domain controller supporting member servers.
Dynamic UDP ports (in the range of 1024 through 65535)	Messaging Application Programming Interface (MAPI) notifications	Used in inbound direction to notify Cisco Unity of changes to subscriber mailboxes when Exchange is the message store.
UDP dynamic (in the range of 22800 through 32767)	Real-Time Protocol (RTP)	Used when sending and receiving VoIP traffic with SCCP or SIP endpoints.



	286 Chapter 9: IP Telephony Security

	Use the information in Table 9-1 to restrict and allow access to firewalls that protect your Cisco Unity servers. Cisco Unity uses Microsoft SQL Server. An important recommendation is to make sure that you increase the security of your Microsoft SQL Server 2000 installation. Make sure you select Windows Authentication Mode when you install Microsoft SQL Server, as documented in the Cisco Unity installation guide. In addition, make sure that you pay attention to the following guidelines: • Use a strong password for the SQL administrator (SA) account. • Restrict client access to Microsoft SQL Server 2000 by only allowing the Cisco Unity service accounts to access the Microsoft SQL Server 2000 directories, folders, and files. You can also grant this access to a highly privileged account designated for use by a system administrator. • Detach the default Northwind and Pubs databases. At a minimum, Internet Explorer (IE) 6.0 with Service Pack 1 must be installed on the Cisco Unity server. Use IE on the Cisco Unity server for Cisco Unity administration only. It is not expected that you will use IE on the Cisco Unity server to browse the Internet and other external resources. On the other hand, in some cases, you may have to access the Microsoft or Cisco websites to obtain patches and hotfixes.

	TIP As part of securing IE, refer to Microsoft Knowledge Base article 826955 at http://support.microsoft.com/kb/826955. It includes instructions on how to reduce the chance of being exposed to a worm like Blaster or Nachi.

	Cisco Unity uses IIS 5.0 and later. Always make sure that you install the latest cumulative update patches for IIS 5.0 on the Cisco Unity server.

	TIP You can also use the guidelines specified in the "Secure Internet Information Services 5 Checklist," which is available on the Microsoft TechNet website, with one exception: grant Full Control access to Cisco Unity directories, folders, and files only to Cisco Unity service accounts and the local server administrators group.



	Securing the IP Telephony Applications 287

	In addition, it is recommended that you pay attention to the following best practices: • Delete all IIS default sample files, folders, and websites. • Disable all default IIS COM objects. • Remove unused script mappings. Cisco Unity uses only the ASA and ASP script mappings. • Do not follow Microsoft recommendations regarding parent paths. The Parent Paths option should remain enabled on the Cisco Unity server.

	TIP Cisco Unity uses Microsoft Message Queuing (MSMQ) 2.0. It is recommended that you do not change the default MSMQ setting of Local Use Only.

	Within Cisco Unity, each application has its own authentication capabilities and mechanisms, and you should become familiar with each of these authentication methods. Cisco has a detailed explanation of each application authentication mechanism at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_unity/unity40/usg/ex/usg006.htm.

	Protecting Cisco Unity Express As mentioned previously in this chapter, Cisco Unity Express is a Linux-based application that runs on Cisco IOS Software routers with either an NM or an AIM. No external interfaces exist on the Cisco Unity Express hardware. In reality, a physical Fast Ethernet interface does exist; however, it is software disabled. All traffic to the Cisco Unity Express hardware must pass through the router. On the other hand, you can access Cisco Unity Express via the router command-line interface (CLI) using the service-module service-engine x/y session command in enable mode. The Cisco Unity Express module also has a CLI, but you cannot configure a password on it. To protect the Cisco Unity Express application, you should first apply all router security best practices that you learned previously in this book to the router itself. In addition, you should only allow SSH access, instead of Telnet, to the router. Cisco Unity Express does not support SSH. However, the communication between the router and Cisco Unity Express is via the router backplane and is not exposed to external interfaces. Therefore, SSH access to the router is sufficient.



	288 Chapter 9: IP Telephony Security

	The initial versions of Cisco Unity Express did not support HTTPS. However, login to the Cisco Unity Express GUI is password protected. One major limitation is that the login information currently travels in cleartext across the IP network. To provide additional protection, you can use an IP Security (IPsec) tunnel to communicate to the router. However, HTTPS is supported on the Cisco Unified Communications Manager Express and Cisco Unity Express since Cisco IOS Software Version 12.2(15)ZJ2. To enable HTTPS access to the Cisco Unity Express application, you must enable the secure HTTP server on Cisco IOS Software with the following two commands: ip http server ip http secure-server You should also use ACLs on the router to restrict access to only the protocols and ports that the Cisco Unity Express software uses. The following are the protocols and ports that Cisco Unity Express uses: • SSH for administrative access: TCP port 22 • DNS: UDP or TCP port 53 • TFTP: UDP port 69 • FTP: TCP port 21 for control and TCP port 20 for data (Active FTP only) • HTTP: TCP port 80 for the Cisco IP phones • HTTPS: TCP port 443 for administrative access to the GUI • Syslog: UDP port 514 • SIP: UDP port 5060 • RTP: UDP port range from port 16384 to port 32767 • NTP: UDP port 123 Cisco Unity Express runs on Linux; however, access to the Linux operating system or to the Linux kernel is not direct. The Linux operating system is entirely embedded. Apply only the patches that Cisco provides. The same goes for SQL and LDAP support. Cisco Unity Express includes a SQL server and LDAP directory services; however, direct access does not exist to the SQL server or the LDAP directory. As with the full version of Cisco Unity, you should also ensure that two servers are configured correctly: first, configuration of authentication to the FTP server that is used for software installation; and second, configuration of the FTP server that is used for backup and restore. Never leave the backup and restore FTP server password configured permanently on the Cisco Unity Express module. In addition, because mailbox PINs do not expire, a best practice is to change all passwords periodically, forcing users to reset their PINs to a new setting.



	Securing the IP Telephony Applications 289

	Protecting Cisco Personal Assistant This section covers the most common best practices to harden the Cisco Personal Assistant. The recommendations to increase the security of the Cisco Personal Assistant server can be summarized into two major areas: • Operating environment • Security policies

	NOTE The Cisco Personal Assistant operating environment is made up of several third-party products. You should follow the security guidelines documented by each of these third-party product vendors. This chapter covers several general guidelines on securing the Cisco Personal Assistant operating environment.

	Hardening the Cisco Personal Assistant Operating Environment The Cisco Personal Assistant operating environment third-party components needed are mainly Microsoft products. Other third-party components, such as Nuance ASR and Real-Speak TTS, are also needed.

	NOTE The following site includes a detailed list of all Cisco Personal Assistant operating environment components: http://www.cisco.com/en/US/products/sw/voicesw/ps2026/prod_maintenance_guides_list.html

	Several of the Cisco Personal Assistant operating environment components are configured by default with minimum security. It is extremely important that customers increase the level of security protection for each of those systems. One of the major flaws is that Microsoft IIS is vulnerable until the Windows 2000 installation on the Cisco Personal Assistant server is complete. You have two options: disable IIS, or wait to install it until after Windows 2000 Service Pack 4 is installed. The recommended method is to install a bundled Windows 2000 installation CD with Service Pack 4.



	290 Chapter 9: IP Telephony Security

	NOTE It is recommended that you go query the Microsoft TechNet website (http://technet.microsoft.com/en-us/default.aspx) for IIS vulnerabilities on a periodic basis. Also, you can always go to http://tools.cisco.com/security/center/home.x for a list of the latest (vendor-neutral) vulnerabilities. You can apply Microsoft-provided security policies to the Cisco Personal Assistant server; however, you should never apply any of these policies until the Cisco Personal Assistant installation is complete. Some security templates can affect the operation of the Cisco Personal Assistant.

	The following are several general guidelines to use when you harden IIS on the Cisco Personal Assistant server: • Always make sure that the most current cumulative update patches for IIS 5.0 are installed on the server. • Always remove all IIS sample files, folders, and web applications. This is specified in the complete IIS 5.0 security checklist available on the Microsoft TechNet website. • Refer to the recommendations described in the complete IIS 5.0 security checklist available on the Microsoft TechNet website to disable all default IIS COM objects. However, do not disable the File System Object (FSO) and Parent Paths. These are enabled by default and are needed for the operation of the Cisco Personal Assistant server. • You can also use the Microsoft IIS Lockdown and URLScan tools. However, it is extremely important that you not disable support for Active Server Pages (.asp) or the Scripts Virtual directory. You can download these tools from the Microsoft TechNet website. One of the requirements of the Cisco Personal Assistant is to have IE Version 6.0 with Service Pack 1. However, it is strongly recommended that you use IE on the server for the administration of the Cisco Personal Assistant only. Microsoft recommends that you subscribe to the Security Notification Service; however, security experts advise against subscribing on the server. To subscribe to that service, drop IE security settings to a lower protection level.



	Securing the IP Telephony Applications 291

	Cisco Personal Assistant Server Security Policies It is recommended that you change several security policies and server settings from their default values. It is also recommended that you enable auditing to track the way the Cisco Personal Assistant server is being accessed. The following values are recommended for the Audit Policies and User Rights Assignments under the Local Policies: Step 1 Set Audit account logon events to Failure. Step 2 Set Audit account management to Success, failure. Step 3 Configure Audit directory service access to Failure. Step 4 Set Audit logon events to Failure. Step 5 Set Audit object access to No auditing. Step 6 Leave Audit policy change at its default value (Success, failure). Step 7 Set Audit privilege use to Failure. Step 8 Leave Audit system events at its default value No auditing. Step 9 Under Access this computer from the network, allow only Backup operators, Power users, Users, Administrators, uservername\IWAM, and domainname\ISUR_servername. In other words, leave all default values except Everyone. Step 10 Under Shut down the system, only allow Backup operators and Administrators. The following is the recommended list of settings that you can modify by using the Windows Local Security Policy utility on the Cisco Personal Assistant server. Step 1 Under Additional restrictions for anonymous connections, select Do not allow enumeration of SAM accounts and shares. Step 2 Disable the Allow system to be shut down without having to log on option. Step 3 Disable the Audit use of Backup and Restore privilege option. Step 4 Disable the Clear virtual memory pagefile when system shuts down option. Step 5 Under Digitally sign client communication (always), select the default Disabled value. Step 6 Enable the Digitally sign client communication (when possible) option.



	292 Chapter 9: IP Telephony Security

	Step 7 Disable the Digitally sign server communication (always) option. Step 8 Enable the Digitally sign server communication (when possible) option. Step 9 Disable Ctrl-Alt-Del requirement for login. Step 10 Enable the Do not display last user name in logon screen option. Step 11 Under the LAN manager authentication level option, select Send NTLM response only. Step 12 Set Number of previous logons to cache (in case domain controller is not available) to 5 logons. This is strictly dependent on your security policy and your environment. Step 13 Enable the Prevent system maintenance of computer account password option. Step 14 Set the Prompt user to change password before expiration to 7 days instead of the 14 days default value. This is strictly dependent on your security policy and your environment; however, as a rule of thumb, 7 days is appropriate for most environments. Step 15 Enable the Restrict CD-ROM access to locally logged-on users only option. Step 16 Enable the Restrict floppy access to locally logged-on users only option. Step 17 Enable the Secure Channel: Digitally encrypt or sign secure channel data (always) option. Step 18 Enable the Secure Channel: Require strong (Windows 2000 or later) session key option. Step 19 Disable the Send unencrypted password to connect to third-party SMB [small and medium-sized business] servers option. Step 20 Set the Smart card removal behavior option to Lock workstation. Step 21 Under Unsigned driver installation behavior, select the Do not allow installation option. Step 22 Under Unsigned non-driver installation behavior, select the Silently succeed / Warn but allow installation option.



	Protecting Against Eavesdropping Attacks 293

	For any other Windows security-related information, see the Microsoft TechNet site. Protecting Against Eavesdropping Attacks Eavesdropping attacks are also known as phone tapping attacks. The main goal is for an attacker to listen, copy, or record a conversation. An example of an eavesdropping attack is an incident reported back in 2006. The phones of about 100 Greek politicians and offices (including the U.S. embassy in Athens and the Greek prime minister) were compromised by a malicious code embedded in Vodafone mobile phone software. The attackers tapped into their conference call system. Basically, by using several prepaid mobile phones, the attackers "joined the conference call" and recorded their conversations. The Cisco ASA, Cisco PIX, and IOS Firewalls provide several features that support the stateful processing of signaling protocols, H.323, and SIP. These devices monitor the specific connection request and required resources and permit only what is specifically necessary for the operation of the system, thereby protecting against session hijacking and spoofing. The Cisco ASA and Cisco PIX security appliances support H.323 inspection by making sure that only compliant transactions are allowed between IP telephony devices, such as Cisco CallManager and other non-Cisco products. Cisco ASA and Cisco PIX support H.323 Versions 3 and 4. They also support multiple calls on the same call signaling channel. Example 9-5 demonstrates how you can configure an H.323 inspection policy map on a Cisco ASA or Cisco PIX security appliance running Version 7.2 or later. Example 9-5 Dynamic Port-Security my_asa(config)# regex phonel "5551234567" my_asa(config)# regex phone2 "5553213212" my_asa(config)# class-map type inspect h323 match-all voice-traffic my_asa(configpmapc)# match called-party regex phone1 my_asa(configpmapc)# match calling-party regex phone2 my_asa(config)# policy-map type inspect h323 h323-policy-map my_asa(config-pmap)# parameters my_asa(configpmapp)# class voice_traffic my_asa(configpmapp)# rtp-conformance enforce-payloadtype my_asa(config-pmap-c)# drop ciscoasa(config)# service-policy h323-policy-map interface inside



	294 Chapter 9: IP Telephony Security

	In Example 9-5, two regular expression entries are configured for two specific phone numbers (5551234567 and 5553213212). This is an optional step, but it gives you the flexibility to inspect traffic based on a specific caller or called party. A class map called voice-traffic is configured to inspect all traffic between the two previously defined phone numbers. The class map is applied to a policy map called h323-policy-map. All noncompliant traffic is dropped. The rtp-conformance enforce-payloadtype parameter is used to ensure that all transit RTP packets comply with protocol specifications. Finally, the policy map is applied to the inside interface using the service-policy command. IPS and IDS devices can also be placed in strategic areas within the network to detect unusual traffic, such as an attempt to execute an unusual command, or a malformed packet indicating some form of protocol manipulation. A good way to protect your voice traffic in untrusted environments is by the use of the voice- and video-enabled VPN (V3PN) solution. V3PN provides secure site-to-site connectivity to transport voice, video, and data. With V3PN, you can enable remote branch offices and teleworkers to use IP telephony services while reducing business operations costs.

	NOTE The following white paper includes detailed information about V3PN design and implementation: http://www.cisco.com/application/pdff/en/us/guest/netsol/ns171/c649/ ccmigration_09186a008074f2d8.pdf

	Media encryption using Secure Real-Time Transport Protocol (SRTP) delivers protection by encrypting the voice conversation, rendering it unintelligible to internal or external eavesdroppers who have gained access to the voice domain. Designed for voice packets, SRTP supports the AES encryption algorithm and is an Internet Engineering Task Force (IETF) RFC 3711 standard. Media encryption on Cisco access routers works with both Cisco CallManager and the media encryption feature on Cisco IP phones, enabling customers to place secure analog phone or fax calls between an IP phone and the PSTN gateway depending on the gateway interface type. The SRTP-encrypted voice packets are almost indistinguishable from RTP voice packets, allowing features like QoS and compression to be implemented without additional development or manipulation. Voice encryption keys derived by Cisco Unified CallManager are securely sent by encrypted signaling path to Cisco Unified IP phones through the use of Transport Layer Security (TLS) and to gateways over IPsec-protected links.



	Summary 295

	Summary IP telephony solutions are being deployed at a fast rate in many organizations. The cost savings introduced with VoIP are significant. On the other hand, these benefits can be heavily impacted if you do not have the appropriate security mechanisms in place. This chapter covers several best practices for securing IP telephony networks. It discusses how to protect voice-enabled networks by protecting infrastructure components. It also covered how to secure different IP telephony components, such as the Cisco Unified CallManager, Cisco Unified CME, Cisco Unity, Cisco Unity Express, and Cisco Unified Personal Assistant. Finally, it covered several mechanisms that are used to combat voice eavesdropping and other attacks.



	This chapter covers the following topics: • Protecting the Data Center Against Denial of Service (DoS) Attacks and Worms • Data Center Segmentation and Tiered Access Control • Deploying Network Intrusion Detection and Prevention Systems • Deploying the Cisco Security Agent (CSA) in the Data Center



		10

	D ata Center	Security

	Data centers comprise some of the most critical assets within any organization. Typically, applications, databases, and management servers reside in the data center. For this reason, it is extremely important to have the appropriate defense mechanisms in place to protect the data center against security threats. Attacks against data center assets can result in lost business applications and the theft of confidential information. This chapter covers several best practices and recommendations used to increase the security of your data center. These topics include protecting against denial of service (DoS) attacks, worms, information theft, and other security threats. The recommendations in earlier chapters are put into action in this chapter to provide an in-depth defense mechanism against existing and new threats.

	Protecting the Data Center Against Denial of Service (DoS) Attacks and Worms

	You can implement different mechanisms and technologies on infrastructure components to help mitigate the effects of DoS and worms on your network. The following are some examples: • SYN cookies in firewalls and load balancers • Intrusion Prevention Systems (IPSs) and Intrusion Detection Systems (IDSs) • Cisco NetFlow in the data center • Cisco Guard • Data center infrastructure protection

	SYN Cookies in Firewalls and Load Balancers

	A commonly used distributed denial of service (DDoS) attack is known as SYN-flooding. In this type of attack, the attacker sends a series of TCP SYN packets that typically originate from spoofed IP addresses. The constant flood of SYN packets can prevent servers within the data center from handling legitimate connection requests. You can use firewalls and



	298 Chapter 10: Data Center Security

	security appliances such as the Cisco ASA and the Cisco PIX enabled with the SYN cookies algorithm to combat SYN flood attacks. In large data centers, the Cisco Firewall Services Module (FWSM), for the Catalyst 6500 series switches, is typically used for this same purpose. Figure 10-1 demonstrates how TCP synchronization message (SYN) cookies work in the Cisco Adaptive Security Appliance (ASA), the Cisco PIX, and the FWSM for the Cisco Catalyst 6500 switches. In this example, a Cisco FWSM is used. Figure 10-1 SYN Cookies in FWSM



	Client FWSM Server The following steps are illustrated in Figure 10-1: 1 A client machine attempts a TCP connection to a web server behind the FWSM and sends the initial SYN packet to the firewall. 2 When the embryonic (half-open) connection limit is reached, the Cisco ASA, Cisco PIX, or Cisco FWSM can act as a proxy for the server and generate a SYN-ACK response to the client SYN request. The SYN-ACK reply has a "cookie" in the sequence (SEQ) field of the TCP header. The cookie is a message digest 5 algorithm (MD5) authentication of the source and destination IP addresses and port numbers. All the connection requests are rebuilt from these cookies. 3 The acknowledgement (ACK) packet SEQ field has the value of the cookie+1. In this case, when the FWSM receives an ACK from the client, it "authenticates" the client and allows the connection to the server. 4 The FWSM sends its own SYN packet to the server. 5 The server replies with an ACK. 6 The FWSM sends its SYN-ACK to the server, and the connection is built. On the Cisco FWSM, you can use the show np command to view SYN cookie statistics. Example 10-1 shows the output of the show np 2 syn command on an FWSM. Example 10-1 Output of show np 2 syn Command FWSM# show np 2 syn Fast Path Syn Cookie Statistics Counters (NP-2)

	SYN_COOKIE: Syn cookie secret wheel index : 16 SYN_COOKIE: Total number of SYNs intercepted : 231356987 SYN_COOKIE: Total number of ACKs intercepted : 204 SYN_COOKIE: Total number of ACKs dropped after lookup : 0

Protecting the Data Center Against Denial of Service (DoS) Attacks and Worms 299

Example 10-1 Output of show np 2 syn Command (Continued)


SYN_COOKIE:	Total	number	of	ACKs successfully validated		: 193
SYN_COOKIE:	Total	number	of	ACKs Dropped: Secret	Expired	: 11
SYN_COOKIE:	Total	number	of	ACKs Dropped: Invalid	Sequence	: 0
SYN_COOKIE:	Total	number	of	Syn Cookie Entries inserted by NP3		: 12
SYN_COOKIE:	ACKs	dropped:	Syn cookie ses not yet		established	: 0
SYN_COOKIE:	Leaf	allocation		failed		: 0
SYN_COOKIE:	Leaf	insertion		failed		: 2088

In the highlighted line in Example 10-1, you can see that the total number of intercepted SYN packets is 231356987. This is most definitely indicative of a SYN flood.

Load-balancing solutions such as the Cisco Content Switching Module (CSM) also support SYN cookies. You can deploy the CSM in inline mode or one-arm mode. Figure 10-2 illustrates a CSM configured in inline mode. Traffic from certain applications cannot be load-balanced because of the nature of those applications. In Figure 10-2, the traffic that cannot be load-balanced is labeled as direct traffic.

Figure 10-2 CSM in Inline Mode

Web Servers

Client

In Figure 10-2, the CSM is configured with both physical interfaces that are connected to the network with all traffic passing through the CSM. Figure 10-3 illustrates the one-arm

CSM design.

The CSM uses a virtual IP address. In a "one-arm" design, you can combine it with a Cisco FWSM. One of the major benefits of using a CSM one-arm design in combination with the Cisco FWSM is that the CSM protects against DoS attacks directed at its virtual IP address, and the Cisco FWSM protects against attacks directed at non-load-balanced servers.

The use of SYN cookies has certain limitations. For example, SYN cookies cannot carry TCP options that are set up in SYN packets; SYN cookies can carry only an encoding of the maximum segment size (MSS) value of the server. Some TCP options are used for performance and scalability (for example, large windows, selective acknowledgement, and so on). Another limitation of SYN cookies is that they do not protect against established connection attacks.



	300 Chapter 10: Data Center Security



	NOTE Established connection attacks are attacks that exploit vulnerabilities after a connection has been established such as a buffer overflow to a specific application.

	Intrusion Prevention Systems (IPS) and Intrusion Detection Systems (IDS) In earlier chapters, you learned the difference between IDS and IPS devices. IDS and IPS appliances and modules are usually placed in the data center distribution center not only to alert an administrator when a security threat has been detected, but also to take action and protect the data center assets. In small environments, one or more IDS/IPS appliances (such as the Cisco 4200 sensors) can be placed in the data center. The Cisco Catalyst 6500 IDS/IPS module (IDSM) is used in larger environments. The Cisco Security Agent (CSA) provides host-based prevention services that help you protect the servers in the data center from attacks that exploit OS and application vulnerabilities. These two technology solutions (network and host-based) complement each other. Despite the fact that both solutions provide intrusion prevention mechanisms that guard against direct attacks, the technologies are different in numerous ways. Later sections in this chapter cover the deployment of both network and host-based IPS solutions. The benefits and limitations of each solution are discussed in their respective sections.



	Protecting the Data Center Against Denial of Service (DoS) Attacks and Worms 301

	Cisco NetFlow in the Data Center Cisco NetFlow provides network traffic visibility that can help in identifying and classifying potential DDoS attempts and other security threats. In addition, it provides valuable information about application usage that can be beneficial for network planning and traffic engineering. You can enable NetFlow in data center infrastructure devices, such as your distribution switches or routers. A new version of NetFlow called Flexible NetFlow is now available on Cisco IOS routers starting with IOS Version 12.4(9)T. Cisco is working to provide this functionality in other platforms such as the Catalyst 6500 series switches.

	NOTE You can use the Cisco Feature Navigator tool to find information about platform support. To access this tool, go to http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp.

	With Flexible NetFlow, you can configure a range of parameters for traffic analysis and data export on a networking device. For instance, you can define your own records by specifying the key and nonkey fields to customize the data collection to your specific requirements. In previous versions of NetFlow, a flow was based on a set of seven IP packet attributes: • Source IP • Destination IP • Source port • Destination port • Layer 3 Protocol • Type of Service (ToS) byte • Input interface Flexible NetFlow adds the ability to check other information, such as the number of bytes and packets in a flow. You can also create custom records for functions like quality of service (QoS), bandwidth monitoring, application and end user traffic profiling, and security monitoring. The main limitation is that, currently, Flexible NetFlow is not supported in the Cisco Catalyst 6500. In most cases, it is recommended that you enable NetFlow at the data center distribution switches. In large data centers, Cisco Catalyst 6500 switches are used as distribution switches. However, the benefits of NetFlow Versions 5 and 9 are still extremely valuable, because NetFlow is one of the most helpful tools for identifying and classifying security threats. In addition, you can use network monitoring tools such as the Cisco Security Monitoring, Analysis, and Response System (CS-MARS) to analyze NetFlow and other telemetry data from many different network devices.



	302 Chapter 10: Data Center Security

	Cisco Guard The Cisco Detector and Cisco Guard provide anomaly detection and attack mitigation features. You can place them in large data centers to divert traffic directed at the target host for analysis and filtering, so that legitimate transactions can still be processed while illegitimate traffic is dropped. On the other hand, in most cases small, medium, and large enterprises place their Cisco Guard at their Internet edge or subscribe to managed services provided by service providers.

	NOTE The managed service solution is called Clean Pipes. Cisco has detailed information about the Clean Pipes solution at http://www.cisco.com/en/US/netsol/ns615/ networking_solutions_sub_solution.html.

	Data Center Infrastructure Protection The infrastructure protection best practices that you learned in Chapter 2, "Preparation Phase," also apply in the data center. For example, you should harden control protocols as a basic security precaution on all applicable devices in the data center. In addition, you should disable unnecessary services on infrastructure components and implement device protection mechanisms, such as infrastructure access control lists (iACLs) and Control Plane Policing (CoPP). These device protection mechanisms will help you greatly in case of worm outbreaks, DDoS, or even in case of an anomaly other than a security threat (that is, a misconfigured application).

	TIP Remember to implement basic best-practice recommendations such as hardening device authentication, hardening Simple Network Management Protocol (SNMP), using Network Time Protocol (NTP), and all others that you learned in Chapter 2.

	You can also develop configuration templates for data center access switch ports where servers reside. Basic Layer 2 security mechanisms, such as limits on the number of MAC addresses that the server can originate on a port, can be included in the configuration template. You can also disable the Cisco Discovery Protocol (CDP) when it is not needed; be careful, however, because certain applications use CDP for legitimate transactions. Example 10-2 shows a basic template. Example 10-2 Data Center Access Switch Port Template interface GigabitEthernet2/4 no ip address switchport switchport access vlan 100



	Data Center Segmentation and Tiered Access Control 303

	Example 10-2 Data Center Access Switch Port Template (Continued) switchport mode access spanning-tree portfast switchport port-security maximum 2 switchport port-security violation shutdown spanning-tree bpduguard enable no cdp enable

	The highlighted commands in Example 10-2 enable port security and BPDU guard and disable CDP.

	NOTE An important point about port security is that it does not interoperate well with virtual servers because they may carry multiple MAC addresses of virtual hosts. You should also be careful when implementing port security with certain server failover mechanisms. In some environments, servers with multiple network interface cards (NIC) may share the same MAC address between interfaces when a failover occurs.

	For antispoofing protection, you can also enable Unicast Reverse Path Forwarding (Unicast RPF) in routers, security appliances such as the Cisco ASA, or in the Cisco FWSM. In the data center, it is most common to deploy Unicast RPF on the firewalls (Cisco ASA or FWSM). With Unicast RPF, if traffic enters the outside or untrusted interface from an address that is known to the routing table, but it resides on the inside interface, the firewall drops the packet. Similarly, if traffic enters the inside interface from an unknown source address, the firewall drops the packet to prevent spoofed attacks. You can enable Unicast RPF on the Cisco ASA, Cisco PIX, or Cisco FWSM with the ip verify reverse-path command, as shown in the following example: FWSM(config)#ip verify reverse-path interface outside FWSM(config)#ip verify reverse-path interface inside In the previous example, Unicast RPF is enabled in the outside and inside interfaces. Because firewalls require traffic path symmetry, in most cases, Unicast RPF can provide great benefits without impacting traffic flow. Data Center Segmentation and Tiered Access Control By isolating different types of servers and services, you can use segmentation and tiered access control in your data center to provide a multilayered architecture while adding security. The easiest way to segment your data center is to configure different Layer 2 domains or VLANs. In addition, you can use firewalls for policy enforcement between each



	304 Chapter 10: Data Center Security

	segment. By using private VLANs, you can also use segmentation that is local to the VLAN. This helps in preventing a compromised or infected server from affecting adjacent systems. In a multitier architecture, you separate systems based on the different functions they handle. For example, you can separate the presentation, business logic, and database layers, as illustrated in Figure 10-4.

	Figure 10-4 Multitier Server Segmentation Example



	In Figure 10-4, a web server farm is separated from the application and the database servers. This is done to protect the application and the database in case the web servers are compromised. You can also segment the data center by separating other types of application servers and devices. It is a best practice to separate all your management servers. For example,



	Data Center Segmentation and Tiered Access Control 305

	your management segment can include your TACACS+, RADIUS, SNMP, and any configuration management servers such as CiscoWorks, Cisco Security Manager, CS-MARS, and others. Figure 10-5 shows how management servers can also be separated from the rest of the data center.

	Figure 10-5 Management Servers Segmented



	As previously mentioned, you can segment your data center simply by configuring separate VLANs; however, this does not truly provide a complete solution that allows you to enforce your security policies between each boundary. Therefore, you can configure firewalls to provide additional security while allowing the necessary traffic to pass between segments.



	306 Chapter 10: Data Center Security

	NOTE You can also segment your data center by configuring Virtual Routing and Forwarding (VRF) interfaces with Multiprotocol Label Switching (MPLS) or by using VRF-Lite. This is more suitable for large environments and requires your staff to be familiar with more advanced routing features such as MPLS. The next section explains how to achieve segmentation using separate VLANs and the Cisco FWSM for policy enforcement and additional protection.

	Segmenting the Data Center with the Cisco FWSM In this section, you will learn how to take advantage of some of the Cisco FWSM features to segment your data center. It covers the modes of operation of the FWSM, design considerations, and configuration steps.

	Cisco FWSM Modes of Operation and Design Considerations You can use the Cisco FWSM not only to segment your data center, but also to enforce policy and to provide additional security benefits such as stateful and deep packet inspection. You can configure the Cisco FWSM in two different modes: • Routed mode: The default behavior. The Cisco FWSM in routed mode acts as a Layer 3 device supporting features such as Network Address Translation (NAT) and routing protocols. In most cases, when a Cisco FWSM is deployed in routed mode in the data center, it becomes the default gateway for a majority of the servers. • Transparent mode: The Cisco FWSM acts as a Layer 2 device. One of the major benefits of transparent mode is that you do not have to worry about readdressing your infrastructure when deploying a new firewall within your data center, because the firewall acts as a bridge between the external and internal network. On the other hand, when you are operating in transparent mode, the FWSM does not support features such as NAT routing protocols and some specific inspections engines that depend on NAT.

	NOTE Routed and transparent modes are also supported in the Cisco ASA and the Cisco PIX security appliances. In smaller environments, you can deploy the Cisco ASA at the data center. The configuration is identical except that the Cisco FWSM runs in the Catalyst 6500 series switches or in the Cisco 7600 series routers; therefore, specific configuration steps are needed in the switch or the router. This subject is covered later in this section.

	Figure 10-6 shows a Cisco FWSM configured in transparent mode.



	Data Center Segmentation and Tiered Access Control 307

	Figure 10-6 Cisco FWSM in Transparent Mode



	(Outside) Vlan 100 10.10.10.0/24



	In Figure 10-6, the Cisco FWSM outside interface resides on VLAN 100, and the inside interface resides on VLAN 101. Both interfaces belong to the same network subnet (10.10.10.0/24). The Cisco FWSM must have a management IP address configured for traffic to pass through it when configured in transparent mode. In this example, the management IP address is 10.10.10.123. You can take advantage of the virtualization capabilities of the Cisco FWSM to segment your data center. You can partition the Cisco FWSM into multiple virtual firewalls, known as security contexts. Each of these virtual firewalls has its own configuration enforcing separate security policies to each segment in the data center.



308 Chapter 10: Data Center Security

NOTE When you have multiple virtual security contexts configured, it is similar to having multiple standalone firewalls. Many features are supported when you configure the Cisco FWSM with multiple contexts, including routing tables, firewall features, and management. However, certain features are not supported, including dynamic routing protocols. The Cisco ASA and Cisco PIX security appliances also support virtual firewalls. Their behavior is similar to the Cisco FWSM.

Figure 10-7 illustrates the four modes of operations of the Cisco FWSM: • Single context routed mode • Single context transparent mode • Multiple context routed mode • Multiple context transparent mode Figure 10-7 Cisco FWSM Modes of Operation FWSM



Single Mode		Multicontext Mode

Routed	Transparent	Routed	Transparent

Figure 10-8 shows a Cisco FWSM configured with three different contexts. Each context includes its own configuration to protect each data center segment.



Data Center Segmentation and Tiered Access Control 309

Figure 10-8 Cisco FWSM Contexts

Outside Interface VLAN 40



Web Servers Context Webservers VLAN 10	Application Servers Context APPservers VLAN 20	Database Servers Context DBservers VLAN 30

In Figure 10-8, the Cisco FWSM contexts separate the web servers, applications servers, and database servers. The following are the context names:

Webservers APPservers

• DBservers The inside interface of context Webservers resides in VLAN 10. The inside interface of context APPservers is in VLAN 20, and the context DBserver inside interface is in VLAN 30.

Configuring the Cisco Catalyst Switch In the Cisco Catalyst switch, you must create the necessary VLANs and assign those to the Cisco FWSM. Example 10-3 shows the commands used to create VLANs 10, 20, 30, and 40 in the Cisco Catalyst 6500 switch.

310 Chapter 10: Data Center Security

Example 10-3 Creating the VLANs in the Switch


	vlan	10
	name !	webservers
	vlan	20
	name !	appservers
	vlan	30
	name _!	dbservers
	vlan	40
	name	tocorpnetwork

Each VLAN entry is configured with a descriptive name based on the data center segment. You then have to assign the VLANs to the Cisco FWSM. Example 10-4 shows how you can create firewall VLAN groups and then assign the group to the Cisco FWSM.

Example 10-4 Assigning the VLANs to the Cisco FWSM

firewall multiple-vlan-interfaces firewall module 2 vlan-group 1 firewall vlan-group 1 10,20,30,40

In Example 10-4, a VLAN group with ID of 1 is configured. This VLAN group includes VLANs 10, 20, 30, and 40 and is applied to the Cisco FWSM with the firewall module 2 vlan-group 1 command. The number 2 indicates that the Cisco FWSM resides on the second slot in the Cisco Catalyst 6500 switch.

TIP For security reasons, by default, only one switch virtual interface (SVI) can exist between

the switch and the Cisco FWSM. You might also choose to use multiple SVIs in routed mode so that you do not have to share a single VLAN for the outside interface. You can use the firewall multiple-vlan-interfaces command to allow you to add more than one SVI to the Cisco FWSM. In this example, the outside interfaces of each context reside on

VLAN 40.

Creating Security Contexts in the Cisco FWSM

When you configure the Cisco FWSM in multiple context modes, you add and manage all security contexts in the system space or system configuration mode. By default, a context named admin is created. The admin context is just like any other context, except that when a user logs into the admin context, that user has system administrator rights and can access the system and all other contexts. The admin context is not restricted in any



	Data Center Segmentation and Tiered Access Control 311

	way and can be used as a regular context. However, because logging into the admin context grants you administrator privileges over all contexts, you might need to restrict access to the admin context for appropriate users.

	TIP The admin context configuration must reside on flash memory and not on a remote system. If your system is already in multiple context mode, or if you convert from single mode, the admin context is created automatically as a file on the internal flash memory called "admin.cfg." This context is named "admin." If you do not want to use admin.cfg as the admin context, you can change the admin context.

	Because the default mode in the Cisco FWSM is single routed mode, to start creating security context, you need to change the FWSM to multiple mode. You can use the mode multiple command from configuration mode to enable multiple mode, as shown here: FWSM(config)# mode multiple

	NOTE After you enter the mode multiple command, you are prompted to reboot the Cisco FWSM.

	Example 10-5 shows the context configuration on the Cisco FWSM that was pictured in the previous example. Example 10-5 Creating the Security Contexts context webservers description Webserver segment allocate-interface vlan40 int1 allocate-interface vlan10 int2 config-url disk:/webservers.cfg _! context appservers description Application server segment allocate-interface vlan50 int1 allocate-interface vlan20 int2 config-url disk:/appservers.cfg _! context dbservers description Database servers segment allocate-interface vlan60 int1 allocate-interface vlan30 int2 config-url disk:/dbservers.cfg



312 Chapter 10: Data Center Security

The contexts webservers, appservers, and dbservers are defined in Example 10-5. Each security context or virtual firewall has two interfaces. In this example, the configuration of each security context is stored locally and not on an external server. After the contexts have been created, you can change to any of them by using the changeto context command, as shown here: FWSM(config)# changeto context webservers FWSM/webservers(config)# Notice that the prompt changes with the hostname followed by the context name you are currently configuring.

Configuring the Interfaces on Each Security Context The interface identifiers on each security context that were previously created were int1 for the outside interface and int 2 for the inside interface. Figure 10-9 shows the IP address configuration of the interfaces on each security context (virtual firewall).

Figure 10-9 IP Address Configuration on Each Virtual Firewall MSFC



Outside Interface 10.10.10.1 VLAN 40	Outside Interface 10.10.10.2 VLAN 50	Outside Interface 10.10.10.3 VLAN 60



Inside Interface 192.168.10.1 VLAN 10 Context Webservers	Inside Interface 192.168.20.1 VLAN 20 Context APPservers	Inside Interface 192.168.30.1 VLAN 30 Context DBservers



	Data Center Segmentation and Tiered Access Control 313

	Example 10-6 shows the configuration of the interfaces on the Webservers security context. Example 10-6 webservers Security Context IP Address Configuration interface int1 nameif outside security-level 0 ip address 10.10.10.1 255.255.255.0 _! interface int2 nameif inside security-level 100 ip address 192.168.10.1 255.255.255.0 Example 10-7 shows the configuration of the interfaces on the APPservers security context. Example 10-7 appservers Security Context IP Address Configuration interface int1 nameif outside security-level 0 ip address 10.10.10.2 255.255.255.0 _! interface int2 nameif inside security-level 100 ip address 192.168.20.1 255.255.255.0 Example 10-8 shows the configuration of the interfaces on the DBservers security context. Example 10-8 dbservers Security Context IP Address Configuration interface int1 nameif outside security-level 0 ip address 10.10.10.3 255.255.255.0 _! interface int2 nameif inside security-level 100 ip address 192.168.30.1 255.255.255.0

	Configuring Network Address Translation The goal is to configure static NAT for each server residing on each security context. Three systems reside in the web server segment (context webservers). This is illustrated in Figure 10-10.

314 Chapter 10: Data Center Security

Figure 10-10 webserver IP Address Configuration


			Outside Interface
			10.10.10.1
			VLAN 40
			ESJi
	Context Webservers		Inside Interface 192.168.10.1 VLAN 10

Щ Щ Щ

Web-Server 1 Web-Server 2 Web-Server 3

192.168.10.51 192.168.10.52 192.168.10.53

Table 10-1 lists the physical IP addresses of each web server with the statically translated address.

Table 10-1 Web Servers NAT Mapping


Web Server Name	Translated IP Address	Physical IP Address
Web-Server 1	10.10.10.51	192.168.10.51
Web-Server 2	10.10.10.52	192.168.10.52
Web-Server 3	10.10.10.53	192.168.10.53

Example 10-9 shows the static NAT configuration for each server on the webservers security context.

Example 10-9 webservers Context NAT Configuration


static	(inside,outside)	10.10.10.51	192.168.10.51	netmask	255.255.255.255
static	(inside,outside)	10.10.10.52	192.168.10.52	netmask	255.255.255.255
static	(inside,outside)	10.10.10.53	192.168.10.53	netmask	255.255.255.255

Data Center Segmentation and Tiered Access Control 315

Two application servers are in the data center as illustrated in Figure 10-11. They are protected by the virtual firewall (context) called APPservers.

Figure 10-11 Application Servers IP Address Configuration


	1*		p
			Outside Interface
			10.10.10.2
			VLAN 40
			si
	Context APPservers		Inside Interface 192.168.20.1 VLAN 20

APP-Server 1 APP-Server 2

192.168.20.71 192.168.20.72

Table 10-2 lists the physical IP addresses of each application server along with the statically translated address.

Table 10-2 Application Servers NAT Mapping


Server Name	Translated IP Address	Physical IP Address
APP-Server 1	10.10.20.71	192.168.20.71
APP-Server 2	10.10.20.72	192.168.20.72

Example 10-10 shows the static NAT configuration for each server on the appservers security context.

Example 10-10 appservers Context NAT Configuration


static	(inside,outside)	10.10.20.71	192.168.20.71	netmask	255.255.255.255
static	(inside,outside)	10.10.20.72	192.168.20.72	netmask	255.255.255.255

316 Chapter 10: Data Center Security

The data center has two database servers, as illustrated in Figure 10-12. They are protected by the virtual firewall (context) called DBservers.

Figure 10-12 Database Servers IP Address Configuration


			Outside Interface
			10.10.10.3
			VLAN 40
			si
	Context DBservers		Inside Interface 192.168.30.1 VLAN 20

DB-Server 1 DB-Server 2

192.168.30.101 192.168.30.102

Table 10-3 lists the physical IP addresses of each application server along with the statically translated address.

Table 10-3 Database Servers NAT Mapping


Server Name	Translated IP Address	Physical IP Address
DB-Server 1	10.10.30.101	192.168.30.101
DB-Server 2	10.10.30.102	192.168.30.102

Example 10-11 shows the static NAT configuration for each server on the DBservers security context.

Example 10-11 dbservers Context NAT Configuration


static	(inside,outside)	10.10.30.101	192.168.30.101	netmask	255.255.255.255
static	(inside,outside)	10.10.30.102	192.168.30.102	netmask	255.255.255.255

Data Center Segmentation and Tiered Access Control 317

Controlling Access with ACLs

It is recommended that you configure ACLs on both interfaces of each security context for more granular security policy enforcement. You can tune the ACLs based on your security policies and application usage. The ACLs that are configured on each of the security contexts in this example only allow the necessary traffic for each server and application.

Table 10-4 lists the protocols and ports that need to be allowed on the webservers security context.

Table 10-4 Protocols and Ports Used by the webservers


Usage/Application	Protocol or Port	Allowed by ACL
HTTP	TCP 80	inbound-traffic
HTTPS	TCP 443	inbound-traffic
SSH¹/SCP²	TCP 22	inbound-traffic
Mgmt-App	TCP 890	inbound-traffic
App-X	TCP 987	outbound-traffic
DNS³	UDP⁴ 53	outbound-traffic
SYSLOG	UDP 514	outbound-traffic

1 SSH = Secure Shell

2 SCP = Secure Copy Protocol

3 DNS = Domain Name System

4 UDP = User Datagram Protocol

Users connect to the web servers via HTTP and HTTPS; therefore, this traffic is allowed on the outside interface in the webservers context. The web servers are Linux-based machines. The administrator transfers files over SCP and connects to the server command-line interface (CLI) via SSH. In addition, the administrator uses a custom management application to install software and patches on the systems (Mgmt-App). This traffic from the management network (10.10.100.0/24) needs to be allowed.

The web servers themselves need to access an application called App-X running on the servers in the APPservers context over TCP port 987. DNS resolution and SYSLOG must also be allowed to external servers. Example 10-12 shows the ACLs configured in the Webservers context allowing the previously mentioned ports and protocols.

Example 10-12 webservers Context ACL Configuration

access-list inbound-traffic remark INBOUND TRAFFIC TO WEBSERVERS access-list inbound-traffic extended permit tcp any host 10.10.10.51 eq www access-list inbound-traffic extended permit tcp any host 10.10.10.51 eq https

continues



	318 Chapter 10: Data Center Security

	Example 10-12 webservers Context ACL Configuration (Continued)

	access-list inbound-traffic 10.10.10.51 eq ssh access-list inbound-traffic 10.10.10.51 eq 890 access-list inbound-traffic access-list inbound-traffic access-list inbound-traffic 10.10.10.52 eq ssh access-list inbound-traffic 10.10.10.52 eq 890 access-list inbound-traffic access-list inbound-traffic access-list inbound-traffic 10.10.10.53 eq ssh access-list inbound-traffic 10.10.10.53 eq 890 access-group inbound-traffic access-list outbound-traffic access-list outbound-traffic 10.10.20.71 eq 987 access-list outbound-traffic 10.10.20.72 eq 987 access-list outbound-traffic 10.10.111.11 eq 53 access-list outbound-traffic 10.10.111.12 eq 53 access-list outbound-traffic 10.10.100.100 eq 514 access-list outbound-traffic 10.10.20.71 eq 987 access-list outbound-traffic 10.10.20.72 eq 987 access-list outbound-traffic 10.10.111.11 eq 53 access-list outbound-traffic 10.10.111.12 eq 53 access-list outbound-traffic 10.10.100.100 eq 514	extended permit tcp 10.10.100.0 255.255.255.0 host extended permit tcp 10.10.100.0 255.255.255.0 host extended permit tcp any host 10.10.10.52 eq www extended permit tcp any host 10.10.10.52 eq https extended permit tcp 10.10.100.0 255.255.255.0 host extended permit tcp 10.10.100.0 255.255.255.0 host extended permit tcp any host 10.10.10.53 eq www extended permit tcp any host 10.10.10.53 eq https extended permit tcp 10.10.100.0 255.255.255.0 host extended permit tcp 10.10.100.0 255.255.255.0 host in interface outside remark OUTBOUND TRAFFIC FROM WEBSERVERS extended permit tcp host 192.168.10.51 host extended permit tcp host 192.168.10.51 host extended permit udp host 192.168.10.51 host extended permit udp host 192.168.10.51 host extended permit udp host 192.168.10.51 host extended permit tcp host 192.168.10.52 host extended permit tcp host 192.168.10.52 host extended permit udp host 192.168.10.52 host extended permit udp host 192.168.10.52 host extended permit udp host 192.168.10.52 host

	access-list outbound-traffic extended permit tcp host 192.168.10.53 host 10.10.20.71 eq 987 access-list outbound-traffic extended permit tcp host 192.168.10.53 host 10.10.20.72 eq 987 access-list outbound-traffic extended permit udp host 192.168.10.53 host 10.10.111.11 eq 53 access-list outbound-traffic extended permit udp host 192.168.10.53 host 10.10.111.12 eq 53 access-list outbound-traffic extended permit udp host 192.168.10.53 host 10.10.100.100 eq 514 access-group outbound-traffic in interface inside

	In Example 10-12, ACLs are configured to allow the traffic specified in Table 10-4. The ACL named inbound-traffic is applied to the outside interface, and the ACL named

Data Center Segmentation and Tiered Access Control 319

outbound-traffic is applied to the inside interface. Notice that the web server IP addresses in the inbound-traffic ACL are the translated addresses. However, because the outbound-traffic ACL is applied to the inside interface, the physical IP addresses are used as the source. The web servers must access two DNS servers. The primary DNS server is 10.10.111.11, and the secondary is 10.10.111.12. The IP address of the SYSLOG server is

10.10.100.100.

Table 10-5 lists the necessary protocols and ports that need to be allowed on the appservers security context.

Table 10-5 Protocols and Ports Used by the appservers


Usage/Application	Protocol and/or port	Allowed by ACL
App-X	TCP 987	inbound-traffic
SSH/SCP	TCP 22	inbound-traffic
Mgmt-App	TCP 890	inbound-traffic
MySQL	TCP 3306	outbound-traffic
DNS	UDP 53	outbound-traffic
SYSLOG	UDP 514	outbound-traffic

The web servers communicate with the application (App-X) running on the servers in the APPservers context over TCP port 987. Similar to the web servers, the administrator transfers files over SCP and connects to the server CLI via SSH. In addition, the administrator uses a custom management application to install software and patches on the systems (Mgmt-App). This management traffic from the management network (10.10.100.0/24) needs to be allowed. The application servers connect to the database servers running MySQL over TCP port 3306. DNS resolution and SYSLOG must also be allowed to external servers.

Example 10-13 shows the ACLs configured in the appservers context allowing the ports and protocols listed in Table 10-6.

Example 10-13 appservers Context ACL Configuration

access-list inbound-traffic remark INBOUND TRAFFIC TO APPSERVERS


access-list eq 987	inbound-traffic	extended	permit	tcp	host	10.10.10.51	host	10.10.20.71
access-list eq 987	inbound-traffic	extended	permit	tcp	host	10.10.10.52	host	10.10.20.71
access-list eq 987	inbound-traffic	extended	permit	tcp	host	10.10.10.53	host	10.10.20.71
access-list eq 987	inbound-traffic	extended	permit	tcp	host	10.10.10.51	host	10.10.20.72
access-list eq 987	inbound-traffic	extended	permit	tcp	host	10.10.10.52	host	10.10.20.72
access-list eq 987	inbound-traffic	extended	permit	tcp	host	10.10.10.53	host	10.10.20.72

continues

320 Chapter 10: Data Center Security

Example 10-13 appservers Context ACL Configuration (Continued)

access-list inbound-traffic extended permit tcp 10.10.100.0 255.255.255.0 host

10.10.20.71 eq 22

access-list inbound-traffic extended permit tcp 10.10.100.0 255.255.255.0 host

10.10.20.72 eq 22

access-list inbound-traffic extended permit tcp 10.10.100.0 255.255.255.0 host

10.10.20.71 eq 890

access-list inbound-traffic extended permit tcp 10.10.100.0 255.255.255.0 host

10.10.20.72 eq 890

access-group inbound-traffic in interface outside _!

access-list outbound-traffic remark OUTBOUND TRAFFIC FROM APPSERVERS access-list outbound-traffic extended permit tcp host 192.168.20.71 host

10.10.30.101 eq 3306 access-list outbound-traffic extended permit tcp host 192.168.20.72 host

10.10.30.101 eq 3306

access-list outbound-traffic extended permit tcp host 192.168.20.71 host

10.10.30.102 eq 3306

access-list outbound-traffic extended permit tcp host 192.168.20.72 host

10.10.30.102 eq 3306 access-list outbound-traffic extended permit udp host 192.168.20.71 host

10.10.111.11 eq 53

access-list outbound-traffic extended permit udp host 192.168.20.72 host

10.10.111.11 eq 53

access-list outbound-traffic extended permit udp host 192.168.20.71 host

10.10.111.12 eq 53

access-list outbound-traffic extended permit udp host 192.168.20.72 host 10.10.111.12 eq 53

access-list outbound-traffic extended permit tcp host 192.168.20.71 host

10.10.100.100 eq 514 access-list outbound-traffic extended permit tcp host 192.168.20.72 host

10.10.100.100 eq 514 access-group outbound-traffic in interface inside

In Example 10-13, ACLs are configured to allow the traffic specified in Table 10-5. The ACL named inbound-traffic is applied to the outside interface, and the ACL named outbound-traffic is applied to the inside interface.

Table 10-6 lists the necessary protocols and ports that need to be allowed on the DBservers security context.

Table 10-6 Protocols and Ports Used by the dbservers


Usage/Application	Protocol and/or port	Allowed by ACL
MySQL	TCP 3306	inbound-traffic
SSH)/SCP	TCP 22	inbound-traffic
Mgmt-App	TCP 890	inbound-traffic
DNS	UDP 53	outbound-traffic
SYSLOG	UDP 514	outbound-traffic

Data Center Segmentation and Tiered Access Control 321

The application servers communicate with the MySQL database running on the servers in the DBservers context over TCP port 3306. Linux-based servers also exist, and the administrator transfers files over SCP and connects to the server CLI via SSH. As with the other servers, the administrator uses the custom management application to install software and patches on the systems (Mgmt-App). This management traffic from the management network (10.10.100.0/24) needs to be allowed. DNS resolution and SYSLOG must also be allowed to external servers.

Example 10-14 shows the ACLs configured in the APPservers context allowing the ports and protocols listed in Table 10-6.

Example 10-14 dbservers Context ACL Configuration

I access-list inbound-traffic remark INBOUND TRAFFIC TO DATABASE SERVERS


access-list eq 3306	inbound-traffic	extended	permit	tcp	host	10.10.20.71	host	10.10.30.101
access-list eq 3306	inbound-traffic	extended	permit	tcp	host	10.10.20.72	host	10.10.30.101
access-list eq 3306	inbound-traffic	extended	permit	tcp	host	10.10.20.71	host	10.10.30.102
access-list	inbound-traffic	extended	permit	tcp	host	10.10.20.72	host	10.10.30.102

eq 3306

access-list inbound-traffic extended permit tcp

10.10.30.101 eq 22 access-list inbound-traffic extended permit tcp

10.10.30.102 eq 22 access-list inbound-traffic extended permit tcp

10.10.30.101

eq 890

access-list inbound-traffic extended permit tcp

10.10.100.0 255.255.255.0 host

10.10.30.102

eq 890

access-group inbound-traffic _!

access-list outbound-traffic access-list outbound-traffic

10.10.111.11 eq 53 access-list outbound-traffic

10.10.111.12 eq 53 access-list outbound-traffic

10.10.100.100 eq 514 access-list outbound-traffic

in interface outside

remark OUTBOUND TRAFFIC FROM DATABASE SERVERS

extended permit udp host 192.168.30.101 host

extended permit udp host 192.168.30.102 host

extended permit udp host 192.168.30.101 host

extended permit udp host 192.168.30.102 host

extended permit tcp host 192.168.30.101 host

extended permit tcp host 192.168.30.102 host

10.10.100.100 eq 514 access-group outbound-traffic in interface inside

In Example 10-14, ACLs are configured to allow the traffic specified in Table 10-6. The ACL named inbound-traffic is applied to the outside interface, and the ACL named outbound-traffic is applied to the inside interface.



	322 Chapter 10: Data Center Security

	Virtual Fragment Reassembly The Cisco FWSM, Cisco ASA, and Cisco PIX security appliances drop fragments. However, many different applications generate fragments. If you enable fragment forwarding, you open yourself to fragment attacks (like the ones defined in RFC 1858). You can use the Virtual Fragment Reassembly feature to protect against this type of attack. You enable Virtual Fragment Reassembly with the fragment command. In the following example, the Cisco FWSM is limiting its fragment buffer size to 200 packets on its outside and inside interfaces. fragment size 200 outside fragment size 200 inside

	TIP By using the chain and timeout options in the fragment command, you can also define the maximum number of fragments to be chained together and the length of time the Cisco FWSM waits for the fragments to arrive before discarding them.

	Deploying Network Intrusion Detection and Prevention Systems You can use network IDS/IPS appliances in small-to-medium organizations or the Cisco IDSM-2 for the Cisco Catalyst 6500 series switches in larger organizations. The implementation of each solution depends on the size of your data center and its requirements. When designing a network IDS/IPS solution for the data center, for both scalability and manageability, you should reduce the amount of traffic that is sent to the sensor. You should also avoid sending duplicate frames to the IDS/IPS sensors or modules. At the same time, you should avoid the situation in which you must change existing ACLs or VACLs before being able to implement an IDS/IPS solution. In most cases, you want to create several SPAN sessions to be able to send the traffic to multiple IDS/IPS devices. This section includes several best practices to use when you deploy an IDS/IPS solution in your data center.

	Sending Selective Traffic to the IDS/IPS Devices Depending on the size of your data center, you may use one or more IPS/IDS devices. In large data centers, you can use several IDSMs to monitor the activity within your server farms. Figure 10-13 illustrates a data center with three different IDSMs installed on each Cisco Catalyst 6500 along with the Cisco FWSM.

Deploying Network Intrusion Detection and Prevention Systems 323


Г	т rf	ft
	Web/Front-End Servers	Application Servers	те Database Servers

In some cases, exposing IPS/IDS sensors to all the traffic that flows within a data center can oversubscribe the IPS/IDS devices. To avoid performance problems in the data center, some administrators prefer to use only IDS features (promiscuous inspection) instead of inline IPS services. Others prefer to limit the number of protocols or the type of traffic to which a sensor is assigned. For example, in the high-level data center topology illustrated in Figure 10-13, you can selectively send traffic from each data center segment to specific IDSMs. For instance, you may want to send all web-related traffic on the webservers segment to the first IDSM. Similarly, you may want to send all traffic that traverses the application server segment to the second IDSM, and traffic destined and originated by the database servers to the third IDSM. This is illustrated in Figure 10-14.



324 Chapter 10: Data Center Security

Figure 10-14 Sending Selective Traffic to the IDS/IPS Devices


	ii

Web/Front-End Servers	Application Servers	Database Servers

Based on VLAN information, you can use a SPAN session to differentiate traffic on multiple ports. This is supported on the Cisco Catalyst 6500 starting from Cisco IOS Versions 12.2(18)SXD and 12.1(24)E. You can configure a single SPAN session to capture traffic from the three VLANs and send traffic from each VLAN to a specific IDSM or external sensor. With this configuration, the IDS/IPS devices can inspect client-to-server traffic, locally switched traffic, and server-to-server routed traffic. Alternatively, you can use VACL capture. You do this by simply configuring three VACLs with the forward capture action and assigning them to the three different segments. You assign IDSM-A to the web servers segment, IDSM-B to the application servers segment, and IDSM-C to the database segment. In certain trunk environments, the use of VACLs achieves half the goal of this design. The IDSMs may still experience substantial noise traffic. In addition to this, you have to modify the security VACLs that might already be in place in the data center to include the capture action for the traffic that you want to monitor. To address this problem, you can use RSPAN and VACL redirect together. You can configure RSPAN to create a copy of the traffic from all the ports connecting the Catalyst 6500 to the core and to the server farms. All these frames are locally copied onto an RSPAN VLAN which is a special VLAN that is equally visible to three IDSMs. Then you configure VACL redirection. This does not permit or deny the traffic, it simply redirects the traffic to the desired IDSM. One VACL entry specifies that



	Deploying the Cisco Security Agent (CSA) in the Data Center 325

	traffic to the web servers on the RSPAN VLAN be redirected to IDSM-1; another VACL entry specifies that traffic destined to the application servers on the RSPAN VLAN be redirected to IDSM-2; the same applies for the database server traffic to IDSM-3.

	NOTE You can find a detailed white paper on how to use RSPAN with VACLs for granular traffic analysis at http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/prodlit/rspan_wp.pdf.

	Monitoring and Tuning Monitoring tools such as CS-MARS help not only to identify and detect security threads, but also to reduce steps in the tuning process. Tuning is the process of managing and minimizing the number of false positives and false negatives that the network IDS/IPS device reports. As you learned in previous chapters, a false positive is a benign network activity mistakenly identified as malicious by the sensor. A false negative is malicious network activity mistakenly identified as benign or not detected by the sensor. To tune sensors, you enable, disable, or modify the signatures used in the network. The tuning process is one of the most crucial operational tasks that you perform when increasing the security of your data center. In Chapter 3, "Identifying and Classifying Security Threats," you learned best practices to use when deploying IDS/IPS devices. These same best practices apply in the data center.

	Deploying the Cisco Security Agent (CSA) in the Data Center CSA provides several security features that are more robust than a traditional antivirus or a personal firewall. CSA not only protects against viruses, worms, and direct attacks, but it also protects against day-zero threats. CSA plays an important role in data center security.

	CSA Architecture In the CSA solution architecture, a central management center maintains a database of policies and information about the workstations and servers on which the CSA software is installed. Agents register with the Cisco Security Agent Management Center (CSA-MC). Subsequently, the CSA-MC checks its configuration database and deploys a configured policy for that particular system.

	NOTE	Starting with CSA Version 5.1, the CSA-MC is a standalone system. Prior to Version 5.1, CSA-MC was part of the Cisco Works VPN and Security Management System (VMS).



	326 Chapter 10: Data Center Security

	The CSA software constantly monitors all activity on the end host and polls to the CSA-MC at configurable intervals for policy updates. The agent sends events and alerts to the global event manager of the CS-AMC. The global event manager inspects the event logs and then alerts the administrator or triggers the agent to take action based on the specific alert.

	NOTE All the communication between the agents and the CSA-MC is via Secure Socket Layer (SSL). The administrator also connects to the CSA-MC via SSL to manage and monitor the agents.

	Configuring Agent Kits As previously mentioned, CSA-MC comes with preconfigured agent kits that can be used to fulfill initial security needs. However, CSA-MC allows you to create custom agent kits to fit your specific requirements. For example, you can create different agent kits for the various servers within your data center. To create a new agent kit, complete the following steps: Step 1 Choose Systems > Agent Kits from the CSA-MC console. Step 2 Click New at the bottom of the page displayed. A dialog box appears asking you to specify the operating system on which the agent kit will be applied. Step 3 Enter a name and description for the new agent kit. For example, you can create agent kits for the web servers, application, and database servers in the examples in the previous sections. Step 4 Select the groups that will be associated with this agent kit. You can select from predefined groups designed for different type of servers. Step 5 Optionally, you can select to reboot the system after the CSA installation is complete. You can also select a quiet install to avoid end-user interaction. Step 6 Click Make Kit to create the new agent kit. Step 7 Click Generate Rules to generate all pending rules. A new window appears with information about the rule generation. After you have made the appropriate selections, click Generate. Step 8 All rules and configuration changes are applied at this point. A summary window appears if the rule generation completes successfully. Phased Deployment When you start your CSA deployment, select the initial hosts on which CSA will be installed based on the following guidelines: • Select at least one host per each distinct application or server environment. • During the pilot, make the test host a mirror sample of the production systems.

Chapter 9: IP Telephony Security

admin — Sat, 06 Mar 2010 10:03:08 +0000



	Summary 327

	• When installing CSA on servers, use a test machine for each server type to ensure that there is no negative impact from the CSA agent software installation. • Create a group for each type of application environment to be protected. Building and tuning of CSA policies is a continuous task. You need to have the proper staff and procedures to minimize the administrative burden. The security staff is responsible not only for maintaining the CSAMC policies, but also for creating and organizing appropriate exception rules and for monitoring user activity. You can organize the exception rules as follows: • Create a global exception policy to allow legitimate traffic and application behavior that is required on all the systems within the organization. Subsequently, add these global exception rules to this exception policy. • Create one exception policy for each group. • Apply these policies to their respective groups and collect all necessary data to complete any additional tuning. The following summarizes the steps that your security staff should use when deploying the agent kits throughout the organization: Step 1 Deploy the CSA agents in test mode throughout your organization. Step 2 Collect and analyze results. Subsequently, start policy tuning (as needed). Step 3 Enable protection mode. Step 4 Make sure that your security, operations, and engineering staff members are comfortable with the support of your deployment.

	Summary In most cases, data centers are equipped with surveillance cameras, biometric locks, authorization-based access policies, strict security personnel, and other physical security options. However, data centers that use such precautions, and are therefore prepared for physical intrusions, often do not deploy the necessary technologies and tools to combat cyberattacks. A good balance between physical and network security is crucial. This chapter covered several best practices to use when deploying Defense-in-Depth strategies to secure the data center. It discussed several tools and mechanisms to help you protect the data center against DoS, worms, and other security outbreaks. You learned several tips for segmenting your data center in a multilayered architecture. This chapter also covered some tips for deploying network IDS/IPS solutions and CSA in the data center.	Cisco alone has sold more than 4.5 million IP phones and 3 million Cisco Unity unified messaging licenses. The company has more than 20,000 IP Communications customers. IP telephony or Voice over IP (VoIP) deployments are growing dramatically on a daily basis. Consequently, the need to secure IP telephony networks is also growing by the minute. IP telephony security threats generally fall into one of two categories. The first category includes risks that are aimed to hijack listening or unauthorized listening to voice conversations (phone tapping). The second category includes risks that can compromise IP telephony communications with direct attacks to the network infrastructure, servers, and other systems, such as denial of service (DoS) attacks. This chapter covers several best practices and strategies for building your infrastructure to successfully identify threats and react to them in a manner that is appropriate to each severity level. It shows how integrated security features must be implemented from end to end across all network elements to increase voice security. IP telephony security has four major elements: • Network infrastructure: Routers, switches, firewalls, and other infrastructure components • Call processing systems: Call management, control, and accounting • Endpoints: IP phones, IP communicator software, video terminals, and so on • Applications: Unified messaging software, conferencing applications, contact, and a custom tool This chapter offers you different techniques to protect each element. IP telephony security requires the collaboration of security, network intelligence, and other services to minimize the impact of attacks and risks. With the collaboration of security technologies and network services, you can deploy Defense-in-Depth security that encompasses the entire network, including voice systems.



	262 Chapter 9: IP Telephony Security

	Protecting the IP Telephony Infrastructure The first step in IP telephony security is to make sure that you apply the best practices learned in previous chapters to protect the infrastructure as a whole. As previously mentioned, all the infrastructure components are networking devices deployed within your organization, such as: • Routers • Switches • Firewalls • Voice gateways • Gatekeepers Figure 9-1 illustrates a common IP telephony deployment in a medium-to-large enterprise. In Figure 9-1, several infrastructure components are depicted within a headquarters main office topology, which demonstrates a layered approach. Within the main office segment of the figure, notice the different access, distribution, and core layers. A group of application servers, a Cisco Unified CallManager cluster, and Cisco Unity servers are deployed to provide different VoIP services to the organization. Within the illustrated topology, IP telephony endpoints include both regular IP phones and wireless phones, as well as IP conferencing systems. A voice gateway is deployed to connect to the public switched telephone network (PSTN). In this figure, voice services are also provided to branch offices, telecommuters, and remote access users. Although Figure 9-1 provides a high-level topology, it represents a highly available, fault-tolerant infrastructure that is based on common infrastructure guidelines. A well-designed infrastructure is essential for easier deployment of IP telephony and its integration with applications such as video streaming and video conferencing. As you learned in previous chapters, resiliency and high availability are crucial for security. As a best practice when designing your network infrastructure, always think about high availability, connectivity options for phones (such as in-line power), and quality of service (QoS) mechanisms. Make sure that you understand the call patterns for your organization.

	TIP You can obtain VoIP provisioning recommendations and best practices listed in the whitepaper at http://www.cisco.com/en/US/products/sw/voicesw/ps556/ products_implementation_design_guide_chapter09186a008063743a.html.



	Protecting the IP Telephony Infrastructure 263



	264 Chapter 9: IP Telephony Security

	Figure 9-2 illustrates a typical regional site, branch office, or small enterprise deployment. Figure 9-2 Branch or Small Enterprise IP Telephony Deployment



	In Figure 9-2, a Cisco IOS Software router running Cisco Unified Communications Manager Express is deployed. The Cisco Unified Communications Manager Express (formerly known as the Cisco CallManager Express) is an optional software feature that enables Cisco routers to deliver Key System or Hybrid PBX functionality for branch offices or small businesses. Also deployed is Cisco Unity Express, which is a Linux-based application that runs on Cisco IOS Software routers, using either Network Module (NM) or Advanced Integration Module (AIM) hardware to provide basic automated attendant and voice mail features.



	Protecting the IP Telephony Infrastructure 265

	NOTE Best practices to secure Cisco Unified CallManager, Cisco Unified Communications Manager Express, Cisco Unity, and Unity Express are covered later in this chapter in the section "Securing the IP Telephony Applications."

	All the infrastructure security recommendations you learned in previous chapters (such as Chapter 2, "Preparation Phase") apply to IP telephony networks. It is, therefore, important that you follow those guidelines. For example, disable unnecessary services, implement infrastructure access control lists (ACL), and protect the control plane. This section shows you several other best practices and outline recommendations that are applicable strictly to voice implementations. You should take a layered approach when securing your IP telephony infrastructure. Build security layer upon layer starting at the ports that your workstations and IP phones connect (access layer), and work your way to the distribution, core, and data center. Figure 9-3 illustrates the different layers within an enterprise network. The following layers are illustrated in Figure 9-3: 1 Access layer: Access switches provide connectivity to user workstations and IP phones. The access layer can also include wireless access points with wireless handsets or workstations with voice software. 2 Distribution layer: This is the segment of the network where LAN-based routers and Layer 3 switches reside. These devices ensure that packets are properly routed between subnets and VLANs in your enterprise. 3 Core: The core typically consists of two or more high-end Layer 3 switches or routers that glue the network together as a whole. 4 Data center distribution layer: The distribution layer at the data center typically includes firewall or other security components (that is, intrusion detection systems [IDS] or intrusion prevention systems [IPS]). In Figure 9-3, two Catalyst 6500 switches with Firewall Services Modules (FWSM) are depicted. 5 Data center access layer: This layer includes access switches to which all the servers are connected. Figure 9-3 shows applications, Cisco Unified CallManager, and Cisco Unity servers connected to access switches at the data center.



	266 Chapter 9: IP Telephony Security

	Figure 9-3 Layered Approach to Securing IP Telephony Infrastructures

	Applications 4 Data Center Distribution Layer
			3 Core



	Access Layer The first recommendation, and one of the most important, is that you enable two VLANs at the access layer—one VLAN for data traffic and another VLAN for voice traffic.



	Protecting the IP Telephony Infrastructure 267

	The voice VLAN in the Catalyst Switches that are running Catalyst Operating System (CatOS) is also known as an Auxiliary VLAN. Figure 9-4 illustrates this recommendation. Figure 9-4 Access Layer and VLAN Assignment

	3750-1		Distribution Switches
	3750-1		3750-2
	Voice VLAN 10		Voice VLAN 11
	Data VLAN 100		Data VLAN 101

	In Figure 9-4, several IP phones are connected to two Cisco Catalyst 3750 switches. User workstations are then connected to the IP phones. The voice VLAN in the 3750-1 switch is VLAN 10, and the data VLAN is VLAN 100. Similarly, the voice VLAN in the 3750-2 switch is VLAN 11, and the data VLAN is VLAN 101.

	TIP When deploying access switches for voice networks, it is recommended that you use switches capable of running the following features: • Inline power or Power over Ethernet (PoE) • Multiple queue support • 802.1p and 802.1Q • Fast link convergence

	The separation of voice and data VLANs is recommended for many reasons. One of the major reasons is for address space conservation as well as for voice device protection from external networks. It is strongly recommended that voice endpoints be addressed using



	268 Chapter 9: IP Telephony Security

	RFC 1918 private subnet addresses. By separating voice and data VLANs, you can also implement QoS trust boundary configurations that are strictly for voice devices. In addition, the use of separate voice and data VLANs can help you dramatically when responding to security incidents. This is why previous chapters stressed the importance of good addressing schemes. For example, if you are responding to a security incident such as a worm or a DoS attack, you can easily identify what addresses represent IP phones and what addresses represent user workstations. Subsequently, you can use VLAN access tagging control mechanisms such as VLAN access control lists (VACL), 802.1Q, and 802.1p to provide protection for voice devices from malicious traffic. Last, but not least, are the ease of management and configuration benefits (that is, simplified QoS configuration schemes). Another recommendation is that you enable root guard or the PortFast bridge protocol data unit (BPDU) guard feature on all access switches. This rules out the possibility of someone introducing a rogue switch that might attempt to become the Spanning Tree root. You can enable PortFast BPDU guard on a global basis on Cisco switches running CatOS, as shown in the following example. Console> (enable) set spantree portfast bpdu-guard enable The next example shows how to enable PortFast BPDU guard on Cisco switches running Cisco IOS Software. myswitch(config)# spanning-tree portfast bpduguard When a switch running BPDU guard disables one of its ports, it remains disabled until it is manually enabled. On the other hand, you can configure a port to re-enable itself automatically from the "errdisable" state on CatOS-enabled switches, as shown in the following example. Console> (enable) set errdisable-timeout interval 450 Console> (enable) set errdisable-timeout enable bpdu-guard The timeout interval in this example is set to 450 seconds. The default timeout interval is 300 seconds and, by default, the timeout feature is disabled. The following example shows how to configure the automatic re-enabling of a disabled port on a switch running Cisco IOS Software. myswitch(config)# errdisable recovery cause bpduguard myswitch(config)# errdisable recovery interval 450 You can also enable port security or dynamic port security to protect against MAC flooding attacks. For instance, if you have an IP phone attached to a switch port and then a workstation connected directly to the IP phone, it is recommended that you limit the number of learned MAC addresses to two: one for the IP phone and one for the workstation behind the phone. Limit the learned MAC addresses to one in case you have only an IP phone connected to the switch port. This configuration is typically used in lobbies, common areas, and conference rooms. Protecting against MAC flooding attacks is important in publicly accessed areas of your organization such as lobbies because you do



	Protecting the IP Telephony Infrastructure 269

	not want outsiders to be able to plug in laptops to an IP phone or disconnect the IP phone and plug in a laptop. Example 9-1 shows how to configure an access port with dynamic port security for a port on which an IP phone resides and a user workstation is plugged into the data port on the phone. Example 9-1 Dynamic Port-Security

	myswitch#configure terminal myswitch(config)#interface GigabitEthernet1/12 myswitch(configif)# switchport access vlan 100 myswitch(configif)# switchport mode access myswitch(configif)# switchport voice vlan 10 myswitch(configif)# switchport port-security myswitch(configif)# switchport port-security maximum 3 myswitch(configif)# switchport port-security violation restrict myswitch(configif)# switchport port-security aging time 2 myswitch(configif)# switchport port-security aging type inactivity

	In the previous example, port security is enabled on the interface GigabitEthernet1/12. Notice the way the VLAN assignment is configured. The voice VLAN is VLAN 10, and the data VLAN is VLAN 100. Port security is configured to restrict learning to a maximum of three MAC addresses—one for the phone itself, another for the integrated PC port on the phone, and the third for a PC connected on the phone.

	TIP The switchport port-security violation restrict command enables the switch to learn up to the maximum number of MAC addresses and then stop learning any new MAC addresses. The default setting is to disable the port. If you keep the default setting and the maximum number of MAC addresses is exceeded, the port becomes disabled, and the phone loses power (in case of inline power). In addition, the recommended port security aging time is 2 minutes.

	It is also recommended that you enable the DHCP snooping feature to prevent rogue DHCP server attacks and DHCP starvation attacks. Attackers can use different tools to create a DHCP starvation attack (the most common is called Gobbler) by making numerous DHCP requests until you run out of IP addresses. Subsequently, legitimate workstations cannot receive an IP address from your DHCP server successfully. You can enable DHCP snooping globally or on a per-interface basis. The following example shows how to configure DHCP snooping globally on a switch running Cisco IOS Software. An IP phone is connected to the switch, and a user workstation is plugged into the data port on the phone. myswitch(config)#ip dhcp snooping vlan 10, 100 myswitch(config)#ip dhcp snooping



	270 Chapter 9: IP Telephony Security

	In the previous example, DHCP snooping is enabled on VLAN 10 (voice VLAN) and VLAN 100 (data VLAN). The following example shows how DHCP snooping is enabled on a specific port/interface. myswitch(config)#interface GigabitEthernet 1/48 myswitch(configif)#ip dhcp snooping limit rate 10 myswitch(configif)#ip dhcp snooping trust DHCP snooping is a DHCP security feature that provides network security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding database (also referred to as a DHCP snooping binding table). DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. You can use DHCP snooping to differentiate between untrusted interfaces connected to the end user and trusted interfaces connected to the DHCP server or another switch. For DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces. Another feature that you can enable to protect the access layer of your voice-enabled network is the Dynamic Address Resolution Protocol (ARP) Inspection (DAI). DAI is commonly used to prevent gratuitous ARP attacks. Workstations bind a MAC address to an IP address in an ARP cache. When the system sends out an ARP request, the device that owns the IP address in that request replies with its IP and MAC address information to the system that originated the request. On the other hand, gratuitous ARP is an unsolicited ARP reply, in which a system tells the rest of the Layer 2 adjacent systems that it owns a specific IP and MAC address. Networking devices commonly use this technique. For example, when the Cisco PIX or the Cisco Adaptive Security Appliances (ASA) fail over, it sends a gratuitous ARP to other devices on the network to advertise the assumed IP addresses. On the other hand, attackers can use gratuitous ARP to spoof the identity of another system. You can use DAI to inspect all ARP requests and replies (gratuitous and nongratuitous) to avoid these types of exploits on untrusted ports.

	NOTE You must enable DHCP snooping to use DAI.

	You can enable DAI globally and then on a per-interface basis. The following example shows how to configure DAI globally on a switch running Cisco IOS Software. myswitch#configure terminal myswitch(config)#ip arp inspection vlan 10,100 myswitch(config)#ip dhcp snooping database tftp://172.18.108.26/dai/dai_db In the previous example, DAI is enabled on VLANs 10 and 100. The switch is configured to save the DHCP snooping database on a TFTP server (172.18.108.26) under a directory



	Protecting the IP Telephony Infrastructure 271

	called dai and a file called dai_db. You can also enable DAI on a per-interface basis, as shown in the following example: myswitch(config)#interface GigabitEthernet 1/12 myswitch(configif)#ip arp inspection limit rate 15 In the previous example, the ip arp inspection command is configured with the limit rate option to specify the maximum number of ARP packets per second allowed on the GigabitEthernet 1/12 interface. The switch disables that port when it detects more than 15 ARP packets per second.

	NOTE If you do not want to disable the phone when the port receives more then 15 ARP messages in a second, you can set the rate limit to none which allows the phone to stay up.

	Many people are becoming more concerned with unauthorized network access, and potentially, even unauthorized placement of IP phones. More advanced features such as 802.1x and Network Admission Control (NAC) can also be implemented. In 802.1x environments in which user workstations are plugged in to the back of IP phones, the use of automatic port control on Cisco Catalyst switches is recommended. To enable 802.1x automatic port control on switches running Cisco IOS Software, use the dotlx port-control auto command. On switches running CatOS, use the set port dot1x port-control auto command. 802.1x and IP telephony are only supported with the use of Cisco IP phones. You must use multi-VLAN access ports (separate VLANs for voice and data) based on the configurations shown in the previous examples in this chapter. When you enable 802.1x on a switch port where a Cisco IP phone resides, authentication is done based only on Cisco Discovery Protocol (CDP). It is important to notice that no voice or data packets are allowed before CDP packets are processed. This varies on a per-platform basis. For instance, on a Catalyst 6500 running CatOS, packets other than Extensible Authentication Protocol over LAN (EAPOL) or CDP are dropped by the software at the in-band driver level. The voice VLAN Spanning Tree state is set to "forwarding," and the disabling of learning of other MAC addresses is done on the line cards by setting the appropriate bits in port header control registers. On the other hand, Cisco Catalyst 3750 switches put phones addresses in the TCAM after detecting CDP packets to allow voice traffic through. In addition, an ACL to catch all EAPOL packets is used. The hardware drops any other packets sent from unknown source addresses when they hit the catchall entry in the TCAM, triggering an address learning violation in the switch. In short, in 802.1x environments, CDP is absolutely necessary for IP phone operation; without it, an IP phone is unusable. In contrast, when you use the Cisco NAC Framework solution in Layer 2 IP (NAC-L2-IP), EAP over UDP (EoU) is used. EOU provides a different type of architecture and access control environment than 802.1x because EoU acts



	272 Chapter 9: IP Telephony Security

	at Layer 3, and 802.1x is strictly Layer 2. In NAC-L2-IP, the security posture check is triggered after an ARP packet is detected or by the use of DHCP snooping. Cisco switches support EoU in an IP telephony environment. In most cases, it is recommended that you use NAC-L2-IP. Based primarily on CDP, you can exempt Cisco IP phones from any EOU rules. An alternative to this approach includes a configured static exception or use of the Generic Authorization Message Exchange (GAME) protocol with an external audit server. It is recommended that you exempt IP phones from the NAC posture entirely. Example 9-2 demonstrates how to configure an exception policy for Cisco IP phones on a switch running Cisco IOS Software. Example 9-2 Exception Policy for Cisco IP Phones identity profile eapoudp device authorize type cisco ip phone policy allow-my-phones identity policy allow-my-phones access-group allow-my-phones ip access-list extended allow-my-phones permit ip any any

	In the previous example, an identity profile is configured for EoU, and the device authorize command is used to "authorize" or exempt all Cisco IP phones from NAC posture checks. This is done by using the CDP information from the Cisco IP phone. The identity policy named allow-my-phones is configured with an access list to catch all traffic.

	NOTE Refer to the Cisco Press book Network Admission Control Volume II for detailed NAC configuration examples and troubleshooting guides.

	You can configure Cisco IP phones to allow an administrator to get statistics and device information through a built-in web server that runs on each phone. Administrators can use this feature for debugging and to obtain the remote status of the phone. This built-in web server is also used to receive application information from the Cisco Unified CallManager. You can enable or disable web access globally or on each phone specifically. It is recommended that you control web access to the phones. If you completely disable web access, troubleshooting voice-related issues can be more difficult to solve. Alternatively, you can restrict access by configuring ACLs or VACLs only, allowing an administrative network or subnet in different parts of the network (in most cases, as close as possible to the phone).



	Protecting the IP Telephony Infrastructure 273

	NOTE As previously mentioned in this book, it is extremely important that you have a separate network segment or subnet dedicated to administrative access and applications.

	Distribution Layer At the distribution layer, you can apply enforcement mechanisms (such as ACLs) based on your security policies for the IP telephony-enabled network. For example, you can configure Layer 3 ACLs so that they do not allow traffic from the nonvoice VLANS to access the voice gateway and voice applications in the network. Typically, voice application servers (such as Cisco Unified CallManager and Cisco Unity) are protected by firewalls in the distribution layer of the data center. On the other hand, you can create ACL templates to strategically deploy within your distribution layer to restrict access from nonvoice VLANs. This method simplifies the ACLs at Layer 3 compared to the ACLs at Layer 2 or VLAN ACLs. Figure 9-5 shows the two access switches you saw in the previous examples, in which IP phones in the 192.168.10.0/24 and 192.168.11.0/24 networks reside (voice VLANs 10 and 11). The user workstations are in VLANs 100 (IP range 192.168.100.0/24) and 101 (IP range 192.168.101.0/24). The goal is to restrict access from nonvoice segments to the voice gateway (10.10.10.100) and to the CallManager cluster (172.18.124.0/24). You can use a simple ACL in your distribution switches, as demonstrated in Example 9-3. Example 9-3 ACL in Distribution Switch access-list 100 deny ip 192.168.100.0 0.0.0.255 host 10.10.10.100 access-list 100 deny ip 192.168.101.0 0.0.0.255 host 10.10.10.100 ! the lines above deny all nonvoice devices to send traffic to the voice ! gateway access-list 100 deny ip 192.168.100.0 0.0.0.255 172.18.124.0 0.0.0.255 access-list 100 deny ip 192.168.101.0 0.0.0.255 172.18.124.0 0.0.0.255 ! the access list entries above deny all nonvoice devices to send ! traffic to the Cisco Unified CallManager servers access-list 100 permit ip 192.168.100.0 0.0.0.255 any access-list 100 permit ip 192.168.101.0 0.0.0.255 any

	Depending on your security policy and your environment, you will allow or restrict access to additional services. Of course, in your data center, you will have more granular ACLs allowing or denying traffic based on your security policy. High availability is crucial in the distribution layer. Use the Hot Standby Router Protocol (HSRP) at the distribution layer to ensure high availability in the event of a failure.



	274 Chapter 9: IP Telephony Security

	Figure 9-5 Distribution Layer Access List

	Voice Gateway 10.10.10.100

	3750-1 ' "~~ ' 3750-2

	NOTE The following link contains numerous step-by-step examples of methods for configuring HSRP on Cisco Catalyst switches and Cisco IOS Software routers: http://www.cisco.com/en/US/partner/tech/tk648/tk362/tk321/ tsd_technology_support_sub-protocol_home.html

	Gateway Load Balancing Protocol (GLBP) is another redundancy mechanism. GLBP is now Stateful Switchover (SSO) aware. GLBP can detect when a router is failing over to the

Chapter 8: Wireless Security

admin — Wed, 03 Mar 2010 09:48:31 +0000



	Securing the IP Telephony Applications 275

	secondary Route Processor (RP) and continue in its current GLBP group state. Prior to being SSO aware, GLBP was not able to detect that a second RP was installed and configured to take over if the primary RP failed. When the primary failed, the GLBP device would stop participating in the GLBP group and, depending on its role, could trigger another router in the group to take over as the active router. With this enhancement, GLBP detects the failover to the secondary RP, and no change occurs to the GLBP group. If the secondary RP fails and the primary is still not available, the GLBP group detects this and re-elects a new active GLBP router. At the distribution layer, you can also enable NetFlow to gain complete visibility of what is happening in your network. As you learned in previous chapters, NetFlow brings unmatched telemetry features that allow you to maintain visibility of your network traffic. Core A number of books are required to fully cover how to design the core of your network. However, for the purpose of this chapter and this book, the most important thing you need to remember is the need for high availability and the ability to route/switch traffic as fast as possible with little need for traffic filtering in your core. You can use features such as Control Plane Policing (CoPP) to protect the control plane of your core routers. In addition, you should implement the routing protocol security best practices learned in previous chapters and all other Network Foundation Protection (NFP) strategies. Securing the IP Telephony Applications In this section, you learn how to protect IP telephony applications such as: • Cisco Unified CallManager • Cisco Unified Communications Manager Express • Cisco Unity • Cisco Unity Express • Cisco Personal Assistant Securing these applications starts with the development of a well-defined application security policy that describes all the processes required to ensure server and application security and assumes that you deployed the recommended network infrastructure best practices described earlier in this chapter. This policy not only includes design guidelines, but also operational practices, such as patch management, antivirus protection, and in-depth protection with the Cisco Security Agent (CSA). In the following sections, you learn best practices for increasing the security of the previously mentioned applications.	Wireless networks are becoming more and more popular. Not only can you take advantage of wireless networking at the office, home, a hotel, and coffee shops, but also at airports, train stations, and many other places. Wireless networks increase productivity. Your employees can save time by sending and receiving e-mail or accessing information on network servers from a conference room or any location within your organization that has wireless connectivity. You can also implement a voice over wireless LAN (WLAN) solution. With a WLAN, your employees can reach each other anywhere within your organization without having to rely on cellular coverage that can be spotty or nonexistent. Now the bad news: wireless networks are a major target for attackers. One of the biggest challenges today is to make sure that the appropriate tools and mechanisms are used to protect data in-transit across wireless networks. In addition, the wireless infrastructure needs to be protected against attacks targeted to the wireless networking devices. Stories abound of attackers gaining access to wireless networks not only to steal information but also to attack other networks. After reading this chapter, you will become familiar with some of the technologies, tools, and mechanisms that are typically used to protect your wireless network. You will also learn best practices to use when securing the Cisco Unified Wireless Architecture. The 802.11a, 802.11b, and 802.11g are the most widely deployed WLAN technologies today. Historically, 802.11 WLAN security includes the use of open or shared-key authentication and static wired equivalent privacy (WEP) keys. This combination offers a rudimentary level of access control and privacy but each element can be compromised. The low cost of wireless deployments makes them popular (that is, you do not have to worry about expensive cabling solutions and portability issues). However, inexpensive equipment also makes it easier for attackers to gain unauthorized access. Rogue access points and unauthorized, poorly secured networks compound the odds of a security breach. The best practices you learned in previous chapters play a crucial role when protecting the infrastructure, analyzing risks, and building the most appropriate operational security program for your organization. In this chapter, you will also learn the different authentication mechanisms in wireless networks. In addition, you will become familiar with advanced topics such as: • Wireless intrusion detection and prevention services (IDS/IPS)



	212 Chapter 8: Wireless Security

	• Precise location tracking • Network Admission Control (NAC) in wireless networks Overview of Cisco Unified Wireless Network Architecture The Cisco Unified Wireless Architecture is a multiservice solution designed for any type of organization. It can be deployed in your corporate offices, branches, retail stores, hospitals, manufacturing plants, warehouses, educational institutions, financial institutions, government agencies, and any other type of organization that needs wireless connectivity. Industry standards including the IEEE 802.11 and the draft IETF Control and Provisioning of Wireless Access Points (CAPWAP) are supported. Because the Cisco Unified Wireless Network is a multiservice solution, it supports data, voice, and video applications. Some examples of data applications are as follows: • E-mail • Internet access • Virtual private network (VPN) access • Inventory management applications • Asset tracking • Mobile healthcare applications You can also run Voice over IP (VoIP) over WLAN. The Cisco Unified Wireless Network Architecture also supports video, such as video surveillance applications, video streaming applications for e-learning, and others. The Cisco Unified Wireless solution provides interoperability with the Cisco Wireless IP Phones to provide comprehensive voice communications using Cisco Unified CallManager and Cisco Wi-Fi access points. The Cisco Compatible Extensions program gives third-party manufacturers the ability to design industry-standard and Cisco innovations into a wide variety of devices. Other advanced features such as wireless intrusion detection and prevention, precise location tracking, and Network Admission Control (NAC) are also supported. You can implement wireless networks in all sizes. For example, you can have merely a couple of wireless access points or wireless routers within your organization, as illustrated in Figure 8-1. In Figure 8-1, a wireless access point and a wireless router are accepting connections from end-user workstations, laptops, and wireless scanners. This approach is only appropriate for small environments. It is not feasible for medium and large organizations because it does not provide centralized management and ease of deployment. The Cisco Unified Wireless Network solution provides centralized management that allows you to easily deploy WLAN configurations with the same level of security, scalability, and reliability to all



	Overview of Cisco Unified Wireless Network Architecture 213

	wireless networking devices within your organization. Figure 8-2 illustrates the main components of the Cisco Unified Wireless Network. Figure 8-1 Basic Wireless Network



	214 Chapter 8: Wireless Security

	Figure 8-2 The Cisco Unified Wireless Network Architecture

	Mobile Clients



	Mobile Clients

	The following are the primary components of the Cisco Unified Wireless Network solution (as illustrated in Figure 8-2): • WLAN management: Centralized management enables configuration of the same level of security, scalability, and reliability features throughout your organization. You can use the CiscoWorks Wireless LAN Solution Engine (WLSE) or the CiscoWorks WLSE express. • Wireless LAN controllers: Provision of centralized intelligence for wireless access point management. • Access points: Devices to which mobile devices connect. • Mobile clients: End-user workstations, laptops, personal assistant (PDAs), and other wireless devices that ensure peak performance and interoperability. • Mobility services: Services such as voice over wireless LAN, wireless intrusion detection and prevention, precise location tracking (Cisco WLAN Location Appliance), and others.



	Overview of Cisco Unified Wireless Network Architecture 215

	NOTE For general information about the Cisco wireless devices, go to http://www.cisco.com/go/wireless.

	You can deploy wireless access points within your organization in two modes: unified mode (as illustrated in Figure 8-2) and autonomous mode. In autonomous mode, a WLSE network management appliance is deployed with autonomous access points. Some access points act as domain controllers (WDS) for sets of access points communicating over the wired network using the Wireless LAN Context Control Protocol (WLCCP). This is illustrated in Figure 8-3. Figure 8-3 Autonomous Wireless Access Points



	The main difference between the unified and autonomous modes is that in unified mode, access points operate with the Lightweight Access Point Protocol (LWAPP) and work in conjunction with Cisco wireless LAN controllers and the Cisco Wireless Control System (WCS). When configured with LWAPP, the access points can automatically detect



	216 Chapter 8: Wireless Security

	the best-available Cisco wireless LAN controller and download appropriate policies and configuration information with no manual intervention. Autonomous access points are based on Cisco IOS software and may optionally operate with the Cisco WLSE. Autonomous access points, along with the Cisco WLSE, deliver a core set of features and may be field-upgraded to take advantage of the full benefits of the Cisco Unified Wireless Network as requirements evolve. You can individually manage Cisco Aironet autonomous access points via the command-line interface (CLI), a web interface, the CiscoWorks WLSE, or CiscoWorks WLSE Express. On the other hand, Cisco recommends that you upgrade any existing Cisco Aironet access points operating autonomously to run LWAPP and operate them as lightweight access points to receive all the features, benefits, and mobility services of the Cisco Unified Wireless Network.

	NOTE Cisco provides free upgrade software for existing customers at http://tools.cisco.com/support/downloads/pub/MDFTree.x?butype=wireless.

	Authentication and Authorization of Wireless Users The 802.11 standard supports different types of authentication. The two most generic types are open and shared-key authentication. In most wireless networks, a service set ID (SSID) is specified to identify the wireless network. The basic mechanisms of 802.11 augment the identification by using SSIDs with authentication mechanisms that prevent the client from sending data to and receiving data from the access point unless the client has the correct shared key. One of the most basic wireless authentication protocols is the wired equivalent privacy (WEP) standard. The following section describes WEP in detail. WEP WEP, an optional encryption standard in 802.11 that most vendors support, is implemented in the MAC layer. WEP-enabled devices encrypt the payload of each 802.11 frame before transmission by using an RC4 stream cipher. The packets are then decrypted in the wireless access point. WEP encrypts only data between 802.11 stations. After the frame enters the wired side of the network, WEP no longer applies. During the encryption process, WEP arranges a key schedule (otherwise known as a seed) by concatenating the shared secret key supplied by the user of the sending station with a random-generated 24-bit initialization vector (IV). The IV lengthens the life of the secret key because the station can change the IV for each frame transmission. WEP inputs the resulting seed into a pseudorandom number generator that produces a key-stream equal to the length of the frame payload plus a 32-bit integrity check value (ICV), as illustrated in Figure 8-4.

Authentication and Authorization of Wireless Users 217

Figure 8-4 WEP Process

Initialization Vector (IV)

Shared Key-►

Seed


	WEP	Sequence
	PRNG

Encrypted Message

Plain Text Message

Integrity Algorithm

The following steps are illustrated in Figure 8-4:

1 The ICV is calculated using CRC-32 and concatenated to the plaintext message.

2 A random IV and the shared secret key are also concatenated producing the seed.

3 This seed is the input to the WEP Pseudorandom Number Generator (PRNG). WEP uses RC4 PRNG of RSA Data Security to produce a pseudorandom sequence.

4 The message is encrypted by using an XOR operation with the sequence generated in the previous step.

5 The encrypted message is sent to the other end.

The ICV is a check sum that the receiving station eventually recalculates and compares to the one sent by the sending station to determine whether the transmitted data underwent any form of tampering while in transient. If the receiving station calculates an ICV that does not match the one found in the frame, the receiving station can reject the frame or flag the user.

NOTE WEP shared secrets use 40-bit, 64-bit, or 128-bit keys.

WEP has some limitations and has undergone extensive examination and criticism over the past years. In short, WEP is vulnerable because of its relatively short IVs and keys that



	218 Chapter 8: Wireless Security

	remain static. For a large, busy network, this reoccurrence of IVs can happen within an hour or so. Because of this, you will have many frames or packets with similar key-streams. Technically, an attacker can gather frames based on the same IV to determine the shared values among the wireless devices. This information can be key-stream or the shared secret key. The static nature of the shared secret keys emphasizes this problem. In many cases, system administrators and users use the same keys for months or even years. This gives mischievous culprits plenty of time to monitor and attack the WEP-enabled networks. Now some vendors deploy dynamic key distribution solutions based on 802.1X, which definitely improves the security of wireless LANs. Many now recommend the use of IP security (IPsec) to ensure data confidentiality, integrity, and authenticity. The only caveat is that when you deploy IPsec in a WLAN environment, you need to install an IPsec software client on every machine that connects to the wireless network. WEP has several enhancements. The first one is the use of the Temporal Key Integrity Protocol (TKIP) .

	NOTE TKIP is often referred to as WEP Version 2.

	The second enhancement is the use of the Advanced Encryption Standard (AES) encryption protocol instead of RC4, which is used in older WEP implementations. The Wi-Fi Protected Access (WPA) standard uses TKIP to provide additional security features. WPA is discussed in the next section. WPA WPA (using TKIP) includes a per-packet keying (PPK) and message integrity check (MIC) and an extension of the initialization vector from 24 bits to 48 bits. WPA mitigates the WEP threat by implementing different keys on a per-packet basis. It does this by hashing the IV and WEP keys to produce a temporal key. This temporal key is then combined with the IV and fed to an XOR operation with the plaintext message. Today WPA combines TKIP and user authentication via IEEE 802.1x and the EAP (Extensible Authentication Protocol). This combination mitigates vulnerabilities from several angles and represents a significant security upgrade over WEP.



Authentication and Authorization of Wireless Users 219

NOTE The following site includes a whitepaper with detailed information about WEP, WPA, and other authentication mechanisms: http://www.cisco.com/en/US/netsol/ns340/ns394/ns348/ns386/ networking_solutions_white_paper09186a00800b469f.shtml

802.1x on Wireless Networks In Chapter 1, "Technology Overview," you learned the basics of the 802.1X. As a refresher, 802.1x is a standard that defines the encapsulation methodologies for the transport of the Extensible Authentication Protocol (EAP) protocol.

NOTE EAP was originally defined in RFC 2284, which is now obsolete due to RFC 3748.

The 802.1X standard allows you to enforce access control when wired and wireless devices attempt to access the network. Figure 8-5 illustrates the main components of 802.1x.

Figure 8-5 802.1x in Wireless Networks

Wireless Client with Supplicant	Authenticator		Authentication Server		Identity Store (Microsoft Active Directory, LDAP, ODBC, etc.)
Wireless Client with Supplicant	Authenticator
802.1x		RADIUS		Identity Store Integration

The following are the main components of 802.1x illustrated in Figure 8-5: • Supplicant: Software running on the client workstation • Authenticator: The wireless access point • Authentication Server: RADIUS server such as the Cisco Secure Access Control Server (ACS) • External Database: External database such as the Microsoft Active Directory, Lightweight Directory Access Protocol (LDAP), or any Open Database Connectivity (ODBC) repository.

NOTE	The Cisco comprehensive identity-based solution, which is based on 802.1x, is referred to as Identity Based Networking Services (IBNS).



220 Chapter 8: Wireless Security

The basic 802.1x authentication negotiation scheme is illustrated in Figure 8-6.

Figure 8-6 802.1x Authentication Negotiation Basics

Wirless Client with Supplicant		Authenticator			Authentication Server

1 2 3	EAP-Identity-Request			(EAP Method Dependent)
	EAP-Identity-Response		Auth Exchange with Auth Server Authentication Successful/Rejected			4
	EAP-Auth Exchange
EAP-Success/Failure

Policy Instructions

5

EAPOL-Logoff

802.1x					RADIUS

The following are the steps illustrated in Figure 8-6: 1 The client attempts to connect to the wireless network, and the wireless access point sends an EAP identity request to the client (supplicant). 2 The user enters his credentials, and the client machine sends the EAP identity reply to the wireless access point. 3 Depending on the EAP method, the client starts an authentication exchange to the authentication server. An EAP tunnel passes directly to the authentication server. 4 The authentication server accepts or rejects the user and sends further information/ instructions based on the authentication and authorization of the user. At the end of the session, the client sends an EAPOL Logout message. The different types of EAP methods are categorized as follows: • Challenge/response based • Cryptographic based • Tunneling methods • Generic token and one-time-passwords The challenge-response-based EAP methods are the following: • EAP with Message Digest 5: Uses MD5 hashing for authentication exchange • Cisco LEAP: Authentication based on usernames and passwords • EAP using the Microsoft Challenge Handshake Authentication Protocol Version 2 (MSCHAPv2)



Authentication and Authorization of Wireless Users 221

The cryptographic-based EAP method is as follows: • EAP over Transport Layer Security (EAP-TLS): Uses x.509 digital certificates and TLS for authentication The most common EAP tunneling methods are as follows: • Protected EAP (PEAP) • EAP Tunneling Transport Layer Security (EAP-TTLS) • EAP Flexible Authentication via Secure Tunneling (EAP-FAST): Designed not to require certificates The EAP Generic Token Card (EAP-GTC) is an EAP method used for generic token cards and one-time passwords.

NOTE EAP-GTC is defined in RFC 3748. It does not protect the authentication data in any way.

The following sections describe each EAP method.

EAP with MD5

When you configure EAP-MD5, both the client and the authentication server must have a shared secret established out-of-band. This shared secret is typically a password associated with an identity/username. Figure 8-7 illustrates the primary steps within the EAP-MD5 authentication method.

Figure 8-7 EAP-MD5 Wireless Client with Supplicant		Authenticator		Authentication Server

1 2	EAP-Identity-Request

EAP-Identity-Response (HASH)

EAP-Success/Failure		Auth Exchange with Auth Server Authentication Successful/Rejected			3

4		Allow or Deny	Policy Instructions

5	Access to the Network



	222 Chapter 8: Wireless Security

	The following are the steps illustrated in Figure 8-7: Step 1 A random challenge is sent to the supplicant from the wireless access point. Step 2 The client sends its response containing the hash of the challenge created using the shared secret. Step 3 The RADIUS authentication server verifies the hash and accepts or rejects the authentication. Step 4 The wireless access point allows or disallows access based on the RADIUS authentication server decision. Step 5 If the authentication is successful, the client gains access to the network. Because EAP-MD5 is purely an authentication protocol, it does not provide encryption after the authentication process. Therefore, all the messages are transmitted in cleartext after authentication. In addition, because it is only a client authentication protocol, the server side is not authenticated. Subsequently, you cannot detect rogue wireless access points if you implement EAP-MD5. The use of mutual authentication provides a means of reducing the risk of users installing rogue access points within the infrastructure, because mutual authentication also requires the client to authenticate the server and, most definitely, rogue devices will not do this. Another way you can try to protect against rogue access points is to lock down your switches so that you can use only authorized MAC addresses on your wired network. This is explained later in this chapter.

	TIP EAP-MD5 is vulnerable to dictionary and brute-force attacks when used with Ethernet and wireless.

	Cisco LEAP Cisco LEAP was initially developed to address the vulnerabilities that WEP showed. At that time, it was an alternative protocol that allowed you to deploy wireless networks without requiring a certificate infrastructure for clients by leveraging authentication mechanisms that were already available within the infrastructure. The following are some of the benefits presented by using Cisco LEAP: • 802.1x EAPOL messages are used within Cisco LEAP. • Server authentication is achievable. • The client username and password are sent over MS-CHAP. • RADIUS is used as the authentication server. • LEAP provides mechanisms for deriving and distributing encryption keys. Many people are now migrating from Cisco LEAP to full 802.1x implementations.



	Authentication and Authorization of Wireless Users 223

	EAP-TLS EAP-TLS provides several features. For example, it supports mutual authentication providing an encrypted transport layer and the capability to change the keys dynamically. EAP-TLS requires the use of digital certificates. You need to keep this in mind when thinking about deploying EAP-TLS within your network.

	NOTE EAP-TLS is defined in RFC 2246.

	During the TLS handshake phase, the client and wireless device establish a session exchanging symmetric session keys used to encrypt the transport during the data transfer phase. TLS has two layers: • Record layer: Includes information about fragmentation, MAC, and encryption • Message layer: Includes four different types of messages The following are the four message types: • Change cipher spec: This defines a change in the session context to be used by the record layer. • Alert message: There are approximately 26 different alert message subtypes. (They include access denied, close notify, decryption failed, and certificate revoked.) • Handshake protocol: During the handshake protocol, the client and the server exchange different hello messages; server authentication and key exchange messages; client authentication and key exchange messages; and the finalization message to close the session. • Application data: This is the actual data that is transmitted over the TLS tunnel. EAP-TLS does not use all parts of the TLS record protocol; however, it uses the TLS handshake for mutual authentication, for cipher suite negotiation, and for derivation of the session keys. EAP-TLS was initially designed for PPP connections; however, in wireless implementations, EAP-TLS is used as a strong and secure mechanism for mutual authentication and key establishment; then the native WEP mechanisms of the wireless device are used to encrypt the data. PEAP Many people refer to PEAP as the true EAP-TLS in wireless implementations. PEAP uses EAP-TLS functionality by securing the open exchanges, but it keeps things simple. For instance, PEAP requires only server-side certificates; however, it can still perform mutual authentication between the client and the server. It also uses TLS for the secure tunnel and



	224 Chapter 8: Wireless Security

	lengthens the EAP-TLS exchange beyond the finished message to add client authentication and key exchange. One of the disadvantages of PEAP is that it is considered to be a chatty protocol. The PEAP protocol has two phases: • Phase 1: Used to establish a secure tunnel using the EAP-TLS with server authentication • Phase 2: Authenticates the client based on EAP methods, exchange of arbitrary information, and other PEAP-specific means using the information established during Phase 1 Many people use PEAP because it is simple to implement within a wireless infrastructure. EAP Tunneled TLS Authentication Protocol (EAP-TTLS) EAP-TTLS is basically the same as EAP-TLS; however, it extends the client authentication by the use of a method called tunneled authentication. With EAP-TTLS, the client does not need a digital certificate (only the authentication server requires one), thereby simplifying the client identity management.

	NOTE EAP-TTLS enables you to also use legacy authentication methods such as password-based methodologies.

	EAP-FAST EAP-FAST was initially known as the Tunneled EAP (TEAP) and as LEAP Version 2. EAP-FAST is classified by many as the most comprehensive and secure EAP type suitable for wireless implementations. It addresses the risks of man-in-the-middle and dictionary attacks. In addition, EAP-FAST reduces the hardware requirements, making it a flexible deployment model and more attractive to many people. EAP-FAST authentication does not require the use of a specific encryption type. Instead, the WLAN encryption type to be used is determined by the client wireless network interface card capabilities. If the client devices do not support WPA2 or WPA, you can deploy 802.1X authentication with dynamic WEP keys, but, because of the well-known exploits against WEP keys, this WLAN encryption mechanism is not recommended. If you must support WEP-only clients, it is recommended that you employ a session-timeout interval which requires that the clients derive a new WEP key on a frequent interval.



	Authentication and Authorization of Wireless Users 225

	TIP 30 minutes is the recommended session interval for typical WLAN data rates.

	Cisco has a comprehensive list of frequently asked questions about EAP-FAST at http://www.cisco.com/en/US/products/hw/wireless/ps4555/ products_qanda_item09186a00802030dc.shtml.

	EAP-GTC

	EAP-GTC enables you to use hardware token cards as one-time-passwords. An example of a hardware token card is the RSA SecurID solution.

	NOTE For more information about RSA SecurID, go to http://rsa.com.

	You can use EAP-GTC inside the TLS tunnel created by PEAP. You can use this EAP method to implement a two-factor authentication solution to avoid common password compromises and combine it with your remote access VPN solution. For instance, a user can use the token card for both wireless and remote access VPN authentication. If you are just starting to deploy a WLAN, you must decide whether token deployment is cost effective. Many people justify the cost of token deployment by using this authentication mechanism with other network infrastructure authentication, such as remote access VPN. In summary, the two EAP methods that most people implement today are EAP-FAST and PEAP. EAP-FAST provides more flexibility when deployed with 802.1x or NAC. EAP-FAST is easy to implement, and it is not Cisco proprietary. It supports Windows single-sign-on and provides support for login script operation with any user database such as Microsoft Active Directory, Lightweight Directory Access Protocol (LDAP), and one-time password (OTP). In addition, because EAP-FAST does not require certificates, you can configure it easily and distribute it for Cisco Aironet client devices with the Cisco Aironet Configuration Administration tool.

	TIP	It is recommended that you employ either WPA2 (AES-CCM) or WPA (TKIP) encryption, which are both dependent on the NIC card capabilities in the specific deployment.



226 Chapter 8: Wireless Security

Configuring 802.1x with EAP-FAST in the Cisco Unified Wireless Solution This section describes how to configure the wireless LAN context (WLC), the Cisco Secure Services Client (CSSC), and Cisco Secure Access Control Server (ACS) to perform 802.1x authentication using EAP-FAST. Figure 8-8 illustrates the topology used in this configuration example.

Figure 8-8 Configuring 802.1x with EAP-FAST on the Cisco Unified Wireless Solution

			LWAPP Tunnel	Wireless LAN Controller Management IP 172.18.85.96 AP Manager 172.18.85.97
		*LWAPPP* :#: OOOOOO	LWAPP Tunnel
		*LWAPPP* :#: OOOOOO	Controll Messages Data Encapsulation

Workstation with CSSC	Wireless Access Point 172.18.85.123

Cisco Secure ACS 172.18.85.181

Figure 8-8 shows a workstation with the CSSC connecting to a Cisco wireless access point (with IP address 172.18.85.123) in a lightweight configuration controlled by a WLC. The management IP address of the WLC is 172.18.85.96, and the AP manager IP address is 172.18.85.97. The WLC forwards all authentication requests to a Cisco Secure ACS.

Configuring the WLC Complete the following steps to configure the WLC to use the Cisco Secure ACS server for authentication. Cisco Secure ACS validates the user credentials using the Windows database. (The Cisco Secure ACS server configuration is covered in the next section.) Step 1 Log in to the WLC as an administrator and click the Security tab; then click New to add a new RADIUS server, as illustrated in Figure 8-9. You will then see the screen shown in Figure 8-10.



	Authentication and Authorization of Wireless Users 227

	Figure 8-9 Adding a RADIUS Server to the WLC



	Figure 8-10 RADIUS Server Configuration on the WLC

228 Chapter 8: Wireless Security

Step 2 In the screen shown in Figure 8-10, enter the RADIUS server information. In this case, the Cisco Secure ACS IP address is 172.18.85.181. Enter a shared key to mutually authenticate the WLC and the RADIUS server. In this example, the default RADIUS port UDP/ 1812 is used. Ports UDP/1645 (legacy) and UDP/1812 are supported by Cisco Secure ACS for RADIUS authentication. Leave all other options with the default values and click Apply.

Step 3 By default, the WLC uses 802.1x for the security policies in WLANs.

You can also combine 802.1x with static WEP, WPA, and others. In this example, 802.1x is used without WEP/WPA. To enable this configuration, navigate to the WLANs tab and edit the configured WLAN. (In this example, the WLAN SSID is named ciscotest.) Under Security Policies and Layer 2 Security, select 802.1x from the dropdown menu, as shown in Figure 8-11.

Figure 8-11 WLAN Layer 2 Security Policy


ft Cisco - Windows Internet Explorer
^jiwf т https:,il72,13	35 Screens/frameset html		Certificate Error			U -
4 & Cisco		n	: a • a # • й	^age - Tools
	MONITOR WLANs CONTROLLER WIRELESS SECURITY		Save Z: j.. "a; MANAGEMENT COMMANDS HELP		out Refresh
WLANs	WLANS > Edit		<	Back	Apply
WLANs	WLAN ID
WLANs AP Groups VLAN	Profile Name	ciscotest
	WLAN SSID	ciscotest
	General Policies		Security Policies
	Radio Policy	All v	IPv6 Enable	□
	Admin Status	3 Enabled				=
		3 Enabled	Layer 2 Security	802. IX	■	=
	Session Timeout (sees) Quality of Service (QoS)	1SQ0 Silver [best effort) v	Layer 2 Security	None WPA1+WPA2
	WMM Policy 7320 Phone Support Broadcast SSID	Disabled v □ Client CAC Limit □ АР CAC Limit 3 Enabled	Layer 3 Security	Static WEP Cyrils Static-ЛЕР + S02.1X CT-
	Aironet IE	3 Enabled
	Allow AAA Override Client Exclusion DHCP Server DHCP Addr. Assignment Interface Name MFP Version Required MFP Signature Generation H-REAP Local Switching	□ Enabled 3 Enabled ** \|б0 Timeout Value (sees) □ Override □ Required \| management v z	* Web Policy cannot be IPsec.	used in cc-mbin	tion will
			** When client exclusion is enabled_r a t value of zero means infinity [will require administrative override to reset enclud *" CKIP is not supported by lOrat APs		rneout d clients)

Step 4 Scroll down on the same screen and choose the configured Cisco Secure ACS server on the drop-down menu under the RADIUS Servers section, as shown in Figure 8-12. Click Apply.



	Authentication and Authorization of Wireless Users 229

	Figure 8-12 Selecting the Configured RADIUS Server



	The next section shows you how to configure the Cisco Secure ACS server.

	Configuring the Cisco Secure ACS Server for 802.1x and EAP-FAST Complete the following steps to configure the Cisco Secure ACS server for 802.1x authentication using the EAP-FAST method. You first add the WLC as AAA client on the Cisco Secure ACS server. To add the WLC as a AAA client on Cisco Secure ACS, click the Network Configuration radio button. You can create a network device group to maintain a collection of AAA clients and AAA servers, or you can use the default Not Assigned network device group. In this example, the WLC is added to the Not Assigned default group. Click the Not Assigned group. Step 1 Click Add Entry. The screen shown in Figure 8-13 is displayed. Step 2 Complete the form by entering the hostname and IP address of the WLC. (WLC is the hostname, and 172.18.85.96 is the management IP address of the WLC in this example.)



	230 Chapter 8: Wireless Security

	Figure 8-13 Adding an AAA Client into Cisco Secure ACS \^^^Tj< - \|B http;/J172.18.S5.1Sl;£283/index£.htm



	Step 3 Step 4 Step 5 Step 6	Enter the shared secret to be used between the Cisco Secure ACS server and the WLC. (In this example, the key is 1qaz@WSX.) Choose RADIUS (Cisco Airspace) under the drop-down menu in the Authenticate Using section.
	Step 3 Step 4 Step 5 Step 6	Click Submit + Apply. In this example, the Cisco Secure ACS server queries an external

	Windows 2003 server for authentication credentials. Navigate through the radio button sequence as follows. Click External User Databases > Database Configuration > Windows Database > Configure. Step 7 Under the Windows EAP Settings, check the Enable password change inside PEAP or EAP-FAST checkbox, as illustrated in Figure 8-14. Step 8 Click Submit. Step 9 Navigate to External User Databases > Unknown User Policy and click the Check the following external user databases radio button. Step 10 Click the Windows Database from External Databases to Selected Databases, as shown in Figure 8-15. Step 11 Click Submit.



	Authentication and Authorization of Wireless Users 231

	Figure 8-14 Windows EAP Settings



	Figure 8-15 Selecting the Windows Database on the Unknown User Policy



	232 Chapter 8: Wireless Security

	Step 12 Next, you have to enable EAP-FAST support on the Cisco Secure ACS Server. To do this, navigate via the radio buttons to System Configuration > Global Authentication Setup > EAP-FAST Configuration. The screen in Figure 8-16 is displayed. Figure 8-16 Enabling EAP-FAST on Cisco Secure ACS



	Step 13 Check Allow EAP-FAST. Step 14 In this example, the recommended (default) values for Active master key TTL (1 month), Retired master key TTL (3 months), and Tunnel PAC TTL (1 week) are selected. Step 15 The Authority ID Info text is shown on some EAP-FAST client software; in this case, cisco is the text configured and displayed. This can be anything you want. On the other hand, the CSSC (used in this scenario) does not display this descriptive text for the PAC authority. However, the word cisco will be displayed if any other client (802.1x supplicant) is used. Step 16 Check the Allow anonymous in-band PAC provisioning checkbox. This enables Automatic PAC Provisioning for EAP-FAST-enabled clients. Step 17 The CSSC supports EAP-FAST Version 1a, which uses MS-CHAPv2 for authentication. Scroll down and check EAP-MSCHAPv2 under the Allowed inner methods section, as shown in Figure 8-17.



	Authentication and Authorization of Wireless Users 233

	Figure 8-17 EAP-MSCHAPv2 and EAP-FAST Master Server Configuration



	Step 18 Check the EAP-FAST master server check box to configure this Cisco Secure ACS server as the master. The Actual EAP-FAST Master server status line will say Master. Any other Cisco Secure ACS servers (if present in your organization) will use this server as the master PAC authority to avoid the need to provision unique keys for each Cisco Secure ACS in a network. Step 19 Click Submit + Restart.

	Configuring the CSSC This section shows how to configure the CSSC to authenticate to the wireless network using EAP-FAST. Complete the following steps to configure the CSSC. Step 1 Launch the CSSC and click Create Network. Step 2 The Network Profile screen shown in Figure 8-18 is displayed. Under Network Configuration Summary and Authentication, click Modify.



	234 Chapter 8: Wireless Security

	Figure 8-18 CSSC Network Profile Screen



	Step 3 The Network Authentication screen shown in Figure 8-19 is displayed. Turn on authentication by clicking the radio button labeled Turn On under the Authentication Methods section, as illustrated in Figure 8-19. In this example, the Use Username as Identity button is selected, because the user credentials are being used for authentication. Step 4 Under the Protocol list, check FAST and click the Configure button. Step 5 The Configure EAP Method screen shown in Figure 8-20 is displayed. Under the Tunneled Method, you can choose Any Method to allow the CSSC to use any EAP method offered by the wireless infrastructure. In this example, the EAP-MSCHAPv2 method is selected, because we are doing external authentication to a Windows Active Directory user database. If, however, you choose the Any Method option, it will work, but in some cases, you may want to be selective to force the use of only one EAP method. (In this case, the method is EAP-MSCHAPv2.) Step 6 Leave all other default values as they are, and click OK. Step 7 Click OK in the Network Authentication screen.

Authentication and Authorization of Wireless Users 235

Figure 8-19 CSSC Network Authentication Screen

Figure 8-20 CSSC Configure EAP Method Screen

Configure EAP Method..

-FAST settings:-

I I Use Client Certificate

Use Smartcard-based Client Certificates Only fyl Validate Server Certificate 0 Allow Fast Session Resumption

Tunneled Method


	EAP-MSCHAPv2	■1
	Any Method \|
	EAP-MSCHAPv2 ;

	EAP-TLS	1

Help

Step 8 Only wireless networks that have SSIDs enabled for broadcast are visible within the CSSC. In this example, the WLC is configured not to broadcast the SSID. Consequently, you must manually define the SSID in the CSSC. To define the SSID in CSSC, click the Add button under the Access Devices section of the Network Profile screen. The SSID used previously is ciscotest.

Step 9 Click Add Access.



	236 Chapter 8: Wireless Security

	Step 10 Click OK. Step 11 The CSSC attempts to connect to your wireless network. If it does not automatically make this attempt, click Connect from the CSSC main screen. Step 12 You are prompted for your user credentials, and if successfully authenticated, you are granted access to the network. Lightweight Access Point Protocol (LWAPP) In the Cisco Unified Wireless Architecture, a wireless LAN controller (WLC) is used to manage the wireless access point configuration and firmware creating an LWAPP tunnel. LWAP provides the control messaging protocol and data encapsulation. In other words, the wireless client data packets are encapsulated between the access point and the WLC. Figure 8-21 illustrates how a WLC controls a wireless access point over an LWAPP tunnel. Figure 8-21 LWAPP Tunnel



	The following steps are illustrated in Figure 8-21:

	1 The wireless client sends a packet to the wireless access point. 2 The wireless access point decrypts the packet and encapsulates it with an LWAPP header, forwarding it to the WLC. 3 The WLC removes the LWAPP header and forwards the packet to its destination in the corporate wired network.



	Lightweight Access Point Protocol (LWAPP) 237

	NOTE When a client on the corporate wired network sends replies to the wireless client, the packet first goes into the WLC where it is encapsulated with an LWAPP header and forwarded to the appropriate wireless access point. Subsequently, the access point removes the LWAPP header and encrypts the packet if necessary.

	The LWAPP control messages are encrypted using the AES-CCM encryption method. The shared encryption key is derived and exchanged when the access point joins the WLC.

	NOTE The payload of the encapsulated LWAPP data is not encrypted. Therefore, you should follow infrastructure protection best practices to protect the wired network.

	The following are the major steps or stages used in the LWAPP: Step 1 Discovery: The wireless access point looks for a controller. The LWAPP Discovery Response from the controller contains the following important information from the WLC: — Controller name (sysName) — Controller type — Controller capacity — Current wireless access point load in the WLC — Master controller status information used for redundancy — Access point manager IP address and the number of access points joined to the manager (a) When the AP is powered on, if a static IP address has not been previously configured, the AP issues a DHCP DISCOVER to get an IP address. (b) If Layer 2 mode is supported, the AP attempts a Layer 2 LWAPP Discovery by sending an Ethernet broadcast message. (c) If Layer 2 mode is not supported or the AP fails to find a WLC, the AP attempts a Layer 3 LWAPP Discovery. (d) If a Layer 3 LWAPP Discovery also fails, the AP reboots and retries the first step.



	238 Chapter 8: Wireless Security

	Step 2 Join: The wireless access point attempts to establish a secured relationship with a controller. Step 3 Image Data: The wireless access point downloads code from the WLC when needed. Step 4 Config: The wireless access point receives the configuration from the WLC. Step 5 Run: The wireless access point and the WLC are operating normally, and service data is exchanged. Step 6 Reset: The wireless access point clears the current state, and this process starts over again. The WLC provides support for radio resource management (RRM). The following are some of the advantages of RRM: • Continuous analysis of RF environment • Dynamic channel and power management • Coverage hole detection and correction • Coverage resiliency The WLCs elect a radio frequency (RF) group leader who analyzes RF data and neighbor relationships to make more optimized decisions about the RF environment for wireless infrastructure. Multiple RF domains can coexist within a single RF Group. These RF domains can be intercontroller or intracontroller, as illustrated in Figure 8-22.

	Figure 8-22 Multiple RF Domains



	Wireless Intrusion Prevention System Integration 239

	Why is this important to security? A good wireless network design that includes network resiliency is important for the overall security of your wireless network. The WLC has a built-in understanding of the signal strength that exists between lightweight access points within the same network. These controllers can use this information to create a dynamic optimal RF topology for the network. When a Cisco LWAPP-enabled access point boots up, it immediately looks for a wireless LAN controller within the network. After it finds a wireless LAN controller, the LWAPP-enabled access point sends out encrypted "neighbor" messages. These neighbor messages include the MAC address and signal strength of any neighboring access points. In a single wireless LAN controller network, the controller uses this neighbor information to determine the relative spatiality of the access points in the network. The controller then tunes each access point channel and optimal signal strength for optimal coverage and capacity. When wireless LAN controllers are clustered in the network, a default controller is chosen. All the controllers feed the default controller information to their registered access points. The default controller correlates information for all the access points in the network and then pushes out the optimal channel and power for every access point on the network. The algorithms built into the Cisco Unified Wireless Network architecture prevent the interruption of wireless connectivity. Wireless Intrusion Prevention System Integration You can integrate Cisco IPS sensors with the Cisco Unified Wireless Solution. This includes the Cisco IPS sensors, the Cisco Adaptive Security Appliance (ASA), Advanced Inspection and Prevention Security Services Module (AIP-SSM), the Catalyst 6500 Intrusion Detection/Prevention Services Module Version 2 (IDSM-2), and the IPS modules for Cisco IOS routers. When you integrate IPS with the Cisco Unified Wireless Solution, the WLC talks to the Cisco IPS sensor via its management port using the Security Device Event Exchange (SDEE) protocol over TCP port 443. The WLC supports up to five IPS sensors.

	NOTE The WLC also supports the use of a certain limited number of IPS signatures that you can enable to detect security threats within your wireless network. However, the combination of an external IPS device with the WLC provides more granular inspection and detection.

	The WLC Software Release Version 4.x and later supports shunning (blocking) from the IPS sensors. A shun request needs to be sent to the WLC from the Cisco IPS device to trigger the client blacklisting or exclusion behavior available on the controller. The WLC queries the Cisco IPS device at a configured query rate to retrieve all the shun events. This is illustrated in Figure 8-23.



	240 Chapter 8: Wireless Security

	Figure 8-23 IPS Sensor Integration



	Infected Client

	The following steps are illustrated in Figure 8-23: Step 1 An infected client sends malicious traffic over the wireless network (through access point 1 (AP1)). Step 2 The WLC sends the traffic to be inspected by the IPS device (IPS Sensor1). Step 3 The IPS device sends a shun request to the WLC to block the offending client. Step 4 The client is blocked (shunned).

	NOTE The shunned client status is maintained on each controller in the mobility group even if any or all of the controllers are reset. On the controller, clients are disabled based on a MAC address, even though the shun request that the IPS initiates uses the client IP address as its destination. Therefore, although a client remains disabled for the duration of the controller exclusion time and is re-excluded if it reacquires its previous DHCP address, that client is no longer disabled if the IP address of the client that is shunned changes Here is an example. The client connects to the same network, and the DHCP lease timeout has not expired.



	Wireless Intrusion Prevention System Integration 241

	Configuring IDS/IPS Sensors in the WLC You can configure IDS/IPS using the WLC web management console or through the CLI. This section demonstrates how to use the web management console to add IDS/IPS sensors. Step 1 Connect the Cisco IPS device to the same switch where the WLC resides. Step 2 Mirror the WLC ports that carry the wireless client traffic to the Cisco IPS device. You do this because the Cisco IPS device must receive a copy of every packet to be inspected on the wireless network. The Cisco IPS device provides a downloadable signature file that you can customize. When a signature is triggered, the Cisco IPS device generates the alarm with a shunning event action. The WLC polls the Cisco IPS device for alarms. When an alarm is detected with the IP address of a wireless client, which is associated to the WLC, the IPS device puts the client into the exclusion list. The WLC generates a trap and notifies the WCS. The WLC removes the user from the exclusion list after the specified period (60 seconds by default). Step 3 Log in to the WLC as an administrator. Step 4 To add the Cisco IPS device to the WLC, navigate to the Security tab. Under CIDS, click Sensors. Step 5 Click New. Step 6 The screen shown in Figure 8-24 is displayed. Enter the sensor IP address. The IP address of the IPS device in this example is 172.18.85.149. The WLC uses SDEE, and the default port is 443. Enter the username and password of the Cisco IPS device. In this example, the query interval is configured for 15 seconds. This query interval is safe to use in most environments. Enter the Cisco IPS device SHA1 fingerprint. You can obtain this by invoking the show tls fingerprint command on the Cisco IPS device, as follows: Example 81 IPS-sensor# show tls fingerprint MD5: B8:A7:74:B5:62:AB:C8:15:5C:FE:E6:4C:0C:42:39:CE SHA1: AC:6A:FA:FC:BE:05:D1:09:31:53:21:DC:36:A0:1A:B6:6A:DA:00:AF The highlighted line shows the fingerprint that is entered into the WLC configuration. You must omit the colons (:) within the hexadecimal fingerprint. The fingerprint must be 40 characters in length.



	242 Chapter 8: Wireless Security

	Figure 8-24 Adding IPS Sensors



	Step 1 Click Apply. Step 1 Navigate to WLANs and click Edit on the configured WLANs that you want to monitor. Make sure that Client Exclusion is enabled. The default client exclusion timeout is 60 seconds. On the other hand, the client exclusion persists as long as the IPS shun (block) remains active. The default block time in the Cisco IPS devices is 30 minutes.

	Uploading and Configuring IDS/IPS Signatures Several signatures come with the WLC by default. You can view the standard signatures by navigating to Security > Wireless Protection Policies and then clicking Standard Signatures. This is illustrated in Figure 8-25. You can also upload a signature file from the WLC to customize the signatures. To do this, navigate to Commands > Upload File > Signature File. To download the modified signature file, navigate to Commands > Download File > Signature File. After you download (or push) the edited signature file to the WLC, all registered wireless access points are refreshed in real time with the new signature configuration.



	Management Frame Protection (MFP) 243

	Figure 8-25 WLC Standard Signatures



	When customizing signatures, you must use the following format: Name = , Ver = , Preced = , FrmType = , Pattern = , Freq = , Interval = , Quiet = , Action = , Desc =

	NOTE The maximum length of each line is 1000 characters. The WLC will not correctly parse any lines longer than 1000 characters.

	You can view the custom signatures by navigating to Security > Wireless Protection Policies and then clicking Custom Signatures. Management Frame Protection (MFP) Management Frame Protection (MFP) enables authentication of all 802.11 management frames between the WLC and wireless access points. MFP protects against direct and man-in-the-middle attacks. It also detects and reports potential phishing attacks. MFP has three main functions: • Frame protection: This enables the wireless access point to protect the management frames by adding a message integrity check information element (MIC-IE) to each frame.



	244 Chapter 8: Wireless Security

	• Frame validation: The wireless access point validates every management frame that it receives from other access points in the network. • Event reporting: The wireless access point notifies the WLC when it detects an anomaly. The WLC can also report these events via SNMP traps to management servers. You can enable MFP globally. However, you can disable it on individual WLANs and access points. In other words, you can selectively enable or disable MFP on specific wireless access points or WLANs. To enable MFP globally, navigate to Security > Wireless Protection Policies. Then click AP Authentication/MFP and choose Management Frame Protection from the Protection Type pull-down menu. You can view the MFP statistics under Security > Wireless Protection Policies > Management Frame Protection.

	Precise Location Tracking The Cisco Wireless Location Appliance uses RF fingerprinting technology to track mobile devices to within a few meters. This allows you to gain visibility into the location of people and assets. In addition, RF fingerprinting technology enables you to respond to security issues and thereby gain insight into the location and movement of people and assets, as well as locating rogue wireless access points. The Cisco Wireless Location Appliance supports two location tracking options: • On-demand location tracking: The user queries the location of the person or wireless device. • Simultaneous location tracking: This automatically tracks up to thousands of 802.11 wireless devices by adding a Cisco Wireless Location Appliance in conjunction with a Cisco WCS.

	TIP It is recommended that you become familiar with the different methodologies used for location tracking and that you deploy these solutions within your network. Conventionally, many have used three different methods for locating wireless users or devices: closest access point, triangulation, and RF fingerprinting. As previously mentioned, the Cisco Wireless Location Appliance uses RF fingerprinting. A whitepaper explaining each methodology is located at http://www.cisco.com/en/US/products/ps6386/ products_white_paper0900aecd80477957.shtml.



	Network Admission Control (NAC) in Wireless Networks 245

	Network Admission Control (NAC) in Wireless Networks Network Admission Control (NAC) was initially designed as two separate solutions: the NAC Framework and NAC Appliance (formerly known as Cisco Clean Access). The most commonly deployed NAC solution for wireless networks is the NAC Appliance. This section covers how to integrate the Cisco NAC Appliance into the Cisco Unified Wireless solution. As mentioned in previous chapters, the NAC Appliance has three major components: • Clean Access Server (CAS) • Clean Access Manager (CAM) • Clean Access Agent In the example illustrated in Figure 8-26, the CAS is configured inline and managed by the CAM (172.18.85.181). All wireless traffic will pass through the server before it can reach the corporate network or the Internet. The goal in this example is to separate guest users from employees. The guest users will have only limited access to the Internet via HTTP and HTTPs. The employees will have access to the corporate resources. Two SSIDs are configured in the Figure 8-26 example: • GUESTNET: Used by guests • CORPACCESS: Used by employees The WLC is configured to broadcast the GUESTNET SSID, but not the CORPACCESS.

	TIP As a best practice, it is recommended that you use different SSIDs for your employees and guest wireless users. For your employees (internal users), you can also use 802.1X authentication and strong encryption (WPA with TKIP/MIC or WPA2 with AES).

	The following sections provide the step-by-step procedures for configuring the NAC Appliance (CAM and CAS), the WLC, and the NAC Agent configuration.



	246 Chapter 8: Wireless Security



	NAC Appliance Configuration It is recommended that you configure the CAS in the Real-IP gateway mode for wireless network deployments. When the CAS is configured in the Real-IP gateway mode, it handles all routing between the unprotected and protected networks. In this example, the untrusted (unprotected) interface resides in the 10.10.10.0/24 subnet, and the trusted (protected) interface resides in the 192.168.40.0/24 subnet. Complete the following steps to configure the NAC Appliance solution to protect the corporate resources by performing security posture checks for wireless users. In addition, enforce policy for guest users so that they are only able to access the Internet while



	Network Admission Control (NAC) in Wireless Networks 247

	employees can access corporate resources. Noncompliant clients will be quarantined and remediated. Step 1 The CAS is always configured via the CAM. Log in to the CAM with an administrator account. Step 2 After you are logged in to the CAM, navigate to the Device Management section in the menu on the left, and click CCA Servers. Step 3 To add a new CAS, click the New Server tab and enter the CAS information, as illustrated in Figure 8-27. In this example, the CAM will access the CAS via the trusted interface (IP address 192.168.40.2). Figure 8-27 Adding a New CAS in the CAM

	73

	Step 4 Enter a server location description. The description can be any word or phrase that describes the location of the CAS. In this example, the location description is Wireless Network. Step 5 The goal in this example is to configure the CAS in Real-IP gateway mode. Choose Real-IP Gateway from the drop-down menu. Step 6 Click Add Clean Access Server. Step 7 To access the CAS, click the Manage icon under Device Management > CCA Servers, as illustrated in Figure 8-28.



	248 Chapter 8: Wireless Security

	Figure 8-28 Accessing the CAS via the CAM

	73

	Step 8 Verify the IP addressing information, and verify that the CAS is configured with the Real-IP Gateway option by clicking the Network tab, as shown in Figure 8-29. Step 9 In this example, the trusted interface IP address is 192.168.40.2, and the default gateway is the Cisco ASA (192.168.40.1). Enter this information under the Trusted Interface section, as illustrated in Figure 8-29. Step 10 Enter the IP address information for the untrusted interface. In this example, the untrusted interface IP address is 10.10.10.2, and the default gateway is 10.10.10.1. Both the trusted and untrusted interfaces are configured with a 24-bit subnet mask (255.255.255.0). Step 11 Enter your DNS information under the DNS section, as illustrated in Figure 8-30. In this example, the CAS name is cas1, the domain name is cisco.com, and the IP address of the DNS server is 172.18.108.40. Step 12 In this example, you will create two users: guest and employee1. To create the local database, navigate to User Management > Local Users and enter the user information, as illustrated in Figure 8-31. Step 13 The next step is to create the user roles. To enter a new user role, go to User Management > User Roles > New Role and enter the user role information, as illustrated in Figure 8-32.



	Network Admission Control (NAC) in Wireless Networks 249

	Figure 8-29 Real-IP Gateway Configuration

	73

	73



	250 Chapter 8: Wireless Security

	Figure 8-31 Adding Local Users

	73

	Figure 8-32 User Roles

	73



	Network Admission Control (NAC) in Wireless Networks 251

	In Figure 8-32, the guest user role is configured. The user role name is Guest Role, and the role description is Wireless Guest Role. For guest users, at the After Successful Login Redirect to field, click to choose this URL, and enter the URL to which you want the guest user redirected. In this case, guest users will be redirected to a site called guestaccess.cisco.com with further instructions and disclaimers. All other options are left with default values. Step 14 You can configure traffic policies to be applied to each user role by clicking the Policies icon by the specific role, as illustrated in Figure 8-33.

	Figure 8-33 User Role Policies

	73

	Step 15 By default, all traffic is denied. To enter a new policy, click the Add Policy link, as illustrated in Figure 8-34. Step 16 Enter the policy information. In this example, all guest users are allowed to access the Internet via HTTP (TCP port 80) and HTTPs (TCP port 443). DNS traffic (UDP port 53) also needs to be allowed. Figure 8-35 shows how to configure a new policy to allow HTTP traffic. Step 17 All internal traffic is denied. In this case, all internal networks can be summarized into two major subnets: 192.168.0.0/16 and 172.18.0.0/16. Figure 8-36 shows how all the guest user policies are configured.



	252 Chapter 8: Wireless Security

	Figure 8-34 Adding a New Policy

	73

	Figure 8-35 Allowing HTTP for Guest Users

	73



	Network Admission Control (NAC) in Wireless Networks 253

	73

	Notice how traffic to HTTP and HTTPS to all destinations is allowed by the first few policy entries. This is done because you cannot map the whole Internet for guest users. However, specific deny statements for all UDP and TCP traffic to internal networks are denied. In addition, a catch-all deny statement is included at the end. You can assign users to different roles by editing the previously created users. Step 18 Configure a host-based policy for access to remediation sites when users are quarantined. Navigate to User Management > User Roles > Traffic Control > Host and choose Agent Quarantine Role in the drop-down menu, as illustrated in Figure 8-37. Then select the sites you want your quarantined clients to be able to access for remediation. In Figure 8-37, access is allowed to update.microsoft.com (the Microsoft update site) and to an internal remediation server. Step 19 You can create or customize a login page for the wireless users by going to Administration > User Pages and choosing Add at the Login Page tab. You can edit the web login portal page content by going to Administration > User Pages > Login Page > Edit > Content.



	254 Chapter 8: Wireless Security

	73

	Step 20 To enable basic network scanning for guest user workstations, go to Network Scanner > Scan Setup to determine which user role and operating system to use. This is illustrated in Figure 8-38. Step 21 Select the operating system options under the Plugins, Options, and Vulnerability tabs. Step 22 You can also configure a user agreement page for web login users by navigating to the User Agreement tab. Step 23 To establish employee roles for posture assessment, you must create a requirement rules mapping by going to Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules. For instance, a user can choose to perform Windows HotFixes checks for Windows-based systems. Step 24 For employees, you should require the use of the NAC Agent (Clean Access Agent) by clicking Require use of Clean Access Agent. After users are successfully logged in, you will see them under Monitoring > Online Users.



	Network Admission Control (NAC) in Wireless Networks 255

	Figure 8-38 Scanner Setup

	73

	WLC Configuration This section includes the steps necessary to configure the WLC for the NAC Appliance solution to work. Complete the following steps to configure the WLC. Step 1 As a best practice, it is recommended that you configure separate VLANs for guest and internal users. To do this, you need to configure two new pseudointerfaces. Log in to the WLC, navigate to Controller > Interfaces, and click New to add a new interface. Enter the name for the new interface and the VLAN you want to assign. This is illustrated in Figure 8-39. In this example, the interface for guest users is called guest and assigned to VLAN Id 123. Step 2 The next screen (shown in Figure 8-40) allows you to enter the interface configuration parameters, such as IP address, subnet mask, default gateway, DHCP server information, and others. In this case, the guest interface is configured with the IP address 10.20.1.2 with a 24-bit subnet mask. The default gateway and DHCP server is 10.20.1.1.

256 Chapter 8: Wireless Security

Figure 8-39 Adding a New Dynamic Guest Interface in the WLC

Figure 8-40 WLC Guest Interface Configuration


Cisco - Windows Internet Explorer				BHD

	https: lj 172.1S. 85.9 Ц screens/frameset .html		v \Щ Certificate Error *\|\|+\|\|x\|** \| Google	l-°H

u * \t		I		J *la -** e- a »
u * \t				J *la -** e- a »
и		Save Configuration Pin MONITOR WLANs CONTROLLER WIRELESS SECURITY MANAGEMENT COMMANDS HELP		g Logout Refresh

Controller		Interfaces > Edit	< Back	Apply
General Inventory		General Information
Interfaces		Interface Name gu
Network Routes		Interface Address
Internal DHCP Server		Interface Address
Mobility Management Mobility Groups Mobility Statistics.		VLAN Identifier IP Address	10.20.1.2
Spanning Tree		Netmask	255.255.255.0
Ports			10.20.1.1
Master Controller Mode Mef-turirL Time Pmtnrnl		Physical Information
QoS Profi		³ort Number Заскир Port ictivs -o 1 Enable Dynamic AF Management Configuration	О ■
			□
		DHCP Information
		Primary DHCP Server	10.20.1.1
		Secondary DHCP Server	1
			$ Internet	+„100% '



	Network Admission Control (NAC) in Wireless Networks 257

	Step 3 Add another interface for employees (internal users).

	Step 4 Under Controller > General, make sure that Layer 3 is selected in the LWAPP Transport Mode drop-down menu, as illustrated in Figure 8-41.

	Figure 8-41 LWAP Setting



	Step 5 In the Default Mobility Domain Name field, enter RFGroup1. Step 6 Create a guest wireless LAN interface named guest and assign an SSID. (In this example, we also name it guest.) Step 7 Configure the WLAN with open authentication and DHCP address assignment required. Enter guest as the wireless LAN interface SSID under the WLANs > Edit window. Click the check box to require DHCP Addr. Assignment, as illustrated in Figure 8-42. Step 8 Repeat Steps 6 and 7 to create and configure a WLAN for internal users. Step 9 To add the RADIUS server information for 802.1X authentication, navigate to Security > AAA> RADIUS Authentication. In this case, you use the same server that you configured previously in this chapter (172.18.85.181). Step 10 The CAS uses RADIUS accounting packets to trigger the security posture of wireless users. Configure the CAS as the RADIUS Accounting server by going to Security > AAA> RADIUS Accounting > New. Add the CAS information, as illustrated in Figure 8-43.



	258 Chapter 8: Wireless Security

	Figure 8-42 Guest WLAN Configuration " [tfls:»172.1s.**



	Figure 8-43 Adding the CAS as a RADIUS Accounting Server

Chapter 7: Proactive Security Framework

admin — Sun, 28 Feb 2010 22:50:14 +0000

Many network security frameworks are in the marketplace and most of them have the common goal of providing a methodical and efficient approach to network security. No framework is perfect, you should choose an approach that can help reduce the time, cost, and resources needed to plan and deploy your security strategy. This chapter highlights best practices and benefits of different security frameworks.

A framework can help you establish a view of your entire security landscape, identify potential capability gaps, and prioritize initiatives for improvement.

The Security Assessment, Validation, and Execution (SAVE) framework, formerly known as the Cisco Operational Process Model (COPM), is a security framework that enables visibility and control for end-to-end security. Cisco initially designed SAVE for the Internet service provider (ISP) part of the Next-Generation Network (NGN) initiative. However, you can also apply its practices to enterprises.

Today, malicious traffic within ISPs is spreading faster than before because attack tools are becoming more sophisticated and easier to find. ISPs have witnessed a transformation in the community that engages in cybercrime activities for financial reward, otherwise known as the miscreant economy. The principles introduced by SAVE allow ISPs and other organizations to defend against these threats while maintaining control and visibility of their networks.

SAVE defines network security in six major categories or "pillars." Figure 7-1 illustrates the different categories within the SAVE framework.

The six pillars in SAVE are as follows:

• Identity and trust

• Visibility

• Correlation

• Instrumentation and management

• Isolation and virtualization

• Policy enforcement



	Summary 259

	After you complete these steps, you will be able to authenticate using a wireless client. Guest users will be redirected to a web-based login, and regular employees will use the Cisco Clean Access Agent to connect to the network. Summary Wireless access is a core part of the infrastructure in most organizations. When developing a wireless implementation, take into consideration the unique security challenges that wireless connectivity brings. Implementing best practice wireless security techniques is a must for any organization. This chapter included best practices when deploying wireless networks. It also covered different types of authentication mechanisms, including 802.1x. In addition, it included an overview of LWAP, location services, MFP, and other wireless features that need to be taken into consideration when designing security within your wireless infrastructure. This chapter also covered step-by-step configuration examples of the integration of IPS on Cisco wireless networks. In addition, it provided guidance on how to integrate the Cisco NAC Appliance and the Cisco Unified Wireless Network solution.

178 Chapter 7: Proactive Security Framework

Figure 7-1 SAVE Categories Illustrated

Identity and Trust

Visibility

Correlation

Instrumentation

and Management

Isolation and Virtualization

Policy Enforcement

Observe IP Packets

Layer 2 through Layer 7

Stateful and Stateless

Relational Analysis of System-Wide

Events

Device Hardening

and Operational

Views

Enforce Subscribed Behavior

Identity State of Trust

Segmentation and Partition



	Resiliency

	Total Visibility Classify, Categorize and Associate Events to a Given Control Policy	Complete Control Service Policies that allow for Containment, Mitigation and Service Constraint Enforcement

SAVE Versus ITU-T X.805

There is a security methodology created by the Lucent consulting practice called ITU-T X.805, "Security Architecture for Systems Providing End-to-End Communications." ITU-T X.805 defines a threat model that includes five categories:

• Destruction

• Corruption

• Removal

• Disclosure

• Interruption

ITU-T X.805 defines three security layers:

• Infrastructure layer

• Services layer

• Applications layer

SAVE Versus ITU-T X.805 179

Figure 7-2 ITU-T X.805 Security Layers

ITU-T X.805

Destruction Corruption Removal Disclosure Interruption


Infrastructure Layer	Services Layer	Applications Layer
• Routers	• Voice over IP (VoIP)	• Web Browsing
• Switches	• Quality of Service (QoS)	• E-mail
• Firewalls	• Location Services	• E-Commerce
• Servers and Workstations	• Other IP Services	• Mobile Web

The ITU-T X.805 infrastructure layer includes all infrastructure devices, including:

• Routers

• Switches

• Firewalls

• Servers

• End-user workstations

The services layer includes services such as the following:

• Voice over IP (VoIP)

• Quality of service (QoS)

• Location services

• Other IP services

The applications layer includes all Layer 7 applications that run on the network infrastructure. Each layer has unique threats, vulnerabilities, and ways to mitigate them. X.805 also has three security planes:

• End-user plane

• Control/Signaling plane

• Management plane

These security planes are illustrated in Figure 7-3.

180 Chapter 7: Proactive Security Framework

Figure 7-3 ITU-T X.805 Planes

Destruction Corruption Removal Disclosure Interruption


Infrastructure Layer • Routers • Switches • Firewalls • Servers and Workstations	Services Layer • Voice over IP (VoIP) • Quality of Service (QoS) • Location Services • Other IP Services	Applications Lay • Web Browsing • E-mail • E-Commerce • Mobile Web	er

End-User Security

Control/Signaling Security Management Security

X.805 also includes eight security dimensions that apply to each security layer and plane. The following are these dimensions:

• Access control: Firewall policies and access control lists (ACL).

• Authentication: Public key infrastructure (PKI), shared secrets, and one-time-passwords.

• Nonrepudiation: Syslogs and digital signatures.

• Data confidentiality: This confidentiality occurs through the use of encryption.

• Communication security: Transport mechanisms such as IP Security (IPsec) and Secure Socket Layer (SSL) virtual private networks (VPN), in addition to Layer 2 Tunneling Protocol (L2TP) tunnels.

• Data integrity: Hashing with message digest algorithm 5 (MD5) and Secure Hash Algorithm (SHA).

• Availability: Examples include redundancy with Hot Standby Router Protocol (HSRP) or Virtual Router Redundancy Protocol (VRRP).

• Privacy: Encryption and Network Address Translation (NAT). The eight security dimensions are illustrated in Figure 7-4.

Confused yet? X.805 is an overcomplicated approach. Cisco has tried to evolve it to make it more practical to use; however, X.805 is not a true end-to-end security framework and is even potentially harmful in the market and in standards.

SAVE Versus ITU-T X.805 181

Figure 7-4 ITU-T X.805 Security Dimensions

Destruction

Corruption

Removal

Disclosure

Interruption

Infrastructure Layer

• Routers

• Switches

• Firewalls

• Servers and Workstations

Services Layer

• Voice over IP (VoIP)

• Quality of Service (QoS)

• Location Services

• Other IP Services

Applications

• Web Browsing

• E-mail

• E-Commerce

• Mobile Web

Layer

End-User Security Control/Signaling Security Management Security

• Access Control

• Authentication

• Non-Repudiation

• Data Confidentiality

• Communication Security

• Data Integrity

• Availability

• Privacy

SAVE introduces a roles-based approach for security assessment in a simple manner. Each device on the network serves a purpose and has a role; subsequently, you should configure each device accordingly. SAVE defines five different planes:

• Management plane: Distributed and modular network management environment.

• Control plane: Includes routing control. This is often a target because the control plane depends on direct CPU cycles.

• User/Data plane: Receives, processes, and transmits network data among all network elements.

• Services plane: Layer 7 application flow built on the foundation of the other layers.

• Policies: The business requirements. Cisco calls policies the business glue for the network. Policies and procedures are part of this section, and they apply to all the planes in this list.



	182 Chapter 7: Proactive Security Framework

	These planes are illustrated in Figure 7-5. Figure 7-5 Planes in SAVE

	Management	Services

	t t t t

	SAVE also presents security in two different perspectives: • Operational (reactive) security • Proactive security This is illustrated in Figure 7-6. Figure 7-6 Operational and Proactive Security Improve your capabilities to react to security incidents.

	Operational Security Proactive Security

	Proactively prepare your infrastructure, staff, and organization as a whole. Learn about new attack vectors and mitigate them with the appropriate hardware, software, and architecture solutions.



	Identity and Trust 183

	You should have a balance between proactive and reactive security approaches. Prepare your network, staff, and organization as a whole to better identify, classify, trace back, and react to security incidents. In addition, proactively protect your organization while learning about new attack vectors, and mitigate those vectors with the appropriate hardware, software, and architecture solutions. You can achieve this balance using what you learned in Chapter 2, "Preparation Phase." The best practices described there help you to proactively prepare and protect your network and organization as a whole. Identity and Trust Identity and trust is one of the SAVE pillars. You should consider deploying a complete trust and identity management solution for secure network access and admission at every point in the network. The following are the most common technologies that are part of the identity and trust pillar: • Authentication, authorization, and accounting (AAA) • Cisco Guard active verification • DHCP snooping • Digital certificates and PKI • Internet Key Exchange (IKE) protocol • IP Source Guard • Network Admission Control and 802.1x • Routing protocol authentication • Strict Unicast Reverse Path Fowarding (Unicast RPF) These technologies are illustrated in Figure 7-7. AAA In Chapter 1, "Overview of Network Security Technologies," you learned the basic concepts of AAA. In Chapter 2, "Preparation Phase," you learned best practices for enabling authentication on networking devices for infrastructure protection. In this chapter, AAA concepts are aligned to the identity and trust pillar. A lack of appropriate user management techniques creates numerous direct business risks, including lower productivity, duplicate and conflicting user information, lack of information security, and difficulty in evaluating regulatory compliance. AAA goes beyond the normal authentication and authorization when accessing network devices for management purposes. You should implement a combination of authentication, access control, and user policies to secure network connectivity and resources to which only specific users should be provided access. This access includes the authentication of databases, web servers, e-mail, and other applications, in addition to authentication of users when they attempt to access network segments and their resources.



184 Chapter 7: Proactive Security Framework

Figure 7-7 Identity and Trust

Radius

TACACS+

Identity and Trust	Э

AAA			Active Directory, LDAP, etc.

Cisco Guard Active Verification

DHCP Snooping

Digital Certificates and PKI		Certs

IKE

IP Source Guard

Network Admission Control

Routing Protocol Authentication		Ъ Ъ 4

Strict uRPF		Ъ 4	Spoofed

Other examples include authentication for remote access VPN and authentication of wireless users. The identity lifecycle consists of account setup, maintenance, and teardown. Account setup includes giving users the appropriate level of access to resources necessary to do their jobs. Account maintenance consists of keeping user identity information up-to-date and appropriately adjusting levels of access to resources needed to conduct business. Account teardown consists of deactivating the user account when the user is no longer affiliated with the company. Stronger forms of authentication, such as PKI and one-time passwords (OTP), are increasingly used to control user access to corporate resources. Several solutions provide these kinds of services. You should always look for solutions that provide flexible authorization policies that are tied to the user identity, the network access type, and the



	Identity and Trust 185

	security of the machine used to access the network. In addition, the ability to centrally track and monitor the connectivity of network users is of primary importance in isolating unwanted and excessive use of valuable network resources.

	NOTE Management, monitoring (correlation), and isolation are discussed later in this chapter, because they are separate SAVE categories or pillars.

	As you learned in Chapter 1, TACACS+ and RADIUS are the most commonly used AAA protocols. Cisco Secure ACS supports both of these protocols and provides support for advanced authentication mechanisms, including the interoperability to external directory services, OTP servers, PKI, and other authentication solutions. Cisco Secure ACS is an important component of the Cisco Identity-Based Networking Services (IBNS) architecture based on port-security standards such as 802.1x (an IEEE standard for port-based network access control). It is also the "brains" behind the Cisco Network Admission Control (NAC) Framework solution.

	NOTE Examples of the use of Cisco Secure ACS are discussed in the case studies included in Chapter 12, "Case Studies." The Cisco Secure ACS documentation is located at http://www.cisco.com/en/US/products/sw/secursw/ps2086/ tsd_products_support_maintain_and_operate.html. A good white paper on how to place the Cisco ACS servers within your network is located at http://www.cisco.com/en/US/products/sw/secursw/ps2086/ products_white_paper09186a0080092567.shtml.

	Cisco Guard Active Verification The Cisco Guard provides multiple layers of defense to identify and block all types of attacks with extreme accuracy. It has integrated dynamic filtering capabilities and active verification technologies. These capabilities and technologies are implemented through the use of a patented Multiverification Process (MVP) architecture, which can process suspicious flows by applying numerous levels of analysis. The MVP enables malicious packets to be identified and removed, while allowing legitimate packets to flow freely.

	NOTE	In Chapter 3, "Identifying and Classifying Security Threats," you learned how to use the Cisco Guard in conjunction with the Cisco Detector and other third-party solutions to identify and classify attacks.



	186 Chapter 7: Proactive Security Framework

	DHCP Snooping DHCP snooping is another technology or feature that can be considered part of identity and trust. It is a DHCP security feature that filters DHCP messages by building and maintaining a binding table. This table contains information that corresponds to the local untrusted interfaces of a switch, such as: • MAC address of the device connected to the switch • IP address of the device connected to the switch • DHCP lease time • DHCP binding type • VLAN number • Interface information

	NOTE The DHCP snooping table does not contain information regarding hosts interconnected with a trusted interface. An untrusted interface is an interface that is configured to receive packets from an untrusted network or device. A trusted interface is an interface that is configured to receive only messages from within the trusted network or device.

	You can configure DHCP snooping for a single VLAN or a range of VLANs. The following example shows how to enable DHCP snooping on VLANs 10 through 50: Example 7-1 IP DHCP Snooping 'enable DHCP snooping globally ! ip dhcp snooping vlan 10 50 !apply DHCP snooping on VLANs 10 to 50 _! ip dhcp snooping information option _! interface GigabitEthernet1/1 ip dhcp snooping limit rate 100 !this interface is classified as an untrusted interface, and the rate limit is configured. !You may not want to configure untrusted rate limiting to more than 100 pps. !Normally, the rate limit applies to untrusted interfaces. !If you want to set up rate limiting for trusted interfaces, keep in mind that trusted !interfaces aggregate all DHCP traffic in the switch, and you will need to adjust the rate !limit to a higher value.



	Identity and Trust 187

	You can use the show ip dhcp snooping command to verify your configuration, as shown in the following example: Example 7-2 Ouput of the show ip dhcp snooping command myswitch#show ip dhcp snooping Switch DHCP snooping is enabled DHCP snooping is configured on following VLANs: 10,20,30,40,50 Insertion of option 82 is enabled Option 82 on untrusted port is not allowed Verification of hwaddr field is enabled Interface Trusted Rate limit (pps) GigabitEthernet1/1 no 100

	In the previous example, you can see that DHCP snooping is enabled on VLANs 10, 20, 30, 40, and 50 (which are VLANs enabled on this switch). The interface GigabitEthernet1/1 is an untrusted interface, and rate limit is applied to 100 packets per second (pps). To configure an interface as a trusted interface, you must use the ip dhcp snooping trust interface subcommand. IP Source Guard IP Source Guard is a Layer 2 feature that works in conjunction with DHCP snooping. When IP Source Guard is enabled, all IP traffic on the port is initially blocked, with the exception of DHCP packets that are processed by the DHCP snooping feature (if enabled). After the end host receives a valid IP address from the DHCP server, or when a user configures a static IP source binding, a Port Access Control List (PACL) is applied on the port to restrict the client IP traffic to specific source IP addresses that are configured in the binding configuration. The switch drops all IP traffic with a source IP address other than that in the IP source binding. An important note to remember is that if you configure IP Source Guard on a trunk port with a large number of VLANs that have DHCP snooping enabled, you might run out of ACL hardware resources, and depending on your platform, some packets might be switched in software. You can configure two levels of IP traffic filtering with IP Source Guard: • Filtering source IP addresses: Only IP traffic with a source IP address that matches the IP source binding entry is permitted. • Filtering on Source IP and MAC address: This is based on source IP address and its associated MAC address. To enable IP Source Guard, use the ip verify source vlan dhcp-snooping interface subcommand, as shown in the following example: interface GigabitEthernet1/1 ip verify source vlan dhcp-snooping



188 Chapter 7: Proactive Security Framework

To verify the configuration, you can use the show ip verify source interface gigabitEthernet 1/1 command, as shown in the following example:

myswitch#show ip verify source interface gigabitEthernet 1/1 Interface Filter-type Filter-mode IP-address Mac-address					Vlan

Gi1/1 Gi1/1		ip-mac ip-mac	active active	10.10.1.1 deny-all	10 11-20

Digital Certificates and PKI

IKE	Digital certificates and PKI are also technologies that are used for trust and identity. Digital certificates bind an identity to a pair of electronic keys that can be used to encrypt and sign digital information. A digital certificate makes it possible to verify a claim that someone has the right to use a given key. This verification helps to prevent people from using phony keys to impersonate other users. Used in conjunction with encryption, digital certificates provide a more complete security solution than traditional username and password schemes. Digital certificates ensure the identity of all parties involved in a transaction. The following are some of the most common uses of digital certificates: • IPsec VPN tunnel authentication • SSL transactions • Code signing • Application authentication (that is, e-mail, e-commerce, and so on) IKE provides authentication mechanisms for IPsec VPN tunnels. This protocol is also an example of identity and trust technologies.

NOTE	Detailed information on IKE authentication mechanisms is covered in Chapter 1.

Network Admission Control (NAC)

NAC is also an example of a trust and identity technology. As you learned in Chapters 1 and 2, NAC appliance and framework provide a solution to evaluate whether end-host workstations are compliant with security policies before they enter the network. These policies can include antivirus, antispyware software, operating system updates, security patches, and other preconfigured options. In addition, the role-based authentication features provide more granular access to end hosts and users.



	Visibility 189

	Routing Protocol Authentication Another example of a trust and identity technique is the implementation of routing protocol authentication. Border Gateway Protocol (BGP), Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), Routing Information Protocol (RIP) and Intermediate System-to-Intermediate System Protocol (IS-IS) all support various forms of authentication mechanisms.

	NOTE These authentication mechanisms are discussed in Chapter 2 in detail.

	Strict Unicast RPF Strict Unicast RPF is an antispoofing mechanism that verifies the source address of a packet received on a router interface by verifying the forwarding table of the router. If the source address is reachable through the same interface on which the packet was received, the router processes the packet; if not, the packet is dropped. You can also categorize Unicast RPF as a trust and identity mechanism.

	NOTE Unicast RPF is discussed in Chapter 2.

	Visibility Network visibility is one of the most important pillars within the SAVE framework. In fact, two of the most important components of SAVE are visibility and control. The following are the most common technologies that can be used to obtain and maintain complete network visibility: • Anomaly detection • Intrusion detection system/intrusion prevention system (IDS/IPS) [IOS, Cisco Security Agent (CSA), network-based intrusion detection system/network-based intrusion prevention system (NIDS/NIPS)] • Cisco Network Analysis Module (NAM) • Layer 2 and Layer 3 information [Cisco Discovery Protocol (CDP), routing tables, Cisco Express Forwarding (CEF) tables] These are illustrated in Figure 7-8.

190 Chapter 7: Proactive Security Framework

Figure 7-8 Technologies That Help to Achieve and Maintain Complete Network Visibility


	Visibility

Cisco Guard

Anomaly Detection

NetFlow

CSA

IDS/IPS

IPS Sensors, AIP-SSM, IDSM

NAM

■

CDP, Routing Tables, CEF, etc.

Anomaly Detection

Anomaly detection can be performed by various tools that provide insightful information on exactly what is happening within your network. These tools or technologies include the following:

• NetFlow

• Arbor Peakflow SP and Peakflow X

• Cisco Anomaly Detector XT

NOTE Anomaly detection technologies and solutions are discussed in Chapters 1 and 2.

IDS/IPS

IDSs and IPSs also provide visibility into what is happening on the network. Most of the network IDS and IPS systems rely on signatures for detection and protection. For this reason, it is extremely important to keep signatures up-to-date and to tune the IDS/IPS devices accordingly. Cisco IPS 6.0 now supports anomaly detection capabilities that allow you to detect day-zero vulnerabilities more easily.



	Visibility 191

	NOTE An introduction to network IDS and IPS systems is covered in Chapter 1. Chapter 3 teaches you how to use network IDS and IPS systems to successfully identify and classify security threats. The configuration of IPS systems is covered within the case studies included in Chapter 12.

	Host-based intrusion prevention systems, such as the Cisco Security agent, also provide information about the behavior of end-host systems by extending the visibility to each end point (host or servers).

	Cisco Network Analysis Module (NAM) The Cisco NAM is an integrated network monitoring solution for the Cisco Catalyst 6500 series switches. Ciso NAM is designed to give you visibility into the network by showing you information about applications running on your network and the performance of these applications. The Cisco NAM solution includes a web-based traffic analyzer GUI that presents statistical information to the administrator. The Cisco NAM uses Management Information Bases (MIB) for Remote Monitoring II (RMON II), Differentiated Services Monitoring (DSMON), Switch Monitoring (SMON), and other mechanisms to analyze and store the collected data.

	NOTE The following link provides detailed information about NAM: http://www.cisco.com/en/US/products/hw/modules/ps2706/ps5025/index.html. The configuration guide is located at http://www.cisco.com/en/US/products/hw/switches/ ps708/products_configuration_guide_book09186a00805e081e.html.

	Layer 2 and Layer 3 Information (CDP, Routing Tables, CEF Tables) Layer 2 and Layer 3 routing features can provide insightful information and increase visibility. Features such as CDP, CEF, and IP routing tables can give you topological information about the network. It is important to notice that in the hands of the enemy, tools like CDP can be destructive. Therefore, it is recommended that you enable CDP only on trusted interfaces.

	NOTE	For more information on best practices to use when implementing CDP, refer to Chapter 2.



	192 Chapter 7: Proactive Security Framework

	Correlation In previous chapters, you learned the different aspects of event correlation. For example, you learned that the more complex the network and devices deployed, the more event messages, alarms, and alerts these devices will generate. In the end, far more data is generated than anyone can easily scan, and it is located in numerous places. In this chapter, you learn the importance of event correlation for maintaining good visibility of what is happening in the network. This chapter also describes tools and technologies you can deploy to successfully correlate events, while maintaining visibility and control of the network. Event correlation tools enable you to efficiently use your staff time and skills, and they prevent revenue loss resulting from downtime. The following are examples of correlation tools: • Cisco Security Monitoring, Analysis, and Response System (CS-MARS) • Arbor Peakflow SP and Peakflow X • Cisco Security Agent Management Center (CSA-MC) basic event correlation These tools are illustrated in Figure 7-9. Figure 7-9 Example of Tools That Help You Maintain Network Visibility



	Instrumentation and Management 193

	CS-MARS CS-MARS supports events from routers, switches, firewalls, VPN devices, IPS/IDS solutions, operating system logs, application logs, and many other items. It supports both Cisco and non-Cisco devices.

	NOTE Chapter 3 teaches how you can use CS-MARS to successfully identify and classify security threats. The configuration of CS-MARS is covered within the case studies included in Chapter 12.

	Arbor Peakflow SP and Peakflow X Arbor Peakflow SP (for service providers) and Peakflow X (for enterprises) are excellent tools that allow you to obtain network visibility. Based on information collected from routers, such as interface statistics and NetFlow, Peakflow SP and Peakflow X can show you details of the traffic traversing throughout your network.

	NOTE For more information about these tools, go to http://www.arbor.net. Arbor has excellent white papers about anomaly detection and combating day-zero threats at http://www.arbor.net/resources_researchers.php.

	Cisco Security Agent Management Console (CSA-MC) Basic Event Correlation CSA-MC can also provide you with basic host-based event correlation. You can gain visibility of what exactly is happening within each endpoint (user workstations and servers).

	Instrumentation and Management Instrumentation and management is also an important category within the SAVE framework. You should always implement protocols and mechanisms that achieve the management of every network device. Having good instrumentation and management mechanisms in place not only allows you to provision configurations to your network devices, but it also helps you to maintain control of your environment. Some examples of management and instrumentation tools are as follows: • Cisco Security Manager (CSM) • Configuration logger and configuration rollback



194 Chapter 7: Proactive Security Framework

• Embedded device managers • Cisco IOS XR XML interface • Simple Network Management Protocol (SNMP) and remote monitoring (RMON) • Syslog These tools are illustrated in Figure 7-10. Figure 7-10 Example of Instrumentation and Management Tools

Instrumentation and Management
Cisco Security Manager

Configuration Logger and Rollback

Embedded Device Managers

ASDM		SDM

Cisco IOS XR XML Interface	XML	Ъ4

SNMP and RMON

Syslog



	Instrumentation and Management 195

	Cisco Security Manager CSM helps you configure Cisco firewalls, IPS devices, and VPN tunnels easily. It not only saves you time in the provisioning phase, but it can also be used to update enforcement policies in firewalls and routers when needed. CSM achieves scalability through policy-based management techniques that are used to simplify administration.

	Configuration Logger and Configuration Rollback The Cisco IOS configuration logger logs all changes that are manually entered at the command-line prompt. In addition, it can notify registered clients about any changes to the log.

	NOTE The contents of the configuration log are stored in the run-time memory; the contents of the log are not persisted after reboots. The Configuration Logger Persistency feature allows you to keep the configuration commands entered by users after reloads. You can enable the Configuration Logger Persistency feature by using the archive log config persistent save command.

	The Cisco IOS Software configuration rollback feature allows you to keep a journal file containing a log of the changes and discard them if needed. The purpose of this feature is to revert (or roll back) to a previous configuration. You can use the configure replace command to roll back to a previous configuration state.

	NOTE More information about the Cisco IOS configuration rollback feature is located at http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/ products_feature_guide09186a0080356ea5.html#wp1066264.

	Embedded Device Managers In small environments, you can use embedded devices managers to configure and manage network access devices such as routers, switches, firewalls, IPS devices, and others. Numerous Cisco devices come with an embedded device manager. Examples include the following: • Cisco Adaptive Security Device Manager (ASDM): Manages Cisco PIX and Cisco Adaptive Security Appliance (ASA) security appliances • Cisco IPS Device Manager (IDM): Manages Cisco IPS sensors, in addition to Advanced Inspection and Prevention Security Services Module (AIP-SSM) for the Cisco ASA • Security Device Manager (SDM): Manages Cisco IOS routers



	196 Chapter 7: Proactive Security Framework

	Cisco IOS XR XML Interface The Cisco IOS XR software supports an extensible markup language (XML) application programming interface (API) that helps you develop external management applications for routers that run Cisco IOS XR software.

	NOTE The following site has detailed information about the Cisco IOS XR XML interface: http://www.cisco.com/en/US/products/ps5845/tsd_products_support_series_home.html

	SNMP and RMON SNMP allows you to exchange management information between network devices and central management servers. SNMP is the most commonly used network device management protocol.

	NOTE In Chapter 2, you learn the basics of SNMP and what is most important: how to secure it.

	The RMON protocol provides you with freedom when selecting network-monitoring probes and consoles with features that not only provide ease of management, but also can be used for greater visibility and control of the network.

	In Chapters 2 and 3, you learn how syslog can provide you with details on what is happening in network devices, while also allowing you to achieve more control and visibility of the network. Firewalls, routers, switches, and other networking devices can send insightful information to administrators via syslog. The combination of syslog and event correlation systems gives you powerful capabilities. Isolation and Virtualization The fifth pillar in the SAVE framework addresses network isolation and virtualization. Several isolation and virtualization techniques and tools are available, including the following: • Cisco IOS Role-Based CLI Access (CLI Views) • Anomaly detection zones • Network device virtualization

Isolation and Virtualization 197

• Segmentation with VLANs

• Segmentation with firewalls

• Segmentation with VRF/VRF-Lite

These techniques and tools are illustrated in Figure 7-11.

Figure 7-11 Examples of Isolation and Virtualization Techniques and Tools


	Isolation

			Cisco IOS role-based CLI Access

			Anomaly Detection Zones

			Network Device Virtualization

			Segmentation with VLANs

			Segmentation with Firewalls

			Segmentation with VRF/VRF Lite

Another isolation technique is maintaining separation between the different network planes. For example, keep the data plane separate from the control and management planes, by also implementing the necessary policies to protect each of them.

Cisco IOS Role-Based CLI Access (CLI Views)

You can consider the Cisco IOS routers Role-Based CLI Access feature a form of virtualization. This feature, otherwise known as CLI Views, allows you to define a virtual set of operational commands and configuration capabilities that provide selective or partial access to Cisco IOS exec and configuration mode commands. A view is a framework of policies that defines which commands are accepted and which configuration information is visible to the user based on his role.



	198 Chapter 7: Proactive Security Framework

	NOTE The following site has detailed information about this feature: http://www.cisco.com/en/US/products/ps6350/ products_configuration_guide_chapter09186a0080455b96.html#wp1027184

	Anomaly Detection Zones The Cisco Detector XT and the Cisco Guard XT allow you to configure zones to categorize and define anomaly detection policies for more granularity and customization. The following are examples of zones you can configure within the Cisco traffic anomaly detectors: • Collections of servers or clients • Collections of routers or other network access devices • Network links, subnets, or entire networks • Single users or whole companies • Internet service providers

	NOTE The following site provides step-by-step instructions on how to create zones in Cisco Detector and Guard implementations: http://www.cisco.com/en/US/products/ps5887/ products_configuration_guide_chapter09186a00804bee78.html#wp1043192

	Network Device Virtualization Several networking devices support virtualization. You can take advantage of device virtualization to segment and apply different policies within your infrastructure, while saving money in hardware. For example, you can partition a single hardware device into multiple virtual devices. In most cases, each virtual device acts as an independent device. The following devices support virtualization: • Cisco PIX • Cisco ASA • Cisco Firewall Services Module (FWSM) for the Catalyst 6500 series switches • Cisco IPS sensors running version 6.x or later • The Cisco Application Control Engine (ACE) family for the Cisco Catalyst 6500 series switches The Cisco PIX, Cisco ASA, and FWSM can be configured in multiple context mode in which each context has its own security policy, interfaces, and administrators. Having



	Isolation and Virtualization 199

	multiple contexts is similar to having multiple standalone devices. Figure 7-12 illustrates how a Cisco FWSM is deployed with three contexts (admin, context-1, and context-2) to segment different servers in a data center).

	Figure 7-12 Security Contexts in FWSM





	Many features are supported in Cisco ASA, Cisco PIX, and Cisco FWSM running in multiple-context mode; however, some features are not supported, including VPN and dynamic routing protocols.

	NOTE Chapter 10, "Data Center Security," includes sample configurations of Cisco FWSM virtualization to provide data center security. Chapter 12, "Case Studies," also has configuration examples of virtualization in Cisco PIX and Cisco ASA security appliances.

	Segmentation with VLANs You can achieve network segmentation and isolation in many ways. The use of VLANs is one of the most commonly used methods because of its simplicity and ease of deployment. Figure 7-13 illustrates how you can isolate/segment different types of devices just by using VLANs.



	200 Chapter 7: Proactive Security Framework

	Figure 7-13 Segmentation Using VLANs



	Web Servers Database Servers LDAP Servers Management Applications

	In Figure 7-13, a set of web, database, Lightweight Directory Access Protocol (LDAP), and management servers are isolated by simply configuring four separate VLANs (VLANs 10, 20, 30, and 40, respectively). Segmentation with Firewalls In many situations, you can simply segment or isolate parts of the network, servers, or users by placing firewalls. Firewalls also provide more granular policy enforcement mechanisms. Sometimes you can use firewalls with VLAN segmentation, as illustrated in Figure 7-14. In Figure 7-14, the same servers and the four separate VLANs are configured. In addition, a pair of Cisco ASAs are placed to provide segmentation services while enforcing more granular security policies. Segmentation with VRF/VRF-Lite You can also use Multiprotocol Label Switching (MPLS) VPN routing and forwarding (VRF) or the MPLS VRF-Lite feature on Cisco IOS routers for network segmentation purposes. This concept is illustrated in Figure 7-15.



	Isolation and Virtualization 201



	Figure 7-15 Segmentation Using VRF and VRF-Lite Cisco ASAs



	Web Servers Database Servers LDAP Servers Management Applications

	The main challenge of implementing VRFs and VRF-Lite is that most enterprises do not run MPLS within their corporate network. More importantly, their staffs do not have the skills to implement MPLS because it is a complicated routing technology. This segmentation technique is mainly implemented by service providers.



	202 Chapter 7: Proactive Security Framework

	Policy Enforcement The last pillar in the SAVE framework defines policy enforcement. You can enforce policy in many ways. Figure 7-16 illustrates some examples of techniques and features that allow you to enforce security policies within your organization: Figure 7-16 Policy Enforcement Policy Enforcement

	Cisco Guard XT MVP

	Control Plane Policing

	Encryption Policies in IPsec

	Firewalls, ACLs, Packet Filters

	NAC Policy Enforcement

	Policy-based Routing

	RTBH

	The following examples are illustrated in Figure 7-16. • Cisco Guard XT MVP: With the Cisco Guard XT, you can do per-flow-level attack analysis, identification, and mitigation. This is an example of policy enforcement, because the Cisco Guard XT MVP architecture provides multiple layers of defense that can block attack traffic, while allowing legitimate transactions to pass. • Control Plane Policing: In Chapter 2, you learn best practices when deploying Control Plane Policing (CoPP) in your network. CoPP is also used to enforce predefined policies to protect the control plane of Cisco IOS routers in your network. • Encryption policies: You can enforce security encryption policies that best fit your environment in IPsec site-to-site and remote access VPN tunnels. • Firewalls, packet filters, and ACLs: Firewalls, packet filters, and ACLs (including VLAN ACLs [VACLs] and policy-based ACLs in the Catalyst 6500) are the methods most commonly used to enforce security policies for segmentation and protection of network resources. • NAC policy enforcement: You can configure NAC Appliance and NAC Framework policies to ensure that only compliant machines can enter the network. Based on your configured policies, you can quarantine and remediate noncompliant machines. • Policy-based routing (PBR): You can also use PBR on routers and Layer 3 devices to define enforcement policies for traffic within your network.



	Visualization Techniques 203

	• Remotely triggered black holes (RTBH): In previous chapters, you learn how you can block attack traffic or infected hosts using RTBH. RTBH is another example of how you can reactively enforce policies within your network. Visualization Techniques This section includes a few examples of how you can create topology maps and other diagrams to visualize your network resources and apply SAVE. These diagrams give you the basic idea so that you can then customize the diagrams to fit your organizational needs. You can create circular diagrams like the one illustrated in Figure 7-17. Typically, these types of diagrams include resources that surround a critical system or area of the network you want to protect. In Figure 7-17, a cluster of database servers is illustrated in the center of the diagram. Several layers describe the devices in the topology in relation to different sections of the network. Figure 7-17 Topology Map Visualization



	204 Chapter 7: Proactive Security Framework

	The illustration in Figure 7-17 helps you visualize and understand the different layers of protection you can apply within your network to protect the mission-critical systems. The diagram in Figure 7-17 has four major sections that portray the path from and to the protected system and the following sections of the network: 1 Finance department users 2 Internet 3 Call Center 4 Branch Office in Los Angeles, California (LA) You can also visualize packet flows and understand how security policies can be applied to each network device to protect critical systems and the infrastructure as a whole. An example is illustrated in Figure 7-18. Figure 7-18 Traffic Flow Visualization



	Visualization Techniques 205

	Figure 7-18 illustrates an example of the packet flow when a user from the finance department accesses the Internet. There you can see the devices that these packets touch and the relation to the critical systems. You can identify where you can apply the technologies that belong to each SAVE pillar. For example, Figure 7-19 shows how you can apply technologies that enable you to gain and maintain visibility of what is happening in your network. Figure 7-19 Visibility Techniques Applied



	Figure 7-19 shows you how you can enable syslog on devices such as the switches, routers, FWSM for the Cisco Catalyst 6500 series switches, and Cisco ASA. It also shows you places where you want to enable NetFlow, IPS services, and other features. Figure 7-20 shows where you can enforce policies to restrict access.



	206 Chapter 7: Proactive Security Framework

	Figure 7-20 Policy Enforcement Visualization



	You can apply ACLs and IP inspection features on the Cisco ASA and the FWSM. In addition, you can apply VACLs on the access switches and antispoofing and infrastructure ACLs on the Internet router and other routers within the network. You can also enforce strict IPsec policies for the site-to-site connectivity between the main office and the branch office.

	NOTE	Antispoofing and infrastructure ACLs are discussed in Chapter 2, "Preparation Phase." Chapter 12, "Case Studies," also provides some examples within the case studies it covers.



	Summary 207

	You can also create similar diagrams to visualize where you can apply the technologies and features described on each of the pillars in SAVE. SAVE advocates the understanding of device roles and their appropriate configuration. For example, the Internet edge routers do not have the same role as the other routers within the topology in the previous examples. Despite that, Internet edge routers can be the same model and run the same software versions as other routers, and their configuration should be modeled after their role.

	NOTE The types of diagrams shown in Figures 7-18, 7-19, and 7-20 are not limited to only these technologies, features, and applications. You can customize them to your specific needs.

	Summary SAVE is a framework that was initially developed for service providers, but you can apply its practices to any organization. This chapter covers SAVE in detail. Examples of technologies within the six SAVE main categories are discussed. Visibility and control are two of the most important topics and concepts within SAVE. This chapter provides examples of techniques and practices that can allow you to gain and maintain visibility and control over the network during normal operations or during the course of a security incident or an anomaly in the network.

Cisco ASA FireWall

Chapter 12: Case Studies

Chapter 11: IPv6 Security

Chapter 10: Data Center Security

Chapter 9: IP Telephony Security

Chapter 8: Wireless Security

Chapter 7: Proactive Security Framework