Cisco ASA Services Module CLI Configuration Guide, 8.5
Introduction to the ASA Services Module
Downloads: This chapterpdf (PDF - 271.0KB) The complete bookPDF (PDF - 12.85MB) | Feedback

Introduction to the Cisco ASA Services Module

Table Of Contents

Introduction to the Cisco ASA Services Module

Hardware and Software Compatibility

New Features

New Features in Version 8.5(1.7)

New Features in Version 8.5(1.6)

New Features in Version 8.5(1)

How the ASA Services Module Works with the Switch

Firewall Functional Overview

Security Policy Overview

Permitting or Denying Traffic with Access Lists

Applying NAT

Protecting from IP Fragments

Using AAA for Through Traffic

Applying HTTP, HTTPS, or FTP Filtering

Applying Application Inspection

Applying QoS Policies

Applying Connection Limits and TCP Normalization

Enabling Threat Detection

Enabling the Botnet Traffic Filter

Firewall Mode Overview

Stateful Inspection Overview

Security Context Overview


Introduction to the Cisco ASA Services Module


The ASASM provides advanced Stateful Firewall functionality. The ASASM includes many advanced features, such as multiple security contexts (similar to virtualized firewalls), transparent (Layer 2) firewall or routed (Layer 3) firewall operation, advanced inspection engines, and many more features.

This chapter includes the following sections:

Hardware and Software Compatibility

New Features

How the ASA Services Module Works with the Switch

Firewall Functional Overview

Security Context Overview

Hardware and Software Compatibility

For a complete list of supported hardware and software, see the Cisco ASA Compatibility:

http://www.cisco.com/en/US/docs/security/asa/compatibility/asamatrx.html

New Features

This section includes the following topics:

New Features in Version 8.5(1.7)

New Features in Version 8.5(1.6)

New Features in Version 8.5(1)


Note New, changed, and deprecated syslog messages are listed in syslog messages guide.



Note Version 8.4(4) was removed from Cisco.com due to build issues; please upgrade to Version 8.4(4.1) or later.


New Features in Version 8.5(1.7)

Released: March 5, 2012

Table 1-2 lists the new features for ASA interim Version 8.5(1.7).


Note We recommend that you upgrade to a Cisco.com-posted ASA interim release only if you have a specific problem that it resolves. If you decide to run an interim release in a production environment, keep in mind that only targeted testing is performed on interim releases. Interim releases are fully supported by Cisco TAC and will usually remain on the download site only until the next maintenance release is available. If you choose to run an interim release, we strongly encourage you to upgrade to a fully-tested maintenance or feature release when it becomes available.

We will document interim release features at the time of the next maintenance or feature release. For a list of resolved caveats for each ASA interim release, see the interim release notes available on the Cisco.com software download site.


Table 1-1 New Features for ASA Interim Version 8.5(1.7) 

Feature
Description
Hardware Features

Support for the Catalyst 6500 Supervisor 2T

The ASASM now interoperates with the Catalyst 6500 Supervisor 2T. For hardware and software compatibility, see: http://www.cisco.com/en/US/docs/security/asa/compatibility/asamatrx.html.

Note You may have to upgrade the FPD image on the ASASM. See the Upgrading procedure the in the release notes.

Failover Features

Configure the connection replication rate during a bulk sync

You can now configure the rate at which the ASASM replicates connections to the standby unit when using stateful failover. By default, connections are replicated to the standby unit during a 15 second period. However, when a bulk sync occurs (for example, when you first enable failover), 15 seconds may not be long enough to sync large numbers of connections due to a limit on the maximum connections per second. For example, the maximum connections on the ASASM is 8 million; replicating 8 million connections in 15 seconds means creating 533K connections per second. However, the maximum connections allowed per second is 300K. You can now specify the rate of replication to be less than or equal to the maximum connections per second, and the sync period will be adjusted until all the connections are synced.

We introduced the following command: failover replication rate rate.

 


New Features in Version 8.5(1.6)

Released: January 27, 2012

Table 1-2 lists the new features for ASA interim Version 8.5(1.6).


Note We recommend that you upgrade to a Cisco.com-posted ASA interim release only if you have a specific problem that it resolves. If you decide to run an interim release in a production environment, keep in mind that only targeted testing is performed on interim releases. Interim releases are fully supported by Cisco TAC and will usually remain on the download site only until the next maintenance release is available. If you choose to run an interim release, we strongly encourage you to upgrade to a fully-tested maintenance or feature release when it becomes available.

We will document interim release features at the time of the next maintenance or feature release. For a list of resolved caveats for each ASA interim release, see the interim release notes available on the Cisco.com software download site.


Table 1-2 New Features for ASA Interim Version 8.5(1.6) 

Feature
Description
Multiple Context Features

Automatic generation of a MAC address prefix

