Denial-of-Service

UNIX systems are susceptible to denial-of-service (DoS) attacks because, among users, many of the system’s resources are shared including kernel resources, disk storage, and memory. This section describes a few DoS attacks that can occur even if the user does not have special privileges. As UNIX OSs have become more mature, they have been placing per-user restrictions on resources, such as the number of concurrently opened files, file-system quota, number of concurrently running processes, memory consumption, and network buffers. Still, it is possible to bring almost any UNIX system to a virtual stop by running a script such as the following:

cd /tmp
while TRUE
do
mkdir foo
cd foo
done

In other words, filling up the /tmp file system will affect a large number of UNIX system processes because the /tmp directory is where they often go for temporary storage. How a particular version of UNIX behaves in response to this situation varies, but some versions cannot even boot if /tmp is out of space. The attack is still possible today because /tmp might fill up before a user’s file-system quota is reached.

This attack is representative of a class of attacks in which a user attempts to exhaust a resource by running the same command repeatedly. To catch this behavior, an IDS needs to set a threshold condition. You must consider two variables:

•  At what value to set the threshold

•  What commands or operations to monitor

A threshold of 3 for this sequence is reasonable for indicating an attack as opposed to a wandering, inexperienced user. The threshold applies to the pair of events—mkdir and cd—rather than 3 arbitrary mkdir commands in sequence. For simplicity, assume that the AUID, RUID, EUID, and corresponding GIDs have not changed across audit events. Also, recall that for each command, a separate audit record will be emitted. Because the audit trail also shows the parameters passed to the command, you could watch for a sequence of audit records with content like the following:

mkdir value, cd value repeated N times

This type of pattern would catch the specific case shown previously. If the abuser is smart, some randomness could be introduced into the attack to avoid detection. The name of the directory created each time could be randomized, but a cd still would switch to the newly created directory each time to set up the next iteration:

mkdir random-val1 followed by cd val1, where val1 equals random-val1,
but random-val1 changes on each iteration.

Certainly, dozens more possible variations exist just for this one attack. What you will not find in commercial IDS tools are many patterns to detect all of the combinations of ways this attack can be programmed. In pattern-matching systems, what you are likely to find is single-command thresholds. If you have a system-level IDS and you can configure in detail what the system looks for, the previous paragraphs give you an idea of what to look for in the data. Another simple, general pattern, which looks for a threshold number of operations, that consume space in /tmp is another possibility. In the audit log, the events one would look for are file create, make directory, and link. However, if you attempt to also track file writes, you could end up with too many false positives. A number of programs create and remove files in /tmp as part of their normal operations. Deciding on the threshold value is not going to be simple either. You need to set it based on observation.

A useful feature of statistical anomaly IDSs is that their general mode of operation is to count execution of user commands or audit event types. A user who runs an unusual number of mkdir commands will generate an alarm in a real-time IDS. The problem with some statistical IDSs is their granularity. For example, someone who receives a tar image that creates a few dozen subdirectories will generate a number of mkdir commands. The preceding attack is not based on generating many different mkdir commands, but on the fact that the parent directory is /tmp or one of its descendants. Merely counting the number of directory create events, even if read from the audit log, is insufficient for differentiating an attack against /tmp from a tar file extraction in another directory. Contextual information also must be examined by the statistical monitor. Therefore, if you have a statistical monitor, you’ll have similar problems in choosing a threshold. You’ll have the added problem of not being able to specify context information. Only pattern-matching IDSs enable you to form complex constraints with context information such as the following:

if the same user runs one of these three commands (link, create, mkdir)
and the user is in /tmp or in a descendent of /tmp, nuke ‘em

Other Denial-of-Service Attacks

If a local user wants to launch a network DoS attack remotely against your system, nothing exists to prevent this from happening. Someone can run through all of the users and purposely fail login attempts until everyone is locked out. However, if the user is already logged into your system and tries to run attacks against other systems, it is easy to detect and assign accountability for this behavior from the audit logs. You simply can look for audit records that contain the name of the program that a user is running. Most records also contain the data that the user specified as well. Many IDSs allow you to configure tagged file lists containing the names of known rogue programs. You could create a tagged file list with names of DoS programs to help watch for times when your users are carrying out these kinds of attacks against other systems.