Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide, 4.0
Introduction to the Firewall Services Module
Downloads: This chapterpdf (PDF - 425.0KB) The complete bookPDF (PDF - 4.66MB) | Feedback

Introduction to the Firewall Services Module

Table Of Contents

Introduction to the Firewall Services Module

New Features

New Features in Release 4.0(4)

New Features in Release 4.0(3)

New Features in Release 4.0(2)

New Features in Release 4.0(1)

Security Policy Overview

Permitting or Denying Traffic with Access Lists

Applying NAT

Protecting from IP Fragments

Using AAA for Through Traffic

Applying Internet Filtering

Applying Application Inspection

Applying Connection Limits

How the Firewall Services Module Works with the Switch

Using the MSFC

Firewall Mode Overview

Stateful Inspection Overview

Security Context Overview


Introduction to the Firewall Services Module


The FWSM is a high-performance, space-saving, stateful firewall module that installs in the Catalyst 6500 series switches and the Cisco 7600 series routers.

Firewalls protect inside networks from unauthorized access by users on an outside network. The firewall can also protect inside networks from each other, for example, by keeping a human resources network separate from a user network. If you have network resources that need to be available to an outside user, such as a web or FTP server, you can place these resources on a separate network behind the firewall, called a demilitarized zone (DMZ). The firewall allows limited access to the DMZ, but because the DMZ includes only the public servers, an attack there affects only the servers and does not affect the other inside networks. You can also control when inside users access outside networks (for example, access to the Internet), by allowing only certain addresses out, by requiring authentication or authorization, or by coordinating with an external URL filtering server.

The FWSM includes many advanced features, such as multiple security contexts (similar to virtualized firewalls), transparent (Layer 2) firewall or routed (Layer 3) firewall operation, hundreds of interfaces, and many more features.

When discussing networks connected to a firewall, the outside network is in front of the firewall, the inside network is protected and behind the firewall, and a DMZ, while behind the firewall, allows limited access to outside users. Because the FWSM lets you configure many interfaces with varied security policies, including many inside interfaces, many DMZs, and even many outside interfaces if desired, these terms are used in a general sense only.

This chapter includes the following sections:

New Features

Security Policy Overview

How the Firewall Services Module Works with the Switch

Firewall Mode Overview

Stateful Inspection Overview

Security Context Overview

New Features

This section lists new features for each maintenance release, and includes the following topics:

New Features in Release 4.0(4)

New Features in Release 4.0(3)

New Features in Release 4.0(2)

New Features in Release 4.0(1)

New Features in Release 4.0(4)

The following Cisco IOS-integrated features are now officially supported in FWSM:

Feature
Description

PISA integration

Note This feature depends on Cisco IOS Release 12.2(18)ZYA or later, and is only available on the Catalyst 6500 switch.

The FWSM can leverage the high-performance deep packet inspection of the PISA card so that it can permit or deny traffic based on the application type.

Route Health Injection

Note This feature depends on Cisco IOS Release 12.2(33)SXI or later, and is only available on the Catalyst 6500 switch.

Route Health Injection is used for injecting the connected and static routes and NAT pools configured on the FWSM into the MSFC routing table on a per context basis. MSFC can then redistribute the route or NAT pools to other router routing tables.

Virtual Switching System (VSS) support

Note This feature depends on Cisco IOS Release 12.2(33)SXI or later, and is only available on the Catalyst 6500 switch.

VSS is a system virtualization technology that allows the pooling of multiple Catalyst 6500 switches into a single virtual switch. If you have the FWSM installed, FWSM traffic benefits from this feature. There is no configuration on the FWSM required.


New Features in Release 4.0(3)

The SCCP (Skinny) inspection has been enhanced to do the following:

Support registrations of SCCP version 17 phones.

Support SCCP version 17 media related messages for opening up pinholes for video/audio streams.

The following is not supported:

Registrations of endpoints that have IPv6 addresses. The Register messages are dropped and a debug message is generated.

If IPv6 messages are embedded in the SCCP messages, they are not NATed or PATed; they are left untranslated.

New Features in Release 4.0(2)

There were no new features in Release 4.0(2).

New Features in Release 4.0(1)

Table 1 lists the new features for Release 4.0(1).

Table 1 New Features for FWSM Release 4.0(1) 

Feature
Description
Routing
 

EIGRP

The following EIGRP features are supported in this release:

Summarization

Stub-routing

Route filtering

Manual Route summarization

Redistribution

Static route monitoring

If you configure multiple static routes to reach a network, the route monitoring feature can detect if a network goes down so that the next best route can be used.

DHCP
 

DHCP Option 82 support

When the switch is acting as relay agent, to interoperate with HSRP, the FWSM will preserve the Option 82 field set up by the switch.

Modular Policy Framework
 

Inspection policy maps and class maps

The following protocols support inspection policy and/or class maps:

DCERPC

ESMTP

HTTP

SIP

Regular expressions and regular expression class maps

You can create regular expressions and regular expression class maps for use in an inspection policy map or class map.

Filtering
 

