Chapter 8: Security Services Design (Part01)

Overview

After completing this chapter, you will be able to

• Design security-intelligent network services for performance, scalability, and availability, given specified enterprise network needs

• Discuss design considerations for firewall services in the enterprise

• Describe design considerations for using network admission control services in the enterprise

• Discuss design considerations for intrusion-detection and -prevention services in the enterprise

As enterprises continually expand their mission-critical networks with new intranet, extranet, and e-commerce applications, network security is increasingly vital to prevent corruption and intrusion, and to eliminate network security vulnerabilities. Without precautions, enterprises could experience major security breaches, resulting in serious damages or loss.

This chapter examines security design in the enterprise. It will look at design considerations for firewall services, network admission control, and intrusion-detection and -prevention services. Readers should already know how to implement firewalls and security features such as access control lists (ACL), IP security (IPsec) connections, Network Address Translation (NAT), and Port Address Translation (PAT).

Designing Firewalls

Firewalls have long provided the first line of defense in network security infrastructures. They accomplish this by comparing corporate policies about network access rights for users to the connection information surrounding each access attempt. User policies and connection information must match; otherwise, the firewall does not grant access to network resources.

This section looks at firewall design considerations. It discusses options for firewall deployment and topologies, including firewall modes, virtual firewalls, asymmetric routing using active/active topologies, scaling firewall performance, private VLANs (PVLAN), and zone-based firewalls.

Firewall Modes

A firewall can run in either routed or transparent mode (see Figure 8-1).

Figure 8-1: Firewall Mode—Routed or Transparent

In the traditional routed mode, the firewall is considered to be a Layer 3 device in the network. It can perform NAT between connected networks. Routed mode supports many interfaces. Each interface is on a different subnet and requires an IP address on that subnet.

Transparent mode is a newer mode available as of Firewall Service Module (FWSM) Release 2.2 and Cisco ASA and PIX Firewall Software Version 7.0.

In transparent mode, the firewall is a Layer 2 device, not a router hop. Per context, the firewall connects the same network on its inside and outside interface in transparent mode.

Firewalls can support multiple pairs of inside and outside interfaces as a bridge group. Each bridge group connects to a different network. A transparent firewall has one IP address assigned to the entire bridge group, and uses this management address as the source address for packets originating on the firewall.

Transparent mode can allow certain types of traffic in an access list that is blocked by routed mode, including unsupported protocols. Routing protocol adjacencies are supported through a transparent firewall. Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), or Border Gateway Protocol (BGP) traffic is allowed based on an extended access list. Protocols such as Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), and IP multicast can be supported through a transparent firewall. Transparent mode can also optionally use ethertype access lists to allow non-IP traffic.

Note

This section primarily uses the FWSM as the example firewall. ASA and PIX devices could be used, too. ASA or PIX operational differences are illustrated in the chapter.

The PIX, ASA, and FWSM have different ACL mechanisms for controlling traffic:

• The PIX Firewall, by default, allows traffic to flow freely from an inside network (higher security level) to an outside network (lower security level).

• The ASA allows IPv4 traffic through the routed or transparent firewall mode automatically from a higher security interface to a lower security interface without an access list. ARPs are allowed through the transparent firewall in both directions without an access list. For Layer 3 traffic traveling from a lower security level interface to a high security level interface, an extended access list is required.

• The FWSM does not allow traffic to pass between interfaces unless it is explicitly permitted with an ACL. The only traffic allowed through the transparent firewall without an ACL is ARP traffic. Layer 3 traffic, such as IP traffic, cannot pass through the FWSM even though the transparent mode acts as a bridge, unless the traffic is explicitly permitted with an extended ACL.

Virtual Firewall Overview

A virtual firewall separates multiple firewall security contexts on a single firewall.

Specific VLANs are tied to a specific security context, as shown in Figure 8-2. In routed mode, up to 256 VLANs can be assigned to a context. The FWSM has an overall limit of 1000 VLAN interfaces divided among all contexts. Up to 250 contexts are supported on an FWSM depending on the software license. Each context has its own policies such as NAT, access lists, and protocol fixups.

Figure 8-2: Virtual Firewall Overview

The FSWM uses the administrative context for network management connectivity. Each context may also be managed individually as if they were distinct and separate firewalls. This granularity allows different groups to administer their own firewall. The system context is used to add VLANS, create contexts, and assign VLANs to contexts. With the default FWSM software, up to two security contexts (the administrative and system context) are provided.

Note

The FWSM does not include any external physical interfaces. VLAN interfaces are assigned to the FWSM in a way that is similar to how a switched virtual interface (SVI) is assigned to the Multilayer Switch Feature Card (MSFC). The FWSM includes an internal interface to the Switch Fabric Module (SFM) (if present) or to the shared bus.

Firewall Context Design Considerations

Resource classes are important to firewall operations because multiple contexts can use a resource class.

An attack or anomaly on one context can impact another context. All contexts belong to the default class if they are not assigned to another class, as illustrated in Figure 8-3. If a context belongs to a class other than the default class, those class settings always override the default class settings. However, if a class has any settings that are not defined, the member context uses the default class for those limits. By default, all security contexts have unlimited access to the resources of the FWSM or security appliance, except where maximum limits per context are enforced. If one or more contexts use too many resources, they cause other contexts to be denied connections. Resource management limits the use of resources per context.

Figure 8-3: Firewall Context Design Considerations

Note

The FWSM does not limit the bandwidth per context; however, the switch containing the FWSM can limit the bandwidth per VLAN.

The FWSM and security appliances manage resources by assigning contexts to resource classes. Each context uses the resource limits set by the class. If some resources are oversubscribed, or are unlimited, a few contexts can use up those resources, potentially affecting service to other contexts. As a recommended practice, set limits for all resources together as a percentage of the total available for the device, and set the limit for individual resources as a percentage or as an absolute value.

