Apache Security - Ivan Ristic [112]
Performing log postprocessing is difficult (for security, or billing purposes) when you do not have logging information in a single file.
To overcome these problems, the second school of thought regarding configuration was formed. The idea is to have only two files for all virtual hosts and to split the logs (creating one file per virtual host) once a day. Log post-processing can be performed just before the splitting. This is where the vcombined access log format comes into play. The first field on the log line, the hostname, is used to determine to which virtual host the entry belongs. But the problem is the format of the error log is fixed; Apache does not allow its format to be customized, and we have no way of knowing to which host an entry belongs.
One way to overcome this problem is to patch Apache to put a hostname at the beginning of every error log entry. One such patch is available for download from the Glue Logic web site (http://www.gluelogic.com/code/apache/). Apache 2 offers facilities to third-party modules to get access to the error log so I have written a custom module, mod_globalerror, to achieve the same functionality. (Download it from http://www.apachesecurity.net/.)
Remote Logging
Logging to the local filesystem on the same server is fine when it is the only server you have. Things get complicated as the number of servers rises. You may find yourself in one or more of the following situations:
You have more than one server and want to have all your logs at one place.
You have a cluster of web servers and must have your logs at one place.
You want to increase system security by storing the logs safely to prevent intruders from erasing them.
You want to have all event data centralized as part of a holistic system security approach.
The solution is usually to introduce a central logging host to the system, but there is no single ideal solution. I cover several approaches in the following sections.
Manual Centralization
The most natural way to centralize logs is to copy them across the network using the tools we already have, typically FTP, Secure File Transfer Program (SFTP), part of the Secure Shell package, or Secure Copy (SCP), also part of the SSH package. All three can be automated. As a bonus, SFTP and SCP are secure and allow us to transfer the logs safely across network boundaries.
This approach is nice, secure (assuming you do not use FTP), and simple to configure. Just add the transfer script to cron, allowing enough time for logs to be rotated. The drawback of this approach is that it needs manual configuration and maintenance and will not work if you want the logs placed on the central server in real time.
Syslog Logging
Logging via syslog is the default approach for most system administrators. The syslog protocol (see RFC 3164 at http://www.ietf.org/rfc/rfc3164.txt) is simple and has two basic purposes:
Within a single host, messages are transmitted from applications to the syslog daemon via a domain socket.
Between network hosts, syslog uses UDP as the transfer protocol.
Since all Unix systems come with syslog preinstalled, it is fairly easy to start using it for logging. A free utility, NTsyslog (http://ntsyslog.sourceforge.net), is available to enable logging from Windows machines.
The most common path a message will take starts with the application, through the local daemon, and across the network to the central logging host. Nothing prevents applications from sending UDP packets across the network directly, but it is often convenient to funnel everything to the localhost and decide what to do with log entries there, at a single location.
Apache supports syslog logging directly only for the error log. If the special keyword syslog is specified, all error messages will go to the syslog:
ErrorLog syslog:facility
The facility is an optional parameter, but you are likely to want to use it. Every syslog message consists of three parts: priority, facility, and the message. Priority can have one of the following eight values: