Checking Log Files

Preparing your system for a cracker attack is only part of the battle. You must also recognize a cracker attack when it is occurring. Understanding the various log files in which Fedora and RHEL record important events is critical to this goal. The log files for your Fedora or RHEL system can be found in the /var/log directory.

Because the system logs are plain text files, you can view the contents of logs directly using any text editor or paging command (such as less or more ). However, RHEL also contains a System Logs window for viewing and searching log files. The logwatch facility (which comes with RHEL) sends daily highlights from your log files in an e-mail message to the root user . You can also add packages, such as logsentry, to monitor your log files. (A description of logsentry is contained on the Wiley Web site for this book at www.wiley.com/go/fedora6bible. )

Using the System Log Window

RHEL comes with a System Log window ( system-logviewer command) that you can use to view and search critical system log files from the GUI. In the most recent release, Fedora replaced system-logviewer with gnome-system-log as the System Log window. To open the System Log window from the Fedora desktop, select System Administration System Log.

The System Log window in Fedora offers some improvements over the previous version. First, you can choose which logs to view (select Log Open, and choose from log files in /var/log or other locations). Then, from the selected log file, messages are sorted by date. You can click on the calendar or a date line in the panel to select which date of messages to view. The example in Figure 14-3 shows messages from the /var/log/messages file for the selected date.

Figure 14-3: Display system log file messages by date in the System Log window.

Table 14-2 contains log files you can choose to display in the System Log window.

Table 14-2: Log Files in the /var/log Directory
Open table as spreadsheet

System Logs Name	Filename	Description
Boot Log	boot.log	Contains messages indicating which system services have started and shut down successfully and which (if any) have failed to start or stop.
Cron Log	cron	Contains status messages from the crond , a daemon that periodically runs scheduled jobs, such as backups and log file rotation.
Kernel Startup Log	dmesg	A recording of messages printed by the kernel when the system boots.
Apache Access Log	httpd/access_log	Logs requests for information from your Apache Web server.
Apache Error Log	httpd/error_log	Logs errors encountered from clients trying to access data on your Apache Web server.
Mail Log	maillog	Contains information about addresses to which and from which e-mail was sent. Useful for detecting spamming .
MySQL Server Log	mysqld.log	Includes information related to activities of the MySQL database server (mysqld).
News Log	spooler	Directory containing logs of messages from the Usenet News server, if you are running one.
RPM Packages	rpmpkgs	Contains a listing of RPM packages installed on your system.
Security Log	secure	Records the date, time, and duration of login attempts and sessions.
System Log	messages	A general-purpose log file to which many programs record messages.
Update Agent Log	up2date	Contains messages resulting from actions by the Red Hat Update Agent.
X.Org X11 Log	Xorg.0.log	Includes messages output by the X.Org X server.
*	acpid	Logs events that occur with the Advanced Configuration and Power Interface daemon ( acpid ).
*	xferlog	Contains information about files transferred using the vsFTPd FTP service.
*	gdm/:0.log	Holds messages related to the login screen (GNOME display manager).
*	samba/log.smbd	Shows messages from the Samba SMB file service daemon.
*	squid/access.log	Contains messages related to the squid proxy/caching server.
*	vsftpd.log	Contains messages relating to transfers made using the vsFTPd daemon (FTP server).
*	sendmail	Shows error messages recorded by the sendmail daemon.
*	uucp	Shows status messages from the Unix to Unix Copy Protocol daemon ( uucico ).

Understanding the Syslogd Service

Most of the files in the /var/log directory are maintained by the syslogd service. The syslogd daemon is the System Logging Daemon. It accepts log messages from a variety of other programs and writes them to the appropriate log files. This is better than having every program write directly to its own log file because it allows you to centrally manage how log files are handled. It is possible to configure syslogd to record varying levels of detail in the log files. It can be told to ignore all but the most critical message, or it can record every detail.

The syslogd daemon can even accept messages from other computers on your network. This is particularly handy because it enables you to centralize the management and reviewing of the log files from many systems on your network. There is also a major security benefit to this practice. If a system on your network is broken into, the cracker cannot delete or modify the log files because those files are stored on a separate computer.

It is important to remember, though, that those log messages are not, by default, encrypted. Anyone tapping into your local network will be able to eavesdrop on those messages as they pass from one machine to another. Also, although the cracker may not be able to change old log messages, he will be able to affect the system such that any new log messages should not be trusted.

It is not uncommon to run a dedicated loghost , a computer that serves no other purpose than to record log messages from other computers on the network. Because this system runs no other services, it is less likely that it will be broken into. This makes it nearly impossible for a cracker to erase his or her tracks. It does not, however, mean that all of the log messages are accurate after a cracker has broken into a machine on your network.

Redirecting Logs to a Loghost with Syslogd

To redirect your computer's log files to another computer's syslogd, you must make some changes to your local syslogd's configuration file. The file that you need to work with is /etc/syslog.conf . If you are not already root, become root and then open the /etc/syslog.conf file in a text editor (such as vi ). You should see something similar to this:

 # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *. info ;mail.none;news.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log # # INN # news.=crit /var/log/news/news.crit news.=err /var/log/news/news.err news.notice /var/log/news/news.notice 

