Most of this chapter discusses bastion hosts that are screened hosts or service-providing hosts on a screened network. There are several kinds of bastion hosts, however, that are configured similarly but have special requirements.
A nonrouting dual-homed host has multiple network connections but doesn't pass traffic between them. Such a host might be a firewall all by itself, or might be part of a more complex firewall. For the most part, nonrouting dual-homed hosts are configured like other bastion hosts but need extra precautions, discussed in the sections that follow, to make certain they truly are nonrouting. If a nonrouting dual-homed host is your entire firewall, you need to be particularly paranoid in its configuration and follow the normal bastion host instructions with extreme care.
You may want to run services that are difficult to provide safely with either proxying or packet filtering, or services that are so new that you don't know what their security implications are. For that purpose, a victim machine (or sacrificial goat) may be useful. This is a machine that has nothing on it you care about, and that has no access to machines that an intruder could make use of. It provides only the absolute minimum necessary to use it for the services you need it for. If possible, it provides only one unsafe or untested service, to avoid unexpected interactions.
Victim machines are configured much as normal bastion hosts are, except that they almost always have to allow users to log in. The users will almost always want you to have more services and programs than you would configure on a normal bastion host; resist the pressure as much as possible. You do not want users to be comfortable on a victim host: they will come to rely on it, and it will no longer work as designed. The key factor for a victim machine is that it is disposable, and if it is compromised, nobody cares. Fight tooth and nail to preserve this.
In most configurations, the main bastion host has special interactions with certain internal hosts. For example, it may be passing electronic mail to an internal mail server, coordinating with an internal name server, or passing Usenet news to an internal news server. These machines are effectively secondary bastion hosts, and they should be configured and protected more like the bastion host than like normal internal hosts. You may need to leave more services enabled on them, but you should go through the same configuration process.
Bastion hosts that exist solely to provide services to the Internet (for instance, web servers used to provide service to customers) have special concerns. They are extremely visible, which makes them popular targets for attack, and increases the visibility of successful attacks. If a machine that provides mail service for internal users is compromised, it's not going to be immediately obvious to outsiders, and it's unlikely to make it into the newspaper. If your web site is replaced by somebody else's page, or a clever satire of your web site, that's something people outside your site will notice and care about.
Although these machines have increased needs for security, they have some features that make them easier to secure. They need only limited access to the internal network; they usually provide only a few services, with well-defined security characteristics; and they don't need to support internal users (often, they don't need to support any users at all).
If the machine you're building is an entire firewall, instead of a part of a firewall, it is even more vulnerable. You are betting your entire site's security on this one machine. It is worth almost any amount of inconvenience and trouble to be absolutely certain that it's a secure machine. You may want to consider having a duplicate machine that you use for testing, so that you can check out new configurations without risking your Internet connection.