IPS60StudentGuide Vol2 UnEncrypted

IPS
Implementing Cisco
Intrusion Prevention
Systems
Volume 2
Version 6.0
Student Guide
EPWS: 06.08.07
The PDF files and any printed representation for this material are the property of Cisco Systems, Inc.,
for the sole use by Cisco employees for personal study. The files or printed representations may not be
used in commercial training, and may not be distributed for purposes other than individual self-study.
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN
CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN ANY OTHER PROVISION OF
THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED
WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR
PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. This learning product may contain early release
content, and while Cisco believes it to be accurate, it falls subject to the disclaimer above.
Table of Contents
Volume 2
Advanced Cisco IPS Configuration 4-1
Overview 4-1
Module Objectives 4-1
Performing Advanced Tuning of Cisco IPS Sensors 4-3
Overview 4-3
Objectives 4-3
Sensor Configuration 4-4
IP Logging 4-11
Reassembly Options 4-17
How to Define Event Variables 4-20
Target Value Rating 4-22
Event Action Overrides 4-25
Event Action Filters 4-30
Risk Rating System 4-34
General Settings of Event Action Rules 4-43
Summary 4-46
Monitoring and Managing Alarms 4-47
Overview 4-47
Objectives 4-47
Cisco IEV Overview 4-48
Installing Cisco IEV 4-49
Configuring Cisco IEV 4-50
Viewing Events 4-64
Cisco Security Management Suite Overview 4-71
External Product Interface 4-75
Integrating Cisco Security Agent into an IPS Installation 4-80
Cisco ICS 4-84
Summary 4-87
Configuring a Virtual Sensor 4-89
Overview 4-89
Objectives 4-89
Virtual Sensor Overview 4-90
Preparing for Virtual Sensors 4-94
Creating Virtual Sensors 4-104
Summary 4-107
Configuring Advanced Features 4-109
Overview 4-109
Objectives 4-109
Anomaly Detection Overview 4-110
Anomaly Detection Components 4-112
Configuring Anomaly Detection 4-127
Monitoring Anomaly Detection 4-138
POSFP Overview 4-141
Operating System Identification 4-143
Configuring POSFP 4-144
Monitoring POSFP 4-154
Summary 4-157
Configuring Blocking 4-159
Overview 4-159
Objectives 4-159
Blocking Overview 4-160
ACL Considerations 4-170
How to Configure Automatic Blocking 4-180
How to Configure Manual Blocking 4-190
How to Configure a Master Blocking Scenario 4-195
Summary 4-203
Module Summary 4-204
References 4-206
Additional Cisco IPS Devices 5-1
Overview 5-1
Installing the Cisco Catalyst 6500 Series IDSM-2 5-3
Overview 5-3
Objectives 5-3
Cisco Catalyst 6500 Series IDSM-2 Overview 5-4
Installing the Cisco Catalyst 6500 Series IDSM-2 5-14
Configuring Cisco Catalyst 6500 Series IDSM-2 Interfaces 5-18
Monitoring the Cisco Catalyst 6500 Series IDSM-2 5-24
Maintaining the Cisco Catalyst 6500 Series IDSM-2 5-25
Summary 5-29
Initializing the Cisco ASA AIP-SSM 5-31
Overview 5-31
Objectives 5-31
Cisco ASA AIP-SSM Overview 5-32
Loading the Cisco ASA AIP-SSM 5-38
Initial Cisco ASA AIP-SSM Configuration Using Cisco ASDM 5-48
Configuring an IPS Security Policy 5-49
Summary 5-55
Module Summary 5-56
References 5-57
Cisco IPS Sensor Maintenance 6-1
Overview 6-1
Maintaining Cisco IPS Sensors 6-3
Overview 6-3
Objectives 6-3
Understanding Cisco IPS Licensing 6-4
How to Upgrade and Recover Sensor Images 6-12
How to Install Service Packs and Signature Updates 6-26
Password Recovery 6-35
How to Restore a Cisco IPS Sensor 6-44
Summary 6-46
Managing Cisco IPS Sensors 6-47
Overview 6-47
Objectives 6-47
Using the CLI to Monitor the Sensor 6-48
Using the Cisco IDM to Monitor the Sensor 6-61
Monitoring Using Cisco Security Manager 6-64
Monitoring Using SNMP 6-65
Summary 6-67
Module Summary 6-68
References 6-68
ii Implementing Cisco Intrusion Prevention Systems (IPS) v6.0 © 2007 Cisco Systems, Inc.
Module 4
Advanced Cisco IPS

Configuration
Overview
This module discusses how sensors can be tuned to provide the most beneficial and efficient
intrusion protection solution. It also examines some of the tools available to achieve this.
Module Objectives
Upon completing this module, you will be able to configure some of the more advanced
features of the Cisco Intrusion Prevention System (IPS) product line. This ability includes
being able to meet these objectives:
Use the Cisco IDM to tune a Cisco IPS sensor to work optimally in the network
Use additional monitoring tools to maximize alarm management efficiency
Explain the virtual sensor, its settings, and advantages
Explain, configure, and monitor anomaly detection and POSFP
Explain blocking concepts and use the Cisco IDM to configure blocking for a given
scenario
4-2 Implementing Cisco Intrusion Prevention Systems (IPS) v6.0 © 2007 Cisco Systems, Inc.
Lesson 1
Performing Advanced Tuning

of Cisco IPS Sensors
Overview
This lesson discusses how to tune Cisco Intrusion Prevention System (IPS) sensors to provide
the most beneficial and efficient intrusion protection solution.
Objectives
Upon completing this lesson, you will be able to use the Cisco IPS Device Manager (IDM) to
tune a Cisco IPS sensor to work optimally in the network. This ability includes being able to
meet these objectives:
Explain how to tune the sensor to avoid evasive techniques and provide network-specific
intrusion prevention
Explain the logging capabilities of the sensor, how to configure logging, and the
performance ramifications of logging
Describe the concept of IP fragment and TCP stream reassembly
Define and configure event variables
Explain and configure TVRs
Describe and configure event action overrides
Describe and configure event action filters
Describe the risk rating system and the values that it uses to calculate the risk rating
number
Describe and configure the general settings for event action rules
Sensor Configuration
This topic explains how to tune the sensor to avoid evasive techniques and provide network-
specific intrusion protection.
Sensor Tuning
Tuning is the process of

configuring your sensor so
that it provides the desired
level of information to
efficiently monitor and
protect your network.
© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-2
“Tuning” is a general term that is applied to the process of setting up a sensor in such a way
that it provides the correct level of information necessary for protecting your specific network.
If your sensor is to serve you efficiently, you must determine what level of events you want
from the sensor and what you are going to do with that event information. A sensor can provide
information on network events at as low a level as reporting every HTTP connection attempt or
every ping sweep or port sweep, but if you have no intention of using this data, there is little
reason to collect it.
One of the main purposes of tuning is to modify the sensor system behavior so that the alarms
that are generated have a much higher fidelity, or likelihood of being correct, and a lower
chance of reflecting anything other than a true event. Another purpose of tuning is to quickly
and efficiently identify attacks in progress in order to respond to them.
Sensor Tuning (Cont.)
To tune sensors successfully, you must have a good

understanding of the following:
– Your network and the individual devices being protected
– The protocols inspected by the signatures you are tuning
This knowledge enables you to recognize normal versus
abnormal network activity.
For tuning to be successful, you must be knowledgeable about your network and the individual
devices that the sensor is protecting. It is also important to have a good understanding of the
protocols used on your network; it is especially important to understand the protocol inspected
by any signature that you intend to tune. This knowledge enables you to recognize normal
versus abnormal network activity.
© 2007 Cisco Systems, Inc. Advanced Cisco IPS Configuration 4-5

Tuning Considerations
Important information to gather before you begin tuning:

The network topology
The network address space under observation and protection
Which inside addresses are statically assigned to servers and
which are DHCP addresses
The operating system running on each server
Applications running on the servers
The security policy
The information that you should gather before tuning your sensor includes, but is not limited to,
the following:
The network topology
The network address space under observation
Which inside addresses are statically assigned to servers and which are DHCP addresses
The operating system running on each server
Applications running on the servers
The security policy
This network knowledge is important if you have to sort through events that may or may not
have relevance and make decisions about how to react to each one. The decision is affected by
such information as the source and destination addresses of each event, the operating system of
a targeted server, the applications that are running on the server, and the normal behavior of the
server.
For example, you might see ping sweep events coming from IP address 10.0.1.99. These might
normally be considered suspicious events. However, if you know that 10.0.1.99 is a server
running HP OpenView network management software (which does ping sweeps as part of its
normal network discovery functionality), you can tune out the event by using the sensor alarm
channel filtering function so that the sensor never again triggers that event when it comes from
the 10.0.1.99 address.
Sensor Location
Inside
Internet
Outside of Firewall? Inside of Firewall?
The location of the sensor is important when tuning

for the following reasons:
The nature of the traffic that a sensor monitors varies.
The security policy with which the sensor interacts varies.
The location of the sensor has an important influence on how it is tuned. A typical deployment
location consideration is whether the sensor is watching traffic outside or inside the firewall.
Another consideration is whether the traffic being monitored is mostly Internet traffic coming
in or user traffic going out to the Internet, versus predominantly internal traffic.
Traffic inspected by a sensor outside a firewall tends to be unregulated. Sensors monitoring

traffic outside a firewall see scans, sweeps, and every Internet worm and attack that exists,
along with potentially large numbers of spoofed packets from around the globe. This amount of
information makes it much more difficult to distinguish true alarms from noise or false alarms.
A possible strategy for a sensor outside a firewall is to use the event stream from the sensor to
identify trends.
When the sensor is outside the firewall, consider these tuning guidelines:
Avoid assigning a high severity level to any individual event.
Turn off all response actions.
Use the sensor primarily to look for trends on the Internet such as activity explosions,
which can indicate attacks such as Code Red or Nimda.
Another reason why location plays an important role is that the security policy the sensor must
enforce may vary at different deployment points. A sensor that monitors traffic outside a
perimeter firewall can function independently of security policy because there is no policy to
enforce; however, a firewall on a tightly controlled demilitarized zone (DMZ) segment could
have a much tighter policy. If Telnet and FTP are not allowed on the DMZ, it would be
reasonable to set high severity levels for Telnet and FTP signatures on the DMZ sensor so that
those protocols generate a high-severity event any time that they are seen.

Phases of Tuning
These phases of tuning correspond to the length of time

that the sensor has been running at the current location:
Deployment phase
Tuning phase
Maintenance phase
The phases of tuning correspond to the length of time that the sensor has been running at the
current location. These are the phases:
Deployment phase: This phase is completed during initial setup and deployment. During
this phase, the sensor is normally running the default configuration, which is generally
close to being tuned for the average deployment. Depending on your security policy and
the location of your sensor, you may choose to turn on specific signatures for activity that
you want to track. You typically do this using one of the connection signatures to track
activity on a specific TCP or User Datagram Protocol (UDP) port or a type of Internet
Control Message Protocol (ICMP) packet.
Tuning phase: Although it could last up to several weeks, this phase usually takes place
during the two weeks after the end of the deployment phase. Most of the activity and work
occurs during the tuning phase. Before you start the tuning phase, the sensor should be up
and running for a continuous period so that it sees a normal sampling of network activity.
During this time, it is possible for the sensor to fire a considerable number of events. Do
not delete these events, because they can be used extensively in the tuning process. Observe
which alarm types are being triggered most frequently and note their source and destination
addresses. Using the Network Security Database (NSDB) as a reference, you can then
proceed to examine each of the top alarm sources to determine whether an event worth
investigating is occurring.
Maintenance phase: This phase is completed periodically as tuning becomes necessary,
such as each time a signature update is applied to the sensor. Because signature updates add
new signatures and modify the way in which existing ones fire, maintenance tuning could
include turning alarms off, modifying their default severity levels or parameters, or creating
filters either on the sensor or on your monitoring application.
Methods of Tuning
Some tuning methods involve configuring the sensor

while others involve configuring your monitoring
application. On the sensor:
Enable and disable signatures
Change the parameters of signatures
Create policies to override event action
Create event action filters
Methods of tuning include the following:

Enabling and disabling signatures: This method is best used on a case-by-case basis. For
example, you might want to enable a signature that is disabled by default, because it is of
interest in your particular situation. Exercise caution when disabling signatures to avoid
compromising your network. Disabling signatures is usually done only when the signature
is of no interest or is providing no foreseeable useful data.
Changing the parameters of the signatures: This tuning mechanism is most commonly
used to control the firing of signatures that have thresholds. For example, a small company
may set the ICMP Network Sweep with Echo signature of a sensor to fire if 5 hosts receive
echo request packets within 15 seconds. A larger company, with a higher level of benign
ICMP activity, might need to set the same signature to 10 hosts in 15 seconds to keep the
signature from firing on benign activity.
Creating event action rules: This method is the most common method of tuning and is the
best method to decrease false positives. You can use event action filters in conjunction with
risk ratings to ensure that alerts are generated only for significant events. You can also use
event action filters to prevent the sensor from taking a specific action, including Produce
Alert, when an event occurs, or you can consume the event completely by creating a filter
that removes all actions from the event. For example, by specifying the source of traffic
that is triggering false positives, you can prevent the sensor from generating unnecessary
alerts.

Global Sensor Tuning
There are guidelines to help you maximize the efficiency of your

sensor via settings for the following:
– Individual signatures
– Target systems
– Monitoring applications
You can configure the following global sensor settings to ensure
that valuable system resources are not wasted:
– IP logging
– IP fragment reassembly
– TCP stream reassembly
You can dramatically increase the benefits of your sensor by adhering to the guidelines that
apply to settings for individual signatures and monitoring applications. However, you can
further increase these benefits by increasing the efficiency of your sensor via global sensor
settings that can conserve valuable system resources. The following global sensor settings can
be configured:
IP logging
IP fragment reassembly
TCP stream reassembly
IP Logging
This topic explains the logging capabilities of the sensor, how to configure logging settings via
the Cisco IDM, and the effects of IP logging on the sensor.
IP Logging
IP logs are generated in two ways:

– Add IP logs on the Add IP Logging dialog box
– Select one of the following as the event action for a signature:
Log Attacker Packets
Log Pair Packets
Log Victim Packets
The IP log file is in libpcap format.
The Cisco IPS 4240, 4255, and 4260 Sensors are diskless
systems that store IP logs in RAM.
The IP logging feature provides the ability to capture raw, unaltered IP packets. IP logs differ
from alerts. They are copies of the binary packets that the sensor sees on the network.
Information from IP logs can be used for confirmation, damage assessment, and forensic
evidence.
The simplest IP logging consists of an IP address. You can configure the sensor to capture all
IP traffic associated with a host that you specify by IP address. The sensor begins collecting as
soon as it sees the first IP packet with this address and continues collecting depending on the
parameters that you have set. You can specify in minutes how long you want the traffic to be
logged at the IP address, how many packets you want logged, and how many bytes you want
logged. The sensor stops logging IP traffic at the first parameter that you specify.
The IP Logging panel displays all IP logs that are available for downloading on the system.
IP logs are generated in two ways:

When you add IP logs on the Add IP Logging dialog box
When you choose one of the following as the event action for a signature:
— Log Attacker Packets
— Log Pair Packets
— Log Victim Packets
When the sensor detects an attack based on this signature, it creates an IP log. The event alert
that triggered the IP log appears in the IP logging table.

The Cisco IPS 4240, 4255, and 4260 Sensors are diskless systems that store IP logs in RAM.
One of the largest problems with storing information to a fixed resource such as a hard drive or
memory is handling all the error conditions properly. The IPS IP logging design ensures that
there is always room to write a new IP log file.
When the sensor starts, it sets up a reusable ring of files for IP logging. After 512 MB of data
has been logged, the sensor starts reusing these files. The sensor reuses files by overwriting the
file with the oldest closing time. A file is closed when it reaches its configured expiry or when
its full size has been used. Because the files are preallocated, there is no reason to delete them;
however, remember that IP logging does affect performance.
You can copy IP log files to an FTP or Secure Copy Protocol (SCP) server so that you can view
them with a sniffing tool such as Ethereal or tcpdump. The files are stored in pcap binary form
with the pcap file extension.
You can use the command iplog-status at the command-line interface (CLI) to verify that IP
logs are being created and display a description of the available IP log contents. IP log files can
be retrieved from the sensor before or after they are closed. If you try to retrieve an IP log
before the file closes, you get all parts of any packet, but you may not get the last couple of
packets. IP log files can be retrieved by the following methods:
Use the CLI copy command to copy the IP log files to another host system using FTP or
SCP.
Download the IP log files via the Cisco IDM.
After retrieving the IP log files, you can use a network protocol analyzer to examine the data.
You can use Ethereal, tcpdump, or any other reader that understands libpcap format. Libpcap
format contains the data of the captured packets in binary form and is a standard used by
network tools such as WinDump, Ethereal, and Snort.
Caution Because of its impact on performance, IP logging should only be used temporarily for such
purposes as attack confirmation, damage assessment, or forensic evidence.
Configuring Manual IP Logging
Monitoring
Add
IP Logging
Stop
To log IP traffic for a particular host, follow these steps:
Step 1 Click the Monitoring button.
Step 2 Choose IP Logging from the table of contents. The IP Logging panel is displayed.
Step 3 Click Add. The Add IP Logging window opens.
Note If you choose a log ID and click Stop, the Stop IP Logging window opens, asking if you are
sure you want to stop logging for the ID you selected. If you click OK, the logging entry is
removed from the IP Logging panel.

Configuring Manual IP Logging (Cont.)
IP Address
Duration
Packets
Bytes
Apply
Step 4 In the IP Address field, enter the IP address of the host from which you want IP logs
to be captured. You receive an error message if you are trying to add a capture that
exists and is in the added or started state.
Step 5 In the Duration field, enter the number of minutes that you want IP logs to be
captured. Valid values range from 1 to 60 minutes.
Step 6 (Optional) Enter the number of packets that you want to be captured in the Packets
field. Valid values range from 0 to 4294967295.
Step 7 (Optional) Enter the number of bytes that you want to be captured in the Bytes field.
Valid values range from 0 to 4294967295.
Step 8 Click Apply to apply your changes and save the revised configuration. The IP
address is displayed on the IP Logging panel along with the following information:
Log ID: This is the ID of the IP log.
Status: This is the status of the IP log. Valid values are added, started, or
completed.
Event Alert: This is the event alert, if any, that triggered the IP log.
Start Time: This is the time stamp of the first captured packet.
Current End Time: This is the time stamp of the last captured packet. There is
no time stamp if the capture is not complete.
Packets Captured: This is the current count of the packets captured.
Bytes Captured: This is the current count of the bytes captured.
You can edit an existing log entry by choosing it in the list and then clicking Edit. The Edit IP
Logging window opens, enabling you to edit the Duration, Packets, and Bytes values for the IP
address for which logging is configured.
Viewing IP Logs
Monitoring
IP Logging
Download
Complete the following steps to view IP logs:
Step 1 To download an IP log, from the IP Logging panel choose the log ID and click
Download. The Save As dialog box appears.
Step 2 Save the log to your local machine. You can view it with Ethereal.

IP Log Settings
Configuration
Signature
Definitions:
sig0
Max IP Log Packets
Max IP Log Bytes IP Log Time
You can configure a sensor to generate an IP session log when the sensor detects an attack.
When IP logging is configured as a response action for a signature and the signature is
triggered, all packets to and from the source address of the alert are logged for a specified
period of time.
To configure IP logging parameters, follow these steps:
Step 1 Log into the Cisco IDM using an account with administrator or operator privileges.
Step 2 Click Configuration and choose Signature Definitions > sig0 and click the
Miscellaneous tab.
The Miscellaneous tab appears.

Step 3 Under IP Log in the Max IP Log Packets field, enter the number of packets that you
want logged.
Step 4 In the IP Log Time field, enter the duration that you want the sensor to log.
A valid value is 1 to 60 minutes. The default is 30 minutes.
Step 5 In the Max IP Log Bytes field, enter the maximum number of bytes that you want
logged.
Step 6 Click Apply to apply your changes and save the revised configuration.
Reassembly Options
This topic describes IP fragment and TCP stream reassembly. It also explains how their settings
affect the sensor.
Reassembly Overview
You can configure sensor reassembly settings for both IP

fragments and TCP streams.
Reassembly settings affect the overall sensing function of the
sensor, but are not necessarily specific to a particular signature or
set of signatures.
Reassembly settings ensure that valuable system resources are
not wasted.
Reassembly options affect the sensing function but are not necessarily specific to a particular
signature or set of signatures. Reassembly settings ensure that valuable system resources are
not wasted. In the Cisco IDM, you can choose two reassembly options:
For IP fragments
For TCP streams

Configuring Reassembly Options
Miscellaneous
Configuration
Fragment
Reassembly
IP Reassembly
Mode
Signature
Definition: TCP Handshake
sig0 Required
Stream
Reassembly TCP Reassembly
Mode
You can use the Miscellaneous tab in the Cisco IDM to configure both IP fragment reassembly
and TCP stream reassembly. Complete the following steps to configure IP fragment reassembly
options:
Step 1 Click the Configuration button.
Step 2 Choose Signature Definitions from the table of contents.
Step 3 Click sig0.
Step 4 From the sig0 panel, click the Miscellaneous tab. The Miscellaneous panel is
displayed.
Step 5 Under Fragment Reassembly, click the green icon next to IP Reassembly Mode and
choose the operating system that you want to use to reassemble the fragments.
Complete the following steps to configure TCP stream reassembly options:
Step 2 Choose Signature Definitions from the table of contents.
Step 3 Click sig0.
Step 4 From the sig0 panel, click the Miscellaneous tab. The Miscellaneous panel is
displayed.
Step 5 Under Stream Reassembly, click the green icon next to TCP Handshake Required
and choose Yes if you want the sensor to only track sessions for which the three-way
handshake is completed. Otherwise, choose No.
Step 6 Click the green icon next to TCP Reassembly Mode and choose one of the following
modes for the sensor to use for reassembling TCP sessions:
Strict: This mode allows only the next packet that is expected in a given stream.
If a packet is missed for any reason, reassembly terminates for that stream.
Loose: This mode allows gaps in the sequence. If a packet in a stream is missed,
stream reassembly continues on a best-effort basis. Because this option can
consume excessive resources on the sensor, it should be used only in
environments where packets might be dropped.
Asymmetric: This mode allows asymmetric traffic, where acknowledgments
(ACKs) traverse a different path and are not seen by the sensor, to be
reassembled. This option disables TCP window evasion checking.
Note To remove your changes, click Reset.

How to Define Event Variables
This topic defines event variables and how to configure them.
Configuring Event Variables

Configuration
Event
Action
Rules:
rules0
Event
Variables
Add
You can create event variables and then use those variables in event action filters. If you want
to use the same value within multiple filters, use a variable. When you change the value of the
variable, any filter using that variable is updated with the new value.
Note You must preface the variable with a dollar sign ($) to indicate that you are using a variable
rather than a string.
For example, if you have an IP address space that applies to your engineering group, and there
are no Microsoft Windows systems in that group and you are not worried about any Windows-
based attacks on that group, you could set up a USER-ADDR1 variable to be the IP address
space of the engineering group. You could then use this variable to configure a filter that would
ignore all Windows-based attacks for USER-ADDR1.
Complete the following steps to create an event variable:

Step 2 Choose Event Action Rules from the table of contents.
Step 3 Click rules0.
Step 4 From the ruls0 panel, click the Event Variables tab. The Event Variables panel is
displayed.
Step 5 Click Add. The Add Variable window opens.
Configuring Event Variables (Cont.)
Name
Type
Value
Step 6 Enter a name for the variable in the Name field. A valid name can only contain
numbers or letters. You can also use a hyphen (-) or an underscore (_). You cannot
change the name of an existing variable.
Note The Type drop-down menu identifies the variable as an address.
Step 7 Enter the values for this variable in the Value field. You can use commas as
delimiters, but ensure that there are no spaces after the comma. Otherwise, you
receive a Validation Failed error. The following is an example of designating both
the 10.0.1.0 and the 172.16.1.0 network, both with a netmask of 255.255.255.0:
10.0.1.0-10.0.1.255,172.16.1.0-172.16.1.255
Step 8 Click OK. The new variable is displayed in the list on the Event Variables panel.
Note Click Reset to refresh the panel by replacing any edits that you made with the previously
configured value.
You can edit an existing variable by choosing it in the list and then clicking Edit. The Edit
Event Variable window opens, enabling you to edit the variable values.

Target Value Rating
This topic defines the target value rating (TVR) and describes how to configure it.
Target Value Ratings
Low Medium High Mission Critical No Value
You can assign a target value rating to your network assets.

The target value rating is one of the factors used to
calculate the risk rating value for each alert.
You can assign a target value rating to your network assets. The TVR is one of the factors used
to calculate the risk rating value for each alert. You can assign different target value ratings to
different targets. Events with a higher risk rating trigger more severe signature event actions.
These values are available:

Low
Medium
High
Mission Critical
No Value
Configuring TVRs
Target Value
Configuration Rating
Event Action
Rules:rules0
Add
Complete the following steps to configure a target value rating:
Step 4 From the rules0 panel, click the Target Value Rating tab. The Target Value Rating
panel is displayed.
Step 5 Click Add to create a new TVR. The Add Target Value Rating window opens.

Configuring TVRs (Cont.)
Target Value
Rating
Target IP
Addresses
Step 6 Choose a rating from the Target Value Rating (TVR) drop-down menu. The values
are High, Medium, Low, Mission Critical, or No Value.
Step 7 Enter the IP address of the network asset in the Target IP Address(es) field. For a
range of IP addresses, enter the lowest address followed by a hyphen and the highest
address in the range. The following is an example of a range of addresses:
10.10.2.1-10.10.2.30
Step 8 Click OK. The new TVR is displayed in the list on the Target Value Rating panel.
To edit an existing TVR, choose it from the list and click Edit. The Edit Target Value Rating
window opens, enabling you to modify the values in the Target IP Address(es) field.
Event Action Overrides
This topic defines event action overrides and describes how to configure them.
Deny Log Alert
You can add an event action override to change the

actions associated with an event based on the
calculated risk.
As mentioned in the “How to Define Event Variables” topic, you can add an event action
override to change the actions associated with an event based on specific details about that
event.

Configuring Event Action Overrides
Configuration
Event Action
Rules:
rules0 Use Event Action Overrides
Add
Complete the following steps to configure event action overrides:
Step 3 Click rules0
Step 4 From the rules0 panel, click the Event Action Overrides tab. The Event Action
Overrides panel is displayed.
Step 5 Check the Use Event Action Overrides check box.
Step 6 Click Add to create a new event action override. The Add Event Action Override
window opens.
Configuring Event Action Overrides
(Cont.)
Event
Action
Enabled
Risk
Rating
Step 7 From the Event Action drop-down menu, choose the event action to which this
override will correspond. This specifies the event action that will be added to an
event if the conditions of the override are satisfied. You can choose from the
following options:
Deny Attacker Inline: This option terminates the current packet and future
packets from this attacker address for a specified period of time. The option is
only for inline mode.
Note The sensor maintains a list of the attackers currently being denied by the system. To remove
an entry from the denied attacker list, you can view the list of attackers and clear the entire
list, or you can wait for the timer to expire. The timer is a sliding timer for each entry.
Therefore, if attacker A is currently being denied but issues another attack, the timer for
attacker A is reset and attacker A remains in the denied attacker list until the timer expires. If
the denied attacker list is at capacity and cannot add a new entry, the packet is still denied.
Deny Attacker Service Pair Inline: (Inline mode only) This option does not
transmit this packet or future packets on the attacker address victim port pair for
a specified period of time.
Deny Attacker Victim Pair Inline: (Inline mode only) This option does not
transmit this packet or future packets on the attacker-victim address pair for a
specified period of time.
Deny Connection Inline: This option terminates the current packet and future
packets on this TCP flow. This option is only for inline mode.
Deny Packet Inline: This option terminates the packet. This option is only for
inline mode.
Log Attacker Packets: This option starts IP logging on packets that contain the
attacker address and sends an alert. This action causes an alert to be written to
the Event Store even if Produce Alert is not selected.

Log Attacker/Victim Pair Packets: This option starts IP logging on packets
that contain the attacker-victim address pair and sends an alert. This action
causes an alert to be written to the Event Store even if Produce Alert is not
selected.
Log Victim Packets: This option starts IP logging on packets that contain the
victim address and sends an alert. This action causes an alert to be written to the
Event Store even if Produce Alert is not selected.
Produce Alert: This option writes the event to the Event Store as an alert.
Produce Verbose Alert: This option includes an encoded dump of the
offending packet in the alert. This action causes an alert to be written to the
Request Block Connection: This option sends a request to the Attack Response
Controller (ARC) to block this connection.
Request Block Host: This option sends a request to the ARC to block this
attacker host.
Request SNMP Trap: This option sends a request to the Notification
Application component of the sensor to perform Simple Network Management
Protocol (SNMP) notification. This action causes an alert to be written to the
Reset TCP Connection: This option sends TCP resets to hijack and terminate
the TCP flow.
Step 8 To enable the override, click the Yes radio button.
Step 9 Use the Risk Rating Minimum and Maximum fields to enter a risk rating range that
triggers the event action override. (Risk rating is discussed in more detail in the
“Risk Rating System” topic in this lesson.) If an event has a risk rating within this
range, the event action is added to other configured actions for the event. All values
should be between 0 and 100, and the value in the Minimum field must be less than
or equal to the value in the Maximum field. The risk rating system will be discussed
in the “Risk Rating System” topic.
Note To undo your changes and close the Add Event Action Override dialog box, click Cancel.
Step 10 Click OK. The new event action override is displayed in the list on the Event Action
Overrides panel.
Note If you do not check the Use Event Action Overrides check box, none of the event action
overrides are enabled, regardless of the value that you set.
You can edit an existing event action override by choosing it from the list and clicking Edit.
The Edit Event Action Overrides window opens, enabling you to edit the Enabled and Risk
Rating values for the specified event action. You can also enable, disable, or delete event action
overrides by choosing the event action override and clicking the button for the desired action.

Event Action Filters
This topic defines event action filter functionality and describes how to configure event action
filters.
Event Action Filters

1
An attacker scans the network.
2
The scanning traffic matches a
signature, the signature fires, and the
traffic is dropped.
3
The sensor allows identical
scanning behavior through from
the management system.
Target
Management
System
You can configure event action filters to remove specific actions from an event or to discard an
entire event and prevent further processing by the sensor. You can also use the variables that
you defined on the Event Variables panel to group addresses for your filters.
Configuring Event Action Filters
Event Action
Filters
Configuration
Add
Move Up Edit
Move Down
Event Action
Rules: Enable
rules0
Disable
Delete
Use the Event Action Filters panel to add and manage event action filters. Choose an event
action filter and then click the following buttons to perform the corresponding tasks:
Move Up: This button moves the selected event action filter up one row in the list. This
action results in a change in the processing order of the filters.
Move Down: This button moves the selected filter down one row in the list. This action
results in a change in the processing order of the filters.
Edit: This button opens the Edit Event Action Filter window. This enables you to modify
the filter values.
Note You must preface the variable with a dollar sign ($) to indicate that you are using a variable
rather than a string. Otherwise, you receive the Bad Source and Destination error.
Complete the following steps to create an event action filter:
Step 4 From the rules0 panel, click the Event Action Filters tab. The Event Action Filters
panel is displayed.
Step 5 Click Add. The Add Event Action Filter window opens.

Configuring Event Action Filters (Cont.)
Signature ID Active
Subsignature ID Enabled
Victim Address Attacker

Address
Victim Port
Attacker Port
Risk Rating
Actions to OS Relevance
Subtract
Deny Percentage
Stop on Match
Comments
Step 6 Enter a name for your filter.
Step 7 Click the Yes Active radio button. The Yes button is selected by default.
Step 8 Click the Yes Enabled radio button to enable the filter. The Yes button is selected by
default.
Step 9 Enter the signature IDs of all the signatures to which this filter should be applied in
the Signature ID field. You can enter a single signature ID, a list, or a range.
Step 10 Enter the subsignature IDs of the subsignatures to which this filter should be applied
in the SubSignature ID field.
Step 11 Enter the IP address of the source host in the Attacker Address field. You can enter a
single IP address, a range of addresses, or an event variable defined in the Event
Variables panel. If you use a variable, preface it with a dollar sign ($).
Step 12 Enter the port number used by the attacker to send the offending packet in the
Attacker Port field. You can also enter a range of ports.
Step 13 Enter the IP address of the recipient host in the Victim Address field. You can enter
a single IP address, a range of addresses, or an event variable defined in the Event
Variables panel. If you use a variable, preface it with a dollar sign ($).
Step 14 Enter the port number used by the victim host to receive the offending packet in the
Victim Port field. You can also enter a range of ports.
Step 15 Assign a risk rating range to this filter. If an event has a risk rating within the range
that you configure here, the event is processed against the rules of this event filter.
Step 16 Choose from the Actions to Subtract list the actions that you want this filter to
remove from the event should the conditions of the event meet the criteria of the
event action filter.
Step 17 Choose which OS Relevance values apply.
Step 18 Modify the Deny Percentage if desired.
Step 19 Choose one of the following Stop on Match radio buttons, which determine whether
this event is processed against remaining filters in the event action filters list:
Click Yes if you want the Event Action Filters component to stop processing
after the actions of this particular filter have been removed. Any remaining
filters are not processed; therefore, no additional actions can be removed from
the event.
Click No if you want to continue processing additional filters for a match until a
Stop flag is encountered.
Step 20 Enter any comments that you want to store with this filter in the Comments field,
such as the purpose of this filter or why you have configured this filter in a particular
way.
Step 21 Click OK. The new event action filter is displayed in the list on the Event Action
Filters panel.
Note If you do not check the Use Event Action Filters check box on the Event Action Filters panel,
none of the event action filters will be enabled regardless of the value that you set here.

Risk Rating System
This topic describes the risk rating system and the values that it uses to calculate the risk rating
number.
Risk Rating System Overview
The risk rating is associated with alerts not signatures.

It is calculated from several components, some of which are
configured, some collected, and some derived.
In contrast to simplistic alert rating models that are commonly used in the industry, Cisco IPS
Sensor Software Version 6.0 delivers unique risk ratings that are assigned to alerts generated
from the Cisco IPS sensors. The intent of this risk rating is to provide the administrator with an
indication of the relative risk of the traffic or offending host continuing to access the network.
This rating can be used either to highlight the events that require immediate administrator
attention in the classic intrusion detection system (IDS) promiscuous mode, or to provide a
means for developing risk-oriented event action policies when you employ the sensor in the
inline intrusion protection system mode.
The risk rating is an integer value in the range from 0 to 100. The higher the value, the greater
the security risk of the trigger event for the associated alert. The risk rating is a calculated
number that is based on several components and is used by event action overrides.
Components That Make Up the Risk
Rating
Attack Severity Rating

Target Value Rating
Signature Fidelity Rating
Attack Relevancy Rating
Promiscuous Delta
Watch List Rating
There are six values used to calculate the risk rating:

Attack Severity Rating (ASR)
Target Value Rating (TVR)
Signature Fidelity Rating (SFR)
Attack Relevancy Rating (ARR)
Promiscuous Delta (PD)
Watch List Rating (WLR)
Some of these values the administrator can configure, some values are calculated.

Attack Severity Rating
ASR is configured on a per-signature basis and indicates how

dangerous the event detected is:
– Informational (25)
– Low (50)
– Medium (75)
– High (100)
It does not indicate how accurately the event is detected.
The ASR is determined by the severity level configured for the signature. The severity level
can be informational, low, medium, or high. Each of these severities has an associated numeric
value which the risk rating formula uses for the ASR value.
Informational (25)
Low (50)
Medium (75)
High (100)
The ASR is not a determination of the accuracy of the signature definition. It is only an
indication of the seriousness of the attack.
Target Value Rating
TVRs are configured in event action rules:

– Zero (50)
– Low (75)
– Medium (100)
– High (150)
– Mission Critical (200)
The default is Medium.
When you configure TVRs in the event action rules, numeric values are assigned and used to
calculate the risk rating value. The TVR is a user-configurable value that identifies the
importance of a network asset, through its IP address. You can develop a security policy that is
more stringent for valuable corporate resources and looser for less important resources. For
example, you could assign a TVR to the company web server that is higher than the TVR that
you assign to a desktop node. In this example, attacks against the company web server have a
higher risk rating than attacks against the desktop node.
The following are the current numeric values for the configured targets:
Zero (50)
Low (75)
Medium (100)
High (150)
Mission Critical (200)

Signature Fidelity Rating
SFRs are configured on a per-signature basis.

Valid numbers are 0–100.
SFR is meant to indicate how accurately the signature detects the
event or condition it describes.
This value has nothing to do with the potential damage done by
the attack. The seriousness of the attack is calculated in the ASR
value.
SFRs are configurable by IPS administrators on a per-signature basis. It is an indication of the

confidence that the signature writer has in the signature accuracy; it is not an indication of the
seriousness of the potential attack. SFR is a weight associated with how well this signature
might perform in the absence of specific knowledge of the target.
Attack Relevancy Rating
The ARR is a derived value. It is not configurable.

ARR values are:
– Relevant (10)
– Unknown (0)
– Not Relevant (–10)
Relevant operating systems are configured on a per-signature
basis.
The relevancy of any target operating system is determined at the
time of the alert.
The ARR adds the relevance of an attack to the risk rating equation. For example, a Microsoft
Internet Information Server (IIS) buffer overflow attack is serious. But if it is launched against
an Apache server, it is not relevant. Therefore, to assist IPS analysts in prioritizing their efforts,
the ARR is included in the risk rating by raising the ARR for attacks against legitimate targets,
and lowering it against others.

Promiscuous Delta
PD is configured on a per-signature basis.

Valid numbers are 0–30.
The PD is relevant only when the sensor is in promiscuous mode.
If the sensor is inline, the PD is subtracted from the risk rating.
PD lowers the risk rating of certain alerts in promiscuous mode. Because the sensor does not
know the attributes of the target system and in promiscuous mode cannot deny packets, it is
useful to lower the prioritization of promiscuous alerts (based on the lower risk rating) so that
the administrator can focus on investigating higher risk rating alerts.
Note It is not recommended that the PD value be changed.
Watch List Rating
If the attacker for the alert is found on the watch list, the WLR for
that attacker is added to the rating.
Valid numbers for this are 0–100.
– Cisco Security Agent only uses 0–35.
The CiscoWorks Management Center for Cisco Security Agent receives host posture
information from the Cisco Security Agent software that it manages. It also maintains a watch
list of IP addresses that it has determined should be quarantined from the network.
The CiscoWorks Management Center for Cisco Security Agent sends two types of events to the
sensor—host posture events and quarantined IP address events. Host posture events contain the
following information:
Cisco Security Agent status
Host system hostname
Set of IP addresses enabled on the host
Cisco Security Agent software version
Cisco Security Agent polling status
Cisco Security Agent test mode status
ARC posture
The quarantined IP address events contain the following information:

