Cisco Intrusion Prevention System Sensor CLI Configuration Guide for IPS 6.0

Defining Signatures

This chapter describes how to define and create signatures. It contains the following sections:

•Understanding Policies

•Working With Signature Definition Policies

•Understanding Signatures

•Signature Variables

•Configuring Signatures

•Creating Custom Signatures

Understanding Policies

You can create multiple security policies and apply them to individual virtual sensors. A security policy is made up of a signature definition policy, an event action rules policy, and an anomaly detection policy. IPS 6.0 contains a default signature definition policy called sig0, a default event action rules policy called rules0, and a default anomaly detection policy called ad0. You can assign the default policies to a virtual sensor or you can create new policies.

The use of multiple security policies lets you create security policies based on different requirements and then apply these customized policies per VLAN or physical interface.

Working With Signature Definition Policies

Use the service signature-definition name command in service signature definition mode to create a signature definition policy. The values of this signature definition policy are the same as the default signature definition policy, sig0, until you edit them.

Or you can use the copy signature-definition source_destination command in privileged EXEC mode to make a copy of an existing policy and then edit the values of the new policy as needed.

Use the list signature-definition-configurations command in privileged EXEC mode to list the signature definition policies.

Use the no service signature-definition name command in global configuration mode to delete a signature definition policy. Use the default service signature-definition name command in global configuration mode to reset the signature definition policy to factory settings.

To create, copy, edit, and delete signature definition policies, follow these steps:

Step 1 Log in to the CLI using an account with administrator privileges.

Step 2 Create a signature definition policy.

sensor# configure terminal

sensor(config)# service signature-definition MySig

Editing new instance MySig.

sensor(config-sig)# exit

Apply Changes?[yes]: yes

sensor(config)# exit

Step 3 Or copy an existing signature definition policy to a new signature definition policy.

sensor# copy signature-definition sig0 sig1

sensor# 

Note You receive an error if the policy already exists or if there is not enough space available for the new policy.

Step 4 Accept the default signature definition policy values or edit the following parameters:

a. Add signature definition variables.

b. Configure the general signature options.

Step 5 To display a list of signature definition policies on the sensor.

sensor# list signature-definition-configurations

Signature Definition

   Instance   Size   Virtual Sensor

   sig0       255    vs0

   temp       707    N/A

   MySig      255    N/A

   sig1       141    vs1

sensor#

Step 6 To delete a signature definition policy.

sensor# configure terminal

sensor(config)# no service signature-definition MySig

sensor(config)# exit

sensor#

Note You cannot delete the default signature definition policy, sig0.

Step 7 Confirm the signature definition policy has been deleted.

sensor# list signature-definition-configurations

Signature Definition

   Instance   Size   Virtual Sensor

   sig0       255    vs0

   temp       707    N/A

   sig1       141    vs1

sensor#

Step 8 To reset a signature definition policy to factory settings.

sensor# configure terminal

sensor(config)# default service signature-definition sig1

sensor(config)#

For More Information

•For the procedure for configuring signature variables, see Signature Variables.

•For the procedure for configuring general signature options, see Configuring Signatures.

Understanding Signatures

Attacks or other misuses of network resources can be defined as network intrusions. Sensors that use a signature-based technology can detect network intrusions. A signature is a set of rules that your sensor uses to detect typical intrusive activity, such as DoS attacks. As sensors scan network packets, they use signatures to detect known attacks and respond with actions that you define.

The sensor compares the list of signatures with network activity. When a match is found, the sensor takes an action, such as logging the event or sending an alert. Sensors let you modify existing signatures and define new ones.

Signature-based intrusion detection can produce false positives because certain normal network activity can be misinterpreted as malicious activity. For example, some network applications or operating systems may send out numerous ICMP messages, which a signature-based detection system might interpret as an attempt by an attacker to map out a network segment. You can minimize false positives by tuning your signatures.

To configure a sensor to monitor network traffic for a particular signature, you must enable the signature. By default, the most critical signatures are enabled when you install the signature update. When an attack is detected that matches an enabled signature, the sensor generates an alert, which is stored in the Event Store of the sensor. The alerts, as well as other events, may be retrieved from the Event Store by web-based clients. By default the sensor logs all Informational alerts or higher.

Some signatures have subsignatures, that is, the signature is divided in to 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 and change the severity, the severity change applies to only subsignature 1 and not to 3050 2, 3050 3, and 3050 4.

IPS 6.0 contains over 1000 built-in default signatures. You cannot rename or delete signatures from the list of built-in signatures, but you can retire signatures to remove them from the sensing engine. You can later activate retired signatures; however, this process requires the sensing engines to rebuild their configuration, which takes time and could delay the processing of traffic. You can tune built-in signatures by adjusting several signature parameters. Built-in signatures that have been modified are called tuned signatures.

You can create signatures, which are called custom signatures. Custom signature IDs begin at 60000. You can configure them for several things, such as matching of strings on UDP connections, tracking of network floods, and scans. Each signature is created using a signature engine specifically designed for the type of traffic being monitored.

Signature Variables

This section describes signature variables, and contains the following topics:

•Understanding Signature Variables

•Adding, Editing, and Deleting Signature Variables

Understanding Signature Variables

When you want to use the same value within multiple signatures, use a variable. When you change the value of a variable, that variable is updated in all signatures in which it appears. This saves you from having to change the variable repeatedly as you configure signatures.

Note You must preface the variable with a dollar ($) sign to indicate that you are using a variable rather than a string.

Some variables cannot be deleted because they are necessary to the signature system. If a variable is protected, you cannot select it to edit it. You receive an error message if you try to delete protected variables. You can edit only one variable at a time.

Adding, Editing, and Deleting Signature Variables

Use the variables command in the signature definition submode to create signature variables.

The following options apply:

•variable_name—Identifies the name assigned to this variable.

A valid name can only contain numbers or letters. You can also use a hyphen (-) or underscore (_).

•ip-addr-range—System-defined variable for grouping IP addresses.

The valid values are: A.B.C.D-A.B.C.D[,A.B.C.D-A.B.C.D]

•web-ports—System-defined variable for ports to look for HTTP traffic.

To designate multiple port numbers for a single variable, place a comma between the entries. For example, 80, 3128, 8000, 8010, 8080, 8888, 24326.

To add, edit, and delete signature variables, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Create a signature variable for a group of IP addresses.

sensor(config-sig)# variables IPADD ip-addr-range 10.1.1.1-10.1.1.24

Step 4 Edit the signature variable for web ports.

sensor(config-sig)# variables WEBPORTS web-ports 80,3128,8000

WEBPORTS has a predefined set of ports where web servers are running, but you can edit the value. This variable affects all signatures that have web ports. The default is 80, 3128, 8000, 8010, 8080, 8888, 24326.

Step 5 Verify the changes.

sensor(config-sig)# show settings

   variables (min: 0, max: 256, current: 2)

   -----------------------------------------------

      variable-name: IPADD

      -----------------------------------------------

         ip-addr-range: 10.1.1.1-10.1.1.24

      -----------------------------------------------

      <protected entry>

      variable-name: WEBPORTS

      -----------------------------------------------

         web-ports: 80,3128,8000 default: 80-80,3128-3128,8000-8000,8010-8010,80

80-8080,8888-8888,24326-24326

      -----------------------------------------------

Step 6 To delete a variable.

sensor(config-sig)# no variables IPADD 

Step 7 Verify the variable has been deleted:

sensor(config-sig)# show settings

   variables (min: 0, max: 256, current: 1)

   -----------------------------------------------

      <protected entry>

      variable-name: WEBPORTS

      -----------------------------------------------

         web-ports: 80,3128,8000 default: 80-80,3128-3128,8000-8000,8010-8010,80

80-8080,8888-8888,24326-24326

      -----------------------------------------------

Step 8 Exit signature definition submode.

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 9 Press Enter to apply the changes or enter no to discard them.

Configuring Signatures

This section describes how to configure signature parameters, and contains the following topics:

•Configuring General Signature Parameters

•Configuring Alert Frequency

•Configuring Alert Severity

•Configuring Event Counter

•Configuring Signature Fidelity Rating

