Case Studies

Now that we have discussed some of the factors that go into sensor placement, let's look at three different scenarios. Each one is shown through a simplified diagram of the relevant portions of the network. No right or wrong answers exist, only reasons why certain locations might be more beneficial than others.

Case Study 1: Simple Network Infrastructure

Figure 8.1 shows a network diagram for a small organization with a simple network infrastructure. It has only one connection point to the Internet. A firewall divides the network into three segments:

• An external DMZ segment that is connected to the Internet

• A screened subnet that contains servers that are directly accessed by Internet-based users or must directly access the Internet, such as email, web, web proxy, and external DNS servers

• An internal segment that contains servers that typically aren't directly connected to the Internet, as well as workstations, printers, and other host devices

Figure 8.1. This is a simple network infrastructure that includes IDS sensors and a separate IDS management network.

In this environment, incoming connections from the Internet can only be made to hosts on the screened subnet; those hosts can then initiate connections to the internal network. Hosts on the internal network can initiate connections to hosts on the screened subnet or directly to Internet-based hosts. Although the firewall has a default deny policy for incoming traffic, it has a default allow policy for outgoing traffic. Little outgoing traffic is restricted.

IDS Deployment Recommendations

Figure 8.1 shows the IDS management network as a separate entity from the monitored networks. Each sensor contains two NICs: one sniffing packets on the monitored network, and the other transmitting IDS data on the management network. The management network is connected only to the sensors, a central IDS logging box, and the analyst workstations.

Ideally, all three network IDS sensors shown in Figure 8.1 should be deployed. IDS 1 (on the external segment) looks for any probes, scans, or attacks coming from the Internet. IDS 2 (on the internal segment) shows you which malicious traffic got through the firewall to your internal network. Both IDS 1 and IDS 2 can monitor outgoing traffic as well, looking for attacks from your internal hosts. IDS 3 focuses on identifying attacks against your externally exposed boxes, which are the most likely targets of attackers. The same sensor is also able to monitor network activity between your external servers that doesn't pass through the firewall. If one of your external hosts becomes compromised, this is the only sensor that could see attempts from it to compromise other hosts on the same segment.

Case Study 2: Multiple External Access Points

Figure 8.2 shows a more complicated network. This environment has multiple external points of access: a dedicated connection to the Internet, a dial-up modem bank for remote users, and multiple frame relay connections to remote offices and business partners. Firewalls have been deployed at each access point to restrict the traffic that enters the internal network.

Figure 8.2. A more complex corporate network has multiple external points of access, which each need to be protected with IDS sensors.

IDS Deployment Recommendations

This scenario follows the same general rule as before: Whenever practical, deploy network IDS sensors on both sides of firewalls and packet filters. The most interesting area to consider is that of the external networks connected through the frame relay connections. You will notice that no sensors monitor the connections on the external side. If your budget permits, you can add sensors to those connections as well, although they might not be needed. It depends on what is on the other side of the connection and what your firewall is supposed to be doing.

You might feel that a remote office poses little threat and that a separate sensor to monitor its connection is not necessary. Of course, you could also deploy a sensor at the remote location, which would monitor traffic before it was sent over the frame relay connection. If the remote site is a business partner's network, you might want to be more cautious; however, your firewall might only be permitting a small, well-defined set of traffic to pass through. The risk might be small enough that you can't justify the expense of an additional sensor. Perhaps the connection to your business partner is largely unrestricted, in which case you would want to monitor it much more closely. If you decide to deploy sensors for the external links that enter the firewall, and the firewall has several interfaces on separate network segments, you would probably want to deploy a sensor for each segment. Each sensor can then be tuned for the nature of that particular connection.

Another item to consider is the risk that outgoing attacks and probes pose. If you are not restricting outbound traffic very much, then sensor placement shouldn't be affected by it. But if you do restrict outbound trafficfor example, you block all connection attempts from the internal network to the modem bankthen having the sensor on the inside is necessary to detect attempted attacks. The question is, how much do you care about that? In your environment, is it sufficient for the firewall to report that a connection attempt was blocked, or do you need to know what the nature of that attempt was? How important is the resource on the other side of the connection? What are the consequences if you fail to notice an attack from one of your hosts against your business partner's systems?

Case Study 3: Unrestricted Environment

Our final case study, shown in Figure 8.3, is a greatly simplified view of a university network with three main groups of hosts: students, faculty and staff, and administration (registrar, bursar, and so on). As is typical of many university environments, no firewalls restrict traffic. A small amount of packet filtering might occur at routers throughout the network, but otherwise, virtually any sort of traffic is permitted. The only exception is some machines in the administration network that contain sensitive information, such as student grades and financial information; these machines are somewhat protected through router packet filtering. Because of the open nature of most universities, faculty and student machines are usually vulnerable to exploitation, in part because just about any sort of traffic is permitted. In addition, many servers are run by students or faculty, not centralized IT staff, and are almost certainly not kept fully patched and secured.

Figure 8.3. In a university environment with little network security, it is not easy to determine where to deploy IDS sensors.

We can expect many student and faculty machines to use modems or wireless network cards. We can also expect that some of these machines run software such as pcAnywhere to allow external hosts to dial in to them. In such an environment, it's impossible to define the border of your network. It's also likely that the university offers dial-in services for users. These services may require little or no authentication.

IDS Deployment Recommendations

As you might imagine, the security requirements of the groups of hosts shown in Figure 8.3 are quite different. In addition, staffing and financial resources are probably quite limited, so you need to focus on the most important areas. Your first priority is protecting the administrative computers, which are at high risk of being attacked. You want to monitor these systems as closely as possible, through a combination of IDS sensors deployed to the segments where the hosts reside, and host-based IDS software running on all of them. If you can do nothing else, you need to regularly monitor IDS alerts and logs related to these sensitive hosts.

Even if you have the resources to deploy and monitor additional sensors, will you have the resources to react to what you see? These environments might contain tens of thousands of largely unsecured machines that can be infected with viruses, Trojans, or other malware. This is a similar problem to that seen by Internet service providers (ISPs), which carry customer traffic but have little control over what their customers do. In fact, portions of a university network can be thought of as an ISP for students. If network IDS sensors are deployed, they need to be carefully tuned to only send alerts on the most severe attacks. If the sensor sends an alert every time a port scan or host scan occurs, the intrusion analyst will quickly be overwhelmed with alerts. Sensors might also be unable to keep up with the high volumes of traffic if they are performing too much analysis.

You might be asking yourself, "Why should I bother trying to monitor this traffic at all? If users are permitted to do almost anything they want to, why should I try to deploy sensors to the networks they use?" Here's a scenario that explains why some level of network intrusion detection should be performed. Suppose that hundreds of hosts throughout the university have been infected with the same Trojan and that these hosts are used to launch DDoS attacks against other sites. Given the lack of other defense devices, deploying an intrusion detection sensor to monitor outgoing traffic may be your best chance of quickly detecting such an attack and collecting enough information about it to identify the infected hosts.