SANS Digital Forensics and Incident Response Blog

Unix Logging

There are a wide variety of logging functions and services on UNIX. Some of these, such as the Solaris audit facility, are limited to a particular variety of UNIX. It is important that the digital forensics analyst become familiar with the logging deployed on the UNIX system that they are reviewing. In particular, have a look at the syslog configuration file, the "/var/log" and "/var/run" directories and check if there are any remote log servers. Syslog is a network service that is most commonly run locally. This allows for the capability of sharing logs to a remote system.

Syslog and Other Standard Logs

There are five primary log files that will exist on nearly any UNIX system (the location may vary slightly). These have been listed in the table below.

The 5 primary Unix Log files

  • /var/log/btmp btmp contains the failed login history
  • /var/log/messages is the default location for messages from the syslog facility
  • /var/log/secure is the default log for access and authentication
  • /var/run/utmp utmp contains summary of currently logged on users
  • /var/log/wtmp wtmp details the history of logins and logouts on the system

The bad logon attempt file ("/var/log/btmp") is a semi-permanent log (such as wtmp) that tracks failed login attempts. This file is a binary format and is read using the "lastb" command. In many systems the btmp file will not be created by default. If this file does not exist the system will not log to it. Any review of a UNIX system should validate the existence of this file and ensure that it is functioning correctly. One way to validate that this file is working correctly is to attempt to log into the system using a set of invalid credentials. If the log is working correctly, an entry should be recorded noting the analyst's failed attempt. It is important that this file is restricted so only root can access or change it. General users have no reason to see failed attempts and should never change or delete this file.

The messages log ("/var/log/messages") or at times also the default syslog (on some systems this file will be named "/var/log/syslog") contains by default the sum of the system messages. Depending on the consideration of the syslog configuration file (commonly "/etc/syslog.conf"), this may contain failed drivers, debug information and many other messages associated with the running of a UNIX system.

In the "secure" log ("/var/log/secure") is designed to record this security and authentication events that occur on the system. By default, applications such as TCPwrappers will log to this file. In addition, the PAM system and "login" facilities will write to this file on most UNIX systems.

The utmp file ("/var/run/utmp") contains a point in time view of the users that logged on to the system. This file is used by a number of applications and utilities (such as the "finger" and "who" commands). This file is volatile in that it will not survive a system boot. Further, when the user logs out of the system their entry is removed. This file does not contain historical data. It is possible to gain a snapshot of user information at a point in time through this file. This information includes the username, terminal identifier, the time that the user logged in to the system and also where they logged in from (which may be a local TTY or remote network host). Many rootkits will change the contents of this file in an attempt to hide themselves.

The wtmp file ("/var/log/wtmp") is a binary file similar to "utmp". This file is also utilized by applications such as "finger", "last" and "who" and contains much of the same information as "utmp". The primary difference however is that it is more permanent in nature. This file provides a formal audit trail of user access and will also record system boots and other events. This file is commonly used when investigating an incident. The "last" command uses this file to display a list of accesses to the system. It will display a historic list as well as listing any user who was still logged onto the system. Like many other UNIX logging facilities it must be activated.

Most UNIX systems (and any that are configured correctly) will rotate logs periodically. This may be done through an automated facility such as "cron" or through some other application. It is important to both verify and validate how the log files are being rotated, whether they are being stored in an offline facility, are they being backed up and lastly that they are maintained online for an adequate period of time. Regulatory standards such as PCI-DSS version 1.1 require that system logs are not only maintained, but are accessible online for a minimum period of time (in this case 90 days). The analyst should ensure that all log files meet the minimum requirements for storage. In addition, always consider long-term data retention needs and the capability to restore logs after an extended period of time. Such log recovery may require that hardware and software associated with the previous system are maintained for a fair number of years (in the case of financial systems this could be a period of six years following the decommissioning of the system).

System Accounting and Process Accounting

Accounting reports created by the system accounting present the UNIX administrator with the information to assess current resource assignments, set resource limits and quotas, and predict future resource requirements. This information is also valuable to the analyst.

When system accounting has been unable on a UNIX system, the collection of statistical data will begin when the system starts or a least from the moment that the accounting service is initiated. The standard data collected by system accounting will include the following categories:

  • Connect session statistics
  • Disk space utilization
  • Printer use
  • Process use

The accounting system process starts with the collection of statistical data from which summary reports can be created. These reports can assist in system performance analysis and offer the criteria necessary to establish an impartial customer charge back billing system or many other functions related to the monitoring of the system. A number of the individual categories of statistics collected have been listed in the sections that follow.

Connect Session Statistics

