5.3.1 What Operating System?

The bastion host should be something you're familiar with. You're going to end up customizing the machine and the operating system extensively; this is not the time to learn your way around a completely new system. Because a fully configured bastion host is a very restricted environment, you'll want to be able to do development for it on another machine, and it helps a great deal to be able to exchange its peripherals with other machines you own. (This is partly a hardware issue, but it doesn't do you any good to be able to plug your UNIX-formatted SCSI disk into a Macintosh SCSI chain: the hardware interoperates, but the data isn't readable.)

You need a machine that reliably offers the range of Internet services you wish to provide your users, with multiple connections simultaneously active. If your site is completely made up of MS-DOS, Windows, or Macintosh systems, you may find yourself needing some other platform (perhaps UNIX, perhaps Windows NT, perhaps something else) to use as your bastion host. You may not be able to provide or access all the services you desire through your native platform, because the relevant tools (proxy servers, packet filtering systems, or even regular servers for basic services such as SMTP and DNS) may not be available for that platform.

UNIX is the operating system that has been most popular in offering Internet services, and tools are widely available to make bastion hosts on UNIX systems. If you already have UNIX machines, you should seriously consider UNIX for your bastion host. If you have no suitable platforms for a bastion host and need to learn a new operating system anyway, we recommend you try UNIX, because that's where you'll find the largest and most extensive set of tools for building bastion hosts.

If all of your existing multiuser, IP-capable machines are something other than UNIX machines (such as VMS systems, for example), you have a hard decision to make. You can probably use a machine you are familiar with as a bastion host and get the advantages of familiarity and interchangeability. On the other hand, solid and extensive tools for building bastion hosts are not likely to be available to you, and you're going to have to improvise. You might gain some security through obscurity (don't count on it; your operating system probably isn't as obscure as you think), but you may lose as much or more if you don't have the history that UNIX-based bastion hosts offer. With UNIX, you have the advantage of learning through other people's mistakes as well as your own.

Most of this chapter assumes that you will be using some kind of UNIX machine as your bastion host; this chapter is more UNIX-centric than any other part of this book. This is because most bastion hosts are UNIX machines, and some of the details are extremely operating system dependent. The principles will be the same if you choose to use another operating system, but the details will vary considerably.

If you have a UNIX machine, which version of UNIX should you choose? Again, you want to balance what you're familiar with against which tools are available for which versions. If your site already uses one version of UNIX, you will most likely use that version. If your site has some familiarity with several versions of UNIX, and the relevant tools (discussed throughout this chapter) are available for all of them, use the least popular one that you still like. Doing so maximizes your happiness and minimizes the likelihood that attackers have precompiled ways of attacking your bastion host. If you have no UNIX familiarity, choose any version you like, provided that it is in reasonably widespread use (you don't want "Joe's UNIX, special today $9.95"). As a rule of thumb, if your chosen version of UNIX has a user's group associated with it, it's probably well-known enough to rely on.

Although UNIX vendors differ vastly in their openness about security issues, the difference in the actual security between different versions of UNIX is much smaller. Don't assume that the publicity given to security holes reflects the number of security holes; it's a more accurate reflection of the popularity of the operating system and the willingness of a vendor to admit and fix security problems. Ironically, the operating systems with the most worrisome tales may be the most secure ones, because they're the ones getting fixed.

5.3.2 How Fast a Machine?

The bastion host doesn't have to be a fast machine; in fact, it's better not being especially powerful. There are several good reasons, besides cost, to make your bastion host as powerful as it needs to be to do its job, but no more so. It doesn't take much horsepower to provide the services required of the bastion host.

Many people use machines in the 2- to 5-MIPS range (for example, Sun-3, MicroVAX II, or 80386-based UNIX platforms) as their bastion hosts. This is plenty of power for an average site. The bastion host really doesn't have much work to do. What it needs to do is mostly limited by the speed of your connection to the outside world, not by the CPU speed of the bastion host itself. It just doesn't take that much of a processor to handle mail, DNS, FTP, and proxy services for a 56 Kb/s or even a T-1 (1.544 Mb/s) line. You may need more power if you are running programs that do compression/decompression (e.g., NNTP servers) or searches (e.g., full-featured WWW servers), or if you're providing proxy services for dozens of users simultaneously.

You may also need more power to support requests from the Internet if your site becomes wildly popular (e.g., if you create something that everybody and their mothers want to access, like The Great American Web Page or a popular and well-stocked anonymous FTP site).[1] At that point, you might also want to start using multiple bastion hosts, as we describe in Chapter 4. A large company with multiple Internet connections and popular services may need to use multiple bastion hosts and large, powerful machines. (Fortunately, most companies in that position are also computer manufacturers and buy computers wholesale.)

[1] If you find yourself (or want to find yourself) in such a position, see Managing Internet Information Services by Cricket Liu, et al (O'Reilly & Associates, 1994). This book contains lots of helpful information and advice.

There are several reasons not to oversize the bastion host:

• A slower machine is a less inviting target. There's no prestige for somebody who brags, "Hey, I broke into a Sun 3/60!" or some other slow (to an attacker, at least) machine. There is far more prestige involved in breaking into the latest, greatest hardware. Don't make your bastion host something with high prestige value (a Cray, for example, would be a poor choice of a bastion host...).

• If compromised, a slower machine is less useful for attacking internal systems or other sites. It takes longer to compile code; it's not very helpful for running dictionary or brute-force password attacks against other machines; and so on. All of these factors make the machine less appealing to potential attackers, and that's your goal.

• A slower machine is less attractive for insiders to compromise. A fast machine that's spending most of its time waiting for a slow network connection is effectively wasted, and the pressure from your own users to use the extra power for other things (for example, as a compilation server, rendering server, or database server) can be considerable. You can't maintain the security of a bastion host while using it for other purposes. Extra capacity on the bastion host is an accident waiting to happen.

5.3.3 What Hardware Configuration?

You want a reliable hardware configuration, so you should select a base machine and peripherals that aren't the newest thing on the market. (There's a reason people call it the "bleeding edge" as well as the "leading edge.") You also want the configuration to be supportable, so don't choose something so old you can't find replacement parts for it. The middle range from your favorite manufacturer is probably about right.

While you don't need sheer CPU power, you do need a machine that keeps track of a number of connections simultaneously. This is memory-intensive, so you'll want a large amount of memory and probably a large amount of swap space as well. Caching proxies also need a large amount of free disk space to use for the caches.

Here are some suggestions about tape and disk needs:

• The bastion host can't reasonably use another host's tape drive for backups, as we'll discuss later in this chapter, so it needs its own tape drive of a size suitable to back itself up.

• A CD-ROM drive also comes in handy for operating system installation and possibly for keeping checksums on (or for comparing your current files to the original files on the CD-ROM). You may only need the CD-ROM drive initially when you first install and configure the machine, so an external drive that you "borrow" from another machine temporarily may be sufficient.

• You should be able to easily add another disk temporarily to the configuration for maintenance work.

• The boot disk should remove easily and attach to another machine - again, for maintenance work.

Both of the disk considerations mentioned suggest the bastion host should use the same type of disks as your other machines. For example, it should not be the only machine at your site running IPI disks.

The bastion host doesn't need interesting graphics, and shouldn't have them. This is a network services host; nobody needs to see it. Attach a dumb terminal (the dumber the better) to be the console. Having graphics will only encourage people to use the machine for other purposes and might encourage you to install support programs (like the X Window System and its derivatives) that are insecure.