Configuring Cisco IPS Signatures and Alerts

Overview
This lesson introduces the location and configuration of the built-in signatures in the
Cisco Intrusion Prevention System (IPS) sensor products. You will be able to find
individual signatures and classes of signatures, and then enable or disable them.
You will also learn how to configure the actions that you would like the sensor to
take

Objectives
Upon completing this lesson, you will be able to use the Cisco IPS Device Manager
(IDM) to configure built-in signatures to meet the requirements of a given security
policy. This ability includes being able to meet these objectives:
 Describe the different types, features, and actions of signatures
 Locate information about specific signatures and describe the Cisco Intrusion
Prevention Alert Center
 Enable, disable, and assign actions to signatures
 Configure additional settings for denying and blocking actions
Cisco IPS Signatures
This topic highlights the features and capabilities of Cisco IPS signatures.

A signature is a set of rules that your sensor uses to detect typical intrusive activity,
such as denial of service (DoS) attacks. As sensors scan network packets, they use
signatures to detect known attacks and respond with actions that you define. The
sensor compares its signatures with network activity. When a match is found, the
sensor can generate an alert event and store it in the Event Store. The alert events,
as well as other events, can be retrieved from the Event Store by web-based
clients.

Note By default, the sensor generates an alert when a signature matches network traffic.
You can disable alert generation for any signature.

A signature must be enabled to monitor network traffic. The most critical signatures
are enabled by default.
Cisco IPS Sensor Software Version 6.0 contains more than 1500 built-in default
signatures. You cannot rename or delete signatures from the list of built-in
signatures, but you can retire signatures that are old or no longer applicable from
the sensing engine. Retiring signatures conserves sensor memory and enhances
performance. If you retire a signature, that signature is removed from the engine but
remains in the signature configuration list. You can later activate retired signatures,
but doing so requires the sensor to rebuild its configurations. This rebuild can be
time consuming and can cause a delay in the processing of traffic.
You can also modify built-in signatures by adjusting their parameters. These
modified built-in signatures are called tuned signatures. In addition, you can create
signatures, which are called custom signatures. Custom signature IDs begin at
60,000.

Some signatures have subsignatures, meaning that the signature is divided into
subcategories. When you configure a subsignature, changes made to the
parameters of one subsignature apply only to that subsignature. For example, if
you edit signature 3050 subsignature 1, the change applies only to subsignature
1 and not to signature 3050 subsignature 2, signature 3050 subsignature 3, and
signature 3050 subsignature 4.

The Cisco IPS signatures have the following features and capabilities.
 Response actions: These enable the sensor to take an action when the
signature is triggered.
 Alert summarization: This enables the sensor to group various alerts into a
single alert, thereby decreasing the number of alerts that the sensor sends to
the Event Store when a signature is triggered.
 Threshold configuration: This enables a signature to be tuned to perform
optimally in a network.
 Anti-evasive techniques: These enable a signature to defeat evasive
techniques used by an attacker.
 Fidelity rating: This is a numerical rating of how prone the signature is to false
alarms.
 Application firewall: This provides Layer 4 to Layer 7 packet inspection to
prevent malicious attacks related to HTTP and FTP.
 Simple Network Management Protocol (SNMP) support: This enables the
sensor to send SNMP traps triggered by IPS alert, status, or error events.
 IP version 6 (IPv6) support: This enables signatures to analyze IP version 4
(IPv4) encapsulated in IPv6 to the same extent as IPv4 traffic is analyzed.

Note Cisco IPS Sensor Software Version 6.0 allows IPv6 traffic to pass unobstructed with
no analysis.
 Use of a blend of the following technologies:
