Foundation and Supplemental Topics


IDS Evasion Techniques

Attackers are continually trying to find ways to bypass the protection barriers in security mechanisms. Bank robbers are constantly searching for ways to bypass traditional burglar alarms so that they can steal money without being detected. In the same way, attackers are continually trying to find ways to attack your network without being detected. Understanding the following common evasion techniques helps you ensure that these avenues do not create weaknesses in your overall security posture:

  • Flooding

  • Fragmentation

  • Encryption

  • Obfuscation

  • TTL manipulation

Flooding

One way attackers attempt to bypass your IPS is by flooding the network with intrusive activity. The goal of this flood is to generate thousands of alarms on your IPS console. Then in the middle of this overwhelming volume of alarm traffic, the attacker conducts the real attack. Attackers hope that you will not be able to detect the real attack in the middle of all the bogus attack traffic, or respond to it in a timely manner. Unless your IPS has an efficient mechanism for consolidating this flood of alarm traffic, looking for the real intrusive activity can be similar to looking for a needle in a haystack.

Generating a flood of alarm traffic can also wreak havoc on your sensor's resources. Depending on the attack traffic being flooded, an attacker may attempt to consume all of the memory or CPU processing power on your sensor. If an attacker can consume a large amount of the resources on your sensor with bogus attacks, the sensor may not have enough resources left to detect the actual attack against your network.

Fragmentation

When network packets exceed the maximum size (known as the maximum transmission unit [MTU]), they must be cut into multiple packets in a process known as fragmentation. When the receiving host gets the fragmented packets, it must reassemble the data. Not all hosts perform the reassembly process in the same order. Some operating systems start with the last fragment and work toward the first. Others start at the first fragment and work toward the last. For normal network traffic, the reassembly order does not matter, because the fragments do not overlap. Fragments that do overlap (known as overwriting fragments) have different contents and therefore provide varying results depending on the reassembly process used. Attackers can send attacks inside overwriting fragments to try to circumvent network-based IPSs. For example, assume that a packet is divided into the three fragments shown in Figure 8-1. If the fragments are reassembled from first to last, the assembly order is fragment A, fragment B, and fragment C. In this reassembled packet, the last 25 bytes of fragment B are overwritten by the first 25 bytes of fragment C. On the other hand, assembling the packet from last to first results in the last 25 bytes of fragment B overwriting the first 25 bytes of fragment C. This area of overlap is where an attacker will attempt to hide attack traffic. To completely analyze fragmented packets, a network sensor must reassemble the fragments in both orders. Another way to handle this problem is to generate an alarm when overwriting fragments are detected, because overwriting fragments should not occur in normal traffic.

Figure 8-1. Overlapping Fragments


Note

When two fragments contain data for the same portion of a packet, they are known as overlapping fragments because the two segments overlap each other. If the data in the overlapping sections is not the same, the fragments are known as overwriting fragments. With overlapping fragments, the reassembly of the packet always produces the same result. With overwriting fragments, however, the reassembly order determines the final contents of the packet.


Reassembling fragmented traffic also requires your sensor to store all the individual fragments. This storage consumes memory resources on your IPS sensors. An attacker may send a flood of incomplete fragmented traffic to cause your sensor to consume memory, hoping to launch the real attack after the sensor is low on system resources.

Encryption

One of the drawbacks of a network-based IPS is that it relies on traffic being sent across the network in clear text. If the data traversing the network is encrypted, your network-based IPS is not capable of examining that data. To protect user credentials and other sensitive information, users and network designers increasingly rely on encrypted sessions. Common examples of encrypted sessions include the following:

  • Secure Socket Layer (SSL) connections to secure websites

  • Secure Shell Host (SSH) connections to SSH servers

  • Site-to-site Virtual Private Network (VPN) tunnels

  • Client-to-LAN VPN tunnels

An attacker who establishes an SSL connection to your web server may then attempt to launch an attack against the website through the established secure connection. Since the traffic is encrypted, your network-based IPS will not be able to detect it. A host-based IPS, however, should still be able to detect this attack.

Obfuscation