•Configuring the Status of Signatures

•Configuring the Vulnerable OSes for a Signature

•Assigning Actions to Signatures

•Configuring AIC Signatures

•Configuring IP Fragment Reassembly

•Configuring TCP Stream Reassembly

•Configuring IP Logging

Configuring General Signature Parameters

The following options apply to configuring the general parameters of a specific signature:

•alert-frequency—Sets the summary options for grouping alerts.

•alert-severity—Sets the severity of the alert.

•engine—Specifies the signature engine. You can assign actions when you are in the engine submode.

•event-counter—Sets the event count.

•promisc-delta—The delta value used to determine the seriousness of the alert.

Caution We do not recommend that you change the promiscuous delta setting for a signature.

Promiscuous delta 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 the administrator can focus on investigating higher risk rating alerts.

In inline mode, the sensor can deny the offending packets and they never reach the target host, so it does not matter if the target was vulnerable. The attack was not allowed on the network and so we do not subtract from the risk rating value.

Signatures that are not service, OS, or application specific have 0 for the promiscuously delta. If the signature is specific to an OS, service, or application, it has a promiscuous delta of 5, 10, or 15 calculated from 5 points for each category.

•sig-description—Your description of the signature.

•sig-fidelity-rating—Rating of the fidelity of signature.

•status—Sets the status of the signature to enabled or retired.

•vulnerable-os—List of OS types that are vulnerable to this attack signature.

For More Information

•For the procedure for configuring alert frequency, see Configuring Alert Frequency.

•For the procedure for configuring alert severity, see Configuring Alert Severity.

•For more information about signature engines, see "Signature Engines."

•For the procedure for assigning actions, see Assigning Actions to Signatures.

•For the procedure for configuring the event counter, see Configuring Event Counter.

•For the procedure for configuring the fidelity rating of a signature, see Configuring Signature Fidelity Rating.

•For the procedure for setting the status of a signature, see Configuring the Status of Signatures.

•For the procedure for configuring the vulnerable OS list for a signature, see Configuring the Vulnerable OSes for a Signature.

Configuring Alert Frequency

Use the alert-frequency command in signature definition submode to configure the alert frequency for a signature. The alert-frequency command specifies how often the sensor alerts you when this signature is firing.

The following options apply:

•sig_id—Identifies the unique numerical value assigned to this signature. This value lets the sensor identify a particular signature. The value is 1000 to 65000.

•subsig_id—Identifies the unique numerical value assigned to this subsignature. A subsignature ID is used to identify a more granular version of a broad signature. The value is 0 to 255.

•summary-mode—The way you want the sensor to group the alerts:

–fire-all—Fires an alert on all events.

–fire-once—Fires an alert only once.

–global-summarize—Summarizes an alert so that it only fires once regardless of how many attackers or victims.

–summarize—Summarize all the alerts.

•specify-summary-threshold {yes | no}—Enables summary threshold mode:

–summary-threshold—Specifies the minimum number of hits the sensor must receive before sending a summary alert for this signature. The value is 0 to 65535.

–summary-interval—Specifies the time in seconds used in each summary alert. The value is 1 to 1000.

•summary-key—Specifies the storage type on which to summarize this signature:

–Axxx—Attacker address.

–Axxb—Attacker address and victim port.

–AxBx—Attacker and victim addresses.

–AaBb—Attacker and victim addresses and ports.

–xxBx—Victim address.

•specify-global-summary-threshold {yes | no}—(Optional) Enables global summary threshold mode:

–global-summary-threshold—Specifies the threshold number of events to take alert in to global summary. The value is 1 to 65535.

To configure the alert frequency parameters of a signature, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Specify the signature you want to configure.

sensor(config-sig)# signatures 9000 0

Step 4 Enter alert frequency submode.

sensor(config-sig-sig)# alert-frequency

Step 5 Specify the alert frequency of this signature:

a. Configure the summary mode to, for example, fire once.

sensor(config-sig-sig-ale)# summary-mode fire-once

sensor(config-sig-sig-ale-fir)# specify-global-summary-threshold yes

sensor(config-sig-sig-ale-fir-yes)# global-summary-threshold 3000

sensor(config-sig-sig-ale-fir-yes)# summary-interval 5000

b. Specify the summary key.

sensor(config-sig-sig-ale-fir-yes)# exit

sensor(config-sig-sig-ale-fir)# summary-key AxBx

c. Verify the settings.

sensor(config-sig-sig-ale-fir)# show settings

   fire-once

   -----------------------------------------------

      summary-key: AxBx default: Axxx

      specify-global-summary-threshold

      -----------------------------------------------

         yes

         -----------------------------------------------

            global-summary-threshold: 3000 default: 120

            summary-interval: 5000 default: 15

         -----------------------------------------------

      -----------------------------------------------

   -----------------------------------------------

sensor(config-sig-sig-ale-fir)#

Step 6 Exit alert-frequency submode.

sensor(config-sig-sig-ale-fir)# exit

sensor(config-sig-sig-ale)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 7 Press Enter to apply the changes or enter no to discard them.

Configuring Alert Severity

Use the alert-severity command in signature definition submode to configure the severity of a signature.

The following options apply:

•sig_id—Identifies the unique numerical value assigned to this signature. This value lets the sensor identify a particular signature. The value is 1000 to 65000.

•subsig_id—Identifies the unique numerical value assigned to this subsignature. A subsignature ID is used to identify a more granular version of a broad signature. The value is 0 to 255.

•alert-severity—Specifies the severity of the alert:

–high —Dangerous alert.

–medium—Medium level alert (default).

–low—Low level alert.

–informational—Informational alert.

To configure the alert severity, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Specify the signature you want to configure.

sensor(config-sig)# signatures 9000 0

Step 4 Assign the alert severity.

sensor(config-sig-sig)# alert-severity medium

Step 5 Verify the settings.

sensor(config-sig-sig)# show settings

   <protected entry>

   sig-id: 9000

   subsig-id: 0

   -----------------------------------------------

      alert-severity: medium default: medium

      sig-fidelity-rating: 75 <defaulted>

      promisc-delta: 0 <defaulted>

      sig-description

      -----------------------------------------------

         sig-name: Back Door Probe (TCP 12345) <defaulted>

         sig-string-info: SYN to TCP 12345 <defaulted>

         sig-comment: <defaulted>

         alert-traits: 0 <defaulted>

         release: 40 <defaulted>

      -----------------------------------------------

      vulnerable-os: general-os <defaulted> 

      engine

      -----------------------------------------------

         atomic-ip

         -----------------------------------------------

            event-action: produce-alert <defaulted>

            fragment-status: any <defaulted>

            specify-l4-protocol

            -----------------------------------------------

--MORE--

Step 6 Exit signatures submode.

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 7 Press Enter to apply the changes or enter no to discard them.

Configuring Event Counter

Use the event-counter command in signature definition submode to configure how the sensor counts events. For example, you can specify that you want the sensor to send an alert only if the same signature fires 5 times for the same address set.

The following options apply:

•event-count—The number of times an event must occur before an alert is generated. The valid range is 1 to 65535. The default is 1.

•event-count-key—The storage type on which to count events for this signatures:

–Axxx—Attacker address

–AxBx—Attacker and victim addresses

–Axxb—Attacker address and victim port

–xxBx—Victim address

–AaBb—Attacker and victim addresses and ports

•specify-alert-interval {yes | no}—Enables alert interval mode:

–alert-interval—The time in seconds before the event count is reset. The default is 60.

To configure event counter, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Specify the signature for which you want to configure event counter.

sensor(config-sig)# signatures 9000 0

Step 4 Enter event counter submode.

sensor(config-sig-sig)# event-counter

Step 5 Specify how many times an event must occur before an alert is generated.

sensor(config-sig-sig-eve)# event-count 2

Step 6 Specify the storage type on which you want to count events for this signature.

sensor(config-sig-sig-eve)# event-count-key AxBx

Step 7 (Optional) Enable alert interval.

sensor(config-sig-sig-eve)# specify-alert-interval yes

Step 8 (Optional) Specify the amount of time in seconds before the event count should be reset.

sensor(config-sig-sig-eve-yes)# alert-interval 30

