Cisco ASA 5500 Series Configuration Guide using the CLI, 8.2 - Configuring the IPS Application on the AIP SSM and SSC [Cisco ASA 5500 Series Adaptive Security Appliances]

Table Of Contents

Configuring the IPS Application on the AIP SSM and SSC

Information About the AIP SSM and SSC

How the AIP SSM/SSC Works with the Adaptive Security Appliance

Operating Modes

Using Virtual Sensors (AIP SSM Only)

Differences Between the AIP SSM and the AIP SSC

Licensing Requirements for the AIP SSM/SSC

Guidelines and Limitations

Configuring the AIP SSM/SSC

AIP SSM/SSC Task Overview

Configuring the Security Policy on the AIP SSM/SSC

Assigning Virtual Sensors to a Security Context (AIP SSM Only)

Diverting Traffic to the AIP SSM/SSC

Monitoring the AIP SSM/SSC

Configuration Examples for the AIP SSM/SSC

Feature History for the AIP SSM/SSC

Configuring the IPS Application on the AIP SSM and SSC

This chapter describes how to configure the IPS application that runs on an Advanced Inspection and Prevention Security Services Module (AIP SSM) or an Advanced Inspection and Prevention Security Security Services Card (AIP SSC).

Note The SSC is supported on the ASA 5505. See the "SSM and SSC Support Per ASA Model" section on page 1-1 for more information about which models support SSMs.

This chapter includes the following sections:

•Information About the AIP SSM and SSC

•Licensing Requirements for the AIP SSM/SSC

•Guidelines and Limitations

•Configuring the AIP SSM/SSC

•Monitoring the AIP SSM/SSC

•Configuration Examples for the AIP SSM/SSC

•Feature History for the AIP SSM/SSC

Information About the AIP SSM and SSC

You can install the AIP SSM/SSC into an ASA 5500 series adaptive security appliance. The AIP SSM/SSC runs advanced IPS software that provides proactive, full-featured intrusion prevention services to stop malicious traffic, including worms and network viruses, before they can affect your network. This section includes the following topics:

•How the AIP SSM/SSC Works with the Adaptive Security Appliance

•Operating Modes

•Using Virtual Sensors (AIP SSM Only)

•Differences Between the AIP SSM and the AIP SSC

How the AIP SSM/SSC Works with the Adaptive Security Appliance

The AIP SSM/SSC runs a separate application from the adaptive security appliance. It is, however, integrated into the adaptive security appliance traffic flow. The AIP SSM/SSC does not contain any external interfaces itself (except for the management interface on the SSM only). When you identify traffic for IPS inspection on the adaptive security appliance, traffic flows through the adaptive security appliance and the AIP SSM/SSC in the following way:

1. Traffic enters the adaptive security appliance.

2. Firewall policies are applied.

3. Traffic is sent to the AIP SSM/SSC over the backplane.

See the "Operating Modes" section for information about only sending a copy of the traffic to the AIP SSM/SSC.

4. The AIP SSM/SSC applies its security policy to the traffic, and takes appropriate actions.

5. Valid traffic is sent back to the adaptive security appliance over the backplane; the AIP SSM/SSC might block some traffic according to its security policy, and that traffic is not passed on.

6. VPN policies are applied (if configured).

7. Traffic exits the adaptive security appliance.

Figure 59-1 shows the traffic flow when running the AIP SSM/SSC in inline mode. In this example, the AIP SSM/SSC automatically blocks traffic that it identified as an attack. All other traffic is forwarded through the adaptive security appliance.

Figure 59-1 AIP SSM/SSC Traffic Flow in the Adaptive Security Appliance: Inline Mode

Operating Modes

You can send traffic to the AIP SSM/SSC using one of the following modes:

•Inline mode—This mode places the AIP SSM/SSC directly in the traffic flow (see Figure 59-1). No traffic that you identified for IPS inspection can continue through the adaptive security appliance without first passing through, and being inspected by, the AIP SSM/SSC. This mode is the most secure because every packet that you identify for inspection is analyzed before being allowed through. Also, the AIP SSM/SSC can implement a blocking policy on a packet-by-packet basis. This mode, however, can affect throughput.

