 |  |
Chapter 11. Unix and Linux Bastion Hosts
Contents:
Which Version of Unix?Securing Unix
Disabling Nonrequired Services
Installing and Modifying Services
Reconfiguring for Production
Running a Security Audit
It's impossible to give complete instructions on how to configure any given machine; the details vary greatly depending on what version of Unix you're running and exactly what you intend to do with the machine. This chapter is intended to give you an outline of what needs to be done, and how to figure out how to do it. For more complete configuration details, you will need to look at resources that are specific to your platform.
Useful Unix Capabilities
Every operating system has certain special capabilities or features that can be useful in building a bastion host. We can't describe all these capabilities for all systems, but we'll tell you about a few special features of Unix because it's a common bastion host platform:
- setuid/setgid
- Every Unix user has a numeric user identification (uid ) in addition to his or her login name and belongs to one or more groups of users, also identified by numbers (gids). The Unix kernel uses the uid and the various gids of a particular user to determine what files that user has access to. Normally, Unix programs run with the file access permissions of the user who executes the program. The setuid capability allows a program to be installed so that it always runs with the permissions of the owner of the program, regardless of which user is running the program. The setgid capability is similar; it allows the program temporarily (while running the program) to grant membership in a group to users who are not normally members of that group.
Environmental modifications, such as those made by setuid/setgid and chroot, are inherited by any subsidiary processes a program starts. A common way of restricting what the programs on a bastion host can do is to run the programs under "wrapper" programs; the wrapper programs do whatever setuid/setgid, chroot, or other environmental change work is necessary, and then start the real program. chrootuid is a wrapper program for this purpose; Appendix B, "Tools", gives information on how to get it.
- chroot
- The chroot mechanism allows a program to irreversibly change its view of the filesystem by changing the program's idea of where the root of the filesystem is. Once a program chroots to a particular piece of the filesystem, that piece becomes the whole filesystem as far as the program is concerned; the rest of the filesystem ceases to exist from the program's point of view. This can provide a very high level of protection, but it is by no means perfect. Programs may not need access to the filesystem to achieve nefarious ends, particularly if they have large numbers of other permissions.
11.1. Which Version of Unix?
Which version of Unix should you choose? 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 want to use that version. If your site has some familiarity with several versions of Unix, and the relevant tools (discussed throughout this chapter) and support 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 suppliers differ vastly in their openness about security issues, the difference in the actual security between different general-purpose 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. Don't assume that proprietary versions of Unix are more secure than open source versions, either; paying money to a vendor doesn't guarantee that they care about security, only that they care about money. Ironically, the operating systems with the most worrisome tales may be the most secure ones, because they're the ones getting fixed.
Some versions of Unix are particularly designed for security and are therefore particularly suited for use in bastion hosts. "Designed for security" means different things to different vendors. It ranges from relatively minor changes to the packages that are installed (for instance, the Debian Linux distribution tries to install securely, and the SuSE Linux distribution provides a post installation security script) to major changes to the internals (for instance, OpenBSD has made significant changes to all parts of the operating system).
Several commercial vendors offer secure versions of their operating systems that are designed to meet government security needs. These versions usually lag behind the main releases (the government approval process is slow) and may not support all the add-on products that the main releases do. On the other hand, the auditing capabilities they offer are useful for bastion hosts. If you can afford the extra cost and the delayed release schedule, these operating systems are a good choice for bastion hosts.
|  | |
| 10.12. Protecting the Machine and Backups |  | 11.2. Securing Unix |