Reason for the quarantine
Protocol associated with a rule violation (TCP, UDP, or ICMP)
Indication of whether a rule-based violation was associated with an established session or a
UDP packet
The sensor uses the information from these events to determine the risk rating increase based
on the information in the event and the risk rating configuration settings for host postures and
quarantined IP addresses.
Note The host posture and watch list IP address information is not associated with a virtual
sensor, but is treated as global information.

Risk Rating Formula
The risk rating is calculated by the following formula:
RR = ASR * TVR * SFR + ARR – PD + WLR

10,000
Valid numbers are from 0–100.
A risk rating is a value between 0 and 100 that represents a numerical quantification of the risk
associated with a particular event on the network. The calculation takes into account the value
of the network asset being attacked (for example, a particular server), so it is configured on a
per-signature basis (ASR and SFR) and on a per-server basis (TVR).
Risk ratings let you prioritize alerts that need your attention. These risk rating factors take into
consideration the severity of the attack if it succeeds, the fidelity of the signature, and the
overall value of the target host to you. The risk rating is reported in the events.
The following values are used to calculate the risk rating for a particular event:
ASR: This is a weight associated with the severity of a successful exploit of the
vulnerability. The ASR is derived from the alert severity parameter of the signature.
SFR: This is a weight associated with how well this signature might perform in the absence
of specific knowledge of the target. SFR is calculated by the signature author on a per-
signature basis. The signature author defines a baseline confidence ranking for the accuracy
of the signature in the absence of qualifying intelligence on the target. It represents the
confidence that the detected behavior would produce the intended effect on the target
platform if the packets under analysis were allowed to be delivered. For example, a
signature that is written with very specific rules (specific regular expression) has a higher
SFR than a signature that is written with generic rules.
TVR: This is a weight associated with the perceived value of the target. TVR is a user-
configurable value that identifies the importance of a network asset through its IP address.
You can develop a security policy that is more stringent for valuable corporate resources
and looser for less important resources. For example, you could assign a TVR to the
company web server that is higher than the TVR that you assign to a desktop node. In this
example, attacks against the company web server have a higher risk rating than attacks
against the desktop node.
General Settings of Event Action Rules
This topic explains the event action rules general settings and how to configure them.
General Settings
You can configure general settings that apply to the event action
rules, such as whether you want to use the summarizer and the
meta event generator.
You can also configure how long you want to deny attackers, the
maximum number of denied attackers, and how long you want
blocks to last.
You can configure the general settings that apply to the event action rules, such as whether you
want to use the summarizer and the meta event generator. The summarizer groups events into a
single alert, thus decreasing the number of alerts that the sensor sends out. The meta event
generator processes the component events, which lets the sensor watch for suspicious activity
transpiring over a series of events.
You can configure settings for how long you want to deny attackers, the maximum number of
denied attackers, and how long you want blocks to last.

Configuring General Settings
General
Settings
Configuration
Use
Event Action
Summarizer
Rules:rules0
Use Meta Event

Generator
Use Threat Rating

Adjustment
Maximum
Deny
Block Action Denied
Attacker
Duration Attackers
Duration
Complete the following steps to configure the general settings for event action rules:
Step 4 From the rules0 panel, click the General Settings tab.
Step 5 If you want to enable the summarizer feature, check the Use Summarizer check
box.
Step 6 If you want to be able to use meta events, check the Use Meta Event Generator
check box.
Caution The summarizer and the meta event generator operate at a global level, so enabling these
options affects all sensor processing of these features.
Step 7 Enter the number of seconds that you want to deny an attacker inline in the Deny
Attacker Duration field.
Step 8 Enter the number of minutes that you want to block a host or connection in the
Block Action Duration field.
Step 9 Enter the maximum number of attackers that you want to deny at any one time in the
Maximum Denied Attackers field.
Click Apply to apply your changes and save the revised configuration.
Threat Rating
A threat rating is an adjusted risk rating.

Most response actions have a threat rating adjustment, which is
subtracted from the risk rating value.
When multiple actions are configured, the largest threat rating
adjustment is the only one subtracted from the risk rating.
A threat rating never goes below 0.
If disabled, the threat rating equals the risk rating.
Threat Rating = Risk Rating – Threat Rating

Adjustment
Threat rating adjustments correlate with actions taken by the sensor. Depending on which
actions you configure, the risk rating is lowered based on the value associated with those
actions, and which actions occur. The amount by which the risk rating is reduced is based on
the following actions:
45: deny-attacker-inline
40: deny-attacker-victim-pair-inline
40: deny-attacker-service-pair-inline
35: deny-connection-inline
35: deny-packet-inline
35: modify-packet-inline
20: request-block-host
20: request-block-connection
20: reset-tcp-connection
20: request-rate-limit

Summary
This topic summarizes the key points that were discussed in this lesson.
Summary
To maximize the efficiency of the sensor, configure the following

on your sensor according to the needs of your particular network:
– Signature parameters
– IP logging
– Reassembly options
– Alarm channel event filters
IP logging captures raw, unaltered IP packets that can be used for
confirmation, damage assessment, and forensic evidence. You
can configure a sensor to automatically generate an IP log when it
detects an attack.
IP fragment reassembly options and TCP stream reassembly
options apply to sensors globally and enable you to conserve
valuable system resources.
Summary (Cont.)
Event variables facilitate the use and modification of values in event

filters.
The TVR values that you can assign to network assets are Low,
Medium, High, Mission Critical, and No Value.
You can add an event action override to change the actions
associated with an event based on specific details about that event.
Event filtering enables you to reduce the number of false positives
and the number of security events reported.
The risk rating formula uses the ASR, TVR, SFR, ARR, PD, and
WLR values to calculate a risk rating value that is used by the event
action overrides.
You can configure settings for how long you want to deny attackers,
the maximum number of denied attackers, and how long you want
blocks to last.
Lesson 2
Monitoring and Managing

Alarms
Overview
This lesson introduces several additional software products to aid and enhance the monitoring
provided by the Cisco Intrusion Prevention System (IPS) sensor. It also covers some
complementary technologies that aid in this enhancement.
Objectives
Upon completing this lesson, you will be able to use additional monitoring tools to maximize
alarm management efficiency. This ability includes being able to meet these objectives:
Explain the Cisco IEV, its features, benefits, and specifications
Explain the installation procedure for Cisco IEV
Add devices to the Cisco IEV
Use Cisco IEV to view events
Explain the Cisco Security Management Suite, its features, benefits, and specifications
Explain the external product interface, its benefits, and specifications
Explain how a Cisco Security Agent installation can be integrated into a Cisco IPS sensor
installation using Cisco Security Monitor
Explain the Cisco ICS
Cisco IEV Overview
This topic describes the features, benefits, and specifications of the Cisco IPS Event Viewer
(IEV).
Cisco IEV
Cisco IEV Version 5.2 is a no-cost monitoring solution for

small scale IPS deployments that provides the following:
Support for up to five sensors
E-mail and pager alert notification
Support for Cisco IPS Sensor Software Version 5.x via SDEE
Customizable reporting
Compatible with Cisco IDSM-2, Cisco IPS 4200 Series Sensors,
Cisco Catalyst 6500 Series AIP-SSM, and Cisco IOS IPS-capable
Software on ISRs
Visibility into applied response actions and threat rating
Cisco IEV Version 5.2 offers a no-cost monitoring solution for small scale Cisco IPS
deployments, for example, up to five devices. Cisco IEV is easy to set up and use for
monitoring individual Cisco IPS devices, and provides the administrator with the following:
E-mail and pager alert notification (new in Version 5.2)
Support for Cisco IPS Sensor Software Version 5 through Security Device Event Exchange
(SDEE) compatibility
Customizable reporting
Visibility into applied response actions and threat rating
Compatibility with events generated from the Cisco Adaptive Security Appliance
Advanced Inspection and Prevention Security Services Module (ASA AIP-SSM), Cisco
IPS 4200 Series Sensors, Cisco Catalyst 6500 Series Intrusion Detection System Services
Module 2 (IDSM-2), and Cisco IOS IPS-capable Software on Cisco integrated services
routers (ISRs)
Installing Cisco IEV
This topic describes how to install Cisco IEV.
Installing Cisco IEV
To install Cisco IEV on a Microsoft Windows-based systems do the following:
Step 1 Download the Cisco IEV executable from Cisco.com.
Step 2 Double-click the IEV-min-5.2-1.exe file to start the installation process.
Step 3 Click Next at the Welcome screen.
Step 4 At the Select Destination Location window, click Browse to change the Destination
Folder. Once satisfied with the location, click Next.
Step 5 From the Select Program Manager Group screen, define the group that you wish for
this program to join and click Next.
Step 6 Click Next when the Start Installation screen appears.
Step 7 When the Installation Complete screen appears, click Finish.
Tip You can download the Cisco IEV executable file (IEV-min-5.2-1.exe) and associated readme
file (IEV-5.2-1.readme.txt) from http://www.cisco.com/cgi-bin/tablebuild.pl/ips-ev. This URL
requires a Cisco.com login.

Configuring Cisco IEV
This topic defines how to add devices to Cisco IEV.
Configuring Cisco IEV

1. Specify the sensors that you want Cisco IEV to monitor.
2. Configure filters and views to specify the alerts that you
want to view.
3. Configure refresh cycle settings and database archival
settings, and verify application settings.
4. Configure alert notification.
5. Maintain the database by importing, exporting, and
deleting event data.
Cisco IEV lets you view and manage alert feeds from up to five sensors. The following task
flow outlines the high-level tasks for configuring and working with Cisco IEV:
Task 1 Specify the sensors that you want Cisco IEV to monitor.
Task 2 Configure filters and views to specify the alerts that you want to view.
Task 3 Configure refresh cycle settings and database archival settings and verify
application settings.
Task 4 Configure alert notification.
Task 5 Maintain the database by importing, exporting, and deleting event data.
Specify the Sensors
File > New > Device
Sensor IP
Address
Sensor Name
Username
Password
Exclude alerts
of following
severity levels
Before Cisco IEV can receive events from a sensor, you must add the sensor to the list of
devices that Cisco IEV monitors.
Follow these steps to add a sensor to the Devices folder:

Step 1 Choose File > New > Device.
Step 2 In the Sensor IP Address field, enter the IP address of the sensor that you are adding.
Step 3 In the Sensor Name field, enter the hostname of the sensor that you are adding.
Step 4 In the User Name field, enter your username.
Step 5 In the Password field, enter your password.
Step 6 In the Web Server Port field, enter the web server port. The default is 443.
Step 7 To specify the communication protocol that Cisco IEV should use when connecting
to the sensor, click the Use Encrypted Connection (https) or Use Non-Encrypted
Connection (http) radio button.
Step 8 Follow these steps to specify what alerts to pull from the sensor:
To exclude alerts of a certain severity level, check one or more of the following
check boxes:
Informational
Low
Medium
High
Step 9 Click OK to apply your changes and close the Device Properties dialog box.

Note Cisco IEV sends a subscription request to the sensor. This request remains open until you
modify the device properties or delete the device. If you specified HTTPS as the
communication protocol, Cisco IEV retrieves the certificate information from the sensor and
the Certificate Information dialog box appears.
Step 10 Click Yes to accept the certificate and continue the HTTPS connection between
Cisco IEV and the sensor.
Tip The sensor has a red dot next to it signifying that it is connected.
Step 11 Repeat Step 1 through Step 10 for any additional sensors that you want to monitor,
up to five.
Tip If Cisco IEV cannot connect to the sensor, a red X appears next to the device name to
indicate that no connection is present. Cisco IEV continues trying to connect to the sensor
every 20 seconds until a connection is established or until you delete the device from Cisco
IEV.
Configure Filters
File > New >

Filter
By Severity
By Src Address
By Signature
By Sensor
Name
By Dst Address By UTC Time
By Status
You can create a filter to include or exclude alerts that match a specified trait, such as severity,
signature, or time. Follow these steps to create a filter:
Step 1 Choose File > New > Filter.
Step 2 To name the filter, enter an alphanumeric text string, up to 64 characters, in the
Filter Name field.
Step 3 To filter alerts by severity, check the By Severity check box in the Filter Functions
area and check one or more of the following severity level check boxes:
Informational, Low, Medium, or High.
Step 4 To filter alerts by source address or destination address, check the By Src Address
or By Dst Address check box, respectively, in the Filter Functions area.
To include an IP address or range, click the Included radio button. To exclude
an IP address or range, click the Excluded radio button.
To specify a single IP address, click the Unique radio button, enter a valid IP
address in the IP Address field, and then click Add.
The IP address is added to the group of addresses excluded or included
(depending on what you selected) by this filter.
To specify a range of IP addresses, click the Range radio button, enter a valid
starting IP address in the Start Address field and a valid ending IP address in the
End Address field, and then click Add.
The IP address range is added to the group of addresses excluded or included
(depending on what you selected) by this filter.
Step 5 Repeat Step 4 to continue adding IP addresses or ranges of IP addresses.
Step 6 To filter alerts by signature, check the By Signature check box in Filter Functions
area and check the following options, as desired:

Releases: This option identifies the signature release categories. You can
expand each signature release to view the signatures that were added to that
release. You can choose an entire signature release, such as S206, to exclude all
signatures contained in that category. You can choose individual signatures from
a release to be excluded. You can choose as many signature releases as you
want.
L2/L3/L4 Protocol: This option identifies the Layer 2, Layer 3, and Layer 4
protocol categories. You can expand each protocol category to view the
individual signatures contained in that category. You can choose an entire
protocol category, such as User Datagram Protocol (UDP) signatures, to exclude
all signatures contained in that category.
Attack: This option identifies the attack classification categories. You can
choose an attack category, such as denial of service (DoS), to exclude all
signatures contained in that category.
OS: This option identifies the operating system categories. You can expand each
operating system category to view the individual signatures contained in that
category. You can choose an entire operating system category, such as Windows
NT, to exclude all signatures contained in that category.
Service: This option identifies the service categories. You can expand each
service category to view the individual signatures contained in that category.
You can choose an entire service category, such as Domain Name System
(DNS), to exclude all signatures contained in that category.
Step 7 To exclude alerts by sensor, check the By Sensor Name check box in the Filter
Functions area and choose a sensor from the Devices folder.
Step 8 To exclude alerts by time and date, check the By UTC Time check box in the Filter
Functions area.
Enter a valid numerical start date, beginning with the four-digit year, and then
the two-digit month and day in the Start Date field.
Enter a valid start time, beginning with the two-digit hour, and then minute and
seconds in the Start Time field.
Tip 16:00:00 is the same as 4:00 p.m.
Enter a valid numerical end date, beginning with the four-digit year, and then
the two-digit month and day in the End Date field.
Enter a valid end time, beginning with the two-digit hour, and then minute and
seconds in the End Time field.
Tip 22:30:00 is the same as 10:30 p.m.
Step 9 Repeat Step 8 to add additional time periods.
Step 10 To exclude alerts by status, check the By Status check box in the Filter Functions
area and check one or more of the following status level check boxes:
New
Acknowledged
Assigned
Closed
Deleted
Step 11 To save the filter, click OK.
The filter is added to the Filters folder and you can now use it in a view.

Configure Views
View Name
File > New >
View Filter
Group By
Secondary
Sort Columns
Follow these steps to create a view:
Step 1 Choose File > New > View.
Step 2 To name the view, enter an alpha or numeric text string, up to 64 characters, in the
View Name field.
Step 3 To specify a filter, check the Use Filter check box and choose a filter from the drop-
down list.
Step 4 To specify how alerts are grouped in the table, check a grouping style check box in
the Select the Grouping Style on Alert Aggregation Table area.
Step 5 To specify the columns that should appear in the table, check one or more check
boxes in the Select the Columns Initially Shown on Alert Aggregation Table area.
Step 6 To specify sort order for the columns, choose an option from the Column Secondary
Sort Order (Initially) drop-down list.
Step 7 Click Next.
Step 8 To specify the alerts that should populate this view, choose a source from the
Choose a Data Source drop-down list.
Note To view alerts in real time, choose event_realtime_table.
Step 9 To specify the columns that should appear in the alert detail, choose one or more
columns in the Select the Columns Initially Shown on Alert Detail Table area. To
rearrange the order of these columns, click Up or Down.
Step 10 To save your changes and create the view, click Finished.
Configure Database and Application
Settings
Edit > Preferences > Refresh
Cycle
Edit >
Application
Settings
Edit > Preferences > Data

Archival Setup
Follow these steps to configure the Refresh Cycle settings:
Step 1 Choose Edit > Preferences.
Step 2 Click the Refresh Cycle tab.
Step 3 To set the automatic refresh cycle, do one of the following:

To set the automatic refresh to occur every 1 to 59 minutes, click the Every
radio button, choose a time interval from the Minute(s) drop-down list, and then
click OK.
To set the automatic refresh to occur every 1 to 23 hours, click the Every radio
button, choose a time interval from the Hour(s) drop-down list, and then click
OK.
To set the automatic refresh to occur once a day, click the Every Day at Time
radio button, choose a specific time from the drop-down list, and then click OK.
To stop the automatic refresh, click the Stop Auto Refresh radio button, and
then click OK.
Cisco IEV includes a database archival feature that lets you archive real-time events and ensure
available disk space for incoming events. Two thresholds control the archival process. The first
is a time interval and the second is a maximum number of records. Crossing either threshold
triggers the archival process.
If the time interval threshold is crossed, all records with a status matching the archival settings
are moved from the event_realtime_table to archive_table.timestamp. Any alerts with a status
set to Deleted are deleted.
If the maximum records threshold is crossed, any alerts with a status set to Deleted are deleted
from the event_realtime_table. Then, all records with a status matching the archival settings are
moved from event_realtime_table to archive_table.timestamp. If, after the initial archival

process, the event_realtime_table still contains more than half of the maximum number of
records allowed, the archival process continues to archive and remove records, except those
with a status set to New. If the number of records remaining exceeds the maximum number of
records allowed, all remaining records are archived, including those with a status of New.
Follow these steps to configure data archival settings:

Step 2 Click the Data Archival Setup tab.
Step 3 To specify the alerts that you want to archive, check one or more of the following
alert status check boxes:
New
Acknowledged
Assigned
Closed
Step 4 To enable a time interval threshold, check the Enable Time Schedule for
Archiving Events check box and do one of the following:
To set the archival to occur every 1 to 59 minutes, click the Every radio button
and choose a time from the Minute(s) drop-down list.
To set the archival to occur every 1 to 23 hours, click the Every radio button
and choose a time interval from the Hour(s) drop-down list.
To set the archival to occur once a day, click the Every Day at Time radio
button and choose a specific time from the drop-down list.
Step 5 To specify the maximum number of real-time events to allow in the

event_realtime_table, enter a numerical value from 1000 to 1,000,000 in the
Maximum Number of Events in the event_realtime_table field.
When this threshold is met, Cisco IEV begins to archive events to make room for
new events in the event_realtime_table.
Step 6 To specify the maximum number of archived files, enter a numerical value, from 10
to 400, in the Maximum Number of Archived Files field.
When this threshold is met, Cisco IEV begins to compress half of the oldest archived
files and moves them to the compressed directory.
Step 7 To specify the maximum number of compressed archived files, enter a numerical
value, from 10 to 400, in the Maximum Number of Compressed Archived Files
field.
When this threshold is met, Cisco IEV begins to purge half of the oldest compressed
archived files.
Note To maintain available disk space for a full event_realtime_table, Cisco IEV purges
compressed and archived files on a first-in, first-out basis until the available disk space is
greater than three times the space needed.
Step 8 Click OK to apply your changes and save the revised configuration.
Cisco IEV relies on supporting applications to carry out database retrieval and communication
functions. From the Edit menu, you can specify the location of these supporting applications.
Note If Ethereal is installed on your computer when you install Cisco IEV, Cisco IEV detects the
location. You must specify only the location of Ethereal if you later move the Ethereal
executable file to a different directory or if you decide to install Ethereal after installing Cisco
IEV.
Follow these steps to specify the location of Ethereal:
Step 1 Choose Edit > Applications Settings.
Step 2 Enter the path, beginning with the drive letter, to the Ethereal executable file in the
Ethereal Executable File Location field, or click Browse to locate the file.
Step 3 Click OK to accept your changes and close the Application Settings dialog box.

Configure Alert Notification
Edit > Preferences>
Alert Notification
Mail Server
From Address
Recipient Address(es)
Send Notifications for

Alerts
Follow these steps to set up alert notification:
Step 2 Click the Alert Notification tab.
Step 3 Check the Enable Email/Epage Notifications check box.
Step 4 In the Mail Server (SMTP Host) field, enter the mail server IP address.
Step 5 In the Recipient Address(es) field, enter the e-mail address that should receive the
notifications. You can enter multiple e-mail addresses separated by a semi-colon (;).
Step 6 Click Send a Test Mail to test the recipient e-mail address.
The test e-mail has Alert Test Mail as the subject and contains something similar to
the following:
Will send out notifications for high level alerts whose risk
rating value is 0-100.
Step 7 Check the check boxes for the severity levels of alerts for which you want to receive
notifications.
Note By default, Cisco IEV counts and sends out notifications only for high-level alerts. Cisco IEV
does not summarize or send detailed notifications for alerts that do not fall into the selected
categories.
Step 8 In the Risk Rating Range field, you can change the default risk rating range (0–100).
Step 9 In the Notification Interval field, you can change the default interval of 10 minutes.
The valid range is 1 to 1440 minutes.
Step 10 Under Notification Type, check the check box of the type of notifications that you
want to receive. Both the Send Summarized Notifications and Send Detailed
Notifications check boxes are checked by default.
Step 11 In the Maximum Number of Detailed Notifications per Interval field, you can
change the default of 10. The valid range is 1 to 100.
Step 12 In the Content Contains field, check the check boxes of the fields that you want the
detailed notifications to contain.
Step 13 Click OK to apply your changes and save the revised configuration.
Note If you want Cisco IEV to send out notifications for certain severity level alerts, ensure that
they are not marked as excluded in the Device Properties dialog box. Cisco IEV must
receive those alerts before it can send out notifications for them.

Maintain the Database
File > Database
Administration > Export
Database Tables
File > Database

Administration > Data Source
Information
You can export data from the Cisco IEV tables to an ASCII file. Follow these steps to export a
table:
Step 1 Choose File > Database Administration > Export Database Tables.
The Export Database Tables dialog box appears.
Step 2 To specify where to store the exported table, click Browse and choose a directory
for the file.
Step 3 To name the exported file, enter a name in the ASCII File Name field.
Step 4 Choose the tables to export to the ASCII file. To choose multiple tables, hold down
the Ctrl key and click the names of the tables that you want to include.
Note By default, tables are exported in the Cisco IEV Version 5.2 format. This option appears
dimmed.
Step 5 To specify how the table fields are separated in ASCII format, choose the Separate
by Comma or Separate by TAB radio button in the How to Separate Fields in
ASCII File area.
Step 6 To export the tables, click OK.
You can delete an existing table from the list of available data sources for a view. Follow these
steps to delete a table from the data source repository:
Step 1 Choose File > Database Administration > Data Source Information.
Step 2 Choose the row corresponding to the table that you want to delete, and then click
Delete.
Step 3 Click Yes to remove the table from the data source repository.
Follow these steps to delete alerts from a data source:

Step 1 Follow these steps to delete alerts with a status set to Deleted:
Verify that you have set the status of all the alerts that you want to delete to
Deleted.
Choose File > Database Administration > Data Source Information.
Choose the row corresponding to the table containing the alerts that you want to
delete, and then click Purge.
Click Yes to purge the alerts that have a status of Deleted.
Alerts with a status set to Deleted are removed from the table.
Tip To delete rows from a table associated with an open view, choose the rows that you want to
delete and then right-click the first column of the table and choose Delete Row(s) from
Database.
Step 2 To clear all alerts from tables:

Choose File > Database Administration > Data Source Information.
Choose the row corresponding to the table, and then click Clear.
Click Yes to clear all alerts from the selected tables.
Step 3 To delete all alerts from a table associated with an open view, right-click the tab for
the view, and choose Delete All Rows from Database.
All of the rows are deleted from the table.
Note You can delete a single row from an Alarm Aggregation table, the Expanded Details Dialog
table, or the Drill-Down Dialog table.

Viewing Events
This topic describes how to use Cisco IEV to view events.
Viewing Events
The Realtime Dashboard and Realtime Graph organize

events from a continuously running thread in Cisco IEV.
This thread continuously monitors and aggregates the
total number of alerts Cisco IEV receives.
Realtime Dashboard: This displays the events, in real time, as
Cisco IEV receives these events from the sensors. The most
recent events appear at the top of the table.
Realtime Graph: This displays the average number of alerts
received by Cisco IEV.
You can use the Realtime Dashboard to view a continuous stream of real-time events from the
sensor.
Follow these steps to view events in the Realtime Dashboard:
Step 1 Choose Tools > Realtime Dashboard > Launch Dashboard.
Cisco IEV opens a subscription request with the sensor. If the connection is
successful, the Realtime Dashboard appears and displays the most recent events
received by the sensor since the request was opened.
You can view events in the Realtime Graph or the Statistical Graph. Each graph
provides a view of the average number of alerts per minute, based on severity level.
However, each graph represents a different data source and therefore a different view
into the events.
Follow these steps to view a graph:
Step 1 Choose Tools > Realtime Graph.
Step 2 To view the Statistical Graph, follow these steps:

Click the Views tab.
Double-click the Views folder and locate the view that contains the alert data
that you want to display in a graph.
Right-click the view and choose Statistical Graph.
Cisco IEV queries the data source for the chosen view and calculates the
average alerts per minute. The Statistical Graph appears and displays the result.
Step 3 To change the range of events displayed in the graph, follow these steps:
Specify the time span by which you want to advance the view.
To adjust the start time by the interval selected in the Switched Port Analyzer
(SPAN), use the forward and backward arrows.
Step 4 To change the presentation to a bar or area graph, click Bar or Area.

Realtime Dashboard
Signature Severity Local Destination

Name Level Time Address
Signature Source
ID Address
You can use the Realtime Dashboard to view a continuous stream of real-time events from the
sensor.
Follow these steps to view events in the Realtime Dashboard:

Step 1 Choose Tools > Realtime Dashboard > Launch Dashboard.
The Cisco IEV opens a subscription request with the sensor. If the connection is
successful, the Realtime Dashboard appears and displays the most recent events
received by the sensor since the request was opened.
Step 2 To pause the stream of real-time events, click Pause.
The Cisco IEV stops populating the Realtime Dashboard with events.
Step 3 To resume the stream of real-time events, click Resume.
The Cisco IEV populates the Realtime Dashboard with events, beginning with the
first event that was received after the stream was paused.
Step 4 To clear all existing events from the Realtime Dashboard, click Reconnect.
All existing events are removed from the Realtime Dashboard and Cisco IEV opens
a new subscription with the sensor.
Realtime Graph
Bar Graph
Area
Graph
You can view events in a real-time graph or statistical graph. Each graph provides a view of the
average number of alerts per minute, based on the severity level. However, each graph
represents a different data source and therefore a different view into the events.
A continuously running thread in Cisco IEV populates the Realtime Graph. This thread
continuously monitors and aggregates the total number of alerts that Cisco IEV receives. The
events that the Realtime Graph displays reflect the average number of alerts received by Cisco
IEV. The time stamp for these events reflects the time that Cisco IEV received the alert, not
necessarily the time that the sensor generated the alert.
The Statistical Graph is populated with events from the data source that you choose. Valid data
sources include the event_realtime_table, any archived table, or any imported table. The events
displayed in the Statistical Graph reflect the average number of alerts received by Cisco IEV,
based on the filter that is applied to the data source. Therefore, depending on the filter, the
Statistical Graph may not reflect the true average number of alerts. The time stamp for these
events reflects the time the sensor generated the alert.
Follow these steps to view a graph:

Step 1 Choose Tools > Realtime Graph.
The Realtime Graph appears.
Step 2 Follow these steps to view the Statistical Graph:

1. Click the Views tab.
2. Double-click the Views folder and locate the view that contains the alert data
you want to display in a graph.
3. Right-click the view and choose Statistical Graph.

Cisco IEV queries the data source for the chosen view and calculates the
average alerts per minute. The Statistical Graph appears and displays the result.
Step 3 Follow these steps to change the range of events displayed in the graph:
1. Specify the time span by which you want to advance the view.
2. To adjust the start time by the interval selected in SPAN, use the forward and
backward arrows.
Step 4 To change the presentation to a bar or area graph, click Bar or Area.
Generate Reports
Cisco IEV generates three types of reports:

Top Alerts
Top Attackers
Top Victims
Follow these steps to generate a report with the top 10 most common alerts:
Step 1 Click the Reports tab.
Step 2 Double-click the Reports folder to display the reports.
Step 3 Double-click Top Alerts in the Reports folder.
Step 4 In the drop-down list, specify how far back in time you want to gather the most
common alerts.
Step 5 Click Generate Report.
The Reporting Devices folder displays the sensors that have the 10 most common alerts. ALL
displays the 10 most common alerts for all the sensors.
Step 1 Double-click an individual sensor or ALL under the Reporting Devices folder to
display the 10 most common alerts.
Step 2 To save the report in a text file, click Save.
Step 3 To obtain details about a common alert, right-click the alert in the list, and choose
Show Details. You can also double-click the row in the list to show the details.
Step 4 The Alarm Information Dialog appears with the list of all occurrences of that alert.
Note Up to 30,000 alerts are displayed. If the count value of the selected row is more than the
30,000 limit, you receive a warning message and then the most recent 30,000 entries are
displayed.

Cisco IEV Reports
Top Alerts
Top
Attackers
Top
Victims
Follow these steps to generate a report:
Step 1 Click the Reports tab.
Step 2 Double-click the Reports folder to display the reports.
Step 3 Double-click the report that you wish to see.
Step 4 In the drop-down list, specify how far back in time you want to gather the top most
common attacker IP addresses.
Step 5 Click Generate Report.
Step 6 Double-click the individual sensor or ALL under the Reporting Devices folder to
display the 10 most common attackers.
Step 7 To save the report in a text file, click Save.
Step 8 To obtain details about an attacker, right-click the attacker IP address in the list, and
choose Show Details.
You can also double-click the row in the list to show the details.
The Alarm Information Dialog appears with the list of all occurrences of that source
IP address.
Cisco Security Management Suite Overview
This topic explains the Cisco Security Management Suite, its features, benefits, and
specifications.
Cisco Security Management Suite
The Cisco Security Management Suite is a framework of

products and technologies designed for scalable policy
administration and enforcement for the Cisco Self-
Defending Network.
Cisco Security Manager is a powerful but easy-to-use solution for
configuring firewall, VPN, and IPS policies on Cisco security
appliances, firewalls, routers, and switch modules.
Cisco Security MARS is an appliance-based, all-inclusive solution
that allows network and security administrators to monitor,
identify, isolate, and counter security threats.
The Cisco Security Management Suite is a framework of products and technologies designed
for scalable policy administration and enforcement for the Cisco Self-Defending Network. This
integrated solution can simplify and automate the tasks associated with security management
operations, including configuration, monitoring, analysis, and response. There are two main
components of the Cisco Security Management Suite:
Cisco Security Manager: A powerful but easy-to-use solution for configuring firewall,
virtual private network (VPN), and IPS policies on Cisco security appliances, firewalls,
routers, and switch modules
Cisco Security Monitoring, Analysis, and Response System (MARS): An appliance-
based, all-inclusive solution that allows network and security administrators to monitor,
identify, isolate, and counter security threats

Cisco Security Manager Overview
Cisco Security Manager is a

powerful but easy-to-use
solution to centrally
provision all aspects of
device configurations and
security policies.
Support for for Cisco firewalls,
VPNs, and IPSs
Scales to efficiently manage
large-scale networks
composed of thousands of
devices
Scalability is achieved through
intelligent policy-based
management techniques that
can simplify administration
Cisco Security Manager is a powerful but very easy-to-use solution to centrally provision all
aspects of device configurations and security policies for the Cisco family of security products.
The solution is effective for managing even small networks consisting of fewer than 10 devices,
but also scales to efficiently manage large-scale networks composed of thousands of devices.
Scalability is achieved through intelligent policy-based management techniques that can
simplify administration. Some of the features of Cisco Security Manager include the following:
Supports provisioning for Cisco router platforms running a Cisco IOS Software image,
Cisco ASA 5500 Series Adaptive Security Appliances, Cisco PIX 500 Series Security
Appliances, Cisco IPS 4200 Series Sensors, and Cisco Catalyst 6500 Series IDSM-2
Responds faster to threats; defines and assigns new security policies to thousands of
devices in a few simple steps
Rich graphical user interface provides superior ease-of-use
Multiple views provide flexible methods to manage devices and policies, including the
ability to manage the security network visually on a topology map
Extensive animated help for the new user, which reduces the learning time
Allows you to centrally specify which policies are shared and automatically inherited by
new devices to ensure corporate policies are implemented consistently, while providing
optional flexibility
Integrates with Cisco Secure Access Control Server (ACS) for granular roll-based access
control (RBAC) to devices and management functions
Integrates with Cisco Security MARS to correlate events with the associated firewall rules
to help with quicker decision making and increased network uptime
Has ability to assign specific tasks to each administrator during the deployment of a policy,
with formal change control and tracking; allows the security and network operations staff
to work together as a single team with effective coordination
Tip For additional training on Cisco Security Manager go to
http://www.cisco.com/web/learning/le31/le29/learning_training_from_cisco_learning_partners.
html.

Cisco Security MARS
Cisco Security MARS provides security monitoring for network

security devices and host applications made by Cisco and
other companies.
Greatly reduces false positives by providing an end-to-end view of the
network
Defines the most effective mitigation responses by understanding the
configuration and topology of your environment
Promotes awareness of environmental anomalies with network behavior
analysis using NetFlow
Provides quick and easy access to audit compliance reports with more
than 150 ready-to-use customizable reports
Makes precise recommendations for threat removal, including the ability
to visualize the attack path and identify the source of the threat with
detailed topological graphs that simplify security response at Layer 2 and
above
Cisco Security MARS provides security monitoring for network security devices and host
applications made by Cisco and other providers. Cisco Security MARS offers these benefits:
Greatly reduces false positives by providing an end-to-end view of the network
Defines the most effective mitigation responses by understanding the configuration and
topology of your environment
Promotes awareness of environmental anomalies with network behavior analysis using
NetFlow
Provides quick and easy access to audit compliance reports with more than 150 ready-to-
use customizable reports
Makes precise recommendations for threat removal, including the ability to visualize the
attack path and identify the source of the threat with detailed topological graphs that
simplify security response at Layer 2 and above
Tip For training on Cisco Secure MARS go to

http://www.cisco.com/web/learning/le31/le29/learning_training_from_cisco_learning_partner
s.html.
Note Each signature now contains a new parameter, MARS Category, which contains the list of
the Cisco Security MARS attack categories associated with the signature. This category is
included in the signature alerts. You can modify the MARS Category for custom signatures
but not for built-in signatures.
External Product Interface
This topic explains the external product interface, its benefits, and specifications.
External Product Interface
The external product interface is a new feature in Cisco IPS

Sensor Software Version 6.0.
The external product interface allows sensors to subscribe for
events from other devices. The events are used to help the
sensor provide a better response when signatures are triggered.
Sensors are already event servers. The external product interface
allows them to be event clients as well. The sensor can establish
a subscription for events from compatible event servers.
Although the external product interface is designed to be a
generic component, at this time it can only process events from
CiscoWorks Management Center for Cisco Security Agent
applications.
The external product interface is designed to receive and process information from external
security and management products. These external security and management products collect
information that can be used to automatically enhance the sensor configuration information. For
example, the types of information that can be received from external products include host
profiles, including the operating system configuration of the host, application configuration,
and security posture, and IP addresses that have been identified as causing malicious network
activity.
Note In Cisco IPS Sensor Software Version 6.0, you can add only interfaces to the CiscoWorks
Management Center for Cisco Security Agent.

External Product Interface (Cont.)
Configuration
External
Product
Interface
Add
Follow these steps to add an external product interface:
Step 1 Log into Cisco IPS Device Manager (IDM) using an account with administrator
privileges.
Step 2 Click Configuration and choose External Product Interfaces.
Step 3 From the Management Center for Cisco Security Agents panel, click Add to add an
external product interface.
Add External Product Interface
Step 4 In the External Product IP Address field, enter the IP address of the external product.
Step 5 Check the Enable Receipt of Information check box to allow information to be
passed from the external product to the sensor.
Step 6 In the Port field, change the default port 443 if you need to.
Note Under Communication Settings, you can change only the Port value.
Step 7 Configure the login settings:

In the Username field, enter the username of the user who can log into the
external product.
In the Password field, enter the password that the user will use.
In the Confirm Password field, enter the password again.
Step 8 Configure the watch list settings:

Check the Enable Receipt of Watch List check box to allow the watch list
information to be passed from the external product to the sensor.
Note If you do not check the Enable Receipt of Watch List check box, the watch list information
received from a CiscoWorks Management Center for Cisco Security Agent is deleted.
In the Manual Watch List RR Increase field, you can change the percentage
from the default of 25. The valid range is 0 to 35.
In the Session-Based Watch List RR Increase field, you can change the
percentage from the default of 25. The valid range is 0 to 35.

In the Packet-Based Watch List RR Increase field, you can change the
percentage from the default of 10. The valid range is 0 to 35.
Step 9 Check the Enable Receipt of Host Postures check box to allow the host posture
information to be passed from the external product to the sensor.
Note If you do not check the Enable Receipt of Host Postures check box, the host posture
information received from a CiscoWorks Management Center for Cisco Security Agent is
deleted.
Step 10 Check the Allow Unreachable Hosts’ Postures check box to allow the host posture
information from unreachable hosts to be passed from the external product to the
sensor.
Note A host is not reachable if the CiscoWorks Management Center for Cisco Security Agent is
unable to establish a connection with the host on any of the IP addresses in the host
posture. This option is useful in filtering the postures whose IP addresses may not be visible
to the sensor or may be duplicated across the network. This filter is most applicable in
network topologies where hosts that are not reachable by the CiscoWorks Management
Center for Cisco Security Agent are also not reachable by the sensor; for example if the
sensor and CiscoWorks Management Center for Cisco Security Agent are not on the same
network segment.
Step 11 Click Add to add a posture access control list (ACL).
Note Posture ACLs are network address ranges for which host postures are allowed or denied.
Use posture ACLs to filter postures that have IP addresses that may not be visible to the
sensor or may be duplicated across the network.
Add Host Posture ACL
Step 12 In the Name field, enter a name for the posture ACL.
Step 13 In the Active field, click the Yes radio button to make the posture ACL active.
Step 14 In the Network Address field, enter the network address that the posture ACL will
use.
Step 15 In the Action drop-down list, choose the action (Deny or Permit) that the posture
ACL will take.
Step 16 Click OK.

