Unix provides a smorgasbord of logs. We’ll cover the merits of each in Chapter 13. Here, we will explain how to expand the default logging capabilities so that you’ll have plenty of data to review in the event of an incident.
Controlling System Logging Syslog, short for system logging, is the heart and soul of Unix log files. Any program can generate syslog messages, which are sent to the syslogd pro- gram. The syslogd program then stores the messages to any or all of several configurable locations. Syslogd is controlled through the configuration file /etc/syslog.conf. Syslog.conf consists of two fields: selector and action. The selector field contains the facil- ity (where the message is generated from) and the priority (the severity of the message). The action field controls where the message is logged.
To ensure that your syslog messages are useful and present, configure syslogd as follows:
▼ Log all auth messages (which generally are security-related messages) with a priority of info or higher to the /var/log/syslog or /var/log/messages file.
auth.info /var/log/syslog
Chapter 3: Preparing for Incident Response
39
The utilities used to record baseline information must be trusted to work as adver- tised. A common trick of an intruder is to substitute a trojaned utility for the origi- nal. An intruder may replace the MD5 utility with a version that does not display the correct checksums. If a trojaned MD5 utility is used when recording the system baseline information, the system baseline information could be inaccurate. You need to ensure that you use known-good copies of system utilities when recording system baseline information.
The system baseline information also must be stored securely in order to be use- ful. Storing the baseline information on the local hard drive is a bad idea! Once the system is compromised, the intruder could modify or delete the baseline informa- tion. The baseline information should be stored offline in a secure environment. Ideally, this means saving the information to media such as CD-ROMs and locking the CDs in a safe-deposit box.
▲ Since disk space is cheap and logs are priceless, we recommend that you log everything. In the event of an incident, seemingly inconsequential system messages may be surprisingly relevant. To log all messages to a file, replace the selector and action fields with the wildcard*:
*.* /var/log/syslog
Now all relative data is being saved on the system.
Setting Up Remote Logging If an attacker logs in to a Unix server as root using the Secure Shell service and a guessed password, the attacker’s login information, including source address, will be saved in the syslog or messages file. However, the attacker could delete or modify the /var/log/syslog or messages file, erasing this important evidence. To avoid this problem, set up secure remote logging. This is one of the more important steps of pre-incident preparation. Remote logging is configured through two steps.
First, create a central syslog server that accepts incoming syslog messages. This is a system whose only purpose is to receive syslog messages via the User Datagram Protocol (UDP) on port 514. To configure this system, you must run syslogd with the–roption, which enables “receiving” syslog messages from the network. (Syslogd is generally run through thercstartup scripts.)
Next, configure other servers to log their messages to this syslog server. You can con- figure this behavior by modifying the action field in the syslog.conf file as follows:
auth.* @10.10.10.1
10.10.10.1 is the IP address of the remote syslog server. Assuming the syslog server can- not be compromised, you have now secured the syslog messages. In the event of a com- promise, the syslog messages will still be valid. (An attacker could add false messages but could not delete or modify existing messages.)
Enabling Process Accounting One of the lesser-known logging capabilities of Unix is pro- cess accounting. Process accounting tracks the commands that each user executes. The log file is usually found in the /var/adm, /var/log, or /usr/adm directory, and it is called either pacct or acct. The file itself is not human-readable. It must be viewed with thelastcommoracctcommcommand. For some Unix flavors, such as Red Hat Linux, the process accounting package may not be included as part of the default installation, so you will need to install it in order to use process accounting.
To enable process accounting on your system, use the accton command or the startup command (usually/usr/lib/acct/startup). While the benefits of this command are extraordinary to the investigator, they are not always reliable in the event of a compromise, because the intruder can delete or modify the log file. The good news is that there are no publicly available hacker tools (that we know of) that are designed to modify process accounting logs. So, it is an all-or-none situation for any attacker who
desires to remove evidence from the process accounting logs—he either deletes the whole log or leaves it intact.
We recommend enabling process accounting, especially after an attack occurs. It can pro- vide great insights to an intruder’s actions when network monitoring proves ineffective.