New Document
Unix - system log

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
Syslog Facilities:

Here are the available facilities for the selector. Not all facilities are present on all versions of UNIX.

FacilityDescription
authActivity related to requesting name and password (getty, su, login)
authprivSame as auth but logged to a file that can only be read by selected users
consoleUsed to capture messages that would generally be directed to the system console
cronMessages from the cron system scheduler
daemonSystem daemon catch-all
ftpMessages relating to the ftp daemon
kernKernel messages
local0.local7Local facilities defined per site
lprMessages from the line printing system
mailMessages relating to the mail system
markPseudo event used to generate timestamps in log files
newsMessages relating to network news protocol (nntp)
ntpMessages relating to network time protocol
userRegular user processes
uucpUUCP subsystem

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.

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.

Logging Actions:

The action field specifies one of five actions:

  1. Log message to a file or a device. For example, /var/log/lpr.log or /dev/console.

  2. Send a message to a user. You can specify multiple usernames by separating them with commas (e.g., root, amrood).

  3. Send a message to all users. In this case, the action field consists of an asterisk (e.g., *).

  4. Pipe the message to a program. In this case, the program is specified after the UNIX pipe symbol (|).

  5. Send the message to the syslog on another host. In this case, the action field consists of a hostname, preceded by an at sign (e.g., @tutorialspoint.com)

The logger Command:

UNIX provides the logger command, which is an extremely useful command to deal with system logging. The logger command sends logging messages to the syslogd daemon, and consequently provokes system logging.

This means we can check from the command line at any time the syslogd daemon and its configuration. The logger command provides a method for adding one-line entries to the system log file from the command line.

The format of the command is:

logger [-i] [-f file] [-p priority] [-t tag] [message]...
What about the SU Log as part of your list.

Unix systems have a very flexible and powerful logging system, which enables you to record almost anything you can imagine and then manipulate the logs to retrieve the information you require.

Many versions of UNIX provide a general-purpose logging facility called syslog. Individual programs that need to have information logged send the information to syslog.

Unix syslog is a host-configurable, uniform system logging facility. The system uses a centralized system logging process that runs the program /etc/syslogd or /etc/syslog.

The operation of the system logger is quite straightforward. Programs send their log entries to syslogd, which consults the configuration file /etc/syslogd.conf or /etc/syslog and, when a match is found, writes the log message to the desired log file.

There are four basic syslog terms that you should understand:
TermDescription
FacilityThe identifier used to describe the application or process that submitted the log message. Examples are mail, kernel, and ftp.
PriorityAn indicator of the importance of the message. Levels are defined within syslog as guidelines, from debugging information to critical events.
SelectorA combination of one or more facilities and levels. When an incoming event matches a selector, an action is performed.
ActionWhat happens to an incoming message that matches a selector. Actions can write the message to a log file, echo the message to a console or other device, write the message to a logged in user, or send the message along to another syslog server.
Syslog Priorities:

The syslog priorities are summarized in the following table:

PriorityDescription
emergEmergency condition, such as an imminent system crash, usually broadcast to all users
alertCondition that should be corrected immediately, such as a corrupted system database
critCritical condition, such as a hardware error
errOrdinary error
warningWarning
noticeCondition that is not an error, but possibly should be handled in a special way
infoInformational message
debugMessages that are used when debugging programs
nonePseudo level used to specify not to log messages.

The combination of facilities and levels enables you to be discerning about what is logged and where that information goes.

As each program sends its messages dutifully to the system logger, the logger makes decisions on what to keep track of and what to discard based on the levels defined in the selector.

When you specify a level, the system will keep track of everything at that level and higher.

The /etc/syslog.conf file:

The /etc/syslog.conf file controls where messages are logged. A typical syslog.conf file might look like this:

*.err;kern.debug;auth.notice /dev/console
daemon,auth.notice           /var/log/messages
lpr.info                     /var/log/lpr.log
mail.*                       /var/log/mail.log
ftp.*                        /var/log/ftp.log
auth.*                       @prep.ai.mit.edu
auth.*                       root,amrood
netinfo.err                  /var/log/netinfo.log
install.*                    /var/log/install.log
*.emerg                      *
*.alert                      |program_name
mark.*                       /dev/console

Each line of the file contains two parts:

  • A message selector that specifies which kind of messages to log. For example, all error messages or all debugging messages from the kernel.

  • An action field that says what should be done with the message. For example, put it in a file or send the message to a user's terminal.

Following are the notable points for the above configuration:

  • Message selectors have two parts: a facility and a priority. For example, kern.debug selects all debug messages (the priority) generated by the kernel (the facility).

  • Message selectetor kern.debug selects all priorities that are greater than debug.

  • An asterisk in place of either the facility or the priority indicates "all." For example, *.debug means all debug messages, while kern.* means all messages generated by the kernel.

  • You can also use commas to specify multiple facilities. Two or more selectors can be grouped together by using a semicolon.

Previous                                                                                                                                                       Next

Back to Top