IDS Sensor Placement

Now that you're familiar with the basics of network intrusion detection, you're ready to consider how it fits into your environment from a network architecture standpoint. It can be difficult to balance your desire to monitor as much of your network as possible with financial and staffing limitations. This section looks at the need for having multiple IDS sensors and where they are typically placed in a network. We'll also discuss some issues that can affect sensor placement, as well as the advantages of implementing a separate IDS management network.

Deploying Multiple Network Sensors

In many environments, you should deploy multiple IDS sensors. Each sensor generally monitors a single network segment. In a small organization with a simple network architecture and limited traffic, a single sensor might be adequate, although more than one might still be advisable in high-security situations. In larger environmentsparticularly those with many network segments, those that offer substantial Internet-based services, and those with multiple Internet access pointsmultiple sensors are almost certainly needed to adequately monitor network traffic.

Deploying more intrusion detection sensors usually produces better results. By deploying sensors on various network segments, you can tune each of them to the traffic you typically see on that segmentthe type of hosts that use it and the services and protocols that are traversing it. You would probably tune a sensor on an Internet-connected segment much differently than you would tune one that is monitoring traffic between two tightly secured internal portions of your network. If you deploy only one sensor, the amount of tuning you can do is generally quite limited. Of course, if you deploy multiple sensors, you need to be prepared to handle the increased number of alerts that will be generated. Placing additional sensors on the network is not very helpful if administrators do not have time to maintain and monitor them.

Another reason for using multiple sensors is the fault tolerance of your IDS. What if your single sensor fails, for any reason, or the network segment that it's monitoring is unexpectedly unavailable? If you have one sensor, you won't have a network intrusion detection capability until the failure is corrected. Having more than one sensor provides a more robust solution that can continue monitoring at least portions of your network during a sensor failure or partial network outage.

Placing Sensors Near Filtering Devices

Typically, you deploy IDS sensors, which are often paired with firewalls or packet filters, near Internet access points. Sometimes you place a sensor on one side of the filtering device, and sometimes on both sides. For example, an Internet firewall might have an IDS sensor on the external network segment to identify all suspicious activity, and a second IDS sensor on the internal network segment that can identify all suspicious activity that passes through the firewall from the outside.

If possible, deploy sensors on both sides of firewalls and packet filters. However, if financial or other resource constraints limit you to one sensor per filtering device, you have to decide on which side of the filtering device the sensor should be deployed. It's often recommended that the sensor be placed on the outside network so that it can detect all attacks, including those that don't get through the filtering.

However, in some cases, you might prefer to put the sensor on the inside network. Sensors on an outside network, particularly one that is connected to the Internet, are more likely to be attacked, and they're also going to process much more traffic than a sensor on an inside network. In addition, if your staff has limited time to perform intrusion analysis and can only address the most serious threats, putting the sensor on the inside network collects data and generates alerts only on attacks that get into the network. Another advantage to putting a sensor on the inside network is that it can help you determine whether your filtering device is misconfigured.