The FWSM and security appliances are subject to oversubscription if more than 100 percent of the resources are assigned across all contexts. For example, if the Bronze class is set to limit connections to 20 percent per context, and 10 contexts are assigned to the class, a total of 200 percent is allocated. If contexts concurrently use more than the system limit, each context gets less than the 20 percent you intended, and some connections will be denied because the system limit is reached.

MSFC Placement

The Multilayer Switch Feature Card can be placed on the inside or the outside of the firewall depending on the VLANs assigned to the FWSM.

In Figure 8-4, the MSFC is outside of the firewall when VLAN 200 is assigned to the outside interface of the FWSM. The FWSM processes and protects all traffic to the inside VLANs 2, 4, and 6. The MSFC routes between the Internet and the switched networks. Placing the MSFC outside the FWSM makes design and management easier.

Figure 8-4: MSFC Placement

The MSFC is inside of the firewall when VLAN 101 is assigned to the outside interface of the FWSM. The MSFC routes between VLANs 201, 5, 7, and 9. No inside traffic goes through the FWSM unless it is destined for the Internet. The FWSM secures the MSFC.

For multiple context mode, if the MSFC is placed inside the FWSM, it should connect to only a single context. If the MSFC connects to multiple firewall contexts, the MSFC will route between the contexts, which might not be your intention.

Active/Active Firewall Topology

The active/active firewall topology uses two firewalls that are both actively providing firewall services.

When an FWSM is running in virtual firewall mode, it is possible to use active/active redundancy. In the active/active topology, the security contexts on the FWSM are divided into failover groups. A failover group is a logical group of one or more security contexts. The FWSM supports a maximum of two failover groups. The administrative context is always a member of failover group 1, and any unassigned security contexts are, by default, also members of failover group 1.

In Figure 8-5, FWSM 1 and FWSM 2 are each configured with two failover groups. FSWM 1 is active for group 1 and standby for group 2. FSWM 2 is active for group 2 and standby for group 1. The first virtual firewall is mapped to group 1, and the second virtual firewall is mapped to group 2.

Figure 8-5: Active/Active Firewall Topology

Active/Active Topology Features

The active/active failover configuration requires two identical FWSMs connected to each other through a failover link associated with a dedicated VLAN and optionally a state-link VLAN using an interchassis design.

Note

The active/active failover configuration can also be supported with redundant FWSM in a single chassis. The failover link is a VLAN.

Note

All information sent over the failover and stateful failover links is sent in clear text. If FWSM is used to terminate VPN tunnels, this information includes any usernames, passwords, and preshared keys used for establishing the tunnels. Cisco recommends securing the failover communication with a failover key.

The health of the active interfaces and units is monitored to determine whether specific failover conditions are met. If those conditions are met, failover occurs. The MAC address of the primary unit is used by all interfaces in the active contexts. When an active failover group fails, it changes to the standby state and the associated standby failover group becomes active. The interfaces in the failover group that becomes active assume the MAC address and IP addresses of the interfaces in the failover group that failed.

This design supports preemption so that the FWSM with a higher priority will resume an active role after recovering from a failure condition.

Additional redundancy is supported if links from separate modules are used to form the Gigabit Ethernet EtherChannels supporting the failover trunk and state traffic VLANs.

Both devices can pass network traffic in an active/active topology; this design is capable of supporting load balancing in the network.

Asymmetric Routing with Firewalls

The FWSMs support asymmetric routing where return traffic for a session is received through a different interface than the interface from which the traffic originated.

Asymmetric routing most commonly occurs when two interfaces on a single FWSM, or two FWSMs in a failover pair, are connected to different service providers and the outbound connection does not use a NAT address. By default, the FWSM drops the return traffic because there is no connection information for the traffic received through a different interface than the interface where the traffic originated.

Asymmetric routing of the return traffic is supported by using the asr-group interface command. The FSWM supports up to 32 asymmetric routing (ASR) groups. Each ASR group supports a maximum of eight interfaces. Asymmetric routing is supported in the active/active failover redundancy mode, and in designs without failover redundancy in either single mode or within a virtual firewall by using ASR groups. Asymmetric routing is supported in both the routed and transparent modes of firewall operation.

Asymmetric Routing with ASR Group on a Single FWSM

Interfaces inside a common ASR group allow packets belonging to a given session to enter and leave from any interface within the ASR group, as shown in Figure 8-6.

Figure 8-6: Asymmetric Routing with ASR Groups on a Single FWSM

When an interface configured with the asr-group command receives a packet for which it has no session information, it checks the session information for the other interfaces that are in the same group. If it does not find a match, the packet is dropped. If it finds a match and the incoming traffic originated on a different interface on the same unit, some or the entire Layer 2 header is rewritten and the packet is re-injected into the stream and forwarded to the intended host.

After valid synchronization (SYN) is sent out an ASR group interface, the FWSM will accept a returning synchronization-acknowledgment (SYN ACK) on another interface in the ASR group.

Asymmetric Routing with Active/Active Topology

Interfaces inside a common ASR group in an active/active topology also support asymmetric routing.

In the active/active topology, when an interface configured with the asr-group command receives a packet for which it has no session information, it checks the session information for the other interfaces that are in the same group. If it does not find a match, the packet is dropped. If it finds a match and the incoming traffic originated on a peer unit that was active for the context, some or all of the entire Layer 2 header is rewritten and the packet is redirected to the active peer.

Figure 8-7 shows that the traffic is forwarded though the outside interface of context A on the unit where context A is in the standby state and returns through the outside interface of context A on the unit where context A is in the active state. This redirection continues as long as the session is active.

Figure 8-7: Asymmetric Routing with Active/Active Topology