The first instance of potential degradation is in the mirroring process. Recall that you're asking the switch to make a copy of all the inbound and outbound packets on a particular port (or ports), then forward them to the SPAN port. Second, depending on how you've set up the mirroring, you can overflow the rated transmission speed of the SPAN port. In most cases, the SPAN port is an ordinary 10/100 port; if you try to push more bandwidth through the port than it can handle, you'll saturate the port and it will drop traffic.
Monitoring VLANs
VLANs provide another bit of switching magic that you must plan for when you locate your sensor. (For information about VLANs, go to http://www.sans.org/newlook/resources/IDFAQ/vlan.htm; for a System Administrator, Networking, and Security—SANS—Institute technical brief about VLANs, go to the SANS VLAN FAQ at http://www.intel.com/network/connectivity/resources/doc_library/tech_brief/virtual_lans.htm.) With a VLAN, all the participants on that network might not physically reside on the same wire. VLANs let you break up the ports on a switch, grouping some together to effectively manage your LAN bandwidth. You can arrange your VLANs any way you choose: putting high network users together, separating a test network from a production network, connecting people who perform the same function—even if they reside in different places on the LAN (e.g., they work on different floors). Each VLAN can have its own 100MB or higher network, and high use on one VLAN does not affect the others. However, when you use VLANs, you make the job of network monitoring more difficult because now you can't see all the traffic—only what's in a particular VLAN. You typically need a router to pass traffic from one VLAN to another, and your filtering and monitoring must take place at the head end, where the network traffic coalesces.
Overcoming IDS-Evasion Tactics
After you locate your sensor in the right place to monitor the traffic that interests you, make sure you're running the most recent version of the software or signatures to avoid sensor-evasion mechanisms. Sensor, or network IDS, evasion is an intruder's attempt to circumvent detection by confounding a network IDS or simply hiding attacks from a network IDS within network traffic. For example, an intruder could send significantly fragmented packets to evade older network IDSs. Packets are usually broken apart when datagrams moving between two nodes pass through networks on which the packet size—or Maximum Transmission Unit (MTU)—is smaller than the size of the datagram. Because this "size window" can change as the packet travels, the routers must compute the maximum size of the window at each hop along the route and the packets must be resized accordingly. Packets are fragmented, then reassembled at the destination host in the IP layer. If any fragments are lost, the packets must be retransmitted. The end host knows how to reconstruct the entire datagram by looking at each fragment's fragment ID and offset (from zero) and knows to expect more fragments if the more fragments (MF) bit is set.
Although you expect packets sent through networks to be disassembled and reassembled, an attacker could purposely break data into much smaller sections, aimed at overwhelming the network IDS or simply confusing it. Network IDSs that perform no reassembly are vulnerable to attackers who used fragmented packets to overwhelm them. Fragrouter, for example, is a tool that interferes with the usual datagram sizes to confuse a network IDS. The network IDS has to look at every packet that passes it. Suppose that instead of the usual fragmentation of a 1MB file, I threw one million 1-byte fragments past the IDS. Although each piece is tiny, when all the tiny pieces join other network traffic, older IDSs would be overwhelmed and miss the attack because the IDS performed no reassembly. IDSs created or updated since 1999 perform packet reassembly, making this kind of attack less successful. However, this network IDS evasion technique is just one in a sea of options.
Recently, attackers have used exotic encoding mechanisms to evade IDSs. For example, an attacker can alter HTTP encoding to something nonstandard to completely confound your sensor (i.e., the network IDS doesn't understand the language in which the exploit is encoded). In RFC 2616, the HTTP 1.1 specification has allowances for content encoding that let you compress a document without losing the identity of its underlying media type. (For more information about the ways in which attackers can overthrow network IDS, see Greg Hoglund and Jon Gary, "Multiple Levels of De-synchronization and other concerns with testing an IDS system" at http://www.securityfocus.com/infocus/1204.)
Most mainstream Web servers use either hexadecimal or Unicode Transformation Format (UTF) URL encoding, which modern network IDSs can decode and analyze. However, Microsoft IIS also supports %u encoding, which earlier IDSs weren't aware of and didn't try to decode. (Some but not all current IDSs are aware of this coding.) Attacks that used this brand of encoding could slip by sensors unnoticed. (For information about this vulnerability, see eEye Digital Security's advisory, "%u encoding IDS bypass vulnerability," at http://www.eeye.com/html/research/advisories/
ad20010705.html.)
Network IDS Success
Intrusion detection plays an important part in a multilayered defense-in-depth approach. As you deploy a network IDS, you need to know your network's architecture to locate your sensor effectively. You'll find placement a key factor in your network IDS's success in protecting your network from invasion. Of course, I've just scratched the surface of network IDSs.