If you're limited to one sensor, your firewall policies might be relevant to its placement. We mentioned earlier that you should also consider issues involving outgoing traffic from compromised or malicious hosts within your own environment. If your firewall has a default deny policy for outgoing traffic, a sensor on the inside network is required to identify attacks that your internal hosts attempt against external hosts but that your firewall blocks. If your firewall has a default allow policy for outgoing traffic, the sensor's location is much less important (as long as there's one near your firewall).

Another factor in sensor deployment is the volume of data to be processed. If a network segment has an extremely high volume of data, you might want to deploy multiple sensors with different configurations to split the traffic. After a sensor starts dropping packets, you will almost certainly experience more false positives and negatives. If your external network sees extremely high volumes of traffic, consider putting a sensor outside the firewall that is tuned to identify only the most severe attacks, particularly flooding-type attacks meant to cause a denial of service for your Internet connectivity or firewall. Use a second sensor inside your firewall to do more detailed analysis; this sensor should see a significantly smaller volume of data than the first sensor.

Note

Wherever there is a link to the Internet or to other external networks or hosts, there should be an IDS sensor. This rule varies from environment to environment, of course. Another great place to put a sensor is where a filtering device should be but isn't.

Placing IDS Sensors on the Internal Network

In many environments, network IDS sensors are placed along the network perimeter only, typically around Internet firewalls and packet filters. However, some environments also benefit from the deployment of additional network IDS sensors. A classic example is a company's research and development division. The company might have established a firewall or packet filter that prevents users in other divisions from accessing the hosts in R&D. Because the information on the R&D hosts is valuable to external attackers and malicious insiders, it would be prudent to deploy an IDS sensor near the firewall or packet filter.

Some companies are so security conscious that they deploy IDS sensors throughout their networks to monitor all traffic. Of course, this requires considerable financial and staffing resources, but it gives the intrusion analysts a great feel for what's happening throughout their environment. If you only look at the activity occurring on your borders, you're missing much of the picture. Remember that IDS sensors aren't limited to identifying attacks against servers; many can also find signs of worms and other malware attempting to spread through a network, sometimes before antivirus software can identify them.

Working with Encryption

When planning network IDS sensor placement, you must consider how to deal with encrypted network traffic, such as VPN connections. IDS sensors certainly don't have the capability to decrypt traffic, but that's a good thing! If all the traffic on a certain network segment is encrypted, it still might be valuable to deploy a sensor to examine packet headers and look for unencrypted traffic. To monitor the content of the traffic that was encrypted, you should deploy IDS sensors at the first point in the network where the decrypted traffic travels. In addition, you should put host-based IDS software on the host decrypting the traffic because it's a likely target for attacks.

Processing in High-traffic Situations

Consider the volume of network traffic. The amount of traffic that IDS sensors can process is dependent on many factors, including what product is being used, which protocols or applications are most commonly used, and for which signatures the sensors have been directed to look. Therefore, no simple answers exist as to what volume of traffic any particular product can handle. In general, IDS sensors reach their capacity before firewalls do, primarily because IDS sensors do much more examination of packets than other network devices do. Also, the field of IDS sensor and signature development and optimization is still fairly young, at least compared to other aspects of network security.

Configuring Switches

If portions of your network that you would like to monitor are switched, then ensure that you configured your IDS sensors and switches appropriately. Switches must have their spanning ports configured properly for network IDS sensors to see all the traffic passing through the switches. This critical configuration has adversely affected many IDS deployments. A sensor that tries to monitor traffic on an improperly configured switch might see no traffic at allor it might see only parts of the traffic, such as only one side of two-way TCP connections, which is only marginally better than seeing nothing. Thoroughly test sensors in switched environments to confirm that they are seeing all the traffic properly.

Note

In some cases, it is not feasible for an IDS to use spanning ports to monitor network activity. Some switches stop sending some or all traffic to the spanning port under peak usage. Also, a spanning port may only be able to see traffic for a single VLAN on a switch. A better alternative may be to deploy a network tap. Taps are available from several vendors, including Finisar (previously known as Shomiti), Intrusion, Net Optics, and Network Critical.

Using an IDS Management Network

To improve the security of your network IDS sensors, you might want to create a separate management network to use strictly for communication among IDS sensors, a centralized IDS data collection box, and analyst consoles. In this model, each network IDS sensor has at least two network interface cards (NICs). One or more NICs sniff traffic from monitored networks as their sole function. These NICs do not transmit traffic. Instead, the last NIC is connected to a separate management network, which is only used for transferring IDS data and configuration updates. This is also known as performing out-of-band management of the network IDS.

By implementing such an architecture, you make it much more difficult for attackers to find and identify an IDS sensor because it will not answer requests directed toward its monitoring NICs. Because the management NIC is on an isolated network, attackers shouldn't be able to reach it. Also, most monitoring NICs are pure sniffers and do not use an IP address. If an IDS sensor uses an IP address and an attacker knows what that address is, the attacker could launch a DoS against it so that it couldn't see her attacks, or she could otherwise try to hide or obfuscate her traffic from the sensor.

Implementing a separate management network has other advantages. It isolates management traffic so that anyone else who is monitoring the same network doesn't see your sensors' communications. It also prevents the sensors from monitoring their own traffic. A separate network might also be a good way to deal with potential problems related to passing sensor data through firewalls and over unencrypted public networks.

Maintaining Sensor Security

One important item that hasn't been addressed yet is that of sensor security. It's critical that you harden your IDS sensors to make the risk of compromise as low as possible. If attackers gain control of your IDS, they could shut it off or reconfigure it so that it can't log or alert you about their activities. Attackers might also be able to use your IDS to launch attacks against other hosts. However, if attackers can get access to your IDS management network, they might be able to access all your sensors. Maintaining the security of your sensors is key to creating a stable and valuable IDS solution.

Note

Most IDS vendors offer IDS appliances that have already been hardened. Typically, appliances offer only the services necessary to support IDS functions, and they are configured to minimize the possibility that they will be compromised. Configuring and deploying an appliance-based sensor generally requires much less effort than building a sensor. However, when a new OS or service vulnerability occurs, it may not be possible to patch the appliance until the vendor releases updated software, because many appliances do not provide any OS access.