Most attackers want to be able to attack your network without being detected. To get past your IPS undetected, many attackers attempt to disguise their attack traffic. One way to accomplish this is through obfuscation. The following list shows some of the major obfuscation techniques attackers can use:

  • Control characters

  • Hex representation

  • Unicode representation

Using Control Characters

Control characters have special meaning when processed by the destination host. An example of this is "../" when used in a URL. When translated by the destination server, these characters will cause the server to use the previous directory level in the URL. For instance, suppose you specify the URL http://webserver/the/the/../attack/file.html. The web server will process this URL as if you had typed http://webserver/the/attack/file.html. Your IPS must be able to process control characters to effectively locate attacks that have been obscured with various control characters. Processing the data stream without also processing the control characters will lead to missed attacks and false negatives.

Note

When your IPS fails to detect an attack that it is programmed to identify, this failure is called a false negative. Most signatures are designed to minimize the chances of false negatives since false negatives represent actual attacks against your network that go undetected.


A common attack uses directory traversal to try to break out of the allowed directory tree. Suppose for instance that the web server allows requests only for the web directory beginning with "TopDir," as in http://webserver/TopDir. An attacker may want to retrieve a file outside of this directory tree. Suppose that the attacker sends the following request:

http://webserver/TopDir/junk/../../etc/shadow

The request appears to be in the approved directory tree, but the request actually becomes http://webserver/etc/shadow after the "../" entries have been processed. Depending on when and how the validity checks are performed on the web server, this request may be able to retrieve the requested file (even though the file is outside of the allowed directory tree).

Using Hex Representation

Most people are familiar with the normal ASCII representation for characters. Another way to represent characters is to use hexadecimal (hex) values. For example, the normal space character can be represented by the hex value 0x20. Many text-based protocols understand either of these ways of representing characters. Your IPS must also understand these multiple representations. Otherwise, your IPS will not be able to effectively analyze data streams when looking for attack traffic.

For instance, the directory "/etc" can be represented in the following two ways (both of which are valid):

  • /etc (ASCII)

  • 0x2f 0x65 0x74 0x63 (hex)

Using Unicode Representation

Originally, computers used the ASCII character set to represent characters. This encoding scheme, however, allows for only 256 different characters (since each character is represented by a single byte). As computers became more prevalent, 256 characters were insufficient to provide a unique character for every character needed in every platform, program, or language. To overcome this limitation, another encoding mechanism was developed. This mechanism was known as Unicode.

Because Unicode uses multiple bytes to represent a single character, it enables a much larger character set than ASCII. This encoding scheme, however, also includes multiple representations for each normal ASCII character (potentially thousands of representations for common characters such as the letter A). Because the destination host interprets each of these representations as the same character, an attacker can send his attack using many different representations in an attempt to sneak the attack past your IPS. If your IPS does not check for these multiple character representations when performing pattern matching, the attacker's traffic can go across your network undetected.

Note

The Unicode encoding mechanism is documented by RFC 2279, "UTF-8, a transformation format of ISO 10646." This encoding mechanism basically uses multiple bytes to represent each character, whereas ASCII uses a single byte for each character. Different versions of Unicode use a different number of bytes to represent a single character. Across these multiple versions, you end up with potentially thousands of different representations for common characters (such as the letter A). Although each of the representations is different, the destination host will process them all as the letter A. Besides referring to the RFC, you can also find more information on Unicode at http://www.unicode.org.


Sometimes, attackers will also use double encoding to try to evade detection. In this situation, the information is encoded twice. If the IPS does not also decode the information twice, an attacker may be able to avoid detection. Double encoding is probably best explained with an example. Suppose you want to double encode the "?" character. The first encoding simply produces the hexadecimal representation, which is 0x3F. In a URL, hexadecimal values are preceded by a "%", so the first encoding produces "%3F". Now for the second encoding, you simply encode each of the characters again. The "%" produces 0x25. The "3" produces 0x33. The "F" produces 0x46. Adding the "%" before each hexadecimal value produces the final result of %25%33%46.

TTL Manipulation