•Promiscuous mode—This mode sends a duplicate stream of traffic to the AIP SSM/SSC. This mode is less secure, but has little impact on traffic throughput. Unlike the inline mode, in promiscuous mode the AIP SSM/SSC can only block traffic by instructing the adaptive adaptive security appliance to shun the traffic or by resetting a connection on the adaptive security appliance. Also, while the AIP SSM/SSC is analyzing the traffic, a small amount of traffic might pass through the adaptive adaptive security appliance before the AIP SSM/SSC can shun it. Figure 59-2 shows the AIP SSM/SSC in promiscuous mode. In this example, the AIP SSM/SSC sends a shun message to the adaptive security appliance for traffic it identified as a threat.

Figure 59-2 AIP SSM/SSC Traffic Flow in the Adaptive Security Appliance: Promiscuous Mode

Using Virtual Sensors (AIP SSM Only)

The AIP SSM running IPS software Version 6.0 and above can run multiple virtual sensors, which means you can configure multiple security policies on the AIP SSM. You can assign each context or single mode adaptive security appliance to one or more virtual sensors, or you can assign multiple security contexts to the same virtual sensor. See the IPS documentation for more information about virtual sensors, including the maximum number of sensors supported.

Figure 59-3 shows one security context paired with one virtual sensor (in inline mode), while two security contexts share the same virtual sensor.

Figure 59-3 Security Contexts and Virtual Sensors

Figure 59-4 shows a single mode adaptive security appliance paired with multiple virtual sensors (in inline mode); each defined traffic flow goes to a different sensor.

Figure 59-4 Single Mode Security Appliance with Multiple Virtual Sensors

Differences Between the AIP SSM and the AIP SSC

The AIP SSM supports the higher performance requirements of the ASA 5510 and above, while the AIP SSC is designed for the small office installation of the ASA 5505 adaptive security appliance. The following features are supported on the AIP SSM, but not on the AIP SSC:

•Virtual sensors

•Anomaly detection

•Unretirement of default retired signatures

•Custom signatures

Licensing Requirements for the AIP SSM/SSC

The following table shows the licensing requirements for this feature:

Model

License Requirement

All models

Base License.

The IPS application on the AIP SSM/SSC requires a separate Cisco Services for IPS license in order to support signature updates. All other updates are available without a license.

Guidelines and Limitations

This section includes the guidelines and limitations for this feature.

Context Mode Guidelines

The ASA 5505 adaptive security appliance does not support multiple context mode, so multiple context features, such as virtual sensors, are not supported on the AIP SSC.

Firewall Mode Guidelines

Supported in routed and transparent firewall mode.

Model Guidelines

•The SSC is supported on the ASA 5505 only. See the "SSM and SSC Support Per ASA Model" section on page 1-1 for more information about which models support SSMs.

•The ASA 5505 adaptive security appliance does not support multiple context mode, so multiple context features, such as virtual sensors, are not supported on the AIP SSC.

Configuring the AIP SSM/SSC

This section describes how to configure IPS for the AIP SSM and AIP SSC, and includes the following topics:

•AIP SSM/SSC Task Overview

•Configuring the Security Policy on the AIP SSM/SSC

•Assigning Virtual Sensors to a Security Context (AIP SSM Only)

•Diverting Traffic to the AIP SSM/SSC

AIP SSM/SSC Task Overview

Configuring the AIP SSM/SSC is a process that includes configuration of the IPS software on the SSM/SSC and then configuration of the ASA 5500 series adaptive security appliance. To configure the AIP SSM/SSC, perform the following steps:

Step 1 On the AIP SSM/SSC, configure the inspection and protection policy, which determines how to inspect traffic and what to do when an intrusion is detected. For the AIP SSM only, configure the inspection and protection policy for each virtual sensor if you want to run the AIP SSM in multiple sensor mode. See the "Configuring the Security Policy on the AIP SSM/SSC" section.