Step 9 Verify the settings.

sensor(config-sig-sig-eve-yes)# exit

sensor(config-sig-sig-eve)# show settings

   event-counter

   -----------------------------------------------

      event-count: 2 default: 1

      event-count-key: AxBx default: Axxx

      specify-alert-interval

      -----------------------------------------------

         yes

         -----------------------------------------------

            alert-interval: 30 default: 60

         -----------------------------------------------

      -----------------------------------------------

   -----------------------------------------------

sensor(config-sig-sig-eve)#

Step 10 Exit signatures submode.

sensor(config-sig-sig-eve)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 11 Press Enter to apply the changes or enter no to discard them.

Configuring Signature Fidelity Rating

Use the sig-fidelity-rating command in signature definition submode to configure the signature fidelity rating for a signature.

The following option applies:

•sig-fidelity-rating—Identifies the weight associated with how well this signature might perform in the absence of specific knowledge of the target. The valid value is 0 to 100.

To configure the signature fidelity rating for a signature, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig0

Step 3 Specify the signature you want to configure.

sensor(config-sig)# signatures 12000 0

Step 4 Specify the signature fidelity rating for this signature.

sensor(config-sig-sig)# sig-fidelity-rating 50

Step 5 Verify the settings.

sensor(config-sig-sig)# show settings

   <protected entry>

   sig-id: 12000

   subsig-id: 0

   -----------------------------------------------

      alert-severity: low <defaulted>

      sig-fidelity-rating: 50 default: 85

      promisc-delta: 15 <defaulted>

      sig-description

      -----------------------------------------------

         sig-name: Gator Spyware Beacon <defaulted>

         sig-string-info: /download/ User-Agent: Gator <defaulted>

         sig-comment: <defaulted>

         alert-traits: 0 <defaulted>

         release: 71 <defaulted>

      -----------------------------------------------

Step 6 Exit signatures submode.

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 7 Press Enter to apply the changes or enter no to discard them.

Configuring the Status of Signatures

Use the status command in signature definition submode to specify the status of a specific signature.

The following options apply:

•status—Identifies whether the signature is enabled, disabled, or retired.

–enabled {true | false}—Enables the signature.

–retired {true | false}—Retires the signature.

–obsoletes signature_ID—Shows the other signatures that have been obsoleted by this signature.

Caution Activating and retiring signatures can take 30 minutes or longer.

To change the status of a signature, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Choose the signature you want to configure.

sensor(config-sig)# signatures 12000 0

Step 4 Change the status for this signature.

sensor(config-sig-sig)# status

sensor(config-sig-sig-sta)# enabled true

Step 5 Verify the settings.

sensor(config-sig-sig-sta)# show settings

   status

   -----------------------------------------------

      enabled: true default: false

      retired: false <defaulted>

   -----------------------------------------------

sensor(config-sig-sig-sta)#

Step 6 Exit signatures submode.

sensor(config-sig-sig-sta)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 7 Press Enter to apply the changes or enter no to discard them.

Configuring the Vulnerable OSes for a Signature

Use the vulnerable-os command in signature definition submode to configure the list of vulnerable OSes for a signature.

The following options apply:

•general-os—All OS types

•ios—Variants of Cisco IOS

•mac-os—Variants of Macin tosh OS

•netware—Netware

•other—Any other OS

•unix—Variants of UNIX

•aix—Variants of AIX

•bsd—Variants of BSD

•hp-ux—Variants of HP-UX

•irix—Variants of IRIX

•linux—Variants of Linux

•solaris—Variants of Solaris

•windows—Variants of Microsoft Windows

•windows-nt-2k-xp—Variants of Microsoft NT, 2000, and XP

•win-nt—Specific variants of Windows NT

To configure the vulnerable OSes for a signature, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Specify the signature you want to configure.

sensor(config-sig)# signatures 6000 0

Step 4 Specify the vulnerable OSes for this signature.

sensor(config-sig-sig)# vulnerable-os linux|aix

Step 5 Verify the settings.

sensor(config-sig-sig)# show settings

   sig-id: 60000

   subsig-id: 0

   -----------------------------------------------

      alert-severity: medium <defaulted>

      sig-fidelity-rating: 75 <defaulted>

      promisc-delta: 0 <defaulted>

      sig-description

      -----------------------------------------------

         sig-name: My Sig <defaulted>

         sig-string-info: My Sig Info <defaulted>

         sig-comment: Sig Comment <defaulted>

         alert-traits: 0 <defaulted>

         release: custom <defaulted>

      -----------------------------------------------

      vulnerable-os: aix|linux default: general-os

*---> engine

      -----------------------------------------------

      -----------------------------------------------

      event-counter

      -----------------------------------------------

         event-count: 1 <defaulted>

         event-count-key: Axxx <defaulted>

         specify-alert-interval

         -----------------------------------------------

--MORE--

Step 6 Exit signatures submode.

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 7 Press Enter to apply the changes or enter no to discard them.

Assigning Actions to Signatures

Use the event-action command in signature definition submode to configure the actions the sensor takes when the signature fires.

The following options apply:

•event-action—Action(s) to perform when an alert is triggered:

–deny-attacker-inline —(Inline mode only) does not transmit this packet and future packets from the attacker address for a specified period of time.

–deny-attacker-service-pair-inline—(Inline mode only) Does not transmit this packet and future packets on the attacker address victim port pair for a specified period of time.

–deny-attacker-victim-pair-inline—Iinline mode only) Does not transmit this packet and future packets on the attacker/victim address pair for a specified period of time.

–deny-connection-inline—(Inline mode only) Does not transmit this packet and future packets on the TCP Flow.

–deny-packet-inline—(Inline mode only) Does not transmit this packet.

–log-attacker-packets—Starts IP logging of packets containing the attacker address. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–log-pair-packets—Starts IP logging of packets containing the attacker-victim address pair. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–log-victim-packets—Starts IP logging of packets containing the victim address. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–produce-alert —Writes the event to Event Store as an alert.

–produce-verbose-alert—Includes an encoded dump (possibly truncated) of the offending packet in the alert. This action causes an alert to be written to the Event Store, even if produce-alert is not selected.

–request-block-connection—Sends a request to ARC to block this connection. You must have blocking devices configured to implement this action.

–request-block-host—Sends a request to ARC to block this attacker host. You must have blocking devices configured to implement this action.

–request-rate-limit—Sends a rate limit request to ARC to perform rate limiting. You must have rate limiting devices configured to implement this action.

–request-snmp-trap—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. You must have SNMP configured on the sensor to implement this action.

–reset-tcp-connection—Sends TCP resets to hijack and terminate the TCP flow. Reset TCP Connection only works on TCP signatures that analyze a single connection. It does not work for sweeps or floods.

–modify-packet-inline— Modifies packet data to remove ambiguity about what the end point might do with the packet.

•event-action-settings—Specifies the external-rate-limit-type:

–none—No rate limiting configured.

–percentage—Sets the rate limit by traffic percentage (external-rate-limit-percentage).

Configuring Event Actions

To configure event actions and event action settings for a signature, follow these steps:

Step 1 Log in to the CLI using an account with administrator privileges.

Step 2 Enter signature definition mode.

sensor# configure terminal

sensor(config)# service signature-definition sig0

sensor(config-sig)#

Step 3 Specify the signature you want to configure.

sensor(config-sig)# signatures 1200 0

Step 4 Specify the signature engine (for signature 1200 it is the Normalizer engine).

sensor(config-sig-sig)# engine normalizer

Step 5 Configure the event action.

sensor(config-sig-sig-nor)# event-action produce-alert|request-snmp-trap

Note Each time you configure the event actions for a signature, you overwrite the previous configuration. For example, if you always want to produce an alert when the signature is fired, you must configure it along with the other event actions you want. Use the | symbol to add more than one event action, for example, product-alert|deny-packet-inline|request-snmp-trap.

Step 6 Verify the settings.

sensor(config-sig-sig-nor)# show settings

   normalizer

   -----------------------------------------------

      event-action: produce-alert|request-snmp-trap default: 
produce-alert|deny-packet-inline

Step 7 Specify the percentage for rate limiting

