HostedDB - Dedicated UNIX Servers

-->
Internet Security Professional Reference:Audit Trails
Previous Table of Contents Next


syslog

syslog is an extremely useful message-logging facility. Originally developed for BSD-based Unix as a companion to sendmail, it is now included with almost every Unix variant. syslog makes it easier for administrators to keep track of logs generated by a variety of programs by providing a central reference point for the destination of log entries.

To utilize syslog, a daemon called syslogd is executed at startup and runs in the background. This daemon listens for log messages from three sources:

  /dev/log. A Unix domain socket that receives messages generated by processes running on the local machine.
  /dev/klog. A device that receives messages from the Unix kernel.
  port 514. An Internet domain socket that receives syslog messages generated by other machines through UDP.

When syslogd receives a message from any of these sources, it checks its configuration file—syslog.conf—for the appropriate destination of the message. A message can go to multiple destinations, or it might be ignored, depending on the corresponding entries in the configuration file.

Entries in the syslog.conf file are comprised of two basic parts:

  Selector field. Tells syslog what kind of messages to log (see tables 4.1 and 4.2).
  {1}

Action field. Tells syslog what to do with the message it receives.

The selector field is comprised of a program that is sending the log message, often called the facility, and the severity level of the message. Table 4.1 shows syslog facilities.

Table 4.1
Syslog Facilities

Facility Name Originating Program

kern The kernel
user User processes
mail The mail system
auth Programs using security (login, su, and so forth)
lpr The line printer system
daemon System daemons
news The news system
uucp UUCP
cron The cron daemon
mark Regularly generated timestamps
local0-7 Locally generated messages
syslog Syslogd messages
authpriv Other authorization messages
ftp ftpd messages
* All facilities (except mark)

Table 4.2 shows syslog severity levels.

Table 4.2
syslog Severity Levels

Severity Level Meaning

emerg Emergency situations, such as system crashes potential
alert Urgent conditions that need correction immediately
crit Critical conditions
err Ordinary errors
warning Warning messages
notice Non-error related that might need special attention
info Informational messages
debug Messages used when debugging

The following text is an example syslog.conf file:

#
# syslog configuration file.
#
*.err;kern.debug;auth.notice;                   /dev/console
*.err;kern.debug;daemon.info;auth.notice;       /var/adm/messages
mail.crit;daemon.info;                          /var/adm/messages
lpr.debug                                       /var/adm/lpd-errs
*.alert;kern.err;daemon.err;                    operator
*.alert;                                        root
*.emerg;                                        *
auth.notice                                     @logginghost.com

In the above example, all emergency messages (*.emerg) go to all users on the system (*). All regular errors (*.err), kernel debugging messages (kern.debug), and authorization failures—such as illegal logins (auth.notice)—are reported to the system console as well as to the file /var/adm/messages. Authorization failures are also sent to a separate host (@logginghost.com) over the network, where they are picked up by that machine’s syslog program listening to port 514.

syslog passes most messages to the /var/adm/messages file. In most default configurations, nearly all messages are passed to this file.

sulog

The switch user command, su, records its usage through syslog. This information is stored in a file called sulog, in the /var/adm directory. Some intruders might use the su command to switch to usernames that have rlogin access to other hosts. This activity is reported in the sulog.

Many sites are now using the sudo command rather than su. By using sudo, properly authorized users can execute commands as another user without having to actually log in with the password of that user (as they would using su). sudo also logs its usage through the syslog facility. sudo logs the command executed, the username of the requester, the time the command was executed, and the directory from which the command was invoked.

A log entry of an authorized user, fred, using sudo to edit the /etc/group file would look something like the following:

Apr 2 06:45:22 hostname sudo: fred: PWD=/usr/fred; COMMAND=/bin/vi /etc/group

aculog

When a user utilizes dial-out facilities, such as tip or cu, a log entry is made to a file called aculog. This file is most often stored as /var/adm/aculog. This log contains a record of the user name, time and date, phone number dialed, and completion status of the call. UUCP-related commands also record their information in the aculog file.

A typical aculog entry looks like the following:

uucp:daemon (Mon Apr 3 12:31:03 1995) <host, 5551212, usr> call completed

Checking aculog entries would be valuable if an intruder were using the Unix host as a conduit, when dialing out to other systems, as a means of avoiding long-distance charges, or avoiding a direct telephone trace.

cron

The cron utility maintains records of the utilities that are executed by cron. Usually this record is maintained in the file /var/log/cron, but because cron versions now make use of syslog, the messages could be stored in a variety of files.

If intruders can manipulate the crontab file or programs or scripts named in that file, they might be able to use the cron utility to gain higher privileges. Logs generated by cron offer clues to such improper usage.


Previous Table of Contents Next