Firewalls have a largely static configuration: Firewall administrators define what is acceptable traffic and use the features of the firewall to instantiate this policy. Some firewalls provide better protection features than others--for example, an HTTP application-level proxy is far superior to an HTTP stateful packet-filtering firewall at blocking malicious attacks--but the basic idea is the same: Your firewall administrator can be confident that only allowable traffic will pass through. If you have doubts about your firewall, get a new one from a different vendor, send your firewall administrator to Firewall Admin 101, or get a new firewall administrator.
Not surprisingly, when we asked you why you're not blocking traffic using NID (network-based intrusion-detection) systems, 63 percent of you said you use a firewall to determine legitimate traffic (see E-Mail Poll results).
But people make mistakes, so misconfigured firewalls are a common source of network insecurity. This simple fact has been used as a selling point for both intrusion-detection and -prevention systems, with vendors claiming their products will alert you to, or block, attacks that do get through.
The answer: Instead of layering on more hardware, solve the fundamental problem of misconfiguration. Unfortunately, though, it's not that simple. If you're enforcing traffic policy on your network using a stateful packet-filter firewall--such as Cisco Systems' PIX, Check Point Software Technologies' FireWall-1 or NetScreen's eponymous product--without security servers or kernel-mode features enabled, you should know that application-layer exploits, such as server-buffer overflows or directory-traversal attacks, will zoom right through. Stateful packet filters stop at Layer 4.
Application-proxy firewalls, like Secure Computing's Sidewinder G2 Firewall and Symantec's Enterprise Firewall, can block some attacks that violate specific protocols, but let's face facts: Protection is limited to a handful of common protocols; the rest are not supported through a proxy, or are supported through a generic proxy, which is no better than a stateful packet filter.
Still, NIP is not a replacement for firewalls and won't be in the foreseeable future. Why? The fundamental problem is false positives--the potential to block legitimate traffic. Before you can prevent attacks, you have to detect them, but NIP systems rely on intrusion detection, which is hardly an exact science. A properly configured firewall will allow in only the traffic you want, and you can bet the farm on that. We need to feel this same confidence in IDSs before we can believe in NIP systems, but IDS vendors have employed lots of talented brain cells trying to raise detection accuracy, and they're nowhere close to 100 percent.
Despite these caveats, we believe a properly tuned NIP device can be instrumental in warding off most malicious traffic that gets past your firewall.
There are several ways to block malicious traffic: If the NIP device is inline, offending packets can be dropped silently, causing the connection to fail. Whether or not the connection is inline, the session can also be summarily dropped by sending TCP Resets or ICMP Unreachable messages to the client, server or both. Or, the offending IP address can be shunned--blocked--for a specific time period.
Just be sure that when blocking is enabled, you know what you're doing. When we asked what it would take to make you use blocking, 57 percent of you cited needing assurance that there would be no false positives or that traffic would be blocked effectively. These are legitimate concerns. During our tests of NIP devices (see "NIP Attacks in the Bud"), only a subset of signatures were defined enough to not alert on false positives consistently. These signatures were primarily TCP-based and violated a protocol or utilized known malicious strings.