sensor(config-sig-sig-nor)# event-action-settings

sensor(config-sig-sig-nor-eve)# external-rate-limit-type percentage

sensor(config-sig-sig-nor-eve-per)# external-rate-limit-percentage 50

Step 8 Verify the settings.

sensor(config-sig-sig-nor-eve-per)# show settings

   percentage

   -----------------------------------------------

      external-rate-limit-percentage: 50 default: 100

   -----------------------------------------------

Step 9 Exit event action submode.

sensor(config-sig-sig-nor-eve-per)# exit

sensor(config-sig-sig-nor-eve)# exit

sensor(config-sig-sig-nor)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 10 Press Enter to apply the changes or enter no to discard them.

For More Information

For detailed information about event actions, see Event Actions.

Configuring AIC Signatures

This section describes the Application Inspection and Control (AIC) signatures and how to configure them. It contains the following topics:

•Overview

•AIC Engine and Sensor Performance

•Configuring the Application Policy

•AIC Request Method Signatures

•AIC MIME Define Content Type Signatures

•AIC Transfer Encoding Signatures

•AIC FTP Commands Signatures

•Creating an AIC Signature

Overview

AIC provides detailed analysis of web traffic. It provides granular control over HTTP sessions to prevent abuse of the HTTP protocol. It also allows administrative control over applications that attempt to tunnel over specified ports, such as instant messaging, and tunneling applications such as, gotomypc. Inspection and policy checks for P2P and instant messaging is possible if these applications are running over HTTP. AIC also provides a way to inspect FTP traffic and control the commands being issued.

You can enable or disable the predefined signatures or you can create policies through custom signatures.

The AIC engine runs when HTTP traffic is received on AIC web ports. If traffic is web traffic, but not received on the AIC web ports, the Service HTTP engine is executed. AIC inspection can be on any port if it is configured as an AIC web port and the traffic to be inspected is HTTP traffic.

Caution The AIC web ports are regular HTTP web ports. You can turn on AIC web ports to distinguish which ports should watch for regular HTTP traffic and which ports should watch for AIC enforcement. You might use AIC web ports, for example, if you have a proxy on port 82 and you need to monitor it. We recommend that you do not configure separate ports for AIC enforcement.

AIC has the following categories of signatures:

•HTTP request method

–Define request method

–Recognized request methods

•MIME type

–Define content type

–Recognized content type

•Define web traffic policy

There is one predefined signature, 12674, that specifies the action to take when noncompliant HTTP traffic is seen. The parameter Alarm on Non HTTP Traffic enables the signature. By default this signature is enabled.

•Transfer encodings

–Associate an action with each method

–List methods recognized by the sensor

–Specify which actions need to be taken when a chunked encoding error is seen

•FTP commands

Associates an action with an FTP command.

For More Information

•For a list of AIC request method signature IDs and descriptions, see AIC Request Method Signatures.

•For a list of AIC MIME define content type signature IDs and descriptions, see AIC MIME Define Content Type Signatures.

•For the procedure for creating a custom MIME signature, see Creating an AIC Signature.

•For a list of AIC transfer encoding signature IDs and descriptions, see AIC Transfer Encoding Signatures.

•For a list of FTP signature IDs and descriptions, see AIC FTP Commands Signatures.

AIC Engine and Sensor Performance

Application policy enforcement is a unique sensor feature. Rather than being based on traditional IPS technologies that inspect for exploits, vulnerabilities, and anomalies, AIC policy enforcement is designed to enforce HTTP and FTP service policies. The inspection work required for this policy enforcement is extreme compared with traditional IPS inspection work. A large performance penalty is associated with using this feature. When AIC is enabled, the overall bandwidth capacity of the sensor is reduced.

AIC policy enforcement is disabled in the IPS default configuration. If you want to activate AIC policy enforcement, we highly recommend that you carefully choose the exact policies of interest and disable those you do not need. Also, if your sensor is near its maximum inspection load capacity, we recommend that you not use this feature since it can oversubscribe the sensor. We recommend that you use the adaptive security appliance firewall to handle this type of policy enforcement.

Configuring the Application Policy

Use the application-policy command in signature definition submode to enable the web AIC feature. You can configure the sensor to provide Layer 4 to Layer 7 packet inspection to prevent malicious attacks related to web and FTP services.

The following options apply:

•ftp-enable {true | false}—Enables protection for FTP services. Set to true to require the sensor to inspect FTP traffic. The default is false.

•http-policy—Enables inspection of HTTP traffic:

–aic-web-ports—Variable for ports to look for AIC traffic. The valid range is 0 to 65535. A comma-separated list of integer ranges a-b[,c-d] within 0-65535. The second number in the range must be greater than or equal to the first number. The default is 80-80,3128-3128,8000-8000,8010-8010,8080-8080,8888-8888,24326-24326.

Note We recommend that you not configure AIC web ports, but rather use the default web ports.

–http-enable {true | false}—Enables protection for web services. Set to true to require the sensor to inspect HTTP traffic for compliance with the RFC. The default is false.

–max-outstanding-http-requests-per-connection—Maximum allowed HTTP requests per connection. The valid value is 1 to 16. The default is 10.

To configure the application policy, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter application policy submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

sensor(config-sig)# application-policy

Step 3 Enable inspection of FTP traffic.

sensor(config-sig-app)# ftp-enable true

Step 4 Configure the HTTP application policy:

a. Enter HTTP application policy submode.

sensor(config-sig-app)# http-policy

b. Enable HTTP application policy enforcement.

sensor(config-sig-app-htt)# http-enable true

c. Specify the number of outstanding HTTP requests per connection that can be outstanding without having received a response from the server.

sensor(config-sig-app-htt)# max-outstanding-http-requests-per-connection 5

d. (Optional) Edit the AIC ports.

Note We recommend that you not configure AIC web ports, but rather use the default web ports.

sensor(config-sig-app-htt)# aic-web-ports 80-80,3128-3128

Step 5 Verify your settings.

sensor(config-sig-app-htt)# exit

sensor(config-sig-app)# show settings

   application-policy

   -----------------------------------------------

      http-policy

      -----------------------------------------------

         http-enable: true default: false

         max-outstanding-http-requests-per-connection: 5 default: 10

         aic-web-ports: 80-80,3128-3128 default: 80-80,3128-3128,8000-8000,8010-

8010,8080-8080,8888-8888,24326-24326

      -----------------------------------------------

      ftp-enable: true default: false

   -----------------------------------------------

sensor(config-sig-app)#

Step 6 Exit signature definition submode:

sensor(config-sig-app)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 7 Press Enter to apply the changes or enter no to discard them.

AIC Request Method Signatures

The HTTP request method has two categories of signatures:

•Define request method—Allows actions to be associated with request methods. You can expand and modify the signatures (Define Request Method).

•Recognized request methods—Lists methods that are recognized by the sensor (Recognized Request Methods).

Table 6-1 lists the predefined define request method signatures. Enable the signatures that have the predefined method you need.

For More Information

For the procedure for enabling signatures, see Configuring the Status of Signatures.

AIC MIME Define Content Type Signatures

There are two policies associated with MIME types:

•Define content type—Associates specific actions for the following cases (Define Content Type):

–Deny a specific MIME type, such as an image/jpeg

–Message size violation

–MIME-type mentioned in header and body do not match

•Recognized content type (Recognized Content Type)

Table 6-2 lists the predefined define content type signatures. Enable the signatures that have the predefined content type you need.

For More Information

•For the procedure for enabling signatures, see Configuring the Status of Signatures.

•You can also create custom define content type signatures. For the procedure for creating custom AIC signatures, see Creating an AIC Signature.

AIC Transfer Encoding Signatures

There are three policies associated with transfer encoding:

•Associate an action with each method (Define Transfer Encoding)

•List methods recognized by the sensor (Recognized Transfer Encodings)

•Specify which actions need to be taken when a chunked encoding error is seen (Chunked Transfer Encoding Error)

Table 6-3 lists the predefined transfer encoding signatures. Enable the signatures that have the predefined transfer encoding method you need.

For More Information

For the procedure for enabling signatures, see Configuring the Status of Signatures.

AIC FTP Commands Signatures

