| In this scenario, you enhance the security of a DMZ segment that is used to provide public access from the Internet for web content and Internet e-mail. The DMZ architecture used in this scenario is a very common architecture in use today, so learning how to secure the segment gives you valuable real world experience. Scenario Exercise Figure 8-20 illustrates the scenario topology used for this scenario. Figure 8-20. Topology 
Corporation XYZ is providing public Internet access for the two external web sites on a DMZ segment, as shown in Figure 8-20. Hosts MARS and VENUS are Windows 2000 web servers. Corporation XYZ wants to provide as much security as possible for this segment and also wants to restrict communications between hosts on the DMZ segment. The following access control policy must be implemented: The DMZ hosts must reside in the same IP subnet, but cannot directly communicate with each other. The DMZ hosts must accept inbound HTTP connections. The DMZ hosts must be able to issue echo requests and DNS queries to any external network. All other access to/from the DMZ hosts must be blocked.
Scenario Objectives The scenario objectives are as follows: Configure private VLANs to prevent communications between hosts on the same IP subnet Configure VLAN access control lists (ACLs) to provide access control of traffic flowing between hosts in the same VLAN
Equipment Needed The equipment needed is as follows: One CatOS Catalyst 6000/6500 switch One Cisco IOS router with at least one Ethernet interface The two hosts in this example are not required, but to verify the objectives you need these two hosts present.
Scenario Planning Private VLANs are an excellent security feature that allows you to reduce the number of VLANs required to implement access control in the network. By restricting access between devices on the same VLAN (IP subnet), you reduce the need for firewalls with multiple interfaces and the complexity of your firewall security policy. Because the switch provides isolation between devices rather than the firewall, this leaves the firewall free to perform other security functions. When planning a private VLAN architecture you need to consider the following: Which devices require isolation? Which devices are to be connected to promiscuous ports? Do you have a group of devices that require connectivity within the group, but isolation from the remaining hosts on a segment?
In this scenario, you have two hosts that require isolation from each other. Rather than placing these hosts in separate VLANs and using multiple physical or virtual interfaces on a firewall device to restrict access between the two hosts, you attach each host to an isolated port that can communicate only with the a promiscuous port which connects the firewall. Straight away, you have isolated each host, and even though they are on the same logical IP subnet, they cannot communicate. One way to bypass the security of private VLANs is to add static host routes on each host, directing frames for another isolated host to the promiscuous port router/firewall, rather than trying to send the frame directly. You can circumvent this issue by using traffic filtering on either the router/firewall or the switch. In this scenario, you use VLAN access control lists on the switch to prevent this. Command Syntax This section describes the commands used for configuring private VLANs and VLAN access control lists on the Catalyst 6000/6500 series switches. The following commands are introduced in this scenario: The set vlan vlan-id pvlan-type Command When creating private VLANs, you create the following types of VLANs to implement your required security configuration: Primary VLAN Isolated VLAN Community VLAN
You use the set vlan vlan-id pvlan-type command to create a new VLAN and assign it the appropriate private VLAN role: set vlan vlan-id pvlan-type {primary | isolated | community | twoway-community}
The set pvlan Command Once you have created your private VLANs, you must now perform the following tasks: To assign ports to isolated/community VLANs, you use the set pvlan command: set pvlan primary-vlan-id secondary-vlan-id {mod/port | sc0}
The mod/port parameter represents the isolated or community port, and you must repeat the command for each secondary VLAN. Once primary and secondary VLANs have been created, you use the set pvlan mapping command to associate secondary VLANs with a primary VLAN and promiscuous port: set pvlan mapping primary-vlan-id {isolated-vlan | community-vlan} mod/port
The mod/port parameter represents the promiscuous port, and you must repeat the command for each secondary VLAN. The set security acl Command The set security acl command is used to create VLAN access control lists (VACLs). VACLs allow you to filter upon Layer 3 and Layer 4 parameters and are applied for all inbound access on the entire VLAN. Although very similar to router ACLs, VACLs can be applied only in the inbound direction and can also filter traffic switched within a VLAN. The following tasks are required to configure VACLs: To create a VACL for IP traffic, you use the set security acl ip command: set security acl ip acl-name {permit | deny} {ip | tcp | udp} source destination
Example 8-57 shows a VACL called EXAMPLE that filters on IP UDP and TCP traffic. Example 8-57. VACL Example Switch> (enable) set security acl ip EXAMPLE permit ip host 10.1.1.1 any Switch> (enable) set security acl ip EXAMPLE permit tcp 10.1.1.0 0.0.0.255 any eq 80 Switch> (enable) set security acl ip EXAMPLE permit udp 10.1.1.0 0.0.0.255 any eq 53 Switch> (enable) set security acl ip EXAMPLE deny ip any any
Once you have created your VACL, you need to commit the VACL to the Policy Feature Card (PFC), PFC2 or PFC3 on the Catalyst 6000/6500 Supervisor using the commit security acl command: commit security acl {vacl-name | all}
Finally, you apply the VACL to a particular VLAN using the set security acl map command: set security acl map vacl-name vlan
Configuration Tasks The following steps are required to successfully perform the scenario configuration: Step 1 Prepare the switch and router Step 2 Configure private VLANs and VLAN ACLs Step 3 Confirm the desired access control has been achieved
Step 1 Preparing the Switch and Router In this step, you: - Configure the system name and IP parameters of the switch
- Configure the router (IP addressing only required)
- Provide connectivity for the router and hosts
Configuring the System Name and IP Parameters of the Switch Configuring the system name and IP parameters of the switch is done as follows: Step 1. | On the switch, configure the system name, prompt, an IP address of 192.168.10.2/24, and the appropriate default route, as shown in Example 8-58.
Example 8-58. Configuring Basic Parameters on XYZSW1 Console enable Enter password: ***** Console (enable) set system name XYZSW3 System name set. XYZSW3 (enable) set interface sc0 192.168.10.2 255.255.255.0 XYZSW3 (enable) set ip route default 192.168.10.1 Route added.
|
Configuring the Router Do the following to configuring the router: Step 1. | On the router, configure the system name (XYZR1), Ethernet interfaces, loopback interfaces, and the appropriate IP addressing, as shown in Example 8-59. Refer to Figure 8-20 for the correct IP addressing.
Example 8-59. Configuring the router Router(config)# hostname XYZR1 XYZR1(config)# interface ethernet0 XYZR1(config-if)# no shutdown XYZR1(config-if)# ip address 192.168.10.1 255.255.255.0 XYZR1(config-if)# interface loopback0 XYZR1(config-if)# ip address 192.168.1.1 255.255.255.0 XYZR1(config-if)# interface loopback1 XYZR1(config-if)# ip address 192.168.100.1 255.255.255.0
|
Providing Connectivity for the Router Step 1. | On XYZSW3, configure port 2/1 as 10 Mbps half-duplex and ports 2/2-3 as 100Mbps full-duplex, also naming each port appropriately.
| Step 2. | Connect the router and hosts with the appropriate cabling to the switch. After at least 30 seconds, ensure that you can ping all hosts and all interfaces on the router as demonstrated in Example 8-60.
Example 8-60. Confirming Connectivity XYZSW3> (enable) ping 192.168.10.1 !!!!! XYZSW3> (enable) ping 192.168.10.10 !!!!! XYZSW3> (enable) ping 192.168.10.11 !!!!! XYZSW3> (enable) ping 192.168.1.1 !!!!! XYZSW3> (enable) ping 192.168.100.1 !!!!!
|
NOTE Try pinging MARS from VENUS or vice versa. Notice that you are able to ping each other because this is normal behavior when both hosts are in the same VLAN, on the same IP subnet with a switch interconnecting the devices. The goal of this scenario is to prevent this intra-VLAN communication using the switch.
Step 2 Configuring Private VLANs and VLAN ACLs In this step you: - Configure the required VLANs to implement private VLANs
- Configure the appropriate VLAN ACLs to enforce the required access control
Configuring the Required VLANs to Implement Private VLANs Figure 8-21 illustrates the VLANs that you use to implement private VLANs. Figure 8-21. Private VLANs Used for Scenario 8-4 
VLAN 100 is designated as the primary VLAN, to which any promiscuous ports are assigned. VLAN 200 is designated as a secondary VLAN, to which any isolated ports are assigned. You assign the server ports and the management interface port sc0 to the isolated VLAN. This ensures the hosts cannot communicate with each other and also cannot communicate with the switch IP address (if you assigned the sc0 interface to the primary VLAN, it is designated as a promiscuous port and, hence, would be open to communications from the isolated ports). NOTE In production environments, the switch management interface should not be placed on the same VLAN as users or servers, especially where security is critical.
Step 1. | The switch must operate in VTP transparent mode to support private VLANs, so configure this first. Next, create the primary VLAN (100) on XYZSW3, assigning it a private VLAN type of primary, as shown in Example 8-61.
Example 8-61. Creating the Primary VLAN on XYZSW3 XYZSW3> (enable) set vtp mode transparent VTP domain modified XYZSW3> (enable) set vlan 100 pvlan-type primary Vlan 100 configuration successful
| Step 2. | Create the secondary VLAN (200) on XYZSW3 assigning it a private VLAN type of isolated and assign ports 2/2 and 2/3 to the isolated VLAN. Also assign the management interface sc0 to the isolated VLAN, as shown in Example 8-62.
Example 8-62. Creating the Secondary (Isolated) VLAN on XYZSW3 XYZSW3> (enable) set vlan 200 pvlan-type isolated Vlan 200 configuration successful XYZSW3> (enable) set pvlan 100 200 2/2-3 Successfully set the following ports to Private Vlan 100,200: 2/2-3 XYZSW3> (enable) set pvlan 100 200 sc0 Successfully set the following ports to Private Vlan 100,200: sc0
| Step 3. | Map the secondary (isolated) VLAN to the primary VLAN on the promiscuous port, as shown in Example 8-63.
Example 8-63. Mapping the Secondary (Isolated) VLAN to the Primary VLAN Promiscuous Port 2/1 XYZSW3> (enable) set pvlan mapping 100 200 2/1 Successfully set mapping between 100 and 200 on 2/1
| Step 4. | Verify your private VLAN configuration by using the show pvlan command, as shown in Example 8-64.
Example 8-64. Verifying the Private VLAN Configuration XYZSW3> (enable) show pvlan Primary Secondary Secondary-Type Ports ------- --------- -------------- ------------ 100 200 isolated 2/2-3, sc0 XYZSW3> (enable) show pvlan mapping Port Primary Secondary ----- -------- ---------- 2/1 100 200
|
The first show pvlan command verifies which ports are isolated, while the second show pvlan mapping command shows the promiscuous ports. Step 5. | Verify that the private VLANs are working as desired by performing the same ping tests described in Example 8-60.
|
Configuring the Appropriate VLAN ACLs to Enforce the Required Access Control You now configure VACLs to provide the required access control on the switch, enhancing the overall security of the architecture. You configure a VACL on the primary VLAN and a VACL on the secondary VACL. The VACL on the primary VLAN is used to prevent the hosts on the DMZ from routing local traffic (e.g., traffic from MARS to VENUS) to the router to bypass the private VLAN security. The VACL on the secondary VLAN is used to restrict the services that are allowed for each host. In this scenario, you allow only HTTP and Domain Name System (DNS) traffic. Step 1. | Configure a VACL for the primary VLAN called PROTECT-DMZ on XYZSW3, as shown in Example 8-65.
Example 8-65. Creating the VACL for the Primary VLAN XYZSW3> (enable) set security acl ip PROTECT-DMZ permit ip host 192.168.10.1 192.168.10.0 0.0.0.255 XYZSW3> (enable) set security acl ip PROTECT-DMZ deny ip 192.168.10.0 0.0.0.255 192.168.10.0 0.0.0.255 XYZSW3> (enable) set security acl ip PROTECT-DMZ permit ip any 192.168.10.0 0.0.0.255
|
This VACL allows the router to communicate with the DMZ segment, then prevents any hosts on the DMZ from routing local traffic via the router, and then allows the DMZ hosts to communicate with remote networks. Note the importance of the ordering of the VACL. TIP This VACL is applied to traffic coming from the router only. Traffic from the hosts is not filtered as you might expect (VACLs normally filter inbound traffic to the VLAN), because the VACL is not applied when the secondary to primary VLAN mapping is performed. The reverse applies for the secondary VACL (i.e., only traffic from the hosts is filtered).
Step 2. | Configure a secondary VACL called DMZ-OUT on XYZSW3, as shown in Example 8-66.
Example 8-66. Creating the Secondary VACL XYZSW3> (enable) set security acl ip DMZ-OUT deny icmp any any fragment XYZSW3> (enable) set security acl ip DMZ-OUT permit tcp host 192.168.10.10 eq 80 any established XYZSW3> (enable) set security acl ip DMZ-OUT permit tcp host 192.168.10.11 eq 80 any established XYZSW3> (enable) set security acl ip DMZ-OUT permit udp host 192.168.10.10 any eq 53 XYZSW3> (enable) set security acl ip DMZ-OUT permit udp host 192.168.10.11 any eq 53 XYZSW3> (enable) set security acl ip DMZ-OUT permit icmp host 192.168.10.10 any echo XYZSW3> (enable) set security acl ip DMZ-OUT permit icmp host 192.168.10.11 any echo
|
This VACL enforces the access control policy for the DMZ. This configuration can be much more effective than filtering on a firewall or router because VACL filtering is performed at wire speed and any dropped packets have no effect on performance (which means denial-of-service attacks can't bring down the switch). Step 3. | Commit the VACLs to hardware and bind them to the appropriate VLANs, as shown in Example 8-67.
Example 8-67. Committing and Binding the VACLs XYZSW3> (enable) commit security acl all ACL commit in progress. ACL PROTECT-DMZ is committed to hardware. ACL DMZ-OUT is committed to hardware. XYZSW3> (enable) set security acl map PROTECT-DMZ 100 ACL PROTECT-DMZ mapped to vlan 100 XYZSW3> (enable) set security acl map DMZ-OUT 200 ACL DMZ-OUT mapped to vlan 200
|
Step 3 Confirm the Desired Access Control Has Been Achieved The final task is to confirm that you have implemented the correct access control policy. Perform the following traffic tests to verify your configuration: Step 1. | Verify that you can ping all router interfaces from both MARS and VENUS, as shown in Example 8-68 (this verifies that your secondary VACL is allowing outbound ICMP echo requests).
Example 8-68. Pinging XYZR1 Interfaces from MARS M:\>ping 192.168.10.1 Pinging 192.168.10.1 with 32 bytes of data: Reply from 192.168.10.1: bytes=32 time<1ms TTL=255 ... M:\>ping 192.168.1.1 Pinging 192.168.1.1 with 32 bytes of data: Reply from 192.168.1.1: bytes=32 time<1ms TTL=255 ... M:\>ping 192.168.100.1 Pinging 192.168.100.1 with 32 bytes of data: Reply from 192.168.100.1: bytes=32 time<1ms TTL=255 ...
| Step 2. | Verify that you cannot ping MARS from VENUS and vice versa, as shown in Example 8-69 (this indicates that your private VLAN configuration is working).
Example 8-69. Pinging VENUS from MARS M:\>ping 192.168.10.11 Pinging 192.168.10.11 with 32 bytes of data: Request timed out. Request timed out. Request timed out.
| Step 3. | Add a static route on both MARS and VENUS, which routes traffic for the other DMZ host to the router IP address on the DMZ segment (192.168.10.1). For example, on MARS you would add a route defining VENUS (192.168.10.11) as being reachable via XYZR1 (192.168.10.1). Now verify that you still cannot ping MARS from VENUS and vice versa, as shown in Example 8-70 (this indicates that your primary VACL is working).
Example 8-70. Adding a Static Route on MARS and Pinging VENUS from MARS M:\>route add 192.168.10.11 mask 255.255.255.0 192.168.10.1 M:\>ping 192.168.10.11 Pinging 192.168.10.11 with 32 bytes of data: Request timed out. Request timed out. Request timed out.
| Step 4. | Verify that you can Telnet to MARS and VENUS on port 80 from the router XYZR1, using a source interface address of loopback 1, as shown in Example 8-71 (this verifies that your secondary VACL is allowing the appropriate access). Press Enter a few times once you have connected to get the HTTP Bad Request output shown.
Example 8-71. Verifying HTTP Connectivity to MARS from XYZR1 XYZR1# telnet 192.168.10.10 80 /source-interface loopback 1 HTTP/1.1 400 Bad Request Server: Microsoft-IIS/5.1 Date: Sun, 03 Feb 2002 12:03:10 GMT Content-Type: text/html Content-Length: 87 <html><head><title>Error</title></head><body>The parameter is incorrect. </body> </html>
| Step 5. | Verify that you cannot perform an extended ping to MARS and VENUS from the router XYZR1 using a source interface address of loopback 1, as shown in Example 8-72 (this verifies that your secondary VACL is blocking any unauthorized services).
Example 8-72. Verifying ICMP Traffic Is Dropped to MARS from XYZR1 XYZR1# ping ip Target IP Address: 192.168.10.10 Repeat Count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.100.1 ... Sending 5, 100-byte ICMP Echos to 192.168.10.10, timeout is 2 seconds: ..... Success rate is 0 percent (0/5), round-trip min/avg/max = 0/0/0 ms
|
| 