Step 2 (AIP SSM only) On the ASA 5500 in multiple context mode, specify which IPS virtual sensors are available for each context (if you configured virtual sensors). See the "Assigning Virtual Sensors to a Security Context (AIP SSM Only)" section.

Step 3 On the ASA 5500, identify traffic to divert to the AIP SSM/SSC. See the "Diverting Traffic to the AIP SSM/SSC" section.

Configuring the Security Policy on the AIP SSM/SSC

This section describes how to access the IPS application in the AIP SSM/SSC.

Note You can alternatively use ASDM to configure the AIP SSM/SSC. See the ASDM documentation for more information.

See also the "Configuring the SSC Management Interface" section on page 58-4 to configure the SSC management interface for ASDM access and other uses.

Detailed Steps

Step 1 Session from the adaptive security appliance to the AIP SSM/SSC. See the "Sessioning to the SSM or SSC" section on page 58-6

Step 2 To run the setup utility for initial configuration of the AIP SSM/SSC, enter the following command:
sensor# setup
You are prompted for basic settings.

Step 3 Configure the IPS security policy.

For the AIP SSM only, if you configure virtual sensors in IPS Version 6.0 or above, you identify one of the sensors as the default. If the ASA 5500 series adaptive adaptive security appliance does not specify a virtual sensor name in its configuration, the default sensor is used.

Because the IPS software that runs on the AIP SSM/SSC is beyond the scope of this document, detailed configuration information is available in the IPS documents at the following location:

http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/tsd_products_support_series_home.html

Step 4 When you are done configuring the AIP SSM/SSC, exit the IPS software by entering the following command:
sensor# exit
If you sessioned to the AIP SSM/SSC from the adaptive security appliance, you return to the adaptive security appliance prompt.

What to Do Next

For the adaptive security appliance in multiple context mode, see the "Assigning Virtual Sensors to a Security Context (AIP SSM Only)" section.

For the adaptive security appliance in single context mode, see the "Diverting Traffic to the AIP SSM/SSC" section.

Assigning Virtual Sensors to a Security Context (AIP SSM Only)

If the adaptive security appliance is in multiple context mode, then you can assign one or more IPS virtual sensors to each context. Then, when you configure the context to send traffic to the AIP SSM, you can specify a sensor that is assigned to the context; you cannot specify a sensor that you did not assign to the context. If you do not assign any sensors to a context, then the default sensor configured on the AIP SSM is used. You can assign the same sensor to multiple contexts.

Note You do not need to be in multiple context mode to use virtual sensors; you can be in single mode and use different sensors for different traffic flows.

Prerequisites

For more information about configuring contexts, see the "Configuring a Security Context" section on page 5-17.

Detailed Steps
Command

Purpose
Step 1
context name
Example:
hostname(config)# context admin
hostname(config-ctx)# 
Identifies the context you want to configure. Enter this command in the system execution space.
Step 2
allocate-ips sensor_name [mapped_name] 
[default]
Example:
hostname(config-ctx)# allocate-ips 
sensor1 highsec
Enter this command for each sensor you want to assign to the context.

The sensor _name argument is the sensor name configured on the AIP SSM. To view the sensors that are configured on the AIP SSM, enter allocate-ips ?. All available sensors are listed. You can also enter the show ips command. In the system execution space, the show ips command lists all available sensors; if you enter it in the context, it shows the sensors you already assigned to the context. If you specify a sensor name that does not yet exist on the AIP SSM, you get an error, but the allocate-ips command is entered as is. Until you create a sensor of that name on the AIP SSM, the context assumes the sensor is down.

Use the mapped_name argument as an alias for the sensor name that can be used within the context instead of the actual sensor name. If you do not specify a mapped name, the sensor name is used within the context. For security purposes, you might not want the context administrator to know which sensors are being used by the context. Or you might want to genericize the context configuration. For example, if you want all contexts to use sensors called "sensor1" and "sensor2," then you can map the "highsec" and "lowsec" sensors to sensor1 and sensor2 in context A, but map the "medsec" and "lowsec" sensors to sensor1 and sensor2 in context B.