Table 6-4 lists the predefined FTP commands signatures. Enable the signatures that have the predefined FTP command you need.

For More Information

For the procedure for enabling signatures, see Configuring the Status of Signatures.

Creating an AIC Signature

The following example demonstrates how to create a MIME-type signature based on the AIC engine.

The following options apply:

•event-action—Specifies the action(s) to perform when alert is triggered:

–deny-attacker-inline —(Inline mode only) Does not transmit this packet and future packets from the attacker address for a specified period of time.

–deny-attacker-service-pair-inline—(Inline mode only) Does not transmit this packet and future packets on the attacker address victim port pair for a specified period of time.

–deny-attacker-victim-pair-inline—(Inline mode only) Does not transmit this packet and future packets on the attacker/victim address pair for a specified period of time.

–deny-connection-inline—(Inline mode only) Does not transmit this packet and future packets on the TCP Flow.

–deny-packet-inline—(Inline mode only) Does not transmit this packet.

–log-attacker-packets—Starts IP logging of packets containing the attacker address. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–log-pair-packets—Starts IP logging of packets containing the attacker-victim address pair. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–log-victim-packets—Starts IP logging of packets containing the victim address. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–produce-alert —Writes the event to Event Store as an alert.

–produce-verbose-alert—Includes an encoded dump (possibly truncated) of the offending packet in the alert. This action causes an alert to be written to the Event Store, even if produce-alert is not selected.

–request-block-connection—Sends a request to ARC to block this connection. You must have blocking devices configured to implement this action.

–request-block-host—Sends a request to ARC to block this attacker host. You must have blocking devices configured to implement this action.

–request-rate-limit—Sends a rate limit request to ARC to perform rate limiting. You must have rate limiting devices configured to implement this action.

–request-snmp-trap—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. You must have SNMP configured on the sensor to implement this action.

–reset-tcp-connection—Sends TCP resets to hijack and terminate the TCP flow. Reset TCP Connection only works on TCP signatures that analyze a single connection. It does not work for sweeps or floods.

–modify-packet-inline— Modifies packet data to remove ambiguity about what the end point might do with the packet.

•no—Removes an entry or selection setting.

•signature-type—Specifies the type of signature desired:

–content-types—Content-types

–define-web-traffic-policy—Defines web traffic policy

–max-outstanding-requests-overrun—Inspects for large number of outstanding HTTP requests

–msg-body-pattern—Message body pattern

–request-methods—Signature types that deal with request methods

–transfer-encodings—Signature types that deal with transfer encodings

To define a MIME-type policy signature, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter application policy enforcement submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

sensor(config-sig)# signatures 60001 0

sensor(config-sig-sig)# engine application-policy-enforcement-http

Step 3 Specify the event action.

sensor(config-sig-sig-app)# event-action produce-alert|log-pair-packets

Step 4 Define the signature type.

sensor(config-sig-sig-app)# signature-type content-type define-content-type

Step 5 Define the content type.

sensor(config-sig-sig-app-def)# name MyContent

Step 6 Verify your settings.

sensor(config-sig-sig-app-def)# show settings

-> define-content-type

   -----------------------------------------------

      name: MyContent

*---> content-type-details

      -----------------------------------------------

      -----------------------------------------------

   -----------------------------------------------

sensor(config-sig-sig-app-def)#

Step 7 Exit signatures submode.

sensor(config-sig-sig-app-def)# exit

sensor(config-sig-sig-app)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 8 Press Enter to apply the changes or enter no to discard them.

Configuring IP Fragment Reassembly

This section describes IP fragment reassembly, lists the IP fragment reassembly signatures with the configurable parameters, describes how to configure these parameters, and how to configure the method for IP fragment reassembly. It contains the following topics:

•Understanding IP Fragment Reassembly

•IP Fragment Reassembly Signatures and Configurable Parameters

•Configuring IP Fragment Reassembly Parameters

•Configuring the Method for IP Fragment Reassembly

Understanding IP Fragment Reassembly

You can configure the sensor to reassemble a datagram that has been fragmented over multiple packets. You can specify boundaries that the sensor uses to determine how many datagram fragments it reassembles and how long to wait for more fragments of a datagram. The goal is to ensure that the sensor does not allocate all its resources to datagrams that cannot be completely reassembled, either because the sensor missed some frame transmissions or because an attack has been launched that is based on generating random fragmented datagrams.

You configure the IP fragment reassembly per signature.

IP Fragment Reassembly Signatures and Configurable Parameters

Table 6-5 lists IP fragment reassembly signatures with the parameters that you can configure for IP fragment reassembly. The IP fragment reassembly signatures are part of the Normalizer engine.

For More Information

•For more information on the Normalizer Engine and a list of Normalizer engine signatures with automatic safeguards that you cannot override with configuration settings, see Normalizer Engine.

•For more information about the AIP SSM and the Normalizer engine, see AIP SSM and the Normalizer Engine.

Configuring IP Fragment Reassembly Parameters

To configure IP fragment reassembly parameters for a specific signature, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Specify the IP fragment reassembly signature ID and subsignature ID.

sensor(config-sig)# signatures 1200 0

Step 4 Specify the engine.

sensor(config-sig-sig)# engine normalizer

Step 5 Enter edit default signatures submode.

sensor(config-sig-sig-nor)# edit-default-sigs-only default-signatures-only

Step 6 Enable and change the default setting (if desired) of any of the IP fragment reassembly parameter for signature 1200 for example, specifying the maximum fragments.

sensor(config-sig-sig-nor-def)# specify-max-fragments yes

sensor(config-sig-sig-nor-def-yes)# max-fragments 20000

Step 7 Verify the settings.

sensor(config-sig-sig-nor-def-yes)# show settings

   yes

   -----------------------------------------------

      max-fragments: 20000 default: 10000

   -----------------------------------------------

sensor(config-sig-sig-nor-def-yes)#

Step 8 Exit signature definition submode.

sensor(config-sig-sig-nor-def-yes)# exit

sensor(config-sig-sig-nor-def)# exit

sensor(config-sig-sig-nor)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 9 Press Enter for apply the changes or enter no to discard them.

Configuring the Method for IP Fragment Reassembly

Use the fragment-reassembly command in the signature definition submode to configure the method the sensor will use to reassemble fragments. You can configure this option if your sensor is operating in promiscuous mode. If your sensor is operating in line mode, the method is NT only.

The following options apply:

•ip-reassemble-mode—Identifies the method the sensor uses to reassemble the fragments based on the operating system:

–nt—Windows systems (default).

–solaris—Solaris systems.

–linux—GNU/Linux systems.

–bsd—BSD UNIX systems.

To configure IP fragment reassembly, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter fragment reassembly submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

sensor(config-sig)# fragment-reassembly

Step 3 Configure the operating system you want the sensor to use to reassemble IP fragments.

sensor(config-sig-fra)# ip-reassemble-mode linux

Step 4 Verify the setting.

sensor(config-sig-fra)# show settings

   fragment-reassembly

   -----------------------------------------------

      ip-reassemble-mode: linux default: nt

   -----------------------------------------------

sensor(config-sig-fra)#

Step 5 Exit signature definition submode.

sensor(config-sig-fra)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 6 Press Enter to apply the changes or enter no to discard them.

Configuring TCP Stream Reassembly

This section describes TCP stream reassembly, lists the TCP stream reassembly signatures with the configurable parameters, describes how to configure TCP stream signatures, and how to configure the mode for TCP stream reassembly. It contains the following topics:

•Understanding TCP Stream Reassembly

•TCP Stream Reassembly Signatures and Configurable Parameters

•Configuring TCP Stream Reassembly Signatures

•Configuring the Mode for TCP Stream Reassembly

Understanding TCP Stream Reassembly

You can configure the sensor to monitor only TCP sessions that have been established by a complete three-way handshake. You can also configure how long to wait for the handshake to complete, and how long to keep monitoring a connection where no more packets have been seen. The goal is to prevent the sensor from creating alerts where a valid TCP session has not been established. There are known attacks against sensors that try to get the sensor to generate alerts by simply replaying pieces of an attack. The TCP session reassembly feature helps to mitigate these types of attacks against the sensor.