Connect session statistics allow an organization to bill, track or charge access based on the tangible connect time. Connect-session accounting data, associated with user login and logout, is composed by the init and login commands. When a user logs into the UNIX system, the login program makes an entry in the "wtmp" file. This file will contain the following user information:

  • Date of login/logout
  • Time of login/logout
  • Terminal port
  • User name

This data may be utilized in the production of reports containing information valuable to both the analyst and system administrator. Some of the information that can be extracted includes:

  • Connect time seconds used,
  • Date and starting time of connect session,
  • Device address of connect session,
  • Login name,
  • Number of prime connect time seconds used,
  • Number of nonprime connect time seconds used,
  • Number of seconds elapsed from Jan 01st 1970 to the connect-session start time,
  • Process Usage,
  • User ID (UID) associated with the connect-session.

It is also possible to gather statistics about individual processes using system accounting. Some areas that may be collected include:

  • Elapsed time and processor time consumed by the process,
  • First eight characters of the name of the command,
  • I/O (Input/output) statistics,
  • Memory usage,
  • Number of characters transferred,
  • Number of disk blocks read or written by the process ,
  • User and group numbers under which the process runs.

Many UNIX systems maintain statistical information in a "pacct" or process account database or accounting file. This database is commonly found in the "/var/adm/pacct" file, but like many UNIX log files, this will vary from system to system. The accounting file used by many of the system and process accounting commands. When a process terminates, the kernel writes information explicit to the particular process into the "pacct" file. This file consists of the following information:

  • Command used to start the process
  • Process execution time
  • Process owner's user ID

When system accounting is installed and running on a UNIX system, commands to display, report, and summarize process information will be available. Commands such as "ckpacct" can be used by the administrator or analyst to ensure that the process accounting file ("pacct") remains under a set size and thus is stopped from either growing too large or possibly impacting system performance in other ways.

Craig Wright is a Director with Information Defense in Australia. He holds both the GSE-Malware and GSE-Compliance certifications from GIAC and completed the GSE as well. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial lawand ecommerce law, A Masters Degree in mathematical statistics from Newcastle as well as working on his 4th IT focused Masters degree (Masters in System Development) from Charles Stuart University where he lectures subjects in a Masters degree in digital forensics. He is writing his second doctorate, a PhD on the quantification of information system risk at CSU.

4 Comments

Posted March 10, 2010 at 9:54 PM | Permalink | Reply

craigswright

I should have also mentioned that syslog has a newer counterpart on many machines, ''rsyslog'.
This is similar to syslog, but can run over TCP and has many additional enhancements. It is basically enhanced syslog and syslog can talk with rsyslog without issue.
One can forget to explicitly make the differentiation when doing this day to day. See the site, http://www.rsyslog.com/ for more info.

Posted May 5, 2010 at 8:23 PM | Permalink | Reply

Josh

Craig,
How would you go about tracking the commands that are run by users on your UNIX box?
Thanks,
Josh

Posted May 7, 2010 at 2:08 AM | Permalink | Reply

Craig S Wright

Hi Josh,
It really depends on a number of issues ''" such as disk space, CPU, memory etc. Ideally, system accounting can be configured to log all commands ''" user and kernel and send these to a remote server. This is the ideal (and most expensive in therms of system use etc). This allows one to discover the development of a rootkit and work back completely removing it when found.
On the other hand, the lastcomm command is simple and if available oin your system easy to start.
Lastcomm will print out information about previously executed commands that are recorded in the acct.
Having come from a Solaris start in life, lastcomm was fairly standard. The use is of the form (sans flags):
lastcomm [ Command ] [ Name ] [ Terminal ]
E.g. #lastcomm root
acctcms (if installed) provides command use summaries.
Rehhat/Centos, install accounting as:
#yum install psacct
Debian:
# apt-get install acct
The accounting processes can be started (Centos/Redhat etc) by the following commands:
# chkconfig psacct on
# /etc/init.d/psacct start
You can call use of a command, e.g.
# lastcomm touch
touch root pts/0 0.00 secs Fri May 7 12:03
or a user:
[root@csw ~]# lastcomm root
vmnet-natd F root __ 0.00 secs Fri May 7 12:04
pdflush F root __ 0.00 secs Fri May 7 12:04
pdflush F root __ 0.00 secs Fri May 7 12:03
psacct root pts/0 0.00 secs Fri May 7 12:03
touch root pts/0 0.00 secs Fri May 7 12:03
As a last resort, the bash history and other history files may also help (esp. of acct is not running). The ''"
~/.bash_history
file will store commands, but this can be altered.
Craig

Posted March 28, 2011 at 6:02 PM | Permalink | Reply

Jay

What about the SU Log as part of your list.