Understanding Cisco IPS Sensor Inline Traffic Normalization
The Cisco IPS Sensor traffic normalizer is a function performed by the SensorApp application in inline mode. A function of the normalizer identifies and stops users from trying low-level evasive techniques to evade detection. The normalizer ensures low-level (mostly IP and TCP) protocol conformance, tracks session state, modifies ambiguously fragmented traffic to remove ambiguities, and properly orders segments to present normalized data to application layer inspectors.
The inline traffic normalizer enforces all anti-evasion checks to traffic incoming from inline traffic sources by operating in its Strict Evasion Protection mode. The normalizer operates in this mode by default, and it is the recommended mode by Cisco best practices. The normalizer can optionally be switched to Asymmetric Mode Protection. While in Asymmetric Mode Protection, most anti-evasion countermeasures are disabled, but the sensor is able to analyze asymmetric traffic. Also in this mode, the sensor only sees one direction of a session. Asymmetric Mode Protection of the traffic normalizer should only be used if asymmetric traffic flows are being inspected and remediation cannot be done by forcing symmetric traffic flows.
Follow these steps to configure the normalizer mode for vs0 or the default virtual sensor:
Step 1. Navigate to Configuration > Policies > IPS Policies. The screen displays the list of virtual sensors at the top of the display.
Step 2. Select the vs0 virtual sensor.
Step 3. Click Edit. The Edit Virtual Sensor window opens.
Step 4. Click Advanced Options.
Step 5. Choose the normalizer mode from the following:
Configuring Cisco IPS Sensor Promiscuous Mode Traffic Reassembly Options
IP Fragment Reassembly
Step 1. From the Cisco IDM, click the Configuration button.
Step 2. Navigate to Policies > Signature Definitions.
Step 3. Select sig0 and click All Signatures.
Step 4. From the All Signatures panel, click Advanced and click the Miscellaneous tab. The Miscellaneous panel is displayed.
Step 5. Under Fragment Reassembly, select the option next to IP Reassembly Modeand choose the operating system that you want to simulate when reassembling IP fragments. You can choose one of the following values: BSD, Linux, NT, and Solaris.
TCP Stream Reassembly
By default, the Cisco IPS sensor will require that it sees a full three-way handshake for all TCP sessions, and that it sees all packets of a TCP session. If the three-way handshake isn’t seen, the sensor’s promiscuous
mode interfaces will ignore the TCP sessions that violate the requirements, which can lead to false negatives. This is why it is very important to size the Switched Port Analyzer (SPAN) ports, size the sensor, and provide symmetric routing to provide highly reliable detection.
Step 1. From the Cisco IDM, click the Configuration button.
Step 2. Navigate to Policies > Signature Definitions.
Step 3. Select sig0 and click All Signatures.
Step 4. From the All Signatures panel, click Advanced and click the Miscellaneous tab. The Miscellaneous panel is displayed.
Step 5. Under Stream Reassembly, select the TCP Handshake Required check box. Choose Yes if you want the sensor to only track sessions for which the threeway handshake is completed. If not, select No.
Step 6. Select TCP Reassembly Mode and choose one of the modes the sensor uses
for reassembling TCP sessions:
Configuring TCP Session Tracking
Cisco IPS Signature Engines and Configuring Common Signature Engine Parameters
Signature and Signature Engines
A signature is a set of rules that your sensor uses to detect malicious or suspicious network activity, such as denial of service (DoS) attacks, while scanning network packets. A signature must be enabled to monitor network traffic.
A Cisco IPS signature engine is a component of the analysis engine of the sensor that inspects network traffic and supports signatures. Each Cisco IPS signature is supported and controlled by a particular signature engine that is specifically designed for the type of traffic being monitored. Cisco IPS signature engines enable network security administrators to tune and create signatures unique to their network environment, and also have a set of parameters that have allowable ranges or set of values.
Trigger Counting
Trigger counting is a mechanism that signatures use to count the occurrence of trafficmatching events; it is also governed by the common engine parameters. Some signatures do not trigger immediately on the first occurrence of an event, as they require an event to repeat a particular number of times before it is considered malicious or suspicious. For example, a single failed login might not be suspicious, but five failed successive logins on the same host could indicate a password-cracking event or attack.
The following steps guide you in configuring trigger counting in signatures:
Step 1. In the common parameters, configure the interval in which you want to count occurrences. After the passing of each interval, the signature removes previous occurrences and starts counting from scratch. A typical value for the counting interval is 60 seconds.
Step 2. In the common parameters, configure the number of matches required to fire the signature. Configure this threshold in the Event Count parameter.
Step 3. In the common parameters, configure the criteria on which the signature counts individual events. The Event Count Key parameter determines the counting criteria and can be set to the following values:
Summary Key
The Summary Key parameter is similar to the Event Count Key parameter in trigger counting. The Summary Key parameter defines the addresses on which the signature will summarize its reporting, if configured to do so. It can have the following values:
Alarm Summarization
Summarization allows the sensor to adapt its alert rate based on the triggering rate. This is enabled by the IPS Sensorfs dynamic summarization engine, which can automatically adjust the number of alarms resulting from malicious activity. The common summarizationrelated parameters of all engines provide the sensor with an option to adapt its alert rate based on the triggering rate of a signature. The Summary Mode common engine parameter controls the number of alarms that are generated by a specific signature.
The Summary Mode parameter can have one of the following values:
Dynamic Alarm Summarization
Dynamic summarization allows the sensor to dynamically change its summarization mode for each signature to adapt itself to the signature triggering rate. To take advantage of the dynamic alert summarization, you must configure the signature to initially use the Fire All or Summarize mode. When the signature is triggered, the Cisco IPS generates the alerts according to the original Summary Mode setting. If the number of alerts for the signature exceeds the value that is configured for the Summary Threshold parameter during a summary interval, the signature automatically switches to the next higher alert mode in which fewer alerts are generated. If the number of alerts of the signature exceeds the global summary threshold during the same summary interval, the signature switches to Global Summarize if not already at this level. At the end of the summary interval, the signature reverts to its original configured summary mode.
Deploying ATOMIC Signature Engines
ATOMIC signature engines support signatures that are triggered by matching the header or payload contents of a single packet. The ATOMIC signature engines examine single packets and do not need to maintain a state; thus, they do not store any persistent data across multiple data packets, but also cannot detect data that is spread across multiple packets.
The Cisco IPS Software uses the following ATOMIC signature engines:
■ ATOMIC ARP: This engine is used to examine Address Resolution Protocol (ARP) packets. This engine is also used for detection of ARP spoofing attacks.
■ ATOMIC IP: This engine is used to examine IP, TCP, UDP, and Internet Control Message Protocol (ICMP) headers and payloads.
■ ATOMIC IP Advanced: The ATOMIC IP Advanced engine parses and interprets the IP version 6 (IPv6) header and its extensions, the IP version 4 (IPv4) header and its options, ICMP, ICMPv6, TCP, and UDP headers and payloads, and seeks out anomalies that indicate unusual or malicious activity.
■ ATOMIC IPv6: This engine detects Cisco IOS Software vulnerabilities that are simulated by malformed IPv6 traffic.
■ FIXED TCP, FIXED UDP, and FIXED ICMP: These are performance-optimized ATOMIC engines that perform a highly optimized pattern search, but only in a fixed portion of the packet headers and payload.
ATOMIC IP Signature Example
An example of a signature based on the ATOMIC IP engine is the Cisco IPS SYN/FINPacket signature. The signature matches malformed TCP packets that have both the SYN and FIN bits set. The signature uses the following illustrative common and engine-specific parameters:
■ Signature Name (common): TCP SYN/FIN packet
■ Signature ID (common): 3041/0
■ Engine (common): ATOMIC IP
■ Description (common): Triggers when a single TCP packet with the SYN and FIN flags are set and is sent to a specific host. This indicates that a reconnaissance sweep
Deploying STRING Signature Engines
The STRING signature engines support regular expression pattern matching and alarm functionality for ICMP, UDP, and TCP. This signature matches patterns based on a reassembled stream of packets and not a single packet. The STRING signature considers the arrival order of packets in a TCP stream and handles pattern matching across packet boundaries.
The Cisco IPS uses the following STRING signature engines:
STRING TCP Signature Example
An example of a signature based on the STRING TCP engine is the Cisco IPS IOS FTPd MKD Command Buffer Overflow signature. This signature matches FTP sessions that include binary data in the argument of the MKD (make directory) FTP command.
Some of the common and engine-specific parameters are as follows:
■ Signature Name (common): IOS FTPd MKD Command Buffer Overflow
■ Signature ID (common): 6973/0
■ Engine (common): STRING TCP
■ Description (common): Buffer Overflow in MKD
■ Service Ports (engine-specific): 21
■ Direction (engine-specific): To service (This indicates that the string should be
matched in the direction from the client to the server.)
■ Regex String (engine-specific): ^[mM][kK][dD]\x20[^\x0a\x0d]*[\x7f-\xff] (This
specifies the data pattern to look for inside the TCP session, which is the MKD command
followed by binary data.)
Deploying SERVICE Signature Engines
The SERVICE signature engines reassemble OSI Layer 4 sessions, decode application layer protocols, and analyze protocol and data units in the decoded stream. This provides inspection for numerous network protocols, such as Domain Name System (DNS), FTP, and HTTP.
The Cisco IPS Sensor Software uses the following SERVICE signature engines:
■ SERVICE DNS: This engine examines TCP and UDP DNS packets.
■ SERVICE FTP: This engine examines FTP traffic.
■ SERVICE Generic: This is an emergency response engine that supplements the STRING and STATE engines, and is only used by Cisco engineering to quickly createcomplex signatures for which there are no other engines available.
■ SERVICE H225: This engine examines H.225 call-signaling and call setup traffic.
■ SERVICE HTTP: This engine examines HTTP traffic.
■ SERVICE IDENT: This engine examines traffic of the IDENT protocol.
■ SERVICE MSRPC: This engine examines Microsoft Remote Procedure Call (RPC) traffic.
■ SERVICE MSSQL: This engine examines traffic used by Microsoft SQL Server.
■ SERVICE NTP: This engine examines Network Time Protocol (NTP) traffic.
■ SERVICE P2P: This engine examines peer-to-peer (P2P) traffic on all ports.
■ SERVICE RPC: This engine examines UNIX remote procedure call (RPC) traffic.
■ SERVICE SMB Advanced: This engine examines Microsoft SMB and Microsoft RPC over SMB traffic.
■ SERVICE SNMP: This engine examines Simple Network Management Protocol (SNMP) traffic.
■ SERVICE SSH: This engine examines Secure Shell (SSH) traffic.
■ SERVICE TNS: This engine examines Transparent Network Substrate (TNS) traffic. TNS is an industry-standard database network protocol, used mostly by Oracle products.
SERVICE HTTP Signature Example
An example of a signature based on the SERVICE HTTP engine is the Cisco IPS Dot Dot Slash in Uniform Resource Identifier (URI). The signature matches HTTP requests that include an attempt to traverse directories on the web server file systems indicated by the “../” pattern in the HTTP request URI.
The common and engine-specific parameters of thesignature are as follows:
■ Signature Name (common): Dot Dot Slash in URI
■ Signature ID (common): 5256/0
■ Engine (common): SERVICE HTTP
■ Description (common): ../ in URI
■ De Obfuscate (engine-specific): Yes (This specifies that the engine should convert all data to a normalized ASCII form before analyzing it.)
■ Service Ports (engine-specific): #WEBPORTS (This is a customizable variable that, by default, includes the following TCP ports: 80, 3128, 8000, 8010, 8080, 8888,and 24326.)
■ URI Regex (engine-specific): [.][.][/\\] (This specifies the data pattern to look for inside the URI container—two dots followed by a forward slash or a backslash.)
Deploying FLOOD Signature Engines
The FLOOD signature engines detect attacks in which the attacker is directing a flood of traffic to either a single host or, generally, over the sensor. Signatures of FLOOD engines measure the traffic rate and compare it to fixed per-signature thresholds to detect and reactto denial of service attacks.
The following FLOOD signature engines are included in the Cisco IPS Sensor Software:
■ FLOOD NET: Used to examine an excessive number of packets sent over the sensor (or received by the sensor in promiscuous mode).
■ FLOOD HOST: Used to examine an excessive number of Internet Control Message Protocol (ICMP) or User Datagram Protocol (UDP) packets sent to an individual target host.
FLOOD Signature Example
An example of a signature based on the FLOOD HOST engine is the Cisco IPS DNS Flood Attack. The signature examines UDP packets from port 53 (DNS replies) and triggers if the rate of such packets is more than 500 per second. Such a high rate of DNS replies is indicative of a DNS cache-poisoning attempt.
The signature uses the following common and engine-specific parameters:
■ Signature Name (common): DNS Flood Attack
■ Signature ID (common): 4004/0
■ Engine (common): FLOOD HOST
■ Description (common): This signature detects a DNS flood that could lead to potential DNS cache-poisoning, reflection, or amplification attacks.
■ Src Ports (engine-specific): 53
■ Dst Ports (engine-specific): 1–65,535
■ Rate Ports (engine-specific): 500
Deploying SWEEP Signature Engines
The SWEEP signature engines detect attacks in which one system makes connections to multiple hosts or a single host on multiple ports. The SWEEP engines are used to detect network reconnaissance.
There are two SWEEP signature engines available in the Cisco IPS Sensor:
■ SWEEP: This engine detects host sweeps, port scans, and service sweeps.
■ SWEEP Other TCP: This engine analyzes traffic between two hosts, looking for the abnormal packets that are typically used to fingerprint a victim.
SWEEP Signature Example
An example of a signature based on the SWEEP engine is the Cisco IPS TCP FIN Port Sweep. This signature examines TCP FIN packets to each host and triggers if more than five packets to different ports are seen within an inspection interval, which indicates a possibility of a port scan.
The signature uses the following common and engine-specific parameters:
■ Signature Name (common): TCP FIN Port Sweep
■ Signature ID (common): 3005/0
■ Engine (common): SWEEP
■ Description (common): Triggers when a series of TCP FIN packets have been sent to a number of privileged ports on a specific host. This is indicative of a reconnaissance sweep of the network.
■ Unique (engine-specific): 5 (This specifies the threshold number of unique port connections between the two hosts.)
■ TCP Flags (engine-specific): FIN (This must be set.)
■ Mask (engine-specific): SYN FIN ACK (These are inspected.)
■ Storage Key (common): Attacker and victim addresses
Deploying the META Signature Engine
The META engine correlates other signatures into a higher-level meta-event. Using the META engine can reduce the number of alerts that are generated by attacks from aggressive network activity. Multifactor attacks exploit a number of different vulnerabilities and can trigger several different signatures, which generate many alerts. The META engine enables you to disable the component signatures of such attacks so that they do not generate alerts, but you receive a meta-alert that the activity is happening. The main difference between the META engine and other signature engines is its input. While regular engines take network traffic as input, the META engine takes signature events as input, even events of other META signatures to provide nested event correlation.
META Correlation Example
An example of a signature based on the META engine is the Cisco IPS Worm Activity .
Brute Force. This signature observes three individual signatures and triggers if they all
trigger within 60 seconds because of the same attacker IP address.
The signature uses thefollowing common and engine-specific parameters:
■ Signature Name (common):Worm Activity . Brute Force
■ Signature ID (common): 13491/0
■ Engine (common): META
■ Description (common): This signature detects a Trojaned Windows host attempting to spread through brute-force methods. The signature tracks multiple account lock messages, attempted access to ADMIN$, and attempts at writing to the system32 directory from a single host. This signature combines signatures 5602-0, 5605-0, and 5589-0 into a single meta-signature. The signatures must be enabled and active for this signature to fire. This signature can be used to help isolate infected hosts on the network.
■ Component List (engine-specific): Signatures 5605, 5589, and 5602 (Windows Account Locked, ADMIN$ Hidden Share Access Attempt, and Windows System32 Directory File Access, respectively)
■ All Components Required (engine-specific): Yes
■ Components List in Order (engine-specific): No
■ Meta Key (engine-specific): Attacker address
■ Meta Reset Interval (engine-specific): 60 seconds
Deploying the NORMALIZER Engine
The NORMALIZER engine is not a general signature engine, but it provides the configuration interface to both normalizers. This is contained in the Cisco IPS Sensor Software as an IP traffic normalizer and a TCP traffic normalizer and removes ambiguities and anomalies from IP and TCP packets through the Modify Packet Inline action. You cannot use the NORMALIZER engine to create new signatures, but you can tune all the signatures in the NORMALIZER engine and therefore influence the operation of the IP and TCP normalizers.
NORMALIZER Engine Example
An example of a signature based on the NORMALIZER engine is the Cisco IPS TCP Segment Overwrite. This signature triggers if packets of the same TCP session exhibit data overlaps with different data at the same place in the TCP sequence number space.
The signature uses the following common parameters:
■ Signature Name (common): TCP Segment Overwrite
■ Signature ID (common): 1300/0
■ Engine (common): NORMALIZER
■ Description (common): This signature fires when one or more TCP segments in the
same stream overwrite data from one or more segments located earlier in the stream.
Deploying Other Engines
The Application Inspection and Control (AIC) engines, such as AIC HTTP and AIC FTP, provide Layer 4–7 packet inspection for HTTP and FTP. By tuning the built-in AIC engine signatures, you can create granular policies for HTTP and FTP similarly to what you can achieve with the inspect policy maps command on the Cisco ASA security appliance. The AIC HTTP provides granular control over HTTP sessions to prevent abuse of the HTTP protocol. It allows administrative control over applications that try to tunnel over specified ports. AIC also provides a way to inspect FTP traffic and control the commands being issued. Both the AIC HTTP and AIC FTP engines are disabled by default. When enabling them, examine their signatures and enable the signatures that you consider necessary. Most of their signatures are disabled as well. When enabled, there is a large performance penalty as the overall throughput of the sensor is reduced.
AIC Signature Engine Example
An example of a signature based on the AIC HTTP engine is the Cisco IPS Request Method Not Recognized. This signature observes HTTP requests and matches requests containing an unknown HTTP request method.
The signature uses the following common parameters:
■ Signature Name (common): Request Method Not Recognized
■ Signature ID (common): 12676/0
■ Engine (common): AIC HTTP
■ Description (common): The HTTP RFC provides a list of request methods such as GET, POST, and so on. You can also enter new request methods. If a method is seen that is not listed as a recognized method, this signature will take the associated action.
The Cisco IPS Sensor traffic normalizer is a function performed by the SensorApp application in inline mode. A function of the normalizer identifies and stops users from trying low-level evasive techniques to evade detection. The normalizer ensures low-level (mostly IP and TCP) protocol conformance, tracks session state, modifies ambiguously fragmented traffic to remove ambiguities, and properly orders segments to present normalized data to application layer inspectors.
The inline traffic normalizer enforces all anti-evasion checks to traffic incoming from inline traffic sources by operating in its Strict Evasion Protection mode. The normalizer operates in this mode by default, and it is the recommended mode by Cisco best practices. The normalizer can optionally be switched to Asymmetric Mode Protection. While in Asymmetric Mode Protection, most anti-evasion countermeasures are disabled, but the sensor is able to analyze asymmetric traffic. Also in this mode, the sensor only sees one direction of a session. Asymmetric Mode Protection of the traffic normalizer should only be used if asymmetric traffic flows are being inspected and remediation cannot be done by forcing symmetric traffic flows.
Follow these steps to configure the normalizer mode for vs0 or the default virtual sensor:
Step 1. Navigate to Configuration > Policies > IPS Policies. The screen displays the list of virtual sensors at the top of the display.
Step 2. Select the vs0 virtual sensor.
Step 3. Click Edit. The Edit Virtual Sensor window opens.
Step 4. Click Advanced Options.
Step 5. Choose the normalizer mode from the following:
■ Strict Evasion Protection: The default mode that fully enforces TCP state and sequence tracking.
■ Asymmetric Mode Protection: Disables most of the normalizer checks. Used typically when the entire stream cannot be inspected.
Configuring Cisco IPS Sensor Promiscuous Mode Traffic Reassembly Options
IP Fragment Reassembly
- Linux mode
- Solaris mode
- BSD mode (typically used by IP stacks derived from the BSD UNIX TCP/IP implementation, which includes Mac OS X and many others)
- NT mode (this is the default setting, and includes all Microsoft Windows TCP/IP stacks)
Step 1. From the Cisco IDM, click the Configuration button.
Step 2. Navigate to Policies > Signature Definitions.
Step 3. Select sig0 and click All Signatures.
Step 4. From the All Signatures panel, click Advanced and click the Miscellaneous tab. The Miscellaneous panel is displayed.
Step 5. Under Fragment Reassembly, select the option next to IP Reassembly Modeand choose the operating system that you want to simulate when reassembling IP fragments. You can choose one of the following values: BSD, Linux, NT, and Solaris.
TCP Stream Reassembly
By default, the Cisco IPS sensor will require that it sees a full three-way handshake for all TCP sessions, and that it sees all packets of a TCP session. If the three-way handshake isn’t seen, the sensor’s promiscuous
mode interfaces will ignore the TCP sessions that violate the requirements, which can lead to false negatives. This is why it is very important to size the Switched Port Analyzer (SPAN) ports, size the sensor, and provide symmetric routing to provide highly reliable detection.
■ Loose: There can be gaps in the sequence space and the session is still analyzed
while many anti-evasion checks are disabled.
■ Strict: The default setting and recommended by Cisco best practices. The sensor
must see all packets of a session to reassemble.
■ Asymmetric: Traffic is only in one direction and is enough to analyze, but most antievasion
checks are disabled.
Step 1. From the Cisco IDM, click the Configuration button.
Step 2. Navigate to Policies > Signature Definitions.
Step 3. Select sig0 and click All Signatures.
Step 4. From the All Signatures panel, click Advanced and click the Miscellaneous tab. The Miscellaneous panel is displayed.
Step 5. Under Stream Reassembly, select the TCP Handshake Required check box. Choose Yes if you want the sensor to only track sessions for which the threeway handshake is completed. If not, select No.
Step 6. Select TCP Reassembly Mode and choose one of the modes the sensor uses
for reassembling TCP sessions:
- Loose: This option can consume excessive resources on the sensor, so it should be used only in environments where packets might be dropped.
- Strict: The default setting.
- Asymmetric: This option disables TCP window evasion checking andallows asymmetric traffic.
Step 7. Click Apply to apply the changes and save the revised configuration.
Configuring TCP Session Tracking
- Interface and VLAN: Packets of the same network connection in the same VLAN orinline VLAN pair and on the same interface belong to the same session. Packets ofthe same network connection, but on different VLANs or interfaces, are tracked separately.This option is typically used when the same network connection crosses thesensor more than once.
- VLAN Only: Packets of the same network connection in the same VLAN or inlineVLAN pair regardless of the interface belong to the same session. Packets of the same network connection but on different VLANs are tracked separately. This option is typically used when the same connection is present in multiple VLANs on the same interface or interface pair.
- Virtual Sensor: This is the default and almost always the best option to choose. Packets of the same network connection within a virtual sensor belong to the same session.
Follow these steps to configure TCP session-tracking mode for the default virtual sensor:
Step 1. Navigate to Configuration > Policies > IPS Policies. The upper half of the screen displays the list of virtual sensors.
Step 2. Select the default virtual sensor, vs0.
Step 3. Click Edit. The Edit Virtual Sensor window opens.
Step 4. Click Advanced Options.
Step 5. From the Inline TCP Session Tracking Mode drop-down menu, select one of these possibilities:
- Interface and VLAN
- VLAN Only
- Virtual Sensor (default mode)
Cisco IPS Signature Engines and Configuring Common Signature Engine Parameters
Signature and Signature Engines
A signature is a set of rules that your sensor uses to detect malicious or suspicious network activity, such as denial of service (DoS) attacks, while scanning network packets. A signature must be enabled to monitor network traffic.
A Cisco IPS signature engine is a component of the analysis engine of the sensor that inspects network traffic and supports signatures. Each Cisco IPS signature is supported and controlled by a particular signature engine that is specifically designed for the type of traffic being monitored. Cisco IPS signature engines enable network security administrators to tune and create signatures unique to their network environment, and also have a set of parameters that have allowable ranges or set of values.
Trigger Counting
Trigger counting is a mechanism that signatures use to count the occurrence of trafficmatching events; it is also governed by the common engine parameters. Some signatures do not trigger immediately on the first occurrence of an event, as they require an event to repeat a particular number of times before it is considered malicious or suspicious. For example, a single failed login might not be suspicious, but five failed successive logins on the same host could indicate a password-cracking event or attack.
The following steps guide you in configuring trigger counting in signatures:
Step 1. In the common parameters, configure the interval in which you want to count occurrences. After the passing of each interval, the signature removes previous occurrences and starts counting from scratch. A typical value for the counting interval is 60 seconds.
Step 2. In the common parameters, configure the number of matches required to fire the signature. Configure this threshold in the Event Count parameter.
Step 3. In the common parameters, configure the criteria on which the signature counts individual events. The Event Count Key parameter determines the counting criteria and can be set to the following values:
■ Attacker address: The signature maintains a separate counter for each attacker.
■ Attacker address and victim port: The signature maintains a separate counter for each attacker-service pair.
■ Attacker and victim addresses: The signature maintains a separate counter for each pair of communicating hosts.
■ Inside a single Layer 4 session: The signature maintains a separatecounter for each Layer 4 session.
■ Victim address: The signature maintains a separate counter for each target.
Summary Key
The Summary Key parameter is similar to the Event Count Key parameter in trigger counting. The Summary Key parameter defines the addresses on which the signature will summarize its reporting, if configured to do so. It can have the following values:
■ Attacker address only: Axxx
■ Attacker and victim addresses: AxBx
■ Attacker address and victim port: Axxb
■ Attacker and victim addresses and ports: AaBb
Alarm Summarization
Summarization allows the sensor to adapt its alert rate based on the triggering rate. This is enabled by the IPS Sensorfs dynamic summarization engine, which can automatically adjust the number of alarms resulting from malicious activity. The common summarizationrelated parameters of all engines provide the sensor with an option to adapt its alert rate based on the triggering rate of a signature. The Summary Mode common engine parameter controls the number of alarms that are generated by a specific signature.
The Summary Mode parameter can have one of the following values:
- Fire Once: The signature will generate a single alarm in a configurable summary interval time range for each unique Summary Key entry. This setting is generally not recommended.
- Fire All: The signature will generate an alarm each time the signature triggers. This is an optimal choice if the signature trigger rate is low.
- Summarize: The signature will send a summary alert once each interval for each unique key entry. This consolidates alarms for the address set specified in the Summary Key parameter. This mode also limits the number of alarms that are generated, which makes it difficult for an attacker to consume resources on the sensor or overwhelm the administrator with alerts.
- Global Summarize: This signature consolidates alarms for all address combinations (that is, without a summary key). The Global Summarize node specifies that you want the sensor to send an alert the first time that a signature fires on an address set and then send only a global summary alert that includes a summary of all the alerts for all address sets over a given time interval.
Dynamic Alarm Summarization
Dynamic summarization allows the sensor to dynamically change its summarization mode for each signature to adapt itself to the signature triggering rate. To take advantage of the dynamic alert summarization, you must configure the signature to initially use the Fire All or Summarize mode. When the signature is triggered, the Cisco IPS generates the alerts according to the original Summary Mode setting. If the number of alerts for the signature exceeds the value that is configured for the Summary Threshold parameter during a summary interval, the signature automatically switches to the next higher alert mode in which fewer alerts are generated. If the number of alerts of the signature exceeds the global summary threshold during the same summary interval, the signature switches to Global Summarize if not already at this level. At the end of the summary interval, the signature reverts to its original configured summary mode.
Deploying ATOMIC Signature Engines
ATOMIC signature engines support signatures that are triggered by matching the header or payload contents of a single packet. The ATOMIC signature engines examine single packets and do not need to maintain a state; thus, they do not store any persistent data across multiple data packets, but also cannot detect data that is spread across multiple packets.
The Cisco IPS Software uses the following ATOMIC signature engines:
■ ATOMIC ARP: This engine is used to examine Address Resolution Protocol (ARP) packets. This engine is also used for detection of ARP spoofing attacks.
■ ATOMIC IP: This engine is used to examine IP, TCP, UDP, and Internet Control Message Protocol (ICMP) headers and payloads.
■ ATOMIC IP Advanced: The ATOMIC IP Advanced engine parses and interprets the IP version 6 (IPv6) header and its extensions, the IP version 4 (IPv4) header and its options, ICMP, ICMPv6, TCP, and UDP headers and payloads, and seeks out anomalies that indicate unusual or malicious activity.
■ ATOMIC IPv6: This engine detects Cisco IOS Software vulnerabilities that are simulated by malformed IPv6 traffic.
■ FIXED TCP, FIXED UDP, and FIXED ICMP: These are performance-optimized ATOMIC engines that perform a highly optimized pattern search, but only in a fixed portion of the packet headers and payload.
ATOMIC IP Signature Example
An example of a signature based on the ATOMIC IP engine is the Cisco IPS SYN/FINPacket signature. The signature matches malformed TCP packets that have both the SYN and FIN bits set. The signature uses the following illustrative common and engine-specific parameters:
■ Signature Name (common): TCP SYN/FIN packet
■ Signature ID (common): 3041/0
■ Engine (common): ATOMIC IP
■ Description (common): Triggers when a single TCP packet with the SYN and FIN flags are set and is sent to a specific host. This indicates that a reconnaissance sweep
Deploying STRING Signature Engines
The STRING signature engines support regular expression pattern matching and alarm functionality for ICMP, UDP, and TCP. This signature matches patterns based on a reassembled stream of packets and not a single packet. The STRING signature considers the arrival order of packets in a TCP stream and handles pattern matching across packet boundaries.
The Cisco IPS uses the following STRING signature engines:
- STRING ICMP: This engine searches ICMP packets for a string pattern.
- STRING TCP: This engine searches TCP connections for a string pattern.
- STRING UDP: This engine searches UDP flows for a string pattern.
- MULTI STRING: This engine searches through multiple independent connections to find multiple strings.
An example of a signature based on the STRING TCP engine is the Cisco IPS IOS FTPd MKD Command Buffer Overflow signature. This signature matches FTP sessions that include binary data in the argument of the MKD (make directory) FTP command.
Some of the common and engine-specific parameters are as follows:
■ Signature Name (common): IOS FTPd MKD Command Buffer Overflow
■ Signature ID (common): 6973/0
■ Engine (common): STRING TCP
■ Description (common): Buffer Overflow in MKD
■ Service Ports (engine-specific): 21
■ Direction (engine-specific): To service (This indicates that the string should be
matched in the direction from the client to the server.)
■ Regex String (engine-specific): ^[mM][kK][dD]\x20[^\x0a\x0d]*[\x7f-\xff] (This
specifies the data pattern to look for inside the TCP session, which is the MKD command
followed by binary data.)
Deploying SERVICE Signature Engines
The SERVICE signature engines reassemble OSI Layer 4 sessions, decode application layer protocols, and analyze protocol and data units in the decoded stream. This provides inspection for numerous network protocols, such as Domain Name System (DNS), FTP, and HTTP.
The Cisco IPS Sensor Software uses the following SERVICE signature engines:
■ SERVICE DNS: This engine examines TCP and UDP DNS packets.
■ SERVICE FTP: This engine examines FTP traffic.
■ SERVICE Generic: This is an emergency response engine that supplements the STRING and STATE engines, and is only used by Cisco engineering to quickly createcomplex signatures for which there are no other engines available.
■ SERVICE H225: This engine examines H.225 call-signaling and call setup traffic.
■ SERVICE HTTP: This engine examines HTTP traffic.
■ SERVICE IDENT: This engine examines traffic of the IDENT protocol.
■ SERVICE MSRPC: This engine examines Microsoft Remote Procedure Call (RPC) traffic.
■ SERVICE MSSQL: This engine examines traffic used by Microsoft SQL Server.
■ SERVICE NTP: This engine examines Network Time Protocol (NTP) traffic.
■ SERVICE P2P: This engine examines peer-to-peer (P2P) traffic on all ports.
■ SERVICE RPC: This engine examines UNIX remote procedure call (RPC) traffic.
■ SERVICE SMB Advanced: This engine examines Microsoft SMB and Microsoft RPC over SMB traffic.
■ SERVICE SNMP: This engine examines Simple Network Management Protocol (SNMP) traffic.
■ SERVICE SSH: This engine examines Secure Shell (SSH) traffic.
■ SERVICE TNS: This engine examines Transparent Network Substrate (TNS) traffic. TNS is an industry-standard database network protocol, used mostly by Oracle products.
SERVICE HTTP Signature Example
An example of a signature based on the SERVICE HTTP engine is the Cisco IPS Dot Dot Slash in Uniform Resource Identifier (URI). The signature matches HTTP requests that include an attempt to traverse directories on the web server file systems indicated by the “../” pattern in the HTTP request URI.
The common and engine-specific parameters of thesignature are as follows:
■ Signature Name (common): Dot Dot Slash in URI
■ Signature ID (common): 5256/0
■ Engine (common): SERVICE HTTP
■ Description (common): ../ in URI
■ De Obfuscate (engine-specific): Yes (This specifies that the engine should convert all data to a normalized ASCII form before analyzing it.)
■ Service Ports (engine-specific): #WEBPORTS (This is a customizable variable that, by default, includes the following TCP ports: 80, 3128, 8000, 8010, 8080, 8888,and 24326.)
■ URI Regex (engine-specific): [.][.][/\\] (This specifies the data pattern to look for inside the URI container—two dots followed by a forward slash or a backslash.)
Deploying FLOOD Signature Engines
The FLOOD signature engines detect attacks in which the attacker is directing a flood of traffic to either a single host or, generally, over the sensor. Signatures of FLOOD engines measure the traffic rate and compare it to fixed per-signature thresholds to detect and reactto denial of service attacks.
The following FLOOD signature engines are included in the Cisco IPS Sensor Software:
■ FLOOD NET: Used to examine an excessive number of packets sent over the sensor (or received by the sensor in promiscuous mode).
■ FLOOD HOST: Used to examine an excessive number of Internet Control Message Protocol (ICMP) or User Datagram Protocol (UDP) packets sent to an individual target host.
FLOOD Signature Example
An example of a signature based on the FLOOD HOST engine is the Cisco IPS DNS Flood Attack. The signature examines UDP packets from port 53 (DNS replies) and triggers if the rate of such packets is more than 500 per second. Such a high rate of DNS replies is indicative of a DNS cache-poisoning attempt.
The signature uses the following common and engine-specific parameters:
■ Signature Name (common): DNS Flood Attack
■ Signature ID (common): 4004/0
■ Engine (common): FLOOD HOST
■ Description (common): This signature detects a DNS flood that could lead to potential DNS cache-poisoning, reflection, or amplification attacks.
■ Src Ports (engine-specific): 53
■ Dst Ports (engine-specific): 1–65,535
■ Rate Ports (engine-specific): 500
Deploying SWEEP Signature Engines
The SWEEP signature engines detect attacks in which one system makes connections to multiple hosts or a single host on multiple ports. The SWEEP engines are used to detect network reconnaissance.
There are two SWEEP signature engines available in the Cisco IPS Sensor:
■ SWEEP: This engine detects host sweeps, port scans, and service sweeps.
■ SWEEP Other TCP: This engine analyzes traffic between two hosts, looking for the abnormal packets that are typically used to fingerprint a victim.
SWEEP Signature Example
An example of a signature based on the SWEEP engine is the Cisco IPS TCP FIN Port Sweep. This signature examines TCP FIN packets to each host and triggers if more than five packets to different ports are seen within an inspection interval, which indicates a possibility of a port scan.
The signature uses the following common and engine-specific parameters:
■ Signature Name (common): TCP FIN Port Sweep
■ Signature ID (common): 3005/0
■ Engine (common): SWEEP
■ Description (common): Triggers when a series of TCP FIN packets have been sent to a number of privileged ports on a specific host. This is indicative of a reconnaissance sweep of the network.
■ Unique (engine-specific): 5 (This specifies the threshold number of unique port connections between the two hosts.)
■ TCP Flags (engine-specific): FIN (This must be set.)
■ Mask (engine-specific): SYN FIN ACK (These are inspected.)
■ Storage Key (common): Attacker and victim addresses
Deploying the META Signature Engine
The META engine correlates other signatures into a higher-level meta-event. Using the META engine can reduce the number of alerts that are generated by attacks from aggressive network activity. Multifactor attacks exploit a number of different vulnerabilities and can trigger several different signatures, which generate many alerts. The META engine enables you to disable the component signatures of such attacks so that they do not generate alerts, but you receive a meta-alert that the activity is happening. The main difference between the META engine and other signature engines is its input. While regular engines take network traffic as input, the META engine takes signature events as input, even events of other META signatures to provide nested event correlation.
META Correlation Example
An example of a signature based on the META engine is the Cisco IPS Worm Activity .
Brute Force. This signature observes three individual signatures and triggers if they all
trigger within 60 seconds because of the same attacker IP address.
The signature uses thefollowing common and engine-specific parameters:
■ Signature Name (common):Worm Activity . Brute Force
■ Signature ID (common): 13491/0
■ Engine (common): META
■ Description (common): This signature detects a Trojaned Windows host attempting to spread through brute-force methods. The signature tracks multiple account lock messages, attempted access to ADMIN$, and attempts at writing to the system32 directory from a single host. This signature combines signatures 5602-0, 5605-0, and 5589-0 into a single meta-signature. The signatures must be enabled and active for this signature to fire. This signature can be used to help isolate infected hosts on the network.
■ Component List (engine-specific): Signatures 5605, 5589, and 5602 (Windows Account Locked, ADMIN$ Hidden Share Access Attempt, and Windows System32 Directory File Access, respectively)
■ All Components Required (engine-specific): Yes
■ Components List in Order (engine-specific): No
■ Meta Key (engine-specific): Attacker address
■ Meta Reset Interval (engine-specific): 60 seconds
Deploying the NORMALIZER Engine
The NORMALIZER engine is not a general signature engine, but it provides the configuration interface to both normalizers. This is contained in the Cisco IPS Sensor Software as an IP traffic normalizer and a TCP traffic normalizer and removes ambiguities and anomalies from IP and TCP packets through the Modify Packet Inline action. You cannot use the NORMALIZER engine to create new signatures, but you can tune all the signatures in the NORMALIZER engine and therefore influence the operation of the IP and TCP normalizers.
NORMALIZER Engine Example
An example of a signature based on the NORMALIZER engine is the Cisco IPS TCP Segment Overwrite. This signature triggers if packets of the same TCP session exhibit data overlaps with different data at the same place in the TCP sequence number space.
The signature uses the following common parameters:
■ Signature Name (common): TCP Segment Overwrite
■ Signature ID (common): 1300/0
■ Engine (common): NORMALIZER
■ Description (common): This signature fires when one or more TCP segments in the
same stream overwrite data from one or more segments located earlier in the stream.
Deploying Other Engines
The Application Inspection and Control (AIC) engines, such as AIC HTTP and AIC FTP, provide Layer 4–7 packet inspection for HTTP and FTP. By tuning the built-in AIC engine signatures, you can create granular policies for HTTP and FTP similarly to what you can achieve with the inspect policy maps command on the Cisco ASA security appliance. The AIC HTTP provides granular control over HTTP sessions to prevent abuse of the HTTP protocol. It allows administrative control over applications that try to tunnel over specified ports. AIC also provides a way to inspect FTP traffic and control the commands being issued. Both the AIC HTTP and AIC FTP engines are disabled by default. When enabling them, examine their signatures and enable the signatures that you consider necessary. Most of their signatures are disabled as well. When enabled, there is a large performance penalty as the overall throughput of the sensor is reduced.
AIC Signature Engine Example
An example of a signature based on the AIC HTTP engine is the Cisco IPS Request Method Not Recognized. This signature observes HTTP requests and matches requests containing an unknown HTTP request method.
The signature uses the following common parameters:
■ Signature Name (common): Request Method Not Recognized
■ Signature ID (common): 12676/0
■ Engine (common): AIC HTTP
■ Description (common): The HTTP RFC provides a list of request methods such as GET, POST, and so on. You can also enter new request methods. If a method is seen that is not listed as a recognized method, this signature will take the associated action.
Комментариев нет:
Отправить комментарий