When traffic traverses your network, each hop (routing device) decreases a packet's Time to Live (TTL) value. If this value reaches 0 before the packet reaches its destination, the packet is discarded, and an Internet Control Message Protocol (ICMP) error message is sent to the originating host.

An attacker can launch an attack that includes bogus packets with smaller TTL values than the packets that make up the real attack. If your network-based sensor sees all of the packets but the target host only sees the actual attack packets, the attacker has managed to distort the information that the sensor uses, causing the sensor to potentially miss the attack (since the bogus packets distort the information being processed by the sensor). Figure 8-2 illustrates this attack. The bogus packets start with a TTL of 3, whereas the real attack packets start with a TTL of 7. The sensor sees both sets of packets, but the target host sees only the real attack packets.

Figure 8-2. Variable TTL Attack


Although this attack is possible, it is very difficult to execute because it requires a detailed understanding of the network topology and location of IPS sensors. Furthermore, many network devices (such as firewalls and inline IP sensors) prevent these types of attacks by normalizing the TCP streams running through them. For instance, the Cisco IPS sensors (running 5.0 software) can monitor a TCP stream (when running in inline mode) and then rewrite the outgoing TTL values to match the lowest TTL value seen on the TCP stream. This prevents an attacker from executing a TTL manipulation attack since either all of the packets will reach the target or none of the packets will (since they all leave the sensor with the same TTL, regardless of what the TTL is on the inbound packet).

Tuning the Sensor

To optimize the effectiveness of your IPS sensors, you need to understand how you can tune the operation of your sensors. Signature tuning impacts the operation of a specific signature, but some tuning operations impact the functionality of the entire sensor. When tuning your sensor, you need to consider the following factors:

  • Network topology

  • Network address space being monitored

  • Statically assigned server addresses

  • Dynamic Host Configuration Protocol (DHCP)-assigned addresses

  • Operating systems running on your servers

  • Applications running on your servers

  • Security policy

The location of your sensors determines which traffic they will be monitoring as well as how they can interact with your defined security policy. Tasks involved in tuning your sensors fall into the following three phases based on the length of time that your IPS has been in operation.

  • Deployment phase

  • Tuning phase

  • Maintenance phase

The most drastic changes occur during the deployment phase as you customize the IPS to your unique network environment. Some of the changes that you will likely perform on your sensors during this time include the following:

  • Enabling and disabling signatures

  • Adjusting alert severities

  • Creating basic event action filters

After the initial deployment phase, you can begin more advanced tuning such as changing the sensor's global sensor characteristics. Your tasks for tuning your sensor's global settings fall into the following categories:

  • Configuring IP log settings

  • Configuring application policy settings

  • Configuring reassembly options

  • Configuring event processing

After you complete the tuning phase, the maintenance phase involves continually tweaking your IPS to match your ever-changing network environment.

Configuring IP Log Settings

IP logging enables you to capture the actual packets that an attacking host sends to your network. You can then analyze these packets by using a packet analysis tool, such as Ethereal or tcpdump, to determine exactly what an attacker is doing.

You can capture traffic by using IP logging in response to both a signature configured with the IP logging action as well as manually initiated IP logging requests. When logging an attacker's activity, you have the following three options:

  • Log attacker packets

  • Log pair packets

  • Log victim packets

All of these logging options rely on your sensor's IP log settings. These parameters regulate how much information is logged when IP logging is used. You can configure the following IP log settings for your sensor:

  • Max IP Log Packets

  • IP Log Time

  • Max IP Log Bytes

The Max IP Log Packets field indicates the maximum number of packets that your sensor will log in response to a logging action. The default is 0, which allows the sensor to capture an unlimited number of packets for an IP logging action.

The IP Log Time indicates the time period for which traffic will be logged in response to an IP logging action. The default is 30 seconds. You can specify a value from 30 to 300 seconds.

The Max IP Log Bytes limits the maximum number of bytes that an IP logging response will capture. The default is 0 (unlimited). You can specify values from 0 through 2147483647 bytes.

Configuring the sensor's IP log settings by using IDM involves the following steps:

Step 1.

Access IDM by entering the following URL in your web browser: https://sensor_ip_address.

Step 2.