You configure TCP stream reassembly parameters per signature. You can configure the mode for TCP stream reassembly.

For More Information

•For more information on the Normalizer Engine and a list of Normalizer engine signatures with automatic safeguards that you cannot override with configuration settings, see Normalizer Engine.

•For more information about the AIP SSM and the Normalizer engine, see AIP SSM and the Normalizer Engine.

TCP Stream Reassembly Signatures and Configurable Parameters

Table 6-6 lists TCP stream reassembly signatures with the parameters that you can configure for TCP stream reassembly. TCP stream reassembly signatures are part of the Normalizer engine.

Configuring TCP Stream Reassembly Signatures

To configure TCP stream reassembly for a specific signature, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Specify the TCP stream reassembly signature ID and subsignature ID.

sensor(config-sig)# signatures 1313 0

Step 4 Specify the engine.

sensor(config-sig-sig)# engine normalizer

Step 5 Enter edit default signatures submode.

sensor(config-sig-sig-nor)# edit-default-sigs-only default-signatures-only

Step 6 Enable and change the default setting (if desired) of the maximum MSS parameter for signature 1313.

sensor(config-sig-sig-nor-def)# specify-tcp-max-mss yes

sensor(config-sig-sig-nor-def-yes)# tcp-max-mss 1380

Note Changing this parameter from the default of 1460 to 1380 helps prevent fragmentation of traffic going through a VPN tunnel.

Step 7 Verify the settings.

sensor(config-sig-sig-nor-def-yes)# show settings

   yes

   -----------------------------------------------

      tcp-max-mss: 1380 default: 1460

   -----------------------------------------------

sensor(config-sig-sig-nor-def-yes)#

Step 8 Exit signature definition submode.

sensor(config-sig-sig-nor-def-yes)# exit

sensor(config-sig-sig-nor-def)# exit

sensor(config-sig-sig-nor)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 9 Press Enter for apply the changes or enter no to discard them.

Configuring the Mode for TCP Stream Reassembly

Use the stream-reassembly command in the signature definition submode to configure the mode that the sensor will use to reassemble TCP sessions.

Note The parameters tcp-3-way-handshake-required and tcp-reassembly-mode only impact sensors inspecting traffic in promiscuous mode, not inline mode. To configure asymmetric options for sensors inspecting inline traffic, use the inline-TCP-evasion-protection-mode parameter.

The following options apply:

•tcp-3-way-handshake-required {true | false}—Specifies that the sensor should only track sessions for which the 3-way handshake is completed. The default is true.

•tcp-reassembly-mode—Specifies the mode the sensor should use to reassemble TCP sessions.

–strict—Only allows the next expected in the sequence (default).

–loose—Allows gaps in the sequence.

–asym—Allows asymmetric traffic to be reassembled.

Caution The asymmetric option disables TCP window evasion checking.

To configure the TCP stream reassembly parameters, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter TCP stream reassembly submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

sensor(config-sig)# stream-reassembly

Step 3 Specify that the sensor should only track session for which the 3-way handshake is completed.

sensor(config-sig-str)# tcp-3-way-handshake-required true

Step 4 Specify the mode the sensor should use to reassemble TCP sessions.

sensor(config-sig-str)# tcp-reassembly-mode strict

Step 5 Verify the settings.

sensor(config-sig-str)# show settings

   stream-reassembly

   -----------------------------------------------

      tcp-3-way-handshake-required: true default: true

      tcp-reassembly-mode: strict default: strict

   -----------------------------------------------

sensor(config-sig-str)#

Step 6 Exit signature definition submode.

sensor(config-sig-str)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 7 Press Enter to apply the changes or enter no to discard them.

For More Information

For information on asymmetric inspection options for sensors configured in inline mode, see Inline TCP Session Tracking Mode and Editing and Deleting Virtual Sensors.

Configuring IP Logging

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.

Note IP logging allows a maximum limit of 20 concurrent IP log files. Once the limit of 20 is reached, you receive the following message in main.log: Cid/W errWarnIpLogProcessor::addIpLog: Ran out of file descriptors.

Use the ip-log command in the signature definition submode to configure IP logging. The following options apply:

•ip-log-bytes—Identifies the maximum number of bytes you want logged. The valid value is 0 to 2147483647. The default is 0.

•ip-log-packets—Identifies the number of packets you want logged. The valid value is 0 to 65535. The default is 0.

•ip-log-time—Identifies the duration you want the sensor to log. The valid value is 30 to 300 seconds. The default is 30 seconds.

Note When the sensor meets any one of the IP logging conditions, it stops IP logging.

To configure the IP logging parameters, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter IP log submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

sensor(config-sig)# ip-log

Step 3 Specify the IP logging parameters:

a. Specify the maximum number of bytes you want logged.

sensor(config-sig-ip)# ip-log-bytes 200000

b. Specify the number of packets you want logged.

sensor(config-sig-ip)# ip-log-packets 150

c. Specify the length of time you want the sensor to log.

sensor(config-sig-ip)# ip-log-time 60

Step 4 Verify the settings.

sensor(config-sig-ip)# show settings

   ip-log

   -----------------------------------------------

      ip-log-packets: 150 default: 0

      ip-log-time: 60 default: 30

      ip-log-bytes: 200000 default: 0

   -----------------------------------------------

sensor(config-sig-ip)#

Step 5 Exit signature definition submode.

sensor(config-sig-ip)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 6 Press Enter to apply the changes or enter no to discard them.

Creating Custom Signatures

This section describes how to create custom signatures, and contains the following topics:

•Sequence for Creating a Custom Signature

•Example String TCP Signature

•Example Service HTTP Signature

•Example Meta Signature

Sequence for Creating a Custom Signature

Use the following sequence when you create a custom signature:

Step 1 Select a signature engine.

Step 2 Assign the signature identifiers:

•Signature ID

•SubSignature ID

•Signature name

•Alert notes (optional)

•User comments (optional)

Step 3 Assign the engine-specific parameters. The parameters differ for each signature engine, although there is a group of master parameters that applies to each engine.

Step 4 Assign the alert response:

•Signature fidelity rating

•Severity of the alert

Step 5 Assign the alert behavior.

Step 6 Apply the changes.

Example String TCP Signature

The String engine is a generic-based pattern-matching inspection engine for ICMP, TCP, and UDP protocols. The String engine uses a regular expression engine that can combine multiple patterns in to a single pattern-matching table allowing for a single search through the data. There are three String engines: String ICMP, String TCP, and String UDP.

The following example demonstrates how to create a custom String TCP signature.

Note This procedure also applies to String UDP and ICMP signatures.

The following parameters apply to the String TCP engine:

•default—Sets the value back to the system default setting.

•direction—Specifies the direction of the traffic:

–from-service—Traffic from service port destined to client port.

–to-service—Traffic from client port destined to service port.

•event-action—Specifies the action(s) to perform when alert is triggered:

–deny-attacker-inline —(Inline mode only) does not transmit this packet and future packets from the attacker address for a specified period of time.

–deny-attacker-service-pair-inline—(Inline mode only) Does not transmit this packet and future packets on the attacker address victim port pair for a specified period of time.

–deny-attacker-victim-pair-inline—(Inline mode only) Does not transmit this packet and future packets on the attacker/victim address pair for a specified period of time.

–deny-connection-inline—(Inline mode only) Does not transmit this packet and future packets on the TCP Flow.

–deny-packet-inline—(Inline mode only) Does not transmit this packet.

–log-attacker-packets—Starts IP logging of packets containing the attacker address. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–log-pair-packets—Starts IP logging of packets containing the attacker-victim address pair. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–log-victim-packets—Starts IP logging of packets containing the victim address. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–produce-alert —Writes the event to Event Store as an alert.

–produce-verbose-alert—Includes an encoded dump (possibly truncated) of the offending packet in the alert. This action causes an alert to be written to the Event Store, even if produce-alert is not selected.

–request-block-connection—Sends a request to ARC to block this connection. You must have blocking devices configured to implement this action.

–request-block-host—Sends a request to ARC to block this attacker host. You must have blocking devices configured to implement this action.

