Apache Security - Ivan Ristic [71]
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.
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.
* * *
Tip
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.
* * *
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.
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.
Traffic-Shaping Modules
Traffic shaping is a technique that establishes control over web server traffic. Many Apache modules perform traffic shaping, and their goal is usually to slow down a (client) IP address or to control the bandwidth consumption on the per-virtual host level. As a side effect, these modules can be effective against certain types of DoS attacks. The following are some of the more popular traffic-shaping modules:
mod_throttle (http://www.snert.com/Software/mod_throttle/)
mod_bwshare (http://www.topology.org/src/bwshare/)
mod_limitipconn (http://dominia.org/djao/limitipconn.html)
One module is designed specifically as a remedy for Apache DoS attacks:
mod_dosevasive (http://www.nuclearelephant.com/projects/dosevasive/)
The mod_dosevasive module will allow you to specify a maximal