The default keyword sets one sensor per context as the default sensor; if the context configuration does not specify a sensor name, the context uses this default sensor. You can only configure one default sensor per context. If you want to change the default sensor, enter the no allocate-ips sensor_name command to remove the current default sensor before you allocate a new default sensor. If you do not specify a sensor as the default, and the context configuration does not include a sensor name, then traffic uses the default sensor on the AIP SSM/SSC.
Step 3
changeto context context_name
Example:
hostname# changeto context customer1
Changes to the context so you can configure the IPS security policy as described in "Diverting Traffic to the AIP SSM/SSC" section.
Examples

The following example assigns sensor1 and sensor2 to context A, and sensor1 and sensor3 to context B. Both contexts map the sensor names to "ips1" and "ips2." In context A, sensor1 is set as the default sensor, but in context B, no default is set so the default that is configured on the AIP SSM is used.
hostname(config-ctx)# context A
hostname(config-ctx)# allocate-interface gigabitethernet0/0.100 int1
hostname(config-ctx)# allocate-interface gigabitethernet0/0.102 int2
hostname(config-ctx)# allocate-interface gigabitethernet0/0.110-gigabitethernet0/0.115 
int3-int8
hostname(config-ctx)# allocate-ips sensor1 ips1 default
hostname(config-ctx)# allocate-ips sensor2 ips2
hostname(config-ctx)# config-url ftp://user1:passw0rd@10.1.1.1/configlets/test.cfg
hostname(config-ctx)# member gold
hostname(config-ctx)# context sample
hostname(config-ctx)# allocate-interface gigabitethernet0/1.200 int1
hostname(config-ctx)# allocate-interface gigabitethernet0/1.212 int2
hostname(config-ctx)# allocate-interface gigabitethernet0/1.230-gigabitethernet0/1.235 
int3-int8
hostname(config-ctx)# allocate-ips sensor1 ips1
hostname(config-ctx)# allocate-ips sensor3 ips2
hostname(config-ctx)# config-url ftp://user1:passw0rd@10.1.1.1/configlets/sample.cfg
hostname(config-ctx)# member silver
hostname(config-ctx)# changeto context A
...
What to Do Next

Change to each context to configure the IPS security policy as described in "Diverting Traffic to the AIP SSM/SSC" section.

Diverting Traffic to the AIP SSM/SSC

This section identifies traffic to divert from the adaptive adaptive security appliance to the AIP SSM/SSC.

Prerequisites

In multiple context mode, perform these steps in each context execution space.

Detailed Steps
Command

Purpose
Step 1
class-map name
Example:
hostname(config)# class-map ips_class
Creates a class map to identify the traffic for which you want to send to the AIP SSM/SSC.

If you want to send multiple traffic classes to the AIP SSM/SSC, you can create multiple class maps for use in the security policy.
Step 2
match parameter
Example:
hostname(config-cmap)# match access-list 
ips_traffic
Specifies the traffic in the class map. See the "Identifying Traffic (Layer 3/4 Class Map)" section on page 9-13 for more information.
Step 3
policy-map name
Example:
hostname(config)# policy-map ips_policy
Adds or edits a policy map that sets the actions to take with the class map traffic.
Step 4
class name
Example:
hostname(config-pmap)# class ips_class
Identifies the class map you created in Step 1.
Step 5
ips {inline | promiscuous} {fail-close | 
fail-open} [sensor {sensor_name | 
mapped_name}]
Example:
hostname(config-pmap-c)# ips promiscuous 
fail-close
Specifies that the traffic should be sent to the AIP SSM/SSC.

The inline and promiscuous keywords control the operating mode of the AIP SSM/SSC. See the "Operating Modes" section for more details.

The fail-close keyword sets the adaptive security appliance to block all traffic if the AIP SSM/SSC is unavailable.

The fail-open keyword sets the adaptive security appliance to allow all traffic through, uninspected, if the AIP SSM/SSC is unavailable.

