Section 5.5. Local Attacks

5.5. Local Attacks

Not all attacks come from the outside. Consider the following points:

In the worst case scenario (from the security point of view), you will have users with shell access and access to a compiler. They can upload files and compile programs as they please.
Suppose you do not allow shell access but you do allow CGI scripts. Your users can execute scripts, or they can compile binaries and upload and execute them. Similarly, if users have access to a scripting engine such as PHP, they may be able to execute binaries on the system.
Most users are not malicious, but accidents do happen. A small programming mistake can lead to a server-wide problem. The wider the user base, the greater the chances of having a user that is just beginning to learn programming. These users will typically treat servers as their own workstations.
Attackers can break in through an account of a legitimate user, or they can find a weakness in the application layer and reach the server through that.

Having a malicious user on the system can have various consequences, but in this chapter, we are concerned only with the DoS attacks. What can such a user do? As it turns out, most systems are not prepared to handle DoS attacks, and it is easy to bring the server down from the inside via the following possibilites:

Process creation attacks: A fork bomb is a program that creates copies of itself in an infinite loop. The number of processes grows exponentially and fills the process table (which is limited in size), preventing the system from creating new processes. Processes that were active prior to the fork bomb activation will still be active and working, but an administrator will have a difficult time logging in to kill the offending program. You can find more information about fork bombs at http://www.voltronkru.com/library/fork.html.
Memory allocation attacks: A malloc bomb is a program that allocates large amounts of memory. Trying to accommodate the program, the system will start swapping, use up all of its swap space, and finally crash.
Disk overflow attacks: Disk overflow attacks require a bit more effort and thought than the previous two approaches. One attack would create a large file (as easy as cat /dev/zero > /tmp/log). Creating a very large number of small files, and using up the inodes reserved for the partition, will have a similar effect on the system, i.e., prevent it from creating new files.

To keep the system under control, you need to:

Put user files on a separate partition to prevent them from affecting system partitions.
Use filesystem quotas. (A good tutorial can be found in the Red Hat 9 manual at http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-disk-quotas.html.)
Use pluggable authentication modules (PAM) limits.
Keep track of what users are doing via process accounting or kernel auditing.

PAM limits, process accounting, and kernel auditing are described in the following sections.

5.5.1. PAM Limits

PAM limits allow administrators to introduce system-wide, per-group, or per-user limits on the usage of system resources. By default, there are virtually no limits in place:

$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 10240
cpu time             (seconds, -t) unlimited
max user processes            (-u) 2039
virtual memory        (kbytes, -v) unlimited

To impose limits, edit /etc/security/limits.conf. (It may be somewhere else on your system, depending on the distribution.) Changes will take effect immediately. Configuring limits is tricky because restrictions can have consequences that are not obvious at first. It is advisable to use trial and error, and ensure the limit configuration works the way you want it to.

One thing you cannot do with PAM limits is control the number of Apache processes because new processes are created while Apache is still running as root, and PAM limits do not work on this account. You can still use the MaxClients directive though.

5.5.2. Process Accounting

With process accounting in place, every command execution is logged. This functionality is not installed by default on most systems. On Red Hat distributions, for example, you need to install the package psacct. Even when installed, it is not activated. To activate it, type:

# accton /var/account/pacct

Process accounting information will be stored in binary format, so you have to use the following tools to extract information:

lastcomm: Prints information on individual command executions.
ac: Prints information on users' connect time.
sa: Prints system-wide or per-user (turn on per-user output with the -m switch) summaries of command execution.

5.5.3. Kernel Auditing

The grsecurity kernel patch (http://www.grsecurity.net) gives even more insight into what is happening on the system. For example, it provides:

Program execution logging
Resource usage logging (it records attempts to overstep resource limits)
Logging of the execution of programs in a chroot jail
chdir logging
(u)mount logging
IPC logging
Signal logging (it records segmentation faults)
Fork failure logging
Time change logging

Once you compile the patch into the kernel, you can selectively activate the features at runtime through sysctl support. Each program execution will be logged to the system log with a single entry:

May  3 17:08:59 ben kernel: grsec: exec of /usr/bin/tail (tail messages )
by /bin/bash[bash:1153] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:1087]
uid/euid:0/0 gid/egid:0/0

You can restrict extensive logging to a single group and avoid logging of the whole system. Note that grsecurity kernel auditing provides more information than process accounting but the drawback is that there aren't tools (at least not at the moment) to process and summarize collected information.