Certification Objective 7.04-Understanding, Maintaining, and Monitoring System Logs

An important part of maintaining a secure system is keeping track of the activities that take place on the system. If you know what usually happens, such as understanding when users log into your system, you can use log files to spot unusual activity. Red Hat Enterprise Linux comes with several utilities you can use to monitor activity on a system. These utilities can help you identify the culprit if there is a problem.

RHEL comes with two logging daemons. The kernel log daemon service, klogd, logs kernel messages and events. The syslogd daemon logs all other process activity. You can use the log files that syslogd generates to track activities on your system. If you are managing multiple Red Hat Enterprise Linux systems, you can configure the syslogd daemon on each system to log messages to a central host system.

Both daemons are typically active by default, and both can be activated by the /etc/init.d/syslog script. Once these daemons start, the syslogd daemon examines /etc/syslog.conf to find the logging options that you may have configured.

On the Job 

The only available SELinux options associated with logging services disable protection; they're associated with the klogd_disable_trans and syslogd_disable_trans booleans.

System Log Configuration File

You can configure what syslogd records through the /etc/syslog.conf configuration file. As shown in Figure 7-15, it includes a set of rules for different facilities (if the corresponding packages are installed): authpriv, cron, kern, mail, news, user, and uucp. You may not see everything that's shown in Figure 7-15; for example, if you haven't installed the Internet News Network (INN) service, you won't see the associated directives in this file.

Figure 7-15: The syslog.conf log configuration file

Each facility is associated with several different levels of logging, known as the priority. In ascending order, log priorities are debug, info, notice, warn, err, crit, alert, emerg. There's also a generic none priority that logs all messages at all levels.

For each facility and priority, log information is sent to a specific log file. For example, consider the following line from /etc/syslog.conf:

 *.info;mail.none;news.none;authpriv.none;cron.none /var/log/messages 

This line sends log information from all of the given facilities to the /var/log/ messages file. This includes:

• All facility messages of info level and higher

• No log messages related to the mail, news, authpriv (authentication), and cron services

You can use the asterisk as a wildcard in /etc/syslog.conf. For example, a line that starts with *.* tells the syslogd daemon to log everything. A line that starts with auth.* means you want to log all messages from the authpriv service.

By default, syslogd logs all messages of a given priority or higher. In other words, a cron.err line will include all log messages from the cron daemon at the err, crit, alert, and emerg levels.

Most messages from the syslogd daemon are written to files in the /var/log directory. You should scan these logs on a regular basis and look for patterns that could indicate a security breach.

Managing Logs

Logs can easily become very large and difficult to read. By default, the logrotate utility creates a new log file on a weekly basis. You can also configure /etc/logrotate .conf to compress, mail, and remove desired log files. By default, the cron daemon runs logrotate on a regular basis, using the configuration files located in the /etc/ logrotate.d directory. As you can see in Figure 7-16, this process works fairly well; up to five weeks of logs are kept for a number of log facilities.

Figure 7-16: A typical set of log files in /var/log

Various log files and their functionality are described in Table 7-11. This is based on the previously described configuration of the /etc/syslog.conf file. All files shown are in the /var/log directory. If you haven't installed or activated the noted service, you may not see the associated log file. For the system depicted in Figure 7-16, I haven't bothered with the INN or PPP services, MySQL databases, or quagga routing messages. You may see a few other log files based on additional services you may have installed.

Table 7-11: Standard Red Hat Log Files

Log Files	Description
acpid	Specifies events related to the Advanced Control and Power Interface (ACPI) daemon; events indicate ACPI activity
anaconda.*	Three log files: anaconda.log for installation message; anaconda.syslog for the first dmesg, and anaconda.xlog for the first start of the GUI server; the anaconda.xlog file won't exist if you install in text mode
audit/	Includes the audit.log file, which collects messages from the kernel 2.6 audit subsystem
boot.log	Associated with services that start and shut down process
btmp	Lists failed login attempts; readable with the utmpdump btmp command
conman/	Directory of messages associated with the console management program
cron	Based on scripts run by the cron daemon
cups/	Directory of printer access, page, and error logs
dmesg	Basic boot messages
faillog	List of failed login attempts; readable with the faillog command
gdm/	Directory of messages associated with starting via the GNOME Display Manager; includes login failures
kdm	Messages associated with starting via the KDE Display Manger; includes login and server failures
httpd/	Directory of log files associated with the Apache Web server
lastlog	Lists login records; readable with the lastlog command
mail/	Directory with mail log statistics; readable with the mailstats command
maillog	Log messages related to the sendmail and postfix mail servers
messages	Messages from other services as defined in /etc/syslog.conf
ppp/	Directory with Point to Point Protocol statistics; usually associated with telephone modems
prelink.log	Log of prelinked libraries and binaries designed to speed the boot process
rpmpkgs	Current list of installed RPM packages
samba/	Directory of access and service logs for the Samba server
scrollkeeper.log	Log related to GNOME documentation
secure	Lists login and access messages
setroubleshoot	Includes messages associated with the SELinux troubleshooting tool
spooler	Print spool log
squid/	Directory of files related to Squid Proxy Server access, cache, and storage
wtmp	List of logins, in binary format; can be read with the utmpdump command
tallylog	Supports pam_tally, which locks out a user after excessive login attempts
up2date	Becoming obsolete; includes access messages associated with updates
vbox/	Directory of logs associated with ISDN utilities
Xorg.0.log	Setup messages for the X Window System; may include configuration problems
yum.log	Logs packages installed, updated, and erased with yum or associated front ends such as the Package Updater (Pup)

Exercise 7-3: Checking Logs

In this exercise, you'll inspect the log files on your computer to try to identify different problems.

1. Restart the Linux computer. Log in as the root user. Use the wrong password once. Log in properly as the root user.

2. In a console, navigate to the /var/log directory and open the file named secure. Navigate to the "FAILED LOGON" message closest to the end of the file. Close the secure file.

3. Review other logs in the /var/log directory. Use Table 7-11 for guidance. Look for messages associated with hardware. What log files are they in? Does that make sense?

4. Try some of the logs from the table which require command interpretation, such as faillog.