Simple pattern matching: This looks for a character string in a single
packet. For example, the signature might look for the string badger.
Stateful pattern matching: This enables string reconstruction. For
example, a Telnet session in which bad and ger were sent in two
separate packets would match the string badger.
Heuristic analysis: This uses some form of algorithmic logic to determine
if an alert should be generated. Heuristic analysis usually involves some
form of statistical analysis. It is typically used to detect reconnaissance
attempts, such as slow scans that attempt to evade sensor detection. A
good example of a signature based on heuristic analysis is one used to
detect a port sweep. The signature looks for the presence of a threshold
number of unique ports being accessed on a particular machine. You can
further restrict the signature to look only for a certain type of packet or a
certain source address. Signatures of this type require some threshold
manipulations to make them conform to the utilization patterns on the
network that they are monitoring.
Protocol decode analysis: This looks for deviations from a standard protocol,
as defined by the RFC.
Anomaly analysis: This looks for network traffic that deviates from the
traffic that it normally detects on the network. The biggest problem with
this methodology is defining normal traffic. There are several types of
anomaly analysis. Cisco signatures use the following:
 Protocol anomalies: An example of a protocol anomaly would be an
unexpected value in a field of a protocol. This method is closely
related to the protocol decode method. In some instances, the lines
blur between methodologies.
 Statistical anomalies: An example of a statistical anomaly would be
a significant difference in the current rate of traffic arrival as compared
to a historical reference. This methodology detects traffic floods, such
as User Datagram Protocol (UDP), TCP, or Internet Control Message
Protocol (ICMP) floods.
 Regular expression string pattern matching: This capability enables the
creation of string patterns using regular expressions. These string patterns are
used by the pattern matching technologies.
You can configure the sensor to respond to malicious activity by configuring a
signature to take a response action when it matches network traffic.
Some of the actions that a sensor can take when a signature is triggered are
specific to inline IPS. The capability to drop packets as a response action is the
essence of an inline solution. For a sensor operating in inline mode, you can
configure deny actions that drop packets, including the packet that triggers the
signature, before they reach their intended target. You can configure signatures to
take the following actions, whether your sensor is running in inline mode,
promiscuous mode, or both:
 Produce an alert or an alert that includes an encoded dump of the trigger
packet
 Log IP packets that contain the attacker address, the victim address, or both
 Initiate the blocking of a connection or a specific host address
 Send a request to the notification application component of the sensor to
perform SNMP notification
 Terminate the TCP session between the source of an attack and the target
host
The notification application is a sensor service that enables the sensor to send
notification of sensor alerts and system errors to an SNMP network management
system (NMS). These SNMP notifications are called traps. In addition to enabling
the sending of traps, the notification application enables an NMS to obtain basic
health information from the sensor. SNMP is used by many network administrators
to monitor and configure network devices. The SNMP support available in Cisco
IPS Sensor Software Version 6.0 and higher enables these administrators to
consolidate data into a single console.
The notification application runs as a thread within MainApp and uses the Net-
SNMP agent, a public domain SNMP agent, to collect and store information about
the sensor, translate the information into a form that is compatible with SNMP, and
deliver it to an NMS via SNMP. Although the Net-SNMP agent currently supports
SNMP version 3 (SNMPv3), the notification application currently does not.

Regular expressions constitute a powerful and flexible notational language that

allows you to describe text. In the context of pattern matching, regular expressions
allow a succinct description of almost any arbitrary pattern.
Regular expressions are used for string matching. Regular expressions are strings
that contain a mix of plaintext and special characters to indicate what kind of
matching to do. For example, if you want the sensor to look for a numeric digit, use
the regular expression [0-9]. The brackets indicate that the character being
compared should match any one of the characters enclosed within the brackets.
The dash (-) between 0 and 9 indicates that it is a range from 0 to 9. Therefore, this
regular expression matches any digit from 0 to 9.
To have the sensor search for a specific special character, you must use a
backslash before the special character. For example, the single-character regular
expression \* matches a single asterisk.
The regular expressions defined in this section are similar to a subset of the
Portable Operating System Interface (POSIX) extended regular expression
definitions. In particular, [..], [==], and [::] expressions are not supported. Escaped
expressions representing single characters are supported. The following table lists
the Cisco IPS regular expressions syntax.
Regular Expression Syntax

