The most critical part of intrusion detection and prevention is the proper deployment and placement of your sensors. An IDS/IPS is only going to be effective if it is deployed in such a manner that it can monitor the traffic that is of concern.
Figure 4-1 illustrates how you would connect two IDS sensors to your network to monitor the traffic entering and exiting your Internet DMZ segment as well as the traffic in front of your firewall. The monitoring interfaces are connected to switches, which mirror the traffic from the ports that the firewall is connected on to the ports that the IDS is connected on. The management interfaces are connected back to the internal network (preferably on a management subnet), allowing the IDS sensors to be managed by a central management console.
Figure 4-1: Connecting your IDS/IPS to the network
Throughout this chapter, I have referred to intrusion detection and intrusion prevention as almost the same thing. In truth, there are many similarities between the two; however, they are two distinct products with unique roles in your environment.
Intrusion detection is just that, detection. As mentioned earlier in this chapter, intrusion detection is largely a process of implementing an alarm system throughout your network to notify you of situations that
Intrusion prevention takes detection a step further and
In practice, however, IPS often misses the mark because the detection process is not a perfect science. There are still far too many false positives that can occur in the detection process, and a misconfigured IPS can take a false positive and create one of the very same things it is trying to prevent ”a denial of service by preventing
Attacks originate from both internal and external sources. As a result, it is important to locate your intrusion detection and prevention systems where they can monitor not only external traffic, but internal traffic as well. Because of this requirement, you need to plan on IDS/IPS being a system of devices, not a singular device. The following locations are recommended locations for IDS/IPS sensors:
In front of your external firewall Although there is some debate as to the value of placing a sensor outside your firewall, I recommend it so that you can gain some kind of insight as to what is happening that your firewall is protecting you from. The sensor should be configured to monitor the traffic on the switch port that the firewall is connected to. When you implement the IDS/IPS in this location, I recommend that you significantly tune down the alerts because much of this traffic should be blocked by the firewall.
Behind your firewalls that provide access to DMZ or internal networks This is the most common location for sensor placement because these network connections represent choke points where all traffic between network modules must pass. The sensor should be configured to monitor the traffic on the switch port that the firewall is connected to. When you implement the IDS/IPS in these locations, I recommend that you configure the sensor to monitor and alarm on any suspicious traffic, because an alarm at this point means that the traffic has bypassed the firewall in some way.
Integrated into your gateway devices Many gateway devices, such as firewalls, have IDS and in particular IPS functionality built in. This is the location where I recommend most IPSs be implemented, because the firewall is already providing blocking functionality, and the IPS function merely extends that functionality.
Behind your VPN
In front of your server segments
Because your servers
Behind your WAN connections With the nature of worms, WAN connections represent an easy point for them to spread. As a result, I recommend that you implement an IDS/IPS to monitor the traffic that is passing through your WAN connections. You should configure the monitoring interface to monitor the traffic on the switch port that connects the WAN router to the internal network.
On your extranet connections
Because extranet connections imply a connection to a remote network that you probably do not have administrative control over, you should make
On any segment that contains or connects to critical resources
This is the generic
Network diagrams illustrating sensor placement are provided in Chapters 11 and 12.
One of the most confusing aspects of sensor placement is implementing them in a switched network. As you know, the whole purpose of a switched network is to prevent systems on one port from receiving traffic destined for systems on another port. This creates a problem because the sensor needs to be able to monitor all traffic passing for a given segment if you want it to be effective. You can address this, however, by connecting the sensor monitoring interface to a switch port that is configured to receive mirrored traffic from the switch ports that you want to monitor traffic on. This is referred to as a
Switched Port Analyzer (SPAN)
by Cisco; other
You can implement SPAN on a CATOS-based switch by running the following command at the CLI:
switch03> (enable) set span 1/1 2/1
In this example, SPAN is configured to mirror the traffic from interface 1/1 to the destination interface 2/1, where the sensor is connected.
You can implement SPAN on IOS-based switches by running the following command at the CLI:
switch02(config)#monitor session 1 source interface Fa0/1 switch02(config)#monitor session 1 destination interface Fa0/5
In this example, SPAN is configured to mirror the traffic from interface Fa0/1 to interface Fa0/5, where the sensor is connected. Although this example shows a one-to-one mirror, it is common to mirror multiple ports to a single monitoring port.
Another issue with implementing sensors on a switched network occurs when you want the sensor to be able to block unauthorized traffic. Many switches prevent a monitoring port from being able to send traffic. The sensor, however, needs to be able to transmit the countermeasure packet (typically, a spoof of the original source MAC address) in order to block the session. In addition, because the sensor is going to spoof the MAC address of the system that it is trying to protect, the switch needs to be configured to disable MAC learning on the monitoring port. If you do not do this, the switch will send all traffic for the destination system to the sensor until the server transmits and causes the switch to relearn the port that it is connected to. You can configure this on your CATOS-based switches by running the following command at the CLI:
switch03> (enable) set span 1/1 2/1 inpkts enable learning disable