–request-rate-limit—Sends a rate limit request to ARC to perform rate limiting. You must have rate limiting devices configured to implement this action.

–request-snmp-trap—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. You must have SNMP configured on the sensor to implement this action.

–reset-tcp-connection—Sends TCP resets to hijack and terminate the TCP flow. Reset TCP Connection only works on TCP signatures that analyze a single connection. It does not work for sweeps or floods.

–modify-packet-inline— Modifies packet data to remove ambiguity about what the end point might do with the packet.

•no—Removes an entry or selection setting.

•regex-string —Specifies a regular expression to search for in a single TCP packet.

•service-ports—Specifies the ports or port ranges where the target service may reside. The valid range is 0 to 65535. It is a separated list of integer ranges a-b[,c-d] within 0 to 65535. The second number in the range must be greater than or equal to the first number.

•specify-exact-match-offset {yes | no}—(Optional) Enables exact-match-offset.

•specify-min-match-length {yes | no}—(Optional) Enables min-match-length.

•strip-telnet-options—Strips Telnet option characters from data before searching.

•swap-attacker-victim {true | false}—Swaps the attacker and victim addresses and ports (source and destination) in the alert message and for any actions taken. The default is false for no swapping.

To create a signature based on the String TCP engine, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Specify a signature ID and subsignature ID for the signature.

sensor(config-sig)# signatures 60025 0

Custom signatures are in the range of 60000 to 65000.

Step 4 Enter signature description submode.

sensor(config-sig-sig)# sig-description

Step 5 Specify a name for the new signature. You can also specify a additional comments about the sig using the sig-comment command or additional information about the signature using the sig-string-info command.

sensor(config-sig-sig-sig)# sig-name This is my new name

Step 6 Exit signature description submode.

sensor(config-sig-sig-sig)# exit

Step 7 Specify the string TCP engine.

sensor(config-sig-sig)# engine string-tcp

Step 8 Specify the service ports.

sensor(config-sig-sig-str)# service-ports 23

Step 9 Specify the direction.

sensor(config-sig-sig-str)# direction to-service

Step 10 Specify the regex string to search for in the TCP packet.

sensor(config-sig-sig-str)# regex-string This-is-my-new-Sig-regex

Step 11 You can change the event actions if needed according to your security policy using the event-action command. The default event action is produce-alert.

Step 12 You can modify the following optional parameters for this custom String TCP signature:

•specify-exact-match-offset

•specify-min-match-length

•strip-telnet-options

•swap-attacker-victim.

Step 13 Verify the settings.

sensor(config-sig-sig-str)# show settings

   string-tcp

   -----------------------------------------------

      event-action: produce-alert <defaulted>

      strip-telnet-options: false <defaulted>

      specify-min-match-length

      -----------------------------------------------

         no

         -----------------------------------------------

         -----------------------------------------------

      -----------------------------------------------

      regex-string: This-is-my-new-Sig-regex

      service-ports: 23

      direction: to-service default: to-service

      specify-exact-match-offset

      -----------------------------------------------

         no

         -----------------------------------------------

            specify-max-match-offset

            -----------------------------------------------

               no

               -----------------------------------------------

               -----------------------------------------------

            -----------------------------------------------

            specify-min-match-offset

            -----------------------------------------------

               no

               -----------------------------------------------

               -----------------------------------------------

            -----------------------------------------------

         -----------------------------------------------

      -----------------------------------------------

      swap-attacker-victim: false <defaulted>

   -----------------------------------------------

sensor(config-sig-sig-str)#

Step 14 Exit signature definition submode.

sensor(config-sig-sig-str)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 15 Press Enter to apply the changes or enter no to discard them.

For More Information

For a list of the signature regular expression syntax, see Regular Expression Syntax.

Example Service HTTP Signature

The Service HTTP engine is a service-specific string-based pattern-matching inspection engine. The HTTP protocol is one of the most commonly used in the networks of today. In addition, it requires the most amount of preprocessing time and has the most number of signatures requiring inspection making it critical to the overall performance of the system.

The Service HTTP engine uses a Regex library that can combine multiple patterns in to a single pattern-matching table allowing a single search through the data. This engine searches traffic directed to web services only to web services, or HTTP requests. You cannot inspect return traffic with this engine. You can specify separate web ports of interest in each signature in this engine.

HTTP deobfuscation is the process of decoding an HTTP message by normalizing encoded characters to ASCII equivalent characters. It is also known as ASCII normalization.

Before an HTTP packet can be inspected, the data must be deobfuscated or normalized to the same representation that the target system sees when it processes the data. It is ideal to have a customized decoding technique for each host target type, which involves knowing what operating system and web server version is running on the target. The Service HTTP engine has default deobfuscation behavior for the Microsoft IIS web server.

The following options apply to the Service HTTP engine:

•de-obfuscate {true | false}—Applies anti-evasive deobfuscation before searching.

•default—Sets the value back to the system default setting.

•event-action —Specifies the action(s) to perform when alert is triggered:

–deny-attacker-inline —(Inline mode only) Does not transmit this packet and future packets from the attacker address for a specified period of time.

–deny-attacker-service-pair-inline—(Inline mode only) Does not transmit this packet and future packets on the attacker address victim port pair for a specified period of time.

–deny-attacker-victim-pair-inline—(Inline mode only) Does not transmit this packet and future packets on the attacker/victim address pair for a specified period of time.

–deny-connection-inline—(Inline mode only) Does not transmit this packet and future packets on the TCP Flow.

–deny-packet-inline—(Inline mode only) Does not transmit this packet.

–log-attacker-packets—Starts IP logging of packets containing the attacker address. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–log-pair-packets—Starts IP logging of packets containing the attacker-victim address pair. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–log-victim-packets—Starts IP logging of packets containing the victim address. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–produce-alert —Writes the event to Event Store as an alert.

–produce-verbose-alert—Includes an encoded dump (possibly truncated) of the offending packet in the alert. This action causes an alert to be written to the Event Store, even if produce-alert is not selected.

–request-block-connection—Sends a request to ARC to block this connection. You must have blocking devices configured to implement this action.

–request-block-host—Sends a request to ARC to block this attacker host. You must have blocking devices configured to implement this action.

–request-rate-limit—Sends a rate limit request to ARC to perform rate limiting. You must have rate limiting devices configured to implement this action.

–request-snmp-trap—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. You must have SNMP configured on the sensor to implement this action.

–reset-tcp-connection—Sends TCP resets to hijack and terminate the TCP flow. Reset TCP Connection only works on TCP signatures that analyze a single connection. It does not work for sweeps or floods.

–modify-packet-inline— Modifies packet data to remove ambiguity about what the end point might do with the packet.

•max-field-sizes —Enables grouping for maximum field sizes:

–specify-max-arg-field-length {yes | no}—Enables max-arg-field-length (optional).

–specify-max-header-field-length {yes | no}—Enables max-header-field-length (optional).

–specify-max-request-length {yes | no}—Enables max-request-length (optional).

–specify-max-uri-field-length {yes | no}—Enables max-uri-field-length (optional).

•no—Removes an entry or selection setting.

•regex—Enables regular expression grouping:

–specify-arg-name-regex—Enables arg-name-regex (optional).

–specify-header-regex —Enables header-regex (optional).

–specify-request-regex—Enables request-regex (optional).

–specify-uri-regex—Enables uri-regex (optional).

•service-ports —Specifies a comma-separated list of ports or port ranges where the target service may reside.

•swap-attacker-victim {true | false}—Swaps the attacker and victim addresses and ports (source and destination) in the alert message and for any actions taken. The default is false for no swapping.

To create a custom signature based on the Service HTTP engine, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Specify a signature ID and a subsignature ID for the signature. Custom signatures are in the range of 60000 to 65000.

sensor(config-sig)# signatures 63000 0 

Step 4 Enter signature description mode.

sensor(config-sig-sig)# sig-description

Step 5 Specify a signature name.

sensor(config-sig-sig-sig)# sig-name myWebSig

Step 6 Specify the alert traits. The valid range is from 0 to 65535.

sensor(config-sig-sig-sig)# alert-traits 2

Step 7 Exit signature description submode.

