Unix and Linux Systems


Although Unix was originally developed to be a programmer's operating system and not a business production system, it has been enhanced over the years to include utilities that can track resource usage and access. Today, the various implementations of Unix (along with its cousin Linux) are the primary operating systems used on the Internet for most firewalls and Web servers in the high-end market.

The files discussed here might vary from one Unix/Linux system to the next , but in general most systems have these available for the system administrator's use. The syslog utility covers the widest area of system resources because you can configure it to record messages from many different system utilities, and you can also decide how the utility will notify you of events as they happen.

Other files ”such as /etc/utmp and /usr/adm/wtmp ”keep track of who is currently logged on to the system and who has logged on to the system in the past. This is an example of Unix and Linux storing files in different locations. For Linux, the files would be /var/run/utmp and /var/log/wtmp .

Understanding each utility or log file and the type of information you can derive from it will enable you to set up a good auditing policy for your systems.

Using syslog

The syslog utility can be used to set up logging for many components that make up the Unix operating system. You can set up message logging so that messages from a wide variety of programs can be managed from a central location. To enable syslog logging, you must edit the /etc/syslog.conf configuration file and enter a record that contains a selector for each type of message you want to be logged by the facility, as well as an action, which is the action the daemon should take for this type of message.

The syslog daemon ( syslogd ) is usually started when the system boots, by commands placed in one of the rc startup files. This is the syntax for starting the daemon:

 /etc/syslog [-mN] [-f  filename  ] [-d] 

The -f option can be used to specify a configuration file other than the standard /etc/syslog.conf file. The -m option sets a "mark" interval for placing timestamps into the file. Timestamps can be important because they indicate that the logging mechanism is working during periods when no other significant events are logged. The absence of timestamps (if you use them) can be a tip that someone has been tampering with your system. The -d option turns on debugging mode.

The syslog.conf File

The syslog.conf file stores the information that the syslog daemon uses to decide which messages to accept (source and severity) and what to do with them (log file, notify user , and so on). You can use any ASCII text editor (such as VI) to configure this file. Each line should be composed of two components:

  • The selector ” This part of the record is composed of two pieces of information separated by a period. The first part of the selector is the name of the system component (or facility ) from which the message originates. The second part of the selector is the severity (or priority ) of the message. You can place multiple selectors on one line if you separate them with a semicolon.

  • The action ” This tells the daemon what to do when it receives a message that matches the selector criteria.

Table 47.1 lists the facility names you can use when composing the selector portion of the record.

Table 47.1. Facility Names in the syslog.conf Configuration File

Source Name

Description

user

Generated by user applications

kern

Kernel messages

mail

Mail system messages

daemon

System daemons

auth

Authorization file (that is, login)

lpr

Line printer spooler system

news

Usenet

uucp

UUCP (not currently implemented)

cron

cron and at utilities

local0-7

Reserved for local use

mark

Timestamp messages

*

All the preceding except for mark

Table 47.2 lists the severity levels you can use as the second component for the selector.

Table 47.2. Severity Levels in the syslog.conf File

Severity Level

Description

panic

Panic condition that is usually broadcast to all users

emerg

Same as panic

alert

A condition that needs immediate attention

crit

Warnings about critical situations

err

Other errors not warranting emerg , alert , or crit

error

Same as err

warn

Warning messages

warning

Same as warn

notice

Situations that require attention, but not as important as a warning or another error; not necessarily an error condition

info

Informational messages

debug

Messages generated by programs running a debug mode

none

Suppresses messages for this entry

Note that another severity level, called panic , has been removed in later versions of Unix/Linux ”it's the same functionality provided by emerg . At this time the error and warn severity levels are also considered to be deprecated, which means that although they work now, they will be removed in future versions.

To create a selector, select one of the facilities listed in Table 47.1 and combine it with one of the error conditions listed in Table 47.2. For example:

 kernel.info mail.notice lpr.crit 

To create the rest of the record, you need to specify an action to take. The action portion of the record is separated from the selector portion by a space character. The syslog daemon can deliver the message in these ways:

  • Write the message to a log file

  • Send it to another computer

  • Send it to one or more usernames

  • All the above

