By observing the log files [Ano99][Fri02], we can quickly get an idea of the global state of the system, as well as the latest events, and detect any irregular intrusions (or intrusion attempts). But it should also be remembered that, if there really has been an intrusion, the logs may have been cleaned or falsified. Most of the log files will be in the /var/log directory.
Many of the services may have their own logs, which are normally established during configuration (through the corresponding configuration file). Most of them usually use the log facilities incorporated in the Syslog through the Syslogd daemon. The configuration will be in /etc/syslog.conf. This configuration is usually established according to the message levels: there are different types of message according to their importance. Normally, levels such as debug, info, err, notice, warning, err, crit, alert, emerg, appear, in which the order of importance of the messages would be more or less as follows (from least to most important). Normally, most of the messages are sent to the /var/log/messages log, but the system can be set so that each message type goes to different files and it is also possible to identify who has created them; typically, the kernel, mail, news, the authentication system etc.
Consequently, it is appropriate to examine (or in any case adapt) the configuration of Syslog so as to determine the logs in which we can find / generate the information. Another important point is to control its growth, as, depending on which are active and the operations (and services) that are performed in the system, the logs can grow very quickly. In Debian and Fedora, this can be controlled through logrotated, a daemon that regularly makes copies and compresses the oldest logs; it is possible to find the general configuration in /etc/logrotate.conf, although some applications set specific configurations that can be found in the /etc/logrotate.d directory.
In the following points, we will discuss some of the log files that should be taken into account (perhaps the most frequently used):
a) /var/log/messages: is the default log file of the Syslogd daemon, but we would have to check its configuration, in case it has been moved to another place or there are several of them. This file contains a wide range of messages from various origins (different daemons, services or the same kernel); anything that looks irregular must be verified. If there has been an intrusion, the date of the intrusion and related files should be checked.
b) /var/log/utmp: this file contains binary information for each user that is currently active. It is useful to determine who is logged in the system. The who command uses this file to provide this information.
c) /var/log/wtmp: each time that a user logs in or out of the system, or the machine reboots, an entry is saved in this file. This is a binary file from which the last command obtains the information; the file records which users logged in or out of the system and when and where the connection was made. It can be useful for finding out where (in which accounts) the intrusion started and detect the use of suspicious accounts. There is also a variation in the command called lastb, which lists the login attempts that were not correctly validated and the /var/log/btmp file is used (you may have to create it if it doesn't exist). These same authentication faults can also be sent to log auth.log. In a similar manner, the lastlog command uses another file, /var/loglastlog, to verify which was the last connection of each of the users.
d) /var/log/secure: they are usually used in Fedora for sending the tcp wrapper messages (or firewalls). Each time that a connection is established to an inetd service, or, in the case of Red Hat 9, to the xinetd service (with its own security), a log message is added to this file. We can search for intrusion attempts in services that are not usually used or in unfamiliar machines that try to connect.
In the logs system, another thing that should be checked is that the directory logs in /var/log can only be writable by the root (or the daemons associated to the services). Otherwise, any attacker could falsify the information in the logs. Nevertheless, if attackers manage to access the root, they may often delete all their tracks.