Integrating Cisco Security Agent into an IPS
Installation
This topic describes how a Cisco Security Agent installation can be integrated into an IPS
installation using Cisco Security Monitor.
Integrating Cisco Security Agent
The Cisco Security Agent is an architecture that enforces a

security policy on network hosts. It has two components:
– Agents that reside on and protect network hosts
– The CiscoWorks Management Center for Cisco Security Agent
The CiscoWorks Management Center for Cisco Security Agent is
an application that manages Cisco Security Agent devices. It
downloads security policy updates to Cisco Security Agent
devices and uploads operational information from Cisco Security
Agent devices.
The CiscoWorks Management Center for Cisco Security Agent
includes an SDEE event server that generates events as
specified in CSAEE, an extension to SDEE. The external product
interface component processes CSAEE events (they are the only
event types that the external product interface can handle at this
time).
CiscoWorks Management Center for Cisco Security Agent receives host posture information
from the Cisco Security Agent software that it manages. It also maintains a watch list of IP
addresses that it has determined should be quarantined from the network.
CiscoWorks Management Center for Cisco Security Agent sends two types of events to the
sensor—host posture events and quarantined IP address events. Host posture events contain the
Unique host ID assigned by CiscoWorks Management Center for Cisco Security Agent
Network Admission Control (NAC) posture
Protocol associated with a rule violation (TCP, UDP, or Internet Control Message Protocol
[ICMP])
Indicator of whether a rule-based violation was associated with an established session or a
UDP packet.

External Product Interface Collaboration
with Cisco Security Agent
Server Protected by
Cisco Security Agent
Host
External Postures Security
Product as Policy
Interface CSAEE
Events
Events
Quarantined
IP Addresses
as CSAEE
Events
Management Center for Cisco
Security Agent
with Internal or External
Database
Cisco Security Agent software installed on hosts report attack information to the CiscoWorks
Management Center for Cisco Security Agent. Once integrated into the IPS installation, the
CiscoWorks Management Center for Cisco Security Agent sends host postures and quarantined
IP addresses to the external product interface component of the sensor. That component
converts the host postures to operating system identifications. It also calculates the risk rating
delta for quarantined IP addresses. These are then forwarded to the SensorApp for processing
as a signature alert.
External Product Interface Collaboration
Naming Conventions
CiscoWorks Management Cisco IPS Name

Center for Cisco Security Agent
Name
Host posture Imported operating system
identification
Quarantined IP addresses Watch list
CiscoWorks Management Center for Cisco Security Agent and

Cisco IPS use different names for the same events.
The vocabulary of the two technologies, CiscoWorks Management Center for Cisco Security
Agent and the Cisco IPS Sensor, differs on key points. What the Cisco IPS sensor processes as
the operating system identification, the CiscoWorks Management Center for Cisco Security
Agent calls a host posture. The Cisco IPS sensor watch list is referred to as quarantined IP
addresses by CiscoWorks Management Center for Cisco Security Agent.
Tip For additional training on Cisco Security Agent go to

http://www.cisco.com/web/learning/le31/le29/learning_training_from_cisco_learning_partners.
html.

Cisco ICS
This topic explains the Cisco Incident Control System (ICS).
Cisco Incident Control System
Cisco ICS is a server-based software application that

helps you manage your incident control initiatives.
Helps protect your network by combining Cisco networking and
security expertise with TrendMicro antivirus and incident-control
technologies
Protects your organization from newly discovered network-based
threats
Deploys policies to Cisco network devices to block the traffic and
ports that network-based threats use to propagate
Configures notifications to alert you about threat-related events
Cleans up infected hosts to remove viruses and other threats
Cisco ICS is a server-based software application that helps you manage your incident control
initiatives. Built on incident-control technology from Trend Micro, Cisco ICS gives you the
means to protect your organization from newly discovered network-based threats.
Use the Cisco ICS web console to manage the Cisco ICS server and perform the following
tasks:
Deploy policies to Cisco network devices to block the traffic and ports that network-based
threats use to propagate
Create reports about the tasks that you create to address threats on your network
Use logs to analyze your protection
Configure notifications to alert you about threat-related events and Cisco ICS threat-
protection updates
Clean up infected hosts to remove viruses and other threats
Cisco ICS Technology
The following elements comprise the Cisco

implementation of the incident control system:
TrendLabs: The TrendMicro worldwide, real-time monitoring, and
signature-development infrastructure
Cisco ICS: A product that delivers protection from viruses, worms,
spyware, and other potential threats
Mitigation devices: Switches, routers, Cisco IPS sensors, and
Cisco IOS IPS devices
The Cisco ICS is a means to control the outbreak of network-based threats on your network.
The incident control system is managed by a central server, the Cisco ICS server, and uses
threat-specific ACLs and signature files to help identify network threats and mitigate the effects
of outbreaks. With these components, your Cisco network devices can become defense nodes
against new outbreaks.
You can deploy Outbreak Prevention ACLs (OPACLs) and Outbreak Prevention Signatures
(OPSigs) from the web console when you create items called outbreak management tasks or
when you enable Cisco ICS to automate the creation of tasks.

Cisco ICS in Action
Cisco ICS
Administrator
Modifications to OPACL
and Exception List
Log and
Watch List Switch IPS
Information
TrendLabs Cisco ICS
Outbreak OPACL
Management Task
OPSig OPSig
m up
d
an
om n
Outbreak
C le a
s
tu
C
ta
Router Cisco
tS
s
Ho IOS IPS
Infection Status
DCS Server
Damage Cleanup
Host Computers
Soon after Trend Micro TrendLabs discovers a new threat, the following sequence of events
takes place:
Step 1 TrendLabs releases an outbreak management task file that contains an OPACL to
address the new threat.
Step 2 As the Cisco ICS server polls the update source for new components, it discovers
that the new outbreak management task is available.
Step 3 Cisco ICS downloads the new outbreak management task file.
Step 4 If Cisco ICS is enabled to deploy outbreak management tasks automatically, it

activates a new task and deploys the OPACL to network devices.
Step 5 Your Cisco network devices block the ports and the types of traffic specified in the
OPACL until the OPACL expires.
Step 6 Approximately two hours after TrendLabs releases the OPACL, it releases an
OPSig, which enables IPS devices to detect the new threat and other threats that
TrendLabs discovered.
Step 7 Cisco ICS downloads and deploys the OPSig to Cisco IPS devices. The OPACL for
the threat expires on all devices when Cisco ICS deploys the OPSig.
Step 8 While they scan network traffic, Cisco IPS devices use the OPSig to identify any
threats that might attack the network.
Step 9 If a Cisco IPS device detects a threat in the network traffic from a certain host, Cisco
ICS considers the host to be potentially infected and puts it on a watch list. You can
view the watch list to see which hosts on your network need attention.
Step 10 If you installed Damage Cleanup Services (DCS), you can run a Damage Cleanup
scan on the potentially infected host to attempt to remove the threat.
Summary
Summary
Cisco IEV is a no-cost monitoring solution for up to five IPS

devices.
The IEV-min-5.2-1.exe file is used to start the installation for
Cisco IEV.
To configure and work with Cisco IEV, you must perform these
tasks: specify sensors for Cisco IEV to monitor, configure filters
and views, configure refresh cycle and database archival settings,
configure alert notification, and maintain the database.
Cisco IEV allows you to view events using Realtime Dashboard or
Realtime Graph.
The Cisco Security Management Suite is a framework of products
and technologies designed for scalable policy administration and
enforcement for the Cisco Self-Defending Network.
Summary
The external product interface allows sensors to subscribe for

events from other devices. The events are used to help the
sensor provide a better response when signatures are triggered.
Cisco Security Agent has two components: agents that reside on
and protect network hosts and the CiscoWorks Management
Center for Cisco Security Agent.
Cisco ICS helps protect your network by combining Cisco
networking and security expertise with Trend Micro antivirus and
incident-control technologies.

Lesson 3
Configuring a Virtual Sensor
Overview
This lesson focuses on configuring different instances of virtual sensors. It will include a
discussion of interfaces, signatures, event rules, and anomaly detection.
Objectives
Upon completing this lesson, you will be able to explain the virtual sensor, its settings, and
advantages. This ability includes being able to meet these objectives:
Explain the principles behind virtual sensors
Prepare for creating virtual sensors by creating inline pairs, signature polices, event action
rules, and anomaly detection policies
Create a virtual sensor by giving it a name and assigning interfaces
Virtual Sensor Overview
This topic describes the principles behind virtual sensors.
Virtual Sensor Overview
The packet processing policy is virtualized.

The sensor interfaces are not virtualized.
A virtual sensor is a collection of data that is kept independently.
A virtual sensor is defined by a set of configuration instances.
Virtual sensor policies are applied to sets of packets defined in
the interface component.
A virtual sensor is not a “virtual machine.”
The sensor can receive data inputs from one or many monitored data streams. These monitored
data streams can either be physical interface ports or virtual interface ports. For example, a
single sensor can monitor traffic from in front of the firewall, from behind the firewall, or from
in front of and behind the firewall concurrently. And a single sensor can monitor one or more
data streams. In this situation, a single sensor policy or configuration is applied to all monitored
data streams.
A virtual sensor can monitor multiple segments, and let you apply a different policy or
configuration for each virtual sensor within a single physical sensor. You can set up a different
policy per monitored segment under analysis. You can also apply the same policy instance, for
example, sig0, rules0, or ad0, to different virtual sensors.
You can assign interfaces, inline interface pairs, inline VLAN pairs, and VLAN groups to a
virtual sensor.
Note The default virtual sensor is “vs0.” You cannot delete the default virtual sensor.
Virtual Sensor Restrictions
The sensor must receive traffic that has 802.1Q headers.

Promiscuous mode is inconsistent with the need to do VLAN
tagging. Therefore, virtual sensors only work in inline mode.
The persistent store is limited.
The sensor must see both directions of traffic in the same VLAN
group.
The virtualization of sensors has the following restrictions:

You must assign both sides of asymmetric traffic to the same virtual sensor.
Using VLAN access control list (VACL) capture or Switched Port Analyzer (SPAN)
(promiscuous monitoring) is inconsistent with regard to VLAN tagging, which causes
problems with VLAN groups.
— When using Cisco IOS Software, a VACL capture port or a SPAN target does not
always receive tagged packets even if it is configured for trunking.
— When using the Cisco Multilayer Switch Feature Card (MSFC), fast path switching
of learned routes changes the behavior of VACL captures and SPAN.
The persistent store is limited.
The virtualization of sensors has the following traffic capture requirements:

The virtual sensor must receive traffic that has IEEE 802.1Q headers, other than traffic on
the native VLAN of the capture port.
The sensor must see both directions of traffic in the same VLAN group, in the same virtual
sensor for any given sensor.

Virtualization Platforms
Among older sensors, the Cisco IDS 4235 and Cisco IDS 4250
XL Sensors support multiple virtual sensors.
The Cisco IPS 4240, Cisco IPS 4255, and Cisco IPS 4260
Sensors fully support multiple virtual sensors.
The Cisco Catalyst 6500 Series IDSM-2 supports multiple virtual
sensors except for VLAN groups on inline interface pairs.
The Cisco ASA AIP-SSM does not support multiple virtual
sensors until Cisco ASA Software Version 8.0.
The Cisco IDS 4215 Sensor supports a single virtual sensor
because of limited memory.
There is a maximum of four virtual sensors on all platforms that
support multiple virtual sensors.
The following sensors support virtualization:

Cisco Intrusion Detection System (IDS) 4235 Sensor
Cisco IDS 4250 XL Sensor
Cisco Intrusion Prevention System (IPS) 4240 Sensor
Cisco IPS 4255 Sensor
Cisco Adaptive Security Appliance Advanced Inspection and Prevention Security Services
Module (ASA AIP-SSM)
The Cisco Catalyst 6500 Series Intrusion Detection System Services Module 2 (IDSM-2)
supports virtualization with the exception of VLAN groups on inline interface pairs. The Cisco
IDS 4215 Sensor supports only one virtual sensor.
Virtual Sensor Advantages
It is possible to apply different configurations to different sets of

traffic.
With virtualization, you can monitor two networks with one sensor.
With virtualization, it is possible to monitor both inside and outside
of a firewall or NAT device with one physical Cisco sensor device.
Virtual sensors have the following advantages:

You can apply different configurations to different sets of traffic.
You can monitor two networks with overlapping IP address spaces with one sensor.
You can monitor both inside and outside of a firewall or Network Address Translation
(NAT) device with one physical Cisco sensor device.

Preparing for Virtual Sensors
This topic describes how to prepare for creating virtual sensors by creating inline pairs,
signature polices, event action rules, and anomaly detection policies.
Interfaces
Interfaces supported by virtual sensors:

– Inline interface pairs
– Inline VLAN pairs
– VLAN groups
No overlapping definitions
The Analysis Engine performs packet analysis and alert detection. It monitors traffic that flows
through specified interfaces.
Virtualization requires that the sensor is running in inline mode. It also requires 802.1Q
tagging. Therefore, the only interface configurations that virtual sensors support are inline
interface pairs, inline VLAN pairs, and VLAN groups.
Packets from interfaces, inline interface pairs, inline VLAN pairs, and VLAN groups that are
not assigned to any virtual sensor are disposed of according to the inline bypass configuration.
Adding Inline VLAN Pairs
Physical Interface
Subinterface Number
VLAN A
VLAN B
Follow these steps to configure inline VLAN pairs:

Step 1 Log into the Cisco IPS Device Manager (IDM) using an account with administrator
privileges.
Step 2 Click Configuration and choose Interface Configuration > VLAN Pairs.
Step 3 Click Add to add inline VLAN pairs.
Step 4 Choose an interface from the Interface Name list.
Step 5 Enter a subinterface number (1 to 255) for the inline VLAN pair in the Subinterface
Number field.
Step 6 Specify the first VLAN (1 to 4095) for this inline VLAN pair in the VLAN A field.
Step 7 Specify the other VLAN (1 to 4095) for this inline VLAN pair in the VLAN B field.
Step 8 If you want, add a description of the inline VLAN pair in the Description field.
Step 9 Click OK.
Follow these steps to edit an inline VLAN pair:
Step 1 From the VLAN Pairs window, choose the VLAN pair that you wish to edit, and
click Edit.
Step 2 You can change the subinterface number, the VLAN numbers, or edit the
description.
Step 3 Click OK.
To delete a VLAN pair, choose the VLAN and follow these steps:
Step 1 Click Delete.

Adding VLAN Groups
Physical Interface
Subinterface Number
All VLANs
Specific VLANs
Because a VLAN group of an inline pair does not translate the VLAN ID (VID), an inline pair
interface must exist between two switches to use VLAN groups on a logical interface. For an
appliance, you can connect the two pairs to the same switch, make them access ports, and then
set the access VLANs for the two ports differently. In this configuration, the sensor connects
between two VLANs, because each of the two ports is in access mode and carries only one
VLAN. In this case, the two ports must be in different VLANs, and the sensor bridges the two
VLANs, monitoring any traffic that flows between the two VLANs. Cisco Catalyst 6500 Series
IDSM-2 also operates in this manner, because its two data ports are always connected to the
same switch.
You can also connect appliances between two switches. There are two variations to this. In the
first variation, the two ports are configured as access ports, so they carry a single VLAN. In this
way, the sensor bridges a single VLAN between the two switches.
In the second variation, the two ports are configured as trunk ports, so they can carry multiple
VLANs. In this configuration, the sensor bridges multiple VLANs between the two switches.
Because multiple VLANs are carried over the inline interface pair, the VLANs can be divided
into groups and each group can be assigned to a virtual sensor.
Follow these steps to configure VLAN groups:
Step 1 Log into the Cisco IDM using an account with administrator privileges.
Step 2 Choose Configuration > Interface Configuration > VLAN Groups.
Step 3 Click Add to add a VLAN group.
Step 4 From the Interface Name drop-down list, choose an interface.
Step 5 In the Subinterface Number field, enter a subinterface number (1 to 255) for the
VLAN group.
Step 6 Under the VLAN Group section, specify the VLAN group for this interface by
checking one of the following check boxes:
— Unassigned VLANs: This lets you assign all of the VLANs that are not already
specifically assigned to a subinterface.
— Specify VLAN Group: This lets you specify the VLANs that you want to assign to
this subinterface. You can assign more than one VLAN (1 to 4096) in this pattern: 1,
5-8, 10-15. This option lets you set up different policies based on the VID. For
example, you can make VLANs 1 to 10 go to one virtual sensor (VS0) and VLANs
20 to 30 go to another virtual sensor (VS1).
Note In the Specify VLAN Group field you must enter the VIDs as they appear on your switch.
Step 7 If you want to, you can add a description of the VLAN group in the Description
field.
Step 8 Click OK.
The new VLAN group appears in the list in the VLAN Groups pane. You must assign this
VLAN group to a virtual sensor.

Signature Definition
More than one instance of signature definitions is

now possible.
An instance may be applied to multiple virtual sensors.
Unused instances may be deleted.
The instance sig0 may not be deleted.
In the Signature Definitions pane, you can add, clone, or delete a signature definition policy.
The default signature definition policy is called sig0. When you add a policy, a control
transaction is sent to the sensor to create the new policy instance. If the response is successful,
the new policy instance is added under Signature Definitions. If the control transaction fails, for
example because of resource limitations, an error message appears.
If your platform does not support virtual policies, this means that you can have only one
instance for each component and you cannot create new ones or delete the existing one. In this
case, the Add, Clone, and Delete buttons are disabled.
Note You must be an administrator or operator to add, clone, or delete signature policies.
Adding Signature Policies
Signature Policy
Name
Follow these steps to add a signature policy:
Step 2 Click Configuration and choose Policies > Signature Definitions.
Step 3 To add a signature definition policy, click Add.
Step 4 In the Policy Name field, enter a name for the signature definition policy.
Step 5 Click OK.
Step 6 To clone an existing signature definition policy, choose it in the list, and then click
Clone.
Note The Clone Policy dialog box appears with “_copy” appended to the existing signature
definition policy name.
Step 7 In the Policy Name field, enter a unique name.
Step 8 Click OK.

Event Action Rules
More than one instance of event rules can now be defined.

An instance may be used by more than one virtual sensor.
Unused instances may be deleted.
The instance rules0 may not be deleted.
In the Event Action Rules pane, you can add, clone, or delete an event action rules policy. The
default event action rules policy is called rules0. When you add a policy, a control transaction
is sent to the sensor to create the new policy instance. If the response is successful, the new
policy instance is added under Event Action Rules. If the control transaction fails, for example
because of resource limitations, an error message appears.
Adding Event Rule Policies
Rule Policy Name
Follow these steps to add an event rule policy:
Step 2 Click Configuration and choose Policies > Event Action Rules.
Step 3 To add an event action rules policy, click Add.
Step 4 Enter a name for the event action rules policy in the Policy Name field.
Step 5 Click OK.
Step 6 To clone an existing event action rules policy, choose it in the list, and then click
Clone.
Note The Clone Policy dialog box appears with “_copy” appended to the existing event action
rules policy name.
Step 7 Enter a unique name in the Policy Name field.
Step 8 Click OK.

Anomaly Detection
It is now possible to configure more than one instance of anomaly

detection policies.
They may be used more than once.
An unused instance may be deleted.
The instance ad0 may not be deleted.
In the Anomaly Detections pane, you can add, clone, or delete an anomaly detection policy.
The default anomaly detection policy is called ad0. When you add a policy, a control
the new policy instance is added under Anomaly Detections. If the control transaction fails, for
Note Anomaly detection is covered in more depth in the “Configuring Advanced Features” lesson.
Adding Anomaly Detection Policies
Anomaly Detection
Policy Name
Follow these steps to add an anomaly detection:
Step 2 Click Configuration and choose Policies > Anomaly Detections.
Step 3 To add an anomaly detection policy, click Add.
Step 4 In the Policy Name field, enter a name for the anomaly detection policy.
Step 5 Click OK.
Step 6 To clone an existing anomaly detection policy, choose it in the list, and then click
Clone.
Note The Clone Policy dialog box appears with “_copy” appended to the existing anomaly
detection policy name.
Step 7 In the Policy Name field, enter a unique name.
Step 8 Click OK.

Creating Virtual Sensors
This topic describes how to create virtual sensors.
Virtual Sensor
Up to four virtual sensors may be defined.

The virtual sensor vs0 already exists and uses instances sig0,
rules0, and ad0.
Virtual sensor vs0 may not be deleted and may not have its
instance configurations changed.
You create virtual sensors in the Analysis Engine. Each virtual sensor has a unique name with a
list of interfaces, inline interface pairs, inline VLAN pairs, and VLAN groups associated with
it. To avoid definition ordering issues, no conflicts or overlaps are allowed in assignments—
you assign interfaces, inline interface pairs, inline VLAN pairs, and VLAN groups to a specific
virtual sensor so that no packet is processed by more than one virtual sensor. Each virtual
sensor is also associated with a specifically named signature definition, event action rules, and
anomaly detection configuration. Packets from interfaces, inline interface pairs, inline VLAN
pairs, and VLAN groups that are not assigned to any virtual sensor are disposed of according to
the inline bypass configuration.
Adding a Virtual Sensor
Virtual Sensor Name Signature Policy
Rule Policy
Anomaly
Detection
Policy
Interfaces
Follow these steps to create a virtual sensor:
Step 2 Click Configuration and choose Analysis Engine > Virtual Sensors.
Step 3 To add a virtual sensor, click Add.
Step 4 Enter a name for the virtual sensor in the Virtual Sensor Name field.
Step 5 Choose a signature definition policy from the Signature Definition Policy drop-
down list.
Tip Unless you want to use the default sig0, you must have already added a signature definition
policy by choosing Configuration > Policies > Signature Definitions > Add.
Step 6 Choose an event action rules policy from the Event Action Rules Policy drop-down
list.
Tip Unless you want to use the default rules0, you must have already added an event action
rule by choosing Configuration > Policies > Event Action Rules > Add.
Step 7 Chose an anomaly detection policy from the Anomaly Detection Policy drop-down
list.
Tip Unless you want to use the default ad0, you must have already added an anomaly detection
policy by choosing Configuration > Policies > Anomaly Detections > Add.

Step 8 Choose the anomaly detection mode (Detect, Inactive, Learn) from the AD
Operational Mode drop-down list.
Step 9 If you want, add a description of this virtual sensor in the Description field.
Step 10 To assign the interface to the virtual sensor, choose it and click Assign.
Note Only the available interfaces are listed in the Available Interfaces list. If other interfaces exist
but have already been assigned to a virtual sensor, they do not appear in this list.
Step 11 Click OK.
Summary
Summary
A virtual sensor is not a virtual machine. It is the packet

processing policy that is virtualized.
Inline interface pairs, inline VLAN groups, and VLAN groups are
the interfaces that support virtual sensors.
The Cisco IPS 4240 DC, IPS 4255, and IPS 4260 Sensors fully
support virtualization and can have a maximum of four virtual
sensors.

Lesson 4
Configuring Advanced
Features
Overview
This lesson presents two new advanced features to the Cisco Intrusion Prevention System (IPS)
product line: anomaly detection and passive operating system fingerprinting (POSFP). These
features provide significant worm protection and alarm relevance in addition to IPS.
Objectives
Upon completing this lesson, you will be able to explain, configure, and monitor anomaly
detection and POSFP. This ability includes being able to meet these objectives:
Explain the principles behind anomaly detection
Explain the components used by anomaly detection
Configure anomaly detection
Monitor and troubleshoot problems with anomaly detection
Explain the principles behind POSFP
Explain the different methods available to identify operating systems
Explain the available configuration options for POSFP
Examine the results of POSFP
Anomaly Detection Overview
This topic describes the principles behind anomaly detection.
Anomaly Detection Overview
Not based on predefined signatures

Identifies worms as they attempt to spread (zero-day detection)
Identifies worm-infected hosts
Identifies fast spreading worms like Code Red and SQL Slammer
Does not detect e-mail, instant messenging, or file share-based
worms
Must see both directions of traffic
The anomaly detection component of the sensor detects worm-infected hosts. Anomaly
detection enables the sensor to be less dependant on signature updates for protection against
worm viruses, such as Code Red, SQL Slammer, and so on. The anomaly detection component
lets the sensor learn normal activity, send alerts, and take dynamic response actions for
behavior that deviates from what it has learned as normal behavior.
Note Anomaly detection does not detect e-mail-based worms, such as Melissa.
Worm viruses are automated, self-propagating, intrusion agents that copy themselves and then
facilitate their spread. Worm viruses attack a vulnerable host, infect it, and then use it as a base
to attack other vulnerable hosts. They search for other hosts by using a form of network
inspection, typically a scan, and then propagate to the next target. A scanning worm virus
locates vulnerable hosts by generating a list of IP addresses to probe, and then contacts the
hosts. Code Red worm, Sasser worm, Blaster worm, and the SQL Slammer worm are examples
of worms that spread in this manner.
Anomaly detection identifies worm-infected hosts by their behavior as a scanner. To spread, a

worm virus must find new hosts. It finds new hosts by scanning the Internet using TCP, User
Datagram Protocol (UDP), and other protocols to generate attempts to access different
destination IP addresses. A scanner is defined as a source IP address that generates events on
the same destination port (in TCP and UDP), or same IP protocol for non-TCP or non-UDP
traffic, for too many destination IP addresses.
Anomaly Detection Objectives
Anomaly detection identifies worms that spread by scanning the

net for vulnerable hosts on a specific service.
Anomaly detection looks for:
– A single worm-infected host that enters the network and starts
scanning
– A network that becomes congested by worm traffic
(multiple scanners)
The events that are important to monitor for on the TCP protocol are nonestablished
connections, such as a synchronize/start (SYN) packet that has not received its SYN-
acknowledgment (ACK) response for a given amount of time. A worm-infected host that scans
using TCP protocol generates nonestablished connections on the same destination port for an
anomalous number of IP addresses.
The events that are important to monitor for on the UDP protocol are unidirectional
connections, such as a UDP connection where all of the packets are going only in one direction.
A worm-infected host that scans using the UDP protocol generates UDP packets but does not
receive UDP packets on the same quad within a certain time period on the same destination
port for multiple destination IP addresses.
The events that are important to monitor for other protocols, such as Internet Control Message
Protocol (ICMP), are events from a source IP address to many different destination IP
addresses (that is, packets that are received in only one direction).
Caution If a worm virus has a list of IP addresses that it should infect and does not have to use
scanning to spread itself (for example, it uses passive mapping—listening to the network as
opposed to active scanning), it will not be detected by the worm policies of anomaly
detection. Worm viruses that receive a mailing list from probing files within the infected host
and e-mail this list will not be detected, because no Layer 3 or Layer 4 anomaly is
generated.
Anomaly detection detects the following two situations:

When the network starts to become congested by worm traffic
When a single worm-infected source enters the network and starts scanning for other
vulnerable hosts

Anomaly Detection Components
This topic describes the components used by anomaly detection.
Scanners
Scanner: Source IP that generates scan events on the same

service for multiple destination IP addresses
Scan event:
– TCP: Non established connection—SYN packet without a
matching SYN-ACK for 15 seconds
– UDP: Unidirectional connections—UDP packets on one
direction only for the same quad for 15 seconds
– ICMP or other: Unidirectional connections—IP packets on one
direction only for the same <src-ip,dst-ip, ip-protocol> for 15
seconds
A scanner is a source IP address that generates events on the same destination port (in TCP or
UDP) for too many destination IP addresses. A scanner should not be confused with an
attacker. Typical attackers use a variety of IP addresses to avoid prosecution. Simply put, one
attacker may actually be represented as dozens or even hundreds of scanners.
Histograms
A histogram is a table that represents the distribution of the

source IPs according to their expected scanning behavior.
Histograms are learned or configured by user.
Destination IP address row is the same for all histograms.
Source IP address row can be learned or configured or both.
Each service may hold its own histogram and scanner threshold
or use the default one.
# Source IP addresses A B C
# Destination IP
5 20 100
addresses
A histogram is a chart representing a frequency distribution, and is often represented as a bar

chart. For the purposes of the example, a histogram is represented as a table reflecting the
frequency distribution.
In the chart, the first column represents a certain number of sources, scanning five different
destinations, where A represents the number of sources. The second column represents a certain
number of sources, scanning 20 different targets, where B represents the number of sources.
The last column is a certain number of sources, scanning 100 different targets, where C
represents the number of sources. Collectively, it represents frequency distributions.

Scanners and Histograms Example
# Source IP addresses 18 6 2
# Destination IP addresses 5 20 100
Example - TCP service 80:

Scanner threshold = 120
From a single source you do not expect to see more than 120 unestablished
connections to different destination IP addresses.
You do not expect to see more than 18 sources generate unestablished
connections to 5 or more different destinations.
All values are for a 60-second duration.
In the example, the roles of the histogram and scanner thresholds are combined. Given a
scanner threshold of 120, the example says that not more than 120 incomplete connections to
different destinations are expected to be seen. If that occurs, a signature fires.
The histogram defines the rest of the expectations. This histogram does not expect to see 18
different scanners, each with 5 or more destination addresses. It also does not expect to see 6
different scanners, each with 20 or more destination addresses.
Finally, this histogram example does not expect to see 2 different scanners generate incomplete
Zones
A zone is a set of destination IP addresses.

The purpose of zones is to subdivide the network to achieve a lower rate of false
positives.
There are three types of zones:
– Internal zone
Address set of the protected network
– External zone
You can expect a lower scan rate to the outside network from normal hosts.
Worms may generate a very high rate of scanning to the outside network.
As default, only the external zone receives packets. Other zones receive
traffic only if configured by the user.
– Illegal zone
There are illegal addresses or nonallocated addresses or both.
Traffic toward those addresses might be a strong indication of worm activity.
This configuration allows use of low thresholds for detection.
A zone is a set of destination IP addresses. By subdividing the network into zones, you can
achieve a lower false negative rate. There are three types of zones, each with its own
thresholds: internal, external, and illegal.
The external zone is the default zone with the default Internet range of 0.0.0.0-
255.255.255.255. By default, the internal and illegal zones contain no IP addresses. Packets that
do not match the set of IP addresses in the internal or illegal zone are handled by the external
zone.
It is recommended that you configure the internal zone with the IP address range of your
internal network. If you configure the internal zone in this way, the internal zone is all of the
traffic that comes to your IP address range, and the external zone is all of the traffic that goes to
the Internet.
You can configure the illegal zone with IP address ranges that should never be seen in normal
traffic, for example, unallocated IP addresses, or part of your internal IP address range that is
unoccupied. An illegal zone can be very helpful for accurate detection, because no legal traffic
is expected to reach this zone. This configuration allows very low thresholds, which in turn, can
lead to very quick worm virus detection.
Note Go to http://www.iana.org/assignments/ipv4-address-space to see a list of unused address

spaces to include in the illegal zone.

Configure Anomaly Detection Zones
Configuration
Anomaly
Detections:
ad0
Internal Illegal External
Zone Zone Zone
You enable the zone from the General tab. If the zone is disabled, packets to this zone are
ignored. By default, the zone is enabled.
Next, you add the IP addresses that belong to this zone. If you do not configure IP addresses for
all zones, all packets are sent to the default zone, which is the external zone.
Learning
Learning builds a behavioral profile of the network:

– Observes the actual traffic patterns on the monitored network
– Prevents creation of false alarms on traffic patterns that are actually
normal for the network
– Learns which services have a scanning behavior
– Allows the anomaly detection engine to identify worm attacks even if
they use lower infection rates to avoid detection
Profiles are saved as knowledge base files.
Each knowledge base file contains a list of services, each with their
histograms and thresholds.
Thresholds are the result of multiplying the highest observed rate by a
factor.
Only services with thresholds higher than the default are learned.
Profiles are saved periodically, or manually, by user command.
Anomaly detection initially conducts a “peacetime” learning process when the most normal
state of the network is reflected. Anomaly detection then derives a set of policy thresholds that
best fit the normal network. This learning is done in two phases:
Learn mode
Detect mode

Learning: 24 Hours, 7 Days a Week
Two learning phases:

– Learning the initial baseline (at least 24 hours)
– Detect attacks according to this baseline and keep updating with
gradual changes
Learning is also performed during detection:
– This allows small deviations that do not cross the thresholds.
– Thresholds are the product of multiplying the observed traffic by a
factor (1.2 for histograms and 2 for scanners).
– A new knowledge base is a merge of the current knowledge base and
the new learned profile (the new base is saved during learning only).
Supported by default configuration
– Scheduler is set to save and replace knowledge base every 24 hours.
– Operational mode set to detect.
– No attack detection is in effect when using initial knowledge base.
In the initial setup, the sensor is in learning mode. It is assumed that during this phase no attack
is being carried out. Anomaly detection creates an initial baseline of the network traffic. This
initial baseline is known as a knowledge base. The default amount of time for anomaly
detection to be in the learning mode is 24 hours, but depending on your network complexity,
you may want to change this default. After the learning mode time has expired, you terminate
this phase by configuring anomaly detection to operate in detect mode.
For ongoing operation, the sensor is in learning plus detecting mode. The sensor is in this state
24 hours, 7 days a week. Once the sensor creates a knowledge base, anomaly detection detects
attacks based on the knowledge base. The sensor looks at the network traffic flows that violate
thresholds in the knowledge base and sends alerts. As anomaly detection looks for anomalies, it
also records gradual changes to the knowledge base that do not violate the thresholds and thus
creates a new knowledge base. The new knowledge base is periodically saved and takes the
place of the old one, thereby maintaining an up-to-date knowledge base.
By default, anomaly detection functions even if you do not follow the two phases and manually
change the operational mode from learning to detect. Anomaly detection does not detect attacks
when working with the initial knowledge base, which is empty. After the default of 24 hours,
the default operational mode is changed to detect. A knowledge base is saved and loaded, and
anomaly detection now also detects attacks.
Note Allowing the sensor to learn for more than 24 hours results in fewer false positives.
Operational Mode to Learn
Edit Virtual
Sensor AD
Operational
Mode
Follow these steps to set the operational mode to learning:
Step 1 Log into the Cisco IPS Device Manager (IDM) using an account with administrator
or operator privileges.
Step 3 To edit a virtual sensor, choose the virtual sensor and click Edit.
Step 4 Choose Learn from the AD Operational Mode drop-down list.

Detection
Anomaly detection monitors the network traffic and looks for worms
and scanners.
Anomaly detection compares traffic to the knowledge base histogram
and scanner threshold.
Once a scanner threshold is violated, an alert is triggered for the
appropriate signature.
Once a histogram threshold is crossed, the service is considered to
be under worm attack.
– Anomaly detection tries to detect infected hosts.
– The service scanner threshold is changed to the histogram bucket
value (5, 20, or 100).
Learning is aborted when an attack is detected.
Learning is resumed after no attacks are detected for a configurable
time period.
Anomaly detection monitors the network, constantly looking for worms and scanners. Once the
scanner threshold is crossed, an alert is triggered. When a histogram threshold is crossed, the
scanner is assumed to be a worm. During the time that the sensor believes there is a worm
attack, learning is suspended, so the anomalous traffic is not calculated as part of “normal”
traffic. Because learning is suspended, the learned baseline of “normal” traffic should not be
affected.
Once the worm attack is over, learning resumes. The time period for resuming learning is
configurable.
Note When the virtual sensor is in detect mode, learned thresholds can only go higher.
Detection Example
# Source IP
18 6 2
addresses
# Destination IP
5 20 100
addresses
Scanner Threshold = 145
A single scanner that scans 145 hosts or more will be detected

as a single scanner.
When more than 6 hosts scan 20 destination hosts or more, a
worm attack is presumed (no alert is generated yet).
The scanner threshold is lowered to 20.
Every scanner that scans 20 hosts or more will be detected as
a worm.
When the attack is over, the threshold is set back to 145.
The scanner threshold in the example is set to 145, which means that any single scanner that
scans 145 or more hosts will be detected. An alert is fired at this point.
When more than 6 hosts scan 20 or more targets, a worm is presumed, and the scanner
threshold reduces to 20. However, no alert is fired. From now until the end of the attack, every
host that scans 20 or more destinations is detected as part of the worm attack.

Switch From Learning to Detection
Edit Virtual
Sensor
AD
Operational
Mode
Follow these steps to switch from Learn mode to Detect mode:
Step 3 To edit a virtual sensor, choose the virtual sensor and click Edit.
Step 4 Choose Detect from the AD Operational Mode drop-down list.
Signatures
Anomaly detection uses nine signatures for alerts:

– 13000 to 13008
One signature for each zone and protocol:
– The available zones are Internal, External, and Illegal.
– The available protocols are TCP, UDP, and Other.
Two subsignatures:
– 0: Scanner
– 1: Scanner during worm
The Traffic Anomaly engine contains nine anomaly detection signatures covering three
protocols: TCP, UDP, and Other. Each signature has two subsignatures, one for the scanner and
the other for the worm-infected host, or a scanner under worm attack. When anomaly detection
discovers an anomaly, it triggers an alert for these signatures. All anomaly detection signatures
are enabled by default and the alert severity for each one is set to High.
When a scanner is detected but no histogram anomaly has occurred, the scanner signature fires
for that attacker (scanner) IP address. If the histogram signature is triggered, the attacker
addresses that are doing the scanning each trigger the worm signature, instead of the scanner
signature. The alert details define which threshold is being used for the worm detection now
that the histogram has been triggered. From that point on, all scanners are detected as worm-
infected hosts.
The following anomaly detection event actions are possible:

Produce alert: Writes the event to the Event Store
Deny attacker inline: (inline only) Does not transmit this packet and future packets
originating from the attacker address for a specified period of time
Log attacker pairs: Starts IP logging for packets that contain the attacker address
Log pair packets: Starts IP logging for packets that contain the attacker and victim address
pair
Deny attacker service pair inline: Blocks the source IP address and the destination port
Request SNMP trap: Sends a request to NotificationApp to perform Simple Network
Management Protocol (SNMP) notification
Request block host: Sends a request to the Attack Response Controller (ARC) to block
this host (the attacker)

Anomaly Detection Signatures
Signature Subsignature Name Description

ID ID
13000 0 Internal TCP The signature identified a single scanner

Scanner over a TCP protocol in the internal zone.
13000 1 Internal TCP The signature identified a worm attack over

Scanner a TCP protocol in the internal zone; the
TCP histogram threshold was crossed and
a scanner over a TCP protocol was
identified.
13001 0 Internal UDP The signature identified a single scanner

Scanner over a UDP protocol in the internal zone.
13001 1 Internal UDP The signature identified a worm attack over

Scanner a UDP protocol in the internal zone; the
UDP histogram threshold was crossed and
a scanner over a UDP protocol was
identified.
13002 0 Internal Other The signature identified a single scanner

Scanner over an Other protocol in the internal zone.
13002 1 Internal Other The signature identified a worm attack over

Scanner an Other protocol in the internal zone; the
Other histogram threshold was crossed
and a scanner over an Other protocol was
identified.
13003 0 External TCP The signature identified a single scanner

