Configuring Event Action Rules
This chapter explains how to add event action rules policies and how to configure event action rules. It contains the following sections:
Event Action Rules Notes and Caveats
The following notes and caveats apply to configuring event action rules:
- Rate limiting and blocking are not supported for IPv6 traffic. If a signature is configured with a block or rate limit event action and is triggered by IPv6 traffic, an alert is generated but the action is not carried out.
- Global correlation inspection and the reputation filtering deny features do not support IPv6 addresses. For global correlation inspection, the sensor does not receive or process reputation data for IPv6 addresses. The risk rating for IPv6 addresses is not modified for global correlation inspection. Similarly, network participation does not include event data for attacks from IPv6 addresses. And finally, IPv6 addresses do not appear in the deny list.
- You must preface the event variable with a dollar ($) sign to indicate that you are using a variable rather than a string.
- Connection blocks and network blocks are not supported on adaptive security appliances. Adaptive security appliances only support host blocks with additional connection information.
- You cannot delete the event action override for deny-packet-inline because it is protected. If you do not want to use that override, set the override-item-status to disabled for that entry.
- Passive OS fingerprinting is enabled by default and the IPS contains a default vulnerable OS list for each signature.
Understanding Security 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. Cisco IPS 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.
Understanding Event Action Rules
Event action rules are a group of settings you configure for the event action processing component of the sensor. These rules dictate the actions the sensor performs when an event occurs. The event action processing component is responsible for the following functions:
- Calculating the risk rating
- Adding event action overrides
- Filtering event action
- Executing the resulting event action
- Summarizing and aggregating events
- Maintaining a list of denied attackers
Note Rate limiting and blocking are not supported for IPv6 traffic. If a signature is configured with a block or rate limit event action and is triggered by IPv6 traffic, an alert is generated but the action is not carried out.
Signature Event Action Processor
The Signature Event Action Processor coordinates the data flow from the signature event in the Alarm Channel to processing through the Signature Event Action Override, the Signature Event Action Filter, and the Signature Event Action Handler. It consists of the following components:
- Alarm Channel—The unit that represents the area to communicate signature events from the SensorApp inspection path to signature event handling.
- Signature Event Action Override—Adds actions based on the risk rating value. Signature Event Action Override applies to all signatures that fall in the range of the configured risk rating threshold. Each Signature Event Action Override is independent and has a separate configuration value for each action type.
- Signature Event Action Filter—Subtracts actions based on the signature ID, addresses, and risk rating of the signature event. The input to the Signature Event Action Filter is the signature event with actions possibly added by the Signature Event Action Override.
Note The Signature Event Action Filter can only subtract actions, it cannot add new actions.
The following parameters apply to the Signature Event Action Filter:
– Signature ID
– Subsignature ID
– Attacker address
– Attacker port
– Victim address
– Victim port
– Risk rating threshold range
– Actions to subtract
– Sequence identifier (optional)
– Stop-or-continue bit
– Enable action filter line bit
– Victim OS relevance or OS relevance
- Signature Event Action Handler—Performs the requested actions. The output from the Signature Event Action Handler is the actions being performed and possibly an evIdsAlert written to the Event Store.
Figure 7-1 illustrates the logical flow of the signature event through the Signature Event Action Processor and the operations performed on the action for this event. It starts with the signature event with configured action received in the Alarm Channel and flows top to bottom as the signature event passes through the functional components of the Signature Event Action Processor.
Figure 7-1 Signature Event Through Signature Event Action Processor
For More Information
For more information on risk rating, see Calculating the Risk Rating.
Event Actions
The Cisco IPS supports the following event actions. Most of the event actions belong to each signature engine unless they are not appropriate for that particular engine.
Alert and Log Actions
- produce-alert—Writes the event to the Event Store as an alert.
Note The produce-alert action is not automatic when you enable alerts for a signature. To have an alert created in the Event Store, you must select produce-alert. If you add a second action, you must include produce-alert if you want an alert sent to the Event Store. Also, every time you configure the event actions, a new list is created and it replaces the old list. Make sure you include all the event actions you need for each signature.
Note There are other event actions that force a produce-alert. These actions use produce-alert as the vehicle for performing the action. Even if produce-alert is not selected or is filtered, the alert is still produced. The actions are the following: produce-verbose-alert, request-snmp-trap, log-attacker-packets, log-victim-packets, and log-pair-packets.
Note A produce-alert event action is added for an event when global correlation has increased the risk rating of an event, and has added either the deny-packet-inline or deny-attacker-inline event action.
- produce-verbose-alert—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 produce-alert is not selected.
- log-attacker-packets—Starts IP logging on packets that contain the attacker address and sends an alert. This action causes an alert to be written to the Event Store, even if produce-alert is not selected.
- log-victim-packets—Starts IP logging on packets that contain the victim address and sends an alert. This action causes an alert to be written to the Event Store, even if produce-alert is not selected.
- log-pair-packets—Starts IP logging on packets that contain the attacker/victim address pair. This action causes an alert to be written to the Event Store, even if produce-alert is not selected.
- 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.
Deny Actions
- deny-packet-inline (inline only)—Terminates the packet.
Note You cannot delete the event action override for deny-packet-inline because it is protected. If you do not want to use that override, set the override-item-status to disabled for that entry.
- deny-connection-inline (inline only)—Terminates the current packet and future packets on this TCP flow.
- deny-attacker-victim-pair-inline (inline only)—Does not transmit this packet and future packets on the attacker/victim address pair for a specified period of time.
- deny-attacker-service-pair-inline (inline only)—Does not transmit this packet and future packets on the attacker address victim port pair for a specified period of time.
- deny-attacker-inline (inline only)—Terminates the current packet and future packets from this attacker address for a specified period of time.
The sensor maintains a list of attackers being denied by the system. To remove an entry from the denied attacker list, you can view the list of attackers and clear the entire list, or you can wait for the timer to expire. The timer is a sliding timer for each entry. Therefore, if attacker A is 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.
- modify-packet-inline (inline only)—Modifies packet data to remove ambiguity about what the end point might do with the packet.
Note You cannot use modify-packet-inline as an action when adding event action filters or overrides.
Other Actions
- request-block-connection—Sends a request to ARC to block this connection. You must have blocking devices configured to implement this action.
Note Connection blocks and network blocks are not supported on adaptive security appliances. Adaptive security appliances only support host blocks with additional connection information.
Note IPv6 does not support request-block-connection.
- request-block-host—Sends a request to ARC to block this attacker host. You must have blocking devices configured to implement this action.
Note IPv6 does not support request-block-host.
- 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.
Note The request-rate-limit action applies to a select set of signatures.
Note IPv6 does not support request-rate-limit.
- reset-tcp-connection—Sends TCP resets to hijack and terminate the TCP flow. The reset-tcp-connection action only works on TCP signatures that analyze a single connection. It does not work for sweeps or floods.
Understanding deny-packet-inline
For signatures that have deny-packet-inline configured as an action or for an event action override that adds deny-packet-inline as an action, the following actions may be taken:
- dropped-packet
- denied-flow
- tcp-one-way-reset-sent
The deny-packet-inline action is represented as a dropped packet action in the alert. When a deny-packet-inline occurs for a TCP connection, it is automatically upgraded to a deny-connection-inline action and seen as a denied flow in the alert. If the IPS denies just one packet, the TCP continues to try to send that same packet again and again, so the IPS denies the entire connection to ensure it never succeeds with the resends.
When a deny-connection-inline occurs, the IPS also automatically sends a TCP one-way reset, which shows up as a TCP one-way reset sent in the alert. When the IPS denies the connection, it leaves an open connection on both the client (generally the attacker) and the server (generally the victim). Too many open connections can result in resource problems on the victim. So the IPS sends a TCP reset to the victim to close the connection on the victim side (usually the server), which conserves the resources of the victim. It also prevents a failover that would otherwise allow the connection to fail over to a different network path and reach the victim. The IPS leaves the attacker side open and denies all traffic from it.
TCP Reset Differences Between IPS Appliances and ASA IPS Modules
The IPS appliance sends TCP reset packets to both the attacker and victim when reset-tcp-connection is selected. The IPS appliance sends a TCP reset packet only to the victim under the following circumstances:
- When a deny-packet-inline or deny-connection-inline is selected
- When TCP-based signatures and reset-tcp-connection have NOT been selected
In the case of the ASA IPS module, the TCP reset request is sent to the ASA, and the ASA then sends the TCP reset packets. The ASA sends TCP reset packets to both the attacker and victim when the reset-tcp-connection is selected. When deny-packet-inline or deny-connection-inline is selected, the ASA sends the TCP reset packet to either the attacker or victim depending on the configuration of the signature. Signatures configured to swap the attacker and victim when reporting the alert can cause the ASA to send the TCP reset packet to the attacker.
TCP Normalizer Signature Warning
You receive the following warning if you disable a default-enabled TCP Normalizer signature or remove a default-enabled modify-packet-inline, deny-packet-inline, or deny-connection-inline action:
Use caution when disabling, retiring, or changing the event action settings of a <Sig ID> TCP Normalizer signature for a sensor operating in IPS mode. The TCP Normalizer signature default values are essential for proper operation of the sensor.
If the sensor is seeing duplicate packets, consider assigning the traffic to multiple virtual sensors. If you are having problems with asymmetric or out-of-order TCP packets, consider changing the normalizer mode from strict evasion protection to asymmetric mode protection. Contact Cisco TAC if you require further assistance.
Understanding deny-packet-inline and reset-tcp-connection
Pay attention to the following when configuring deny-packet-inline and reset-tcp-connection:
- If you want to deny attack packets from reaching the victim and also reset the TCP connection for that flow, then you must configure BOTH deny-packet-inline AND reset-tcp-connection.
- Configuring reset-tcp-connection alone only resets the TCP connection but the attack packet is not denied from reaching the victim.
- Configuring deny-packet-inline alone only denies the attack packet from reaching the victim. It does not trigger a TCP reset.
For More Information
Event Action Rules Configuration Sequence
Follow these steps when configuring the event action rules component of the IPS:
1. Create any variables that you want to use in event action filters.
2. Create target value ratings. Assign target value ratings to your network assets so that you can calculate the risk rating.
3. Create overrides to add actions based on the risk rating value. Assign a risk rating to each event action type.
4. Create filters. Assign filters to subtract actions based on the ID, IP addresses, and risk rating of the signature.
5. Create OS mappings. OS mappings are used for the attack relevance rating in the calculation of the risk rating for an alert.
6. Configure the general settings. Specify whether you want to use the summarizer, the meta event generator, or configure denied attacker parameters.
Working With Event Action Rules Policies
Use the service event-action-rules name command in service event action rules submode to create an event action rules policy. The values of this event action rules policy are the same as the default event action rules policy, rules0, until you edit them. Or you can use the copy event-action-rules 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 event-action-rules-configurations command in privileged EXEC mode to list the event action rules policies. Use the no service event-action-rules name command in global configuration mode to delete an event action rules policy. Use the default service event-action-rules name command in global configuration mode to reset the event action rules policy to factory settings.
Working With Event Action Rules Policies
To create, copy, display, edit, and delete event action rules policies, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 Create an event action rules policy.
sensor# configure terminal
sensor(config)# service event-action-rules MyRules
Step 3 Copy an existing event action rules policy to a new event action rules policy.
sensor# copy event-action-rules rules0 rules1
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 event action rules policy values or edit the following parameters.
a. Add event action rules variables.
b. Configure event action rules overrides.
c. Configure event action rules filters.
d. Configure the event action rules general settings.
e. Configure the event action rules target value rating.
f. Configure the event action rules OS identification settings.
Step 5 Display a list of event action rules policies on the sensor:
sensor# list event-action-rules-configurations
Instance Size Virtual Sensor
Step 6 Delete an event action rules policy.
sensor(config)# no service event-action-rules MyRules
Note You cannot delete the default event action rules policy, rules0.
Step 7 Confirm the event action rules instance has been deleted.
sensor# list event-action-rules-configurations
Instance Size Virtual Sensor
Step 8 Reset an event action rules policy to factory settings.
sensor# configure terminal
sensor(config)# default service event-action-rules rules1
For More Information
Event Action Variables
This section describes event action variables, and contains the following topics:
Understanding Event Action Variables
Note Global correlation inspection and the reputation filtering deny features do not support IPv6 addresses. For global correlation inspection, the sensor does not receive or process reputation data for IPv6 addresses. The risk rating for IPv6 addresses is not modified for global correlation inspection. Similarly, network participation does not include event data for attacks from IPv6 addresses. And finally, IPv6 addresses do not appear in the deny list.
Note Rate limiting and blocking are not supported for IPv6 traffic. If a signature is configured with a block or rate limit event action and is triggered by IPv6 traffic, an alert is generated but the action is not carried out.
You can create event variables and then use those variables in event action filters. When you want to use the same value within multiple filters, use a variable. When you change the value of the variable, any filter that uses that variable is updated with the new value.
Note You must preface the event 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.
IPv4 Addresses
When configuring IPv4 addresses, specify the full IP address or ranges or set of ranges:
- 192.0.2.3-192.0.2.26
- 10.90.1.1
- 192.56.10.1-192.56.10.255
- 10.1.1.1-10.2.255.255, 192.0.2.3-192.0.2.26
IPv6 Addresses
When configuring IPv6 addresses, use the following format:
<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>-<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>[,<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>-<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>]
Note IPv6 addresses are 128 bits represented in hexadecimal and divided into eight 16-bit groups separated by colons. You can skip the leading zeros and you can represent the zeroed groups in the middle with a double colon (::). You must start the address with the 2001:db8 prefix.
Timesaver If you have an IP address space that applies to your engineering group and there are no Windows systems in that group, and you are not worried about any Windows-based attacks to that group, you could set up a variable to be the IP address space of the engineering group. You could then use this variable to configure a filter that would ignore all Windows-based attacks for this group.
Adding, Editing, and Deleting Event Action Variables
Note Global correlation inspection and the reputation filtering deny features do not support IPv6 addresses. For global correlation inspection, the sensor does not receive or process reputation data for IPv6 addresses. The risk rating for IPv6 addresses is not modified for global correlation inspection. Similarly, network participation does not include event data for attacks from IPv6 addresses. And finally, IPv6 addresses do not appear in the deny list.
Note Rate limiting and blocking are not supported for IPv6 traffic. If a signature is configured with a block or rate limit event action and is triggered by IPv6 traffic, an alert is generated but the action is not carried out.
Use the variables variable_name address ip_address command in service event action rules submode to create an IPv4 event action variable. The IPv4 address can be one address, a range, or ranges separated by a comma. Use the variables variable_name ipv6-address ip_address command in service event action rules submode to create an IPv6 event action variable. Use the no variables variable_name command in service event action rules submode to delete an event action variable.
Note IPv6 addresses are 128 bits represented in hexadecimal and divided into eight 16-bit groups separated by colons. You can skip the leading zeros and you can represent the zeroed groups in the middle with a double colon (::). You must start the address with the 2001:db8 prefix.
Working With Event Action Variables
To add, delete, and edit event action variables, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 Enter event action rules submode.
sensor# configure terminal
sensor(config)# service event-action-rules rules0
Step 3 Add an IPv4 event action rules variable. The valid values for address are A.B.C.D-A.B.C.D [,A.B.C.D-A.B.C.D].
sensor(config-eve)# variables variable-ipv4 address 192.0.2.3
Step 4 Add an IPv6 event action rules variable. The valid form for ipv6-address is: <XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>-<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>[,<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>-<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>]
sensor(config-eve)# variables variable-ipv6 ipv6-address 2001:0db8:3c4d:0015:0000:0000:abcd:ef12
Step 5 Verify that you added the event action rules variable.
sensor(config-eve)# show settings
variables (min: 0, max: 256, current: 2)
-----------------------------------------------
variableName: variable-ipv6
-----------------------------------------------
ipv6-address: 2001:0db8:3c4d:0015:0000:0000:abcd:ef12 default: ::0-FFFF
:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
-----------------------------------------------
variableName: variable-ipv4
-----------------------------------------------
address: 192.0.2.3 default: 0.0.0.0-255.255.255.255
-----------------------------------------------
-----------------------------------------------
Step 6 To edit an event action rules variable, change the IPv6 address to a range.
sensor(config-eve)# variables variable-ipv6 ipv6-address ::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
Step 7 Verify that you edited the event action rules variable.
sensor(config-eve)# show settings
variables (min: 0, max: 256, current: 2)
-----------------------------------------------
variableName: variable-ipv6
-----------------------------------------------
ipv6-address: ::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF default: ::0
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
-----------------------------------------------
Step 8 Delete an event action rules variable.
sensor(config-eve)# no variables variable-ipv6
Step 9 Verify the event action rules variable you deleted.
sensor(config-eve)# show settings
variables (min: 0, max: 256, current: 1)
-----------------------------------------------
variableName: variableipv4
-----------------------------------------------
address: 192.0.2.3 default: 0.0.0.0-255.255.255.255
-----------------------------------------------
-----------------------------------------------
Step 10 Exit event action rules submode.
Step 11 Press Enter to apply your changes or enter no to discard them.
Configuring Target Value Ratings
This section describes what risk rating is and how to use it to configure target value ratings. This section contains the following topics:
Calculating the Risk Rating
A risk rating (RR) is a value between 0 and 100 that represents a numerical quantification of the risk associated with a particular event on the network. The calculation takes into account the value of the network asset being attacked (for example, a particular server), so it is configured on a per-signature basis using the attack severity rating and the signature fidelity rating, and on a per-server basis using the target value rating. The risk rating is calculated from several components, some of which are configured, some collected, and some derived.
Note The risk rating is associated with alerts not signatures.
Risk ratings let you prioritize alerts that need your attention. These risk rating factors take into consideration the severity of the attack if it succeeds, the fidelity of the signature, the reputation score of the attacker from the global correlation data, and the overall value of the target host to you. The risk rating is reported in the evIdsAlert.
The following values are used to calculate the risk rating for a particular event:
- Signature fidelity rating (SFR)—A weight associated with how well this signature might perform in the absence of specific knowledge of the target. The signature fidelity rating is configured per signature and indicates how accurately the signature detects the event or condition it describes.
Signature fidelity rating is calculated by the signature author on a per-signature basis. The signature author defines a baseline confidence ranking for the accuracy of the signature in the absence of qualifying intelligence on the target. It represents the confidence that the detected behavior would produce the intended effect on the target platform if the packet under analysis were allowed to be delivered. For example, a signature that is written with very specific rules (specific regular expression) has a higher signature fidelity rating than a signature that is written with generic rules.
Note The signature fidelity rating does not indicate how bad the detected event may be.
- Attack severity rating (ASR)—A weight associated with the severity of a successful exploit of the vulnerability. The attack severity rating is derived from the alert severity parameter (informational, low, medium, or high) of the signature. The attack severity rating is configured per signature and indicates how dangerous the event detected is.
Note The attack severity rating does not indicate how accurately the event is detected.
- Target value rating (TVR)—A weight associated with the perceived value of the target.
Target value rating is a user-configurable value (zero, low, medium, high, or mission critical) that identifies the importance of a network asset (through its IP address). You can develop a security policy that is more stringent for valuable corporate resources and looser for less important resources. For example, you could assign a target value rating to the company web server that is higher than the target value rating you assign to a desktop node. In this example, attacks against the company web server have a higher risk rating than attacks against the desktop node. Target value rating is configured in the event action rules policy.
- Attack relevance rating (ARR)—A weight associated with the relevancy of the targeted operating system. Attack relevancy rating is a derived value (relevant, unknown, or not relevant), which is determined at alert time. The relevant operating systems are configured per signature.
- Promiscuous delta (PD)—A weight associated with the promiscuous delta, which can be subtracted from the overall risk rating in promiscuous mode. Promiscuous delta is in the range of 0 to 30 and is configured per signature.
Note If the trigger packet is not inline, the promiscuous delta is subtracted from the rating.
- Watch list rating (WLR)—A weight associated with the CSA MC watch list in the range of 0 to 100 (CSA MC only uses the range 0 to 35). If the attacker for the alert is found on the watch list, the watch list rating for that attacker is added to the rating.
Figure 7-2 illustrates the risk rating formula:
Figure 7-2 Risk Rating Formula
Understanding Threat Rating
\Threat rating is risk rating that has been lowered by event actions that have been taken. Nonlogging event actions have a threat rating adjustment. The largest threat rating from all the event actions taken is subtracted from the risk rating. The event actions have the following threat ratings:
- deny-attacker-inline—45
- deny-attacker-victim-pair-inline—40
- deny-attacker-service-pair-inline—40
- deny-connection-inline—35
- deny-packet-inline—35
- modify-packet-inline—35
- request-block-host—20
- request-block-connection—20
- reset-tcp-connection—20
- request-rate-limit—20
Adding, Editing, and Deleting Target Value Ratings
Note Global correlation inspection and the reputation filtering deny features do not support IPv6 addresses. For global correlation inspection, the sensor does not receive or process reputation data for IPv6 addresses. The risk rating for IPv6 addresses is not modified for global correlation inspection. Similarly, network participation does not include event data for attacks from IPv6 addresses. And finally, IPv6 addresses do not appear in the deny list.
Note Rate limiting and blocking are not supported for IPv6 traffic. If a signature is configured with a block or rate limit event action and is triggered by IPv6 traffic, an alert is generated but the action is not carried out.
You can assign a target value rating to your network assets. The target value rating is one of the factors used to calculate the risk rating value for each alert. You can assign different target value ratings to different targets. Events with a higher risk rating trigger more severe signature event actions.
For IPv4 address, use the target-value { zerovalue | low | medium | high | mission-critical } target-address ip_address command in service event action rules submode to add target value ratings for your network assets. The default is medium. Use the no target-value { zerovalue | low | medium | high | mission-critical } command in service event action rules submode to delete target value ratings.
For IPv6 addresses, use the ipv6-target-value { zerovalue | low | medium | high | mission-critical } ipv6-target-address ip_address command in service event action rules submode to add target value ratings for your network assets. The default is medium. Use the no ipv6-target-value { zerovalue | low | medium | high | mission-critical } command in service event action rules submode to delete target value ratings.
The following options apply:
- target-value —Specifies the IPv4 target value rating:
– zerovalue —No value of this target.
– low —Lower value of this target.
– medium —Normal value of this target (default).
– high —Elevated value of this target.
– mission-critical —Extreme value of this target.
- no target-value —Removes the IPv4 target value rating.
- target-address ip_address —Specifies the range set of IP address(es) for IPv4 addresses in the following form: <A.B.C.D>-<A.B.C.D>[,<A.B.C.D>-<A.B.C.D>]
- ipv6-target-value —Specifies the IPv6 target value rating:
– zerovalue —No value of this target.
– low —Lower value of this target.
– medium —Normal value of this target (default).
– high —Elevated value of this target.
– mission-critical —Extreme value of this target.
- no ipv6-target-value —Removes the IPv6 target value rating.
- ipv6-target-address ip_address —Specifies the range set of IP address(es) for IPv6 addresses in the following form: <XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>-<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>[,<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>-<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>]
Adding, Editing, and Deleting Target Value Ratings
To add, edit, and delete target value ratings for your network assets, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 Enter event action rules submode.
sensor# configure terminal
sensor(config)# service event-action-rules rules1
Step 3 Assign an IPv4 target value rating to the network asset.
sensor(config-eve)# target-value mission-critical target-address 192.0.2.0
Step 4 Assign an IPv6 target value rating to the network asset.
sensor(config-eve)# ipv6-target-value mission-critical ipv6-target-address 2001:0db8:3c4d:0015:0000:0000:abcd:ef12
Step 5 Verify that you added the target value rating.
sensor(config-eve)# show settings
-----------------------------------------------
target-value (min: 0, max: 5, current: 1)
-----------------------------------------------
target-value-setting: mission-critical
target-address: 192.0.2.0 default: 0.0.0.0-255.255.255.255
-----------------------------------------------
ipv6-target-value (min: 0, max: 5, current: 2)
-----------------------------------------------
ipv6-target-value-setting: mission-critical
ipv6-target-address: 2001:0db8:3c4d:0015:0000:0000:abcd:ef12 default: ::0-
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
-----------------------------------------------
Step 6 To edit a target value rating, change the target value rating setting of the asset.
sensor(config-eve)# target-value low target-address 192.0.2.0
Step 7 Verify that you edited the target value rating.
sensor(config-eve)# show settings
-----------------------------------------------
target-value (min: 0, max: 5, current: 1)
-----------------------------------------------
target-value-setting: low
target-address: 192.0.2.0 default: 0.0.0.0-255.255.255.255
-----------------------------------------------
Step 8 Delete the target value rating.
sensor(config-eve)# no ipv6-target-value mission-critical
Step 9 Verify that you deleted the target value rating.
sensor(config-eve)# show settings
-----------------------------------------------
ipv6-target-value (min: 0, max: 5, current: 0)
-----------------------------------------------
-----------------------------------------------
Step 10 Exit event action rules submode.
Step 11 Press Enter to apply your changes or enter no to discard them.
Configuring Event Action Overrides
This section describes event action overrides, and contains the following topics:
Understanding Event Action Overrides
You can add an event action override to change the actions associated with an event based on the risk rating of that event. Event action overrides are a way to add event actions globally without having to configure each signature individually. Each event action has an associated risk rating range. If a signature event occurs and the risk rating for that event falls within the range for an event action, that action is added to the event. For example, if you want any event with a risk rating of 85 or more to generate an SNMP trap, you can set the risk rating range for request-snmp-trap to 85-100 . If you do not want to use action overrides, you can disable the entire event action override component.
Note Connection blocks and network blocks are not supported on adaptive security appliances. Adaptive security appliances only support host blocks with additional connection information.
Adding, Editing, Enabling, and Disabling Event Action Overrides
Use the overrides { request-block-connection | request-block-host | deny-attacker-inline | deny-packet-inline | deny-attacker-service-pair-inline | deny-attacker-victim-pair-inline | deny-connection-inline | log-attacker-packets | log-victim-packets | log-pair-packets | reset-tcp-connection | produce-alert | produce-verbose-alert | request-rate-limit | request-snmp-trap } command in service event action rules submode to configure the parameters of event action overrides. Use the no overrides command in service event action rules submode to delete the parameters of event action overrides.
Note You cannot delete the event action override for deny-packet-inline because it is protected. If you do not want to use that override, set the override-item-status to disabled for that entry.
Configure the override event actions, then the risk rating range, then enable or disable the override. The following options apply:
- no overrides —Removes an entry or selection setting.
- override-item-status { enabled | disabled }—Enables or disables the use of this override item. The default is enabled.
- risk-rating-range —Specifies the range of risk rating values for this override item. The default is 0 to 100.
- show —Displays system settings and/or history information.
Configuring Event Action Overrides
To add event action overrides, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 Enter event action rules submode.
sensor# configure terminal
sensor(config)# service event-action-rules rules0
Step 3 Assign the action for the override:
- Deny packets from the source IP address of the attacker.
sensor(config-eve)# overrides deny-attacker-inline
- Do not transmit the single packet causing the alert.
sensor(config-eve)# overrides deny-packet-inline
- Do not transmit packets on the specified TCP connection.
sensor(config-eve)# overrides deny-connection-inline
- Send TCP RST packets to terminate the connection.
sensor(config-eve)# overrides reset-tcp-connection
- Request a block of the connection.
sensor(config-eve)# overrides request-block-connection
- Request a block of the attacker host.
sensor(config-eve)# overrides request-block-host
- Log the packets from the attacker IP address.
sensor(config-eve)# overrides log-attacker-packets
- Log the packets from the victim IP address.
sensor(config-eve)# overrides log-victim-packets
- Log packets from both the attacker and victim IP addresses.
sensor(config-eve)# overrides log-pair-packets
- Write an alert to Event Store.
sensor(config-eve)# overrides produce-alert
- Write verbose alerts to Event Store.
sensor(config-eve)# overrides produce-verbose-alert
- Write events that request an SNMP trap to the Event Store.
sensor(config-eve)# overrides request-snmp-trap
Step 4 Configure the risk rating for this override item. The default risk rating range is 0 to 100. Set it to a different value, such as 85 to 100.
sensor(config-eve-ove)# risk-rating-range 85-100
Step 5 Enable or disable the use of this override item. The default is enabled.
sensor(config-eve-ove)# override-item-status {enabled | disabled}
Step 6 Verify the settings.
sensor(config-eve-ove)# exit
sensor(config-eve)# show settings
action-to-add: deny-attacker-inline
-----------------------------------------------
override-item-status: Enabled default: Enabled
risk-rating-range: 85-100 default: 0-100
-----------------------------------------------
Step 7 Edit the risk rating of an event action override.
sensor(config-eve)# overrides deny-attacker-inline
sensor(config-eve-ove)# risk-rating 95-100
Step 8 Verify that you edited the event action override.
sensor(config-eve-ove)# exit
sensor(config-eve)# show settings
-----------------------------------------------
overrides (min: 0, max: 14, current: 1)
-----------------------------------------------
override-item-status: Enabled <defaulted>
risk-rating-range: 95-100 default: 0-100
-----------------------------------------------
Step 9 Delete the event action override.
sensor(config-eve)# no overrides deny-attacker-inline
Step 10 Verify that you deleted the event action override.
sensor(config-eve-ove)# exit
sensor(config-eve)# show settings
overrides (min: 0, max: 14, current: 1)
-----------------------------------------------
action-to-add: deny-attacker-inline
-----------------------------------------------
override-item-status: Enabled <defaulted>
risk-rating-range: 95 default: 0-100
-----------------------------------------------
override-item-status: Enabled <defaulted>
risk-rating-range: 90-100 <defaulted>
-----------------------------------------------
-----------------------------------------------
Step 11 Exit event action rules submode.
Step 12 Press Enter to apply your changes or enter no to discard them.
For More Information
For a detailed description of all the event actions, see Event Actions.
Configuring Event Action Filters
This section describes event action filters, and contains the following topics:
Understanding Event Action Filters
Note Global correlation inspection and the reputation filtering deny features do not support IPv6 addresses. For global correlation inspection, the sensor does not receive or process reputation data for IPv6 addresses. The risk rating for IPv6 addresses is not modified for global correlation inspection. Similarly, network participation does not include event data for attacks from IPv6 addresses. And finally, IPv6 addresses do not appear in the deny list.
Note Rate limiting and blocking are not supported for IPv6 traffic. If a signature is configured with a block or rate limit event action and is triggered by IPv6 traffic, an alert is generated but the action is not carried out.
Event action filters are processed as an ordered list and you can move filters up or down in the list. Filters let the sensor perform certain actions in response to the event without requiring the sensor to perform all actions or remove the entire event. Filters work by removing actions from an event. A filter that removes all actions from an event effectively consumes the event.
Note When filtering sweep signatures, we recommend that you do not filter the destination addresses. If there are multiple destination addresses, only the last address is used for matching the filter.
Caution Event action filters based on source and destination IP addresses do not function for the Sweep engine, because they do not filter as regular signatures. To filter source and destination IP addresses in sweep alerts, use the source and destination IP address filter parameters in the Sweep engine signatures.
Configuring Event Action Filters
Note Global correlation inspection and the reputation filtering deny features do not support IPv6 addresses. For global correlation inspection, the sensor does not receive or process reputation data for IPv6 addresses. The risk rating for IPv6 addresses is not modified for global correlation inspection. Similarly, network participation does not include event data for attacks from IPv6 addresses. And finally, IPv6 addresses do not appear in the deny list.
Note Rate limiting and blocking are not supported for IPv6 traffic. If a signature is configured with a block or rate limit event action and is triggered by IPv6 traffic, an alert is generated but the action is not carried out.
You can configure event action filters to remove specific actions from an event or to discard an entire event and prevent further processing by the sensor. You can use event action variables that you defined to group addresses for your filters.
Note You must preface the event variable with a dollar sign ($) to indicate that you are using a variable rather than a string. Otherwise, you receive the Bad source and destination
error.
Use the filters { edit | insert | move] name1 [begin | end | inactive | before | after} command in service event action rules submode to set up event action filters. The following options apply:
- actions-to-remove —Specifies the event actions to remove for this filter item.
- attacker-address-range —Specifies the range set of IPv4 attacker address(es) for this item (for example, 192.0.2.0-192.0.2.254,192.3.2.0-192.3.2.254).
Note The second IP address in the range must be greater then or equal to the first IP address. If you do not specify an attacker address range, all IPv4 attacker addresses are matched.
- attacker-port-range —Specifies the range set of attacker port(s) for this item (for example, 147-147,8000-10000).
- default —Sets the value back to the system default setting.
- deny-attacker-percentage —Specifies the percentage of packets to deny for deny attacker features. The valid range is 0 to 100. The default is 100.
- filter-item-status { enabled | disabled }—Enables or disables the use of this filter item.
- ipv6-attacker-address-range —Specifies the range set of IPv6 attacker address(es) for this item (for example, <XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>-<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>[,<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>-<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>].
Note The second IPv6 address in the range must be greater than or equal to the first IPv6 address. If you do not specify an IPv6 attacker address range, all IPv6 attacker addresses are matched.
- ipv6-victim-address-range —Specifies the range set of victim address(es) for this item (for example, <XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>-<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>[,<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>-<XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX>].
Note The second IPv6 address in the range must be greater than or equal to the first IPv6 address. If you do not specify an IPv6 victim address range, all IPv6 victim addresses are matched.
- no —Removes an entry or selection setting.
- os-relevance —Specifies the event OS relevance for this filter:
– relevant —Specifies that the event is relevant to the target OS.
– not-relevant —Specifies that the event is not relevant to the target OS.
– unknown —It is unknown whether the event is relevant to the target OS.
- risk-rating-range —Specifies the range of risk rating values for this filter item.
- signature-id-range —Specifies the range set of signature ID(s) for this item (for example, 1000-2000,3000-3000).
- stop-on-match {true | false} —Specifies to continue evaluating filters or stop when this filter item is matched.
- subsignature-id-range —Specifies the range set of subsignature ID(s) for this item (for example, 0-2,5-5).
- user-comment —Lets you add your comments about this filter item.
- victim-address-range —Specifies the range set of victim address(es) for this item (for example, 10.20.1.0-10.20.1.255,10.20.5.0-10.20.5.255).
Note The second IP address in the range must be greater then or equal to the first IP address. If you do not specify a victim address range, all IPv4 attacker addresses are matched.
- victim-port-range —Specifies the range set of victim port(s) for this item (for example, 147-147,8000-10000).
Configuring Event Action Filters
To configure event action filters, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 Enter event action rules submode.
sensor# configure terminal
sensor(config)# service event-action-rules rules1
Step 3 Create the filter name. Use name1 , name2 , and so forth to name your event action filters. Use the begin | end | inactive | before | after keywords to specify where you want to insert the filter.
sensor(config-eve)# filters insert name1 begin
Step 4 Specify the values for this filter:
a. Specify the signature ID range. The default is 900 to 65535.
sensor(config-eve-fil)# signature-id-range 1000-1005
b. Specify the subsignature ID range. The default is 0 to 255.
sensor(config-eve-fil)# subsignature-id-range 1-5
c. Specify the attacker address range for IPv4 or IPv6.
sensor(config-eve-fil)# attacker-address-range 192.0.2.3-192.0.2.26
sensor(config-eve-fil)# ipv6-attacker-address-range 2001:0db8:3c4d:0015:0000:0000:abcd:ef12
d. Specify the victim address range for IPv4 or IPv6.
sensor(config-eve-fil)# victim-address-range 192.56.10.1-192.56.10.255
sensor(config-eve-fil)# ipv6-victim-address-range ::0-FFFF:FFFF:FFFF:FFFF:FFFF:
FFFF:FFFF:FFFF
e. Specify the victim port range. The default is 0 to 65535.
sensor(config-eve-fil)# victim-port-range 0-434
f. Specify the OS relevance. The default is 0 to 100.
sensor(config-eve-fil)# os-relevance relevant
g. Specify the risk rating range.The default is 0 to 100.
sensor(config-eve-fil)# risk-rating-range 85-100
h. Specify the actions to remove.
sensor(config-eve-fil)# actions-to-remove reset-tcp-connection
i. If you are filtering a deny action, set the percentage of deny actions you want. The default is 100.
sensor(config-eve-fil)# deny-attacker-percentage 90
j. Specify the status of the filter to either disabled or enabled. The default is enabled.
sensor(config-eve-fil)# filter-item-status {enabled | disabled}
k. Specify the stop on match parameter. True tells the sensor to stop processing filters if this item matches. False tells the sensor to continue processing filters even if this item matches.
sensor(config-eve-fil)# stop-on-match {true | false}
l. Add any comments you want to use to explain this filter.
sensor(config-eve-fil)# user-comment NEW FILTER
Step 5 Verify the settings for the filter.
sensor(config-eve-fil)# show settings
-----------------------------------------------
signature-id-range: 1000-10005 default: 900-65535
subsignature-id-range: 1-5 default: 0-255
attacker-address-range: 192.0.2.3-192.0.2.26 default: 0.0.0.0-255.255.255.255
victim-address-range: 192.56.10.1-192.56.10.255 default: 0.0.0.0-255.255.255.255
ipv6-attacker-address-range: 2001:0db8:3c4d:0015:0000:0000:abcd:ef12 default: ::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
ipv6-victim-address-range: ::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF default: ::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
attacker-port-range: 0-65535 <defaulted>
victim-port-range: 1-343 default: 0-65535
risk-rating-range: 85-100 default: 0-100
actions-to-remove: reset-tcp-connection default:
deny-attacker-percentage: 90 default: 100
filter-item-status: Enabled default: Enabled
stop-on-match: True default: False
user-comment: NEW FILTER default:
os-relevance: relevant default: relevant|not-relevant|unknown
------------------------------------------------
Step 6 Edit an existing filter.
sensor(config-eve)# filters edit name1
Step 7 Edit the parameters (see Steps 4a through 4l).
Step 8 Move a filter up or down in the filter list.
sensor(config-eve-fil)# exit
sensor(config-eve)# filters move name5 before name1
Step 9 Verify that you have moved the filters.
sensor(config-eve-fil)# exit
sensor(config-eve)# show settings
-----------------------------------------------
filters (min: 0, max: 4096, current: 5 - 4 active, 1 inactive)
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
signature-id-range: 900-65535 <defaulted>
subsignature-id-range: 0-255 <defaulted>
attacker-address-range: 0.0.0.0-255.255.255.255 <defaulted>
victim-address-range: 0.0.0.0-255.255.255.255 <defaulted>
attacker-port-range: 0-65535 <defaulted>
victim-port-range: 0-65535 <defaulted>
risk-rating-range: 0-100 <defaulted>
actions-to-remove: <defaulted>
filter-item-status: Enabled <defaulted>
stop-on-match: False <defaulted>
user-comment: <defaulted>
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
signature-id-range: 900-65535 <defaulted>
subsignature-id-range: 0-255 <defaulted>
attacker-address-range: 0.0.0.0-255.255.255.255 <defaulted>
victim-address-range: 0.0.0.0-255.255.255.255 <defaulted>
attacker-port-range: 0-65535 <defaulted>
victim-port-range: 0-65535 <defaulted>
risk-rating-range: 0-100 <defaulted>
actions-to-remove: <defaulted>
filter-item-status: Enabled <defaulted>
stop-on-match: False <defaulted>
user-comment: <defaulted>
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
signature-id-range: 900-65535 <defaulted>
subsignature-id-range: 0-255 <defaulted>
attacker-address-range: 0.0.0.0-255.255.255.255 <defaulted>
victim-address-range: 0.0.0.0-255.255.255.255 <defaulted>
attacker-port-range: 0-65535 <defaulted>
victim-port-range: 0-65535 <defaulted>
risk-rating-range: 0-100 <defaulted>
actions-to-remove: <defaulted>
filter-item-status: Enabled <defaulted>
stop-on-match: False <defaulted>
user-comment: <defaulted>
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
Step 10 Move a filter to the inactive list.
sensor(config-eve)# filters move name1 inactive
Step 11 Verify that the filter has been moved to the inactive list.
sensor(config-eve-fil)# exit
sensor(config-eve)# show settings
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
signature-id-range: 900-65535 <defaulted>
subsignature-id-range: 0-255 <defaulted>
attacker-address-range: 0.0.0.0-255.255.255.255 <defaulted>
victim-address-range: 0.0.0.0-255.255.255.255 <defaulted>
attacker-port-range: 0-65535 <defaulted>
victim-port-range: 0-65535 <defaulted>
risk-rating-range: 0-100 <defaulted>
actions-to-remove: <defaulted>
filter-item-status: Enabled <defaulted>
stop-on-match: False <defaulted>
user-comment: <defaulted>
-----------------------------------------------
-----------------------------------------------
Step 12 Exit event action rules submode.
Step 13 Press Enter to apply your changes or enter no to discard them.
For More Information
Configuring OS Identifications
This section describes OS identifications and how to configure OS maps, and contains the following topics:
Understanding Passive OS Fingerprinting
Passive OS fingerprinting lets the sensor determine the OS that hosts are running. The sensor analyzes network traffic between hosts and stores the OS of these hosts with their IP addresses. The sensor inspects TCP SYN and SYNACK packets exchanged on the network to determine the OS type.
The sensor then uses the OS of the target host OS to determine the relevance of the attack to the victim by computing the attack relevance rating component of the risk rating. Based on the relevance of the attack, the sensor may alter the risk rating of the alert for the attack and/or the sensor may filter the alert for the attack. You can then use the risk rating to reduce the number of false positive alerts (a benefit in IDS mode) or definitively drop suspicious packets (a benefit in IPS mode). Passive OS fingerprinting also enhances the alert output by reporting the victim OS, the source of the OS identification, and the relevance to the victim OS in the alert.
Passive OS fingerprinting consists of three components:
- Passive OS learning—Passive OS learning occurs as the sensor observes traffic on the network. Based on the characteristics of TCP SYN and SYNACK packets, the sensor makes a determination of the OS running on the host of the source IP address.
- User-configurable OS identification—You can configure OS host maps, which take precedence over learned OS maps.
- Computation of attack relevance rating and risk rating—The sensor uses OS information to determine the relevance of the attack signature to the targeted host. The attack relevance is the attack relevance rating component of the risk rating value for the attack alert. The sensor uses the OS type reported in the host posture information imported from the CSA MC to compute the attack relevance rating.
There are three sources of OS information. The sensor ranks the sources of OS information in the following order:
1. Configured OS maps—OS maps you enter. Configured OS maps reside in the event action rules policy and can apply to one or many virtual sensors.
Note You can specify multiple operating systems for the same IP address. The last one in the list is the operating system that is matched.
2. Imported OS maps—OS maps imported from an external data source. Imported OS maps are global and apply to all virtual sensors.
Note Currently the CSA MC is the only external data source.
3. Learned OS maps—OS maps observed by the sensor through the fingerprinting of TCP packets with the SYN control bit set. Learned OS maps are local to the virtual sensor that sees the traffic.
When the sensor needs to determine the OS for a target IP address, it consults the configured OS maps. If the target IP address is not in the configured OS maps, the sensor looks in the imported OS maps. If the target IP address is not in the imported OS maps, the sensor looks in the learned OS maps. If it cannot find it there, the sensor treats the OS of the target IP address as unknown.
Note Passive OS fingerprinting is enabled by default and the IPS contains a default vulnerable OS list for each signature.
Passive OS Fingerprinting Configuration Considerations
You do not have to configure passive OS fingerprinting for it to function. IPS provides a default vulnerable OS list for each signature and passive analysis is enabled by default.
You can configure the following aspects of passive OS fingerprinting:
- Define OS maps—We recommend configuring OS maps to define the identity of the OS running on critical systems. It is best to configure OS maps when the OS and IP address of the critical systems are unlikely to change.
- Limit the attack relevance rating calculation to a specific IP address range—This limits the attack relevance rating calculations to IP addresses on the protected network.
- Import OS maps—Importing OS maps provides a mechanism for accelerating the learning rate and fidelity of the OS identifications made through passive analysis. If you have an external product interface, such as the CSA MC, you can import OS identifications from it.
- Define event action rules filters using the OS relevance value of the target—This provides a way to filter alerts solely on OS relevance.
- Disable passive analysis—Stops the sensor from learning new OS maps.
- Edit signature vulnerable OS lists—The vulnerable OS list specifies what OS types are vulnerable to each signature. The default, general-os, applies to all signatures that do not specify a vulnerable OS list.
Adding, Editing, Deleting, and Moving Configured OS Maps
Use the os-identifications command in the service event action rules submode to configure OS host mappings, which take precedence over learned OS mappings. You can add, edit, and delete configured OS maps. You can move them up and down in the list to change the order in which the sensor computes the attack relevance rating and risk rating for that particular IP address and OS type combination.
You can also move them up and down in the list to change the order in which the sensor resolves the OS associated with a particular IP address. Configured OS mappings allow for ranges, so for network 192.168.1.0/24 an administrator might define the following( Table 7-1 ):
Table 7-1 Example Configured OS Mapping
|
|
192.168.1.1 |
IOS |
192.168.1.2-192.168.1.10,192.168.1.25 |
UNIX |
192.168.1.1-192.168.1.255 |
Windows |
More specific mappings should be at the beginning of the list. Overlap in the IP address range sets is allowed, but the entry closest to the beginning of the list takes precedence. The following options apply:
- calc-arr-for-ip-range —Calculates the attack relevance rating for victims in this range. The value is <A.B.C.D>-<A.B.C.D>[,<A.B.C.D>-<A.B.C.D>], for example, 10.20.1.0-10.20.1.255,10.20.5.0-10.20.5.255).
Note The second IP address in the range must be greater than or equal to the first IP address.
- configured-os-map {edit | insert | move] name1[begin | end | inactive | before | after} —Specifies a collection of administrator-defined mappings of IP addresses to OS IDs (configured OS mappings take precedence over imported and learned OS mappings).
- ip —Specifies the host IP address (or addresses) running the specified OS. The value is <A.B.C.D>-<A.B.C.D>[,<A.B.C.D>-<A.B.C.D>], for example, 10.20.1.0-10.20.1.255,10.20.5.0-10.20.5.255.
Note The second IP address in the range must be greater than or equal to the first IP address.
- os —Specifies the OS type the host (or hosts) is running:
– general-os —All OS types
– ios —Variants of Cisco IOS
– mac-os —Variants of the Apple System OS prior to OS X
– 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 NT, 2000, and XP
– win-nt —Specific variants of Windows NT
– unknown —Unknown OS
- default —Sets the value back to the system default setting.
- no —Removes an entry or selection setting.
- passive-traffic-analysis {enabled | disabled} —Enables/disables passive OS fingerprinting analysis.
Configuring OS Maps
To configure OS maps, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 Enter event action rules submode.
sensor# configure terminal
sensor(config)# service event-action-rules rules1
Step 3 Create the OS map. Use name1 , name2 , and so forth to name your OS maps. Use the begin | end | inactive | before | after keywords to specify where you want to insert the filter.
sensor(config-eve)# os-identification
sensor(config-eve-os)# configured-os-map insert name1 begin
sensor(config-eve-os-con)#
Step 4 Specify the values for this OS map:
a. Specify the host IP address.
sensor(config-eve-os-con)# ip 192.0.2.0-192.0.2.255
b. Specify the host OS type.
sensor(config-eve-os-con)# os unix
Caution You can specify multiple operating systems for the same IP address. The last one in the list is the operating system that is matched.
Step 5 Verify the settings for the OS map.
sensor(config-eve-os-con)# show settings
-----------------------------------------------
ip: 192.0.2.0-192.0.2.255 default:
-----------------------------------------------
sensor(config-eve-os-con)#
Step 6 Specify the attack relevance rating range for the IP address.
sensor(config-eve-os-con)# exit
sensor(config-eve-os)# calc-arr-for-ip-range 192.0.2.1 to 192.0.2.25
Step 7 Enable passive OS fingerprinting.
sensor(config-eve-os)# passive-traffic-analysis enabled
Step 8 Edit an existing OS map.
sensor(config-eve-os)# configured-os-map edit name1
sensor(config-eve-os-con)#
Step 9 Edit the parameters (see Steps 4 through 7).
Step 10 Move an OS map up or down in the OS maps list.
sensor(config-eve-os-con)# exit
sensor(config-eve-os)# configured-os-map move name5 before name1
Step 11 Verify that you have moved the OS maps.
sensor(config-eve-os)# show settings
-----------------------------------------------
calc-arr-for-ip-range: 192.0.2.1-192.0.2.25 default: 0.0.0.0-255.255.255.255
configured-os-map (ordered min: 0, max: 50, current: 2 - 2 active, 0 inactive)
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
ip: 192.0.2.0-192.0.2.255 default:
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
passive-traffic-analysis: Enabled default: Enabled
-----------------------------------------------
Step 12 Move an OS map to the inactive list.
sensor(config-eve-os)# configured-os-map move name1 inactive
Step 13 Verify that the filter has been moved to the inactive list.
sensor(config-eve-os)# show settings
-----------------------------------------------
calc-arr-for-ip-range: 192.0.2.33 default: 0.0.0.0-255.255.255.255
configured-os-map (ordered min: 0, max: 50, current: 2 - 1 active, 1 inactive)
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
ip: 192.0.2.0-192.0.2.255 default:
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
passive-traffic-analysis: Enabled default: Enabled
Step 14 Delete an OS map.
sensor(config-eve-os)# no configured-os-map name2
Step 15 Verify that the OS map has been deleted.
sensor(config-eve-os)# show settings
-----------------------------------------------
calc-arr-for-ip-range: 192.0.2.33 default: 0.0.0.0-255.255.255.255
configured-os-map (ordered min: 0, max: 50, current: 1 - 0 active, 1 inactive)
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
ip: 192.0.2.0-192.0.2.255 default:
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
passive-traffic-analysis: Enabled default: Enabled
-----------------------------------------------
Step 16 Exit event action rules submode.
sensor(config-eve-os)# exit
Step 17 Press Enter to apply your changes or enter no to discard them.
Displaying and Clearing OS Identifications
Use the show os-identification [ virtual-sensor ] learned [ ip-address ] command in EXEC mode to display OS IDs associated with IP addresses that were learned by the sensor through passive analysis.
Use the clear os-identification [ virtual-sensor ] learned [ ip-address ] command in EXEC mode to delete OS IDs associated with IP addresses that were learned by the sensor through passive analysis.
When you specify an IP address, only the OS identification for the specified IP address is displayed or cleared. If you specify a virtual sensor, only the OS identifications for the specified sensor is displayed or cleared. If you specify an IP address without a virtual sensor, the IP address is displayed or cleared on all virtual sensors.
The following options apply:
- virtual-sensor —(Optional) Specifies the learned addresses of the virtual sensor that should be displayed or cleared.
- ip-address —(Optional) Specifies the IP address to query or clear. The sensor displays or clears the OS ID mapped to the specified IP address.
Displaying and Clearing OS Identifications
To display and clear OS IDs, follow these steps:
Step 1
Log in to the CLI using an account with administrator or operator privileges.
Note An account with viewer privileges can display OS IDs.
Step 2 Display the learned OS IDs associated with a specific IP address.
sensor# show os-identification learned 192.0.2.0
sensor# show os-identification learned
Step 3 Clear the learned OS IDs for a specific IP address on all virtual sensors.
sensor# clear os-identification learned 192.0.2.0
Step 4 Verify that the OS IDs have been cleared.
sensor# show statistics os-identification
Statistics for Virtual Sensor vs0
Statistics for Virtual Sensor vs1
Configuring General Settings
This section describes the general settings, and contains the following topics:
Understanding Event Action Summarization
Summarization decreases the volume of alerts sent out from the sensor by providing basic aggregation of events into a single alert. Special parameters are specified for each signature and they influence the handling of the alerts. Each signature is created with defaults that reflect a preferred normal behavior. However, you can tune each signature to change this default behavior within the constraints for each engine type.
The nonalert-generating actions (deny, block, TCP reset) go through the filters for each signature event unsummarized. The alert-generating actions are not performed on these summarized alerts; instead the actions are applied to the one summary alert and then put through the filters.
If you select one of the other alert-generating actions and do not have it filtered out, the alert is created even if you do not select produce-alert. To prevent alerts from being created, you must have all alert-generating actions filtered out.
Summarization and event actions are processed after the Meta engine has processed the component events. This lets the sensor watch for suspicious activity transpiring over a series of events.
Understanding Event Action Aggregation
Basic aggregation provides two operating modes. The simple mode involves configuring a threshold number of hits for a signature that must be met before the alert is sent. A more advanced mode is timed-interval counting. In this mode, the sensor tracks the number of hits per second and only sends alerts when that threshold is met. In this example, a hit is a term used to describe an event, which is basically an alert, but it is not sent out of the sensor as an alert until the threshold number of hits has been exceeded.
You can choose from the following summarization options:
- fire-all—Fires an alert each time the signature is triggered. If the threshold is set for summarization, alerts are fired for each execution until summarization occurs. After summarization starts, only one alert every summary interval fires for each address set. Alerts for other address sets are either all seen or separately summarized. The signature reverts to fire all mode after a period of no alerts for that signature.
- summary—Fires an alert the first time a signature is triggered, and then additional alerts for that signature are summarized for the duration of the summary interval. Only one alert every summary interval should fire for each address set. If the global summary threshold is reached, the signature goes into global summarization mode.
- global-summarization—Fires an alert for every summary interval. Signatures can be preconfigured for global summarization.
- fire-once—Fires an alert for each address set. You can upgrade this mode to global summarization mode.
Configuring the General Settings
Use the following commands in service event action rules submode to configure general event action rules settings:
- global-block-timeout —Specifies the number of minutes to block a host or connection. The valid range is 0 to 10000000. The default is 30 minutes.
- global-deny-timeout —Specifies the number of seconds to deny attackers inline. The valid range is 0 to 518400. The default is 3600.
- global-filters-status { enabled | disabled} —Enables or disables the use of the filters. The default is enabled.
- global-metaevent-status { enabled | disabled} —Enables or disables the use of the Meta Event Generator. The default is enabled.
- global-overrides-status { enabled | disabled} —Enables or disables the use of the overrides. The default is enabled.
- global-summarization-status { enabled | disabled} —Enables or disables the use of the summarizer. The default is enabled.
- max-denied-attackers —Limits the number of denied attackers possible in the system at any one time. The valid range is 0 to 100000000. The default is 10000.
Configuring Event Action General Settings
To configure event action general settings, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 Enter event action rules submode.
sensor# configure terminal
sensor(config)# service event-action-rules rules0
Step 3 Enter general submode.
Step 4 Enable or disable the meta event generator. The default is enabled.
sensor(config-eve-gen)# global-metaevent-status {enabled | disabled}
Step 5 Enable or disable the summarizer. The default is enabled.
sensor(config-eve-gen)# global-summarization-status {enabled | disabled}
Step 6 Configure the denied attackers inline event action:
a. Limit the number of denied attackers in the system at any given time. The default is 1000.
sensor(config-eve-gen)# max-denied-attackers 100
b. Configure the amount of seconds to deny attackers in the system. The default is 3600 seconds.
sensor(config-eve-gen)# global-deny-timeout 1000
Step 7 Configure the number of minutes to block a host or a connection. The default is 30 minutes.
sensor(config-eve-gen)# global-block-timeout 20
Step 8 Enable or disable any overrides that you have set up. The default is enabled.
sensor(config-eve-gen)# global-overrides-status {enabled | disabled}
Step 9 Enable or disable any filters that you have set up. The default is enabled.
sensor(config-eve-gen)# global-filters-status {enabled | disabled}
Step 10 Verify the settings for general submode.
sensor(config-eve-gen)# show settings
-----------------------------------------------
global-overrides-status: Enabled default: Enabled
global-filters-status: Enabled default: Enabled
global-summarization-status: Enabled default: Enabled
global-metaevent-status: Enabled default: Enabled
global-deny-timeout: 1000 default: 3600
global-block-timeout: 20 default: 30
max-denied-attackers: 100 default: 10000
-----------------------------------------------
Step 11 Exit event action rules submode.
sensor(config-eve-gen)# exit
Step 12 Press Enter to apply your changes or enter no to discard them.
Configuring the Denied Attackers List
This section describes the denied attackers list and how to add, clear, and monitor the list. It contains the following topics:
Adding a Deny Attacker Entry to the Denied Attackers List
Use the deny attacker [ virtual-sensor name ] [ ip-address attacker-ip-address ] | victim victim-ip-address | port port-number ] command to add a single deny attacker entry to the list of denied attackers. Use the no form of the command to delete the deny attacker entry from the list.
The following options apply:
- name —(Optional) Specifies the name of the virtual sensor to which the deny attackers entry should be added.
- attacker-ip-address —Specifies the attacker IP address.
- victim-ip-address —(Optional) Specifies the victim IP address.
- port-number —(Optional) Specifies the victim port number. The valid range is 0 to 65535.
Adding Entries to the Denied Attacker List
To add a deny attacker entry to the list of denied attackers, follow these steps:
Step 1
Log in to the CLI using an account with administrator or operator privileges.
Step 2 Add a deny attacker entry with an IP address of 192.0.2.0.
sensor# deny attacker ip-address 192.0.2.0
Warning: Executing this command will add deny attacker address on all virtual sensors.
Step 3 Enter yes to add this deny attacker entry for all virtual sensors.
Step 4 Add a deny attacker entry to a specific virtual sensor.
sensor# deny attacker virtual-sensor vs0 ip-address 192.0.2.0
Step 5 Remove the deny attacker entry from the list.
sensor# no deny attacker ip-address 10.1.1.1
Warning: Executing this command will delete this address from the list of attackers being denied by all virtual sensors.
Step 6 Enter yes to remove the deny attacker entry from the list.
Note To immediately stop denying attackers, you must use the clear denied-attackers command to clear the denied attackers list.
For More Information
For the procedure for clearing denied attackers permanently from the denied attackers list, see Monitoring and Clearing the Denied Attackers List .
Monitoring and Clearing the Denied Attackers List
Use the show statistics denied-attackers command to display the list of denied attackers. Use the clear denied-attackers [ virtual_sensor ] [ ip-address ip_address ] command to delete the denied attackers list and clear the virtual sensor statistics.
If your sensor is configured to operate in inline mode, the traffic is passing through the sensor. You can configure signatures to deny packets, connections, and attackers while in inline mode, which means that single packets, connections, and specific attackers are denied, that is, not transmitted, when the sensor encounters them. When the signature fires, the attacker is denied and placed in a list. As part of sensor administration, you may want to delete the list or clear the statistics in the list.
The following options apply:
- virtual_sensor —(Optional) Specifies the virtual sensor whose denied attackers list should be cleared.
- ip_address —(Optional) Specifies the IP address to clear.
Displaying and Deleting Denied Attackers
To display the list of denied attackers and delete the list and clear the statistics, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 Display the list of denied IP addresses. The statistics show that there are two IP addresses being denied at this time.
sensor# show statistics denied-attackers
Denied Attackers and hit count for each.
Step 3 Delete the denied attackers list.
sensor# clear denied-attackers
Warning: Executing this command will delete all addresses from the list of attackers currently being denied by the sensor.
Continue with clear? [yes]:
Step 4 Enter yes to clear the list.
Step 5 Delete the denied attackers list for a specific virtual sensor.
sensor# clear denied-attackers vs0
Warning: Executing this command will delete all addresses from the list of attackers being denied by virtual sensor vs0.
Continue with clear? [yes]:
Step 6 Enter yes to clear the list.
Step 7 Remove a specific IP address from the denied attackers list for a specific virtual sensor.
sensor# clear denied-attackers vs0 ip-address 192.0.2.0
Warning: Executing this command will delete ip address 192.0.2.0 from the list of attackers being denied by virtual sensor vs0.
Continue with clear? [yes]:
Step 8 Enter yes to clear the list.
Step 9 Verify that you have cleared the list. You can use the show statistics denied-attackers or show statistics virtual-sensor command.
sensor# show statistics denied-attackers
Denied Attackers and hit count for each.
Denied Attackers and hit count for each.
Statistics for Virtual Sensor vs0
Denied Attackers with percent denied and hit count for each.
Denied Attackers with percent denied and hit count for each.
Statistics for Virtual Sensor vs1
Denied Attackers with percent denied and hit count for each.
Denied Attackers with percent denied and hit count for each.
sensor# show statistics virtual-sensor
Virtual Sensor Statistics
Statistics for Virtual Sensor vs0
Name of current Signature-Definition instance = sig0
Name of current Event-Action-Rules instance = rules0
List of interfaces monitored by this virtual sensor = mypair
Denied Address Information
Number of Active Denied Attackers = 0
Number of Denied Attackers Inserted = 2
Number of Denied Attackers Total Hits = 287
Number of times max-denied-attackers limited creation of new entry = 0
Number of exec Clear commands during uptime = 1
Denied Attackers and hit count for each.
Step 10 Clear only the statistics.
sensor# show statistics virtual-sensor clear
Step 11 Verify that you have cleared the statistics. The statistics have all been cleared except for the Number of Active Denied Attackers and Number of exec Clear commands during uptime categories. It is important to know if the list has been cleared.
sensor# show statistics virtual-sensor
Virtual Sensor Statistics
Statistics for Virtual Sensor vs0
Name of current Signature-Definition instance = sig0
Name of current Event-Action-Rules instance = rules0
List of interfaces monitored by this virtual sensor = mypair
Denied Address Information
Number of Active Denied Attackers = 2
Number of Denied Attackers Inserted = 0
Number of Denied Attackers Total Hits = 0
Number of times max-denied-attackers limited creation of new entry = 0
Number of exec Clear commands during uptime = 1
Denied Attackers and hit count for each.
Monitoring Events
This section describes how to display and clear events from the Event Store, and contains the following topics:
Displaying Events
Note The Event Store has a fixed size of 30 MB for all platforms.
Note Events are displayed as a live feed. To cancel the request, press Ctrl-C.
Use the show events [{ alert [informational] [low] [medium] [high] [ include-traits traits ] [ exclude-traits traits ] [ min-threat-rating min-rr ] [ max-threat-rating max-rr ] | error [warning] [error] [fatal] | NAC | status }] [ hh:mm:ss [ month day [ year ]] | past hh:mm:ss ] command to display events from Event Store. Events are displayed beginning at the start time. If you do not specify a start time, events are displayed beginning at the current time. If you do not specify an event type, all events are displayed.
The following options apply:
- alert —Displays alerts. Provides notification of some suspicious activity that may indicate an attack is in process or has been attempted. Alert events are generated by the Analysis Engine whenever a signature is triggered by network activity. If no level is selected (informational, low, medium, or high), all alert events are displayed.
- include-traits —Displays alerts that have the specified traits.
- exclude-traits —Does not display alerts that have the specified traits.
- traits —Specifies the trait bit position in decimal (0 to 15).
- min-threat-rating —Displays events with a threat rating above or equal to this value. The default is 0. The valid range is 0 to 100.
- max-threat-rating—Displays events with a threat rating below or equal to this value. The default is 100. The valid range is 0 to 100.
- error —Displays error events. Error events are generated by services when error conditions are encountered. If no level is selected (warning, error, or fatal), all error events are displayed.
- NAC —Displays the ARC (block) requests.
Note The ARC is formerly known as NAC. This name change has not been completely implemented throughout the IDM, the IME, and the CLI for Cisco IPS 7.1.
- status —Displays status events.
- past —Displays events starting in the past for the specified hours, minutes, and seconds.
- hh:mm:ss —Specifies the hours, minutes, and seconds in the past to begin the display.
Note The show events command continues to display events until a specified event is available. To exit, press Ctrl-C.
Displaying Events
To display events from the Event Store, follow these steps:
Step 1
Log in to the CLI.
Step 2 Display all events starting now. The feed continues showing all events until you press Ctrl-C .
evError: eventId=1041472274774840147 severity=warning vendor=Cisco
time: 2011/01/07 04:41:45 2011/01/07 04:41:45 UTC
errorMessage: name=errWarning received fatal alert: certificate_unknown
evError: eventId=1041472274774840148 severity=error vendor=Cisco
time: 2011/01/07 04:41:45 2011/01/07 04:41:45 UTC
errorMessage: name=errTransport WebSession::sessionTask(6) TLS connection exce
ption: handshake incomplete.
Step 3 Display the block requests beginning at 10:00 a.m. on February 9, 2011.
sensor# show events NAC 10:00:00 Feb 9 2011
evShunRqst: eventId=1106837332219222281 vendor=Cisco
appName: NetworkAccessControllerApp
time: 2011/02/09 10:33:31 2011/08/09 13:13:31
host: connectionShun=false
protocol: numericType=0 other
evAlertRef: hostId=esendHost 123456789012345678
Step 4 Display errors with the warning level starting at 10:00 a.m. on February 9, 2011.
sensor# show events error warning 10:00:00 Feb 9 2011
evError: eventId=1041472274774840197 severity=warning vendor=Cisco
time: 2011/01/07 04:49:25 2011/01/07 04:49:25 UTC
errorMessage: name=errWarning received fatal alert: certificate_unknown
Step 5 Display alerts from the past 45 seconds.
sensor# show events alert past 00:00:45
evIdsAlert: eventId=1109695939102805307 severity=medium vendor=Cisco
time: 2011/03/02 14:15:59 2011/03/02 14:15:59 UTC
signature: description=Nachi Worm ICMP Echo Request id=2156 version=S54
addr: locality=OUT 10.89.228.202
addr: locality=OUT 10.89.150.185
evIdsAlert: eventId=1109695939102805308 severity=medium vendor=Cisco
Step 6 Display events that began 30 seconds in the past.
sensor# show events past 00:00:30
evStatus: eventId=1041526834774829055 vendor=Cisco
time: 2011/01/08 02:41:00 2011/01/08 02:41:00 UTC
controlTransaction: command=getVersion successful=true
description: Control transaction response.
evStatus: eventId=1041526834774829056 vendor=Cisco
time: 2011/01/08 02:41:00 2011/01/08 02:41:00 UTC
description: session opened for user cisco by cisco(uid=0)
Clearing Events from Event Store
Use the clear events command to clear the Event Store. To clear events from the Event Store, follow these steps:
Step 1
Log in to the CLI using an account with administrator privileges.
Step 2 Clear the Event Store.
Warning: Executing this command will remove all events currently stored in the event store.
Step 3 Enter yes to clear the events.