sensor(config-sig-sig-sig)# exit

Step 8 Specify the alert frequency:

sensor(config-sig-sig)# alert-frequency

sensor(config-sig-sig-ale)# summary-mode fire-all

sensor(config-sig-sig-ale-fir)# summary-key Axxx

sensor(config-sig-sig-ale-fir)# specify-summary-threshold yes

sensor(config-sig-sig-ale-fir-yes)# summary-threshold 200

Step 9 Exit alert frequency submode.

sensor(config-sig-sig-ale-fir-yes)# exit

sensor(config-sig-sig-ale-fir)# exit

sensor(config-sig-sig-ale)# exit

Step 10 Configure the signature to apply anti-evasive deobfuscation before searching.

sensor(config-sig-sig)# engine service-http

sensor(config-sig-sig-ser)# de-obfuscate true

Step 11 Configure the Regex parameters.

sensor(config-sig-sig)# engine service-http

sensor(config-sig-sig-ser)# regex

sensor(config-sig-sig-ser-reg)# specify-uri-regex yes

sensor(config-sig-sig-ser-reg-yes)# uri-regex [Mm][Yy][Ff][Oo][Oo]

Step 12 Exit Regex submode.

sensor(config-sig-sig-ser-reg-yes)# exit

sensor(config-sig-sig-ser-reg-)# exit

Step 13 Configure the service ports using the signature variable WEBPORTS.

sensor(config-sig-sig-ser)# service-ports $WEBPORTS

Step 14 Exit signature definition submode.

sensor(config-sig-sig-ser)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit

Apply Changes:?[yes]:

Step 15 Press Enter to apply the changes or enter no to discard them.

For More Information

For a list of the signature regular expression syntax, see Regular Expression Syntax.

Example Meta Signature

The Meta engine defines events that occur in a related manner within a sliding time interval. This engine processes events rather than packets. As signature events are generated, the Meta engine inspects them to determine if they match any or several Meta definitions. The Meta engine generates a signature event after all requirements for the event are met.

All signature events are handed off to the Meta engine by the Signature Event Action Processor. The Signature Event Action Processor hands off the event after processing the minimum hits option. Summarization and event action are processed after the Meta engine has processed the component events.

Caution A large number of Meta signatures could adversely affect overall sensor performance.

Note The Meta engine is different from other engines in that it takes alerts as input where most engines take packets as input.

The following options apply to the Meta signature engine:

•component-list—Specifies the Meta component:

–edit—Edits an existing entry in the list.

–insert name1—Inserts a new entry in to the list.

–move—Moves an entry in the list.

–begin—Places the entry at the beginning of the active list.

–end—Places the entry at the end of the active list.

–inactive—Places the entry in to the inactive list.

–before—Places the entry before the specified entry.

–after—Places the entry after the specified entry.

•component-count—Number of times component must fire before this component is satisfied.

•component-sig-id—Signature ID of the signature to match this component on.

•component-subsig-id—Subsignature ID of the signature to match this component on.

•component-list-in-order {true | false}—Whether or not to have the component list fire in order.

•event-action—Specifies the action(s) to perform when alert is triggered:

–deny-attacker-inline —(Inline mode only) Does not transmit this packet and future packets from the attacker address for a specified period of time.

–deny-attacker-service-pair-inline—(Inline mode only) Does not transmit this packet and future packets on the attacker address victim port pair for a specified period of time.

–deny-attacker-victim-pair-inline—(Inline mode only) Does not transmit this packet and future packets on the attacker/victim address pair for a specified period of time.

–deny-connection-inline—(Inline mode only) Does not transmit this packet and future packets on the TCP Flow.

–deny-packet-inline—(Inline mode only) Does not transmit this packet.

–log-attacker-packets—Starts IP logging of packets containing the attacker address. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–log-pair-packets—Starts IP logging of packets containing the attacker-victim address pair. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–log-victim-packets—Starts IP logging of packets containing the victim address. This action causes an alert to be written to Event Store, even if produce-alert is not selected.

–produce-alert —Writes the event to Event Store as an alert.

–produce-verbose-alert—Includes an encoded dump (possibly truncated) of the offending packet in the alert. This action causes an alert to be written to the Event Store, even if produce-alert is not selected.

–request-block-connection—Sends a request to ARC to block this connection. You must have blocking devices configured to implement this action.

–request-block-host—Sends a request to ARC to block this attacker host. You must have blocking devices configured to implement this action.

–request-rate-limit—Sends a rate limit request to ARC to perform rate limiting. You must have rate limiting devices configured to implement this action.

–request-snmp-trap—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. You must have SNMP configured on the sensor to implement this action.

–reset-tcp-connection—Sends TCP resets to hijack and terminate the TCP flow. Reset TCP Connection only works on TCP signatures that analyze a single connection. It does not work for sweeps or floods.

–modify-packet-inline— Modifies packet data to remove ambiguity about what the end point might do with the packet.

•meta-key—Specifies the storage type for the Meta signature:

–AaBb—Attacker and victim addresses and ports.

–AxBx—Attacker and victim addresses.

–Axxx—Attacker address.

–xxBx—Victim address.

•meta-reset-interval—Specifies the time in seconds to reset the Meta signature. The valid range is 0 to 3600 seconds. The default is 60 seconds.

Note Signature 64000 subsignature 0 will fire when it sees the alerts from signature 2000 subsignature 0 and signature 3000 subsignature 0 on the same source address. The source address selection is a result of the meta key default value of Axxx. You can change the behavior by changing the meta key setting to xxBx (destination address) for example.

To create a signature based on the Meta engine, follow these steps:

Step 1 Log in to the CLI using an account with administrator or operator privileges.

Step 2 Enter signature definition submode.

sensor# configure terminal

sensor(config)# service signature-definition sig1

Step 3 Specify a signature ID and a subsignature ID for the signature. Custom signatures are in the range of 60000 to 65000.

sensor(config-sig)# signatures 64000 0 

Step 4 Specify the signature engine.

sensor(config-sig-sig)# engine meta

Step 5 Insert a Meta signature (named c1) at the beginning of the list.

sensor(config-sig-sig-met)# component-list insert c1 begin

Step 6 Specify the signature ID of the signature on which to match this component.

sensor(config-sig-sig-met-com)# component-sig-id 2000

Step 7 Exit component list submode.

sensor(config-sig-sig-met-com)# exit

Step 8 Insert another Meta signature (named c2) at the end of the list.

sensor(config-sig-sig-met)# component-list insert c2 end 

Step 9 Specify the signature ID of the signature on which to match this component.

sensor(config-sig-sig-met-com)# component-sig-id 3000

Step 10 Verify the settings.

sensor(config-sig-sig-met-com)# exit

sensor(config-sig-sig-met)# show settings

   meta

   -----------------------------------------------

      event-action: produce-alert <defaulted>

      meta-reset-interval: 60 <defaulted>

      component-list (min: 1, max: 8, current: 2 - 2 active, 0 inactive)

      -----------------------------------------------

      ACTIVE list-contents

      -----------------------------------------------

         NAME: c1

         -----------------------------------------------

            component-sig-id: 2000

            component-subsig-id: 0 <defaulted>

            component-count: 1 <defaulted>

         -----------------------------------------------

         -----------------------------------------------

         NAME: c2

         -----------------------------------------------

            component-sig-id: 3000

            component-subsig-id: 0 <defaulted>

            component-count: 1 <defaulted>

         -----------------------------------------------

         -----------------------------------------------

      -----------------------------------------------

      meta-key

      -----------------------------------------------

         Axxx

         -----------------------------------------------

            unique-victims: 1 <defaulted>

         -----------------------------------------------

      -----------------------------------------------

      component-list-in-order: false <defaulted>

   -----------------------------------------------

sensor(config-sig-sig-met)#

Step 11 Exit signature definition submode.

sensor(config-sig-sig-met)# exit

sensor(config-sig-sig)# exit

sensor(config-sig)# exit 

Apply Changes:?[yes]:

Step 12 Press Enter to apply the changes or enter no to discard them.

For More Information

•For more information about Signature Event Action Processor, see Signature Event Action Processor.

•For more information on the Meta engine, see Meta Engine.