Apache Security - Ivan Ristic [113]
ErrorLog syslog:local4
We then configure syslog to single out Apache messages (that is, those with facility local4) and send them to the central logging host. You need to add the following lines at the bottom of /etc/syslog.conf (assuming the central logging host occupies the address 192.168.0.99):
# Send web server error messages to the central host
local4.*: 192.168.0.99
At the remote server, the following addition to /etc/syslog.conf makes local4 log entries go into a single file:
local4.*: /var/www/logs/access_log
* * *
Tip
Most syslog daemons are not allowed to receive remote messages by default. The option -r should be specified on the syslogd command line to open the port 514, which is the port typically used to receive remote syslog messages.
* * *
To send access log entries to syslog, you must use piped logging. One way of doing this is through the logger utility (normally available on every Unix system):
CustomLog "|/usr/bin/logger -p local5.info" combined
I have used the -p switch to assign the priority and the facility to the syslog messages. I have also used a different facility (local5) for the access log to allow syslog to differentiate the access log messages from the error log messages. If more flexibility is needed, send the logs to a simple Perl script that processes them and optionally sends them to syslog. You can write your own script using the skeleton code given in this chapter, or you can download, from this book's web site, the one I have written.
Not everyone uses syslog, because the syslog transport protocol has three drawbacks:
The transport method is unreliable
Syslog uses UDP, and UDP packets are easy to send across the network, but the sending host cannot determine if the packet was received. Therefore, a loss of information is possible. The loss may be small on a local network of good quality but potentially significant otherwise.
Messages are transmitted in cleartext
Logs usually carry sensitive data, so transporting them in plaintext (that is, unencrypted) can be unacceptable.
There is no support for authentication
Simply said, syslog messages are very easy to fake. Anyone who can send a UDP packet to port 514 on the logging host can create a fake message.
On top of all this, the default daemon (syslogd) is inadequate for anything but the simplest configurations. It supports few transport modes and practically no filtering options.
Attempts have been made to improve the protocol (RFC 3195, for example) but adoption of such improvements has been slow. It seems that most administrators who decide on syslog logging choose to resolve the problems listed above by using Syslog-NG (http://www.balabit.com/products/syslog_ng/) and Stunnel (http://www.stunnel.org). Syslog-NG introduces reliable logging via TCP, which is nonstandard but does the job when Syslog-NG is used on all servers. Adding Stunnel on top of that solves the authentication and confidentiality problems. The combination of these two programs is the recommended solution for automated, reliable, and highly secure logging.
Chapter 12 of Linux Server Security by Michael D. Bauer, which covers system log management and monitoring and includes detailed coverage of Syslog-NG, is available for free download from O'Reilly (http://www.oreilly.com/catalog/linuxss2/ch12.pdf).
Database Logging
Remember how I said that some developers do not believe the web server should be wasting its time with logging? Well,