UNIX Computing Security/Log files and auditing

Suggested topics: syslog, lpd's log, mail log, install, Audit, and IDS.

Log files are generated by system processes to record activities for subsequent analysis. They can be useful tools for troubleshooting system problems and also to check for inappropriate activity. The UNIX releases are preconfigured to record certain information in log files, but configuration settings are available to increase the amount of information recorded.

Log files can be very useful resources for security incident investigations. They can also be essential for prosecution of criminal activity. For these reasons log files should be periodically backed up to separate media, and precautions need to be taken to prevent tampering with the log files. It is expected that an unauthorized intruder into a computing system will attempt to remove any trace of their activities from the system log files.

For log files that tend to grow significantly in size over the course of time, it can be good practice to periodically rotate the logs. That is to say, rename the current log file to a name in a sequence, and start a new log. Here is an example of rotating a log file called mylog:

 $ cd /var/adm
 $ test -f mylog.2 && mv -f mylog.2 mylog.3
 $ test -f mylog.1 && mv -f mylog.1 mylog.2
 $ test -f mylog.log && cp -p mylog mylog.1
 $ :>mylog

The effect of this is to rotate the log through three copies before it is finally overwritten. A script can be used to run this periodically, thus keeping the log file trimmed. (The log files should be backed up to media at some point.) Rotating the log files helps minimizes the disk space usage, thus avoiding a denial of service event due to a full file system.

Syslog

The system log is a log file that is maintained by the syslogd daemon. This log file can collect a variety of useful information, including panic conditions, data corruption, hardware errors, as well as warnings and tracking information. This log file can be written to from a shell or script by means of the logger command. Messages are sent to the syslogd daemon, which processes them according to a configuration defined by a special file (such as /etc/syslog.conf).

Events passed to the syslog are defined by a set of facilities and log levels. Combinations of facilities and log levels can be processed in different manners, or ignored altogether. For example, all error messages can be copied to the syslog.log file and e-mailed to the System Administrator, alerts can be printed to the console, mail debug messages can be added to a mail.log file, and so forth.

Certain services or daemons can be configured to log information to the syslogd file. These can include the inetd file, which on some systems can be configured to provide additional logging information. Among the types of information that can be logged is remote user login attempts and successes, including the client host from where the user is connecting. In some circumstances this can be useful for helping tracing the origin of an inappropriate or erroneous connection.

Some versions of syslogd can be configured to read log messages broadcast over the network. However it is possible to flood this socket with invalid messages, thus leading to a rapid growth of the log file and a potential denial of service. For this reason it is often a good idea to disable this network logging capability in the syslogd startup.

There are several options for maintaining a system log that is difficult if not impossible for an intruder to clean up. These can be configured by means of the /etc/syslog.conf file.

A printer can be dedicated to recording log messages on hard copy. The old line printers were especially useful for this purpose as the messages could be viewed immediately, rather than waiting for a page to fill.
The daemon can forward messages to a secure system on the network. If the server is compromised, the messages will still be stored safely on the remote host.
The log messages can be copied to a device that is configured for write-once, read-many operations. This could be a CD-ROM recording or a specially-configured tape drive.

The System Administrator should also be wary of misleading log messages. Users can add log entries using the logger command, and this can be employed as a prank or nuisance factor.

Other logs

There are other log files that can sometimes be useful in tracking accesses and activities.

The line printer daemon (lpd) is normally used to dispatch an output job to a printer. This can either print to a locally attached device, or forward the print jobs to a remote printer on a different server. The print jobs are recorded in a log file, usually giving the printer name, the account running the print job, and the date and time. This could potentially be useful in tracking access attempts.

The sendmail daemon can be used to send and receive electronic mail between UNIX systems using SMTP (Simple Mail Transfer Protocol). The daemon can be configured to log information about e-mail messages sent, received, and relayed. It can be used to troubleshoot e-mail issues as well as to look for unusual mail activity. The log messages are sent to the system via the syslogd, which is often configured to save mail-related messages to a dedicated log file.

Auditing

Auditing is normally a built-in capability that can be activated on a UNIX system. It is a requirement for C-2 trusted system security.

The audit system must be activated in order to begin collecting data. This data acquisition does come at a cost, as it can consume as much as 10% of the system CPU time. The data is stored in a file, which can then be analyzed using the available audit system commands.

The audit subsystem can collect data on events, system calls, and user activities. Auditing can collect a significant amount of data, which can then be examined for information about the system calls being run, the users calling the system commands, and the modifications made.

The particulars of the auditing configuration can vary depending on the particular flavor of the UNIX OS, so it is best for the System Administrator to review the manual pages on the subject. Usually there is an audit man page, which is a good place to start.

As the audit file can potentially grow without bounds, management of the file is necessary, usually on a daily basis. This can be done by rotating the log files and backing up the logs to separate media. The audit capability typically has a threshold setting that will cause the auditing to switch to an alternate log file under certain conditions. This audit file is often placed on a different file system in case the threshold switch is triggered by the original file system reaching a disk usage limit.

The audit logs should be regularly monitored to check for activity that needs to be tracked. Usually this can be achieved by means of a cron job that summarizes the log entries and looks for inappropriate events. In addition, regularly storing the audit event logs on separate media can be useful for the purposes of investigation of unauthorized access, &c.