Logging appears to be a simple process, and you might wonder why security is involved at all. There are some very basic security problems connected to logging. For example:

• Logs are written as root, and permission problems can be dangerous.

• Logs are written in plain text, and can be easily modified and forged.

• Logging programs are executed as root; if they are vulnerable, an attacker may gain root access.

• Logs can cause a DOS if they run out of disk space (an attacker might do this deliberately).

• Logging can be unreliable; if Apache dies (for example after an attack), they could be incomplete.

I will discuss each of these problems in the following sections.

Apache is normally started by the root user, in order to be able to listen to port 80 (non-root processes can only listen to ports higher than 1024). After starting up, Apache opens the log files, and only then drops its privileges. This allows the Apache server to write to files that no other user may access (if the permissions are set properly), protecting the log files. If the log files were opened after dropping privileges, they would be a lot more vulnerable.

This implies that if the directory where the logs are stored is writable by common users, then an attacker can do this (note the wrong permissions for the logs directory):

[merc@localhost merc]$ cd /usr/local/apache2/
[merc@localhost apache2]$ ls -l
total 52
drwxr-xr-x 2 root root 4096 Oct 4  14:50 bin
drwxr-xr-x 2 root root 4096 Sep 13 23:18 build
drwxr-xrwx 2 root root 4096 Oct 5  18:10 logs
[...]
drwxr-xr-x 2 root root 4096 Oct 4  18:50 modules
[merc@localhost apache2]$ cd logs
[merc@localhost logs]$ ls -l
total 212
-rw-r--r--1 root root 124235 Oct 5 18:11 access_log
-rw-r--r--1 root root 74883  Oct 5 18:10 error_log
-rw-r--r--1 root root 5      Oct 5 18:10 httpd.pid
[merc@localhost logs]$ rm access_log
rm: remove write-protected file 'access_log'? y
[merc@localhost logs]$ ln -s /etc/passwd_for_example 
                       access_log
[merc@localhost logs]$ ls -l
total 84
lrwxrwxrwx 1 merc merc 23   Oct 5 19:26 access_log ->
/etc/passwd_for_example
-rw-r--r--1 root root 75335 Oct 5 19:27 error_log
-rw-r--r--1 root root 5     Oct 5 19:27 httpd.pid
[merc@localhost logs]$

Obviously, this can only be done if the attacker has login access to the web server. The next time Apache is run, the web server will append to /etc/passwd. This would make the system unstable and prevent any further login by users. The solution is to ensure that the logs directory is not writable by other users.

Log files are usually stored as text files, and they are therefore very easy to:

• Forge. A cracker might want hide any trace of his or her attack, and might therefore edit out those lines that would highlight the attacks.

• Delete. Logs might be quite valuable for your company for access-analyzing purposes, and missing information might represent a problem—and a loss of money.

• Steal. This wouldn’t happen very often, but it’s a possibility, especially if your logs have any value for data mining.

A possible solution to this problem is to protect the logs (and your system) properly so that these things can’t happen. Another solution is remote logging, discussed in the second part of this chapter.

Because the logger program is run as root, it must be kept simple, and the code must be audited for vulnerabilities like buffer overflows. In addition, the directory where the program resides must be owned by root, and non-root users must not have write permissions. Otherwise, they could delete the logging program and replace it with a malicious one.

Because Apache logs can be big, you need to monitor their size. For instance, a cracker might send many requests, with the sole purpose of filling up the disk space, and then perform an attack (buffer overflow, for instance). If Apache’s logs and other system logs share the same partition, the cracker will be able to perform any kind of buffer overflow attack without being logged.

Remember that all the system logs should be directed to a partition that will not cause system-wide interruptions if it fills up, such as /var. Further, the log files should be compressed once they are archived to save disk space. In addition, you can use a script that periodically checks the size of the log directory and issues a warning if too much disk space is being used, or if the log partition is full. The script could be as simple as this:

#!/bin/bash

partition="/dev/hda5"

free_space=`df | grep $partition | cut -b 41-50`
echo $free_space

if [ $free_space -le 5000 ];then
       message="WARNING: Only $free_space blocks left on
                $partition";
       logger -p local0.crit $message 
       echo $message | mail -s "Partition problem"
                                merc@localhost
fi

This script assumes that the log partition is /dev/hda5. The available free space is taken out of the df command using cut (free_space=`df | grep $partition | cut -b 41-50). If there are fewer than 5000 blocks left (if [ $free_space -le 5000 ];then), the script logs the problem using logger, and sends an e-mail to merc@localhost. This script should be placed in your crontab, and should be executed every 15 minutes. This script can easily be improved so that it stores the available space each time in /tmp/free_space, and warns you if there has been a drastic change in the available space on the log partition. See Chapter 7 for more scripts aimed at automated system administration tasks.

After a DOS attack, the server’s accountability (the logs) may be compromised; therefore, Apache might not be able to write the entries about the attack on the log files. This means that if an attacker performed a DOS attack against your server, you might not be able to investigate the attack.