Remote Logging - Apache

In some cases, you’ll want to store your logs on a separate, secure server on your network dedicated to logging. This means that your server won’t be responsible for holding the logs, and if some crackers gain access to it, they won’t be able to delete their tracks (unless they crack the log server as well).

There are two ways of doing this. The first one is to instruct Apache to send all the log messages to the standard Unix log server, syslogd. The second solution is to build a custom-made logger script that sends the log entries to a remote server. You can implement this in several ways, and it might prove to be better for security and simplicity.

In the following sections I will explain how syslogd works, how to configure Apache and syslogd so that logs are stored on a remote log server, and how to store log files remotely without using syslogd and encrypting the log information.

Logging is a critical task. On a machine that acts as a server, there might be several daemons that log important messages continuously. Unix has logging facilities that make this completely transparent, and so Unix programs don’t have to worry about where or how their messages are logged, or know about all the problems concerning locking or integrity of log files. They can use the ready-to-use functions that abstract the whole logging mechanism using the syslogd logging daemon.

syslogd at Work

The syslogd daemon runs in the background and waits for new messages coming from either /dev/log (a UNIX domain socket) or the 514 UDP port. For security reasons, syslogd will not listen to the 514 UDP port by default. This means it will only work locally, and not by remote (otherwise, everyone on the Internet could log information on your server).

A log message is a line of text, but it has two important attributes: the facility (to specify the type of program that is logging the message), and the log level (which specifies how urgent the message is).

The facility can be (from man 3 syslog):

• LOG_AUTH: security/authorization messages (DEPRECATED Use LOG_AUTHPRIV instead)

• LOG_AUTHPRIV: security/authorization messages (private)

• LOG_CRON: clock daemon (cron and at)

• LOG_DAEMON: system daemons without separate facility value

• LOG_FTP: ftp daemon

• LOG_KERN: kernel messages

• LOG_LOCAL0 through LOG_LOCAL7: reserved for local use

• LOG_LPR: line printer subsystem

• LOG_MAIL: mail subsystem

• LOG_NEWS: USENET news subsystem

• LOG_SYSLOG: messages generated internally by syslogd

• LOG_USER (default): generic user-level messages
  
• LOG_UUCP: UUCP subsystem

    The log level can be (from man 3 syslog):

• LOG_EMERG: system is unusable

• LOG_ALERT: action must be taken immediately

• LOG_CRIT: critical conditions

• LOG_ERR: error conditions

• LOG_WARNING: warning conditions
  
• LOG_NOTICE: normal, but significant, condition

• LOG_INFO: informational message

• LOG_DEBUG: debug-level message

A program can use three standard library functions to log a message. They are:

void openlog(const char *ident, int option, int facility);
void syslog(int priority, const char *format, ...);
void closelog(void);

A program calls openlog() as soon as it is started; then, it uses syslog() to send log information to syslogd, and calls closelog() just before finishing its execution. The program sets the facility only once, with the facility parameter of the openlog() function, and then decides the importance level of each message, with the priority parameter in syslog(). The function syslog() uses the /dev/log UNIX socket to communicate with syslogd. You can see an example of this approach in Figure 3-1.

Figure 3-1. A diagrammatic representation of the logging process

You can see that Apache and other daemons don’t actually record the files, but talk to syslogd instead. It is syslogd’s responsibility to deal with the log requests.

Configuring syslogd

The syslogd daemon receives the logging requests issued by every running daemon on the system, regardless of the level of importance. Storing every log request onto a single file might lead to a huge and unmanageable log file, full of information of all kinds and levels of importance. Through /etc/syslog.conf you can decide:

• What messages to consider (facility and level)

• Where they should be stored

All the other log messages received by syslogd will be ignored. The syslog.conf file (usually found in the /etc directory) looks like this:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                    /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none   /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                 /var/log/secure

# Log all the mail messages in one place.
mail.*                                     /var/log/maillog

# Log cron stuff
cron.*                                     /var/log/cron

# Everybody gets emergency messages
*.emerg                                    *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                             /var/log/spooler

# Save boot messages also to boot.log
local7.*                                   /var/log/boot.log

Each line contains two fields separated by one or more tab characters. The first field, on the left hand side, contains the facility and the level. For example, news.crit means “facility: news, level: critical.” A star symbol (*) means “any.” The second field is the file where the log information will be stored. The following line means that cron messages of any importance are stored in /var/log/cron:

cron.*                                     /var/log/cron

Look at syslogd’s man page (man syslogd and man syslog.conf) for more detailed information on how to configure syslogd.