In multiple context mode, the ASASM now converts the automatic MAC address generation configuration to use a default prefix. The ASASM auto-generates the prefix based on the last two bytes of the backplane MAC address. This conversion happens automatically when you reload, or if you reenable MAC address generation. The prefix method of generation provides many benefits, including a better guarantee of unique MAC addresses on a segment. You can view the auto-generated prefix by entering the show running-config mac-address command. If you want to change the prefix, you can reconfigure the feature with a custom prefix. The legacy method of MAC address generation is no longer available.

Note To maintain hitless upgrade for failover pairs, the ASASM does not convert the MAC address method in an existing configuration upon a reload if failover is enabled. However, we strongly recommend that you manually change to the prefix method of generation when using failover. Without the prefix method, ASASMs installed in different slot numbers experience a MAC address change upon failover, and can experience traffic interruption. After upgrading, to use the prefix method of MAC address generation, reenable MAC address generation to use the default prefix.

We modified the following command: mac-address auto.

 


New Features in Version 8.5(1)

Released: July 8, 2011

Table 1-3 lists the new features for ASA Version 8.5(1). This ASA software version is only supported on the ASASM.


Note Version 8.5(1) includes all features in 8.4(1), plus the features listed in this table. The following features, however, are not supported in No Payload Encryption software, and this release is only available as a No Payload Encryption release:

VPN

Unified Communications

Features added in 8.4(2) are not included in 8.5(1) unless they are explicitly listed in this table.


Table 1-3 New Features forASA Version 8.5(1) 

Feature
Description
Hardware Features

Support for the ASA Services Module

We introduced support for the ASASM for the Cisco Catalyst 6500 E switch.

Firewall Features

Mixed firewall mode support in multiple context mode

You can set the firewall mode independently for each security context in multiple context mode, so some can run in transparent mode while others run in routed mode.

We modified the following command: firewall transparent.

 

Interface Features

Automatic MAC address generation is now enabled by default in multiple context mode

Automatic generation of MAC addresses is now enabled by default in multiple context mode.

We modified the following command: mac address auto.

 

NAT Features

Identity NAT configurable proxy ARP and route lookup

In earlier releases for identity NAT, proxy ARP was disabled, and a route lookup was always used to determine the egress interface. You could not configure these settings. In 8.4(2) and later, the default behavior for identity NAT was changed to match the behavior of other static NAT configurations: proxy ARP is enabled, and the NAT configuration determines the egress interface (if specified) by default. You can leave these settings as is, or you can enable or disable them discretely. Note that you can now also disable proxy ARP for regular static NAT.

For pre-8.3 configurations, the migration of NAT exempt rules (the nat 0 access-list command) to 8.4(2) and later now includes the following keywords to disable proxy ARP and to use a route lookup: no-proxy-arp and route-lookup. The unidirectional keyword that was used for migrating to 8.3(2) and 8.4(1) is no longer used for migration. When upgrading to 8.4(2) from 8.3(1), 8.3(2), and 8.4(1), all identity NAT configurations will now include the no-proxy-arp and route-lookup keywords, to maintain existing functionality. The unidirectional keyword is removed.

We modified the following commands: nat static [no-proxy-arp] [route-lookup] (object network) and nat source static [no-proxy-arp] [route-lookup] (global).

Also available in Version 8.4(2).

PAT pool and round robin address assignment

You can now specify a pool of PAT addresses instead of a single address. You can also optionally enable round-robin assignment of PAT addresses instead of first using all ports on a PAT address before using the next address in the pool. These features help prevent a large number of connections from a single PAT address from appearing to be part of a DoS attack and makes configuration of large numbers of PAT addresses easy.

Note Currently in 8.5(1), the PAT pool feature is not available as a fallback method for dynamic NAT or PAT. You can only configure the PAT pool as the primary method for dynamic PAT (CSCtq20634).

We modifed the following commands: nat dynamic [pat-pool mapped_object [round-robin]] (object network) and nat source dynamic [pat-pool mapped_object [round-robin]] (global).

Also available in Version 8.4(2).

Switch Integration Features

Autostate

The switch supervisor engine can send autostate messages to the ASASM about the status of physical interfaces associated with ASASM VLANs. For example, when all physical interfaces associated with a VLAN go down, the autostate message tells the ASASM that the VLAN is down. This information lets the ASASM declare the VLAN as down, bypassing the interface monitoring tests normally required for determining which side suffered a link failure. Autostate messaging provides a dramatic improvement in the time the ASASM takes to detect a link failure (a few milliseconds as compared to up to 45 seconds without autostate support).

Note The switch supports autostate messaging only if you install a single ASASM in the chassis.

See the following Cisco IOS command: firewall autostate.

Virtual Switching System

The ASASM supports VSS when configured on the switches. No ASASM configuration is required.


How the ASA Services Module Works with the Switch

You can install the ASASM in the Catalyst 6500 series switches with Cisco IOS software on both the switch supervisor and the integrated MSFC.


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


The ASASM runs its own operating system

The switch includes a switching processor (Applythe 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. You can alternatively use external routers instead of the MSFC.

In single context mode, you can place the router in front of the firewall or behind the firewall (see Figure 1).

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

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

Figure 1 MSFC/Router Placement

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

Figure 2 MSFC/Router Placement with Multiple Contexts

Firewall Functional Overview

Firewalls protect inside networks from unauthorized access by users on an outside network. A 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 only includes the public servers, an attack there only affects 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.

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 ASASM 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 section includes the following topics:

Security Policy Overview

Firewall Mode Overview

Stateful Inspection Overview

Security Policy Overview

A security policy determines which traffic is allowed to pass through the firewall to access another network. By default, the ASASM allows traffic to flow freely from an inside network (higher security level) to an outside network (lower security level). 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 HTTP, HTTPS, or FTP Filtering

Applying Application Inspection

Applying QoS Policies

Applying Connection Limits and TCP Normalization

Enabling Threat Detection

Enabling the Botnet Traffic Filter

Permitting or Denying Traffic with Access Lists

You can apply an access list to limit traffic from inside to outside, or allow traffic from outside to inside. 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 ASASM 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 ASASM. 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 ASASM also sends accounting information to a RADIUS or TACACS+ server.

Applying HTTP, HTTPS, or FTP 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 ASASM in conjunction with a separate server running one of the following Internet filtering products:

Websense Enterprise

Secure Computing SmartFilter

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 ASASM to perform a deep packet inspection.

Applying QoS Policies

Some network traffic, such as voice and streaming video, cannot tolerate long latency times. QoS is a network feature that lets you give priority to these types of traffic. QoS refers to the capability of a network to provide better service to selected network traffic.

Applying Connection Limits and TCP Normalization

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 ASASM 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.

TCP normalization is a feature consisting of advanced TCP connection settings designed to drop packets that do not appear normal.

Enabling Threat Detection

You can configure scanning threat detection and basic threat detection, and also how to use statistics to analyze threats.

Basic threat detection detects activity that might be related to an attack, such as a DoS attack, and automatically sends a system log message.

A typical scanning attack consists of a host that tests the accessibility of every IP address in a subnet (by scanning through many hosts in the subnet or sweeping through many ports in a host or subnet). The scanning threat detection feature determines when a host is performing a scan. Unlike IPS scan detection that is based on traffic signatures, the ASASM scanning threat detection feature maintains an extensive database that contains host statistics that can be analyzed for scanning activity.

The host database tracks suspicious activity such as connections with no return activity, access of closed service ports, vulnerable TCP behaviors such as non-random IPID, and many more behaviors.

You can configure the ASASM to send system log messages about an attacker or you can automatically shun the host.

Enabling the Botnet Traffic Filter

Malware is malicious software that is installed on an unknowing host. Malware that attempts network activity such as sending private data (passwords, credit card numbers, key strokes, or proprietary data) can be detected by the Botnet Traffic Filter when the malware starts a connection to a known bad IP address. The Botnet Traffic Filter checks incoming and outgoing connections against a dynamic database of known bad domain names and IP addresses (the blacklist), and then logs any suspicious activity. When you see syslog messages about the malware activity, you can take steps to isolate and disinfect the host.

Firewall Mode Overview

The ASASM runs in two different firewall modes:

Routed

Transparent

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

In transparent mode, the ASASM acts like a "bump in the wire," or a "stealth firewall," and is not considered a router hop. The ASASM connects to the same network on its inside and outside interfaces.

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 multicast streams using an EtherType access list.

Stateful Inspection Overview

All traffic that goes through the ASASM is inspected using the Adaptive Security Algorithm and 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 TCP state bypass feature allows you to customize the packet flow. See the "TCP State Bypass" section.


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

Is this a new connection?

If it is a new connection, the ASASM 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."

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 "fast path"

The ASASM creates forward and reverse flows in the fast path for TCP traffic; the ASASM also creates connection state information for connectionless protocols like UDP, ICMP (when you enable ICMP inspection), so that they can also use the fast path.


Note For other IP protocols, like SCTP, the ASASM does not create reverse path flows. As a result, ICMP error packets that refer to these connections are dropped.


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.

Is this an established connection?

If the connection is already established, the ASASM does not need to re-check packets; most matching packets can go through the "fast" path in both directions. The fast 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

Data packets for protocols that require Layer 7 inspection can also go through the fast 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.

Security Context Overview

You can partition a single ASASM into multiple virtual devices, known as security contexts. Each context is an independent device, with 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, IPS, and management. Some features are not supported, including VPN and dynamic routing protocols.

In multiple context mode, the ASASM 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 ASASM. 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 into the admin context, then that user has system administrator rights and can access the system and all other contexts.