In addition to venerable antivirus tools, we have another network-centric weapon we can use in the fight against malicious code: the network-based intrusion prevention system (IPS). Although network-based IPSes have dealt with thwarting denial-of-service floods and preventing system compromise for a few years, their use in thwarting the propagation of worms has only recently come into vogue.
Here's the idea behind this technology: An organization deploys network-based IPS devices at strategic points on its network, in effect creating automated choke points to detect and block attacks. Typically, these tools sit inline and monitor passing traffic going through them, trying to match signatures of known attacks and blocking nasty stuff when it is detected. Some of them don't sit inline, but instead monitor traffic on a LAN and inject messages into a network to block attacks and prevent malware propagation. Unlike network-based IDS, which focuses on detecting and alerting, network-based IPS not only detects and alerts but also automatically responds by blocking traffic or resetting connections.
When a host machine gets infected with a worm, the conquered system usually starts scanning for other vulnerable hosts. A network-based IPS tool can automatically detect and suppress the worm's scanning and propagation traffic when it arrives, preventing systems on the other side of the IPS or on the same LAN as the IPS from getting infected. Keep in mind, though, that network-based
Products such as ForeScout's WormScout, TippingPoint's UnityOne, Top Layer's Attack Mitigator, McAfee's IntruShield (formerly IntruVert) and ISS Proventia all fall into this category. There's even a free, open source network-based IPS built on top of the Snort intrusion-detection system (IDS) called snort_inline, maintained by Rob McMillen in association with the Honeynet Project.
I know what you are thinking: "Isn't this what a firewall is supposed to do?" Most of today's firewalls look at packets and protocols to determine whether they should be transmitted or not based on an allowed set of ports or services. However, these firewalls usually do not have signature-matching capabilities to look for exploits, malicious code or traffic surges. In other words, firewalls usually look at services and ports, and not actual attack signatures and behavior. IPSes specialize in the latter.
Still, the network-based IPS category has always been a bit squishy in terms of whether firewalls fit in or not. Increasingly, the distinction between firewalls and network-based IPSes is narrowing, as more intelligence is built into firewalls to recognize actual attacks. In fact, Check Point's Application Intelligence functionality and Juniper Networks' (NetScreen) Deep Inspection technology are firewall add-ons that attempt to match signatures of known attacks to block or throttle them, including popular exploits used by many worms. These firewalls, with the associated functionality turned on, therefore constitute a form of network-based intrusion-prevention system. Look for more IPS-like capabilities in other firewall products in the near future.
Most network-based IPSes have their own set of signatures for detecting exploit and attack traffic. Some go further, monitoring traffic loads and comparing them against a learned "normal" level. TippingPoint, for example, offers a feature called "Statistical Anomaly Control", which monitors different protocol types against a baseline of expected traffic. When traffic loads get out of hand, the network-based IPS can throttle the traffic or block it. As an example, consider the ICMP traffic generated by Nachi infections, which let out a torrent of ping packets when searching for new hosts to conquer. TippingPoint includes intelligence to say, "It's highly unusual to see 100 Mbps of ping traffic, so I'll start blocking it," without any human intervention at all.
For more related info on this topic, visit these resources:
Once a worm attack is detected, network-based IPS devices automatically take action in a variety of ways, but be very careful regarding which response method you configure the tool to use! Most tools have options of throttling traffic to preserve bandwidth, resetting connection requests with TCP Reset or ICMP Host Unreachable messages or even just dropping worm-related traffic to prevent propagation. Merely throttling traffic is typically problematic in that some machines will still get infected. The connection reset and host unreachable messages sent by these tools could be even worse trouble. These TCP and ICMP messages could result in an amplification attack, sucking up all bandwidth of the target network when you need it most. It's bad enough having your network groan under the load of a thousand worm-infected systems scanning for more prey, without having the trouble compounded by self-inflicted reset packets from your own network-based IPS. Additionally, carefully constructed worm code could ignore reset packets and still propagate. For this reason, outright blocking of worm-related traffic is usually the most effective and safest configuration for a network-based IPS. It stops the worm from spreading and helps to preserve network bandwidth.
Also, just in case a false positive starts blocking legitimate traffic, make sure your network-based IPS is configured to alert personnel in your incident-response team immediately. They can manually verify the attack, allow traffic that was blocked by a false positive or start clean-up procedures if a true infection occurred.
If you have deployed this technology, don't throw out or even weaken your other defenses! I had a client that was planning on lowering their security stance on their servers and dropping ACLs from their border router because of their deployment of a new-fangled network-based IPS. Network-based IPS tools sitting inline or on a LAN must make decisions about attacks in real-time. To meet such crucial performance criteria, the signature base and flexibility of network-based IPS is often less comprehensive than network-based IDS or host-based IPS.
As a result of its real-time monitoring capabilities, the risk associated with a false positive on a network-based IPS is significantly greater. Rather than just falsely alarming an incident-response team (which an errant IDS can do) or blocking action from a single host (which a false alarm with a host-based IPS can do), a network-based IPS with a false positive can seriously disable an entire network segment, or depending on your architecture, your entire Internet connectivity. Remember that network-based IPS is not a replacement for firewalls or host-based security. Think of network-based IPS solutions as an additional layer of your defense, and make sure you keep those other defenses (traditional firewalls, IDS products, antivirus tools and file integrity checkers) up to date.
Also, to handle the increasing crescendo of attacks, you must make sure you keep the signatures in your network-based IPS itself up to date. Schedule regular updates to occur automatically or implement a manual procedure for daily updates based on your vendor's release schedule. Carefully tuning such tools is also critical, so that they understand your normal network traffic patterns and can differentiate attack traffic.
Finally, if you aren't yet using network-based IPS, look at the technology. It can offer a valuable layer of additional defense. If you are not ready to buy but want to get more familiar with what such tools can do, test drive snort_inline, in a lab or in front of a non-mission-critical server to get your feet wet. Then, decide if you want to dive in.
About the author
Ed Skoudis, CISSP is cofounder of Intelguardians Network Intelligence, a security consulting firm, and author of Malware: Fighting Malicious Code (Prentice Hall, 2003).
This was first published in June 2004