In "Protect Your Network from Intrusion," May 2002, InstantDoc ID 24650, I discuss the value of a network Intrusion Detection System (IDS) as part of a multilayered approach to network protection. For your network IDS to be effective, you must place the system's sensors where they can best contribute to your network's security. In addition, you must manage your network IDS, fine-tuning the sensors' alerts and monitoring the data that the sensors provide. When you correctly deploy a network IDS, you gain not only an early warning system but also a deterrent to attackers.
Placing Your Network IDS
As you prepare to deploy your network IDS, you need to know your network's architecture so that you can place the network IDS sensors effectively. Sensor placement is a key factor in your IDS's ability to protect your network from invasion. Let's approach the subject of placement by first reviewing how traffic comes into your network.
Traffic from the Internet enters your network through a router. At best, the router applies an initial set of filters before it lets traffic through. Although ordinary router operation doesn't require setting up such filters, security experts recommend doing so. Router filtering acts as a first layer of defense, keeping out risky connections such as broadcast Internet Control Message Protocol (ICMP) and reserved addresses. (ICMP is the basis for Smurf attacks, which use ping messages and the target's IP broadcast address to flood a target's Internet access link; Internet Engineering Task Force—IETF—Request for Comments—RFC—1918 specifies that reserved addresses aren't meant to be on the Internet or to be routed.) You can also filter outbound traffic to prevent compromised servers from sending connections to other networks.
Figure 1 shows a network IDS set up at a corporate perimeter. Although the diagram is simplified for this discussion, you can see how such a setup can dramatically enhance border security. I recommend that you use at least two sensors and place them so that they give your network two layers of defense and give you comparative information with which you can verify your firewall settings. In the material that follows, I show you how the two sensors increase your network protection. You need at least two distinct points of reference to assess the completeness of your security perimeter.
Generally, IDS sensors have two network interfaces—one for monitoring traffic and one for management. The traffic-monitoring interface is unbound from any protocol, which means that the interface has no IP address and other entities can't communicate with it. (For information about how machines communicate with each other and what "promiscuous mode" means for your network interface, see "Protect Your Network from Intrusion.") When two machines on a nonswitched Ethernet segment want to communicate with each other, all computers on that network hear the request but ignore it unless it's destined for them. When you place your NIC in promiscuous mode, your IDS sensors actively listen to and act upon network traffic. Network sniffers and IDSs look at, record, or act upon all the network traffic they can see, regardless of the destination (unless you've told them to ignore all but some specific traffic).
Placing the outer sensor. If you examine the diagram that Figure 1 shows, you see that the first checkpoint for data coming into the network is an Ethernet switch to which you attach your first-level firewall. You can mirror the port that the firewall uses, through which all inbound and outbound packets pass, to the Switched Port Analyzer (SPAN) port, an excellent place to attach your first network IDS (the upper line in red). By placing the sensor on a SPAN port rather than on a hub or on a Virtual LAN (VLAN) with the firewall, you can reduce attackers' potential abuse of the sensor. Although the port the sensor uses has no protocol attached to it and an attacker can't directly address it, you can experience problems with an incorrectly installed or misconfigured sensor. Placing the sensor on the SPAN port should eliminate most of the downside because the port simply mirrors another port and a broken sensor won't offer potential attackers a foothold. (For more about VLANs and the potential complications involved in securing them, see "Protect Your Network from Intrusion." Also see the VLAN Technical Brief at http://www.intel.com/network/connectivity/resources/doc_library/tech_brief/virtual_lans.htm.)
The outer sensor monitors "barbarians at the gate," helping you gauge the external risk at any given time and also providing troubleshooting assistance. The outer sensor lets you see what traffic is passing. Keep in mind that your security won't stop attempted attacks or probes, but you will want to measure the number of attempted attacks (events) and actual attacks (incidents). Understanding what occurs before traffic reaches your firewall helps you see how well your access control works. The external sensor can record that information for you. In the form of sensor logs and alerts, the external sensor provides your second level of defense (after router filtering) and a comparison point for the inner sensor. You can also use sensor information to adjust your firewall policy settings.
Looking again at Figure 1, you can see that the management interface (the black line to the left of both sensors) connects to an out-of-band (OOB) network that isn't quite a demilitarized zone (DMZ) or the core network. An OOB network provides a segregated area in which administrative and monitoring functions can take place without compromising that traffic or the core internal network. On the OOB network, you perform firewall and sensor administration, store your Syslog repository, and generally manage the perimeter infrastructure.
Keeping administrative traffic off the core internal (i.e., production) network gives you a definite security advantage. In the event of a compromise, attackers will find little in the OOB network but administrative stations, which typically contain administrative consoles but no important data. To manage an OOB, a security administrator needs two computers (and two network jacks)—one for administrative tasks related to components of the core production network (e.g., email) and one for managing the OOB.
Placing the inner sensor. On the inside of the perimeter firewall, in this case, within the DMZ, you can place a second sensor (see the lower red line). This sensor provides assurance that the DMZ machines are behaving properly and also verifies your firewall rule set. Just as you need to evaluate what's happening outside your network, you need to know how much dangerous traffic gets through your access control (i.e., firewall). To verify that the firewall is successfully applying its rule set, you can compare data from the outer and inner sensors. For example, if, on the outer sensor, you find many instances of RFC 1918 addresses, you want to know whether those addresses also appear inside. If they do, you know that you must reconfigure your firewall.
The comparison doesn't occur automatically. You must know—from a port, protocol, and application perspective—what inbound traffic the firewall permits. If the internal sensor stops traffic that the outer sensor saw but let pass through the firewall security membrane, you've just identified a firewall rule or configuration error that you must correct immediately.
For administrative purposes, the OOB is connected to both firewalls. The OOB might also send outbound traffic to the Internet (e.g., to perform searches or to update software), but you should never permit access from the OOB to the internal network—it's simply too risky.
Managing Your Network IDS
After you place your network IDS sensors correctly, you need to manage the information you receive. Your organization's overall approach to security—its security posture—determines how you characterize the occurrences—events and incidents—that your security system reports. An event is an occurrence that you can observe; it might or might not be a problem. For example, you might see that a node Address Resolution Protocol (ARP) has been queried—or "ARPed"—for an IP address. An incident is also an occurrence that you can observe but that you identify as both purposeful and problematic.
You need to manage the security information for a couple of reasons. Because every organization has a different threshold (i.e., the point that determines whether you classify an occurrence as a security event or a security incident), you'll find few agreed-upon best practices that you can implement. In addition, initial classifications aren't absolute: Many occurrences remain classified as security events until related occurrences come to light that lead you to reclassify them as security incidents. Finally, when you monitor any security system, especially a network IDS, you're bound to see false positives—alerts that appear to be evidence of an incident but that you can eventually classify as events.
Understanding false positives. In essence, a false positive is a security event that's mischaracterized (based on your organization's security stance) as a security incident. For example, a sensor might give an event too high a priority, which then triggers unnecessary alarms. Although the organization sets the event-incident threshold, false positives are difficult, if not impossible, to avoid. To set up the explanation of false positives, let me first give you some common examples of "true" positives.
Despite the subjective nature of classifying security-related occurrences, some events are usually (and properly) classified as incidents. The following occurrences indicate that something or someone is trying to penetrate (or already has penetrated) your defenses:
- Incoming connections with internal IP addresses. Obviously, inbound (i.e., outside) connections shouldn't have inside addresses. This attack is geared to trick your firewall into believing that legitimate systems have initiated the connections.
- Packets with destination or source addresses that fall within the reserved address space ranges defined in IETF RFC 1918. RFC 1918 designates IP addresses 10.0.0.0 through 10.255.255.255, 172.31.16.0.0 through 172.31.255.255, and 192.168.0.0 through 192.168.255.255 as reserved address space set aside for internal use only. You should never see these addresses on or incoming from the Internet, but because of attacks and ISP misconfigurations, you do. (For more information about RFC 1918, go to http://www.ietf.org/rfc/rfc1918.txt.)
- Unexpected outgoing connections on suspect channels (e.g., the Internet Relay Chat—IRC—channel). Worms commonly use such channels to communicate back to their creator about their progress.
Intrusion detection sensors must be tuned and tweaked to keep false positives to a minimum. In the field of information security, we usually prefer more information to less. Because of the somewhat subjective nature of alerts, most systems are set to alert. The vendors that make IDS sensors don't extensively preconfigure the sensors, but they do set sensitivity levels that might not make sense for your organization. Therefore, tuning your sensors is an important step in reducing false positives and enabling the sensors to look for data that's truly important. You have a couple of ways to reduce the amount of time you spend chasing down red herrings.
Fine-tuning network IDS alerts. First, you can usually adjust the rating system within your network IDS software to a different level of alert. In systems such as the network IDS Snort, for example, a classification.config file sets up 13 levels of alert that range from "not suspicious traffic" to "Successful Administrator Privilege Gain." (For more information about this open-source network IDS, go to http://www.snort.org.) The alert levels are tied to specific alerts in individual rule files (e.g., exploit.rules) or in a concatenated configuration file. I don't recommend adjusting the alert classification levels unless you fully understand both the nature of an attack and the reason for the alert. However, if you feel sufficiently confident that what's being reported isn't useful to you and your organization, you can make changes.
Second, you can completely remove the logic that looks for a particular event. In most modern sensors, the logic (i.e., the set of "fingerprints" the sensor uses to identify potential attacks) is modular so that you can set your sensor to look for fewer potential attacks and thereby achieve better performance. Keep in mind that the sensor must look at every packet that passes it and must reassemble fragments to evaluate the entire packet. The sensor must be balanced for your network; otherwise, traffic can overload the sensor until the sensor drops packets without inspecting them. In Snort, the configuration files drive the types of events that the network IDS discovers. Out of the box, Snort identifies more than 900 events. In NFR Security's network IDS, a GUI lets you add and remove back ends (i.e., modules that categorize what the sensor will look for, such as SMTP attacks) from the distributed sensors to eliminate unnecessary analysis.
In either case, you should run your sensors for a while to get a feel for what actually occurs on your network and come to recognize which alerts are more meaningful than others. You might see activity that at first looks harmless but later discover that this innocent-looking traffic preceded an attack. Having "forensic evidence" to examine is valuable. Take time to understand the details of your network and its traffic—what should be present on the network and what shouldn't; what you want to have trigger an alert and what you can safely ignore—then fine-tune the sensors. Don't make the mistake of turning anything off or reducing the alert sensitivity before you really have a complete grasp of what's happening.
Monitoring your network IDS. When you deploy a network IDS at your perimeter or within your internal networks, you must make a commitment to look at the information it gathers. As obvious as that sounds, it's worth saying. Don't underestimate the amount of work involved in managing a distributed sensor installation.
Because incidents don't occur during the workday only, you must monitor your sensors 24 x 7. However, you and your organization might not be prepared to do so. I know of organizations that monitor IDS alerts during workdays, review overnight alerts the morning after, and review weekend alerts on Monday. Although this approach still offers some protection, it leaves significant gaps in the monitoring process—and experienced attackers move in and out during precisely those time frames. Attackers know that evenings and weekends are the least well-staffed times, and they make their moves when they think no one's watching.
If a limited budget or staff availability keeps you from adding enough network IDS-knowledgeable members to the security group to provide coverage around the clock, you can find several excellent organizations, such as Counterpane Internet Security (http://www.counterpane.com) and Riptech (http://www.riptech.com), that can manage the monitoring process for you.
In-Depth Network Defense
For your network IDS to give you the best protection, you must deploy it effectively. After you place your sensors correctly in your organization's overall architecture, fine-tune them, and develop a good system to monitor the data they provide, your network IDS can contribute significantly to your organization's security depth.