If you use virtual sensors on the AIP SSM only, you can specify a sensor name using the sensor sensor_name argument. To see available sensor names, enter the ips ... sensor ? command. Available sensors are listed. You can also use the show ips command. If you use multiple context mode on the adaptive security appliance, you can only specify sensors that you assigned to the context (see the "Assigning Virtual Sensors to a Security Context (AIP SSM Only)" section). Use the mapped_name if configured in the context. If you do not specify a sensor name, then the traffic uses the default sensor. In multiple context mode, you can specify a default sensor for the context. In single mode or if you do not specify a default sensor in multiple mode, the traffic uses the default sensor that is set on the AIP SSM. If you enter a name that does not yet exist on the AIP SSM, you get an error, and the command is rejected.
Step 6
(Optional)
class name2
Example:
hostname(config-pmap)# class ips_class2
If you created multiple class maps for IPS traffic, you can specify another class for the policy.

See the "Information About Layer 3/4 Policy Maps" section on page 9-5 for detailed information about how the order of classes matters within a policy map. Traffic cannot match more than one class map for the same action type; so if you want network A to go to sensorA, but want all other traffic to go to sensorB, then you need to enter the class command for network A before you enter the class command for all traffic; otherwise all traffic (including network A) will match the first class command, and will be sent to sensorB.
Step 7
(Optional)
ips {inline | promiscuous} {fail-close | 
fail-open} [sensor {sensor_name | 
mapped_name}]
Example:
hostname(config-pmap-c)# ips promiscuous 
fail-close
Specifies that the second class of traffic should be sent to the AIP SSM/SSC.
Step 8
service-policy policymap_name {global | 
interface interface_name}
Example:
hostname(config)# service-policy 
tcp_bypass_policy outside
Activates the policy map on one or more interfaces. global applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
Monitoring the AIP SSM/SSC

See the "Monitoring SSMs and SSCs" section on page 58-9.

Configuration Examples for the AIP SSM/SSC

The following example diverts all IP traffic to the AIP SSM/SSC in promiscuous mode, and blocks all IP traffic if the AIP SSM/SSC card fails for any reason:
hostname(config)# access-list IPS permit ip any any
hostname(config)# class-map my-ips-class
hostname(config-cmap)# match access-list IPS
hostname(config-cmap)# policy-map my-ips-policy
hostname(config-pmap)# class my-ips-class
hostname(config-pmap-c)# ips promiscuous fail-close
hostname(config-pmap-c)# service-policy my-ips-policy global
The following example diverts all IP traffic destined for the 10.1.1.0 network and the 10.2.1.0 network to the AIP SSM in inline mode, and allows all traffic through if the AIP SSM fails for any reason. For the my-ips-class traffic, sensor1 is used; for the my-ips-class2 traffic, sensor2 is used.
hostname(config)# access-list my-ips-acl permit ip any 10.1.1.0 255.255.255.0
hostname(config)# access-list my-ips-acl2 permit ip any 10.2.1.0 255.255.255.0
hostname(config)# class-map my-ips-class
hostname(config-cmap)# match access-list my-ips-acl
hostname(config)# class-map my-ips-class2
hostname(config-cmap)# match access-list my-ips-acl2
hostname(config-cmap)# policy-map my-ips-policy
hostname(config-pmap)# class my-ips-class
hostname(config-pmap-c)# ips inline fail-open sensor sensor1
hostname(config-pmap)# class my-ips-class2
hostname(config-pmap-c)# ips inline fail-open sensor sensor2
hostname(config-pmap-c)# service-policy my-ips-policy interface outside
Feature History for the AIP SSM/SSC

Table 59-1 lists the release history for this feature.

Table 59-1 Feature History for the AIP SSM/SSC

Feature Name

Releases

Feature Information

AIP SSM

7.0(1)

The AIP SSM was introduced. The following command was introduced: ips.

Virtual sensors

8.0(2)

Virtual sensor support was introduced. Virtual sensors let you configure multiple security policies on the AIP SSM. The following command was introduced: allocate-ips.

AIP SSC for the ASA 5505

8.2(1)

The AIP SSC was introduced. The following commands were introduced: allow-ssc-mgmt, hw-module module ip, and hw-module module allow-ip.