For example, because kernel events are usually important (the kernel is the heart of the Unix operating system) and need to be looked at immediately, you might want to send them to the computer's console device. To do this, use the following entry:

 kern.* /dev/console 

The asterisk tells syslog to log all message types generated by the kernel, and the /dev/console part of the record specifies the console device (check the documentation to be sure of the exact device filename).

If the message is something important, but not so critical that it needs immediate attention, you can send it to a user whose responsibilities are associated with the application. The following example sends all messages from the mail facility (at a severity level of info or above) to the mail administrator named Johnson:

 mail.info johnson 

For security reasons, you might want to send important logging messages to another host. This can be a valuable service that the syslog daemon can perform. For example, when you are using bastion hosts in a demilitarized zone (DMZ), it's best not to store security logging events on a host computer that might be compromised. Instead, you instruct the daemon to send these events to another server for logging purposes. In a large network, you can dedicate a single host computer to this function and use other security measures to make the computer inaccessible to ordinary users. To send messages relating to kernel events and authorization events to another computer, for example, you might use this:

 kern.*;auth.* @yoko.ono.com 

You'll find more detailed information about bastion hosts, firewalls, and DMZs in Chapter 49, "Firewalls."


Some message types are more useful for reviewing at a later date to review the overall functioning of the system. Using log files for these kinds of messages is a good idea. To send messages to a log file, specify the log file path in the action field:

 mail.info;lpr.info;news.* /var/adm/messages 

Tip

When sending messages to a log file, you can send them all to the same file as shown in the preceding example ( /var/adm/messages ). However, to make administering the logged messages easier, you might want to create several log files and group similar message types together. This way you don't have to search through a large file that might contain a large number of entries to find just a few records of interest. Using separate log files makes it easier to write script files to automate the process of searching for important messages.

Another good reason to use multiple log files is that you can delegate the reviewing of these log files to those employees who are best qualified to review them. A typical Unix system administrator has a lot of things to do during a normal working day. Delegating the review of certain events to subordinates can make the day a much more pleasant experience!

When sending syslog messages to a file, don't forget to review the log files periodically. Depending on the severity level you set for each facility, these files can grow to be quite large over a short period. To make administration more efficient, decide on a policy for reviewing, archiving, and deleting log files on a regular basis. You should keep these files available for at least a year. Some intrusions can lie in wait for a trigger before causing your system a problem. If you keep your log files on tape or other offline storage, you can look back through them for what might not have seemed an obvious event when it originally occurred. For legal reasons, keeping log files archived and readily available can help you make your case against an intruder who has spent days, weeks, or months trying to compromise your system.

System Log Files

Unix systems have many log files not related to the syslog utility that you can review for security purposes. For example, user logins are recorded in a file, as are usages of the switch user ( su ) command. When you are new to a system, you should review the documentation to make sure you are aware of all the logging facilities on the computer, where the files are located, and what maintenance procedures are necessary.

Some of the more useful files are listed here:

  • /usr/adm/wtmp ” This file keeps track of all logins, showing the username, terminal, and connect time. System shutdowns (but not system crashes, of course) are also listed in this file. Use the last command or the ac command to view entries in this log file.

  • /etc/utmp ” This file is similar to the /usr/adm/wtmp file, in that it stores information about users logging in to the system. However, this file only shows information about users that are actually logged on to the system currently and is not a historical file.

  • /var/adm/sulog ” This important log file should be looked at often because it records the usage of the su (switch user) command.

  • /var/adm/ aculog ” This file records the usage of dial-out utilities, such as tip or cu .

  • /var/log/cron ” Actions taken by the cron scheduling utility are recorded here. This utility schedules events for execution on the system. By reviewing this file, you can determine whether unauthorized users are running procedures.

  • /var/adm/lpd-errs ” This file is used to record messages having to do with the lpr / lpd spooling system. Although not really of great concern from a security point of view, it can be a potential tool to use when looking for security breaches, such as determining who printed what.

  • /var/adm/acct ” This is the process accounting file. Use the sa command or the lastcomm command to view the contents of this file.



Upgrading and Repairing Networks
Upgrading and Repairing Networks (5th Edition)
ISBN: 078973530X
EAN: 2147483647
Year: 2003
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net