Click on the Configuration icon to display the list of configuration tasks.

Step 3.

If the items under the Signature Definition category are not displayed, click on the plus sign to the left of Signature Definition.

Step 4.

Click on Miscellaneous to access the Miscellaneous configuration screen. (See Figure 8-3.)

Figure 8-3. Signature Definition>Miscellaneous Configuration Screen


Step 5.

(Optional) Click on the square next to Max IP Log Packets to override the default value of 0. Then enter the maximum number of packets that you want to capture in conjunction with an IP logging response.

Step 6.

(Optional) Click on the square next to IP Log Time to override the default value of 30 seconds. Then enter the maximum length of time (in seconds) that you want to capture packets in conjunction with an IP logging response.

Step 7.

(Optional) Click on the square next to Max IP Bytes to override the default value of 0. Then enter the maximum number of bytes that you want to capture in conjunction with an IP logging response.

Step 8.

Click on Apply to apply the changes to the sensor's configuration.

Note

You can also configure the maximum number of IP log files that can be open at any time. This parameter is available on the Analysis Engine>Global Variables configuration screen. (See Figure 8-4.) The default is 20.


Figure 8-4. Analysis Engine>Global Variables Configuration Screen


Configuring Application Policy Settings

Cisco IPS 5.0 provides the capability to perform application policy enforcement for both HTTP and FTP. This functionality is provided by the following two signature engines:

  • AIC HTTP

  • AIC FTP

Note

The Application Inspection and Control (AIC) engines provide deep-packet inspection from Layer 4 through Layer 7, enabling a much more granular verification of your defined security policy.


To use this functionality, however, you must enable it on your sensor (by default it is disabled). Table 8-2 lists the application policy fields that you can configure on your sensor.

Table 8-2. Application Policy Sensor Parameters

Parameter

Description

Enable HTTP

Used to enable and disable the application policy enforcement for HTTP on the sensor (default is No)

Max HTTP Requests

Specifies the maximum number of HTTP requests allowed for each connection (default is 10)

AIC Web Ports

Specifies the destination ports of traffic that you want the sensor to perform HTTP policy inspection on

Enable FTP

Used to enable and disable the application policy enforcement for FTP on the sensor (default is No)


To configure the application policy sensor parameters using IDM, access the Signature Definition>Miscellaneous configuration screen. (See Figure 8-5.) After changing any of the parameters listed in Table 8-2, you simply click on Apply to save the changes to the sensor's configuration.

Figure 8-5. Configuring Application Policy Parameters


Configuring Reassembly Options

Since many attacks involve fragmented traffic, Cisco IPS provides various reassembly options that impact the manner in which your sensor reassembles traffic when analyzing network traffic. Reassembly options fall into the following two categories:

  • Fragment reassembly

  • Stream reassembly

Fragment Reassembly

Different operating systems reassemble IP fragmented packets in slightly different ways. You can use the IP Reassemble Mode parameter to configure your sensor to reassemble IP fragmented traffic the same way as one of the following operating systems:

  • NT (default)

  • Solaris

  • Linux

  • BSD

When you configure this parameter, it applies to all of the packets processed by your sensor. Therefore, you probably want to set it to an operating system that is representative of the greatest number of systems on your network.

Stream Reassembly

Normal TCP traffic begins with a three-way handshake and ends with a FIN or an RST packet (a packet with the FIN flag set or a packet with the RST flag set). Many attackers, however, will flood your network with traffic that appears to be valid TCP attack traffic, with the intent to cause your IPS to generate alarms. This attack traffic is not part of valid TCP sessions. By tuning your sensor's TCP stream reassembly options, you can control how your sensor responds to the TCP traffic that traverses your network. When configuring stream reassembly, define the following parameters:

  • TCP Handshake Required

  • TCP Reassemble Mode

If you enable the TCP Handshake Required parameter (by setting it to Yes), your sensor will analyze only TCP streams that start with a complete three-way handshake. Although this can reduce the number of alarms generated by traffic that is not part of a valid TCP stream, it can also potentially cause your sensor to miss valid attacks against your network.