Character Description

^ This is the beginning of the string. The expression ^A will match an "A" only at
the beginning of the string.

^ This is immediately following the left bracket ([) and excludes the remaining
characters within brackets from matching the target string. The expression [^0-9]
indicates that the target character should not be a digit.

$ This matches the end of the string. The expression abc$ matches the substring
abc only if it is at the end of the string.

| This allows the expression on either side to match the target string. The
expression a|b matches "a" as well as "b."

. This matches any character.

* This indicates that the character to the left of the asterisk in the expression
should match zero or more times.

+ This is similar to the asterisk (*) but there must be at least one match of the
character to the left of the plus sign (+) in the expression.

? This matches the character to its left zero or one time.

() This affects the order of pattern evaluation and serves as a tagged expression
that can be used when replacing the matched substring with another expression.

[] This encloses a set of characters and indicates that any of the enclosed
characters can match the target character.

\ This allows for specifying a character that would otherwise be interpreted as

special.
\xHH represents the character whose value is the same as the value
represented by (HH) hexadecimal digits [0-9A-Fa-f]. The value must not be zero.
BEL is the same as \x07; BS is \x08; FF is \x0C; LF is \x0A; CR is \x0D; TAB is
\x09; and VT is \x0B.
For any other character `c', `\c' is the same as `c' except that it is never
interpreted as special.

The following provides examples of the special characters:

 a* matches any number of occurrences of the letter a, including none.
 a+ requires that at least one letter a be in the string to be matched.
 ba?b matches the string bb or bab.
 \** matches any number of asterisks (*).
To use multipliers with multiple-character patterns, you enclose the pattern in
parentheses.
(ab)* matches any number of the multiple-character string ab.
([A-Za-z][0-9])+ matches one or more instances of alphanumeric pairs but not none.
An empty string is not a match. The order for matches using multipliers (*, +, or ?) is
to put the longest construct first. Nested constructs are matched from outside to
inside. Concatenated constructs are matched beginning at the left side of the
construct. Thus, the regular expression matches A9b3 but not 9Ab3 because the
letters are specified before the numbers.
You can also use parentheses around a single- or multiple-character pattern to
instruct the software to remember a pattern for use elsewhere in the regular
expression. To create a regular expression that recalls a previous pattern, you use
parentheses to indicate memory of a specific pattern and a backslash (\) followed
by a digit to reuse the remembered pattern. The digit specifies the occurrence of a
parenthesis in the regular expression pattern. If you have more than one
remembered pattern in your regular expression, then \1 indicates the first
remembered pattern, and \2 indicates the second remembered pattern, and so on.
The regular expression a(.)bc(.)\1\2 uses parentheses for recall. It matches an
a followed by any character, followed by bc followed by any character, followed by
the first any character again, followed by the second any character again. For
example, the regular expression can match aZbcTZT. The software remembers that
the first character is Z and the second character is T and then uses Z and T again
later in the regular expression.

The following table shows examples of regular expression patterns:

Regular Expression Pattern Examples

To Match Regular Expression

Hacker Hacker

Hacker or hacker [Hh]acker

Variations of bananas, banananas, banananananas Ba(na)+s

Either hot or cold hot|cold

Either moon or soon (m|s)oon

A signature engine is a component of the sensor that supports a category of

signatures. Each Cisco IPS signature is created and controlled by a signature
engine specifically designed for the type of traffic being monitored. For example, the
string TCP engine searches TCP packets for string patterns. It controls such
signatures as the following:
 Signature 3118, rwhoisd format string, which triggers upon detecting
an soa command sent to a rwhois server with a large argument
 Signature 3138, Bagle.C virus email attachment, which fires when a pattern
matching the C variant of the Bagle virus in an e-mail attachment is detected
An engine is composed of a parser and an inspector. Each engine has a set of legal
parameters that have allowable ranges or sets of values. These configurable
engine parameters enable you to tune signatures to work optimally in your network
and to create new signatures unique to your network environment.
By default, the sensor generates an alert when an enabled signature is triggered.
Generating an alert, however, is a configurable signature action that can be
disabled. Alerts are stored in the sensor Event Store. The Cisco IDM can pull alerts
from the sensor via the Security Device Event Exchange (SDEE). This capability
allows a host or hosts to collect alerts on an as-needed basis.
SDEE specifies two types of event requests for external monitoring applications
such as Cisco IDM interfacing with the sensor:
 Query: Retrieve events that are in the Event Store at the time the query
request is issued
 Subscription: Establish a live feed

Note Multiple hosts can perform queries and subscribe to the live event feed
simultaneously.

Every alert has a severity level that is derived from the severity level of the
signature causing the alert. Therefore, an alert, and a signature, can have one of
the following security levels:
 Informational
 Low
 Medium
 High
At times, you may need to look at an alert via the command-line interface
(CLI) show events command. In the output of this command, you can distinguish
an alert from other types of events by its first field, evIdsAlert. The format of an alert
as it appears in the CLI conforms to the Cisco Intrusion Detection Event Exchange
standards. SDEE is a general-purpose standard for the messaging of security
events. SDEE, along with the Cisco Intrusion Detection Event Exchange, specifies
the format of event messages.

Note The Cisco Intrusion Detection Event Exchange extends the SDEE and
adds IPS-specific elements that are used in Cisco IPS Sensor Software
Version 6.0 alerts.

The following is an example of a Cisco IPS Sensor Software Version 6.0 alert from
signature 2004, ICMP Echo Req:
evIdsAlert: eventId=1104949863483006238 severity=informational
vendor=Cisco
originator:
hostId: sensor1
appName: sensorApp
appInstanceId: 375
time: 2006/12/27 14:15:38 2006/12/27 06:15:38 GMT-08:00
signature: description=ICMP Echo Req id=2004 version=S1
subsigId: 0
marsCategory: Info/AllSession
interfaceGroup: vs0
vlan: 0
participants:
attacker:
addr: locality=OUT 10.0.1.12
target:
addr: locality=OUT 172.26.26.50
os: idSource=unknown relevance=relevant type=unknown
riskRatingValue: attackRelevanceRating=relevant
targetValueRating=medium 35
threatRatingValue: 35
interface fe0/1
protocol icmp

The information in Cisco IPS alerts is labeled intuitively. For example, the signature:
description and eventID fields obviously contain the name and identification number
of the signature. The following list provides additional details and information on
some of the less intuitive fields, listed as they will appear on your screen:
 vendor: This is always Cisco for Cisco products. This field is included in SDEE
format because vendors other than Cisco use SDEE.
 originator: This contains the following subfields that provide information on the
originator of the alert:
hostId: Name of the sensor that originated the alert
appName: Name of the application that originated the alert
appInstanceId: Numerical value that uniquely identifies this instance of
the application that originated the alert
 marsCategory: This is the category of event to be used by Cisco Security
Monitoring, Analysis, and Response System (MARS).
 interfaceGroup: This is the name of the interface group that received the
traffic.

 vlan: This is the VLAN number associated with packets involved in the
activity that triggered the alert. If this field is omitted or the value is 0, no VLAN
information is available.
 participants: This contains the following subfields providing information about
hosts that participated in the attack, either as attackers or targets:
- attacker: Host or hosts involved in attacking each of the target hosts
  addr: locality: This is the IP address of the attacker and where this
address is located. The locality subfield is a string that indicates the
relative location of the attacker address within the network topology. It
indicates, for example, whether the host is within the protected
network, the demilitarized zone (DMZ), or the external (unprotected)
network. The locality subfield displays a single locality per address. If
the address matches many localities, the most specific match is
displayed. For example, if the address matches both IN and DMZ1,
DMZ1 is displayed.

Note Locality names such as IN and DMZ1 come from event variables that
you define. You can create event variables and then use those variables
in event action filters. Event variables enable you to use the same value
within multiple filters.

target: Host or hosts that are the target of an attack by each of the
attackers
 addr: locality: This is the IP address of the target host and where this
address is located. The locality subfield is a string that indicates the
relative location of the target address within the network topology. It
indicates, for example, whether the host is within the protected
network, the DMZ, or the external (unprotected) network. The locality
subfield displays a single locality per address. If the address matches
many localities, the most specific match is displayed. For example, if
the address matches both IN and DMZ1, DMZ1 is displayed.
 os: This is the operating system of the target host.

Note Base 64 is a method of encoding arbitrary data as plain ASCII text.

 riskRatingValue: This is the value that represents the calculated risk

associated with the detected activity. The risk value is calculated using multiple
factors and has a range between 0 and 100 (inclusive), where 0 represents the
lowest risk and 100 the greatest risk.
 threatRatingValue: This is the value that represents the calculated threat
associated with the detected activity. The threat value is calculated using
multiple factors and has a range between 0 and 100 (inclusive), where 0
represents the lowest threat and 100 the greatest threat.
 interface: This provides traffic source information. The Interface field holds a
simple value such as fe1_0.
 protocol: This is the network protocol wherein the malicious content was
discovered.
How to Locate Signature Information
This topic explains how to locate information about specific signatures and
describes the Cisco Intrusion Prevention Alert Center.

Up-to-the-minute signature and attack information is available at the Cisco

Security Center, which provides information on emerging threats and quick
access to the latest signatures. The Intelligence Reports section of the Cisco
Security Center contains information about new malicious Internet activity. It
provides the names of the most recent threats along with the date, severity
level, and status of each threat, and a link to other sources of information about
the various threats.
The figure shows an example of the Signature Details page that displays when you
click the name of a related signature from the Cisco Security Center page. A typical
page contains the following information fields about a signature:
 Signature Name: The name of the signature
 Signature ID: A unique identification number for the signature
 Alarm Severity: The default alarm severity level assigned to the signature
 Release Version: The signature update in which the signature was released
 Release Date: The date on which the signature update was released
 Signature Description: A concise description of the signature
 Benign Triggers: An explanation of any false positives that may appear to be
exploits, but are actually normal network activity
 Related Security Reports: Links to intelligence reports that offer additional
insight regarding the vulnerability and its consequences

Note A valid Cisco.com account is required to view the threat details.

If you click on the name of one of the latest or active threats listed in the Example
Recent IntelliShield Alerts section of the Cisco Security Center main page, you are
taken to a page that provides more information about the threat:
 The date the threat was discovered
 A concise description
 The damage that the threat can impose
 A description of what can be done to protect systems from the threat
 A list of operating systems that can be affected by the threat and links to
patches for each operating system
 A list of software that can be affected by the threat
How to Configure Basic Signatures
This topic explains how to enable, disable, retire, activate, and assign actions to
signatures.

By default, the Cisco IPS signatures are configured to meet the needs of most
average deployments. The most critical signatures are enabled to provide you
immediately with a certain level of security. Depending on your security policy and
the location of your sensor or sensors, you can choose to enable specific
signatures that are disabled by default, tune certain signatures, or even create
custom signatures. Before modifying any signature settings or creating new
signatures, study the built-in signatures and their default settings and consider the
following:
 Network protocols: Consider the network protocol of the traffic to be
examined. For example, if you are concerned with Enhanced Interior Gateway
Routing Protocol (EIGRP) packets, you might want to examine the configurable
parameters of signatures that examine IP packets and are triggered by the
contents of a single packet.
 Target address: Consider the target of any anticipated attack. For example, if
you are concerned with an excessive number of packets being sent to a specific
network, you might want to examine the configurable parameters of signatures
that detect an excessive volume of packets sent to a network.
 Target port: Consider the anticipated target ports of the attack. For example, if
you are concerned with connections to a specific UDP port or a range of UDP
 ports, you might want to examine the configurable parameters of signatures that
detect those connections.
 Type of attack: Consider any anticipated type of attack. For example, if you
anticipate DoS attacks, you might want to examine the signatures that are
commonly used to detect DoS attacks. If you anticipate reconnaissance attacks,
you might want to examine the signatures that are commonly used to detect
network reconnaissance attacks.
 Payload inspection: Consider the need to inspect the payload of a packet for
a string pattern. For example, if you must detect a string pattern in a TCP
packet, you might want to examine the configurable parameters of signatures
that are designed to detect a string pattern in a TCP packet.

After determining the needs of your specific deployment and familiarizing yourself
with the built-in signatures and their default settings, you can begin to modify
signature settings as needed. All signatures have the following two basic
configurable parameters:
 Enable: Enables or disables the signature
 Action: Assigns the action to take if the signature is triggered

Note You must be an administrator or operator to add, clone, enable,

disable, edit, or delete signatures.

You can access signatures of interest in a variety of ways from the Cisco IDM. To
begin, click Configuration, choose Signature Definitions,and then click
the Signature Configuration tab to access the Signature Configuration panel. By
default, the Signature Configuration panel displays signatures listed by signature ID
number. You can use the Select By drop-down menu to display signatures in
different ways, such as the types of attack they detect, or the services that they
inspect. When you change your selection in the Select By drop-down menu, the
Select Criteria drop-down menu changes to correspond to your selection.
For example, if you are searching for a UDP flood signature, choose DoS from the
Select By drop-down menu. The Select Criteria drop-down menu becomes a Select
Type drop-down menu. You can then choose UDP Floods from the Select Type
drop-down menu. The Signature Configuration panel refreshes and displays only
those signatures that match your sorting criteria.

Cisco IPS Sensor Software Version 6.x greatly increases the choices available in
searching for signatures. From the Select By drop-down menu, you can choose one
of the following:
 Active Signatures: Displays all individual signatures that have not been
retired, listed in ascending numerical order by signature ID number
 Sig ID: Displays signatures by signature ID number
 Sig Name: Displays signatures by signature name
 Enabled: Displays all signatures that are enabled, or in other words, actively
running on the sensor
 Severity: Displays signatures based on their severity level
 Fidelity Rating: Allows you to define a fidelity rating range of numbers, and
then displays only those signatures within that fidelity range
 Base RR: Similar to fidelity rating, allows you to define a range of numbers and
then displays only those signatures within that range
 Action: Displays signatures grouped by assigned signature actions
 Type: Displays signatures based on type such as tuned, custom, or default
 Engine: Displays signatures grouped by engine
 Adware/Spyware: Displays signatures designed to address adware and
spyware issues
 Attack: Displays signatures grouped by attack types
 DDOS: Displays distributed denial of service (DDoS) signatures
 DOS: Displays DoS signatures
 Email: Enables you to display e-mail signatures by protocol such as Internet
Message Access Protocol (IMAP) or Simple Mail Transfer Protocol (SMTP)
 Instant Messaging: Displays instant messaging (IM) signatures by IM
application
 L2/L3/L4 Protocol: Enables you to display signatures grouped by network
protocol type including Address Resolution Protocol (ARP), IP fragment, IPv6,
and others
 Network Services: Displays signatures based on network service protocols
such as DHCP or Border Gateway Protocol (BGP)
 OS: Enables you to display signatures grouped by operating system type
 Other Services: Displays signatures based on application layer services such
as FTP, HTTP, NetBIOS/Server Message Block (SMB), and others
 P2P: Displays signatures based on different peer-to-peer file sharing
applications
 Reconnaissance: Enables the display of signatures such as ping sweeps and
different types of port scans
 Releases: Enables you to display signatures grouped by signature update
release
 Viruses/Worms/Trojans: Displays signatures based on malware defined as
these three types
 Web Server: Enables you to display signatures based on specific web servers
 Active & Retired Signatures: Enables you to display all signatures known to
the sensor, whether active or not
A signature can be in multiple groups. For example, web signatures would be found
in the Other Services group and in the Web Server group. Editing a signature in one
group affects it in all groups. The last edit that you make is the one that is applied.
The figure shows the Signature Configuration panel as it appears when Sig ID is
chosen from the Select By drop-down menu. The Select Criteria drop-down menu
becomes an Enter Sig ID field that enables you to enter the signature ID of the
signature that you are trying to locate. When the Enter Sig ID field is displayed, it is
accompanied by a Find button. Click Find to locate the signature of the signature ID
that you entered. The following parameters of the signature are displayed in the
Signature Configuration panel:
 SigID: This identifies the number assigned to the signature.
 Subsig ID: This identifies the number assigned to the subsignature. Usually
this is 0.
 Name: This identifies the name assigned to the signature.
 Enabled: This identifies whether the signature is enabled. A signature must be
enabled for the sensor to protect against the traffic specified by the signature.
 Severity: This identifies the severity level that the signature will report: High,
Informational, Low, and Medium.
 Fidelity Rating: This identifies the weight associated with how well this
signature might perform in the absence of specific knowledge of the target.

 Base RR: This displays the base risk rating value of each signature. Cisco
IDM automatically calculates the base risk rating by multiplying the Fidelity
Rating and the Severity factor and dividing them by 100 (Fidelity Rating x
Severity factor /100).
The Severity factor has the following values:
 Severity factor = 100 if the signature severity level is High.
 Severity factor = 75 if signature severity level is Medium.
 Severity factor = 50 if signature severity level is Low.
 Severity factor = 25 if signature severity level is Informational.
 Action: This identifies the actions that the sensor will take when this signature
fires.
 Type: This identifies whether this signature is a default (built-in), tuned, or
custom signature.
 Engine: This identifies the engine that parses and inspects the traffic specified
by this signature.
 Retired: This identifies whether the signature is retired.

Caution A retired signature is removed from the signature engine. You can
activate a retired signature to place it back in the signature engine.

Note These parameters are displayed for all signatures that you display in
the Signature Configuration panel, regardless of how you display them.
The figure shows the Signature Configuration panel when Other Services is selected from
the Select By drop-down menu. The Select Criteria drop-down menu becomes a Select
Service drop-down menu that enables you to choose a network service. In the figure,
NETBIOS/SMB is selected, so the Signature Configuration panel displays a list of
signatures that inspect NetBIOS and SMBs.
Often it is desirable to enable or disable an entire group of signatures based on the
operating system criteria. Perhaps there are no IBM Advanced Interactive
eXecutive (AIX) servers in your environment and, as a noise reduction strategy; you
choose to disable all AIX signatures. In this case, you would want to locate all AIX
signatures and disable them as a group.
Step 1 Click Configuration, choose Signature Definitions, and click
the Signature Configuration tab. The Signature Configuration panel is
displayed.
Step 2 In the Select By drop-down box choose OS.
Step 3 From the Select Criteria drop-down box, choose the operating system in
which you are interested.

Complete the following steps to enable a signature:

Step 1 Click Configuration, choose Signature Definitions, and click
the Signature Configuration tab. The Signature Configuration panel is
displayed.
Step 2 Locate the signature that you want to enable.
Step 3 Look at the Enabled column to determine the status of the signature. A
signature that is currently enabled has the value Yes in this column.
Step 4 If the signature is currently disabled, choose the signature and
click Enable.
Step 5 Click Apply to apply your changes and save the revised configuration.
To disable a signature that is currently enabled, choose the signature and
click Disable. You can enable or disable all signatures in a group by clicking Select
All before clicking the Enable or Disable button.

Complete the following steps to configure signature actions:

Step 1 Click Configuration, choose Signature Definitions, and click
the Signature Configuration tab. The Signature Configuration panel is
displayed.
Step 2 Locate the signature or signatures to which you want to assign actions.
Step 3 Choose the signature or signatures.
Step 4 Click Actions. The Assign Actions window opens.

Note The Restore Defaults button returns all parameters for the selected
signature to the default settings. The Reset button refreshes the panel by
replacing any edits that you have made with the previously configured
value.
Step 5 Check the check boxes for the actions that you want to assign to the
signature. A check mark indicates that the action is assigned to the
selected signature. No check mark indicates that the action is not
assigned to any of the selected signatures. A gray check mark indicates
that the action is assigned to some of the selected signatures. You can
choose one or more of the following actions from the on-screen list:
 Deny Attacker Inline: This action terminates the current packet and future
packets from this attacker address for a specified period of time. The sensor
maintains a list of the attackers currently being denied by the system. You can
remove entries from the list or 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.

Note This action is the most severe of the deny actions. It denies current and
future packets from a single attacker address.

 Deny Attacker Service Pair Inline: This action terminates the current packet
and future packets from the attacker address victim port pair for a specified
period of time.
 Deny Attacker Victim Pair Inline: This action terminates the current packet
and future packets from the attacker and victim address pair for a specified
period of time.
 Deny Connection Inline: This action terminates the current packet and future
packets on this TCP flow.
 Deny Packet Inline: This action terminates the packet.

Note The deny actions are for inline sensors only.

 Log Attacker Packets: This action 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 the Produce Alert action is not selected.
 Log Pair Packets: This action starts IP logging on packets that contain the
attacker and victim address pair. This action causes an alert to be written to the
Event Store, even if the Produce Alert action is not selected.
 Log Victim Packets: This action 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 the Produce Alert action is not selected.
 Produce Alert: This action writes the event to the Event Store as an alert.
 Produce Verbose Alert: This action includes an encoded dump of the
offending packet in the alert. This action causes an alert to be written to the
Event Store, even if the Produce Alert action is not selected.
 Request Block Connection: This action sends a request to a blocking device
to block this connection.
 Request Block Host: This action sends a request to a blocking device to block
this attacker host.
 Request SNMP Trap: This action sends a request to the Notification
Application component of the sensor to perform SNMP notification. This action
causes an alert to be written to the Event Store, even if Produce Alert is not
selected.
 Reset TCP Connection: This action sends TCP resets to hijack and terminate
the TCP flow.
The Reset TCP Connection action can be used in conjunction with the deny packet
and deny flow actions. However, deny packet and deny flow actions do not
automatically cause TCP reset actions to occur.

Note If you want to assign all actions to the selected signatures, click Select
All. If you want to remove all actions from the selected signatures,
click Select None.

Step 6 Click OK to close the Assign Actions window. The Signature

Configuration panel displays the actions that you selected in the Action
column for the signature that you configured.
Step 7 Click OK to apply your changes.
Special Considerations for Signature Actions
This topic provides additional information for, denying and blocking actions.

From the General Settings panel, you can configure how long you want to deny
attackers, the maximum number of denied attackers, and how long you want blocks
to last. To access the General Settings panel, click Configuration, choose Event
Action Rules, and click the General Settings tab.
When you have completed your configuration, click Apply to apply your changes to
the sensor, or click Reset to replace any edits that you made with the previously
configured value.
 The Denied Attackers panel displays the IP addresses of all the attackers that have
been denied and the hit count for each denied attacker. You can reset the hit count
for all IP addresses or clear the list of denied attackers. To access the Denied
Attackers panel, click Monitoring andchoose Denied Attackers. Click Refresh to
refresh the list and use the following buttons as needed:
 Reset All Hit Counts: Clears the hit count for the denied attackers
 Clear List: Clears the entire list of denied attackers

Note Rebooting the sensor deactivates the denied attacker list.

Summary
This topic summarizes the key points that were discussed in this lesson.