Chapter 6
Detecting Intruders on Your System Is Fun and Easy

Well, perhaps the title of this chapter is a slightly misleading. Supposedly, becoming an intruder is fun and easy, too. If you want to detect intruders, you should know what type of system resources can be depended on for providing evidence. Should you want to become an intruder, you ought to know how commercial IDSs look for traces of your activity.

Scanners are designed to take a look at your system and to let you know whether you have configuration problems or holes that can be used for attacks. If your system was previously set up in a secure fashion, and an intruder has altered this configuration, a scanner will detect this change (when you run the scan) and notify you of the problem.

System-level intrusion detection tools differ from scanners in a couple of ways. If the IDS runs in real time, it can let you know the instant a compromise has occurred. Also, if the monitor gathers its data by reading an activity stream on the system, it can detect a range of features that a single scanner cannot. For example, scanners will not tell you that someone just entered three bad passwords and exceeded the failed login threshold.

By the time you finish this chapter, you will understand the following:

•  How to classify attacks according to how they originate and the threat they pose

•  The pros and cons of different data sources that a system monitor can use for decisions

•  What system monitors can and cannot detect

•  The tradeoffs you may need to make for monitoring your systems in real time

•  What it takes to really track someone through a network

As you will soon see, you need to consider a number of issues when trying to build a system-level IDS.

Classes of Attacks

Table 6.1 provides a convenient way of looking at attack categories. You can see that threats generally are divided between internal and external points of origin. Along the other axis, you see increasingly more severe attacks. Inside the table are relative indications of the seriousness of the consequences. If an internal user obtains privileges belonging to other users, you usually can rectify the situation and perhaps take legal action. When someone outside your network is able to gain superuser access into one of your nodes, you have a catastrophic breakdown in security somewhere. Also, because so many ways to hide one’s identity from the outside exist, the chances of catching the intruder are slim.

Internal Attacks

Statistics from the FBI Crime Lab consistently show that the majority of computer crime occurs from the inside. True, as more people connect to the Internet, the threats from outside increase. Today, most crimes still are committed by insiders, or at least outside criminals are assisted by insiders. The theft of millions of dollars from a major U.S. bank was launched from Russia, but collusion from an insider made the task easier. Most of the money was returned. Although some companies do not like to think of their employees, contractors, or business partners as potential criminals, historical data encourages them to do so. What are some of the threats that an insider poses to internal systems?

Internal Denial-of-Service Attack

Recently, a number of NT systems at the University of Texas were hounded by a denial-of-service attack against the IP stack delivered with NT. The attack was a variant of the Teardrop UDP attack that was possible because of a bug in NT. By sending certain types of UDP datagrams, an adversary could cause the system to crash. Because UDP packets often are blocked by screening routers or firewalls, this threat was unlikely from outside sources. Someone with access to one of the UT labs launched the attack internally.

Users with accounts on various company servers or on university systems pose threats because they already have access to the system. When you are able to establish a login session on a computer, a number of denial-of-service attacks rare possible:

•  Consume all of the disk space in the /tmp directory of UNIX systems to slow or crash the system (depending on how that particular version of UNIX handles this condition)

•  Write a program to consume all available resources such as all of the memory buffers allocated for sockets

•  Fill up the printer queue directory

•  Create a number of concurrent I/O bound processes that thrash the disk repeatedly

You really don’t even need an account on a system to cause problems. As shown in Chapter 2, “The Role of Identification and Authentication in Your Environment,” physical or network access is sufficient for locking all accounts with failed login attempts until the lockout threshold is hit for each account. If the system permits remote logins from other nodes inside the enterprise, failed login attacks are possible even when physical access is not granted.

Most environments run a large number of client-server applications. The telnet program is a well-known example. However, numerous proprietary client-server protocols are running throughout the enterprise, and each of these also is susceptible to denial-of-service attacks. For example, it is unlikely that many legacy applications are performing adequate authentication of packets received. Forged IP addresses and packets can find their way into listening servers and cause denial-of-service attacks. If the servers are designed to accept connections from any internal node, it’s easy enough to create packets, flood the server with them, and thus render the server useless.

In general, the closer you can get to running on the system directly, the more damage you can potentially do.