5.5. Local Attacks
Not all attacks come from the outside. Consider the following points:
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:
To keep the system under control, you need to:
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.
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:
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:
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.