PART 2
Intrusion Detection: Beyond Traditional Security

Now that you’ve examined the roles and limitations of traditional security tools, it’s time to take a closer look at intrusion detection. In this part of the book, you’ll see how attackers can get through your existing defenses and how intrusion detection systems (IDSs) detect these events. This part includes four chapters that describe the following:

•  What intrusion detection is, how this tool category differs from others, and the value that intrusion detection brings to your site

•  How vulnerability scanner intrusion detection tools look for known program bugs or configuration errors to warn you of security holes

•  How system-level intrusion detection catches activities that many other products miss

•  How network-level intrusion detection sees hacker activities by inspecting network packets

As you learn about each of these IDSs, you also will be asked to think about the problems they do not solve. Your insights will help you understand the role that an IDS fulfills at your site. Also, thinking about how an IDS can be improved is necessary for evaluating future releases of IDSs.

Chapter 5
Intrusion Detection and Why You Need It

Within the last two to three years, many people thought that if they wanted to connect to the Internet, only a firewall was necessary to complete the security puzzle. In this chapter, you start by looking at how common scenarios you expect to be secure are really not. As you see why hackers can still get through, you will realize the value that an Intrusion Detection System (IDS) adds.

After going through these detailed examples, the central themes of an IDS are explained. In this chapter, you can read about the different type of IDSs, design tradeoffs in building an IDS, and learn the critical questions to ask about an IDS tool you might be considering. When you have finished this material, you will be ready to jump into the next few chapters, which describe specific IDS approaches in more detail.

Do You Have Protection?

Figure 5.1 contains a diagram of an Internet configuration for a company with a public Web server. Notice that the Web server itself is encased in a perimeter network. At first, people tried to directly attach Web servers to the Internet without screening routers or firewalls to block attacks at the Internet entry point. This configuration was tried despite warnings from Morris (1986) and Bellovin (1988), which were discussed in Chapter 4, “Traditional Network Security Approaches.” However, now it is rare to see a Web server connected directly to the Net without protection as shown in Figure 5.1. The question to ask is whether this Web server is safe from security breaches.

Figure 5.1  Common perimeter configuration for a Web server.

If the answer is “Yes,” this chapter will certainly be short. As history has shown, almost no server is immune to penetration. The problem is that we can defend only against attacks known about today. Nothing prevents a publicly accessible system from being compromised by an attack that is newly discovered tomorrow.

The untrusted Internet and the perimeter network in Figure 5.1 are separated by a screening router. What is the role of the screening router in this configuration? TCP/IP packet level attacks that require address impersonation (or IP address spoofing) are eliminated by the router because it is configured to do the following:

•  Block any inbound packet from the Internet to the perimeter that has a source IP address from the perimeter network

•  Block any outbound packet from the perimeter to the Internet that has a source address from outside the perimeter network

•  Block any inbound packet with source routing enabled

The screening router may be configured to block other attacks, such as Ping of Death or SYN Flood, which are targeted at the Web server. Other threats also may be addressed if the router is sophisticated enough. One thing that this screen will definitely not block is HTTP traffic. Otherwise, no one would be able to connect to the Web server.

Chances are that the router does not perform any application-specific checking of the network packets, such as looking at the URL being requested in incoming packets. Screening routers apply access control using network concepts, such as source address, destination address, port number, and TCP header field settings.

Several reasons why this common configuration alone is not enough for a secure defense are as follows:

•  Vendor software on one of these systems contains a software bug that will result in a security problem. The bug could be in the operating system, in the Web server, or in the router implementation.

•  Executable programs or scripts created at your site and called by the Web server can have flaws.

•  One or more of the defense mechanisms will not be configured properly. Ample data supports this claim. When Dan Farmer ran a few scans against public Web servers in 1997, he found well over 80 percent to be open to some form of attack.

These items should be familiar by now because they are variations on the common reasons why hackers get through—software bugs or configuration errors.

In 1997, a rather nasty flaw in the Microsoft Internet Information Server (IIS) was discovered. With a little effort, it was possible to discover a URL of a particular length that would crash IIS. Anyone with a Web browser could send a URL of this size in HTTP. IIS would process the URL to open it, but a bounds checking problem caused IIS to hang or crash instead. Microsoft fixed the bug, but it serves as a good example of something that first-level defenses, such as screening routers, were not checking for at that time. The attack did not give the hacker access to the server, and therefore, Web site content remained safe. However, if a company had been depending on the Web site for revenue, the down time would have had a measurable impact. The perimeter network shown in Figure 5.1 did not stop this attack because HTTP packets were allowed into the Web server.

Microsoft was not the only vendor hit as a consequence of program errors. The Apache Web server also had a serious bug that impacted several sites. Writing error-free code is difficult, and as long as there is a possibility for bugs, a potential for security threatening consequences exists, as shown in Figure 5.1.