Detecting Intrusions from Log Files

Detecting Intrusions from 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 Red Hat Linux records important events is critical to this goal. The log files for your Red Hat Linux system can be found in the /var/log directory.

Red Hat Linux comes with a System Logs window (redhat-logview command) that you can use to view and search critical system log files from the GUI. To open the System Logs window, from the main desktop menu, click System Tools ? System Logs. Figure 14-3 shows an example of the System Logs window.

Click To expand
Figure 14-3: Display system log files in the System Logs window.

To view a particular log file, click the log name in the left column. If you are looking for a particular message or problem, type a keyword into the "Filter for" box, and click Filter. Only lines containing that word are displayed. Case matters, so searching for "Mem" won't find "mem" when you use the filter. Click Reset to display the whole file again.

Table 14-6 contains a listing of log files displayed on the System Logs window, along with other files in the /var/log directory that may interest you. (* Indicates a log file that is not contained in the System Logs window. Access these files directly from /var/log.)

Table 14-6: Log Files in the /var/log Directory

System Logs Name



Boot Log


Contains messages indicating which systems services have started and shut down successfully and which (if any) have failed to start or stop.

Cron Log


Contains status messages from the crond, a daemon that periodically runs scheduled jobs, such as backups and log file rotation.

Kernel Startup Log


A recording of messages printed by the kernel when the system boots.



Information about files transferred using the wu-ftpd FTP service.

Apache Access Log


Logs requests for information from your Apache Web server.

Apache Error Log


Logs errors encountered from clients trying to access data on your Apache Web server.

Mail Log


Contains information about addresses to which and from which e-mail was sent. Useful for detecting spamming.

MySQL Server Log


Includes information related to activities of the MySQL database server (mysqld).

News Log


Directory containing logs of messages from the Usenet News server, if you are running one.

RPM Packages


Contains a listing of RPM packages that are installed on your system.

Security Log


Records the date, time, and duration of login attempts and sessions.

System Log


A general-purpose log file to which many programs record messages.

Update Agent Log


Contains messages resulting from actions by the Red Hat Update Agent.

XFree86 Log


Includes messages output by the Xfree86 server.



Holds messages related to the login screen (GNOME display manager).



Messages from the Samba SMB file service daemon.



Contains messages related to the squid proxy/caching server.



Contains messages relating to transfers made using the vsFTPd daemon (FTP server).



Error messages recorded by the sendmail daemon.



Status messages from the Unix to Unix Copy Protocol daemon.

The role of syslogd

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, though 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 unlikely 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. Become root using the su command and then load 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
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 colons (spaces won't work). 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. 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 above 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 host name 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 only need to change the loghost alias; you do not need to reedit the syslog.conf file on every computer.

Understanding the messages logfile

Because of the many programs and services that record information to the messages logfile, it is important that you understand the format of this file. Examining this file will often give 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=  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 file snippet above. 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 (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.


The logsentry package provides a simpler way to manage your log files and not miss critical messages. Refer to "Monitoring Log Files with LogSentry" later in this chapter.

Part IV: Red Hat Linux Network and Server Setup