Chapter 10. Bastion Hosts
A
bastion host is
your public presence on the Internet. Think of it as the lobby of a
building. Outsiders may not be able to go up the stairs and may not
be able to get into the elevators, but they can walk freely into the
lobby and ask for what they want. (Whether or not they will get what
they ask for depends upon the building's security policy.) Like
the lobby in your building, a bastion host is exposed to potentially
hostile elements. The bastion host is the system that any outsiders
-- friends or possible foes -- must ordinarily connect with
to access your systems or services.
By design, a bastion host is highly exposed because its existence is
known to the Internet. For this reason, firewall builders and
managers need to concentrate security efforts on the bastion host.
You should pay special attention to the host's security during
initial construction and ongoing operation. Because the bastion host
is the most exposed host, it also needs to be the most fortified
host.
Although we sometimes talk about a single bastion host in this
chapter and elsewhere in this book, remember that there may be
multiple bastion hosts in a firewall configuration. The number
depends on a site's particular requirements and resources, as
discussed in Chapter 7, "Firewall Design". Each is set up according to
the same general principles, using the same general techniques.
Bastion hosts are used with many different firewall approaches and
architectures; most of the information in this chapter should be
relevant regardless of whether you're building a bastion host
to use with a firewall based on packet filtering, proxying, or a
hybrid approach. The principles and procedures for building a bastion
host are extensions of those for securing any host. You want to use
them, or variations of them, for any other host that's security
critical, and possibly for hosts that are critical in other ways
(e.g., major servers on your internal network).
This chapter discusses bastion hosts in general; the two following
chapters give more specific advice for Unix and Windows NT bastion
hosts. When you are building a bastion host, you should be sure to
read both this chapter and the specific chapter for the operating
system you are using.
10.1. General Principles
There are two basic principles for designing and building a bastion
host:
- Keep it simple
- The simpler a bastion host is, the easier it is to secure.
Any service a bastion host offers could have software bugs or
configuration errors in it, and any bugs or errors may lead to
security problems. Therefore, you want a bastion host to do as little
as possible. It should provide the smallest set of services with the
least privileges it possibly can, while still fulfilling its role.
- Be prepared for bastion hosts to be compromised
- Despite your best efforts to ensure the security of a bastion host,
break-ins can occur. Don't be naive about it. Only by
anticipating the worst, and planning for it, will you be most likely
to avert it. Always keep the question, "What if this bastion
host is compromised?" in the back of your mind as you go
through the steps of securing the machine and the rest of the
network.
Why do we emphasize this point? The reason is simple: bastion hosts
are the machines most likely to be attacked because they're the
machines most accessible to the outside world. They're also the
machines from which attacks against your internal systems are most
likely to come because the outside world probably can't talk to
your internal systems directly. Do your best to ensure that each
bastion host won't get broken into, but
keep in mind the question, "What if it does?"
In case a bastion host is broken into, you don't want that
break-in to lead to a compromise of the entire firewall. You can
prevent it by not letting internal machines trust bastion hosts any
more than is absolutely necessary for the bastion hosts to function.
You will need to look carefully at each service a bastion host
provides to internal machines and determine, on a service-by-service
basis, how much trust and privilege each service really needs to
have.
Once you've made these decisions, you can use a number of
mechanisms to enforce them. For example, you might install standard
access control mechanisms (passwords, authentication devices, etc.)
on the internal hosts, or you might set up packet filtering between
bastion hosts and internal hosts.
| | |
9.8. What If You Can't Proxy? | | 10.2. Special Kinds of Bastion Hosts |