Table Of Contents
Introduction to the Firewall Services Module
New Features by Platform Release
New Features in Release 4.0(1)
New Features in Release 3.2(1)
New Feature in Release 3.1(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 by Platform Release
•
Security Policy Overview
•
How the Firewall Services Module Works with the Switch
•
Firewall Mode Overview
•
Stateful Inspection Overview
•
Security Context Overview
New Features by Platform Release
This section lists the new features available in each supported platform release. Because ASDM supports multiple platform releases, and this guide includes features for all releases, you should refer to these sections to determine if a feature is in your release. This section includes the following topics:
•
New Features in Release 4.0(1)
•
New Features in Release 3.2(1)
•
New Feature in Release 3.1(1)
New Features in Release 4.0(1)
Table 1-1 lists the new features for Release 4.0(1).
Table 1-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
See the "Configuring EIGRP" section on page 10-29.
|
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.
See the "Configuring Route Health Injection" section on page 10-45.
|
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.
See the "Configuring Static Routes" section on page 10-41.
|
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.
See the "DHCP Relay" section on page 12-1.
|
Modular Policy Framework
|
|
Inspection policy maps and class maps
|
The following protocols support inspection policy and/or class maps:
• DCERPC
• ESMTP
• HTTP
• SIP
See the "Configuring Inspect Maps" section on page 19-7 and the "Configuring Class Maps" section on page 19-7.
See Chapter 23, "Configuring Application Layer Protocol Inspection," for information about these inspections.
|
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.
See the "Configuring Regular Expressions" section on page 19-7.
|
Filtering
|
|
HTTPS support with Secure Computing SmartFilter
|
The FWSM now supports HTTPS filtering using Secure Computing SmartFilter.
See the "Filter Rules" section on page 25-7.
|
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 .
See the "Add/Edit Parameters for Websense URL Filtering" section on page 25-5.
|
Application Inspection
|
|
DNS Guard configurability
|
You can now disable DNS Guard at the CLI.
See the "DNS Client" section on page 12-8.
|
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.
See the "SIP Inspection" section on page 23-19.
|
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.
See the "HTTP Inspection" section on page 23-13.
|
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.
See the "ESMTP Inspection" section on page 23-8.
|
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.
See the "DCERPC Inspection" section on page 23-6.
|
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.
See the "Changing the Memory Partition Size" section on page 9-12.
|
Rule reallocation per feature per partition
|
You can reallocate rules between features on a per-partition basis instead of just globally.
See the "Reallocating Rules Between Features for a Specific Memory Partition" section on page 9-15.
|
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.
See Chapter 20, "Configuring Access Rules and EtherType Rules."
|
Connections and Switch Integration
|
|
Trusted Flow Acceleration
|
Note This feature depends on Cisco IOS Release 12.2(33)SXI or later, and is only available on the Catalyst 6500 switch.
Trusted Flow Acceleration lets the FWSM take advantage of the processing power of the switch supervisor to greatly increase packet throughput.
See the "Using PISA to Permit or Deny Application Types" section on page 26-12.
|
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.
See the "Using PISA to Permit or Deny Application Types" section on page 26-12.
|
Connection rate limiting
|
You can limit the connection rate for TCP and UDP traffic.
See the "Configuring Connection Settings, TCP State Bypass, and Trusted Flow Acceleration" section on page 26-1.
|
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.
|
Monitoring
|
|
New SNMP MIBs
|
For ACL entries and ACL hit counters (CISCO-IP-PROTOCOL-FILTER-MIB), and ARP table entries (IP-MIB).
|
New Features in Release 3.2(1)
Table 1-2 lists the new features for Release 3.2(1).
Table 1-2 New Features for FWSM Release 3.2(1)
Feature
|
Description
|
Routing
|
|
BGP Stub Routing
|
The FWSM supports BGP stub routing. The BGP stub routing process advertises static and directly- connected routes but does not accept routes advertised by the BGP peer.
|
High Availability
|
|
Failover Preemption for Active/Standby Failover
|
You can configure failover preemption for units in an Active/Standby failover configuration. When the primary unit in an Active/Standby failover configuration fails, or if the secondary unit boots before the primary unit, the secondary, standby unit becomes active. Configuring failover preemption causes the primary unit to automatically become the active unit after a specified amount of time.
|
AAA State Replication
|
FWSM synchronizes the user authentication table when Stateful Failover is enabled so the user does not have to authenticate once again after failover happens.
|
Application Inspection
|
|
SIP Enhancement
|
SIP enhancements allow FWSM to clear media connections on receipt of a 200 OK for BYE message, on receipt of a 200 OK for CANCEL message, or on receipt of 200 OK for 4xx/5xx/6xx Error messages. Previously media connections were cleared only due to an idle timeout. This enhancement also makes embryonic connections timeout no longer based on the configurable timeout sip-invite command or on the expiry field in the SIP invite message.
|
RTSP PAT
|
This release introduces PAT support in RTSP. For the RTSP PAT feature, if the translated port is different from the original port in an RTSP control channel message exchange, the translated port number is included in the RTSP packet before it is sent to the server. This ensures that the server responds on the correct port for the client.
|
H.323 GUP Support
|
The H.323 GUP support feature includes a separate inspection module that receives packets via dynamic inspection logic. This new inspection opens up pin-holes for establishing connection among Cisco gatekeepers working as clusters to provide gatekeeper redundancy to H323 gateways.
|
GGSN Load Balancing
|
The GGSN load balancing feature allows any GNS belonging to a GNS pool to respond to an SGSN request in order to achieve load balancing on the GGSNs. The inspection engine allows a set of GNS to respond to a request even if a GSN is not specified as the responder to the request in the GTP request message.
|
Transparent Firewall
|
|
Transparent Firewall NAT Support
|
You can now configure NAT for a transparent firewall. This feature extends the NAT/PAT functionality to transparent mode thereby reducing the need for adding a new NAT/PAT device in the network. This feature is also very useful in cases where multiple VRFs with overlapping addresses are used. NAT per VRF is not supported on the Catalyst 6500 series switches and the Cisco 7600 series routers.
Introducing NAT support for transparent firewalls addresses the NAT per VRF requirement while offering the capability to run routing protocols through the firewall with a simple configuration.
|
NAT
|
|
NAT Bypass No Longer Creates NAT Sessions
|
In previous releases, even if you used NAT exemption or identity NAT, the FWSM created NAT sessions (xlates) for all flows. In Release 3.2, you can configure the FWSM to create xlates only when NAT is configured. By default, the FWSM creates NAT sessions for all connections even if you do not use NAT. For example, a session is created for each untranslated connection even if you do not enable NAT control, you use NAT exemption or identity NAT, or you use same security interfaces and do not configure NAT. Because there is a maximum number of NAT sessions, these kinds of NAT sessions might cause you to run into the limit. To avoid running into the limit, you can disable NAT sessions for untranslated traffic using the xlate-bypass command.
|
AAA
|
|
Authentication Support When Sessioning To The System Execution Space
|
When you log in to the system execution space from the switch in multiple context mode, a new feature in FWSM Release 3.2 lets you use authentication using a AAA server or local database. Previously, the only method of authentication available was to use the login password defined in the system configuration. The new authentication method is enabled by the aaa authentication telnet console command in the admin context. If you upgrade to Release 3.2, and have this command already in the admin context configuration, then authentication for the system execution space is enabled using the specified server or local database, even if you did not intend to enable it. To use the login password instead, you must remove the aaa authentication telnet console command in the admin context.
|
Direct Login Or Logout Using Virtual HTTP and SSH For User Authentication
|
In addition to direct login with virtual Telnet, you can now log in or out directly using HTTP and SSH.
|
Virtual HTTP Hostname Support
|
You can now assign a hostname to the virtual HTTP server on the FWSM. When a user is forwarded to the virtual HTTP server to enter their AAA username and password, you see the hostname in the authentication dialog box message.This information helps differentiate the AAA prompt from the destination HTTP server prompt.
|
Interactive Password Prompts With RADIUS For Authentication
|
With RADIUS servers, a user can now be prompted for a new password when authenticating.
|
TCP
|
|
TCP State Bypass
|
If you have asymmetric routing configured on upstream routers, and traffic alternates between two FWSMs, then you can configure TCP state bypass for specific traffic.
|
Connection Timeouts For Non-TCP Traffic On A Per-flow Basis
|
You can now configure connection timeouts for non-TCP traffic using Modular Policy Framework. Formerly, you could only set global timeouts.
|
Switch Integration
|
|
IOS Support For Autostate Messaging For Rapid Link Failure Detection
|
Using Catalyst operating system software Release 8.4(1) and higher or Cisco IOS software Release 12.2(18)SXF5 and higher, the supervisor engine can send autostate messages to the FWSM about the status of physical interfaces associated with FWSM VLANs.
|
New Feature in Release 3.1(1)
Table 1-3 lists the new features for FWSM software Release 3.1(1).
Table 1-3 New Features for FWSM Release 3.1(1)
Type of Feature
|
Feature
|
Description/Benefits
|
Authentication, Authorization, and Accounting (AAA)
|
Support for simultaneous RADIUS accounting servers
|
Ability to send START/STOP accounting records to multiple RADIUS servers simultaneously.
Provides higher scalability for RADIUS accounting.
|
Accounting for management traffic
|
AAA accounting records are generated for management connections to the box. Only TACACS+ is supported.
Allows backtracking of administrative commands that may have caused problems.
|
Configure FTP authentication challenge
|
Specifies if the user should be challenged for FTP traffic based on prior authentication of other interactive traffic (Telnet, HTTP, HTTPS) and whether to challenge and block unauthorized FTP traffic. This allows traffic from internal authenticated hosts to go through, while blocking traffic from unauthenticated users.
|
MAC-based AAA exemption
|
Allows specifying AAA exemption based on a MAC and an IP address that was dynamically allocated or relayed by the DHCP server or DHCP Relay. This supports dynamic addressing of devices like printers and IP phones behind a firewall.
|
Cut-through proxy authentication using local database
|
Authentication of cut-through traffic using a local username database, as a backup for AAA services. This allows disconnected use of policies when a AAA server is not available.
|
AAA server checks all TFTP commands for authorization
|
If command authorization is turned on, then all TFTP server commands are checked by the AAA server for authorization. If users are not authorized to use the command, then the request is denied. In previous releases, only the configure net command was checked for authorization.
Note Note: If you have many access lists configured for your network, then this could result in a delay while the server is checking them.
|
Access Lists
|
Time-based ACE
|
Defines a time range (time of the day and week) when certain ACEs become active. Provides more granular policy, identical to the Cisco IOS software implementation.
|
Modular Policy Framework
|
Provides a modular and consistent framework that identifies traffic flows, classifies traffic, and defines policies. Policies include inspection policies, connection policies, and TCP connection timeouts. The Modular Policy Framework lets you apply these policies to specific classes of traffic.
|
Access list editing
|
ACEs can be added in the middle of an access list between two consecutive ACEs based on the ACE line number. This allows more flexible policy definitions.
|
Interface keyword as address in access lists
|
Allows the use of the interface keyword with the access-list command.
|
Network Address Translation
|
NAT control
|
NAT configuration is no longer required to pass traffic through the FWSM.
|
Overlapping static NAT configuration
|
Overlapping static statements are allowed and only a warning message is issued. FWSM performs the Longest Prefix lookup for the static statements.
|
Inspection Engines (Fixups)
|
TCP stream assembly for application inspection
|
Assembly of VoIP/TCP streams which are processed by the inspection engines (such as SIP, Skinny, and MGCP) instead of individual packets. This allows interoperability with the latest version of Cisco CallManager.
|
Persistent TCP connections and TCP pools for URL filtering
|
The FWSM uses established connections for requests instead of creating a new TCP connection to the URL server for each HTTP request. It creates a pool of five connections and reuses them in round robin fashion. This improves the performance of Websense and N2H2 URL filtering.
|
Configurable application inspection engines
|
Inspection engines can be enabled for specific interfaces or globally (the fixup command has been renamed inspect). This provides more granular control of application inspection.
|
ESMTP application inspection
|
Extended SMTP (ESMTP) allows e-mail that includes graphics, audio, video, and text in various national languages. SMTP is still supported in accelerated mode. This enhances client-to-server communication.
|
FTP command filtering
|
Strict FTP inspection includes FTP command request filtering for over ten FTP commands. This provides additional security, including hiding the reply to the system command and protecting against username discovery. This feature also provide more granular control of FTP.
|
Active X/Java filtering
|
Filters objects, such as ActiveX objects or Java applets, that may pose security risks.
|
PPTP PAT and application inspection enhancement
|
PAT support and stateful inspection is added for PPTP so that only TCP port 1723 needs to be opened. This simplifies FWSM configuration for remote client connections.
|
VoIP Inspection Engines (Fixups)
|
H.323 enhancement - T.38
|
Allows inspection and modification of T.38 (FAX over IP) within H.323 sessions. This protects FAX messages transmitted between endpoints over an IP network.
|
H.323 enhancement -GKRCS
|
GKRCS application inspection opens pin-holes between endpoints, which allows firewalls to be placed between an H.323 gatekeeper and the end points.
|
MGCP NAT
|
Supports NAT of the IP address and opening pin-holes according to the NATed/PATed IP address and port information. This allows firewalls to be placed between media gateways and end points.
|
GTP application inspection
|
GTP application inspection provides advanced stateful inspection capabilities for GSM/GPRS wireless service provider (3GPP—Third Generation Partnership Project) environments.
|
SIP instant messaging application inspection
|
Provides Instant Messaging (IM) support for RTC client for Windows Messenger version 4.7.0105. Support for new SIP methods MESSAGE/INFO and new response 202 as described by RFC 3428 and RFC 3265. Allows stateful inspection of IM over SIP.
|
TAPI/CTIQBE application inspection
|
TAPI/CTIQBE application inspection translates the embedded IP addresses or port numbers and opens pinholes for subsequent media transmission between call endpoints. CTIQBE is a VoIP protocol developed by Cisco for Cisco IP SoftPhone and other Cisco TAPI/JTAPI applications for call setup with Cisco CallManager.
|
Skinny video support
|
Supports Skinny (SCCP) video application inspection by handling Skinny video messages that carry embedded IP addresses and ports for the video channels and by opening pinholes for video RTP/RTCP streams. Interoperates with video over IP in Cisco CallManager 4.0.
|
Application Firewall
|
HTTP inspection engine enhancements
|
Provides deep payload inspection of HTTP traffic to detect and block Port 80 misuse and deter web-based attacks.
|
Detect and block applications and attacks tunneled over HTTP
|
Detects a list of pre-defined port 80 tunneling applications, such as instant messaging (AIM, MSN Messenger, Yahoo), and peer-to-peer (Kazaa). Permits or blocks traffic based on user policy configured using the Modular Policy Framework. Also generates a message for any port 80 misuse event. Prevents malicious applications from being tunneled over HTTP.
|
RFC compliance checking
|
Specifies whether all traffic that is not compliant with the HTTP standard should be permitted or logged. This provides HTTP protocol anomaly detection.
|
HTTP command filtering
|
Determines if the Request Message is an RFC-defined method (OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, or CONNECT) or an extension method (INDEX, MOVE, and so forth.). If the check fails, the user may be alerted, a message may be generated, and the TCP connection may be reset. This lets you select the HTTP methods to allow or deny.
|
MIME type filtering
|
Permits passing a predefined list of mime-types (such as image/Jpeg, text/html, application/msword, audio/mpeg) or all mime-types through the firewall. This helps control the types of content that can traverse the firewall.
|
Checks for minimum and maximum size of HTTP message, header length and URI
|
Permits or denies traffic based on whether a requestor response HTTP message meets the configured size constraints. Checks the maximum header length for the HTTP request and response messages and checks the maximum size of URI permitted through the firewall. Allows control of HTTP messages that violate the criteria defined for URI length and request/response message header size.
|
Content validation
|
Verifies that the content-type specified in the header matches the content-type defined in the body of the HTTP message. Validates that the content-type in the response message matches the request message accept-type field. If the check fails, the user may be alerted, a message may be generated, and the TCP connection may be reset.
|
HTTP message filtering based on keywords
|
Filters HTTP messages based on keywords and takes appropriate action. Improves control and deters port 80 misuse.
|
High Availability
|
Active/active
|
Contexts can be active on one blade, standby on the second blade, while other contexts are in standby in the first blade and active in the second blade. This provides high resilience in multi-group HSRP style.
|
Pre-empt option for active/active
|
Allows redundant FWSMs to preempt one another depending on the configured priority. Allows the design of deterministic traffic paths with redundant firewalls.
|
Asymmetric routing support
|
Traffic that arrives on a different unit or interface than the traffic originated can be forwarded to the unit or interface where the traffic originally was passed. This provides resilient WAN connectivity.
|
Scalability
|
Support for 250 virtual contexts
|
Maximum number of supported virtual contexts is increased from 100 to 250. This provides high scalability for virtual contexts.
|
Apply the write mem command to all contexts
|
The write mem command saves configuration for all contexts without having to enter the command for each individual context. This makes configuring a large number of virtual contexts easier.
|
Increase number of global statements to 4 K
|
The total number of global statements within the system is increased from 1 K to 4 K. This improves scalability when defining a pool of global addresses.
|
Access list memory enhancements
|
Increase of 20% in total available access list memory. This improves scalability for access lists.
|
Sessions for non-TCP/UDP packets
|
Non-TCP/UDP packets are forwarded through the fast path instead of the slow path. This improves performance for GRE, ESP, and multicast traffic.
|
Support up to ten DHCP relay statements
|
Increases the number of DHCP relay statements from four to ten, which allows better scalability.
|
80 HTTPS sessions for ASDM
|
Increases the current number of possible HTTPS sessions from 32 to 80 for ASDM.
|
Network Integration
|
Mixed L2 & L3 mode support
|
A mixture of L2 and L3 modes on the same FWSM is allowed, which enables flexible network deployments.
|
Multiple pairs of L2 interfaces per context
|
The number of supported interfaces in transparent mode is increased from a single pair up to eight pairs pairs. This improves scalability and reusability of L2 contexts.
|
Private VLAN support
|
FWSM is now aware of PVLANs configured on the Cisco Catalyst 6000 Supervisor and properly processes traffic coming from a secondary VLAN that is configured as a secure VLAN with 802.1Q tagging of the primary. This leverages the logical separation and traffic isolation provided by PVLANs.
|
Per interface DHCP relay
|
Allows DHCP relay (helper addresses) to be configured for each interface rather than for the entire context. This allows better granularity and control of DHCP services.
|
Core IP Enhancements
|
IPv6 Phase 1
|
Support for inspection, security checks on headers, access lists, routing, and management to the device for IPv6 traffic. This supports the expanded addressing capabilities and native security offered by IPv6.
|
Multicast support
|
Support for PIM-SM version 2 (RFC2362) dynamic routing as well as IGMP v2. This provides secure integration in distributed video conferencing and collaborative computing environments and reliable delivery of sensitive real-time streaming updates.
|
dNAT for multicast
|
Destination NAT on the group addresses after packets are replicated protects internal resources from an external multicast source.
|
OSPF neighbor
|
Allows FWSM to push OSPF routes over a VPN tunnel by statically defining neighbors and exchanging databases using unicasts. OSPF hello updates and OSPF adjacencies can be established over VPN tunnels.
|
Monitoring and Management
|
SSHv2
|
SSHv2 provides a more secure way of accessing FWSM and improves security for management connections.
|
Ping, logging and memory management enhancements
|
Extended ping, logging of subsystem identification when packets are dropped or discarded, enhanced messages for memory depletion conditions, user-configurable system message buffer size, and sanity checks for detecting memory corruptions.
|
Syslog server failure policy for TCP transport
|
The FWSM can be configured to stop or continue processing if the syslog server fails when using TCP as the syslog transport.
|
4 K+ certificate support
|
The FWSM can work with certain certificate authorities for administrator authentication by supporting 4 K key sizes. For example, Microsoft CA defaults to 4 K key sizes.
|
SNMPv2c
|
SNMPv2C agent supports new features, such as 64-bit counters, enhanced MIBS (SNMPv2 MIB [RFC 1907], and the IF-MIB [RFC 1573,2233]). Provides uniform SNMP agent/MIB support with Cisco PIX security appliance and VPN 3000.
|
Additional MIBs
|
Includes other MIBs currently available on the Cisco PIX security appliance and VPN 3000 platforms. New additions are: CISCO-CRYPTO-ACCELERATOR-MIB.my, IF-MIB.my, CISCO-FIREWALL-MIB.my, CISCO-PROCESS-MIB.my, CISCO-SYSLOG-MIB.my, CISCO-REMOTE-ACCESS-MONITOR-MIB.my,CISCO-IPSEC-FLOW-MONITOR-MIB.my, ENTITY-MIB.my. This provides uniform SNMP agent/MIB support with Cisco PIX security appliance and VPN 3000.
|
Enhanced parser and CLI
|
FWSM CLI is enhanced by porting the Cisco IOS software parser and by providing functions such as command alias, comments in configuration file, command completion, command syntax check, and context sensitive help.
|
Out of band management
|
Restricts management traffic to a specific interface. Enhances security for management connections.
|
Prompt slot/status reporting
|
CLI enables/disables reporting the slot number and failover status as part of the FWSM session prompt. Identifies the slot in which the FWSM is installed and the failover status of the module.
|
Debug message timestamp
|
Adds a timestamp for debugging messages. This improves ease of use for logged debug messages.
|
System context logging to external syslog server
|
The system context can send logs to an external syslog server. This provides logging messages from the system context.
|
Include ACE info as part of message 106023
|
The specific ACE entry is identified in the message, rather than just the access list name. This helps isolate traffic issues.
|
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 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 do 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.
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. The configuration of both series is identical, except for the following variations:
•
The Catalyst 6500 series switches supports two software modes:
–
Cisco IOS software on both the switch supervisor and the integrated MSFC (known as "supervisor IOS").
–
Catalyst Operating System (OS) on the supervisor, and Cisco IOS software on the MSFC.
For commands and configuration that are performed on the switch itself, both modes are described.
Note
FWSM Release 4.0 and later only supports supervisor IOS; the Catalyst operating system is no longer supported.
•
The Cisco 7600 series routers support only Cisco IOS software.
Both series are referred to generically in this guide as the "switch."
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 1 on page A-1). 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 features allow you to customize the packet flow: "Using PISA to Permit or Deny Application Types" section on page 26-12 and "Configuring TCP Options" section on page 26-20.
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.