Each IP packet in a TCP stream has sequence numbers that enable the destination host to put the packets into the correct order and identify missing packets. You can choose one of the following three TCP reassembly modes, depending on your network environment:

  • Strict

  • Loose

  • Asymmetric

The strict TCP stream reassembly causes your sensor to ignore streams that are missing packets (based on the sequence numbers). Once a gap (a missing packet in the sequence) in a TCP session is detected, the sensor stops processing data for the TCP stream. Strict reassembly mode is the most accurate configuration since the analysis is performed only on complete TCP streams. The drawback is that if the sensor drops any packets in the stream, none of the traffic (for that TCP connection) after the dropped packet is analyzed. This can happen if the traffic load on the sensor exceeds its maximum processing capacity, such as in a burst of traffic.

The loose TCP stream reassembly attempts to place the packets collected during a specific period of time in the correct sequence, but it still processes the packets if missing packets never arrive. Since it allows gaps in the sequence numbers received for the TCP session, this option can lead to false positives since the TCP stream is incomplete. This option, however, guarantees that the sensor will attempt to analyze all the traffic that it captures for a TCP connection, regardless of any dropped packets within the TCP session.

Asymmetric mode is useful for situations in which your sensor does not have access to all the traffic for the TCP connections because of asymmetric routing on your network. Asymmetric stream reassembly mode enables your sensor to maintain state for the signatures that do not require the traffic going in both directions to operate effectively. Asymmetric mode, however, is weaker from a security perspective because it examines only the traffic flowing in one direction on a TCP stream. Only by examining both sides of the TCP conversation can you perform a thorough security analysis on the TCP stream.

Note

Most of the TCP timeout parameters and other TCP stream reassembly settings are handled by the Normalizer engine in Cisco IPS version 5.0. So to change parameters such as the following, you need to change the corresponding signature that enforces the parameter using the Normalizer signature engine:

  • TCP Established Timeout

  • TCP Embryonic Timeout

  • TCP Max Queue Size

Furthermore, some of Normalizer-based signatures have default mandatory behaviors that will occur even if the signature is disabled, such as in "TCP Drop Segment out of window" (SigID 1330, Sub SigID 18). This signature will enforce a default TCP Embryonic Timeout of 30 even when the signature is disabled. Another thing to watch for is that some of the Normalizer signatures have a default action of Deny (when running inline mode), but they are not configured to generate an alert. This can cause packets to be dropped without an alert, making debugging more difficult.


Caution

If you deploy a sensor in inline mode in an environment with asymmetric routing, the mandatory behaviors defined in the Normalizer signatures will break the operation of the network.


Note

Asymmetric routing happens when traffic going between two systems takes multiple paths to reach the systems. When monitoring traffic between systems in an asymmetric routing environment, the monitoring system sees only the traffic flowing in one direction (between the two systems being monitored). Capturing traffic flowing in only one direction (on the TCP stream) makes regular TCP stream reassembly impossible.


Configuring Reassembly Options

To configure reassembly options using IDM, you need to perform the following steps:

Step 1.

Access IDM by entering the following URL in your web browser: https://sensor_ip_address.

Step 2.

Click on the Configuration icon to display the list of configuration tasks.

Step 3.

If the items under the Signature Definition category are not displayed, click on the plus sign to the left of Signature Definition.

Step 4.

Click on Miscellaneous to access the Miscellaneous configuration screen.

Step 5.

Configure the fragment reassembly parameters.

Step 6.

Configure the stream reassembly parameters.

Step 7.

Click on Apply to apply the changes to the sensor's configuration.

Note

The parameters accessible via the Miscellaneous configuration screen represent the fragment and TCP stream reassembly parameters that you can control globally. The other parameters related to fragment and TCP stream reassembly are specified by certain signatures that use the Normalizer signature engine. These parameters must be configured by editing the appropriate signature.


Event Configuration

Whenever a signature triggers, your sensor generates an event. In addition to configuring signature parameters, you can also configure event parameters on your sensor. These event parameters fall into the following categories:

  • Event variables

  • Target Value Rating

  • Event action override

  • Event action filters

Event Variables

