Pretend or Prevent?
No matter what it’s called, if a network security system doesn’t shoot first and ask questions later, it doesn’t qualify as intrusion prevention
by Jon Ramsey
Overview
Intrusion detection systems (IDS) and intrusion prevention systems (IPS) describe two different approaches to network security and are not interchangeable. Market demand, however, has prompted some vendors to apply the “prevention” label to systems thatdetect attacks but actually do nothing to stop them. To qualify as true intrusion prevention, the system must use an in-line appliance to inspect traffic at the packet level and drop offending packets before they reach the victim.
Recognizing attacks
Unlike security measures like firewalls or access control lists on routers, intrusion detection systems (IDS) are designed specifically to recognize attacks. The logic is clear: you cannot prevent what you cannot detect.
IDS falls into two categories: signature-based and algorithmic. Signature-based, which compares network traffic or operating system calls to representations of attacks (signatures), is the more mature technology of the two. Algorithm-based systems use statistical anomalies (based on normal traffic) as the detection mechanism. (One drawback of the algorithmic approach is the false-positive volume it generates.)
Intercepting attacks
The position of the security system in relation to the protected network determines how attacks are intercepted. The system may be in-line or out-of line, and in front of or behind the firewall (figure 1 and 2).
Intranet
Internet
Router
IDS
Hub
Firewall
Intranet
Internet
Router
IDS
Firewall
Hub
Figure 2: Security
system
out of line and behind a firewallResponding to attacks
Generally speaking, protected networks fall into one of four general configurations (described below). Regardless of their “street description,” the first three systems can detect, but literally cannot prevent, intrusions. The diagrams show how this works.
Intranet Internet Router IDS Firewall Hub Victim Attacker 2. Analyze Alert 1. S end Ale rt 3. A d d ru le
Figure 3: Ask questions, then shoot
Figure 3 shows the security system positioned out-of-line and behind the firewall. In this situation, the system recognizes the attack and sends an alert to a security analyst. The analyst assesses the alert and takes precautionary (not preventative) measures by adding a rule to the firewall. The attack has usually penetrated the network by the time this process is complete.
Intranet Internet Router IDS Firewall Hub Victim Attacker 1. Send Reset
Figure 4: Yell for help
Figure 4 shows the same configuration as above. In this case, however, the security system recognizes the attack and sends an instruction—TCP reset, for example—to the victim server in an effort to reset the connection before any damage can be done. As in figure 3, the detection system will almost certainly lose this race. Intranet Internet Router IDS Firewall Hub Victim Attacker Ad d R ule
Figure 5: The horses are gone—but lock the barn door anyway
Figure 5 is an improvement over figure 3 because firewall updates take place without human intervention. The instant the security system detects an attack, it automatically responds by adding a rule to the firewall. But as in the previous situations, this is after-the-fact protection. The attack has already penetrated the network. (This is how Code Red and SQL Slammer infected millions of computers.) Does positioning the protection in front of the firewall solve the problem? In theory, perhaps, but not in practice. Even when installed in-line in front of the firewall, a system that detects but does not prevent intrusions always loses the race against malicious traffic. The system must process the entire
packet/stream, update the firewall to block the IP, and do it all before the firewall lets the packet pass. This is a race the attacker always wins.
What happens when intrusion detection and firewall software run on the same device? If the firewall waits for a go/no-go from the IDS, which it is designed to do, a race condition still exists. The attack will prevail.
Intranet Internet Router IDS Firewall Hub Victim Attacker Ad d R ule Partner 192.168.12.1 From: 192.168.12.1 To: 192.168.12.3 Attack Spoofed Packet From: 192.168.12.1 To: 192.168.12.3 Business Transaction
Attacker spoofs an attack from the partner IDS detects attack
Firewall rule added to drop traffic from 192.168.12.1
Business transactions from 192.168.12.1 are dropped
Figure 6: “Solutions” that make matters worse
Figure 6 is the anatomy of a spoof attack. Both Yell for Help and Lock the Barn Door create larger security holes than they fill by leaving the network vulnerable to IP spoofing. Spoofing simulates a trusted IP address (e.g. that of a legitimate business partner) and prompts the system to continuously reset the “legitimate connection”. This is a worst-case scenario that can bring a network to its knees.
Intranet Internet Router IPS Firewall Hub Server Attacker Partner 192.168.12.1
IPS detects attacks
IPS filters attacks
Legitimate traffic flows uninterrupted
Figure 7: Shoot first and ask questions later
Figure 7 represents true intrusion prevention. The system detects and blocks attacks before they reach the victim server. The security device is in-line with the network and uses both representational and functional methods to identify and repel threats. All traffic is inspected at the packet level, and malicious packets are filtered automatically while legitimate traffic flows uninterrupted.
SQL Slammer CODE Red Nimda Deloader
Ask questions Yell for help Lock the barn
Shoot first X X X X
Figure 8: How IDS and IPS compare against widespread attacks
About the author: Jon Ramsey is an information security expert with policy-making responsibility at SecureWorks in Atlanta, GA. Ramsey has 10 years of hands-on experience at every level: system administrator, software engineer, analyst, security penetration specialist and senior engineer. Prior to joining SecureWorks, Ramsey was a member of the Computer Emergency Response Team (CERT), and worked for Siemens International and the University of Pittsburgh.
Ramsey earned a Master’s degree in software engineering from Carnegie Mellon University and a BS in computer science from the University of Pittsburgh. He is a member of IEEE and the Association for Computing Machinery (ACM).