The lines beginning with a # character are comments. Other lines contain two columns of information, separated by spaces or tabs. The left field is a semicolon-separated list of message types and message priorities. The right field is the log file to which those messages should be written.

Note 

Notice the dash (-) before the /var/log/maillog file. Normally, each log file is synced after every logging. A dash preceding the full path to the log file indicates that the file is not synced after each logging. While this might result in lost information if your machine crashes before the log is written, it can result in better performance on your system if you run verbose logging.

To send the messages to another computer (the loghost) instead of a file, simply replace the log file name with the @ character followed by the name of the loghost. For example, to redirect the output normally sent to the messages, secure , and maillog log files, make these changes to the previous file:

 # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;news.none;authpriv.none;cron.none @loghost # The authpriv file has restricted access. authpriv.* @loghost # Log all the mail messages in one place. mail.* @loghost 

The messages will now be sent to the syslogd running on the computer named loghost. The name loghost was not an arbitrary choice. It is customary to create such a hostname and make it an alias to the actual system acting as the loghost. That way, if you ever need to switch the loghost duties to a different machine, you need to change only the loghost alias; you do not need to re-edit the syslog.conf file on every computer.

Understanding the Messages Logfile

Because of the many programs and services that record information to the messages log file, it is important that you understand the format of this file. Examining this file often gives you a good early warning of problems developing on your system. Each line in the file is a single message recorded by some program or service. Here is a snippet of an actual messages log file:

 Feb 25 11:04:32 toys network: Bringing up loopback interface: succeeded Feb 25 11:04:35 toys network: Bringing up interface eth0: succeeded Feb 25 13:01:14 toys vsftpd(pam_unix)[10565]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=10.0.0.5 user=chris Feb 25 14:44:24 toys su(pam_unix)[11439]: session opened for user root by chris(uid=500) 

This is really very simple when you know what to look for. Each message is divided into five main parts . From left to right they are:

• The date and time that the message was logged

• The name of the computer that the message came from

• The program or service name that the message pertains to

• The process number ( enclosed in square brackets) of the program sending the message

• The actual text message itself

Let's examine the previous file snippet. In the first two lines, you can see that I restarted the network. The next line shows that I tried to log in as the user named chris to get to the FTP server on this system from a computer at address 10.0.0.5 (I typed the wrong password and authentication failed). The last line shows that I used the su command to become root user.

By occasionally reviewing the messages file and the secure file, it is possible to catch a cracking attempt before it is successful. If you see an excessive number of connection attempts for a particular service, especially if they are coming from systems on the Internet, you may be under attack.

Tracking Log Messages with Logwatch

Another way to keep up with the contents of your log files is with the logwatch facility. Logwatch flags messages that might reflect a problem with your system and forwards them each day in an e-mail message to your system's root user. When you install Fedora or RHEL, the logwatch package is installed and configured to watch your log files and report suspicious activities to your system administrator. Based on the logwatch cron file ( /etc/cron.daily/0logwatch ), the logwatch facility will:

• Run each morning at 4:00 a.m.

• Choose which log files to scan and where to send the e-mail message, based on the configuration file /etc/logwatch/conf/logwatch.conf . (The defaults are listed in /usr/share/logwatch/default.conf .)

• Send an e-mail message to the local computer's root user that reports potentially suspicious activity on your system, based on the contents of your log files.

• Report on administrative activities that could reflect a problem with the system.

The kind of information logwatch reports on includes users and groups that have been deleted, packages installed or uninstalled , and disk space consumed. The daily messages also show login activity through ssh over the network and file transfer activities. Failure messages are flagged and reported for each log file scanned.

Review the /usr/share/logwatch/default.conf/logwatch.conf file to see the options you have for configuring your logwatch service. To change any options, you can add them to the /etc/logwatch/conf/logwatch.conf file. Here are examples of some logwatch settings:

 LogDir = /var/log TmpDir = /var/cache/logwatch MailTo = root Print = No Range = yesterday Detail = Low mailer = /bin/mail Service = All 

LogDir sets the log file directory as /var/log (so any log files listed are shown as relative to that directory). The /var/cache/logwatch directory is used to hold temporary files. The daily e-mail report is sent to the root user on the local system (you can change MailTo to any valid e-mail address). You can change the Print value to Yes to have the report sent to standard output, instead of being mailed to the MailTo recipient.

The Range is set to yesterday, which causes logwatch to search log files for the past day only. You can change the Range to All to search all past files available for a particular log file, as in messages, messages.1, messages.2 , and so on. To increase the amount of detail (which is set to Low by default), you can identify Detail as Medium or High (or a number from 0 to 10). The mail application used to send the report is /bin/mail .

Most of the action that takes place by logwatch is based on the value of the Service entry. With Service set to All , all files in the /usr/share/logwatch/conf/services directory are used to produce the logwatch report. Files in this directory are each related to a service that is checked by logwatch and defines the type of information that is gathered for that service.