Scanner over a TCP protocol in the external zone.
13003 1 External TCP The signature identified a worm attack over

Scanner a TCP protocol in the external zone; the
TCP histogram threshold was crossed and
a scanner over a TCP protocol was
identified.
13004 0 External UDP The signature identified a single scanner

Scanner over a UDP protocol in the external zone.
13004 1 External UDP The signature identified a worm attack over

Scanner a UDP protocol in the external zone; the
UDP histogram threshold was crossed and
a scanner over a UDP protocol was
identified.
13005 0 External Other The signature identified a single scanner

Scanner over an Other protocol in the external zone.
13005 1 External Other The signature identified a worm attack over

Scanner an Other protocol in the external zone; the
identified.
13006 0 Illegal TCP The signature identified a single scanner

Scanner over a TCP protocol in the illegal zone.
13006 1 Illegal TCP The signature identified a worm attack over

Scanner a TCP protocol in the illegal zone; the TCP
histogram threshold was crossed and a
scanner over a TCP protocol was
identified.
13007 0 Illegal UDP The signature identified a single scanner

Scanner over a UDP protocol in the illegal zone.
Signature Subsignature Name Description
ID ID
13007 1 Illegal UDP The signature identified a worm attack over

Scanner a UDP protocol in the illegal zone; the UDP
histogram threshold was crossed and a
scanner over a UDP protocol was
identified.
13008 0 Illegal Other The signature identified a single scanner

Scanner over an Other protocol in the illegal zone.
13008 1 Illegal Other The signature identified a worm attack over

Scanner an Other protocol in the illegal zone; the
identified.

Modify Anomaly Detection Signatures
Deny Attacker
Inline
All of these anomaly detection signatures are enabled by default and the alert severity for each
one is set to High. It is recommended that you configure the anomaly detection signature to
include Deny Attacker Inline.
Configuring Anomaly Detection
This topic describes how to configure anomaly detection.
Configuration
It is possible to have multiple anomaly detection instances and

attach each to a different virtual sensor.
These settings are configured per-anomaly detection:
– Scheduler
– Zones IP addresses
– IP addresses to ignore
– Service histograms and scanner thresholds
Any threshold configuration overrides default thresholds or
learned thresholds or both.
On sensors with multiple virtual sensors configured, it is possible to have multiple anomaly
detection instances, each configured differently. The following are settings that are unique to
each instance of anomaly detection:
Scheduler
Zones IP addresses
IP addresses to ignore
Service histograms and scanner thresholds

Configuring Anomaly Detection Policies
Configuration
Add
Anomaly
Detections
Anomaly Detection
Policy Name
In the Anomaly Detections pane, you can add, clone, or delete an anomaly detection policy.
The default anomaly detection policy is called ad0. When you add a policy, a control
the new policy instance is added under Anomaly Detections. If the control transaction fails, for
If your platform does not support virtual policies, you can have only one instance for each
component, and you cannot create new ones or delete the existing one. In this case, the Add,
Clone, and Delete buttons are disabled.
Note Cisco Adaptive Security Appliance Advanced Inspection and Prevention Security Services
Module (ASA AIP-SSM) Software before Version 8.0 and Cisco Intrusion Detection System
(IDS) Network Module do not support sensor virtualization and therefore do not support
multiple policies.
Follow these steps to add an anomaly detection policy:
Step 2 Click Configuration and choose Policies > Anomaly Detections.
Step 3 To add an anomaly detection policy, click Add.
Step 4 In the Policy Name field, enter a name for the anomaly detection policy.
Step 5 Click OK.
Anomaly Detection Configuration
Procedure
1. Add the anomaly detection policy to your virtual sensors.

2. Configure the AD zones, protocols, and services.
3. Set the anomaly detection Operational Mode to Learn.
4. Let the sensor run in learning mode for at least 24 hours.
5. Switch from learning mode to detection mode.
6. Configure the anomaly detection parameters.
Follow this sequence when configuring anomaly detection:
Step 1 Add the anomaly detection policy to your virtual sensors.
You can use the default anomaly detection policy, ad0, or you can configure
a new one.
Step 2 Configure the anomaly detection zones and protocols.
Step 3 Set the AD Operational Mode to Learn.
Note The AD Operational Mode is found in the virtual sensor configuration.
Step 4 Let the sensor run in learning mode for at least 24 hours (the default).
Note It is recommended that you leave the sensor in learning mode for at least 24 hours. If you
can let the sensor run in learning mode for longer, even up to a week, that is better.
After the time period identified for learning, the sensor saves the initial knowledge
base as a baseline of the normal activity of your network.
Step 5 Switch the sensor from learning mode to detection mode.
Note Step 5 is not necessary in a production environment. Anomaly detection will automatically
switch from learning to detection mode after the configured time has elapsed.
Step 6 Configure the anomaly detection parameters:

Configure the worm timeout and which source and destination IP addresses
should be bypassed by anomaly detection. After this timeout, the scanner
threshold returns to the configured value.
Decide whether you want to enable automatic knowledge base updates when
anomaly detection is in detect mode.
Configure the 18 anomaly detection worm signatures to have more event actions
than just the default. For example, configure them to have Deny Attacker event
actions.
Add Anomaly Detection to Virtual Sensor
Edit Virtual
Sensor AD Operational
Mode
to Inactive
Anomaly
Detection
Policy
You can apply the same policy instance, for example, sig0, rules0, and ad0, to different virtual
sensors. Follow these steps to add, edit, and delete virtual sensors:
Step 3 To add a virtual sensor, click Add.
Step 4 Enter a name for the virtual sensor in the Virtual Sensor Name field.
Step 5 Choose an anomaly detection policy from the drop-down list.
Step 6 Choose Inactive from the AD Operational Mode drop-down list.

Configure Anomaly Detection Protocols
Configuration
Anomaly
Detections:
ad0
TCP UDP Other

Protocol Protocol Protocols
You enable or disable the TCP protocol for the internal zone on the TCP Protocol tab. You can
configure a destination port for the TCP protocol, and you can use either the default thresholds
or override the scanner settings and add your own thresholds and histograms.
On the UDP Protocol tab, you enable or disable the UDP protocol for the internal zone. You
can configure a destination port for the UDP protocol, and you can use either the default
thresholds or override the scanner settings and add your own thresholds and histograms.
On the Other Protocols tab, you enable or disable other protocols for the internal zone. You can
configure a protocol number map for the other protocols, and you can use either the default
thresholds or override the scanner settings and add your own thresholds and histograms.
The default thresholds are as follows:

Scanner threshold: 200 scanners
Histogram thresholds:
— Low: 10 source IP addresses where there are 5 destination IP addresses
— Medium: 3 source IP addresses where there are 20 destination IP addresses
— High: 1 source IP address where there is 100 destination IP addresses
Configure Anomaly Detection Services
Configuration
Anomaly
Detections:
ad0
Destination
Port Map
The Add and Edit Destination Port dialog boxes contains the following fields:
Destination Port number: This lets you enter the destination port number. The valid range
is 0 to 65535.
Enable the Service: If checked, this enables the service.
Override Scanner Settings: If checked, this overrides the default scanner settings, and lets
you add, edit, delete, and choose all histograms.
Scanner Threshold: This lets you set the scanner threshold. The valid range is 5 to 1000.
The default is 100.
Threshold Histogram: This displays the histograms that were added.
— Number of Destination IP Addresses: Displays the number of destination IP
addresses that you added for High (100), Medium (20), and Low (5)
— Number of Source IP Addresses: Displays the number of source IP addresses that
you added for High, Medium, and Low
Note Under the destination port map there are no default scanner or histogram values. The
administrator must configure these values.

Scheduler
Configuration
Learning
Anomaly Accept
Detections: Mode
ad0
Schedule
Use the Learning Accept Mode tab to configure whether the sensor will automatically create a
new knowledge base every so many hours. You can configure whether the knowledge base will
be created and loaded (Rotate) or saved (Save Only). You can schedule how often and when the
knowledge base will be loaded or saved. The new updated knowledge base is saved as
KB_current-date.
Note You must be an administrator or operator to configure the Learning Accept Mode.
Follow these steps to configure the Learning Accept Mode for anomaly detection:
Step 1 Log into Cisco IDM using an account with administrator or operator privileges.
Step 2 Click Configuration and choose Policies > Anomaly Detections > ad0 and click
the Learning Accept Mode tab.
Step 3 To have anomaly detection automatically update the knowledge base, check the
Automatically Accept Learning Knowledge Base check box.
Step 4 From the Action drop-down list, choose one of the following action types:
Rotate: With this action option, a new knowledge base is created and loaded.
This option is the default.
Save Only: With this action option, a new knowledge base is created but not
loaded. You can view it to decide if you want to load it.
Step 5 From the Schedule drop-down list, choose one of the following schedule types:
Calendar Schedule: Go to Step 6.
Periodic Schedule: Go to Step 7.
Step 6 To configure the calendar schedule, follow these substeps:
1. Click Add to add the start time. The Add Start Time dialog box appears.
2. Enter the start time in hours, minutes, and seconds using the 24-hour time
format.
Tip To undo your changes and close the Add Start Time dialog box, click Cancel.
3. Click OK.
4. In the Days of the Week field, check the check boxes of the days that you want
the anomaly detection module to capture knowledge base snapshots.
Step 7 To configure the periodic schedule (the default):

1. In the Start Time fields, enter the start time in hours, minutes, and seconds using
the 24-hour time format.
2. In the Learning Interval field, enter the interval of the subsequent knowledge
base snapshots.
Tip To remove your changes, click Reset.

Configure an Anomaly Detection Policy
Configuration
Anomaly
Detections:
ad0
Operation
Settings
From the Operation Settings tab, you can set the worm detection timeout. After this timeout,
the scanner threshold returns to the configured value. You can also configure source and
destination IP addresses that you want the sensor to ignore when anomaly detection is gathering
information for a knowledge base. Anomaly detection does not track these source and
destination IP addresses, and the knowledge base thresholds are not affected by these IP
addresses.
Note You must be an administrator or operator to configure anomaly detection operation settings.
The following fields are on the Operation Settings tab:

Worm Timeout: This lets you enter the time in seconds for the worm termination timeout.
The range is 120 to 10,000,000 seconds. The default is 600 seconds.
Configure IP Address Ranges to Ignore During Anomaly Detection Processing: This
lets you enter IP addresses that anomaly detection should ignore while processing.
— Enable Ignored IP Addresses: If checked, this enables the list of ignored IP
addresses.
— Source IP Addresses: This lets you enter the source IP addresses that you want
anomaly detection to ignore.
— Destination IP Addresses: This lets you enter the destination IP addresses that you
want anomaly detection to ignore.
Follow these steps to configure anomaly detection operation settings:
Step 2 Click Configuration and choose Policies > Anomaly Detections > ad0 and click
the Operation Settings tab.
Step 3 In the Worm Timeout field, enter the number of seconds that you want to wait for
worm detection to time out. The range is 120 to 10,000,000 seconds. The default is
1000 seconds.
Step 4 To enable the list of ignored IP addresses, check the Enable Ignored IP Addresses
check box.
Note You must check the Enable Ignored IP Addresses check box or none of the IP addresses
you enter are ignored.
Step 5 In the Source IP Addresses field, enter the addresses or range of source IP addresses
that you want anomaly detection to ignore. The valid form is 10.10.5.5,10.10.2.1-
10.10.2.30.
Step 6 In the Destination IP Addresses field, enter the addresses or range of destination IP
addresses that you want anomaly detection to ignore.
Tip To remove your changes, click Reset.

Monitoring Anomaly Detection
This topic describes how to monitor and troubleshoot problems with anomaly detection.
Knowledge Base Management
Monitoring
Show
Thresholds
Compare
KBs
Anomaly
Detection
Load
Save Current
Download
Upload
The Anomaly Detection pane displays the knowledge bases for all virtual sensors. On the
Anomaly Detection pane, you can perform the following actions:
Show thresholds of specific knowledge bases
Compare knowledge bases
Load a knowledge base
Make the KB the current knowledge base
Rename a knowledge base
Download a knowledge base
Upload a knowledge base
Delete a knowledge base
Note The anomaly detection buttons are active only if one row in the list is selected, except for
Compare KBs, which can have two rows selected. If any other number of rows is selected,
none of the buttons are active.
The fields and buttons listed here are on the Anomaly Detection pane.
Here are the field descriptions:

Virtual Sensor: This is the virtual sensor to which the knowledge base belongs.
Knowledge Base Name: This is the name of the knowledge base. By default, the
knowledge base is named by its date. The default name is the date and time (year-month-
day-hour_minutes_seconds). The initial knowledge base is the first knowledge base, the
one that has the default thresholds.
Current: “Yes” indicates the currently loaded knowledge base.
Size: This is the size in kilobytes of the knowledge base. The range is usually less than 1
KB to 500 to 700 KB.
Created: This is the date that the knowledge base was created.
Here are the button functions:

Show Thresholds: This button opens the Thresholds window for the selected knowledge
base. In this window, you can view the scanner thresholds and histograms for the selected
knowledge base.
Compare KBs: This button opens the Compare Knowledge Bases dialog box. In this
dialog box, you can choose which knowledge base you want to compare to the selected
knowledge base. It opens the Differences Between Knowledge Bases KB name and KB
name window, where KB name is replaced with the names of the knowledge bases that
were selected.
Load: This button loads the selected knowledge base, which makes it the currently used
knowledge base.
Save Current: This button opens the Save Knowledge Base dialog box. In this dialog box,
you can save a copy of the selected knowledge base.
Rename: This button opens the Rename Knowledge Base dialog box. In this dialog box,
you can rename the selected knowledge base.
Download: This button opens the Download Knowledge Base from Sensor dialog box. In
this dialog box, you can download a knowledge base from a remote server, such as TFTP
or Secure Copy Protocol (SCP).
Upload: This button opens the Upload Knowledge Base to Sensor dialog box. In this
dialog box, you can upload a knowledge base to a remote server, such as TFTP or SCP.
Delete: This button deletes the selected knowledge base.
Refresh: This button refreshes the Anomaly Detection pane.
Note You must be an administrator to monitor anomaly detection knowledge bases.

Monitoring
SensorP#show statistics anomaly-detection <vs name>
Attack in progress
Detection - ON
Learning - OFF
Next KB rotation at 10:00:00 UTC Thu Mar 30 2007
Internal Zone
TCP Protocol
UDP Protocol
Other Protocol
External Zone
TCP Protocol
Service 80
Source IP: 1.1.1.119 Num Dest IP: 10
UDP Protocol
Other Protocol
Illegal Zone
TCP Protocol
UDP Protocol
Other Protocol
The command show statistics anomaly-detection was added to the Cisco IPS Sensor Software
Version 6.0(1) and higher. Besides displaying anomaly statistics, it also reveals whether an
anomaly has been detected and the source of the worm infestation.
In the example, an attack has been perceived with all of the attackers originating from the
external zone.
POSFP Overview
This topic describes the principles behind POSFP.
POSFP Overview
POSFP is a set of features that enables the Cisco IPS sensor to

identify the operating system of an attack victim.
With knowledge of the victim operating system, the Cisco IPS
sensor determines the relevance of the attack to the victim.
Based on the relevance of the attack, the Cisco IPS sensor may
alter the risk rating of the alert for the attack, the Cisco IPS sensor
may filter the alert for the attack, or the Cisco IPS sensor may fo
both of these things.
No initial configuration tasks are required for the POSFP feature
to function. The Cisco IPS sensor ships with a default vulnerable
operating system list for each signature, and passive analysis is
enabled by default.
POSFP lets the sensor determine the operating system that hosts are running. The sensor
analyzes network traffic between hosts and stores the operating system of these hosts with their
IP addresses. The sensor inspects TCP SYN and ACK packets exchanged on the network to
determine the operating system type.
The sensor then uses the target host operating system to compute the Attack Relevancy Rating
(ARR) component of the risk rating. You can then use the risk rating to reduce the number of
false positive alerts, a benefit in promiscuous mode, or definitively drop suspicious packets, a
benefit in inline mode.
POSFP consists of three components:

Passive operating system learning: Passive operating system learning occurs as the
sensor observes traffic on the network. Based on the characteristics of TCP SYN and ACK
packets, the sensor makes a determination of the operating system running on the host of
the source IP address.
User-configurable operating system identification: You can manually configure
operating system host mappings, which take precedence over learned operating system
mappings.
Computation of ARR and risk rating: The sensor uses operating system information to
determine the relevance of the attack signature to the targeted host. The attack relevance is
the ARR component of the risk rating value for the attack alert. The sensor uses the
operating system type reported in the host posture information imported from the
CiscoWorks Management Center for Cisco Security Agent to compute the ARR.

Value of POSFP
When the Cisco IPS sensor operates in inline mode, the POSFP
relevance determination increases the confidence with which the
Cisco IPS sensor may drop suspicious traffic.
When the Cisco IPS sensor operates in promiscuous mode, the
POSFP relevance determination decreases the number of
false positive alerts generated by the Cisco IPS sensor.
POSFP enhances the alert output by reporting the victim
operating system, the source of the operating system
identification, and the relevance to the victim operating system
in the alert.
When the IPS sensor is inline, the operating system relevance factor allows the administrator to
be more aggressive in configuring signature actions.
For sensors in promiscuous mode, the POSFP relevance determination decreases the number of
false positive alerts generated by the sensor.
Whether the sensor is in inline or promiscuous mode, the alert output contains additional,
useful information about the victim and the relevance of the alert.
Operating System Identification
This topic describes the different methods available to identify operating systems.
Operating System Identification

The Cisco IPS sensor has three means to associate an IP address
with an operating system identity.
Method Description
Configured This method involves operating system mappings

entered by an administrator.
Imported This method involves operating system mappings

imported from an external data source. Currently,
Management Center for Cisco Security Agent is the
only data source, but third parties will serve as data
sources in the future.
Learned This method involves operating system mappings
observed by the sensor through the fingerprinting of
TCP packets with the SYN control bit set.
There are three sources of operating system information. The sensor ranks the sources of
operating system information in the following order:
1. Configured operating system mappings
2. Imported operating system mappings (from the CiscoWorks Management Center for Cisco
Security Agent)
3. Learned operating system mappings
When the sensor must determine the operating system for a target IP address, it consults the
configured operating system mappings. If the target IP address is not in the configured
operating system mappings, the sensor looks in the imported operating system mappings. If the
target IP address is not in the imported operating system mappings, the sensor looks in the
learned operating system mappings. If it cannot find it there, the sensor treats the operating
system of the target IP address as unknown.
Note POSFP is enabled by default. The Cisco IPS sensor contains a default vulnerable operating
system list for each signature. If you do not configure any IP addresses for POSFP to
fingerprint, it fingerprints all IP addresses.

Configuring POSFP
This topic describes the available configuration options for POSFP and how to configure them.
Configurable Settings
Although no configuration is required to enable POSFP,

there are still some configuration options available.
Among these are:
Create user-defined operating system mappings
Import operating system mappings
Define the ARR for a specific IP address
Create relevance alert filters
Create a vulnerable operating system list for a signature
Disable passive analysis
You can configure the following aspects of POSFP:

Define operating system mappings: It is recommended that you configure operating
system mappings to define the identity of the operating system running on critical systems.
It is best to configure operating system mappings when the operating system and IP address
of the critical systems are unlikely to change.
Import operating system mappings: Importing operating system mappings provides a
mechanism for accelerating the learning rate and fidelity of the operating system
identifications made through passive analysis. If you have an external product interface,
such as the CiscoWorks Management Center for Cisco Security Agent, you can import
operating system identifications from it.
Define the ARR for a specific IP address: This option limits the ARR calculations to IP
addresses on the protected network.
Define event action rules filters using the target operating system relevancy value:
This option provides a way to filter alerts solely on operating system relevancy.
Note You must be an administrator or operator to add, edit, and delete configured operating
system maps.
Configuring User-Defined Operating
System Mappings
Configuration
Event Action
Rules:rules0
Add
The relevant fields on the OS Identifications tab are as follows:

Enable Passive OS Fingerprinting Analysis: When checked, this option lets the sensor
perform passive operating system analysis.
Configured OS Map: This displays the attributes of the configured operating system map.
— Name: The name you give the configured operating system map
— Active: Whether this configured operating system map is active or inactive
— IP Address: The IP address of this configured operating system map
— OS Type: The operating system type of this configured operating system map
Note The Restrict OS Mapping and ARR to These IP Addresses field is discussed later in this
topic.

Manually Configured Operating System
Map
Name of Operating
System Map
IP
Addresses OS
Type
The following fields and options are on the Add and Edit Configured OS Map dialog boxes.
Name: This lets you name the configured operating system map.
Active: This lets you choose to have the configured operating system map active or
inactive.
IP Address: This lets you enter the IP address associated with this configured operating
system map. The IP address for the configured operating system mappings, and only the
configured operating system mappings, can be a set of IP addresses and IP address ranges.
The following are all valid IP address formats for configured operating system mappings:
— 10.1.1.1,10.1.1.2,10.1.1.15
— 10.1.2.1
— 10.1.1.1-10.2.1.1,10.3.1.1
— 10.1.1.1-10.1.1.5
OS Type: This lets you choose one of the following operating system types to associate
with the IP address:
— AIX
— BSD
— General OS
— HP UX
— IOS
— IRIX
— Linux
— Mac OS
— Netware
— Other
— Solaris
— UNIX
— Unknown OS
— Win NT
— Windows
— Windows NT/2K/XP

Data Source for Imported Mappings
Configuration
External
Product
Interfaces
Management
Center for Cisco
Security Agents
CiscoWorks Management Center for Cisco Security Agent receives host posture information
from the Cisco Security Agent software that it manages. It also maintains a watch list of IP
addresses that it has determined should be quarantined from the network.
CiscoWorks Management Center for Cisco Security Agent sends two types of events to the
sensor—host posture events and quarantined IP address events.
Host posture events contain the following information:

Unique host ID assigned by CiscoWorks Management Center for Cisco Security Agent
Network Admission Control (NAC) posture

Protocol associated with a rule violation (TCP, UDP, or ICMP)
Indicator of whether a rule-based violation was associated with an established session or a
UDP packet

IP Range Restriction for Risk Rating
Relevance Calculation
Restrict OS
Mapping and
ARR to These IP
Addresses
To configure restrictions on the operating system mapping done by the sensor, it is necessary to
complete the following steps:
Step 2 Click Configuration and choose Policies > Event Action Rules > rules0 and then
click the OS Identifications tab.
Step 3 Confirm that the Enable Passive OS Fingerprinting Analysis check box is
checked.
Step 4 In the Restrict OS Mapping and ARR to These IP Addresses field, add the addresses
used by the networks monitored by this virtual sensor.
Relevance Alert Filters
OS Relevance
Follow these steps to edit the event action filter OS Relevance value:
Step 2 Click Configuration and choose Policies > Event Action Rules > rules0 and then
click the Event Action Filter tab.
Step 3 Click Edit to edit an event action filter.
The Edit Event Action Filter dialog box appears.
Step 4 In the OS Relevance drop-down list, choose whether you want to know if the alert is
relevant to the operating system that has been identified for the victim.

Signature Vulnerable OS List
Vulnerable OS
List
Select Operating
Systems
Follow these steps to edit a signature:
Step 2 Click Configuration and choose Signature Definitions > sig0 and click the
Signature Configuration tab.
Step 3 Click Edit.
Step 4 Click the Vulnerable OS List field.
Step 5 In the Select Item(s) dialog box, choose the vulnerable operating system (or
systems) and click OK.
Tip To choose more than one operating system, hold down the Ctrl key.
Disable POSFP
Configuration
Event Action
Rules:rules0
Enable Passive OS
Fingerprinting
Analysis
To disable POSFP, perform the following steps:

Step 1 Click Configuration.
Step 2 Choose Event Action Rules > rules0 and click the OS Identifications tab.
Step 3 Clear the Enable Passive OS Fingerprinting Analysis check box.

Monitoring POSFP
This topic describes how to examine the results of POSFP.
Monitoring Learned Operating Systems
Monitoring
Learned OS
The Learned OS pane displays the learned operating system mappings that the sensor has
learned from observation of traffic on the network. The sensor inspects TCP session
negotiations to determine the operating system running on each host.
You can clear the list or delete one entry by choosing the row and clicking Delete.
Note If POSFP is still enabled, and hosts are still communicating on the network, the learned
operating system mappings are immediately repopulated.
Follow these steps to delete a learned operating system value or to clear the entire list:
Step 2 Click Monitoring and choose OS Identifications > Learned OS.
Step 3 To delete one entry in the list, choose it in the Learned OS pane, and click Delete.
Step 4 To clear all learned operating system values, click Clear List from the Learned OS
pane.
Note You must be an administrator to clear and delete learned operating system mappings.
Monitoring Imported Operating Systems
Monitoring
Imported OS
The Imported OS pane displays the operating system mappings that the sensor has imported
from CiscoWorks Management Center for Cisco Security Agent if you have it set up as an
external interface product on the Configuration > External Product Interfaces pane.
You can clear the list or delete one entry by choosing the row and clicking Delete.
Follow these steps to delete an imported operating system value or to clear the entire list:
Step 1 Log into Cisco IDM using an account with administrator privileges.
Step 2 Click Monitoring and choose OS Identifications > Imported OS.
Step 3 To delete one entry in the list, choose the entry from the Imported OS pane, and
click Delete.
Step 4 To clear all imported operating system values, click Clear List from the Imported
OS pane.
Note You must be an administrator to clear and delete imported operating system mappings.

Notes on POSFP
Configured operating system mappings reside in the event action

rules and may apply to one or many virtual sensors.
Imported operating system mappings are global and apply to all
virtual sensors.
Learned operating system mappings are specific to the virtual
sensor that sees the traffic.
If the victim operating system is unknown and the vulnerable
operating system of the signature is General OS, the alert
relevance = relevant.
These mappings apply to specific virtual sensors:

Configured operating system mappings
Learned operating system mappings
The following applies to all virtual sensors:

Imported operating system mappings
When the victim operating system is unknown and the vulnerable operating system setting of
the signature is General OS, the alert relevance is “relevant.”
Summary
Summary
Anomaly detection identifies worms as they attempt to spread.

Scanners and histograms make up the primary worm detection tools.
It is possible to have multiple anomaly detection instances and attach each to
a different virtual sensors.
From the Anomaly Detection pane, you can monitor and manage the
knowledge bases used for anomaly detection.
POSFP is a set of features that enables the Cisco IPS sensor to identify the
operating system of an attack victim.
Cisco IPS sensors learn operating systems by:
– Observing TCP segments
– Importing them from Cisco Security Agent
– Manual configuration of operating system mappings
POSFP is on by default.
The Learned OS pane displays the learned operating system mappings that
the sensor has learned.

Lesson 5
Configuring Blocking
Overview
This lesson explains how to configure the blocking capability on a Cisco Intrusion Prevention
System (IPS) sensor and how blocking is used. In addition, this lesson explains the issues that
you should consider before you select the interface on which to apply the blocking access
control lists (ACLs).
Objectives
Upon completing this lesson, you will be able explain blocking concepts and use the Cisco IPS
Device Manager (IDM) to configure blocking for a given scenario. This ability includes being
able to meet these objectives:
Explain the principles behind blocking
Describe the things that should be taken into account before applying ACLs
Explain how to configure a sensor to perform automatic blocking
Explain how to configure a sensor to perform manual blocking
Explain how to configure a master blocking scenario
Blocking Overview
This topic explains blocking and provides guidelines for designing a Cisco IPS solution that
incorporates the blocking feature.
Definitions
Blocking: A Cisco IPS sensor feature that prevents packets from reaching
their destination; initiated by a sensor and performed by another Cisco
device at the request of the sensor
ARC: The blocking application on the sensor
Device management: The ability of a sensor to interact with a Cisco
device and dynamically reconfigure the Cisco device to stop an attack
Blocking device: The Cisco device that blocks the attack; also referred to
as a managed device
Blocking sensor: The Cisco IPS sensor configured to control the
managed device
Managed interface or VLAN: The interface or VLAN on the managed
device where the Cisco IPS sensor applies the ACL or VACL
Active ACL or VACL: The ACL or VACL created and applied to the
managed interfaces or VLANs by the sensor
The following terms are used when discussing the Cisco IPS blocking feature:
Blocking: This is a Cisco IPS feature that prevents packets from reaching their destination.
Blocking is initiated by a sensor and performed by another Cisco device at the request of
the sensor.
Attack Response Controller (ARC): This is the blocking application on the sensor. The
ARC starts and stops blocks. It monitors the time for the block and removes the block after
the time has expired. ARC, formerly known as Network Access Controller (NAC) in Cisco
IPS Sensor Software prior to Version 6.0, is also used in rate limiting.
Device management: This is the ability of a sensor to interact with a Cisco device and
dynamically reconfigure the Cisco device to block the source of an attack in real time.
Managed device: This is the Cisco device that actually blocks the attack. It is also referred
to as a blocking device.
Blocking sensor: This is a sensor that has been configured to control a managed device.
Managed interface or VLAN: This is the interface or VLAN on the managed device
where the sensor applies the dynamically created ACL or VLAN ACL (VACL). This
interface or VLAN is also referred to as a blocking interface or blocking VLAN.
Note The Cisco PIX 500 Series Security Appliances and the Cisco ASA 5500 Series Adaptive
Security Appliances use the shun command to enforce a block. The Cisco PIX security
appliance and Cisco ASA adaptive security appliance ACLs are not modified.
Active ACL or VACL: This is the ACL or VACL dynamically created and maintained by
the sensor and applied to the managed interface or VLAN.
Blocking Devices
Cisco routers
Cisco PIX 500 Series Security Appliances
Cisco Catalyst 6500 Series Firewall Services Modules
Cisco Catalyst 6500 Series Switches
Cisco ASA 5500 Series Adaptive Security Appliances
The ARC can control up to 250 supported devices in any combination. The following lists
blocking devices that have been tested and approved to work with the sensors and device
management:
Cisco routers running Cisco IOS Release 11.2 or later using ACLs
Cisco PIX 500 Series Security Appliances running Software Version 6.0 or later using the
shun command; you must use one of the following Cisco PIX security appliance models:
— Cisco PIX 501 Security Appliance
— Cisco PIX 506E Security Appliance
— Cisco PIX 515E Security Appliance
Cisco Catalyst 6500 Series Firewall Services Modules (FWSMs)
Cisco ASA 5500 Series Adaptive Security Appliances running Version 7.0 or later using
the shun command
Note If the Cisco Catalyst Series FWSM is configured in multimode, blocking is not supported for
the administrative context. Blocking is only supported in single mode and in multimode
customer context.
Cisco Catalyst 6500 Series Switches with Cisco IOS Release 12.1(13)E or later using
ACLs

Cisco Catalyst 6000 Series Switches with Cisco Catalyst Operating System Software
version 7.5(1) or later using VACLs
— Cisco Catalyst 6000 Series Supervisor Engine 1A with Policy Feature Card (PFC)
— Cisco Catalyst 6000 Series Supervisor Engine 1A with Multilayer Switch Feature
Card 1 (MSFC1)
— Cisco Catalyst 6000 Series Supervisor Engine 1A with Multilayer Switch Feature
Card 2 (MFSC2)
— Cisco Catalyst 6000 Series Supervisor Engine 1A with MFSC2 required
Blocking is done with ACLs, VACLs, or the shun command. All of the Cisco PIX security
appliance models that support the shun command can be used as blocking devices.
Blocking Device Requirements
The sensor must be able to communicate with the device via IP.
Remote network access must be enabled and permitted from the
sensor to the managed device using one of the following:
– Telnet
– SSH (default)
If using SSH, the blocking device must have an encryption license
for DES or 3DES.
The sensor must be able to communicate with the blocking device. The sensor must have a
route to, or must be on the same subnet as, the managed firewall.
The blocking device must also have one of the following configured:
Telnet: Telnet access should be allowed from the sensor.
Secure Shell (SSH): SSH access should be allowed from the sensor.
SSH is the default communication mechanism between the sensor and the blocking device. If
SSH is used, the blocking device must have a software license that supports Data Encryption
Standard (DES) or Triple Data Encryption Standard (3DES) encryption.
As soon as the blocking device is configured on the sensor, the sensor attempts to log into the
blocking device using the specified credentials and access protocol, Telnet or SSH. If the
sensor logs in successfully, a user connection is maintained between the sensor and the
blocking device. This persistent connection allows the sensor to immediately and dynamically
configure blocking rules on the blocking device as required.
This table displays a partial sample configuration for a Cisco router that supports SSH
authentication from the sensor using the local database for password authentication.

Sample Configuration for a Router Blocking Device
Subhead Subhead
hostname router1 This establishes the router identity.
username sensor This creates sensor username account for SSH login.
password 0 secret
aaa new-model —
aaa authentication This defines the login profile named “ssh” to use the local user
login ssh local enable database for authentication; the enable password is used as a
backup.
ip domain-name This establishes the domain identity of the router.
company.com
ip ssh time-out 90 (Optional) This sets the SSH timeout to 90 seconds. The default
is 60 seconds.
ip ssh authentication- (Optional ) This sets the number of allowed retries to 2. The
retries 2 default is 3.
line vty 0 4 This enters line vty configuration mode.
login authentication This configures the vty lines to authenticate using the login profile
ssh named “ssh.”
transport input ssh This enables the SSH transport on the vty line.
The Cisco IOS command crypto key generate rsa does not appear in the static configuration,
but is used to enable the SSH server and generates the server public and private keys for SSH
authentication.
The Cisco IOS commands show users and show ssh can be used to verify that the sensor has
logged into the Cisco router and established an SSH connection; the encryption level is also
displayed.
The “Sample Cisco PIX Security Appliance Configuration” table displays a partial sample
configuration for a Cisco PIX security appliance that supports SSH authentication from the
sensor using local password authentication, not authentication, authorization, and accounting
(AAA).
Sample Cisco PIX Security Appliance Configuration
Command Description
passwd secret Defines the SSH local password
hostname pix1 Establishes the identity of the Cisco PIX security appliance for
key generation
domain-name Establishes the domain identity of the Cisco PIX security

company.com appliance for key generation
ssh 172.16.1.1 Allows SSH traffic only from host 172.16.1.1 on the inside
255.255.255.255 inside network
ssh timeout 60 (Optional) Sets the SSH timeout to 60 seconds
Once the hostname and domain name of the Cisco PIX security appliance are set, the Cisco PIX
security appliance ca generate rsa key command is used to generate the server public and
private keys for SSH authentication; the ca save all command is then used to save the Rivest,
Shamir, and Adleman (RSA) key pair to flash memory.
The Cisco PIX security appliance show ssh sessions command can be used to verify that the
sensor has logged into the Cisco PIX security appliance and established an SSH connection.
The encryption level is also displayed.
Note If local authentication, not AAA, is used for SSH on the Cisco PIX security appliance, the
SSH username is always “pix.” There is no per-user name entry.

Adding the Device to the Sensor Known
Hosts List
Configuration
Sensor Setup
SSH
Add
Known Host
Key
If you select SSH-DES or 3DES as the secure communication method, SSH password
authentication is used, not public key authentication. To configure the sensor to communicate
with a blocking device using SSH, you must configure the SSH public key of the blocking
device on the sensor. The sensor can automatically retrieve the SSH parameters from the router,
if properly configured for an SSH server.
Follow these steps to add the blocking device to the sensor known hosts list:
Step 1 Click Configuration and choose Sensor Setup > SSH > Known Host Keys. The
Known Host Keys panel is displayed.
Step 2 Click Add. The Add Known Host Key window opens.
Blocking Guidelines
Implement antispoofing mechanisms

Identify hosts that are to be excluded from blocking
Identify network entry points that will participate in blocking
Assign a block reaction to signatures that are deemed an
immediate threat
Determine the appropriate blocking duration
Cisco IPS blocking is a powerful feature that you should use only after thorough planning. The
automatic blocking feature generates blocking rules, ACLs, VACLs, and shun commands,
based solely on the IP addresses of the hosts that generate the alarms. The sensor cannot
determine whether the attacking host should be considered a friend or a foe. Consequently, the
blocking feature could block legitimate network traffic. There are several key points to
remember when designing and implementing blocking:
Antispoofing mechanisms: Attackers will forge packets with IP addresses that are either
private addresses (RFC 1918) or addresses on your internal network. The goal of the
attacker could be to elude detection, to gain privileged access using a trusted address, or to
cause a denial of service (DoS) if sensor blocking is configured. If you implement a proper
antispoofing mechanism and network ingress and egress filtering (RFC 2827), the sensor
does not block possibly valid addresses.
Critical hosts: Each network has critical hosts that should not be blocked. It is important to
identify these hosts to prevent possible network disruptions.
Network topology: Determine which devices should be blocked by which sensor. Two
sensors cannot control blocking on the same device.
Entry points: Networks of today have several entry points to provide for reliability,
redundancy, and resilience. These entry points are avenues for someone to attack your
network. It is important to identify all of the entry points and decide whether the connecting
devices should participate in blocking.
Signature selection: Cisco IPS sensors contains several hundred signatures that can be
configured for blocking. It is not feasible to perform blocking on all of the signatures.
Identify which signatures are best suited for blocking. For example, if you were allowing
only web traffic to your server farm, you would identify web-related signatures specific to
your web server software. From this list of signatures, you would then identify those
signatures whose severity is ranked high and could potentially lead to access. These
signatures would be candidates for blocking.

Blocking duration: By default, the Cisco IPS sensor automatically blocks for 30 minutes.
Determine the appropriate time for your network environment.
Device login information: Before you configure blocking, you must determine any
usernames, passwords, enable passwords, and connection types needed to log into each
blocking device.
Interface ACL requirements: Be sure that you understand which interfaces should and
should not be blocked to avoid accidentally shutting down an entire network.
ARC Block Actions
Two events cause the ARC to initiate a block:

Automatic blocking: A signature configured with one of the
following block actions generates an alert:
– Request block host
– Request block connection
Manual blocking: You manually configure the ARC to block in real
time:
– Request block host
– Request block network
The ARC is the sensor service that initiates the network access control, or blocking, function.
The ARC controls the starting and stopping of blocks on routers, switches, Cisco PIX security
appliances, and Cisco ASA adaptive security appliances.
The following events cause the ARC to initiate a block:
Automatic blocking: A signature configured with a block action generates an alert. You
can configure either of two block actions for a signature.
— Request block host: Blocks all of the traffic from a given IP address
— Request block connection: Blocks traffic from a given source IP address to a given
destination IP address and destination port
Note Multiple connection blocks from the same source IP address to a different destination IP
address or destination port automatically switch the block from a connection block to a host
block.
Manual blocking: You manually configure the ARC to block a specific host or network
address.

ACL Considerations
This topic describes the considerations that you should take into account before applying
ACLs.
Blocking Scenario
192.168.1.10 172.26.26.1
1
Sensor
2 Attacker attacks
detects
192.168.1.10.
attack.
Protected Deny Untrusted

