To start with, build a machine with a standard operating system, secured as much as possible. Start with a clean operating system and follow the procedures we describe in this section:
Start with a minimal clean operating system installation.
Fix all known system bugs.
Use a checklist.
Safeguard the system logs.
Start with a clean operating system installation, straight from vendor distribution media. If you do this, you will know exactly what you're working with. You won't need to retrofit something that may already have problems. Using such a system will also make later work easier. Most vendor security patches you later obtain, as well as the vendor configuration instructions and other documentation, assume that you're starting from an unmodified installation.
While you're installing the operating system, install as little as you can get away with. It's much easier to avoid installing items than it is to delete them completely later on. For that matter, once your operating system is minimally functional, it's not hard to add components if you discover you need them. Don't install any optional subsystems unless you know you will need them.
If you are reusing a machine that has already had an operating system installed on it, be sure to erase all data from the disks before doing the reinstall. Otherwise, you cannot guarantee that all traces of the old system are gone.
Get a list of known security patches and advisories for your operating system; work through them to determine which are relevant for your own particular system, and correct all of the problems described in the patches and advisories. You can get this information from your vendor sales or technical support contacts, or from the user groups, newsgroups, or electronic mailing lists devoted to your particular platform.
In addition, be sure to get from the Computer Emergency Response Team Coordination Center (CERT-CC) any advisories relevant to your platform, and work through them. (For information on how to contact CERT-CC and retrieve its information, see the list of resources in Appendix A.)
Many operating systems have both recommended and optional patches or have periodic patch sets (called service packs for Windows NT) with individual patches issued in between (Microsoft calls these hot fixes). You should install the current recommended patch set, plus all other security-related patches that are relevant to your installation.
To be sure you don't overlook anything in securing your bastion host, use a security checklist. Several excellent checklists are around. Be sure to use one that corresponds to your own platform and operating system version.
As a security-critical host, the bastion host requires considerable logging. The next step in building the bastion host is to make sure that you have a way of safeguarding the system logs for the bastion host. The system logs on the bastion host are important for two reasons:
They're one of the best methods of determining if your bastion host is performing as it should be. If everything the bastion host does is logged (and it should be), you should be able to examine the logs to determine exactly what it's doing and decide if that's what it's supposed to be doing. Chapter 26, describes the use of system logs in maintaining your firewall.
When (not if!) someday someone does successfully break in to the bastion host, the system logs are one of the primary mechanisms that determine exactly what happened. By examining the logs and figuring out what went wrong, you should be able to keep such a break-in from happening again.
Where should you put the system logs? On the one hand, you want the system logs to be somewhere convenient; you want them to be where they can be easily examined to determine what the bastion host is doing. On the other hand, you want the system logs to be somewhere safe; this will keep them from any possible tampering in case you need to use them to reconstruct an incident.
The solution to these seemingly contradictory requirements is to keep two copies of the system logs — one for convenience, the other for catastrophes. The details of the logging services are operating-system dependent and are discussed in the chapters on individual operating systems.
The first copy of the system logs is the one you'll use on a regular basis to monitor the ongoing activity of the machine. These are the logs against which you run your daily and weekly automated analysis reports. You can keep these logs either on the bastion host itself or on some internal host.
The advantage of keeping them on the bastion host is simplicity: you don't have to set up logging to go to some other system, nor do you have to configure the packet filters to allow this. The advantage to keeping them on an internal host is ease of access: you don't have to go to the bastion host, which doesn't have any tools anyway, to examine the logs. Avoid logging in to the bastion host, in any case.
The second copy of the system logs is the one you'll use after a catastrophe. You can't use your convenience logs at a time like this. Either the convenience logs won't be available, or you won't be sure of their integrity any longer.
These logs need to be kept separate from the bastion host and kept for a long time. Sometimes you will discover an intruder a long time after the original compromise (among other things, it's not unusual for an intruder to break into a bunch of machines and install back doors for later use; a compromised machine may be left alone for months).
If you have a write-once device available to you, use that device; doing so is probably the technically easiest way to keep the logs, especially if your write-once device can emulate a filesystem. 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.
The other methods available to you will differ depending on the operating system you are using and are discussed in Chapter 11, and Chapter 12.
Knowing the time (within minutes and sometimes seconds) when something occurred can be very useful when dealing with break-ins. You will need date and time information if you (or law enforcement agencies) need to request information from other sites. You should make sure that your bastion hosts have accurate and synchronized times in their logs. See Chapter 22, for more information about time synchronization protocols.
Choosing the information you want to log is a delicate business. You don't want gigantic logs full of routine events; that just wastes space and time and makes it harder to find important information. On the other hand, you do want logs that are general enough that you can debug problems and figure out what intruders did.
What you would like to do is to log everything except events that are frequent and nonthreatening. Don't try to limit your logging to dangerous or interesting events because it's hard to successfully predict which those are going to be. Instead, log everything you can stand, eliminating only the known clutter.
For instance, Windows NT provides the ability to log all accesses to files. You don't want to turn this on for all files on a bastion host; you'll drown in routine accesses to files that are accessed as it provides services. On the other hand, you probably do want to log all accesses to system files that aren't accessed by the services. These files shouldn't be touched often, and the nuisance caused by the log entries when you do maintenance work will be compensated for by the number of attacks you can detect.