6.3 Sensor Placement

Since the Snort sensor can only alert on what it sees, the placement of the sensor is very important. In many networks, putting the sensor in the wrong spot can cause you to miss an entire network's traffic. Figure 6-1 illustrates this in a simplistic example. If you place the Snort sensor at point A, you will be able to see all traffic between the internal network and the Internet. You will not be able to see the traffic between your DMZ (containing a web server and mail server) and the Internet. In this case, an attack on your web server would go unnoticed.

Figure 6-1. The importance of sensor placement

If you put the sensor at point B, you will see all traffic between the systems in your DMZ and the Internet. In this case, you will not see the traffic between the internal network and the Internet. Please note that this might be desirable. Perhaps you have a sensor dedicated to the DMZ with a tuned set of rules and preprocessors specifically for those servers. You might have another sensor located at point A that watches that traffic that is tuned appropriately.

Locating a sensor at point C will allow you to see all traffic traveling to and from both networks (DMZ and internal) and the Internet. Putting the sensor at point C still leaves a potential blind spot: traffic between the DMZ and the internal network will not be watched.

As you can see, connecting your sensor to the network is not a trivial decision. Let's examine some of the aspects of this decision.

6.3.1 Systems and Networks to Watch

It is not realistic to expect to watch all traffic between all systems on your network effectively with NIDS. Prioritization of your systems and networks is necessary.

Systems that provide services to the Internet are a good first choice. These systems are more at risk than systems on your internal network. They also may be providing services to your customers or business partners that are very important (if not increasingly central) to the goals of your organizations. A rule of thumb is to segregate any systems that provide services to the public Internet in a separate network that has limited access to your internal network. This arrangement makes watching the traffic much easier.

There are also a group of servers that provide services to people sitting at the desks: print servers, file servers, authentication and directory servers, mail servers, intranet servers, and databases. The incidence of false positives increases greatly when watching internal LAN traffic. The normal chatter between Windows systems can generate an overwhelming volume of such alerts and the sheer amount of effort involved in tracking these down outweighs the value of doing so. Target high-value systems—the database storing your ERP solution or your accounting systems—for NIDS sensor vigilance. You can make up for the lack of an NIDS watching traffic by the disciplined administration of your systems, including following best practices when building the systems, pervasively using antivirus software, and auditing system logs.

This isn't to say that we will ignore the workstations, laptops, and other citizens of the internal network. It is suggested that traffic between these systems and the Internet be watched by an NIDS. If you have a WAN connection to your business partners or branch offices, a sensor watching traffic across these links is advised.

The exact placement of sensors is made easier by looking for natural bottlenecks—connections between networks make very nice connection points. The point (or points) that your network connects to the Internet is an easy choice. As previously mentioned, WAN links are important bottlenecks to watch. Consider putting your internal servers on a separate network so that traffic between the networks containing your desktop users and your servers can be aggregated and watched.

One question remains: do you want to place your sensor on the Internet side of the firewall (outside) or on the internal side (inside)? Outside, the sensor sees all inbound attempts to probe the network. Inside, it provides even more targeting for your sensors, since only inbound traffic that makes it through open ports in the firewall will be monitored. Given the noise and the questionable usefulness of alerting on that noise, I prefer locating the sensors behind the firewall.

6.3.2 Creating Connection Points

The high-speed switches that most networks use direct traffic to just the ports that connect to the systems engaging in the conversation—making eavesdropping on that conversation with an NIDS sensor impossible without further assistance. Some administrators plug a small hub into the path of the traffic they want to watch. While this tactic works (hubs send all traffic out all ports), small hubs are very often not as reliable as enterprise-class switches.

There are a variety of hardware network taps that can make a copy of traffic traveling on copper and fiber network cables. Some are commercial and others can be built with instructions on the Internet. The commercial solutions are usually well made, but represent a potential single point of failure for the cable being tapped. While I know one end of a soldering iron from the other, I wouldn't want to trust my network's Internet connection to my skills.

A better solution is available from most enterprise-class switches on the market. The specific examples here are those used on Cisco switch hardware. It is possible for the switch itself to make a copy of the traffic from one or several ports and send it out a designated port that you can plug the NIDS sensor into. This is called a SPAN port (Switched Port Analyzer) by Cisco. You can mirror the traffic from a single port, or aggregate the traffic from multiple ports (even ports on remote switches!). Please note that we are talking about Cisco switches, not routers.

Because you are using your existing (likely redundant) hardware to perform this task, you are not introducing any potential failure points. Going back to Figure 6-1, if we create a SPAN port that aggregates the traffic from both points A and B, we can watch traffic between both the internal network and the Internet and the DMZ and the Internet with a single sensor interface.

Plan carefully. On Cisco switches, you are allowed only two SPAN ports per physical switch.

There is one thing to watch out for when spanning multiple ports into a single monitor port. If the total bandwidth you are aggregating is larger than the bandwidth of the port you're sending it to, the extra traffic will be lost and not monitored. For example, if you are sending the traffic from five 100 Mbps Fast Ethernet ports—each of which is carrying 25 Mbps of traffic—to a single 100 Mbps Fast Ethernet port, you will lose 25 Mbps of traffic, since you cannot send 125 Mbps of traffic through a 100 Mbps port. When possible, I try to use a Gigabit port as the SPAN port to get around this problem. In truth, this much traffic causes most systems running Snort to get little Xs on their eyes and fall over backwards. For such high traffic levels, consider some of the strategies presented in Chapter 13.

6.3.3 Encrypted Traffic

It's also important to have a good understanding of how your systems perform their business. You might want to use Snort to monitor a very important e-commerce web server that processes credit card purchases from Internet based customers. This traffic is encrypted using SSL encryption—making the transaction much more secure. It is impossible for the Snort sensor to match the content of an encrypted packet to signatures in the rule files. The goal of encrypting the traffic is to make it nearly impossible to intercept and monitor. Figure 6-2 illustrates this situation.

Figure 6-2. Snort can't watch encrypted traffic

One solution that allows your web traffic to remain encrypted (maintaining the security of the transaction) but also allows Snort to watch for signs of intrusion is an SSL proxy. SSL proxies go by many names, including Content Switch, SSL Accelerator, and SSL Proxy. This device sits between the client and the server and handles the task of encrypting the traffic. The traffic from the web server to the SSL proxy is not encrypted, but the traffic between the proxy and the web client is encrypted. Plugging the Snort sensor between the web server and the proxy allows the traffic to be monitored. Another real advantage to the implementation of an SSL proxy is the ability to offload CPU-intensive encryption tasks to a dedicated device, allowing your web servers to scale more effectively. SSL proxies very often can perform other tasks, such as load-balancing and authentication. Figure 6-3 illustrates the implementation of an SSL proxy between the web server and the client (and where the Snort sensor can be connected).

Figure 6-3. Snort is now able to watch the web transaction