Network 172.26.26.1 Network
3 Sensor writes ACL. 4 Router blocks attacker.
The following steps describe the process for the scenario in the figure, in which a signature is
configured with a blocking action:
Step 1 An attack starts when an attacker executes a hack to gain access to the protected
network. In the figure, the attacker IP address is 172.26.26.1. The attacker has
launched attacks against the server at 192.168.1.10.
Step 2 The sensor detects the attack. The signature triggered was configured so that an
automatic block is enforced.
Step 3 The sensor writes a new ACL on the managed router denying traffic from the
attacking host.
Step 4 The managed router then denies any traffic generated by the attacking host until the
block is manually removed or the default automatic block time expires. The ACL
entry written to the router would be similar to the following example:
Extended IP access list IDS_Ethernet0/1_in_1
20 deny ip host 172.26.26.1 any
30 permit ip any any
The ACL name indicates the source, IPS, the interface and direction (e0/1_in), and a unique
identifier, 1. The ACL is applied to the appropriate interface in the specified direction. Here is
an example:
interface Ethernet0/1
ip access-group IDS_e0/1_in_1 in

Where to Apply ACLs
When the sensor has full Untrusted

Network
control, no manually entered
ACLs are allowed.
For an external interface, External Inbound
prefer an inbound direction. Interfaces ACL
For an internal interface, prefer
an outbound direction.
Internal Outbound
Interfaces ACL
Protected
Network
Selecting the blocking interfaces on the blocking device and specifying the direction of traffic
that you want blocked are important configuration tasks. The sensor must have full control of
an assigned interface ACL. The sensor writes ACLs and applies them to the blocking device
until the device is no longer defined as a blocking device. Manually configured ACLs are not
allowed on this interface but can be applied to other interfaces or incorporated into the
dynamically created ACL.
You must decide on which interface and in which direction to apply the ACL. You can apply
the ACL on either the external or the internal interface of the router. You can also configure it
for either inbound or outbound traffic on these interfaces.
If you select an external interface as the managed interface, the recommended ACL direction is
inbound. If you select an internal interface as the managed interface, the recommended ACL
direction is outbound. Either of these strategies will block attacks in the direction of the
protected network.
Note Sensor blocking ACLs are incompatible with Context-Based Access Control (CBAC), a
component of the Cisco IOS Firewall Feature Set.
Applying ACLs on External vs. Internal
Interfaces
External interface in the Internal interface in the

inbound direction: outbound direction:
– Denies packets from the – Denies packets from the
host before they enter the host before they enter the
router protected network
– Provides the best – Does not apply to the
protection against an router itself
attacker
Applying the ACL to the external interface in the inbound direction denies a host access before
the router processes packets. Applying the ACL to the internal interface in the outbound
direction denies a host access to the protected network but allows packets to be processed by
the router. The latter scenario is less desirable, but it may be required if an existing ACL is
already applied to an external interface.
Based on your unique network architecture and security policy, you must decide which
configuration will meet your needs for security and functionality.

Using Existing ACLs
The sensor takes full control of ACLs on the managed interface.

Existing ACL entries can be included before the dynamically
created ACL. This is referred to as applying a Pre-Block ACL.
Existing ACL entries can be added after the dynamically created
ACL. This is referred to as applying a Post-Block ACL.
The existing ACL must be an extended IP ACL, either named or
numbered.
Each interface and direction combination of a blocking device can have only one active ACL.
Therefore, if an interface needs other ACL entries besides the blocking ACL entries generated
by the sensor, you should configure these additional entries in the form of Pre-Block and Post-
Block ACLs. You must configure the Pre-Block and Post-Block ACLs on the blocking device
independently of the sensor. These ACLs allow an administrator to include access rules that
must be processed before and after the blocking rules are added by the sensor.
Pre-Block ACLs: These override the deny lines resulting from blocks. Pre-Block ACLs
are used for permitting what you do not want the sensor to block. When a packet is checked
against an ACL, the first line that is matched determines the action. If the first line matched
is a permit line from the Pre-Block ACL, the packet is permitted, even though there could
be a deny line from an automatic block listed later in the ACL.
Post-Block ACLs: These are used for additional blocking or permitting of what you want
to occur on an interface or direction. If you have an existing ACL on an interface that the
sensor manages, that existing ACL can be used as a Post-Block ACL. The sensor creates an
ACL with the following entries and applies it to the specified interface with the specified
direction, in or out:
— A permit line for the sensor IP address, unless you have allowed blocking of the
sensor IP address
— Copies of all of the configuration lines of the Pre-Block ACL
— A deny line for each address being blocked by the sensor
— Copies of all of the configuration lines of the Post-Block ACL
If you do not have a Post-Block ACL, the sensor inserts “permit ip any any” at the end of the
new ACL. When you apply the new ACL to an interface or direction of the router, it removes
the application of any other ACL to that interface or direction.
You must create any Pre-Block and Post-Block ACLs that you plan to use on your blocking
device before you specify them in the Cisco IDM. Pre-Block and Post-Block ACLs must be
extended IP ACLs, either named or numbered. See the documentation for your blocking device
for more information on creating ACLs.
Note When blocking is not in effect, the ACL applied to the interface is simply a combination of
the Pre-Block and Post-Block ACLs without any blocking entries inserted.
The following are examples of blocking ACLs. They depict portions of a blocking
configuration for a Cisco IOS router that implements Pre-Block and Post-Block ACLs on
interface serial0/0 for the inbound direction. The predefined Pre-Block ACL is named
Pre-ACL, and the predefined Post-Block ACL is named Post-ACL.
ip access-list extended pre-ACL
deny ip any host 172.16.16.200
deny tcp any host 192.168.2.2 eq ftp
!
ip access-list extended post-ACL
permit tcp any any
The “ACL Configuration Before Blocking” table displays the ACL configuration as it appears
on a Cisco router after the sensor takes control of the interface but before blocking is initiated,
or after the blocking duration has expired.
ACL Configuration Before Blocking
Configuration Description
interface Serial0/0 —
ip access-group IDS_Serial0/0_in_1 in ACL applied to interface in the “in”
direction
ip access-list extended IDS_Serial0/0_in_1 —
permit ip host 172.16.16.110 any IP address to never block entry
deny ip any host 172.16.16.200 Pre-Block ACL entry
deny tcp any host 198.168.2.2 eq ftp Pre-Block ACL entry
permit tcp any any Post-Block ACL entry
The “ACL Configuration During Blocking” table displays the ACL configuration while an
active block is in progress on a Cisco IOS router. In the example, a signature was set to trigger
a connection block for attacks to the web server:

ACL Configuration During Blocking
Configuration Description
interface Serial0/0 —
ip access-group IDS_Serial0/0_in_1 in ACL applied to interface in the “in”
direction
ip access-list extended IDS_Serial0/0_in_1 —
permit ip host 172.16.16.110 any IP address to never block entry
deny ip any host 172.16.16.200 Pre-Block ACL entry
deny tcp any host 192.168.2.2 eq ftp Pre-Block ACL entry
deny tcp host 10.1.1.200 host Blocking ACL entry with logging
172.16.16.100 eq www log enabled
permit tcp any any Post-Block ACL entry
Configuration Tasks
Tasks to configure a sensor for automatic blocking:

Assign a block reaction to a signature.
Assign the sensor global blocking properties.
Create the device login profiles that the sensor uses when logging
into blocking devices.
Define the blocking device properties.
For Cisco IOS or Catalyst 6500 Series devices, assign the
properties of the managed interface.
(Optional.) Define a master blocking sensor.
Perform the following tasks to configure a sensor for blocking:

Assign a block reaction to a selected signature: This task involves using the Cisco IDM
to configure a signature action to block.
Assign the sensor global blocking properties: This task involves enabling blocking and
defining blocking parameters, such as the maximum number of blocking entries, regardless
of whether to allow the sensor IP address to be blocked, and IP addresses that should never
be blocked.
Create device login profiles: This task involves defining the username, password, and
enable password for communication between the sensor and the blocking device for
blocking.
Define the blocking device properties: This task involves defining the properties of the
blocking device such as device type, IP address, username, password, and communication
method.
Assign the managed interface properties for Cisco IOS or Cisco Catalyst 6500 devices:
This task involves selecting the blocking interface or VLAN, specifying the direction in
which ACLs are applied, and assigning Pre-Block and Post-Block ACLs or VACLs.
(Optional) Define a master blocking sensor: This task involves adding the sensor that
will perform blocking on behalf of this sensor.

Configuring Blocking Properties
Configuration
Enable Blocking
Allow
Sensor IP
Address to
be Blocked
Blocking
Maximum
Blocking Block Entries Add
Properties
After you configure the signature action, you can use the options in the Cisco IDM Blocking
menu to configure blocking. Follow these steps to configure the sensor blocking properties:
Step 1 Click Configuration and choose Blocking > Blocking Properties. The Blocking
Properties panel is displayed.
Step 2 Check the Enable Blocking check box if it is not already selected. By default,
blocking is enabled. You might want to disable blocking, for example, if the ARC is
managing a device on which you must manually configure something. This prevents
a situation in which both you and the ARC are making a change at the same time on
the same device. This could cause the device or the ARC to fail.
Step 3 If you want to allow the sensor IP address to be blocked, check the Allow Sensor IP
Address to be Blocked check box. It is recommended that you do not allow the
sensor to block itself because it could stop communicating with the managed device.
You can choose this option if you can ensure that, if the sensor creates a rule to
block its own IP address, it will not be prevented from accessing the blocking
device.
Step 4 Enter the number of blocks that are to be maintained simultaneously in the
Maximum Block Entries field. Valid values are 1 to 65535. The default is 250.
Setting the maximum block entries higher than 250 is not recommended. The
number of blocks will not exceed the maximum block entries. If the maximum is
reached, new blocks will not occur until existing blocks time out and are removed.
Step 5 Click Add to add a host or network to the list of addresses never to be blocked. The
Add Never Block Address window opens.
Adding Never Block Addresses
IP Address
Mask
Step 6 Enter the IP address of the host or network in the IP Address field. This is the IP
address to never block.
Step 7 Choose the network mask that corresponds to the IP address from the Mask drop-
down menu.
Step 8 Click OK. The new host or network appears in the Never Block Addresses list on
the Blocking Properties panel.

How to Configure Automatic Blocking
This topic covers how to configure a sensor to perform automatic blocking.
Configuring Blocking Actions
Configuration
Signature
Definition:sig0
Signature
Configuration
Actions
The first step to configure automatic blocking is to select a signature and set its alert response
to block the offending host or connection. If you choose to block a host, all of the packets with
the source address of the suspected intruder are blocked. If you choose to block a connection,
only those packets that are moving from the offending source to its target and are associated
with the offending protocol are blocked.
Follow these steps to configure a signature action to perform blocking when the signature is
triggered:
Step 1 Click Configuration and choose Signature Definition > Signature Configuration.
Step 2 From the sig0 panel, click Actions. The Assign Actions window opens.
Configuring Device Login Profiles
Configuration
Add
Blocking
Device Login
Profiles
The next step for configuring blocking is to specify the username and password that the sensor
uses when logging into blocking devices. Although you can create multiple profiles, one device
login profile can be used for multiple devices. For example, routers that all share the same
passwords and usernames can use the same device login profile. You must configure a device
login profile before configuring the blocking devices.
Follow these steps to configure device login profiles:

Step 1 Click Configuration and choose Blocking > Device Login Profiles. The Device
Login Profiles panel is displayed.
Step 2 Click Add to add a profile. The Add Device Login Profile window opens.

Configuring Device Login Profiles (Cont.)
Profile
Name
Username
New
Password
Confirm
New
Password
New
Password
Confirm
New
Password
Step 3 Enter a name for your profile in the Profile Name field.
Step 4 Enter the username used to log into the blocking device in the Username field. This
step is optional.
Step 5 Enter the password used to log into the blocking device in the New Password field.
This step is optional.
Step 6 If you entered a password, enter the password again in the Confirm New Password
field.
Step 7 Enter the enable password used on the blocking device in the New Password field.
This step is optional.
Step 8 If you entered an enable password, enter it again in the Confirm New Password
field.
Step 9 Click OK. You receive an error message if the profile name already exists. The new
device login profile appears in the list on the Device Login Profile panel.
Configuring Blocking Devices
Configuration
Blocking Add
Blocking
Devices
After configuring device login profiles, you are ready to configure your blocking devices.
Follow these steps to configure blocking devices:
Step 1 Click Configuration and choose Blocking > Blocking Devices. The Blocking
Devices panel is displayed.
Step 2 Click Add to add a blocking device. You receive an error message if you have not
configured the device login profile. The Add Blocking Device window opens.

Configuring Blocking Devices (Cont.)
IP Address
Sensor’s NAT
Address
Device Login
Profile
Device Type
Response
Capabilities
Communication
Step 3 Enter the IP address of the blocking device in the IP Address field.
Step 4 Enter the sensor Network Address Translation (NAT) address in the Sensor’s NAT
Address field. This is an optional field.
Step 5 Choose the device login profile from the Device Login Profile drop-down list. This
login profile is used to log into the blocking device.
Step 6 Choose the device type from the Device Type drop-down list.
Step 7 Choose the communication mechanism used to log into the blocking device from the
Communication drop-down menu.
Step 8 Click OK.
You can configure a Cisco PIX security appliance running Cisco PIX Firewall Software
Version 7.0 or later or a Cisco ASA adaptive security appliance to function as multiple virtual
devices, with each virtual device having its own IP addresses, configuration, and session
tracking. This configuration is referred to as multiple virtual firewalls or multimode. Each
virtual firewall instance is referred to as a context. There are three types of contexts.
System: Where system-level commands are executed and where the other contexts are
created
Admin: The primary user context
Additional user contexts: Contains additional instances or virtual firewalls
Each admin and user context has an IP address and can be managed as its own device, with the
exception of executing system-level commands. Blocking can be done in the user contexts. The
ARC treats each user context as a separate device. You must configure the ARC to separately
connect to each user context IP address on which you want blocking to occur.
Configuring Router Blocking Device
Interfaces
Configuration
Add
Blocking
Router
Blocking
Device
Interfaces
Follow these steps to configure the blocking device interfaces if your blocking device is a
router.
Step 1 Click Configuration and choose Blocking > Router Blocking Device Interfaces.
Step 2 Click Add. The Add Router Blocking Device Interface window opens.

Configuring Router Blocking Device
Interfaces (Cont.)
Router
Blocking
Device
Blocking
Interface
Direction
Pre-Block
ACL
Post-Block
ACL
Step 3 Choose the IP address of the router blocking device from the Router Blocking
Device drop-down menu.
Step 4 Enter the blocking interface name in the Blocking Interface field. This is the
interface to be used on the router blocking device. A valid value is 2 to 32
characters.
Step 5 Choose the direction in which to apply the blocking ACL from the Direction drop-
down menu. You can choose In or Out.
Step 6 Enter the name of the Pre-Block ACL in the Pre-Block ACL field. This is an ACL to
apply before the blocking ACL. A valid value is zero to 64 characters. This is an
optional field.
Step 7 Enter the name of the Post-Block ACL in the Post-Block ACL field. This is an ACL
to apply after the blocking ACL. A valid value is zero to 64 characters. This is an
optional field.
Note The Post-Block ACL cannot be the same as the Pre-Block ACL.
Step 8 Click OK. You receive an error message if the IP address, interface, and direction
combination already exists. The new interface appears in the list on the Router
Blocking Device Interfaces panel.
Configuring Switch Blocking Device
Interfaces
Configuration
Blocking
Add
Cat 6K Blocking
Device Interfaces
You configure blocking on a Cisco Catalyst 6000 Series Switch running the Cisco Catalyst
operating system using VACLs. A blocking device interface is required to complete the
configuration of the blocking feature on the Cisco Catalyst Series 6000 Switch using VACLs.
Because Cisco Catalyst 6000 Series Switch VACLs do not support direction-based ACLs, the
blocking direction is not available for Cisco Catalyst 6000 Series Switch VACL devices.
Follow these steps to configure blocking device interfaces if your blocking device is a Cisco
Catalyst 6000 Series Switch:
Step 1 Click Configuration and choose Blocking > Cat 6K Blocking Device Interfaces.
Step 2 Click Add. The Add Cat 6K Blocking Device Interface window opens.

Configuring Switch Blocking Device
Interfaces (Cont.)
Cat 6K
Blocking
Device
VLAN ID
Pre-Block
VACL
Post-Block
VACL
Step 3 Choose the IP address of the Cisco Catalyst 6500 Series Switch from the Cat 6K
Blocking Device drop-down menu.
Step 4 Enter the VLAN ID (VID) of traffic you want blocked in the VLAN ID field.
Step 5 Enter the name of the Pre-Block VACL in the Pre-Block VACL field. This is an
optional field.
Step 6 Enter the name of the Post-Block VACL in the Post-Block VACL field. This is an
optional field.
Step 7 Click OK. You receive an error message if the IP address and VLAN combination
already exists. The new interface appears in the list on the Cat 6K Blocking Device
Interfaces panel.
Note You must create and save Pre-Block and Post-Block VACLs in your switch configuration.
These VACLs must be extended IP VACLs, either named or numbered. See your switch
documentation for more information on creating VACLs.
Cisco ASA Adaptive Security Appliance
Blocking Device Considerations
Cisco ASA 5500 Series Adaptive Security Appliance interfaces

and ACLs do not need to be configured when the ASA 5500
Series is defined as a blocking device.
Blocking is enforced using the ASA 5500 Series shun command.
The shun command is limited to blocking hosts.
The shun command does not support the blocking of specific host
connections or the manual blocking of entire networks or
subnetworks.
You do not need to configure the Cisco ASA 5500 Series Adaptive Security Appliance
interfaces and ACLs when the ASA 5500 Series is defined as a blocking device. Blocking is
enforced using the ASA 5500 Series shun command. The shun command is limited to blocking
hosts; it does not support the blocking of specific host connections or the manual blocking of
entire networks or subnetworks.
Note This behavior applies to the Cisco PIX 500 Series Security Appliances and the Cisco ASA
5500 Series Adaptive Security Appliances.

How to Configure Manual Blocking
This topic explains how to configure manual blocking.
Configuring Active Host Blocks

Monitoring
Active Host
Blocks Add
In addition to the automatic blocking initiated by the firing of a signature, the sensor can
perform blocking of a specific host or network. A host block can deny traffic from a specific
host until you remove the block or until a specified amount of time elapses. You can base the
block on a connection by indicating the destination IP address and the destination protocol and
port.
A host block is defined by its source IP address. If you add a block with the same source IP
address as an existing block, the new block overlays the old block. If you specify an amount of
time for the block, the value must be in the range of 1 to 70560 minutes, which is 49 days. If
you do not specify a time, the host block remains in effect until the sensor is rebooted or the
block is deleted.
Follow these steps to configure a host block:

Step 1 Click Monitoring and choose Active Host Blocks. The Active Host Blocks panel is
displayed.
Step 2 Click Add to add an active host block. The Add Active Host Block window opens.
Configuring Active Host Blocks (Cont.)
Source IP
Enable
Connection Destination
Blocking Port
Protocol
Destination IP
VLAN
Enable
Timeout
Timeout No Timeout
Step 3 Enter the source IP address of the host that you want blocked.
Step 4 Check the Enable Connection Blocking check box if you want the block to be
connection-based. A connection block will block traffic from a given source IP
address to a given destination IP address and destination port. If you choose Enable
Connection Blocking, complete the following substeps within the Connection
Blocking area:
1. Enter the destination IP address for the block in the Destination IP field.
2. Enter the destination port for the block in the Destination Port field. This field is
optional.
3. Choose the protocol for the block from the Protocol drop-down menu. This field
is optional. The default is ANY. You can choose one of the following:
TCP
UDP
ANY
Step 5 Enter a VID in the VLAN field. This field is optional.
Step 6 Choose the Enable Timeout or No Timeout radio button. Enable Timeout allows
you to configure the block for a specified number of minutes. If you choose Enable
Timeout, enter the number of minutes for the block to last in the Timeout field. A
valid value is between 1 and 70560 minutes (49 days).
Step 7 Click Apply. You receive an error message if a block is configured for that IP
address. The new active host block is displayed in the list on the Active Host Blocks
panel.

Note You can see the time remaining for the blocks in the Minutes Remaining column of the
Active Host Blocks panel.
Configuring Network Blocks
Monitoring
Network Add
Blocks
You can also configure the sensor to block specific networks. A network block denies traffic
from a specific network until the block is removed or a specified amount of time elapses. A
network block is defined by its source IP address and netmask. If you specify an amount of
time for the block, the value must be in the range of 1 to 70560 minutes, which is 49 days. If
you do not specify a time, the block remains in effect until the sensor is rebooted or the block is
deleted.
Follow these steps to configure a network block:
Step 1 Click Monitoring and choose Network Blocks. The Network Blocks panel is
displayed.
Step 2 Click Add to add a network block. The Add Network Block window opens.

Configuring Network Blocks (Cont.)
Source IP
Netmask
Enable
Timeout
Timeout
No
Timeout
Step 3 Enter the source IP address of the network that you want blocked in the Source IP
field.
Step 4 Choose the netmask that corresponds to the source IP address from the Netmask
drop-down menu.
Step 5 Choose the Enable Timeout or the No Timeout radio button. Enable Timeout
allows you to configure the block for a specified number of minutes. If you choose
Enable Timeout, enter the number of minutes that you want the block to last in the
Timeout field. A valid value is between 1 to 70560 minutes (49 days).
Step 6 Click Apply. You receive an error message if a block has already been added. The
new network block appears in the list on the Network Blocks panel.
Note You can see the time remaining for the blocks in the Minutes Remaining column of the
Network Blocks panel.
How to Configure a Master Blocking Scenario
This topic explains how to configure a master blocking sensor (MBS).
Master Blocking Sensors
Provider Provider
X Y
Attacker Sensor B
Sensor A Blocks
Router A
Blocks
Sensor A PIX B Sensor B:

MBS
... Protected Sensor A

commands
Network
Sensor B to
Target block.
In some configurations, it is necessary to have a proxy sensor perform the blocking action for
another sensor on your network. These proxy sensors are referred to as MBSs. The sensors that
send block requests to master blocking sensors are referred to as blocking forwarding sensors.
The figure illustrates how to use MBSs. The network has two entry points from two different
providers: Provider X and provider Y. The entry point for provider X has a sensor configured
for device management with router A. The entry point for provider Y has a sensor configured
for device management with the Cisco PIX security appliance B. When an attempt to penetrate
a host in the protected network is detected by sensor A, it blocks the attack at router A. If
sensor A has not been configured to use an MBS, the provider Y access would still be possible,
and the attacker could penetrate the protected network through that route.
Note An MBS can also operate as a master rate-limiting sensor.

MBS Characteristics
Characteristics of an MBS:
An MBS can be any sensor that controls blocking on a device on
behalf of another sensor.
A blocking forwarding sensor is a sensor that sends block
requests to an MBS.
Any Cisco IPS running Cisco IPS Sensor Software Version 6.0
can act as an MBS for any other Cisco IPS running Cisco IPS
A sensor can forward block requests to a maximum of 10 MBSs.
An MBS can handle block requests from multiple blocking
forwarding sensors.
An MBS can use other MBSs to control other devices.
An MBS is a sensor that controls blocking on one or more devices on behalf of one or more
other sensors, which are known as blocking forwarding sensors. In other words, the ARC on an
MBS controls blocking on devices at the request of the ARCs running on blocking forwarding
sensors.
Any Cisco IPS sensor running Cisco IPS Sensor Software Version 6.0 can act as an MBS for
another Cisco IPS sensor running Cisco IPS Sensor Software Version 6.0. With Cisco IDS
sensors running Cisco Intrusion Detection System (IDS) Software Version 3.1 or earlier, Post
Office Protocol (POP) is used to communicate blocking instructions. With Cisco IDS Sensor
Software Version 4.0 and Cisco IPS Sensor Software Version 5.0, the blocking forwarding
sensor uses Remote Data Exchange Protocol (RDEP) to communicate blocking instructions to
an MBS. Cisco IPS Sensor Software Version 6.0 uses Remote Data Exchange Protocol version
2 (RDEP2). The blocking forwarding sensor ARC can send two block messages to an MBS:
Initiate a block: Used for manual blocks or automatic blocks initiated in response to an
event.
Stop blocking: Used for manual blocks
Block timeout messages are not communicated because each sensor handles its own blocking
timeouts. Permanent blocks are also not communicated because these can be configured only
for devices that a sensor directly manages.
A blocking forwarding sensor can forward block requests to a maximum of 10 MBSs, and each
MBS can handle block requests from more than one blocking forwarding sensor. However,
multiple sensors cannot manage a single blocking device.
An MBS can also use other MBSs to control other devices. However, this type of blocking
configuration can become quite complex, and, because MBSs can chain block messages,
circular block messaging can occur.
Note When an MBS chains block messages, the block messages are applied one right after the
other. Circular block messaging occurs when chained block messages continue for an
extended period of time.

Configuring the Use of an MBS
On the blocking forwarding sensor:

– Specify the MBS.
– If TLS is enabled, add the MBS to the TLS
trusted host table.
On the MBS, add each blocking forwarding sensor to the allowed
hosts table.
To have a sensor initiate blocking on behalf of another sensor, you must configure both sensors.
On the blocking forwarding sensor, complete the following steps:
Identify the remote host that serves as the MBS.
Add the MBS to the blocking forwarding sensor Transport Layer Security (TLS) trusted
host table if TLS is enabled for encrypted communications.
On the MBS, add the blocking forwarding sensor IP address to the allowed host configuration.
Configuring the Blocking Forwarding
Sensor
Configuration
Add
Blocking
Master
Blocking
Sensor
Follow these steps in the Cisco IDM on a blocking forwarding sensor:
Step 1 Click Configuration and choose Blocking > Master Blocking Sensor. The Master
Blocking Sensor panel is displayed.
Step 2 Click Add to add an MBS. The Add Master Blocking Sensor window opens.

Configuring the Blocking Forwarding
Sensor (Cont.)
IP Address
Port
Username
New
Password
Confirm
New
Password
Step 3 Enter the IP address of the MBS in the IP Address field.
Step 4 Enter the port number in the Port field. The blocking forwarding sensor connects to
the MBS on this port. The default is 443. This field is optional.
Step 5 Enter the username used to log into the MBS in the Username field. A valid value is
1 to 16 characters.
Step 6 Enter the password for the user in the Password field.
Step 7 Confirm the password in the Confirm Password field.
Step 8 Check or uncheck the Use TLS check box. If you check the Use TLS check box,
complete the following substeps to configure the ARC of the blocking forwarding
sensor to accept the TLS or SSL X.509 certificate of the MBS remote host.
1. Log into the blocking forwarding sensor CLI using an account with
administrator privileges.
2. Enter global configuration mode:
sensor# configure terminal

3. Add the trusted host:
sensor(config)# tls trusted-host ip-address

MBS_ip_address
4. When prompted to confirm adding the trusted host, press Enter to answer yes.
Would you like to add this to the trusted certificate

table for this host?[yes]: <Enter>
5. Exit global configuration mode and the command-line interface (CLI):
sensor(config)# exit
sensor# exit
You are prompted to accept the certificate based on the certificate fingerprint.
Sensors provide only self-signed certificates instead of certificates signed by a
recognized certificate authority. You can verify the certificate of the MBS host
sensor by logging into the host sensor and entering the show tls fingerprint
command to see that the fingerprints of the host certificate match.
Step 9 Click OK. You receive an error message if the IP address has already been added.
The new MBS appears in the list on the Master Blocking Sensor panel.
Note You can also configure the blocking forwarding sensor to accept the X.509 certificate by
using the Add Trusted Host window, which is displayed when you choose Configuration >
Certificates > Trusted Hosts.
Note You can check the status of the ARC by using the CLI show statistics network-access
command. The output shows the devices that you are managing, any active blocks, and the
status for all of the devices. You can also check the status in the Cisco IDM by choosing
Monitoring > Statistics.

Configuring the MBS
IP
Address
Network
Mask
To complete your master blocking configuration, go to the MBS and use the Add Allowed Host
window to add the IP address of the blocking forwarding sensor to the allowed hosts list. To
access the Add Allowed Host window, click Configuration and choose Sensor Setup >
Allowed Hosts, and then click Add. Enter the IP address of the blocking forwarding sensor in
the IP Address field and select its corresponding network mask from the Network Mask drop-
down menu.
Summary
Summary
Blocking means that a sensor can dynamically reconfigure a Cisco device to

block the source of an attack in real time. The guidelines for designing a
Cisco IPS solution with blocking are:
– Implement an antispoofing mechanism.
– Identify critical hosts and network entry points.
– Select applicable signatures.
– Determine the blocking duration.
You can apply ACLs on the external or the internal interface of the Cisco IOS
device and may be configured for inbound or outbound traffic on either
interface.
To configure automatic blocking, you must select a signature and set uts alert
response, configure device login profiles, and configure blocking devices.
You can configure an MBS to block on behalf of another sensor.
You can manually configure the sensor to perform blocking of a specific host
or network.

Module Summary
This topic summarizes the key points that were discussed in this module.
Module Summary
To maximize your Cisco IPS sensor efficiency, you can configure

signature parameters, IP logging, reassembly options, and alarm
channel event filters according to the needs of your particular
network. The risk rating formula calculates a risk rating value that
you can use to help focus on the events that require immediate
administrator attention, or develop risk-oriented event action
policies.
Cisco IEV, the Cisco Security Management Suite, Cisco Security
MARS, and Cisco ICS are all additional tools that can help
monitor and enhance Cisco IPS sensor products.
For a virtual sensor, the packet processing policy is virtualized.
The Cisco IPS 4240, IPS 4255, and IPS 4260 sensors fully
support virtualization and can have a maximum of four virtual
sensors.
Module Summary (Cont.)
Anomaly detection and POSFP are features that allow the Cisco
IPS Sensor products to provide significant worm protection and
alarm relevance.
– Anomaly detection allows the sensor to learn what is normal
behavior to your network, and take dynamic actions in
response to behavior that deviates from what is considered
normal.
– POSFP helps the Cisco IPS Sensor determine the operating
system for a host. This information is then used to help
calculate a more appropriate risk rating.
Blocking can be initiated either automatically or manually. You
can configure a manual block to block by host or by network.
While the Cisco Intrusion Prevention System (IPS) sensor products work well out of the box,
there are several ways that you can tune the sensors to work more optimally for their network.
Configuring event variables, target value ratings (TVRs), event action overrides, and event
action filters are all ways you can improve the likelihood of events being correct, and lower the
chance of events reflecting anything other than a true event.
There are also many tools that you can use to more efficiently monitor and enhance the
performance of the Cisco IPS sensor products. These include, but are not limited to, the Cisco
IPS Event Viewer (IEV), the Cisco Security Management Suite, Cisco Security Monitoring,
Analysis, and Response System (MARS), and Cisco Incident Control System (ICS). Cisco IEV
is a no-cost option that allows you to customize the events to monitor for up to five Cisco IPS
sensor products.
Virtual sensor is an added feature to the Cisco IPS Sensor Software Version 6.0, which allows
you to apply different configurations to different traffic. Virtual sensors also make it possible
for you to monitor traffic from networks that have overlapping address spaces, while using one
physical sensor. Anomaly detection and passive operating system fingerprinting (POSFP) are
additional tools available to help better and more efficiently protect your network from attacks.
Blocking is a Cisco IPS feature that prevents packets from reaching their destination. Blocking
is initiated by a sensor and performed by another Cisco device at the request of the sensor. You
can configure blocking to occur automatically or you can manually configure specific hosts or
networks to block.

References
For additional information, refer to these resources:
Cisco Systems, Inc. Tools & Resources: Software Download. http://www.cisco.com/cgi-
bin/tablebuild.pl/ips-ev.
Cisco Systems, Inc. Training Resources: Training from Cisco Learning Partners.
http://www.cisco.com/web/learning/le31/le29/learning_training_from_cisco_learning_part
ners.html.
The Internet Corporation for Assigned Names and Numbers. Internet Protocol V4 Address
Space. http://www.iana.org/assignments/ipv4-address-space.
Module 5
Additional Cisco IPS Devices
Overview
This module introduces additional devices in the Cisco Intrusion Prevention System (IPS)
family of products besides the Cisco IPS 4200 Series Sensors. This module will provide an
overview of the differences of these products and how to perform an initial configuration.
Module Objectives
Upon completing this module, you will be able to initialize and install into your environment
the rest of the Cisco IPS family of products. This ability includes being able to meet these
objectives:
Explain the basics of how to install the Cisco Catalyst 6500 Series IDSM-2 into a Cisco
Catalyst 6500 Series Switch and initialize the module
Initialize a Cisco ASA AIP-SSM
Lesson 1
Installing the Cisco Catalyst

6500 Series IDSM-2
Overview
This lesson covers information on the Cisco Catalyst 6500 Series Intrusion Detection System
Services Module 2 (IDSM-2) and how to prepare it to provide intrusion prevention.
Objectives
Upon completing this lesson, you will be able to explain the basics of how to install the Cisco
Catalyst 6500 Series IDSM-2 in a Cisco Catalyst 6500 Series Switch and initialize it. This
ability includes being able to meet these objectives:
Describe the Cisco Catalyst 6500 Series IDSM-2
Install the Cisco Catalyst 6500 Series IDSM-2
Configure the Cisco Catalyst 6500 Series IDSM-2 interfaces
Monitor the Cisco Catalyst 6500 Series IDSM-2
Perform Cisco Catalyst 6500 Series IDSM-2 maintenance
Cisco Catalyst 6500 Series IDSM-2 Overview
This topic introduces the Cisco Catalyst 6500 Series IDSM-2.
Cisco Catalyst 6500 Series IDSM-2
IDSM-2
Performance 500 Mbps
Size 1 RU
Processor Dual 1.13 GHz
Operating system Linux
The technical specifications for the Cisco Catalyst 6500 Series IDSM-2 are as follows:
Performance: 500 Mbps with 450-byte (B) packets
Size: 1 rack unit (RU)
Processor: Dual 1.13 GHz
Operating system: GNU Linux kernel version 2.4.26
Note Performance up to 600 Mbps is possible when the Cisco Catalyst 6500 Series IDSM-2 is
running in promiscuous mode (intrusion detection system [IDS]). Performance for a Cisco
Catalyst 6500 Series IDSM-2 running Cisco Intrusion Prevention System (IPS) Sensor
Software Version 6.0 is rated at 500 Mbps with 450-B packets at 5000 new TCP
connections per second with 50,000 concurrent connections.
The following are the inline performance statistics:

500 Mbps
5,000 new TCP connections per second
5,000 HTTP transactions per second
50,000 concurrent connections
Supports up to 500,000 concurrent connections
Differences between Cisco Catalyst 6500 Series
IDSM-2 and Cisco IPS 4200 Series Sensors
The Cisco Catalyst 6500 Series IDSM-2 has these

differences:
It does not support sensor virtualization with inline VLAN groups.
It does not support subdividing inline interfaces or VLAN groups.
It automatically synchronizes its clock with the switch.
There is no clock set command.
There are only two sensing interfaces.
It must be configured with a native VLAN.
There is no console access.
Several Cisco Catalyst 6500 Series IDSM-2 related commands
are executed on the switch.
It has a maintenance partition.
Although the Cisco Catalyst 6500 Series IDSM-2 runs the same image as the Cisco IPS 4200
Series Sensors, there are some differences that can largely be traced to the fact that the Cisco
Catalyst 6500 Series IDSM-2 is a module in a switch. These are the major differences for the
Cisco Catalyst 6500 Series IDSM-2:
It does not support sensor virtualization using inline VLAN groups.
It does not support subdividing inline interfaces or VLAN groups.
It automatically synchronizes its clock with the switch.
It does not have a clock set command.
It has only two sensing interfaces.
It must be configured with a native VLAN.
It does not have console access.
Several of the Cisco Catalyst 6500 Series IDSM-2 related commands are executed on the
Cisco Catalyst 6500 Series Switch.
It has a maintenance partition.
© 2007 Cisco Systems, Inc. Additional Cisco IPS Devices 5-5

Cisco Catalyst 6500 Series IDSM-2
Key Features
Brings switching and security into a single chassis

Supports inline and promiscuous-mode operations
Provides an effective platform across all Catalyst 6500 Series
Switch chassis
Uses the same code as the Cisco IPS 4200 Series Sensors
The following are key features of the Cisco Catalyst 6500 Series IDSM-2:
It brings switching and security into a single chassis.
It supports inline and promiscuous-mode operations.
It is supported by all Cisco Catalyst 6500 Series Switches.
It uses the same code as the Cisco IPS 4200 Series Sensors. This enables you to employ a
single management technique and makes installation, training, operation, and support
simpler and faster.
It takes only a single slot in the switch chassis. You can install up to eight Cisco Catalyst
6500 Series IDSM-2 in a single switch chassis.
It supports most TCP, IP, and Address Resolution Protocol (ARP) protocols, including
Multiprotocol Label Switching (MPLS).
Differences Between Promiscuous and
Inline Mode
The following Cisco Catalyst 6500 Series IDSM-2

features vary, depending on your selection of inline or
promiscuous mode:
How the Cisco Catalyst 6500 Series IDSM-2 obtains the
traffic it inspects
Number of VLANS supported
Potential effects on the network
Supported Cisco Catalyst switches
Supported software
Supported signature actions
The table shows how the features of the Cisco Catalyst 6500 Series IDSM-2 vary depending on
your selection of inline or promiscuous mode.
Cisco Catalyst 6500 Series IDSM-2 Features
Feature Promiscuous Mode Inline Mode
Traffic visibility Has access to the data stream via VLAN Resides in the data forwarding path
access control list (VACL) capture,
Switch Port Analyzer (SPAN), or Remote
SPAN (RSPAN)
Maximum Unlimited One VLAN pair

number of
VLANs (IEEE
802.1Q tagging)
Failover Has no disruptive effect on the Uses a software bypass capability

protection Cisco Catalyst switch in the event of that prevents the Cisco Catalyst
failure 6500 Series IDSM-2 from
becoming a failure point
Never exposes the network to
performance degradation or Can monitor Cisco Catalyst 6500
downtime (This is because the Series IDSM-2 health via Simple
Cisco Catalyst 6500 Series IDSM-2 Network Management Protocol
is not in the switch forwarding path.) (SNMP)
Cisco Catalyst Yes Yes

6500 Series
support
Cisco Catalyst Yes, with Cisco IOS Release No

7600 support 12.2(18)SFX4 only
Cisco Catalyst Yes, Cisco Catalyst OS Release 8.5(1) Yes

operating or higher
system software
support

Feature Promiscuous Mode Inline Mode
Catalyst IOS Yes, with Cisco IOS Release No

software support 12.2(18)SFX4 or later
Supported Log attacker packets Deny attacker inline