HTTPS support with Secure Computing SmartFilter

The FWSM now supports HTTPS filtering using Secure Computing SmartFilter.

Adding the context name to Websense version 4 requests

Because Websense requests initiated from the FWSM use the pre-NATted IP address of clients, which can be overlapping, this can lead to problems in defining policies in the Websense server. Adding the context name to Websense queries lets the Websense server use the context name for policy lookups.

Application Inspection
 

DNS Guard configurability

You can now disable DNS Guard at the CLI.

SIP inspection enhancements

Numerous enhancements were added.

You can now use an inspection policy map to configure special actions for inspection traffic; this method replaces the application map.

HTTP inspection enhancements

Numerous enhancements were added.

You can now use an inspection policy map to configure special actions for inspection traffic; this method replaces the application map.

ESMTP inspection enhancements

Numerous enhancements were added.

You can now use an inspection policy map to configure special actions for inspection traffic; this method replaces the application map.

DCERPC inspection enhancements

Numerous enhancements were added.

You can now use an inspection policy map to configure special actions for inspection traffic; this method replaces the application map.

Access Lists
 

Customizable memory partition sizes

In multiple context mode, you can change the size of memory partitions for rule use, so you can reallocate memory from one partition to another.

Rule reallocation per feature per partition

You can reallocate rules between features on a per-partition basis instead of just globally.

Access list optimization

The access list group optimization feature reduces the number of ACEs per group by merging and/or deleting redundant and conflicting ACEs without affecting the semantics of the access list.

Connections and Switch Integration
 

Connection rate limiting

You can limit the connection rate for TCP and UDP traffic.

Monitoring
 

New SNMP MIBs

For ACL entries and ACL hit counters (CISCO-IP-PROTOCOL-FILTER-MIB), and ARP table entries (IP-MIB).


Security Policy Overview

A security policy determines which traffic is allowed to pass through the firewall to access another network. The FWSM does not allow any traffic to pass through unless explicitly allowed by an access list. You can apply actions to traffic to customize the security policy. This section discusses some commonly-used features; not all features are listed here. This section includes the following topics:

Permitting or Denying Traffic with Access Lists

Applying NAT

Protecting from IP Fragments

Using AAA for Through Traffic

Applying Internet Filtering

Applying Application Inspection

Applying Connection Limits

Permitting or Denying Traffic with Access Lists

You can apply an access list to allow traffic through an interface. For transparent firewall mode, you can also apply an EtherType access list to allow non-IP traffic.

Applying NAT

Some of the benefits of NAT include the following:

You can use private addresses on your inside networks. Private addresses are not routable on the Internet.

NAT hides the local addresses from other networks, so attackers cannot learn the real address of a host.

NAT can resolve IP routing problems by supporting overlapping IP addresses.

Protecting from IP Fragments

The FWSM provides IP fragment protection. This feature performs full reassembly of all ICMP error messages and virtual reassembly of the remaining IP fragments that are routed through the FWSM. Fragments that fail the security check are dropped and logged. Virtual reassembly cannot be disabled.

Using AAA for Through Traffic

You can require authentication and/or authorization for certain types of traffic, for example, for HTTP. The FWSM also sends accounting information to a RADIUS or TACACS+ server.

Applying Internet Filtering

Although you can use access lists to prevent outbound access to specific websites or FTP servers, configuring and managing web usage this way is not practical because of the size and dynamic nature of the Internet. We recommend that you use the FWSM in conjunction with a separate server running one of the following Internet filtering products:

Websense Enterprise

Sentian by N2H2

Applying Application Inspection

Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports. These protocols require the FWSM to perform a deep packet inspection.

Applying Connection Limits

You can limit TCP and UDP connections and embryonic connections. Limiting the number of connections and embryonic connections protects you from a DoS attack. The FWSM uses the embryonic limit to trigger TCP Intercept, which protects inside systems from a DoS attack perpetrated by flooding an interface with TCP SYN packets. An embryonic connection is a connection request that has not finished the necessary handshake between source and destination.


Note When you use TCP SYN cookie protection to protect servers from SYN attacks, you must set the embryonic connection limit lower than the TCP SYN backlog queue on the server that you want to protect. Otherwise, valid clients can nolonger access the server during a SYN attack.


How the Firewall Services Module Works with the Switch

You can install the FWSM in the Catalyst 6500 series switches and the Cisco 7600 series routers with Cisco IOS software on both the switch supervisor and the integrated MSFC (known as "supervisor IOS").


Note The Catalyst Operating System (OS) is not supported.


The FWSM runs its own operating system.

Using the MSFC

The switch includes a switching processor (the supervisor) and a router (the MSFC). Although you need the MSFC as part of your system, you do not have to use it. If you choose to do so, you can assign one or more VLAN interfaces to the MSFC (if your switch software version supports multiple SVIs; see Table A-1 on page A-2). In single context mode, you can place the MSFC in front of the firewall or behind the firewall (see Figure 1-1).