Sometimes, you may want to use the same value (such as an address range) in multiple event filters. Event variables enable you to configure values that are used in multiple event filters. The advantage of using event variables instead of typing the actual values is that you can change the settings of the event variables so that all the filters that use those settings are automatically changed.

Suppose that you have an engineering network segment (10.20.10.0/24) that contains only Linux-based systems. To reduce your monitoring duties, you may not want to see alerts based on Microsoft Windows-based attacks against these engineering systems. By configuring an event variable that defines this address range, you can use this variable in multiple event filters to eliminate Windows-based alerts against systems in this IP address range.

Although this approach reduces your monitoring duties, it prevents you from detecting valid attacks if someone happens to place a Windows system on the network (either temporarily or permanently). Therefore, before filtering alerts for a specific operating system, you need to carefully analyze your current network configuration and the likelihood that the operating systems in use will change.

You use the following steps to configure an event variable named ENG-NETWORK that identifies the 10.20.10.0/24 network segment using IDM:

Step 1.

Access IDM by entering the following URL in your web browser: https://sensor_ip_address.

Step 2.

Click on the Configuration icon to display the list of configuration tasks.

Step 3.

If the items under the Event Action Rules category are not displayed, click on the plus sign to the left of Event Action Rules.

Step 4.

Click on Event Variables to access the Event Variables screen. (See Figure 8-6.) This screen displays the currently configured event variables.

Figure 8-6. Event Variables Configuration Screen


Step 5.

Click on Add to access the Add Event Variable popup window. (See Figure 8-7.)

Figure 8-7. Add Event Variable Popup Window


Step 6.

Enter ENG-NETWORK in the Name field.

Step 7.

Enter 10.20.10.0-10.20.10.255 in the Value field.

Step 8.

Click on OK to save the new event variable.

Step 9.

Click on Apply to save your changes to the sensor's configuration.

Note

When defining the addresses for an event variable, you can separate individual addresses with commas, or you can specify address ranges by separating the starting address and ending address with a hyphen.


Target Value Rating

The Target Value Rating enables you to assign an asset value rating to specific IP addresses on your network. This rating is used to calculate the Risk Rating for attacks against those systems. The target values that you can assign to an IP address or range of IP addresses are as follows:

  • Mission Critical

  • High

  • Medium

  • Low

  • No Value

The process of assigning values to systems is subjective; the important factor to remember is that the asset values enable you prioritize the devices on your network based on their perceived value. For instance, you may use the following classification model:

  • Mission Critical Server systems

  • High Infrastructure systems

  • Medium IP Phones

  • Low Desktops and laptops

  • No Value Printers

Event Action Override

Besides the actions you can configure a signature to perform, you can also configure an event action override for each Cisco IPS response action. This override causes actions to be added to signatures if the Risk Rating of the event matches the override definition. Each override defines a minimum and maximum Risk Rating. If a signature generates an alert that falls within the defined Risk Rating range, the specific response action is added to the alert event.

For instance, suppose you want the sensor to use the Deny Connection Inline action whenever a signature generates an event with a Risk Rating greater than 90. The following steps define the event action override for the specified action:

Step 1.

Access IDM by entering the following URL in your web browser: https://sensor_ip_address.

Step 2.

Click on the Configuration icon to display the list of configuration tasks.

Step 3.

If the items under the Event Action Rules category are not displayed, click on the plus sign to the left of Event Action Rules.

Step 4.

Click on Event Action Override to access the Event Action Overrides screen. (See Figure 8-8.) This screen displays the currently configured action overrides.

Figure 8-8. Event Action Overrides Configuration Screen


Step 5.

Click on Add to access the Add Event Action Override popup window. (See Figure 8-9.)

Figure 8-9. Add Event Action Override Popup Window


Step 6.

Select the Deny Connection Inline action from the Event Action pull-down menu.

Step 7.

Verify that the Enabled radio box is selected.

Step 8.

Enter 90 for the Minimum Risk Rating.

Step 9.

Verify that the Maximum Risk Rating is set to 100.

Step 10.

Click on OK to save the action override.

Step 11.

Click on Apply to save your changes to the sensor's configuration.