signature
Log pair packets Deny connection inline
actions
Log victim packets Deny packet inline
Produce alert Log attacker packets
Produce verbose alert Log pair packets
Request block connection Log victim packets
Request block host Produce alert
Request SNMP trap Produce verbose alert
Reset TCP connection Request block connection
Request block host
Request SNMP trap
Reset TCP connection
Cisco Catalyst 6500 Series IDSM-2 Ports
The Cisco Catalyst 6500 Series IDSM-2 has the following

logical ports:
– Port 1: TCP resets (for promiscuous mode only)
– Port 2: Command and control
– Ports 7 and 8: Sensing
Ports 7 and 8 can be configured as a pair to support inline IPS.
The Cisco Catalyst 6500 Series IDSM-2 has four logical ports, which can be used as follows:
Port 1 (System0/1 in Cisco IPS Sensor Software Version 6.0): This is the TCP reset port
for promiscuous-mode IDS. This port is not used for inline IPS.
Port 2 (Gigabit Ethernet 0/2 in Cisco IPS Sensor Software Version 6.0): This is the
command and control port.
Ports 7 and 8 (Gigabit Ethernet 0/7 and Gigabit Ethernet 0/8 in Cisco IPS Sensor
Software Version 6.0): These are the monitoring ports. One of these ports can be a SPAN
destination or VACL capture port for promiscuous-mode IDS. Otherwise, ports 7 and 8 can
be configured as a port pair to support inline IPS.
For promiscuous-mode sensing, packets are directed to the monitoring ports of the Cisco
Catalyst 6500 Series IDSM-2 by using the VACL capture, SPAN, or RSPAN method of traffic
capture. SPAN provides a means of sending a copy of the traffic within the switch from a
spanned source port to a port designated as the SPAN port. The port being spanned is usually
an Ethernet port in the chassis with interesting traffic that the Cisco Catalyst 6500 Series
IDSM-2 can monitor. A copy of transmit (Tx), receive (Rx), or both Tx and Rx traffic can be
sent from the spanned port to an Cisco Catalyst 6500 Series IDSM-2 monitor port.
With SPAN enabled on a source port or VLAN, a copy of all Rx traffic, all Tx traffic, or all Rx
and Tx traffic from the SPAN source port or VLAN is sent to the SPAN destination port. On
the Catalyst 6500 Series Switch, there is a limit to the number of SPAN ports that you can
configure. For Rx SPAN sessions, you can have a maximum of two per chassis. For Tx SPAN
sessions, you can have a maximum of four sessions per chassis. For SPAN sessions that copy
and send both Rx and Tx traffic from a port, you can configure a maximum of two SPAN
sessions per chassis.
When using SPAN, remember the following rules:

The total amount of spanned traffic cannot exceed the maximum throughput of the Cisco
Catalyst 6500 Series IDSM-2, 600 Mbps.

The limitation on the number of SPAN sessions limits the number of ports in the chassis
that can have their traffic monitored by the Cisco Catalyst 6500 Series IDSM-2.
A VACL capture is a way to leverage the hardware resources of the Policy Feature Card (PFC),
which resides on the supervisor engine of the switch. With VACL capture, traffic matching
access control lists (ACLs) programmed into the PFC hardware is copied and sent to a
configured capture port. The monitor port of the Cisco Catalyst 6500 Series IDSM-2 can be
configured as the VACL capture port. Although configuring SPAN is easier, the VACL method
of sending traffic to the Cisco Catalyst 6500 Series IDSM-2 may be preferable because it
allows a subset of traffic to be copied and sent to the Cisco Catalyst 6500 Series IDSM-2. This
limits the amount of traffic that must be processed and potentially allows more traffic in the
chassis to be analyzed. Other traffic flows as usual and does not add to the load of traffic that
the Cisco Catalyst 6500 Series IDSM-2 has to process.
Traffic Flow: Promiscuous
Cisco Catalyst 6500 Series Switch Destination

Source Traffic Traffic
Destination Source Traffic

Traffic Copied VACL or SPAN
Switch traffic or RSPAN traffic to
Backplane Catalyst 6500 Series
IDSM-2 monitor ports
Catalyst 6500 Series IDSM-2

Alarms and configuration
through Catalyst 6500 Series
IDSM-2 command and control
port
Management
Console
For promiscuous-mode operations, the Cisco Catalyst 6500 Series Switch must be configured
to capture traffic for intrusion detection analysis. If this configuration is not done, the Cisco
Catalyst 6500 Series IDSM-2 will never be able to see into the network traffic.
The figure illustrates how the Cisco Catalyst 6500 Series IDSM-2 captures and analyzes
network traffic. Traffic enters the Cisco Catalyst 6500 Series Switch destined for a host or
network. The traffic is captured off the switch backplane and sent to the Cisco Catalyst 6500
Series IDSM-2. The Cisco Catalyst 6500 Series IDSM-2 performs intrusion detection analysis
and performs the defined actions.

Traffic Flow: Inline
Cisco Catalyst 6500 Series Switch Destination

Source Traffic Traffic
Destination
Traffic Source Traffic
VLAN traffic flows through
Catalyst 6500 Series
IDSM-2
Catalyst 6500 Series IDSM-2

Alarms and configuration
through Catalyst 6500 Series
IDSM-2 command and control
port
Management
Console
For inline IPS, it is not necessary to configure traffic capture. When the Cisco Catalyst 6500
Series IDSM-2 and its host switch are properly configured, traffic flows through the Cisco
Catalyst 6500 Series IDSM-2 for inspection as it traverses the host switch.
Time and Cisco Catalyst 6500
Series IDSM-2
You can use one of the following methods to ensure

accurate time on the Cisco Catalyst 6500 Series IDSM-2:
You can allow the Cisco Catalyst 6500 Series IDSM-2 to
automatically synchronize its clock with the time on the switch.
Only the UTC is synchronized with the switch. It is still necessary
to configure the Cisco Catalyst 6500 Series IDSM-2 with time
zone and summertime parameters.
You can configure the Cisco Catalyst 6500 Series IDSM-2 to get
its time from an NTP time synchronization source.
The Cisco Catalyst 6500 Series IDSM-2 requires a reliable time source. All of the alerts must
have the correct Greenwich mean time (GMT) and local time stamp. Otherwise, you cannot
correctly analyze the logs after an attack.
To ensure a reliable time source, the Cisco Catalyst 6500 Series IDSM-2 must obtain its time
from one of the following:
Its host switch: By default, the Cisco Catalyst 6500 Series IDSM-2 automatically
synchronizes its clock with the GMT time on the switch. The time zone and summertime
settings, however, are not synchronized between the switch and the Cisco Catalyst 6500
Series IDSM-2. Be sure to set the time zone and summertime settings on both the switch
and the Cisco Catalyst 6500 Series IDSM-2 to ensure that the GMT time settings are
correct. The Cisco Catalyst 6500 Series IDSM-2 local time will be incorrect if its time zone
or summertime settings do not match those of the switch.
A Network Time Protocol (NTP) server: This is the recommended method. You can
configure the Cisco Catalyst 6500 Series IDSM-2 to use NTP during initialization, or you
can set up NTP on the Cisco IPS Device Manager (IDM) time panel.

Installing the Cisco Catalyst 6500 Series IDSM-2
This topic describes how to install the Cisco Catalyst 6500 Series IDSM-2.
Installation Tasks
Task 1: Install the Cisco Catalyst 6500 Series IDSM-2 in the switch.
Task 2: Initialize the Cisco Catalyst 6500 Series IDSM-2.
Task 3: Configure the switch for command and control access.
Task 4: Configure the interfaces.
Task 5: Configure the Cisco Catalyst 6500 Series IDSM-2 for inline
operation.
Task 6: Configure multiple virtual sensors and assign inline VLAN
pairs to them. (optional)
To enable the Cisco Catalyst 6500 Series IDSM-2 to protect your network, complete the
following tasks:
Task 1 Install the Cisco Catalyst 6500 Series IDSM-2 in the Cisco Catalyst switch. This
step involves the physical installation into the chosen slot.
Task 2 Initialize the Cisco Catalyst 6500 Series IDSM-2 by running the setup command.
Task 3 Configure the switch for command and control access.
Task 4 Configure the interfaces to receive traffic.
Task 5 Configure the Cisco Catalyst 6500 Series IDSM-2 for inline operation by creating an
inline pair.
Task 1: Installing the Cisco Catalyst 6500
Series IDSM-2
Step 1: Choose a slot for the module.

Step 2: Insert the Cisco Catalyst 6500 Series IDSM-2 into the slot
until the notches on both ejector levers engage the chassis
sides.
Step 3: Fully seat the module in the backplane connector.
Step 4: Tighten the installation screws.
Follow these steps to install the Cisco Catalyst 6500 Series IDSM-2 in the Cisco Catalyst
switch:
Step 1 Read the Regulatory Compliance and Safety Information for the Intrusion Detection
System Appliances and Modules manual that comes with the Cisco Catalyst 6500
Series IDSM-2 before installing the Cisco Catalyst 6500 Series IDSM-2 and ensure
that you take the necessary safety precautions.
Step 2 Choose a slot for the module. The Supervisor Engine must be installed in slot 1, and
a redundant Supervisor Engine can be installed in slot 2. If you do not install a
redundant Supervisor Engine, you can install the Cisco Catalyst 6500 Series IDSM-
2 in any slot except slot 1.
Step 3 Loosen the installation screws that secure the filler plate to the desired slot. Use a
screwdriver if necessary.
Step 4 Remove the filler plate by pulling the ejector levers on both sides and sliding it out.
Step 5 Hold the module with one hand, and place your other hand under the module carrier
to support it.
Caution Do not touch the printed circuit boards or connector pins on the module.
Step 6 Place the module in the slot by aligning the notch on the sides of the module carrier
with the groove in the slot.
Step 7 Keeping the module at a 90-degree orientation to the backplane, carefully slide it
into the slot until the notches on both ejector levers engage the chassis sides.
Step 8 Using the thumb and forefinger of each hand, simultaneously pivot in both ejector
levers to fully seat the module in the backplane connector.

Caution Always use the ejector levers when installing or removing the module. A module that is
partially seated in the backplane will cause the system to halt and subsequently crash.
Step 9 Use a screwdriver to tighten the installation screws on the left and right sides of the
module.
All of the Cisco Catalyst 6500 Series Switches support hot swapping, which enables you to
install, remove, replace, and rearrange modules without turning off the system power. When the
system detects that a module has been installed or removed, it runs diagnostic and discovery
routines, acknowledges the presence or absence of the module, and resumes system operation
with no operator intervention.
If you perform a hot swap, the console displays a message informing you that a module has
been inserted. If you are connected to the Cisco Catalyst 6500 Series Switch through a Telnet
session, this message does not appear.
Note For detailed installation procedures, see the Cisco Intrusion Detection System Appliance
and Module Installation and Configuration Guide at
http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_installation_and_config
uration_guide_book09186a008014a234.html.
Task 2: Initializing the Cisco Catalyst
6500 Series IDSM-2
Step 1: Access the Cisco Catalyst 6500 Series IDSM-2 using the
switch session command.
Step 2: Log in at the Cisco Catalyst 6500 Series IDSM-2 login
prompt with the username cisco and the default password
cisco.
Step 3: Execute the setup command to enter the configuration
dialog.
Step 4: Enter the network communication parameters.
Step 5: Reset the Cisco Catalyst 6500 Series IDSM-2.
Because the Cisco Catalyst 6500 Series IDSM-2 runs the same code as the Cisco IPS 4200
Series Sensors, the initialization of the Cisco Catalyst 6500 Series IDSM-2 is essentially the
same as that of the Cisco IPS 4200 Series Sensor. The main difference is the method of
accessing the Cisco Catalyst 6500 Series IDSM-2 command-line interface (CLI) for
initialization. Follow these steps to initialize the Cisco Catalyst 6500 Series IDSM-2:
Step 1 Use the session command to initiate a session with the Cisco Catalyst 6500 Series
IDSM-2 from the switch CLI. The following example would enable access to the
Cisco Catalyst 6500 Series IDSM-2 installed in slot 3 of the Cisco Catalyst 6500
Series Switch:
cat6k>(enable) session 3
Step 2 Log into the Cisco Catalyst 6500 Series IDSM-2 using the default username cisco
and the password cisco.
Step 3 Follow the prompts to change the default password.
Note Passwords must be at least eight characters long and must not be words found in the
dictionary.
Step 4 Run the setup command and respond to its interactive prompts to complete the
initial configuration.
Step 5 Reset the Cisco Catalyst 6500 Series IDSM-2 to enable and apply the configuration
changes.
Note The examples in this lesson use the Catalyst software command syntax. For Cisco IOS
command syntax, refer to Cisco Intrusion Prevention System Command Reference 6.0 at
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_command_reference_b
ook09186a00807a874d.html.

Configuring Cisco Catalyst 6500 Series IDSM-2
Interfaces
This topic explains how to configure the Cisco Catalyst 6500 Series IDSM-2 for inline and
promiscuous-mode operations.
Task 3: Configuring the Switch for

Command and Control Access
Step 1: Log into the switch.

Step 2: Enter privileged mode.
Step 3: Assign the command and control port to the correct VLAN.
After initializing the Cisco Catalyst 6500 Series IDSM-2, you must configure the switch for
command and control access to the Cisco Catalyst 6500 Series IDSM-2. To configure the Cisco
Catalyst 6500 Series Switch to have command and control access to the Cisco Catalyst 6500
Series IDSM-2, complete the following steps:
Step 1 Log into the switch.
Step 2 Enter privileged mode:

cat6k> enable
Step 3 Assign the command and control port to the correct VLAN. The command and
control port, whose port number is always 2, should be in the same VLAN as its
default gateway. The following example assigns the command and control port of a
Cisco Catalyst 6500 Series IDSM-2 installed in slot 3 to VLAN 147:
cat6k> (enable) set vlan 147 3/2
Step 4 Complete the following substeps to verify that you have connectivity:
1. Initiate a session with the Cisco Catalyst 6500 Series IDSM-2:
cat6k> (enable) session 3

Trying IDS-3...
Connected to IDS-3.
Escape character is '^]'.
login: cisco
Password:
Last login: Thu Mar 3 09:40:53 from 127.0.0.11
***NOTICE***
This product contains cryptographic features and is
subject to United States and local country laws
governing import, export, transfer and use. Delivery
of Cisco cryptographic products does not imply third-
party authority to import, export, distribute or use
encryption. Importers, exporters, distributors and
users are responsible for compliance with U.S. and
local country laws. By using this product you agree to
comply with applicable laws and regulations. If you
are unable to comply with U.S. and local laws, return
this product immediately.
A summary of U.S. laws governing Cisco cryptographic
products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by
sending email to export@cisco.com.
***LICENSE NOTICE***
There is no license key installed on the system.
Please go to http://www.cisco.com/go/license to obtain
a new license or install a license.
idsm-2#
2. Ping a network IP address:
idsm-2# ping 10.89.149.126

PING 10.89.149.126 (10.89.149.126): 56 data bytes
64 bytes from 10.89.149.126: icmp_seq=0 ttl=255
time=0.3 ms
time=0.3 ms
time=0.3 ms
time=0.3 ms
--- 10.89.149.126 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet
loss
round-trip min/avg/max = 0.3/0.3/0.3 ms

Task 4: Configuring the Interfaces
Step 1: Log into the switch.

Step 2: Enter privileged mode.
Step 3: Set the native VLAN for the Cisco Catalyst 6500 Series
IDSM-2 sensing ports, 7 and 8.
Step 4: Clear all VLANs from each Cisco Catalyst 6500 Series
IDSM-2 sensing port except the native VLAN.
Step 5: Enable BPDU spanning-tree filtering on the Cisco Catalyst
6500 Series IDSM-2 sensing ports.
For Cisco Catalyst 6500 Series IDSM-2 inline operations, you will next configure the Cisco
Catalyst 6500 Series IDSM-2 sensing ports as trunk ports in the Cisco Catalyst operating
system software. Because the native VLAN is the same as the sole VLAN being trunked, the
traffic is 802.1Q encapsulated.
Caution The default configuration for Cisco Catalyst 6500 Series IDSM-2 ports 7 and 8 is to trunk all
of the VLANs, 1 to 4094. If you clear the Cisco Catalyst 6500 Series IDSM-2 configuration
using the clear configuration module_number command, the Cisco Catalyst 6500 Series
IDSM-2 will trunk all VLANs. If the Cisco Catalyst 6500 Series IDSM-2 is configured for inline
functionality, spanning-tree loops will likely be created and a storm will occur.
Follow these steps to configure the sensing ports on the Cisco Catalyst 6500 Series IDSM-2 for
inline operations:
Step 1 Log into the switch.
Step 2 Enter privileged mode:

cat6k> enable
Step 3 Set the native VLAN for the Cisco Catalyst 6500 Series IDSM-2 sensing ports,
which are ports 7 and 8:
cat6k (enable)> set vlan 651 3/7
cat6k (enable)> set vlan 652 3/8
Note For this example, the Cisco Catalyst 6500 Series IDSM-2 is installed in slot 3.
Step 4 Clear all of the VLANs from each Cisco Catalyst 6500 Series IDSM-2 sensing port,
except for the native VLAN on each port:
cat6k (enable)>clear trunk 3/7 1-650,652-4094
cat6k (enable)>clear trunk 3/8 1-651,653-4094
Step 5 Enable bridge protocol data unit (BPDU) spanning-tree filtering on the Cisco
Catalyst 6500 Series IDSM-2 sensing ports to prevent spanning-tree loops:
cat6k (enable)> set spantree bpdu-filter 3/7-8 enable

Task 5: Configuring the Cisco Catalyst
6500 Series IDSM-2 for Inline Operation
Step 1: Configure ports 7 and 8 as a port pair.

Step 2: Assign the port pair to the default virtual sensor.
If you want to run the Cisco Catalyst 6500 Series IDSM-2 in inline mode, you are now ready to
configure the Cisco Catalyst 6500 Series IDSM-2 for inline operation. You can use the Cisco
IDM or the CLI to configure the Cisco Catalyst 6500 Series IDSM-2 sensing ports, ports 7 and
8, as an inline pair and assign the inline pair to the default virtual sensor.
To configure the Cisco Catalyst 6500 Series Switches and the Cisco Catalyst 6500 Series
IDSM-2 using promiscuous-mode operations, refer to
https://tools.cisco.com/qtc/config/html/configureHomeGuest.html.
Note For more information on configuring the Cisco Catalyst 6500 Series Switch running the
Cisco Catalyst operating system, see the Catalyst 6500 Series Command Reference, 8.4 at
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/cmd_ref/index.htm.
Task 6: Configuring the Cisco Catalyst
6500 Series IDSM-2 for Virtualization
Step 1: Configure ports 7 and 8 as inline VLAN pairs.

Step 2: Configure an additional virtual sensor.
Step 3: Assign the VLAN pair to the default virtual sensor.
To configure multiple virtual sensors for your Cisco Catalyst 6500 Series IDSM-2 you must
create inline VLAN pairs using ports 7 and 8. Next, create a new virtual sensor with the
associated anomaly detection, signature, and event action rule policies. Lastly, you must assign
at least one inline VLAN pair to the virtual sensor.
For more information, refer to the “Configuring a Virtual Sensor” lesson in the “Advanced
Cisco IPS Configuration” module.

Monitoring the Cisco Catalyst 6500 Series
IDSM-2
This topic explains how to verify the status of the Cisco Catalyst 6500 Series IDSM-2.
show module Command

switch>
show module [mod]
This command displays module status and information.
cat6k>show module
Mod Slot Ports Module-Type Model Sub Status
—- —— ——- ————————————- —————
1 1 2 1000BaseX Supervisor WS-X6K-SUP2-2GE yes ok
15 1 1 Multilayer Switch Feature WS-F6K-MSFC2 no ok
2 2 8 1000BaseX Ethernet WS-X6408-GBIC no ok
3 3 48 10/100BaseTX Ethernet WS-X6548-RJ-45 no ok
4 4 8 Intrusion Detection Syste WS-SVC-IDSM-2 yes ok
5 5 0 Switch Fabric Module 2 WS-X6500-SFM2 no ok
This command displays the status of all modules in the switch. Three
Cisco Catalyst 6500 Series IDSM-2 modules are installed, one in slot
4, one in slot 6, and one in slot 7. The ok state indicates that the
Cisco Catalyst 6500 Series IDSM-2 modules are online.
Use the show module [mod | all] command to display the module status and information,
where mod is the number of the module of which you would like to see the status, and the all
option displays information for all of the modules.
The figure shows the output of the show module command. It is normal for the status to
display “other” when the Cisco Catalyst 6500 Series IDSM-2 is first installed. After the Cisco
Catalyst 6500 Series IDSM-2 completes the diagnostics routines and comes online, the status
displays “ok.” Allow up to 5 minutes for the Cisco Catalyst 6500 Series IDSM-2 to come
online.
Maintaining the Cisco Catalyst 6500
Series IDSM-2
This topic explains how to upgrade and recover the Cisco Catalyst 6500 Series IDSM-2 image.
Upgrading the Cisco Catalyst 6500

Series IDSM-2
You can use the upgrade command to apply image upgrades,

service packs, and signature updates to your Cisco Catalyst 6500
Series IDSM-2 .
You can use the upgrade command to upgrade from Cisco IPS
Sensor Software Version 5.x to 6.0.
To upgrade from Cisco IPS Sensor Software Version 5.x to 6.0,
the Cisco Catalyst 6500 Series IDSM-2 must already be running
Cisco IPS Sensor Software Version 5.1 or higher.
When you use the upgrade command to apply the Cisco IPS
Sensor Software Version 6.0 major upgrade, your configuration,
including the signature settings, is retained.
You can use the upgrade command to apply image upgrades, service packs, and signature
updates to the Cisco Catalyst 6500 Series IDSM-2. You can use the upgrade command to
upgrade your Cisco Catalyst 6500 Series IDSM-2 from Cisco IPS Sensor Software Version 5.x
to 6.0; however, the Cisco Catalyst 6500 Series IDSM-2 must be running Cisco IPS Sensor
Software Version 5.1 or higher prior to the upgrade. Using the upgrade command to apply the
Cisco IPS Sensor Software Version 6.0 major upgrade file retains your configuration, including
signature settings.

Recovering the Application Image
Maintenance Partition
WS-SVC-IDSM2-K9-sys-1.1-a-6.0-1-E1.bin.gz
Application Partition
The Cisco Catalyst 6500 Series IDSM-2 has two partitions, an application partition and a
maintenance partition. You can launch a full system reimage of the Cisco Catalyst 6500 Series
IDSM-2 from the maintenance partition by applying the Cisco Catalyst 6500 Series IDSM-2
system image. An installation script embedded in the Cisco Catalyst 6500 Series IDSM-2
system image performs the system reimage operation. This script is only executed when
launched from the maintenance partition.
Follow these steps to reimage the Cisco Catalyst 6500 Series IDSM-2 application partition:
Step 1 Obtain the application partition file from Cisco.com and copy it to an FTP server.
Step 2 Log into the switch CLI.
Step 3 Boot the Cisco Catalyst 6500 Series IDSM-2 to the maintenance partition. In the
example, the Cisco Catalyst 6500 Series IDSM-2 is installed in slot 3:
cat6k> (enable) reset 3 cf:1
Step 4 Log into the maintenance partition CLI:
login: guest
Password: cisco
Step 5 Enter global configuration mode and use the upgrade command to reimage the
application partition. When the application partition file has been installed, you are
returned to the maintenance partition CLI.
Step 6 Exit the maintenance partition CLI and return to the switch CLI.
Step 7 Reboot Cisco Catalyst 6500 Series IDSM-2 to the application partition:
cat6k> (enable) reset 3 hdd:1
Step 8 When the Cisco Catalyst 6500 Series IDSM-2 has rebooted, check the software
version:
sensor#show configuration
After you reimage the application partition of the Cisco Catalyst 6500 Series IDSM-2, you
must initialize the Cisco Catalyst 6500 Series IDSM-2 using the setup command.

Reimaging the Maintenance Partition
Maintenance
Partition
Application
Partition
c6svc-mp.2-1-2.bin.gz
When there is a new maintenance partition image file, you can reimage the Cisco Catalyst 6500
Series IDSM-2 maintenance partition from the application partition. Follow these steps to
reimage the maintenance partition:
Step 1 Obtain the maintenance partition file from Cisco.com and copy it to a Secure Copy
Protocol (SCP) or FTP server.
Step 2 Log into the switch CLI.
Step 3 Initiate a session with the Cisco Catalyst 6500 Series IDSM-2 application partition
CLI. In the following example, the Cisco Catalyst 6500 Series IDSM-2 is installed
in slot 3 of the Cisco Catalyst 6500 Series Switch:
cat6k> (enable) session 3
Note Enter global configuration mode and use the upgrade command to reimage the
maintenance partition.
Summary
Summary
The Cisco Catalyst 6500 Series IDSM-2 is a line card for the Cisco
Catalyst 6500 Series Switches that runs the same code as the
Cisco IPS 4200 Series Sensors and supports both inline and
promiscuous-mode operations.
Sensor initialization tasks specific to the Cisco Catalyst 6500 Series
IDSM-2 include the following:
– Assigning the command and control port to the proper VLAN
– Configuring the switch to capture traffic for intrusion detection
analysis (for promiscuous-mode operations only)
– Obtaining the time setting from either the host switch or an NTP
server
You can use the CLI upgrade command to apply the Cisco IPS
Sensor Software Version 6.0 major upgrade file to the Cisco Catalyst
6500 Series IDSM-2 and retain your configuration.
Summary (Cont.)
Use the show module command to display the module status

and information.
You can recover the application partition image by booting to the
maintenance partition and using the upgrade command to install
the Cisco Catalyst 6500 Series IDSM-2 system image. When you
install the system image, you lose all of your configuration
settings.

Lesson 2
Initializing the Cisco ASA AIP-

SSM
Overview
This lesson describes the Cisco Adaptive Security Appliance Advanced Inspection and
Prevention Security Services Module (ASA AIP-SSM). It also describes how to load Cisco
Intrusion Prevention System (IPS) software on the Cisco ASA AIP-SSM, how to initialize the
module with the setup command, and how to define an IPS modular policy on a security
appliance using the Cisco Adaptive Security Device Manager (ASDM).
Objectives
Upon completing this lesson, you will be able to initialize a Cisco ASA AIP-SSM. This ability
includes being able to meet these objectives:
Describe the Cisco ASA AIP-SSM
Upload the IPS image to the Cisco ASA AIP-SSM
Perform the initial configuration of the Cisco ASA AIP-SSM using Cisco ASDM
Configure an IPS security policy using Cisco ASDM
Cisco ASA AIP-SSM Overview
This topic provides on overview of the Cisco ASA AIP-SSM.
Cisco ASA AIP-SSM Front Bezel
DMZ Servers
Internet
AIP-SSM
Speed Link/Act
Cisco ASA
AIP-SSM
Ethernet Port
Power Status
There are two models of Cisco ASA AIP-SSM, the Cisco ASA AIP-SSM-10 and the Cisco
ASA AIP-SSM-20. Both models appear identical, but the Cisco ASA AIP-SSM-20 has a faster
processor and more memory than the Cisco ASA AIP-SSM-10. Only one module can populate
the slot at a time. On the front bezel of the Cisco ASA AIP-SSM, there are four LEDs and one
10/100/1000 Ethernet port. The table lists the states of the Cisco ASA AIP-SSM LEDs.
States of Cisco ASA AIP-SSM LEDs
LED Color State Description
Power Green On On when the security appliance has power
Status Green Flashing Flashing when the power-up diagnostics are

running or the system is booting
Solid Green when the system has passed power-up

diagnostics
Amber Solid Amber when the power-up diagnostics have

failed
Speed Green Flashing Flashing when there is network activity
Link/Act Green Solid Green when data is passing through the

interface
Remove power to the Cisco ASA 5500 Series Adaptive Security Appliance before installing or
removing the Cisco ASA AIP-SSM.
Differences Between the Cisco ASA AIP-SSM
and Cisco IPS 4200 Series Sensors
The Cisco ASA AIP-SSM has the following differences:

It automatically synchronizes its clock with the Cisco ASA adaptive security
appliance, but it does not synchronize time zone or summertime settings.
There is no clock set command.
The command and control interface is GigabitEthernet0/0.
There is only one sensing interface.
It does not support an alternate TCP reset interface.
It does not require two interfaces in order to be inline mode.
There is no support for inline VLAN pairs or inline pairs.
Sensor virtualization is supported in Cisco ASA Software Version 8.0 and
beyond.
Many Cisco AIP-SSM commands are executed from the CLI.
Although the two Cisco ASA AIP-SSM modules run the same code as the Cisco IPS 4200
Series Sensor, there are some differences. These are the major differences for the Cisco ASA
AIP-SSM:
The Cisco ASA AIP-SSM automatically synchronizes its clock with the Cisco ASA
adaptive security appliance, but it does not synchronize time zone or summertime settings.
There is no clock set command on the Cisco ASA AIP-SSM.
The command and control interface is GigabitEthernet0/0.
There is only one sensing interface.
The Cisco ASA AIP-SSM does not support an alternate TCP reset interface.
It does not require two interfaces in order to be in inline mode.
There is no support for inline VLAN pairs or inline pairs.
The Cisco ASA AIP-SSM supports sensor virtualization starting with Cisco ASA Software
Version 8.0.
Many Cisco ASA AIP-SSM commands are executed from the Cisco ASA adaptive security
appliance command-line interface (CLI).

Cisco ASA AIP-SSM Ethernet
Connections
DMZ Servers
Internet
AIP-SSM
Cisco ASA 5500 Series Adaptive Security Appliance
Cisco ASA
IPS
AIP-SSM
Data channel
Control
channel
Software Download
and Cisco IDM
The Cisco ASA AIP-SSM supports an internal (sensing) Gigabit Ethernet and an external
(command and control) Gigabit Ethernet interface to the Cisco ASA 5500 Series Adaptive
Security Appliance main card. The internal interface is the primary IPS data path interface for
both inline and promiscuous IPS packets. An internal 10/100 Ethernet interface provides a
control channel to the Cisco ASA 5500 Series Adaptive Security Appliance main card. The
external 10/100/1000 Ethernet interface is primarily used for downloading Cisco ASA AIP-
SSM software and for Cisco ASDM access to the Cisco ASA AIP-SSM. The external
10/100/1000 Ethernet interface has an IP address configured.
The GigabitEthernet0/0 interface is the command-control interface, and GigabitEthernet0/1 is

the sensing interface.
Cisco ASA AIP-SSM: Modes of Operation
DMZ Servers
Internet
AIP-SSM
DMZ
Promiscuous
Copy IDS Intrusion Detection
of Traffic
DMZ
Inline
Actual Traffic
IPS Intrusion Prevention
You can configure a Cisco ASA AIP-SSM to operate in one of two IPS modes, promiscuous or
inline. In promiscuous mode, the IPS module is not in the traffic packet flow. You can
configure a security policy, using standard rules and access control lists (ACLs) to identify
traffic that will be copied and passed to the Cisco ASA AIP-SSM. The Cisco ASA AIP-SSM
performs analysis of the traffic. A significant benefit of operating an IPS module in
promiscuous mode is that the IPS module does not affect the packet flow. There are no
performance or operational reliability issues with the forwarded traffic. The drawback to
operating in a promiscuous mode, however, is that the Cisco ASA AIP-SSM may not stop
malicious traffic from reaching its intended target. The response actions implemented by
modules in promiscuous mode are typically post-event responses and often require assistance
from other networking devices, such as routers and firewalls, to respond to an attack. The
argument can be successfully made that modules operating in promiscuous mode cannot
prevent an attack, but can only react. Most IPS products on the market today operate in
promiscuous mode.
Operating in an inline mode, the Cisco ASA AIP-SSM is inserted directly into the traffic flow.
You configure a security policy, using standard rules and ACLs, to identify traffic that should
pass directly to the Cisco ASA AIP-SSM. An inline IPS module sits in the data path, allowing
the sensor to stop attacks by dropping malicious traffic before it reaches the intended target.
The Cisco ASA AIP-SSM not only processes information on the packet “envelope” (Layer 3
and Layer 4), but also analyzes the contents, or payload, of the packets for more sophisticated
embedded attacks (Layer 3 to Layer 7). This deeper analysis allows the system to identify and
block attacks that would normally pass through a traditional firewall device.

Cisco ASA AIP-SSM: Failure Modes
DMZ Servers
Internet
AIP-SSM
DMZ
IPS Fail-Open
DMZ
IPS Fail-Closed
You also must configure what action to take if the Cisco ASA AIP-SSM fails. “Fail-open” or
“fail-closed” refers to what should happen to the traffic flow if the Cisco ASA AIP-SSM fails
for any reason, either a hardware or a software malfunction. With fail-open configured, if the
Cisco ASA AIP-SSM fails, traffic will continue to flow. When operating in promiscuous mode,
Cisco ASA AIP-SSM modules are typically configured for fail-open. With fail-closed enabled,
traffic will cease flowing if the Cisco IPS Sensor Software fails for any reason.
Initializing the Cisco ASA AIP-SSM
Module
DMZ Servers
TFTP Internet
Server
AIP-SSM
Bootstrapping the Cisco ASA AIP-SSM:

Load the IPS software (if necessary)
Configure the initial setup of the Cisco ASA AIP-SSM module
Configure a security policy on the Cisco ASA security appliance
Before the Cisco ASA AIP-SSM can start to inspect and analyze traffic, you must perform
three steps. You should verify, or load and verify, the Cisco IPS Sensor Software on the Cisco
ASA AIP-SSM. After verifying the Cisco IPS Sensor Software, you should configure the initial
setup of the Cisco ASA AIP-SSM. Lastly, you should configure an IPS policy for the Cisco
ASA 5500 Series Adaptive Security Appliance. Each of these steps is discussed in more depth
the “Configuring an IPS Security Policy” topic.

Loading the Cisco ASA AIP-SSM
This topic describes loading and verifying Cisco ASA AIP-SSM Software.
Cisco ASA AIP-SSM Module: No

Software
Internet
AIP-SSM
“slot 1”
asa1# show module 1 detail

Getting details from the Service Module, please wait...
Unable to read details from slot 1
ASA 5500 Series Security Services Module-10
Model: ASA-SSM-10
Hardware version: 1.0
Serial Number: 12345678
Firmware version: 1.0(9)0
Software version:
Status: Init
You can use the show module 1 detail command to view module 1 configuration. You can
view such statistics as hardware version, software version, firmware version, and status of the
Cisco ASA AIP-SSM. The full syntax for this command is as follows:
show module [all | slot [details | recover]]
show module Parameters
Parameter Description
all Shows information for the Cisco ASA AIP-SSM in slot 1 and the
system in slot 0
details Shows additional version information
recover Shows the settings for the hw-module module recover

command
slot Specifies the Cisco ASA AIP-SSM slot information
The output fields of the show module command are as follows:

Model: The model of this Cisco ASA AIP-SSM
Serial Number: The serial number of the Cisco ASA AIP-SSM
Hardware Version: The hardware version of the Cisco ASA AIP-SSM
Firmware Version: The firmware version of the Cisco ASA AIP-SSM
Software Version: The software version of the Cisco ASA AIP-SSM
Status: The status of the module, as follows:
— Initializing: The Cisco ASA AIP-SSM is being detected, and the control
communication is being initialized by the system.
— Up: The Cisco ASA AIP-SSM has completed initialization by the system.
— Unresponsive: The system encountered an error communicating with this Cisco
ASA AIP-SSM.
— Reloading: The Cisco ASA AIP-SSM is reloading.
— Shutting: The Cisco ASA AIP-SSM is shutting down.
— Shut Down: The Cisco ASA AIP-SSM is shut down.
— Recover: The Cisco ASA AIP-SSM is attempting to download a recovery image.
In the example in the figure, the Cisco ASA AIP-SSM present is an ASA AIP-SSM-10 model.
Notice that there is no software present on the module and the module is in the status of trying
to initialize.

TFTP Download Information
Cisco ASA AIP-SSM
Internet
.1
TFTP 10.0.31.0
Server .10
TFTP server IP address and image path:

