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.

[23]We discuss ways to support nonreusable passwords in Chapter 21, "Authentication and Auditing Services".

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.

---