Event Action Filters

Event action filters enable you to configure your sensor to remove actions from events based on one or more of the criteria shown in Table 8-3. Event filter tasks can be very simple, such as removing the alert action for events based on a single signature ID and victim address. They can also be very complex, such as removing the Request SNMP Trap action when an event matches the following criteria:

  • Attacker address is 10.89.10.102

  • Attacker port is 200

  • Victim address is 10.10.200.10

  • Victim port is 53

  • Event Risk Rating is between 50 and 75

Table 8-3. Event Action Filter Criteria

Parameter

Description

Signature ID

Specifies a signature ID or range of signature IDs that apply to the filter

SubSignature ID

Specifies a subsignature ID or range of subsignature IDs that apply to the filter

Attacker Address

Specifies an attacker address (source address) or range of addresses that apply to the filter

Attacker Port

Specifies a source port or range of source ports that apply to the filter

Victim Address

Specifies a victim address (destination address) or range of addresses that apply to the filter

Victim Port

Specifies a destination port or range of destination ports that apply to the filter

Risk Rating

Specifies a range of Risk Ratings that apply to the filter

Actions to Subtract

Specifies the actions to remove when an event matches the event filter

Stop on Match

Specifies whether other event filters are processed after an event filter matches an event

False: Continue processing event filters

True: Stop processing when a match is found


Configuring event action filters is better understood by going through an actual example. Suppose that you have tuned the built-in signature 4612, "Cisco IP Phone TFTP Config Retrieve," so that besides generating an alert, it also drops the offending traffic by using the inline deny packet action. This modification prevents systems from retrieving IP phone configuration files from your TFTP server. Your IP phones, however, still need to download configuration files from the TFTP server. Therefore, you should implement an event action filter to remove the inline packet deny action when the traffic comes from your IP phone network segment. Assuming that the IP phone segment is 10.10.20.0/24, the steps to configure the appropriate event action filter are as follows:

Step 1.

Access IDM by entering the following URL in your web browser: https://sensor_ip_address.

Step 2.

Click on the Configuration icon to display the list of configuration tasks.

Step 3.

If the items under the Event Action Rules category are not displayed, click on the plus sign to the left of Event Action Rules.

Step 4.

Click on Event Action Filters to access the Event Action Filters configuration screen. (See Figure 8-10.) This screen displays the currently configured event action filters.

Figure 8-10. Event Action Filters Configuration Screen


Step 5.

Click on Add to access the Add Event Action Filter popup window to add a new event action filter. (See Figure 8-11.)

Figure 8-11. Add Event Action Filter Popup Window


Step 6.

Enter PhoneConfigTFTP in the Name field.

Note

If you place spaces in the Name field, the event filter will have problems being added to the sensor's configuration when you click on Apply.

Step 7.

Enter 4612 in the Signature ID field.

Step 8.

Enter 10.10.20.0-10.10.20.255 in the Attacker Address field.

Step 9.

Click Deny Packet Inline to highlight it in the Actions to Subtract field.

Step 10.

Click on OK to save the event action filter.

Step 11.

Click on Apply to save your changes to the sensor's configuration.

With event action filters, the order of processing is important (since you can configure a filter to stop processing future filters if a match is found). You can adjust the order of the event action filters by using one of the following buttons on the Event Action Filters configuration screen:

  • Insert Before

  • Insert After

  • Move Down

  • Move Up

Using either Insert Before or Insert After enables you to decide where new event action filters will be inserted into the list. After highlighting an existing filter (by clicking on it), you can click on either Insert Before or Insert After to indicate exactly where the new event filter should be inserted. These two options work the same as clicking Add to add a new event filter, except that they can also specify where the new filter will be inserted in the event filter list.

Once you have created the filters, you can adjust their order by using either Move Up or Move Down. Again, start by highlighting a specific event filter (by clicking on it). Then you can click on either Move Up or Move Down to move the location of the filter in the list.



CCSP IPS Exam Certification Guide
CCSP IPS Exam Certification Guide
ISBN: 1587201461
EAN: 2147483647
Year: 2004
Pages: 119
Authors: Earl Carter

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net