AIP-SSM Ethernet port IP address
AIP-SSM Ethernet port IEEE 802.1Q VLAN ID
AIP-SSM Ethernet port default gateway address
asa1(config)# hw module 1 recover configure
Image URL [tftp://0.0.0.0/]: tftp://10.0.31.10/IPS-SSM-K9-sys-1.1-a-6.0-1-E1.img
Port IP Address [0.0.0.0]: 10.0.31.1
VLAN ID [0]:
Gateway IP Address [0.0.0.0]:
You can use the hw module 1 recover command to load a recovery software image to the
Cisco ASA AIP-SSM from a TFTP server. This recovery is a two-step process. You must first
define the Cisco ASA AIP-SSM interface and TFTP server network parameters, and then
initiate the download.
Adding the configure keyword to the command enables you to define the Cisco ASA AIP-
SSM and TFTP server network parameters. In the example in the figure, the TFTP server IP
address is 10.0.31.10, and the external Cisco ASA AIP-SSM Ethernet connector IP address is
10.0.31.1. The TFTP server will download the Cisco ASA AIP-SSM-K9-sys-1.1-a-6.0-1-
E1.img image file to the Cisco ASA AIP-SSM.
The full syntax for the hw module slot recover command is as follows:
hw module slot recover {boot | stop | configure [url tfp_url | ip

port_ip_address | gateway gateway_ip_address | vlan vlan_id]}
hw module slot recover Parameters
slot This parameter specifies the Cisco ASA AIP-SSM slot number.
boot This parameter initiates recovery of this Cisco ASA AIP-SSM and
downloads a recovery image according to the configuration
settings. The Cisco ASA AIP-SSM then reboots from the new
image.
stop This parameter stops the recovery action and stops downloading
the recovery image. The Cisco ASA AIP-SSM boots from the
original image.
configure This parameter configures the network parameters to download a

recovery image. If you do not enter any network parameters after
the configure keyword, you are prompted for the information.
url tftp_url This parameter sets the URL for the image on a TFTP server, in
the following format: tftp://server/[path/]filename.
ip port_ip_adress This parameter sets the IP address of the Cisco ASA AIP-SSM
management interface.
gateway This parameter sets the gateway IP address for access to the
gateway_ip_address TFTP server through the Cisco ASA AIP-SSM management
interface.
vlan vlan_id This parameter sets the VLAN ID (VID) for the management
interface.

Recover IPS Image
asa1(config)# debug module
debug module-boot enabled at level 1
asa1(config)# hw module 1 recover boot
The module in slot 1 will be recovered. This may

erase all configuration and all data on that device and
attempt to download a new image for it.
Recover module in slot 1? [confirm]
Recover issued for module in slot 1
asa1(config)# %The module in slot 1 is unresponsive.
%The module in slot 1 is recovering.
Slot-1 8> tftp IPS-SSM-K9-sys-1.1-a-6.0-1-E1.img@10.0.31.10
Slot-1 9> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
Slot-1 10>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
........
Slot-1 79> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Slot-1 80> Received 25116842 bytes
Slot-1 81> Launching TFTP Image...
Slot-1 82> Launching BootLoader...
You can use the hw module 1 recover boot command to initiate the TFTP download of the
image defined in the hw module 1 recover configure command. To aid in the download, you
can enable the debug module command. A sample of a download is displayed in the example
in the figure. The full debug output was truncated to fit into the window. Downloading and
launching the image, launching the bootloader, and recovering the module takes approximately
five minutes to complete.
Cisco ASA AIP-SSM Initialized
Internet
AIP-SSM
asa1# show module 1
Mod Card Type Model Serial No.

--- -------------------------------------------- --------------- ----------
1 ASA 5500 Series Security Services Module-10 ASA-SSM-10 12345678
Mod MAC Address Range Hw Version Fw Version Sw Version

--- --------------------------------- ---------- ------------ ------------
1 000b.fcf8.0170 to 000b.fcf8.0170 1.0 1.0(9)0 6.0(1.22)S267.0
Mod Status
--- ------------------
1 Up
Once the Cisco ASA AIP-SSM is initialized, you can use the show module 1 command to view
the status of the module. From the Show Module 1 window, you can view the model type,
MAC address, serial number, hardware version, firmware version, and software version of the
Cisco ASA AIP-SSM. You can also determine the status of the module. In the example in the
figure, notice that the module is in the Up status and the Cisco IPS Sensor Software Version
6.0(1.22)S267.0 is loaded on the module.

Initiate a Session with the
Cisco ASA AIP-SSM
Internet
AIP-SSM
asa1# session 1
Opening command session with slot 1.
Connected to slot 1. Escape character sequence is 'CTRL-^X'.
login: cisco
Password: <cisco>
You are required to change your password immediately (password aged)
Changing password for cisco
(current) UNIX password: <cisco>
New password: <training>
Retype new password: <training>
………….
sensor#
If the Cisco ASA AIP-SSM is in the Up status, you can open a Telnet session with the module
via the security appliance command line. To initiate a Telnet session, enter the session 1
command at the CLI command prompt. Entering the session 1 command for the first time, you
are prompted for the default login prompt, username cisco, and password cisco. After entering
the default login and password, you are immediately prompted to change the password. In the
example in the figure, the password was changed to training. After changing the password, the
default sensor# command prompt is displayed. To end a session, enter exit or Ctrl+Shift+6
followed by the x key.
Session Setup Default
sensor# setup
--- System Configuration Dialog ---
Current Configuration:
service host
network-settings
host-ip 10.1.9.201/24,10.1.9.1
host-name sensor
telnet-option disabled
ftp-timeout 300
login-banner-text
exit
time-zone-settings
offset 0
standard-time-zone-name UTC
exit
summertime-option disabled
ntp-option disabled
exit
service web-server
port 443
exit
After installing and loading software on the Cisco ASA AIP-SSM, you must initialize the Cisco
ASA AIP-SSM using the setup command. With the setup command, you can configure basic
Cisco ASA AIP-SSM settings, including the hostname, IP interfaces, Telnet server, web server
port, ACLs, and time settings. The example in the figure displays the default setup parameters.
Notice that the default IP address of the external Ethernet connector is 10.1.9.201/24.

Session setup Command
sensor# setup
………….
Continue with configuration dialog?[yes]: <yes>
Enter host name[sensor]: sensor1
Enter IP interface[10.1.9.201/24,10.1.9.1]: 10.0.1.41/24,10.0.1.1
Enter telnet-server status[disabled]:
Enter web-server port[443]:
Modify current access list?[no]: yes
Current access list entries:
No entries
Permit: 10.0.1.0/24
Permit:
………….
[0] Go to the command prompt without saving this config.

[1] Return back to the setup without saving this config.
[2] Save this configuration and exit setup.
Enter your selection[2]: 2

Warning: Reboot is required before the configuration change will take effect
Configuration Saved.
Warning: The node must be rebooted for the changes to go into effect.
Continue with reboot? [yes]: yes
To communicate with Cisco ASDM, you may need to change some of the default setup
parameters such as the IP interface and current access list. Descriptions of the setup command
parameters are as follows:
Enter host name [sensor]: This is the name of the sensor. The hostname can be a string of
1 to 64 characters that matches the pattern ^[A-Za-z0-9_/-]+$. The default is “sensor.” You
receive an error message if the name contains a space or exceeds 64 alphanumeric
characters.
Enter IP interface [10.1.9.201/24, 10.1.9.1]: This is the IP address of the external Cisco
ASA AIP-SSM Ethernet interface. The default is 10.1.9.201. The default mask
corresponding to the IP address is /24, or 255.255.255.0. The default gateway address is
10.1.9.1.
Enter telnet-server status [disabled]: This enables or disables Telnet for remote access to
the sensor. Telnet is not a secure access service and, therefore, is disabled by default.
Enter web-server port [443]: This is the TCP port used by the web server. The default is
443 for HTTPS. You receive an error message if you enter a value out of the range of 1 to
65535.
Modify current access list? [no]: This is the IP address of the hosts or networks that have
permission to access the sensor. By default, there are no entries.
In the example in the figure, the IP address of the external Ethernet connector was changed to
10.0.1.41/24. Hosts on the 10.0.1.0/24 subnet are permitted to access the module.
show module 1 detail Command
asa1# show module 1 detail

Getting details from the Service Module, please wait...
ASA 5500 Series Security Services Module-10
Model: ASA-SSM-10
Hardware version: 1.0
Serial Number: 0
Firmware version: 1.0(9)0
Software version: 6.0(1.22)S267.0
Status: Up
Mgmt IP addr: 10.0.1.41
Mgmt web ports: 443
Mgmt TLS enabled: true
You can use the show module 1 detail command to view the Cisco ASA AIP-SSM hardware
and software details, including the remote management configuration. In the example in the
figure, a device manager can access the Cisco ASA AIP-SSM through the Cisco ASA AIP-
SSM external interface using the IP address 10.0.1.41, the Cisco ASA AIP-SSM web server
port is 443, and management Transport Layer Security (TLS) or Secure Sockets Layer (SSL) is
enabled.

Initial Cisco ASA AIP-SSM Configuration Using
Cisco ASDM
This topic describes how to access the Cisco ASA AIP-SSM with Cisco ASDM.
IPS Access
AIP-SSM
Internet
.41
Cisco
ASDM .10
After installing the Cisco ASA AIP-SSM, you initialized the module using the setup command
from the CLI. With the setup command, you configured basic sensor settings, including the
hostname, IP interfaces, web server port, ACLs, and time settings. After initializing the Cisco
ASA AIP-SSM, you can now communicate with the module using Cisco ASDM. The IPS icon
is not present on Cisco ASDM until the Cisco IPS Sensor Software is installed and configured
on the Cisco ASA AIP-SSM.
To access the Cisco ASA AIP-SSM from Cisco ASDM, click the IPS icon under the features
column. The Connecting to IPS pop-up window appears. The IP address referenced by the
Management IP Address prompt in the pop-up window refers to the IP address of the external
Ethernet interface of the Cisco ASA AIP-SSM. An option is provided in this dialog to enter a
different IP address, in case you are accessing the IPS sensor from behind a Network Address
Translation (NAT) device. Cisco ASDM can manage only the Cisco ASA AIP-SSM card in the
same chassis as the Cisco ASA adaptive security appliance from which Cisco ASDM is started.
Choose Management IP Address and then click Continue. If a route exists between the Cisco
ASDM PC and the external Ethernet interface on the Cisco ASA AIP-SSM, the Cisco ASA
AIP-SSM session login prompt should open.
You can configure intrusion prevention either using the Cisco ASDM or through the CLI.
Configuring an IPS Security Policy
This topic describes how to configure an IPS service policy on the Cisco ASA security
appliance.
Create a Security Policy

Create a security
policy.
Identify a class of
traffic.
Associate IPS
policy with class
of traffic.
Activate the
policy globally or
on an interface.
The last step in the process is to create a security policy on the Cisco ASA 5500 Series
Adaptive Security Appliance. A security policy enables the Cisco ASA Adaptive Security
Appliance to prefilter, and then pass selected traffic to the Cisco ASA AIP-SSM for inspection
and analysis. This level of interaction between the Cisco ASA security appliance and Cisco
ASA AIP-SSM enables the IPS system to operate at greater efficiency. The Cisco ASA AIP-
SSM analyzes only a subset of the total bandwidth, the relevant traffic, and filters out
nonrelevant traffic. You can apply a security policy to an interface or globally to every
interface.
To create an IPS service policy from Cisco ASDM, click Security Policy and choose the
Service Policy Rules option.

Create a Service Policy
The Add Service Policy Rule Wizard dialog box guides you through the addition of a new
service policy rule. You can apply the new security policy rule to a specific interface, such as
the outside or inside interface, or you can apply it globally to all of the interfaces.
Descriptions of the fields in the Create a Service Policy and Apply To group box are as follows:
Interface radio button: This applies the rule to a specific interface. This selection is
required if you want to match traffic based on the source or destination IP address using an
ACL.
Interface drop-down list: This specifies the interface to which the rule applies.
Description field: This provides a text description of the policy.
Global - Applies to All Interfaces radio button: This applies the rule to all of the
interfaces.
Policy Name box: This specifies the name of the global service policy. Only one global
service policy is allowed and it cannot be renamed.
Description box: This provides a text description of the policy.
Identify a Class of Traffic
After you define a service policy, you define a traffic class. You define the criteria used by the
Cisco ASA Adaptive Security Appliance to identify which traffic is routed to the Cisco ASA
AIP-SSM for inspection and analysis. The Traffic Classification Criteria dialog box enables
you to specify the criteria that you want to use to match traffic to which the security policy rule
applies. Descriptions of the fields are as follows:
Create a New Traffic Class: This identifies the name of the new traffic class.
Description: This provides a text description of the new traffic class.
Traffic Match Criteria: The available matching criteria choices are as follows:
— Default Inspection Traffic: This uses the criteria specified in the default inspection
traffic policy.
— Source and Destination IP Address (Uses ACL): This matches traffic based on the
source and destination IP addresses, using an ACL. This selection is only available if
you apply the rule to a specific interface using an interface service policy.
— Tunnel Group: This matches traffic based on the tunnel group. If a tunnel group is
selected as one match criteria, a second criterion can also be selected.
— TCP or UDP Destination Port: This matches traffic based on the TCP or User
Datagram Protocol (UDP) destination port.
— RTP Range: This matches traffic based on a range of Real-Time Transport Protocol
(RTP) ports.
— IP DiffServ CodePoints (DSCP): This matches traffic based on the differentiated
services code point (DSCP) model of quality of service (QoS).
— IP Precedence: This matches traffic based on the IP precedence model of QoS.
— Any Traffic: This matches all traffic regardless of the traffic type.

Define Traffic Matching Criteria
The Source and Destination Address dialog box appears when you check the Source and
Destination IP Address (Uses ACL) check box on the Traffic Match Criteria dialog box. This
dialog window enables you to identify the traffic to which a service policy rule applies based
on the IP address of the sending or receiving host. In the example in the figure, the traffic
criteria is a packet with any source IP address from the outside destined to anywhere.
Define IPS Policy
The Intrusion Prevention tab enables you to configure the IPS action to take on the selected
traffic class. This window appears only if Cisco IPS Sensor Software and Cisco ASA AIP-SSM
hardware is installed in the security appliance. The fields on the Intrusion Prevention tab are as
follows:
Enable IPS for This Traffic Flow: This check box enables or disables intrusion
prevention for the traffic flow. When this check box is selected, the other parameters in this
window become active.
Mode: This group box configures the operating mode for intrusion prevention.
— Inline Mode: This option selects Inline Mode, in which a packet is directed to IPS.
The packet might be dropped because of the IPS operation.
— Promiscuous Mode: This option selects Promiscuous Mode, in which IPS operates
on a duplicate of the original packet. The original packet cannot be dropped.
If IPS Card Fails, Then: This group box configures the action to take if the IPS card
becomes inoperable.
— Permit Traffic: This option permits traffic if the Cisco ASA AIP-SSM card fails.
— Close Traffic: This option blocks traffic if the Cisco ASA AIP-SSM card fails.

Apply or View Service Policy Rule
The last step is to apply the service policy rule. Click Apply to initiate the new IPS service
policy.
Summary
Summary
There are two Cisco ASA AIP-SSM models: the AIP SSM-10 and
AIP SSM-20.
If there is no Cisco IPS Sensor Software on the Cisco ASA AIP-
SSM, or if it is corrupt, use the hw module 1 recover command
to load the initial Cisco IPS Sensor Software image.
Use the setup command to configure the initial Cisco ASA
AIP-SSM setup.
A security policy enables the Cisco ASA adaptive security
appliance to prefilter, and then pass, selected traffic to the Cisco
ASA AIP-SSM for inspection and analysis.

Module Summary
Module Summary
The Cisco Catalyst 6500 Series IDSM-2 and Cisco ASA AIP-SSM
run the same code as the Cisco IPS 4200 Series Sensors, and they
must obtain their time setting from one of the following:
– The host device
– An NTP server
Use the Cisco ASDM or the CLI to configure a modular policy for IPS
inspection on the Cisco ASA AIP-SSM models.
The Cisco Catalyst 6500 Series Intrusion Detection System Services Module 2 (IDSM-2) is a
high-performance module designed to run in the Cisco Catalyst 6500 Series Switches. It runs
the same image as the Cisco Intrusion Prevention System (IPS) 4200 Series Sensors, although
some features are not exactly the same.
There are two Cisco Adaptive Security Appliance Advanced Inspection and Prevention
Security Services Module (ASA AIP-SSM) models: the Cisco ASA AIP-SSM-10 and Cisco
ASA AIP-SSM-20. The features on both are identical. They run the same image as the Cisco
IPS 4200 Series Sensors and for the most part have the same features.
References
Cisco Systems, Inc. Cisco Intrusion Prevention System: Introduction.
http://www.cisco.com/go/ips.
Cisco Systems, Inc. Regulatory Compliance and Safety Information for the Intrusion
Detection System Appliances and Modules.
Cisco Systems, Inc. Cisco Intrusion Detection System Appliance and Module Installation
and Configuration Guide.
http://www.cisco.com/en/US/products/sw/secursw/ps2113/products_installation_and_confi
guration_guide_book09186a008014a234.html.
Cisco Systems, Inc. Cisco Intrusion Prevention System Command Reference 6.0.
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_command_reference_
book09186a00807a874d.html.
Cisco Systems, Inc. Cisco Dynamic Configuration Tool.
https://tools.cisco.com/qtc/config/html/configureHomeGuest.html.
Cisco Systems, Inc. Catalyst 6500 Series Command Reference, 8.4.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_4/cmd_ref/index.htm.
Cisco Systems, Inc. Cisco ASA 5500 Series Adaptive Security Appliances: Introduction.
http://www.cisco.com/go/asa.

Module 6
Cisco IPS Sensor

Maintenance
Overview
This module provides information on monitoring the health and welfare of your sensor. This
module will examine how to use the command-line interface (CLI) and the Cisco Intrusion
Prevention System (IPS) Device Manager (IDM) to install licenses and upgrade or recover the
Cisco IPS Sensor Software, in addition to other maintenance tasks.
Module Objectives
Upon completing this module, you will be able to use the CLI and the Cisco IDM to obtain
system information. You will also be able to configure the Cisco IPS sensor to allow a Simple
Network Management Protocol (SNMP) network management system (NMS) to monitor the
Cisco IPS sensor. This ability includes being able to meet these objectives:
Install and recover the Cisco IPS Sensor Software and perform service pack and signature
updates
Use the CLI and the Cisco IDM to verify sensor configuration and perform password
recovery
Lesson 1
Maintaining Cisco IPS Sensors
Overview
This lesson explains how to maintain a Cisco Intrusion Prevention System (IPS) sensor. This
lesson discusses how to perform maintenance tasks such as updating signatures files,
recovering corrupted images, and performing password recovery.
Objectives
Upon completing this lesson, you will be able to install and recover the Cisco IPS Sensor
Software and perform service pack and signature updates. This ability includes being able to
meet these objectives:
Describe the Cisco IPS sensor licenses and how to install them
Perform a Cisco IPS sensor upgrade or recovery
Install service pack and signature updates
Perform a password recovery on a Cisco IPS sensor
Restore a Cisco IPS sensor to its default configuration
Understanding Cisco IPS Licensing
This topic describes the different Cisco IPS sensor licenses and how to install them.
Understanding Cisco IPS Licensing
Although the Cisco IPS sensor can function without the license
key, you must have a license key to obtain signature updates.
To obtain a license key, you must have a Cisco Services for IPS
service contract.
Contact your reseller, or Cisco service or product sales to
purchase a contract.
Sixty-day trial licenses are available when there are problems with
your contract.
Although the Cisco IPS sensors function without a license key, you must have a license key to
obtain signature updates. To obtain a license key, you must have a Cisco Services for IPS
service contract. Contact your reseller, or Cisco service or product sales to purchase a contract.
Trial license keys are also available. If you cannot get your Cisco IPS sensor licensed because
of problems with your contract, you can obtain a 60-day trial license that supports signature
updates that require licensing. You can obtain a license key from the Cisco.com licensing
server, which is then delivered to the sensor. Or, you can update the license key from a license
key provided in a local file. Go to
https://tools.cisco.com/SWIFT/Licensing/PrivateRegistrationServlet?FormId=137 to apply for
a license key. This requires a Cisco.com account.
You must know your Cisco IPS device serial number to obtain a license key. To find the Cisco
IPS sensor serial number use Cisco IPS Device Manager (IDM) and choose Configuration >
Licensing, or enter the command show version at the command-line interface (CLI).
You can view the status of the license key on the Licensing panel in Cisco IDM. Whenever you
start Cisco IDM, you are informed of your license status—whether you have a trial, invalid, or
expired license key. With no license key, an invalid license key, or an expired license key, you
can continue to use Cisco IDM but you cannot download signature updates.
When you enter the CLI, you are also informed of your license status. For example, you receive
the following message if there is no license installed:
***LICENSE NOTICE***
There is no license key installed on the system.
The system will continue to operate with the currently installed
signature set. A valid license must be obtained in order to apply
signature updates. Please go to http://www.cisco.com/go/license
to obtain a new license or install a license.
You will continue to see this message until you install a license key.
© 2007 Cisco Systems, Inc. Cisco IPS Sensor Maintenance 6-5

Service Programs for Cisco IPS
Licensing
Cisco IPS 4200 Series Sensors require Cisco Services for IPS
service contracts to install signature updates.
The Cisco Catalyst 6500 Series IDSM-2 requires the Cisco
Services for IPS service contract for signature updates even when
a SMARTnet contract exists.
Cisco ASA 5500 Series Adaptive Security Appliances also require
the Cisco Services for IPS service contract for signature updates
even when a SMARTnet contract exists.
When you purchase the following Cisco IPS sensor products, you must also purchase a Cisco
Services for IPS service contract:
Cisco Intrusion Detection System (IDS) 4215 Sensor
Cisco Catalyst 6500 Series Intrusion Detection System Services Module 2 (IDSM-2)
For Cisco ASA 5500 Series Adaptive Security Appliances, if you purchase one of the following
Cisco ASA adaptive security appliance products that do not contain IPS, you must purchase a
SMARTnet contract:
Note SMARTnet provides operating system updates, access to Cisco.com, access to the Cisco
Technical Assistance Center (TAC), and hardware replacement on the next business day on
site.
Cisco ASA5510-K8 Adaptive Security Appliance

Cisco ASA5510-DC-K8 Adaptive Security Appliance
Cisco ASA5510-SEC-BUN-K9 Adaptive Security Appliance
Cisco ASA5520-BUN-K9 Adaptive Security Appliance
Cisco ASA5540-BUN-K9 Adaptive Security Appliance
If you purchased one of the following Cisco ASA 5500 Series Adaptive Security Appliances
that ships with the Cisco Adaptive Security Appliance Advanced Inspection and Prevention
Security Services Module (ASA AIP-SSM) installed, or if you purchased a Cisco ASA AIP-
SSM to add to your Cisco ASA adaptive security appliance product, you must purchase the
Cisco Services for IPS service contract:
Note Cisco Services for IPS provides IPS signature updates, operating system updates, access to
Cisco.com, access to Cisco TAC, and hardware replacement on the next business day on
site.
Cisco ASA5510-AIP10-K9 Adaptive Security Appliance

Cisco ASA AIP-SSM-10-K9
Cisco ASA AIP-SSM-20-K9
For example, if you purchased a Cisco ASA 5510 Adaptive Security Appliance and then later
wanted to add IPS capabilities and purchased a Cisco ASA AIP-SSM-10-K9, you must now
purchase the Cisco Services for IPS service contract.
Once you have the Cisco Services for IPS service contract, you must also have your product
serial number to apply for the license key.

Installing a Cisco IPS License
Apply for the license at http://www.cisco.com/go/license.

Place the license file on one of the following types of servers:
– FTP
– SCP
– HTTP
– HTTPS
Use the copy command with the keyword license-key to install a
license.
Step 1 Apply for the license key at http://www.cisco.com/go/license.
Note You must have a Cisco Services for IPS service contract before you can apply for a license
key.
Step 2 Fill in the required fields.
Note You must have the correct Cisco IPS sensor device serial number because the license key
functions only on the device with that number. Your Cisco IPS Signature Subscription
Service license key is sent by e-mail to the e-mail address that you specify when applying
for the license key.
Step 3 Save the license key to a system that has a web server, FTP server, or Secure Copy
Protocol (SCP) server.
Step 4 Log into the CLI using an account with administrator privileges.
copy Command
sensor(config)#
copy source-url license_file_name license-key
Upgrades the license via an FTP, HTTP, HTTPS, or SCP

server
sensor(config)#
copy ftp://administator@10.0.1.12/license.lic license-
key
Upgrades the license via an FTP server
Step 5 Copy the license key to the sensor using the command copy source-url
license_file_name license-key and provide a password if prompted. Here is an
example:
sensor# copy ftp://administrator@10.0.1.12/license.lic license-key
Password: *******
Step 6 Verify that the sensor is licensed.

Sensor Licensing
Configuration
Cisco
Connection
Online
Licensing
License File Update

License
You can also use the Cisco IDM to obtain and install a new license. When you launch the Cisco
IDM, a dialog box appears informing you of your license status. The status can be trial, invalid,
or expired. With no license key, an invalid license key, or an expired license key, you can
continue to use the Cisco IDM, but you cannot download signature updates.
You can also view the current status of your license, its expiration date, and your sensor serial
number on the Cisco IDM Licensing panel. You must know your sensor serial number to obtain
a license. If the key is invalid, no expiration date is displayed.
Note The CLI show version command also displays the serial number.
Follow these steps to obtain a new license from the Cisco IDM:
Step 1 Choose one of the following Update From radio buttons:

Cisco Connection Online: This option enables you to have the Cisco.com
licensing server automatically deliver a license to your sensor.
License File: This option enables you to update the sensor license from a
license key provided in a local file. You can enter the location of the local file
containing the license key in the Local File Path or click Browse Local to invoke
a file browser for locating the license key. Before you can use this option, you
must apply for a license. The license is mailed to the e-mail address that you
specify in the application. Save the license to a drive that is accessible by the
Cisco IDM.
Step 2 Click Update License. The Licensing window opens.
Step 3 Click Yes to continue. If you selected the Cisco Connection Online radio button, a
Status window opens informing you that the sensor is attempting to connect to
Cisco.com. When the license has been obtained, an Information dialog box appears
confirming that the license has been updated.

How to Upgrade and Recover Sensor Images
This topic explains how to upgrade your sensor image and recover it if it becomes corrupted.
Sensor Image Types
There are three types of sensor images:

Application image
System image
Recovery image
There are three types of sensor images:

Application image: The image used for operating the sensor
System image: The full IPS application and recovery image used for reimaging an entire
sensor
Recovery image: The application image plus an installer to be used for recovery
Upgrading the Sensor
You can use the upgrade command to apply image upgrades, service
packs, and signature updates to your sensor.
The upgrade command upgrades the sensor application and recovery
images.
You can use the upgrade command to upgrade from Cisco IPS Sensor
Software Version 5.x to Version 6.0.
To upgrade from Cisco IPS Sensor Software Version 5.x to 6.0, the
sensor must already be running Cisco IPS Sensor Software Version 5.1
or higher.
When you use the upgrade command to apply the Cisco IPS Sensor
Software Version 6.0 major upgrade file, your configuration, including
signature settings, is retained.
The Cisco IPS Sensor Software Version 6.0 major upgrade file is the
same for all sensor appliances.
Example: IPS-K9-6.0-1-E1.pkg
You can use the upgrade command to apply image upgrades, service packs, and signature
updates to any of the following Cisco IPS sensor models:
Cisco IDS 4215 Sensor
The upgrade command upgrades the sensor application and recovery images. You can use the
upgrade command to upgrade your sensor from Cisco IPS Sensor Software Version 5.x to
Cisco IPS Sensor Software Version 6.0; however, the sensor must be running Cisco IPS Sensor
Software Version 5.1(4) or higher prior to the upgrade. Using the upgrade command to apply
the Cisco IPS Sensor Software Version 5.0 major upgrade file retains your configuration,
including signature settings.

upgrade Command
sensor(config)#
upgrade source-url
Upgrades the sensor image via an FTP or SCP server
sensor(config)#
upgrade ftp://administator@10.0.1.12/IPS-K9-6.0-1-
E1.pkg
Upgrades the application and recovery image to Cisco IPS

Sensor Software Version 6.0(1)
You can install a Cisco IPS Sensor Software update by executing the upgrade command from
the configuration prompt of the sensor. You can enter all of the necessary file location (URL)
information and the username in one command-line entry.
Note You cannot downgrade the Cisco IPS Sensor Software Version 6.0(1) major update using
the downgrade command. You must reimage the sensor using a Cisco IPS Sensor
Software Version 5.1(4) system image or recovery CD. When you reimage the sensor, this
results in the loss of any configuration changes that you made.
Use the following guidelines when specifying the location of the update file:
FTP: This is the source URL for an FTP network server. The syntax for this prefix can be
one of the following:
— ftp:[[//username@]location]/relativeDirectory/filename
— ftp:[[//username@]location]//absoluteDirectory/filename
SCP: This is the source URL for the SCP network server. The syntax for this prefix can be
one of the following:
— scp:[[//username@]location]/relativeDirectory]/filename
— scp:[[//username@]location]//absoluteDirectory]/filename
HTTP: This is the source URL for a web server. The syntax for this prefix is as follows:
— http:[[//username@]location]/directory]/filename
HTTPS: This is the source URL for a web server. The syntax for this prefix is as follows:
— https:[[//username@]location]/directory]/filename
Note Before using the HTTPS protocol, you must configure a Transport Layer Security (TLS)
trusted host.

Full System Reimage
A full system reimage is a means of upgrading or recovering both

the application image and the recovery image.
The method you use to perform a full system reimage varies
among sensor platforms.
To perform a full system reimage, you must use the system image
file specific to your sensor platform.
You lose all of your configuration settings when you perform a full
system reimage.
A full system reimage is a means of upgrading or recovering the application and recovery
images. To perform a full system reimage, you must use the system image file specific to your
sensor platform. You lose your entire configuration settings when you perform a full system
reimage.
Full System Reimage: Cisco IDS 4235
and 4250 XL Sensors
You can perform a full system reimage of the following sensors

by using the Cisco IPS Sensor Software Version 6.0(1)
Recovery CD:
– Cisco IDS 4235 Sensor
– Cisco IDS 4250 XL Sensor
Complete the following steps to perform a full system reimage:
1.Connect to the sensor with a keyboard and monitor or a serial
connection.
2.Place the CD in the sensor.
3.Boot the sensor from the CD.
4.Follow the instructions to reimage the sensor.
You can perform a full system reimage of the following sensors by using the Cisco IPS Sensor
Software Version 6.0(1) Recovery CD:
Follow these steps to perform a full system reimage of the sensor:
Step 1 Connect to the sensor with a keyboard and monitor or a serial connection.
Step 2 Place the CD in the sensor.
Step 3 Boot the sensor from the CD.
Step 4 Follow the instructions to reimage the sensor.
Note The recovery image IPS-K9-cd-11-a-6.0-1-E1.iso is available at Cisco.com.

Full System Reimage: Cisco IDS 4215 Sensor,
and Cisco IPS 4240, 4255, and 4260 Sensors
You can use ROM monitor, a boot utility on the sensor, to transfer
system images onto the following sensors:
– Cisco IDS 4215 Sensor
– Cisco IPS 4240 Sensor
Cisco IPS Sensor Software Version 6.0 system image files
contain the “sys” identifier. Example: IPS-4240-K9-sys-1.1-a-6.0-
1-E1.img
Because the Cisco IDS 4215, Cisco IPS 4240, Cisco IPS 4255 and Cisco IPS 4260 Sensors
have no CD-ROM drive, a full system reimage is done over the network using TFTP. You can
also use ROM monitor, a boot utility on the sensor, to transfer system images onto these
sensors.
Using ROM Monitor for Full System
Reimage
Follow these steps to perform a full system reimage over the
network:
1. Place the system image file for your sensor platform on a TFTP server.
2. Verify that you can access the TFTP server from the network connected to
your sensor Ethernet port.
3. Reboot the sensor.
4. Escape the boot sequence.
5. Verify that the Cisco IPS sensor is running BIOS version 5.1.7 or later and
ROM monitor version 1.4 or later.
6. Change the interface port number if necessary.
7. Specify the IP address of the sensor.
8. Specify the IP address of the TFTP server.
9. Specify the IP address of the sensor default gateway.
10. Specify the path and filename on the TFTP server.
11. Begin the TFTP download.
Follow these steps to use ROM monitor to install the system image onto the sensor:
Step 1 Download the system image file for your sensor platform to the TFTP root directory
of a TFTP server that is accessible from your sensor. A system image file has the
.img extension and contains the platform number in the name.
Step 2 Verify that you can access the TFTP server from the network connected to your
sensor Ethernet port.
Step 3 Log into the sensor and reboot it:
sensor# reset
Step 4 Press Ctrl-R within 5 seconds after the following message is displayed during
bootup:
Evaluating Run Options...
Note If you are applying a system image to a Cisco IPS 4240 or Cisco IPS 4255 Sensor, press
Break or Esc within 10 seconds instead of pressing Ctrl-R within 5 seconds.
Step 5 Examine the console display information to verify that the sensor is running BIOS
version 5.1.7 or later and ROM monitor version 1.4 or later. If not, you must
upgrade the Cisco IDS 4215 Sensor BIOS to version 5.1.7 and the ROM monitor to
version 1.4, using the upgrade utility file IDS-4215-bios-5.1.7-rom-1.4.bin, available
for download at http://www.cisco.com/cgi-bin/tablebuild.pl/ips6-firmware.
Step 6 If necessary, change the interface port number to be used for the TFTP download
when the ROM monitor prompt is displayed. The default interface port number used
for TFTP downloads on the Cisco IPS 4240 and 4255 Sensors is Management0/0,
which corresponds with the Cisco IPS 4240 and 4255 Sensor management
interfaces. The default interface port number used for TFTP downloads on the Cisco

IDS 4215 Sensor is port 1, which corresponds with its command and control
interface. The port in use is listed in the console display just before the ROM
monitor prompt. On the Cisco IPS 4240 and 4255 Sensors, it appears immediately
after the platform name. In the Cisco IDS 4215 Sensor, it appears immediately after
the “bus” and “irq” information. Here is an example:
On the Cisco IPS 4240 Sensor:
Platform IPS-4240-K9
Management0/0
On a Cisco IDS 4215 Sensor:
0: i8255X @ PCI(bus:0 dev:13 irq:11)
1: i8255X @ PCI(bus:0 dev:14 irq:11)
Using 1: i82557 @ PCI(bus:0 dev:14 irq:11), MAC:
0000.0001.0001
Note Although the information that must be entered is the same for the Cisco IDS 4215, Cisco
IPS 4240, and Cisco IPS 4255 Sensors, the format for the Cisco IDS 4215 Sensor is
different from that of the newer platforms. For example, the format for entering the port
number on the Cisco IDS 4215 Sensor is rommon> interface port_number, while the
format for the Cisco IPS 4240 and Cisco IPS 4255 Sensors is rommon> PORT=. For this
example, the format of the Cisco IDS 4215 Sensor is used.
Step 7 Specify the IP address of the sensor:

rommon> address 10.0.1.4
Step 8 Specify the IP address of the TFTP server on which the image is stored:
rommon> server 172.16.1.22
Step 9 Specify the gateway IP address used by the sensor:
rommon> gateway 10.0.1.2
Step 10 Specify the path and filename on the TFTP server from which you are downloading
the image. In UNIX, the path is relative to the default tftpboot directory of the UNIX
TFTP server. Images located in the default tftpboot directory do not have any
directory names or slashes in the file location.
rommon> file IPS-4215-K9-sys-1.1-a-6.0-1.img
Note On the Cisco IPS 4240 and Cisco IPS 4255 Sensors, replace the keyword file with the
keyword IMAGE.
Step 11 Download and install the system image:

rommon> tftp
Caution If you remove power from the sensor during the update process, the upgrade can become
corrupt.
The following TFTP servers are recommended:
For Microsoft Windows: Tftpd32 version 2.0
For UNIX: Tftp-hpa series

Recovering the Sensor Appliance Image
You can use either of the following methods to recover

your sensor appliance application image, both of which
retain your network settings:
Use the recover command
Select the recovery image from the boot menu during bootup
In case your Cisco IPS sensor application image becomes corrupted, you can recover it by
using one of two methods.
You can use the recover command. This method retains your sensor IP address, subnet
mask, and default gateway settings.
You can choose the Cisco IPS recovery image from the boot menu during bootup. This
method also retains your sensor IP address, subnet mask, and default gateway settings and
is useful if you are unable to access the CLI.
Note You can also recover sensor platforms that support a CD drive using the Cisco IPS Sensor
Software Version 6.0(1) Recovery CD.
recover Command
sensor(config)#
recover application-partition
Performs an application reimage on the sensor
sensor(config)# recover application-partition

Warning: Executing this command will stop all
applications and re-image the node to version 6.0(1).
All configuration changes except for network settings
will be reset to default.
Continue with recovery?:yes
Request Succeeded
sensor(config)#
Use the command recover application-partition to perform an application reimage on the

Cisco IPS sensor.

Booting the Recovery Image
You can use the boot menu to perform an application reimage on
the following Cisco IPS and IDS sensors:
Cisco IPS
Recovery
You can perform an application reimage on the following sensors using the boot menu:
Follow these steps to perform an application reimage using the boot menu option during reboot:
Step 1 Enter reset at the privileged EXEC prompt to reboot the sensor.
sensor# reset
Step 2 Answer yes when asked if you want to continue.
Warning: Executing this command will stop all applications and
reboot the node. Continue with reset? [] yes
Step 3 When the Grand Unified Bootloader (GRUB) menu is displayed, press the Down
Arrow key to choose Cisco IPS Recovery.
Step 4 Press Enter. The application reimage process begins.
The Recovery Image File
You can upgrade the recovery image on your sensor with the
most recent version so that it is ready if you need to recover the
application image.
Recovery images are only generated for major and minor
software releases, not for service packs or signature updates.
The recovery image file can be recognized by the “r” identifier in
its name.
Example: IPS-K9-r-1.1-a-6.0-1.pkg
You can use the Cisco IPS Software Sensor Version 6.0(1)
recovery image file to upgrade the recovery image of all sensor
platforms.
The recovery image can be applied to the sensor by using the
upgrade command.
You can upgrade the recovery image on your sensor with the most recent version so that it is
ready if you need to recover the application image. Recovery images are generated only for
major and minor software releases, not for service packs or signature updates. The recovery
image file can be recognized by the “r” identifier in its name. For example, in the file name
IPS-K9-r-1.1-a-6.0-1.pkg, the “r-1.1” indicates that this is a recovery image and specifies the
recovery image version. Like other image files, the recovery image can be applied to the sensor
by using the upgrade command.
You can use the Cisco IPS Sensor Software Version 6.0 recovery image file with the CLI
upgrade command to upgrade the recovery image of the following sensors:
Note Cisco IPS Sensor Software Version 6.0 files are available through a Cisco.com download.

How to Install Service Packs and Signature
Updates
This topic explains how to use the Cisco IDM to install service packs and signature updates.
Software Updates Overview
Cisco IPS Sensor Software updates provide the latest signature

and intrusion prevention improvements.
New IPS signatures are released as signature updates.
IPS improvements are released as service packs.
The most recent update can be uninstalled to return the Cisco IPS
Sensor Software to the previous version.
New attacks that pose a threat to networks are discovered every day. Cisco releases regular
signature updates and critical updates for major attack events to enable the sensor to detect
these attacks. Cisco also releases service packs to improve the intrusion prevention capabilities
of the Cisco IPS sensors.
Signature updates are released independently from the other software files, such as major
upgrades, minor upgrades, and service packs, and they have their own versioning scheme.
Note Beginning with Cisco IPS Sensor Software Version 5.0, signature updates include all
signatures since the initial signature release, in addition to the new signatures being
released.
Cisco has partnered with Trend Micro to provide an additional signature update service. You
can subscribe to this service, in which Trend Micro pushes signature updates to sensors within
two hours of signature creation. Your sensor must be properly licensed to accept the signature
updates.
Trend Micro updates signatures by adding or modifying their set of signatures in the signature
definition service configuration. Trend Micro is allotted a block of signatures in the
configuration. Trend Micro does not change the settings for signatures that are outside of their
block. The sensor supports partial configuration changes to allow Trend Micro to modify only
their part of the configuration. Trend Micro can push update signatures independently from
normal signature updates.
You can install service pack and signature updates from the supported management consoles or
from the CLI. You can also uninstall the most recent update if necessary.
Note To remove the last applied signature update or service pack, use the downgrade command
in global configuration mode.

Service Pack Files
Major Minor Service

Version Version Pack
Level Level Level
IPS-K9–type–w.x-y.pkg
Update Extension
Type
Example: IPS-K9-sp-6.0-2.pkg
A Cisco IPS service pack file name has the following parts:
IPS: This specifies the product line.
K9: This indicates strong cryptography.
Update type: This indicates whether the file contains a major version upgrade, a minor
version upgrade, or a service pack. The package type for a service pack is “sp.”
Software version: The software version consists of numeric values representing the major
release, the minor upgrade, and the service pack. The major release number and minor
upgrade number are separated by a decimal. The minor upgrade number and the service
pack number are separated by a hyphen (-).
Extension: The filename extension is .pkg.
Signature Update Files
Signature
Update Extension
Version
IPS-sig–Sx-req-w.pkg
Minimum
Requirement
Designator
Example: IPS-sig-S267-req-E1.pkg
A Cisco IPS signature update file name has the following parts:
IPS: This specifies the product line.
Sig: This specifies the update type, which indicates the type of content contained in the file.
The package type “sig” indicates that this is a signature update.
S: This is the signature version designator.
x: This is the signature update version.
Req: This is the minimum requirement designator.
Extension: This is the filename extension.

Applying Updates to the Sensor
Configuration
URL
Username
Update
Sensor Password
Browse
Local
Update is Located Local File
on a Remote Path
Update Is Update
Server and Is
Located on Sensor
Accessible by the
Sensor This Client
From the Cisco IDM Update Sensor panel, you can immediately apply service pack and
signature updates. The sensor does not download service pack and signature updates from
Cisco.com. You must download the service pack and signature updates from Cisco.com to an
FTP, SCP, HTTP, or HTTPS server and then configure the sensor to download them from your
server.
Follow these steps to immediately apply a service pack and signature update:
Step 1 Click Configuration and choose Update Sensor. The Update Sensor panel is
displayed.
Step 2 Choose one of the two options and complete the fields it activates.
Update Is Located on a Remote Server and Is Accessible by the Sensor:
Supply the following information for this option:
— URL: Select the type of server on which the file is stored from the drop-
down menu and enter the URL where the update can be found in the
URL field. The syntax for each type of server is as follows:
FTP:
ftp://location/relative_directory/filename
or
ftp://location//absolute_directory/filename
HTTPS:
https://location/directory/filename
Note Before using the HTTPS protocol, configure a TLS trusted host.
SCP:
scp://location/relative_directory/filename
or
scp://location/absolute_directory/filename
HTTP:
http://location/directory/filename
— Username: Enter the username for an account on the remote server.

— Password: Enter the password associated with the username that you specified.
Update Is Located on This Client: This option pushes the update from the local client to
the sensor. You can enter the path to the update file in the Local File Path field or click
Browse Local to navigate through the files on the local client.
Step 3 Click Update Sensor. The Update Sensor window opens.

Step 4 Click OK.
Note The sensor applications are stopped while the update is applied. If you are applying a
service pack, the installer automatically reboots the sensor.

Configuring Automatic Updates
Configuration
Enable Auto
Update
Auto Update
Schedule
Remote
Server
Settings
Hourly Daily
Apply
You can configure automatic updates to have service pack or signature updates that reside on a
local FTP or SCP server downloaded and applied to your sensor. The sensor does not
automatically download service pack and signature updates from Cisco.com. You must
download the service pack or signature updates from Cisco.com to your FTP or SCP server and
then configure the sensor to download them from your server.
Follow these steps to configure automatic updates:

Step 1 Click Configuration and choose Auto Update. The Auto Update panel is displayed.
Step 2 Check the Enable Auto Update check box to enable automatic updates. If you do
not check Enable Auto Update, all of the fields are disabled and cleared. You cannot
toggle this on or off without losing all of the other settings.
Step 3 Enter the IP address of the remote server that contains the updates in the IP Address
field within the Remote Server Settings.
Step 4 Choose FTP or SCP from the File Copy Protocol drop-down menu to identify the
protocol used to connect to the remote server.
Step 5 Enter the path to the update in the Directory field. The path cannot exceed 128
characters.
Step 6 Enter the username to use when logging into the remote server in the Username
field. A valid value for the username is 1 to 16 characters.
Step 7 In the Password field, enter the password for the username that you specified. A
valid password contains 1 to 16 characters.
Step 8 Enter the password again in the Confirm Password field.
Step 9 Choose one of the following Frequency ratio buttons within the Schedule settings:
Hourly: This enables the sensor to check for an update at the hourly interval that
you specify. If you select this option, enter a value from 1 to 8760 in the
Every___Hours field. For example, if you enter 5, every 5 hours the sensor
looks at the directory of files on the server. If there is an available update
candidate, it is downloaded and installed. Only one update is installed per cycle,
even if there are multiple available candidates. The sensor determines the latest
update that can be installed in a single step and installs that file.
Daily: This enables you to specify the days of the week on which updates are
performed. Check the check boxes for the day or days on which you want the
sensor to check for and download available updates.
Step 10 Enter, in 24-hour time, the time at which you want the updates to start in the Start
Time fields.
Note To remove your changes, click Reset. Reset refreshes the panel by replacing any edits that
you made with the previously configured value.
Step 11 Click Apply to apply your changes to the sensor and save them.

Software Update Guidelines
The following are guidelines for installing Cisco IPS

Sensor Software updates:
Obtain a service contract and a license for downloading signature
updates.
Obtain a Cisco.com password for accessing the Software Center.
Check Cisco.com regularly for the latest service packs and
signature updates.
Read the release notes to verify that the sensor meets the
requirements.
Download updates to an FTP, SCP, HTTP, or HTTPS server for
application to your sensor.
The following are guidelines for installing and deploying Cisco IPS Sensor Software updates:
Obtain a license for downloading signature updates.
Obtain a Cisco.com password for accessing the Software Center and downloading updates.
Check Cisco.com regularly for the latest signature updates and service packs. Signature
updates, which also contain Network Security Database (NSDB) updates, occur
approximately every two weeks, and service packs are made available as the product is
upgraded.
Read the release notes to determine if the sensor meets the requirements. The release notes
contain caveats and known issues that can arise when the update is installed.
Download update files to an FTP, SCP, HTTP, or HTTPS server on your network.
Signature update files and service pack files are the same for all of the sensor platforms.
Note It is strongly recommended that you download and apply all of the service pack updates as
they become available. You can find service packs, signature updates, readme files, and
other Cisco IPS Sensor Software updates in the Software Center on Cisco.com at
http://www.cisco.com/kobayashi/sw-center/ciscosecure/ids/crypto/.
Caution Never reboot the sensor during an installation process. Doing so will leave the sensor in an
unknown state and may require that the sensor be reimaged.
Password Recovery
This topic explains how to use the new password recovery feature in the various Cisco IPS
sensor products.
Password Recovery
Customers need a password recovery mechanism that is intuitive

and does not require the sensor to be reimaged.
Administrators may need to disable the feature for security
reasons (it is enabled by default).
Implementations vary due to individual platform requirements.
Password recovery is only implemented for the Cisco
administrative account. The Cisco IPS sensor administrator can
then recover other user passwords from the CLI.
The Cisco user password reverts to cisco and must be changed
after the next login.
For most Cisco IPS sensor platforms, you can now recover the password on the sensor rather
than using the service account or reimaging the sensor. This section describes how to recover
the password for the various Cisco IPS sensor platforms.

Password Recovery Platform Differences
Platform Description Recovery Method
Cisco 4200 Series Standalone IPS GRUB prompt

Sensor appliances
Cisco ASA Cisco ASA adaptive Cisco ASA adaptive security

AIP-SSM security appliance appliance CLI command
firewall IPS blades
Cisco Catalyst Switch IPS blades Download image

6500 Series
IDSM-2
Password recovery implementations vary according to Cisco IPS sensor platform requirements.
Password recovery is implemented only for the Cisco administrative account and is enabled by
default. The Cisco IPS sensor administrator can then recover user passwords for other accounts
using the CLI. The Cisco user password reverts to “cisco” and must be changed after the next
login.
Password Recovery: Cisco IPS 4200
Series Sensor
Password recovery
occurs from the
GRUB menu.
To use this menu, the Cisco IPS
user must have a Clear Password
direct serial (cisco)
connection to the
Cisco IPS 4200
Series Sensor.
The GRUB menu
appears during
bootup.
For the Cisco IPS 4200 Series Sensors, you can find password recovery in the GRUB menu,
which appears during bootup. When the GRUB menu appears, press any key to pause the boot
process.
Note You must have a terminal server or direct serial connection to the sensor to use the GRUB
menu to recover the password.
Follow these steps to recover the password on appliances:
Step 1 Reboot the appliance.
The following menu appears:

GNU GRUB version 0.94 (632K lower / 523264K upper memory)
-------------------------------------------
0: Cisco IPS
1: Cisco IPS Recovery
2: Cisco IPS Clear Password (cisco)
-------------------------------------------
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS, 'e' to edit the
commands before booting, or 'c' for a command-line.
Step 2 Press any key to pause the boot process.
Step 3 Choose 2: Cisco IPS Clear Password (cisco)
The password is reset to “cisco.” You can change the password the next time that you log into
the CLI.

Password Recovery: ROM Monitor
Prompt
The Cisco IPS 4240 and 4255 Sensors also support password
recovery from the ROM monitor CLI.
To access the ROM monitor CLI, reboot the sensor from a
console connection and interrupt the boot process by pressing the
Esc or Ctrl-R (terminal server) or send a Break command
(direct connection).
The ROM monitor commands to reset the password are:
– confreg=0x7
– boot
For the Cisco IPS 4240 and Cisco IDS 4250 XL Sensors, you can use the ROM monitor to
recover the password. To access the ROM monitor CLI, reboot the sensor from a terminal
server or direct connection and interrupt the boot process.
Follow these steps to recover the password using the ROM monitor CLI:
Step 1 Reboot the appliance.
Step 2 Interrupt the boot process by pressing Esc or Ctrl-R (terminal server) or send a
Break command (direct connection).
The boot code either pauses for 10 seconds or displays something similar to one of the
following:
Password: ********
Warning: Executing this command will apply a major version
upgrade to the application partition. The system may be
rebooted to complete the upgrade.
Step 3 Enter the following commands to reset the password:

confreg=0x7
boot
Password Recovery: Cisco ASA
AIP-SSM
ciscoasa(config)#
hw-module module slot_number password-reset
Password recovery is accomplished from the Cisco ASA 5500 Series

interface for the Cisco ASA AIP-SSM modules.
Use the hw-module module slot_number password-reset command to reset the Cisco
Adaptive Security Appliance Advanced Inspection and Prevention Security Services Module
(ASA AIP-SSM) password to the default of “cisco.” The Cisco ASA 5500 Series Adaptive
Security Appliance sets the ROM monitor configuration register bits to 0x7 and then reboots
the sensor. When the ROM monitor configuration register bits are set to 0x7, the GRUB menu
defaults to option 2 (clear password).
If the module in the specified slot has a Cisco IPS Sensor Software Version that does not
support password recovery, the following error message is displayed:
ERROR: the module in slot <n> does not support password recovery.
Note To recover the password on a Cisco ASA AIP-SSM, you must be running Cisco ASA
Software Version 8.0 or later.

Password Recovery: Cisco Catalyst 6500
Series IDSM-2
Password recovery is performed in the same manner as a system

image upgrade.
Download the password recovery file from Cisco.com.
Place the file on an FTP server.
From the switch CLI, boot to the recovery partition.
Session into the recovery partition, then login as guest with a
password of cisco.
Execute the upgrade command to install a new image.
Nothing is changed on the sensor except for the “cisco” account
password.
To recover the password for the Cisco Catalyst 6500 Series IDSM-2, you must perform a
system image upgrade, which installs a special password recovery image instead of a typical
system image. This upgrade resets only the password—all of the other configuration remains
intact. You must have administrative access to the Cisco Catalyst 6500 Series Switch to recover
the password. You boot to the maintenance partition and execute the upgrade command to
install a new image. Use the following commands:
For Cisco Catalyst operating system software:
— reset module_number cf:1
— session module_number
For Cisco IOS Software:
— hw-module module module_number reset cf:1
— session slot slot_number processor 1
The only program that you can use for this upgrades is FTP. Ensure that you put the password
recovery image file (WS-SVC-IDSM2-K9-a-5.2-password-recovery.bin.gz) on an FTP server.
Note For the full procedures, refer to Configuring the Cisco Intrusion Prevention System Sensor
Using the Command Line Interface 6.0: Upgrading, Downgrading, and Installing System
Images at
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_ch
apter09186a00807517ba.html#wp1121140.
Configuring Password Recovery
The host
component can
be configured to
allow or deny
password
recovery.
Allow
Use CLI or Password
Cisco IDM to Recovery
disable
password
recovery.
The ability to perform password recovery is enabled by default. You can disable this feature
using the CLI or Cisco IDM.
Follow these steps to disable password recovery from the CLI:

Step 1 Log into the CLI using an account with administrator privileges.
Step 2 Enter global configuration mode:

Step 3 Enter host mode:
sensor(config)# service host
Step 4 Disable password recovery:
sensor(config-hos)# password-recovery disallowed
Note If you try to recover the password on a sensor on which password recovery is disabled, the
process proceeds with no errors or warnings; however, the password is not reset.
Follow these steps to disable or enable password recovery using the Cisco IDM:
Step 2 Click Configuration and choose Sensor Setup > Network.
Step 3 To disable password recovery, uncheck the Allow Password Recovery check box.
To re-enable the password recovery feature, check the Allow Password Recovery
check box.

Password Recovery Troubleshooting
It is not possible to determine whether password recovery has

been disabled from the ROM monitor prompt, GRUB menu,
switch CLI, or router CLI. If password recovery is attempted, it
always appears to succeed even if the operation fails.
When performing password recovery on the Cisco Catalyst 6500
Series IDSM-2, you will see a message, “Upgrading will wipe out
the contents on the storage media.” This can be safely ignored.
If the Cisco ASA 5500 Series Adaptive Security Appliance
password recovery CLI command is not supported, the only way
to recover the password is to log in using the su - root command,
then execute the passwd cisco command, or reimage the
sensor.
To troubleshoot password recovery, pay attention to the following:

You cannot determine whether password recovery has been disabled in the sensor
configuration from the ROM monitor prompt, GRUB menu, switch CLI, or router CLI. If
password recovery is attempted, it always appears to succeed. If it has been disabled, the
password is not reset to “cisco.” The only option is to reimage the sensor.
You can disable password recovery in the host configuration, and the platforms that use
external mechanisms, such as ROM monitor and the maintenance partition for the Cisco
Catalyst 6500 Series IDSM-2. You will actually be able to run the commands to clear the
password, but if password recovery is disabled on the Cisco IPS sensor, the sensor detects
that password recovery is not allowed and rejects the external request.
When performing password recovery on a Cisco Catalyst 6500 Series IDSM-2, you see the
following message:
Continue with upgrade?: yes
You can ignore this message. Only the password is reset when you use the specified
password recovery image.
Use the show settings | include password command to verify that password recovery is
enabled. Follow these steps to verify that password recovery is enabled:
Step 1 Log into the CLI.

Step 2 Enter service host submode:
sensor (config)# service host
sensor (config-hos)#
Step 3 Enter show settings | include to verify the state of password recovery:
sensor(config-hos)# show settings | include password
password-recovery: allowed <defaulted>
sensor(config-hos)#

How to Restore a Cisco IPS Sensor
This topic explains how to use the Cisco IDM to reboot and shut down the sensor and restore
its default configuration.
Restoring the Default Configuration

Configuration
Restore Restore
Defaults Defaults
When you restore the default configuration of your sensor, your network settings are lost and
you are disconnected from the sensor.
Follow these steps to restore the default configuration of the sensor:
Step 1 Click Configuration and choose Restore Defaults. The Restore Defaults panel is
displayed.
Step 2 Click Restore Configuration Defaults to restore the default configuration. The
Restore Defaults window opens.
Step 3 Click Yes to begin the restore defaults process. An Information window displays the
following message:
Your connection to Sensor is closed. IDM will now exit.
Note From the CLI, enter erase current-config to reset the sensor back to its default.
Backing Up and Restoring
Configurations
sensor#
copy [/erase] source-url destination-url
Copies configuration files
sensor# copy current-config ftp://ip_address/file_name
Creates a backup configuration on an FTP server
sensor# copy /erase ftp://ip_address/file_name current-

config
Overwrites the current configuration with the backup

configuration
You can use the copy command to do any of the following:

Transfer a configuration to or from another host system using FTP or SCP
Copy IP log files to another host system
Note See the document Configuring the Cisco Intrusion Prevention System Sensor Using the
Command Line Interface 6.0 at
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_bo
ok09186a0080751759.html for the complete copy command syntax.
Follow these steps to back up and restore the configuration of the sensor:
Step 1 Enter the following command at the privileged EXEC prompt to save the current
configuration in a backup file:
sensor# copy current-config ftp://ip_address/file_name
Step 2 Choose one of the following:
Enter the following command to merge the backup configuration into the
current configuration:
sensor# copy ftp://ip_address/file_name current-config
Enter the following command to overwrite the current configuration with the
backup configuration:
sensor# copy /erase ftp://ip_address/file_name current-config

Summary
Summary
You must have a license to download signature updates.

You use the CLI upgrade command to apply the Cisco IPS
Sensor Software Version 6.0 major upgrade file and retain your
configuration. You can use the recovery image to recover the
sensor application image in case it becomes corrupt.
You must download an update to an FTP or SCP server for it to
be automatically applied.
The password recovery options reset the Cisco user account
password back to “cisco.”
You can use the Cisco IDM to restore the default configuration to
your sensor and to reboot or shut down your sensor.
Lesson 2
Managing Cisco IPS Sensors
Overview
This lesson provides information on how to monitor the health and welfare of your sensor.
There are a variety of tools that you can use to examine the status of your Cisco Intrusion
Prevention System (IPS) sensors, including the command-line interface (CLI), the Cisco IPS
Device Manager (IDM), the Cisco Security Manager, and Simple Network Management
Protocol (SNMP).
Objectives
Upon completing this lesson, you will be able use the CLI and the Cisco IDM to verify sensor
configuration. This ability includes being able to meet these objectives:
Explain the various CLI commands used for sensor monitoring
Describe the Cisco IDM as a tool to perform sensor monitoring
Describe Cisco Security Manager as a tool to perform sensor monitoring
Describe SNMP as a tool to perform sensor monitoring
Using the CLI to Monitor the Sensor
This topic explains how to use the CLI to display information about your sensor.
Obtaining Information About Your Cisco

IPS Sensor
You can use the sensor CLI to obtain the following

information about your sensor:
PEP information
Service statistics
Interface statistics
Details about traffic traversing an interface
Technical support information
The sensor CLI contains a number of commands that enable you to obtain valuable information
about your sensor and can be very useful for troubleshooting. These commands can provide the
Cisco Product Evolution Program (PEP) information
Service statistics
Interface statistics
Details about traffic traversing an interface
Technical support information
Displaying PEP Information
sensor#
show inventory
Displays Cisco PEP information for the sensor hardware
sensor# show inventory

NAME: "Chassis", DESCR: "Chasis-4240"
PID: 4240-515E , VID: V04, SN: 639156
Displays the product identifier, version identifier, and serial

number of the local Cisco IPS 4240 Sensor
Cisco devices, including intrusion prevention sensors, have a Unique Device Identifier (UDI)
that enables you to easily and efficiently manage certified hardware versions within your
network. These are characteristics of the UDI:
It is guaranteed to be unique for all Cisco devices.
It can be retrieved via the CLI or an SNMP MIB.
Methods of retrieving it are platform independent.
It includes product version traceability.
It is a deliverable of Cisco PEP, a new architecture baseline for all Cisco products.
It is made of up of the following three values:
— Product identifier (PID): This indicates a product that can be ordered by a
customer. These items are used by the customer, sales, customer service, Global
Product Services, and manufacturing to transact an order for a certain product. The
naming convention is alphanumeric.
— Version identifier (VID): This indicates the version of a product identifier. The
naming convention is a three-character field comprising the letter “v” followed by a
two-character number starting at 00 and incrementing until the product version
reaches 99. The “v” character may be uppercase or lowercase, for example, v03 or
V21.
— SN: This is the product serial number.
The UDI provides the following benefits:

Gives you the ability to electronically inventory Cisco products accurately and reliably
Simplifies product identification
Provides consistent product identification across products

The show inventory command can be used to display Cisco PEP UDI information. The output
of this command varies depending on the sensor platform. The following is an example of
show inventory command output:
sensor# show inventory
NAME: "Chassis", DESCR: "Chasis-4240"
PID: 4240-515E , VID: V04, SN: 639156
You can retrieve Cisco PEP information from a Cisco IPS sensor only if the Cisco PEP
information is stored in the sensor. This information is currently stored only in the Cisco IPS
4240 and 4255 Sensors. Therefore, the show inventory command is currently available only on
these sensors.
Displaying Service Statistics
sensor#
show statistics { analysis-engine | authentication |
denied-attackers | event-server | event-store| host |
logger | network-access | notification | sdee-server
| transaction-source |virtual-sensor [name]| web-
server } [ clear ]
Displays statistics for the specified option
sensor# show statistics authentication

General
totalAuthenticationAttempts = 9
failedAuthenticationAttempts = 0
Displays authentication statistics
Statistics provide a snapshot of the current internal state of sensor services; therefore, they can
be very useful for troubleshooting. You can use the show statistics command to display
statistics. The statistics content is specific to the service that provides it.
The syntax for the show statistics command is as follows:
show statistics { analysis-engine | authentication | denied-attackers | event-server | event-

store || host | logger | network-access | notification | sdee-server | transaction-source |
virtual-sensor [name]| web-server } [ clear ]

show statistics Parameters
analysis-engine Displays Analysis Engine statistics

authentication Displays authorization authentication statistics
denied-attackers Displays the list of denied IP addresses and the number of
packets from each attacker
event-server Displays event server statistics
event-store Displays Event Store statistics
host Displays host (main) statistics
logger Displays logger statistics
network-access Displays Attack Response Controller (ARC) statistics
notification Displays notification statistics
sdee-server Displays Security Device Event Exchange (SDEE) server
statistics
transaction-source Displays transaction source statistics
virtual-sensor Displays virtual sensor statistics
name Logical name for the virtual sensor
web-server Displays web server statistics
clear Clears statistics after they are retrieved
This option is not available for host or network access statistics.
Displaying Interface Statistics
sensor#
show interfaces {fastethernet | gigabitethernet |
management } [slot/port]
Displays statistics for system interfaces
sensor# show interfaces FastEthernet0/1
Displays statistics for the Fast Ethernet 0/1 interface
You can use the show interfaces command to display statistics for all sensor interfaces. You
can display statistics simultaneously for all interfaces or for all interfaces of a specified type.
You can also display statistics for a specific interface. The clear option clears statistics that can
be reset.
The syntax for the show interfaces commands is as follows:
show interfaces {fastethernet | gigabitethernet | management } [slot/port]
show interfaces [clear]
show interface Parameters
fastethernet This parameter displays the statistics for the Fast Ethernet
interfaces.
gigabitethernet This parameter displays the statistics for the Gigabit Ethernet
interfaces.
management This parameter displays the statistics for the management

interfaces. Only platforms with external ports marked “MGMT”
support this keyword. The management interface for the
remaining platforms is displayed in the show interfaces output
based on the interface type.
slot/port Refer to the appropriate hardware manual for slot and port
information.
clear This parameter clears statistics that can be reset.

The following example shows how to display statistics for a specific Fast Ethernet interface:
Sensor1# show interfaces FastEthernet0/1
MAC statistics from interface FastEthernet0/1
Media Type = TX
Missed Packet Percentage = 0
Inline Mode = Paired with interface FastEthernet1/0
Pair Status = Up
Link Status = Up
Link Speed = Auto_10
Link Duplex = Auto_Half
Total Packets Received = 9513
Total Bytes Received = 863646
Total Multicast Packets Received = 0
Total Broadcast Packets Received = 0
Total Jumbo Packets Received = 0
Total Undersize Packets Received = 0
Total Receive Errors = 0
Total Receive FIFO Overruns = 0
Total Packets Transmitted = 9872
Total Bytes Transmitted = 994518
Total Multicast Packets Transmitted = 0
Total Broadcast Packets Transmitted = 0
Total Jumbo Packets Transmitted = 0
Total Undersize Packets Transmitted = 0
Total Transmit Errors = 0
Total Transmit FIFO Overruns = 0
Displaying Learned Operating Systems
sensor#
show os-identification [name] learned [ip-address]
Displays operating system IDs associated with IP

addresses learned through passive analysis
sensor1# show os-identification learned

Virtual Sensor vs0:
10.1.1.12 windows
Virtual Sensor vs1:
10.1.0.1 unix
10.1.0.2 windows
10.1.0.3 windows
To display operating system IDs associated with the IP addresses learned by the sensor through
passive analysis, use the show os-identification command in privileged EXEC mode. The
syntax for the show os-identification command is show os-identification [name] learned [ip-
address].
Note You must be an administrator, operator, or viewer to run this command.
show os-identification Parameters
name (Optional) This is the name of the virtual sensor configured on the
sensor. The show operation is restricted to learned IP addresses
associated with the identified virtual sensor.
ip-address (Optional) This is the IP address to query. The sensor reports the
operating system mapped to the specified IP address.
If you specify the name of a virtual sensor, only the operating system ID for the specified
virtual sensor is displayed; otherwise, the learned operating system ID for all virtual sensors are
displayed. If you specify an IP address without a virtual sensor, the output displays all virtual
sensors containing the requested IP address.
The following example displays the operating system ID for a specific IP address:
sensor# show os-identification learned 10.1.1.12
Virtual Sensor vs0:
10.1.1.12 windows
The following example displays the operating system ID for all of the virtual sensors:

sensor# show os-identification learned
Virtual Sensor vs0:
10.1.1.12 windows
Virtual Sensor vs1:
10.1.0.1 unix
10.1.0.2 windows
10.1.0.3 windows
Displaying Anomaly Detection
Knowledge Base
sensor#
show ad-knowledge-base virtual-sensor files
Displays the anomaly detection files available

for a virtual sensor
sensor# show ad-knowledge-base files

Virtual Sensor vs0
Filename Size Created
initial 84 04:27:07 CDT Wed Jan 28
2007
* 2006-Jan-29-10_00_01 84 04:27:07 CDT Wed Jan 29
2007
2006-Mar-17-10_00_00 84 10:00:00 CDT Fri Mar 17
2007
2006-Mar-18-10_00_00 84 10:00:00 CDT Sat Mar 18
2007
Use the show ad-knowledge-base command to display the anomaly detection knowledge base
files available for a virtual sensor. The syntax for the command is show ad-knowledge-base
virtual-sensor files.
Note You must be an administrator, operator, or viewer to run this command.
show ad-knowledge-base Parameter
virtual-sensor (Optional) This is the virtual sensor containing the knowledge

base file. This is a case-sensitive character string containing 1 to
64 characters. Valid characters are A–Z, a–z, 0–9, “-” and “_”.
The following example displays the knowledge base files available for all of the virtual sensors.
The file 2007-Mar-16-10_00_00 is the current knowledge base file loaded for virtual sensor
vs0.
sensor# show ad-knowledge-base files
Virtual Sensor vs0
Filename Size Created
initial 84 04:27:07 CDT Wed Jan 28 2007
* 2006-Jan-29-10_00_01 84 04:27:07 CDT Wed Jan 29 2007
2006-Mar-17-10_00_00 84 10:00:00 CDT Fri Mar 17 2007
2006-Mar-18-10_00_00 84 10:00:00 CDT Sat Mar 18 2007

The asterisk (*) before the filename indicates that the knowledge base file is currently loaded.
The current knowledge base always exists (it is the initial knowledge base after installation). It
shows the currently loaded knowledge base in the anomaly detection, or the one that is loaded
if anomaly detection is not currently active.
If you do not provide the name of the virtual sensor, the knowledge base files are displayed for
all of the virtual sensors.
Note The initial knowledge base has factory-configured thresholds.
Displaying Technical Support
Information
sensor#
show tech-support[page][password][destination-url
destination-url]
Displays the current system status
sensor# show tech-support destination-url

ftp://ipsuser@10.2.1.2/reports/sensor1Report.html
Places the technical support output in the file

~ipsuser/reports/sensor1Report.html
The show tech-support command captures all status and configuration information on the
sensor. The command allows the information to be transferred to a remote system. The output
includes HTML-linked output from the following commands and can be very large:
show interfaces
show statistics network-access
cidDump
The cidDump command captures a large amount of information, including the process list, log
files, operating system information, directory listings, package information, and configuration
files. This information is needed by developers to troubleshoot problems.
The syntax for the show tech-support command is as follows:
show tech-support [page][password][destination-url destination-url]

show tech-support Parameters
page (Optional) This parameter causes the output to display one page
of information at a time. Use the Enter key to display the next line
of output or use the Spacebar to display the next page of
information. If page is not used, the output is displayed without
page breaks.
password (Optional) This parameter leaves passwords and other security

information in the output. If password is not used, passwords
and other security-sensitive information in the output are replaced
with the label ”removed” by default.
destination-url (Optional) This is the tag indicating the information should be

formatted as HTML and sent to the destination following this tag.
destination-url (Optional) This is the destination for the report file. If a URL is
provided, the output will be formatted as an HTML file and sent to
the specified destination; otherwise the output is displayed on the
screen.
The exact format of the destination URL varies according to the file. You can select a filename,
but it must be terminated by .html.
You can specify the following destination types:

ftp: This is the destination URL for the FTP network server. The syntax for this prefix is as
follows: ftp:[[//username@location]/relativeDirectory]/filename or
ftp:[[//username@location]//absoluteDirectory]/filename
scp: This is the destination URL for the SCP network server. The syntax for this prefix is
as follows: scp:[[//username@]location]/relativeDirectory]/filename or
scp:[[//username@]location]//absoluteDirectory
Using the Cisco IDM to Monitor the Sensor
This topic explains how to use the Cisco IDM to run a diagnostics report and view statistics and
system information.
Running a Diagnostics Report
Support
Information Monitoring
Generate
Diagnostics Report
Report
You can obtain diagnostics information about your sensors for troubleshooting purposes by
running a diagnostics report. Complete the following steps to run a diagnostics report.
Caution After you start the diagnostics process, do not click any other options in the Cisco IDM or
leave the Diagnostics panel. This process must run to completion before you attempt to
perform any other tasks for the sensor.
Step 1 Click Monitoring and choose Support Information > Diagnostics Report. The
Diagnostics Report panel is displayed.
Step 2 Click Generate Report. The diagnostics process begins and may continue for
several minutes. When the process is complete, a report is generated and the display
is refreshed with the updated report.
Note To save the report as a file, view the report in your browser and choose File > Save As.

Viewing Statistics
Monitoring
Support
Information
Statistics
Refresh
The Statistics panel shows statistics for the following:

Analysis Engine
Event Server
Event Store
Host
Interface Configuration
Logger
Network Access
Notification
Transaction Server
Transaction Source
Web Server
To display statistics for your sensor, complete the following steps:
Step 1 Click Monitoring and choose Support Information > Statistics. The Statistics
page is displayed.
Step 2 To update statistics as they change, click Refresh. Refresh displays the latest
information about the sensor applications.
Viewing System Information
Monitoring
Support
Information
System
Information
Refresh
The System Information panel displays the following information:

Cisco Technical Assistance Center (TAC) contact information
Type of sensor
Software version
Status of applications
Upgrades installed
Cisco PEP information
Complete the following steps to view system information:
Step 1 Click Monitoring and choose Support Information > System Information.
Step 2 The System Information panel displays information about the system.
Step 3 Click Refresh. The panel refreshes and displays new information.

Monitoring Using Cisco Security Manager
This topic describes how to use Cisco Security Manager to monitor a Cisco IPS sensor.
Monitoring Using Cisco Security

Manager
Cisco Security Manager is a powerful but very easy-to-use solution to centrally provision all
aspects of device configurations and security policies for Cisco firewalls, Cisco virtual private
networks (VPNs), and Cisco IPS sensors. The solution is effective for managing even small
networks consisting of fewer than 10 devices, but also scales to efficiently manage large-scale
networks composed of thousands of devices. Scalability is achieved through intelligent policy-
based management techniques that can simplify administration.
Note Cisco Security Manager Version 3.1 or later is required to install or configure Cisco IPS
Monitoring Using SNMP
This topic describes how to use SNMP as a tool to perform sensor monitoring.
Configuring SNMP Monitoring
Configuration
Enable SNMP
Gets/Sets
Read-only
Community
String
SNMP: General Sensor Agent Port

Configuration
Sensor
Agent
Protocol
Apply
Reset
You can configure the sensor for monitoring by SNMP, an application layer protocol that
facilitates the exchange of management information among network devices. SNMP enables
you to manage network performance, find and solve network problems, and plan for network
growth.
SNMP is a simple request and response protocol. An SNMP network management system
(NMS) issues a request, and managed devices return responses. This behavior is implemented
by using one of the following protocol operations: Get, GetNext, Set, and Trap. Cisco IPS
Sensor Software Version 6.0 currently implements the Get and Set SNMP operations. The Get
operation is used by the NMS to retrieve information from an Agent. The Set operation is used
by the manager to set the values of object instances within an Agent.
Complete the following steps to configure the sensor so that it can be monitored by SNMP:
Step 1 Click Configuration and choose SNMP > SNMP General Configuration. The
SNMP General Configuration panel is displayed.
Step 2 Check the Enable SNMP Gets/Sets check box to enable SNMP so that the SNMP
NMS can issue requests to the sensor SNMP agent.
Step 3 Complete the following substeps to configure the SNMP Agent Parameters, which
are the values that the NMS can request from the sensor SNMP agent.
1. Enter the read-only community string in the Read-Only Community String field.
This entry identifies the community string for read-only access.
2. Enter the read-write community string in the Read-Write Community String

field. This entry identifies the community string for read and write access.

Note The management workstation sends SNMP requests to the sensor SNMP agent, which
resides on the sensor. If the management workstation issues a request and the community
string does not match what is on the senor, the sensor rejects it.
3. Enter the sensor contact user ID in the Sensor Contact field. The sensor contact
identifies the point of contact for the sensor.
4. Enter the location of the sensor in the Sensor Location field.
5. Enter the sensor port for its SNMP agent in the Sensor Agent Port field. This
entry identifies the sensor IP port. The default SNMP port number is 161.
6. From the Sensor Agent Protocol drop-down menu, choose the protocol that the
sensor SNMP agent will use. The Sensor Agent Protocol identifies the sensor
protocol. The default protocol is User Datagram Protocol (UDP).
Note If you want to undo your changes, click Reset. Reset refreshes the panel by replacing any
edits that you made with the previously configured value.
Summary
Summary
The CLI contains the following useful troubleshooting commands:

– show statistics: Provides a snapshot of the current internal state of
sensor services
– show interfaces: Provides statistics for sensor interfaces
– packet: Captures or displays live traffic on an interface
– show tech-support: Captures all status and configuration information on
the sensor
The Cisco IDM enables you to monitor your sensor as follows:
– Run a diagnostics report
– View statistics for sensor services
– View Cisco TAC contact information and system information, such as the
type of sensor, software version, upgrades installed, Cisco PEP
information
The Cisco Security Manager can be used to manage a Cisco IPS sensor.
You can configure your sensor to be monitored by SNMP.

Module Summary
Module Summary
The CLI upgrade command applies the Cisco IPS Sensor

Software Version 6.0 major upgrade file and retains your
configuration. You must have a license to download signature
updates.
The CLI contains these commands, which are useful
troubleshooting commands: show statistics, show interfaces,
packet, and show tech-support. The Cisco IDM enables you to
run a diagnostics report, view statistics for sensor services, and
view Cisco TAC contact information and system information.
You can accomplish most of the maintenance of the Cisco Intrusion Prevention System (IPS)
sensor using the Cisco IPS Device Manager (IDM). The command-line interface (CLI), Cisco
Security Manager, and Simple Network Management Protocol (SNMP) are also tools that can
help you manage the Cisco IPS sensors.
References
Cisco Systems, Inc., Cisco Intrusion Prevention System Command Reference 6.0.
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_command_reference_
book09186a00807a874d.html.
Cisco Systems, Inc., Configuring the Cisco Intrusion Prevention System Sensor Using the
Command Line Interface 6.0: Upgrading, Downgrading, and Installing System Images.
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_
chapter09186a00807517ba.html#wp1121140.
Cisco Systems, Inc., Configuring the Cisco Intrusion Prevention System Sensor Using the
Command Line Interface 6.0.
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_
book09186a0080751759.html.

IPS60StudentGuide Vol2 UnEncrypted

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IPS60StudentGuide Vol2 UnEncrypted

Uploaded by

Copyright:

Available Formats

IPS

Advanced Cisco IPS

Performing Advanced Tuning

Tuning is the process of

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-2

 To tune sensors successfully, you must have a good

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-3

© 2007 Cisco Systems, Inc. Advanced Cisco IPS Configuration 4-5

Important information to gather before you begin tuning:

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-4

Outside of Firewall? Inside of Firewall?

The location of the sensor is important when tuning

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-5

Traffic inspected by a sensor outside a firewall tends to be unregulated. Sensors monitoring

© 2007 Cisco Systems, Inc. Advanced Cisco IPS Configuration 4-7

These phases of tuning correspond to the length of time

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-6

Some tuning methods involve configuring the sensor

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-7

Methods of tuning include the following:

© 2007 Cisco Systems, Inc. Advanced Cisco IPS Configuration 4-9

 There are guidelines to help you maximize the efficiency of your

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-8

 IP logs are generated in two ways:

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-9

IP logs are generated in two ways:

© 2007 Cisco Systems, Inc. Advanced Cisco IPS Configuration 4-11

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-10

To log IP traffic for a particular host, follow these steps:

Step 1 Click the Monitoring button.

Step 3 Click Add. The Add IP Logging window opens.

© 2007 Cisco Systems, Inc. Advanced Cisco IPS Configuration 4-13

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-11

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-12

Complete the following steps to view IP logs:

© 2007 Cisco Systems, Inc. Advanced Cisco IPS Configuration 4-15

Max IP Log Bytes IP Log Time

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-13

To configure IP logging parameters, follow these steps:

The Miscellaneous tab appears.

A valid value is 1 to 60 minutes. The default is 30 minutes.

 You can configure sensor reassembly settings for both IP

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-14

© 2007 Cisco Systems, Inc. Advanced Cisco IPS Configuration 4-17

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-15

Step 2 Choose Signature Definitions from the table of contents.

Step 3 Click sig0.

Complete the following steps to configure TCP stream reassembly options:

Step 1 Click the Configuration button.

Step 2 Choose Signature Definitions from the table of contents.

Step 3 Click sig0.

Note To remove your changes, click Reset.

© 2007 Cisco Systems, Inc. Advanced Cisco IPS Configuration 4-19

Configuring Event Variables

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-16

Complete the following steps to create an event variable:

Step 2 Choose Event Action Rules from the table of contents.

Step 3 Click rules0.

Step 5 Click Add. The Add Variable window opens.

© 2007 Cisco Systems, Inc. All rights reserved. IPS v6.0—4-17

Note The Type drop-down menu identifies the variable as an address.

© 2007 Cisco Systems, Inc. Advanced Cisco IPS Configuration 4-21

To tune sensors successfully, you must have a good

There are guidelines to help you maximize the efficiency of your

IP logs are generated in two ways:

You can configure sensor reassembly settings for both IP

The risk rating is associated with alerts not signatures.

Attack Severity Rating

ASR is configured on a per-signature basis and indicates how

TVRs are configured in event action rules:

SFRs are configured on a per-signature basis.

The ARR is a derived value. It is not configurable.

PD is configured on a per-signature basis.

The risk rating is calculated by the following formula:

Valid numbers are from 0–100.