Malicious traffic coming into an organization cannot always be prevented or detected. However, where intrusion prevention systems (IPSes) fall short in stopping attacks, intrusion detection systems (IDSes) have the advantage of detecting them.
Network-based IDSes are deployed to identify compromised targets, while network-based IPSes are deployed in an effort to prevent compromise. Both systems must be able to recognize malicious traffic to issue warnings or block offending packets. IDSes, however, have the upper hand in identifying intrusions, because they have the luxury of generating an alert based on traffic from the attacker to the victim or from the victim to the client. In other words, an IDS can alert on either the inbound attack traffic or the outbound victim response. But to prevent an intrusion, an IPS must deny incoming attack traffic. An IPS that only inspects outbound traffic allows a target to be compromised. An IPS that makes a block decision based on responses from the victim is an "intrusion containment system," not an IPS.
Developer-centric vs. user-centric false positives
Both IDSes and IPSes make detection and blocking decisions using signatures, along with other methods. A signature is a security developer's idea of how best to recognize malicious traffic. From the developer's point of view, an IDS/IPS generates a false positive if the inspection engine "sees" a pattern not present in the traffic. If the signature says "find cmd.exe," and "cmd.exe" appears in a benign packet, an alert on "cmd.exe" is not a real false positive. From the user's point of view, an IDS/IPS generates a false positive if the product decides traffic is malicious when it really is not. When "cmd.exe" generates an alert but the traffic is benign, the user complains the IDS/IPS fired a false positive.
To make a detection or blocking decision based on inbound traffic, the product might use a signature like the following rule found in the deleted.rules file shipped in the Snort 2.4 rule set:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS unicode directory traversal attempt"; flow:to_server,established; content:"/..%c0%af../"; nocase; reference:bugtraq,1806; reference:cve,2000-0884; classtype:web-application-attack; reference:nessus,10537; sid:981; rev:11;)
This signature makes an identification decision on traffic inbound to HTTP_PORTS. When
"/..%c0%af../" appears in a packet sent from an EXTERNAL_NET to an organization's HTTP_SERVERS, Snort provides a "WEB-IIS unicode directory traversal attempt" alert. (Since this rule is in the delete.rules file, it is not active by default. Snort now uses a preprocessor to identify this sort of attack.)
This form of detection is more likely to generate user-centric false positives than developer-centric false positives. The inspection engine could see packets with "/..%c0%af../" occur every minute, but the target Web servers might be running Apache or patched versions of Microsoft Internet Information Services. Alerts would not be false positives for developers, but users would become very frustrated.
One way to reduce the number of user-centric false positives is to employ signatures that inspect outbound traffic. This is a form of extrusion detection, meaning malicious activity is identified by watching packets leaving the enterprise. A system that emits suspicious traffic from the enterprise to a remote host may indicate it has been compromised. Watching responses to attacks is more faithful to the idea of detecting intrusions. Watching inbound traffic is more likely to be seen as attack detection. Fortunately, IDS vendors realize the power of extrusion detection.
Consider the following rule from the attack-responses.rules file shipped in the Snort 2.4 rule set:
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES directory listing"; flow:established; content:"Volume Serial Number"; classtype:bad-unknown; sid:1292; rev:9;)
This signature makes an identification decision on outbound traffic to EXTERNAL_NET from HOME_NET. Traffic that contains "Volume Serial Number" is believed to be indicative of an intrusion. For example, an intruder may gain a shell on a target by exploiting a vulnerable service. Rather than inspecting inbound shell code, an inspection engine may pay more attention to the victim's response to the shell code. The following shows the sort of prompt that might appear once an intruder exploits a vulnerable target:
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\Documents and Settings\richard>dir
Volume in drive C has no label.
Volume Serial Number is 00AA-FE5F
Directory of C:\Documents and Settings\richard
The previous Snort signature triggered on the content "Volume Serial Number" that appears in the syntax above when an intruder executes the "dir" command.
This technique can be extended to any outbound activity that might be considered indicative of evidence of compromise. Extrusion detection is a powerful way to identify compromised systems, but it is less helpful for the more difficult problem of preventing compromise. A system that prevents the emission of outbound traffic containing "Volume Serial Number," for example, can limit an intruder's freedom to maneuver on a target.
Sometimes detection is the only option, so remember to watch outbound traffic for indicators of compromise. Review Snort's attack-responses.rules file for more ideas on the type of indicators one can use to detect intrusions.
About the author
Richard Bejtlich is the author of the book Extrusion Detection: Security Monitoring for Internal Intrusions. He is founder of TaoSecurity (www.taosecurity.com) and the TaoSecurity Blog (taosecurity.blogspot.com). He wrote The Tao of Network Security Monitoring: Beyond Intrusion Detection and co-authored Real Digital Forensics.