Each line in syslogd.conf 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.
To log all cron messages (any level) to /var/log/cron:
Look at syslogd’s man page (man syslogd and man syslog.conf) for more detailed information on how to configure syslogd.
The syslogd daemon can be configured so that it doesn’t store the received log messages in a local file, but sends them to another syslogd daemon running on another host (obviously) listening to the 514 UDP port. Adding a line in the syslog.conf file can do this:
To test syslogd:
logger -p local0.crit "Hello readers..."
ErrorLog syslog:local0 CustomLog "|/usr/bin/logger -p local1.info" common
Of course, if you want a remote host to actually store the messages, you have to change the file syslogd.conf to:
local0.* @remote_log_server.yout_net.com local1.info @remote_log_server
The server @remote_log_server should preferably be on your own network, and should be configured to store messages from facility local7 on a local file. Remember that the syslogd daemon on the server remote_log_server must be started with the -r option.
There is no syslog option for the access_log directive. The reason behind this is that sending access log information to the syslog daemon isn’t something that many users would do, because syslogd is quite slow. If you get 10 requests a second, you might miss something important.
If your system doesn’t have a logger program, you should be able to find its equivalent quite easily.
It is best to log all the access log messages with an info log level, so they are all of equal importance (unlike the log entries in Apache’s error log).
There are several disadvantages to remote logging using syslog:
- It is unreliable. A log line could simply get lost on the way to the log server. There is no acknowledgment of any sort by the remote logging server regarding the information being written. An attacker could cause a denial of service on the remote logger by flooding it, or feeding it bad data
- Centralizing logging to one server means that the log server represents a single point of failure.
- It is simple to create fake log entries. syslog’s protocol is based on UDP, and it is extremely simple to send a forged or spoofed UDP packet, because UDP is connectionless. You need to firewall the network carefully, and even then, a cracker might be able to create misleading log entries.
- It’s based on clear text. This means that the information can be forged on its way to the log server, because there is no reliable mechanism for checking that the packet that arrived is the same as the packet that was sent.
Here are alternatives that help to solve some of the shortcomings:
syslog-ng (http://www.balabit.hu/en/downloads/syslog-ng/) This is a replacement for the standard syslog daemon. syslog-ng (the ng means next generation) can be configured to support digital signatures and encryption, to make sure that log messages weren’t modified. It can also filter log messages according to their content, and log messages using TCP rather than UDP (TCP is a connection-oriented protocol and is much harder to spoof ). Additionally, it can run in a jailed environment (see Chapter 6 for detailed information on how to run Apache in a “jail” using chroot()).
nsyslogd (http://coombs.anu.edu.au/~avalon/nsyslog.html) This is another replacement of the syslog daemon, with some interesting features, including the use of TCP instead of UDP, and the ability to encrypt connections to prevent data tampering using OpenSSL. Unfortunately, while it is a feasible solution for several Unix systems, it doesn’t work well on Linux at the time of this writing.
socklog (http://smarden.org/socklog/) This is yet another replacement of the syslog daemon. The main strength of socklog is that it’s based on daemontools (http://cr.yp.to/daemontools.html). daemontools’ architecture makes it possible to have encryption, authentication, compression, and log rotation quite easily. It’s definitely worth looking into.
The e-mail available at http://cert.uni-stuttgart.de/archive/honeypots/2002/07/msg00100.html includes tips on how to hide a remote log server.
Remote Logging without syslogd:
CustomLog "|/usr/bin/custom_logging_program" common ErrorLog "|/usr/bin/custom_logging_program"
The program custom_logging_program could be a program that reads the log messages from its standard input, and sends them to a remote server via a TCP connection. The remote log server would be a program written specifically to talk to custom_logging_program. This way, all the problems connected with syslogd could be solved, and you would be absolutely sure that the system works the way you want it to work. There is only one problem: designing a functional client/server application like this can be very complicated. At the beginning of this chapter, I mentioned that logging programs should be kept as simple as possible. A program like this would be anything but simple; it would need to use cryptography, and would need to communicate with the server following all the rules set by the (newly designed) protocol. Writing the logging server program would be even harder.
To cause message to be forwarded to another host, replace the normal line in syslog.conf with the name of the host to which the message is to be sent, prepended with @:
*.* @hostname kern.* @hostname