Foundation and Supplemental Topics
IDS Evasion TechniquesAttackers 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:
FloodingOne 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. FragmentationWhen 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. EncryptionOne 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:
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. ObfuscationMost 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:
Using Control CharactersControl 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 RepresentationMost 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):
Using Unicode RepresentationOriginally, 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 ManipulationWhen 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 SensorTo 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:
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.
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:
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:
After you complete the tuning phase, the maintenance phase involves continually tweaking your IPS to match your ever-changing network environment. Configuring IP Log SettingsIP 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:
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:
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:
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 SettingsCisco 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:
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.
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 OptionsSince 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 ReassemblyDifferent 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:
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 ReassemblyNormal 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:
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:
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:
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 OptionsTo configure reassembly options using IDM, you need to perform the following steps:
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 ConfigurationWhenever 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 VariablesSometimes, 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:
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 RatingThe 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:
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:
Event Action OverrideBesides 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:
Event Action FiltersEvent 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:
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:
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:
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. |
EAN: 2147483647
Pages: 119