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

Fedora comes with a System Logs window (system-logviewer 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, select System Tools ® System Logs. Figure 14-2

Figure 14-2:   Display system log files in the System Logs window.

shows an example of 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-3 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. (An asterisk indicates a log file that is not contained in the System Logs window. Access these files directly from /var/log.)

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

System Logs Name	Filename	Description
Boot Log	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	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 that are 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.
*	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.

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. If you are not already root, become root 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      #  # 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. 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 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=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.

The logsentry package presented in the following section provides a simpler way to manage your log files and not miss critical messages.