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.

image from book
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.

image from book
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



Specifies events related to the Advanced Control and Power Interface (ACPI) daemon; events indicate ACPI activity


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


Includes the audit.log file, which collects messages from the kernel 2.6 audit subsystem


Associated with services that start and shut down process


Lists failed login attempts; readable with the utmpdump btmp command


Directory of messages associated with the console management program


Based on scripts run by the cron daemon


Directory of printer access, page, and error logs


Basic boot messages


List of failed login attempts; readable with the faillog command


Directory of messages associated with starting via the GNOME Display Manager; includes login failures


Messages associated with starting via the KDE Display Manger; includes login and server failures


Directory of log files associated with the Apache Web server


Lists login records; readable with the lastlog command


Directory with mail log statistics; readable with the mailstats command


Log messages related to the sendmail and postfix mail servers


Messages from other services as defined in /etc/syslog.conf


Directory with Point to Point Protocol statistics; usually associated with telephone modems


Log of prelinked libraries and binaries designed to speed the boot process


Current list of installed RPM packages


Directory of access and service logs for the Samba server


Log related to GNOME documentation


Lists login and access messages


Includes messages associated with the SELinux troubleshooting tool


Print spool log


Directory of files related to Squid Proxy Server access, cache, and storage


List of logins, in binary format; can be read with the utmpdump command


Supports pam_tally, which locks out a user after excessive login attempts


Becoming obsolete; includes access messages associated with updates


Directory of logs associated with ISDN utilities


Setup messages for the X Window System; may include configuration problems


Logs packages installed, updated, and erased with yum or associated front ends such as the Package Updater (Pup)

Exercise 7-3: Checking Logs

image from book

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.

image from book

RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302)
Linux Patch Management: Keeping Linux Systems Up To Date
ISBN: 0132366754
EAN: 2147483647
Year: 2004
Pages: 227
Authors: Michael Jang

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net