Previous | Table of Contents | Next |
Now that youve examined the roles and limitations of traditional security tools, its time to take a closer look at intrusion detection. In this part of the book, youll 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:
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.
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.
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:
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:
These items should be familiar by now because they are variations on the common reasons why hackers get throughsoftware 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.
Previous | Table of Contents | Next |