The location of the MSFC depends entirely on the VLANs that you assign to it. For example, the MSFC is behind the firewall in the example shown on the left side of Figure 1-1 because you assigned VLAN 201 to the inside interface of the FWSM. The MSFC is in front of the firewall in the example shown on the right side of Figure 1-1 because you assigned VLAN 200 to the outside interface of the FWSM.

In the left-hand example, the MSFC routes between VLANs 201, 301, 302, and 303, and no inside traffic goes through the FWSM unless it is destined for the Internet. In the right-hand example, the FWSM processes and protects all traffic between the inside VLANs 201, 202, and 203.

Figure 1-1 MSFC Placement

For multiple context mode, if you place the MSFC behind the FWSM, you should only connect it to a single context. If you connect the MSFC to multiple contexts, the MSFC will route between the contexts, which might not be your intention. The typical scenario for multiple contexts is to use the MSFC in front of all the contexts to route between the Internet and the switched networks (see Figure 1-2).

Figure 1-2 MSFC Placement with Multiple Contexts

Firewall Mode Overview

The FWSM runs in two different firewall modes:

Routed

Transparent

In routed mode, the FWSM is considered to be a router hop in the network.

In transparent mode, the FWSM acts like a "bump in the wire," or a "stealth firewall," and is not considered a router hop. The FWSM connects to the same network on its inside and outside interfaces. You can configure up to eight pairs of interfaces (called bridge groups) to connect to eight different networks, per context.

You might use a transparent firewall to simplify your network configuration. Transparent mode is also useful if you want the firewall to be invisible to attackers. You can also use a transparent firewall for traffic that would otherwise be blocked in routed mode. For example, a transparent firewall can allow unsupported routing protocols.

In multiple context mode, you can choose the mode for each context independently, so some contexts can run in transparent mode while others can run in routed mode.

Stateful Inspection Overview

All traffic that goes through the firewall is inspected using the Adaptive Security Algorithm and is either allowed through or dropped. A simple packet filter can check for the correct source address, destination address, and ports, but it does not check that the packet sequence or flags are correct. A filter also checks every packet against the filter, which can be a slow process.


Note The following feature allows you to customize the packet flow: "Configuring TCP State Bypass" section on page 20-10.


A stateful firewall like the FWSM, however, takes into consideration the state of a packet:

Is this a new connection?

If it is a new connection, the firewall has to check the packet against access lists and perform other tasks to determine if the packet is allowed or denied. To perform this check, the first packet of the session goes through the "session management path," and depending on the type of traffic, it might also pass through the "control plane path."


Note The first packet for a session cannot be comprised of fragments for a packet that is larger than 8500 Bytes. The session will be established, but only the first 8500 Bytes will be sent out. Subsequent packets for this session are not affected by this limitation.


The session management path is responsible for the following tasks:

Performing the access list checks

Performing route lookups

Allocating NAT translations (xlates)

Establishing sessions in the "accelerated path"

Some packets that require Layer 7 inspection (the packet payload must be inspected or altered) are passed on to the control plane path. Layer 7 inspection engines are required for protocols that have two or more channels: a data channel, which uses well-known port numbers, and a control channel, which uses different port numbers for each session. These protocols include FTP, H.323, and SNMP.


Note The FWSM performs session management path and accelerated path processing on three specialized networking processors. The control plane path processing is performed in a general-purpose processor that also handles traffic directed to the FWSM and configuration and management tasks.


Is this an established connection?

If the connection is already established, the firewall does not need to recheck packets; most matching packets can go through the accelerated path in both directions. The accelerated path is responsible for the following tasks:

IP checksum verification

Session lookup

TCP sequence number check

NAT translations based on existing sessions

Layer 3 and Layer 4 header adjustments

For UDP or other connectionless protocols, the FWSM creates connection state information so that it can also use the accelerated path.

Data packets for protocols that require Layer 7 inspection can also go through the accelerated path.

Some established session packets must continue to go through the session management path or the control plane path. Packets that go through the session management path include HTTP packets that require inspection or content filtering. Packets that go through the control plane path include the control packets for protocols that require Layer 7 inspection.


Note For QoS compatibility, the FWSM preserves the DSCP bits for all traffic that passes through the FWSM.


Security Context Overview

You can partition a single FWSM into multiple virtual devices, known as security contexts. Each context has its own security policy, interfaces, and administrators. Multiple contexts are similar to having multiple standalone devices. Many features are supported in multiple context mode, including routing tables, firewall features, and management. Some features are not supported, including dynamic routing protocols.

In multiple context mode, the FWSM includes a configuration for each context that identifies the security policy, interfaces, and almost all the options you can configure on a standalone device. The system administrator adds and manages contexts by configuring them in the system configuration, which, like a single mode configuration, is the startup configuration. The system configuration identifies basic settings for the FWSM. The system configuration does not include any network interfaces or network settings for itself; rather, when the system needs to access network resources (such as downloading the contexts from the server), it uses one of the contexts that is designated as the admin context.

The admin context is just like any other context, except that when a user logs in to the admin context, then that user has system administrator rights and can access the system and all other contexts.


Note Multiple context mode supports static routing only.