10.7. Disabling User Accounts on Bastion Hosts
If
at all possible, don't allow any user accounts access to
bastion hosts. For various reasons, bastion hosts may know about
users, but users should not have accounts that actually allow them to
use the host. Keeping such accounts off bastion hosts will give you
the best security. There are several reasons why, including:
- Vulnerabilities of the accounts themselves
- Vulnerabilities of the services required to support the accounts
Reduced stability and reliability of the machine
Inadvertent subversion of the bastion host's security by users
Increased difficulty in detecting attacks
User accounts provide relatively easy avenues of attack for someone
who is intent on breaking into a bastion host. Each account usually
has a reusable password[23] that can be attacked through a variety of means,
including dictionary searches, brute force searches, or capture by
network eavesdropping. Multiply this by many users, and you have a
disaster in the making.
Supporting user accounts in any useful fashion requires a bastion
host to enable services (for example, printing and local mail
delivery services) that could otherwise be disabled on the bastion
host. Every service that is available on a bastion host provides
another avenue of attack, through software bugs or configuration
errors.
Having to support user accounts also can reduce the stability and
reliability of the machine itself. Machines that do not support user
accounts tend to run predictably and are stable. Many sites have
found that machines without users tend to run pretty much
indefinitely (or at least until the power fails) without crashing.
Users themselves can contribute to security problems on bastion
hosts. They don't (usually) do it deliberately, but they can
subvert the system in a variety of ways. These range from trivial
(e.g., choosing a poor password) to complex (e.g., setting up an
unauthorized information server that has unknown security
implications). Users are seldom trying to be malicious; they're
normally just trying to get their own jobs done more efficiently and
effectively.
It's usually easier to tell if everything is "running
normally" on a machine that doesn't have user accounts
muddying the waters. Users behave in unpredictable ways, but you want
a bastion host to have a predictable usage pattern, in order to
detect intrusions by watching for interruptions in the pattern.
If you need to allow user accounts on a bastion host, keep them to a
minimum. Add accounts individually, monitor them carefully, and
regularly verify that they're still needed.
There is one circumstance where you
should have user accounts. Every person who needs to log into a
bastion host for administrative purposes should have an individual
account and should log in with that account. Nobody should log into
the machine directly as "administrator" or
"root" if there is any other way for them to get work
done. These accounts should be kept to a minimum and closely
controlled. It should be made impossible to reach these accounts from
the Internet with a reusable password (if the capability is there,
some administrator will use it). In fact, it's better not to
allow access to the accounts from the Internet at all, and you might
want to consider disallowing network logins altogether. (Note that
whitehouse.gov was broken into
because its administrators, who knew better, succumbed to temptation
and logged into it across the Internet to do administration.) We will
discuss appropriate mechanisms for remote administration in the
following chapters about specific operating systems.
 |  |  |
10.6. Selecting Services Provided by a Bastion Host |  | 10.8. Building a Bastion Host |