Syslog Configuration

Not all log messages are equally importantor even interesting. This is where /etc/sysiog.conf comes in. The configuration file /etc/sysiog.conf enables you to tailor the log output to meet your own needs.

Messages are categorized by the subsystem that produces them. In the man pages, these categories are called facilities (see Table 8.1).

Table 8.1. syslog Log Facility Categories


Table 8.1. syslog Log Facility Categories


auth or security



Private security/authorization


cron daemon messages


System daemon-generated messages


FTP server messages


Kernel messages


Printer subsystem


Mail subsystem


Network news subsystem


sysiogd-generated messages


User program-generated messages


UUCP subsystem

Within any given facility category, log messages are divided into priority types. The priorities, in increasing order of importance, are listed in Table 8.2.

Table 8.2. syslog Log Message Priorities


Table 8.2. syslog Log Message Priorities



Debug messages


Informational status messages


Normal but important conditions

warning or warn

Warning messages

err or error

Error message


Critical conditions


Immediate attention required

emerg or panic

System is unusable

An entry in syslog.conf specifies a logging facility, its priority, and where to write the messages. Not obvious is that the priority is inclusive. It's taken to mean all messages at that priority and higher. If you specify messages at the

Thisdocumentiscreated withtrial version of CHM2PDFPilot 2.15.72.e includedcrit, alert, and Logs can be written to devices, such as the console, as well as to files and remote machines.

TIPS ABOUT LOG FILES IN /var/log syslogd doesn't create files. It only writes to existing files. If a log file doesn't exist, you can create it with the touch command and then make sure that it is owned by root. For security purposes, log files are often not readable by general users. The security log file, /var/iog/secure, in particular, is readable by root alone.

These two entries write all kernel messages to both duplicated to multiple destinations:

the console and /var/log/_messages- Messages can be

/dev/console /var/log/messages

This entry writes panic messages to all default locations, terminal sessions:

*.emerg including /var/iog/messages, the console, and all user

The next two entries write authentication information related to root privilege and connections to /var/iog/secure, and user authorization information to /var/log/auth. With the priority defined at the info level, debug messages won't be written: /var/iog/secure /var/log/auth

The next two entries write general daemon information to /var/log/daemon, and mail traffic information to /var/log/maillog :

daemon.notice /var/log/daemon /var/log/maillog

Daemon messages at the debug and info priorities and mail messages at the debug priority are not logged (author's preference). named, crond, and systematic mail checking produce uninteresting informational messages on a regular basis.

The final entry logs all message categories of priority info or higher to /var/log/messages, with the exception of auth, authpriv, daemon, and maii. In this case, the latter four message facilities are set to none because their messages are directed to their own dedicated log files:

*.info;auth,authpriv,daemon,mail.none /var/log/messages


For a more complete description of syslog configuration options and sample configurations, see the man pages for syslog.conf(5) and sysklogd(8) .

syslogd can be configured to write the system logs to a remote machine. A site that uses a networked server configuration similar to the example in Chapter 6, "Packet Forwarding," with services offered from internal machines in the DMZ, might want to keep a remote copy of the system logs. Maintaining a remote copy offers two advantages: First, log files are consolidated on a single machine, making it easier for a system administrator to monitor the logs. Second, the information is protected if one of the server machines is ever compromised.

This dooirienUs created withtrial versionofCHM2PDFPilot 2.15.72.,ce that system logs play during recovery if a system is ever compromised. One of the first things an attacker does after successfully gaining root access to a compromised machine is to either erase the system logs or install trojan programs that won't log his activities. The system log files are either gone or untrustworthy at exactly the time you need them most. Maintaining a remote copy of the logs helps protect this information, at least until the hacker replaces the daemons writing the log file information.

To log system information remotely, both the local logging configuration and the remote logging configuration require slight modifications.

On the remote machine collecting the system logs, add the -r option to the syslogd invocation. The -r option tells syslogd to listen on the UDP syslog UDP port 514 for incoming log information from remote systems.

On the local machine producing the system logs, edit syslogd's configuration file, /etc/ syslog.conf, and add lines specifying what log facilities and priorities you want written to a remote host. For example, the following copies all log information to hostname:

*.* @hostname syslogd output is sent over UDP. Both the source and the destination ports are 514. The client firewall rule would be as follows:

iptables -A OUTPUT -o <out-interface> -p udp \ -s <this host> --sport 514 \ -d <log host> —dport 514 -j ACCEPT

Was this article helpful?

0 0

Post a comment