Securing Unix (Building Internet Firewalls, 2nd Edition)

11.2. Securing Unix

Once you have chosen a machine, you need to make sure that it has a reasonably secure operating system installation. The first steps in this process are the same as for any other operating system and were discussed in Chapter 10, "Bastion Hosts". They are:

Start with a minimal clean operating system installation. Install the operating system from scratch onto empty disks, selecting only the subsystems you need.
Fix known bugs. Consult CERT-CC, your vendor, and any other sources of security information you may have to make certain that you have all appropriate patches, and only the appropriate patches, installed.
Use a checklist to configure the system. Practical UNIX & Internet Security, by Simson Garfinkel and Gene Spafford (O'Reilly & Associates, 1996), contains an extensive checklist that covers most Unix platforms. More specific checklists for particular operating system releases are often available through the formal or informal support channels for those platforms; check with your vendor support contacts, or the user groups, newsgroups, or mailing lists that are devoted to the platform.

11.2.1. Setting Up System Logs on Unix

On a Unix system, logging is handled through syslog. The syslog daemon records log messages from various local and remote clients (programs with messages they want logged). Each message is tagged with facility and priority codes: the facility code tells syslog what general subsystem this message is from (for example, the mail system, the kernel, the printing system, the Usenet news system, etc.), and the priority code tells syslog how important the message is (ranging from debugging information and routine informational messages through several levels up to emergency information). The /etc/syslog.conf file controls what syslog does with messages, based on their facility and priority. A given message might be ignored, logged to one or more files, forwarded to the syslog daemon on another system, flashed onto the screens of certain or all users who are currently logged in, or any combination.

When you configure syslog to record messages to files, you could configure it to send all messages to a single file, or to split messages up to multiple files by facility and priority codes. If you split messages by facility and priority codes, each log file will be more coherent, but you'll have to monitor multiple files. If you direct everything to a single file, on the other hand, you'll have only a single file to check for all messages, but that file will be much larger.

any non-Unix systems, particularly network devices such as routers, can be configured to log messages via syslog. If your systems have that capability, configuring them so they all log to your bastion host provides a convenient way to collect all their messages in a single place.

Be aware that remote logging via syslog (e.g., from a router to your bastion host, or from your bastion host to some internal host) is not 100 percent reliable. For one thing, syslog is a UDP-based service, and the sender of a UDP packet has no way of knowing whether or not the receiver got the packet unless the receiver tells the sender (syslog daemons don't confirm receipt to their senders). Some syslog variants can be made to remotely log using TCP. Unfortunately, you still cannot absolutely depend on them not to lose messages; what if the receiving system was down or otherwise unavailable? One solution is to have a local method to reliably capture all syslog messages. (See Section 11.2.1.2, "System logs for catastrophe", later in this chapter.)

syslog will accept messages from anywhere and does no checking on the data that it receives. This means that attackers can use syslog for denial of service attacks or can hide important syslog messages in a blizzard of fake ones. Some syslog daemons can be configured not to accept messages over the network. If this option is available to you, you should use it on all systems except those that you intend to use as log servers.

Despite its weaknesses, though, syslog is a useful service; you should make extensive use of it.

11.2.1.1. syslog Linux example

Most versions of syslog are derived from the original BSD version. Example 11-1 is taken from Linux, which includes some enhancements. It allows wildcards for either the facility or the priority and also allows a facility to be ignored by using the syntax facility.none. One peculiar feature of almost all syslog daemons is that they require the use of the Tab character to delimit fields. The use of spaces can cause a syslog line to be silently ignored.

Example 11-1. Linux syslog.conf Example

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none 	/var/log/messages

# The authpriv file has restricted access.
authpriv.*	 /var/log/secure

# Log all the mail messages in one place.
mail.debug 	 /var/log/maillog

# Everybody gets emergency messages, plus log them on another
# machine.
*.emerg 	*
*.emerg 	 @logger.greatcircle.com

11.2.1.2. System logs for catastrophe

One of the simplest ways to create catastrophe logs is to attach a line printer to one of the bastion host's serial ports, and simply log a copy of everything to that port. There are some problems with this approach, though. First, you have to keep the printer full of paper, unjammed, and with a fresh ribbon. Second, once the logs are printed, you can't do much with them except look at them. Because they aren't in electronic form, you have no way to search or analyze them in an automated fashion.

If you have a write-once device available to you, direct logs to that device; that will give you reasonably trustworthy logs in an electronic form. Be sure you can trust the write-once feature. Some magneto-optical drives are capable of both multiple-write and write-once operations, and keep track of the mode they're in via software. If the system is compromised, it may be possible to overwrite or damage previously written parts of the supposedly write-once media.

Some operating systems (notably BSD 4.4-Lite and systems derived from it, such as current releases of BSDI, FreeBSD, and NetBSD) support append-only files. These are not an advisable alternative to write-once media. Even if you can trust the implementation of append-only files, the disk that they're on is itself writable, and there may be ways to access it outside of the filesystem, particularly for an intruder who wants to destroy the logs.