 |  |
11.5. Reconfiguring for Production
Now it's time to move the machine from the configuration that was useful to you when you were building it to the best configuration for running it. You'll need to do several things:
- Reconfigure and rebuild the kernel.
- Remove all nonessential programs.
Mount as many filesystems as possible as read-only.
11.5.1. Reconfigure and Rebuild the Kernel
The first step in this phase of building your bastion host is to rebuild the operating system kernel to remove kernel capabilities you don't need. This may sound intimidating, but it's generally a relatively straightforward operation; it needs to be, because you'll be using the same capabilities you'd use to install a new type of device on your system. Every Unix system, as shipped, contains some form of configuration support (they range considerably in how kernel reconfiguration is supported and in what you can do). Besides reducing the size of your kernel (and thereby making more memory available for other purposes), rebuilding the kernel denies to attackers the chance to exploit these capabilities.Some capabilities are particularly dangerous. In particular, you should probably remove the following capabilities or device drivers:
- NFS and related capabilities
- Anything that enables network sniffing -- for example, Network Interface Tap (NIT) or Berkeley Packet Filter (BPF)
If your bastion host is a dual-homed host, this is the time to disable IP forwarding.
You have to be more careful when you disable kernel capabilities than when you disable services started by inetd or at boot time from the /etc/rc files (as described earlier). There are a lot of interdependencies between kernel capabilities. For this reason, it's sometimes hard to determine exactly what a given capability is used for. The consequences of disabling a capability that is actually needed can be severe -- for example, the new kernel might not boot.
ake sure you follow your vendor's instructions for building and installing new kernels. Always keep a backup copy of your old kernel. If you have a backup, you can boot from it if you find out that something is wrong with the new kernel. Some boot systems need all the kernels to reside in the same partition, or they may need to be configured with the names of all the kernels you wish to boot. Either way, be sure that you have a backup kernel, that it's possible to boot that kernel, and that you know how to do so, all before you change the working kernel.
When you know you can safely reboot the machine, go through the kernel configuration files the same way you went through the startup files, checking every single line to make certain that it's something you want. Again, watch for places where one configuration file contains another, and check your documentation to be sure that you've looked at all the configuration files that are consulted. Often there is one file for including device drivers and one or more for parameters; IP forwarding will be in the latter.
Once you've got a working kernel, you'll probably want to delete or encrypt your old "full function" kernel. Replace it with a backup copy of the working minimal kernel. Doing so will keep an attacker who somehow manages to break into your machine from simply using that old kernel to reboot, and thereby restore all of the services you so carefully disabled. For similar reasons, you'll probably also want to delete the files and programs needed to build a new kernel.
If your kernel uses loadable modules, it may be difficult to determine when they're used. You will want to delete or encrypt all the ones that you don't want used, but because they're not always explicitly loaded, you may not know which those are. Keeping an alternate boot medium handy, try moving them out of the directory for loadable modules. Run the machine through its paces before you finally remove or encrypt them.
Beware! Your vendor may have provided copies of "generic" kernels (which typically have every possible capability enabled) in unexpected locations for use during the installation of the machine and its (nonexistent) client machines. Poke around in all the directories where installation files are kept and all the directories for clients. The documentation generally tells you where client kernels are but rarely tells you about the internals of the install process. Check the documentation for disaster recovery advice, which may helpfully tell you where to locate spare kernel images.
11.5.2. Remove Nonessential Programs
The next step is to remove all of the programs that aren't essential for day-to-day operation. If a program isn't there, an attacker can't exploit any bugs that it might contain. This is especially true for setuid/setgid programs, which are a very tempting target for an attacker. You should remove programs you normally think of as being essential. Remember that the bastion host is purely providing Internet services; it does not need to be a comfortable environment in which to work.Window systems and compilers are examples of major programs you can get rid of. Attackers find these programs very useful: window systems are fertile ground for security problems, and compilers can be used to build the attacker's own tools. Graphical system administration programs are also usually powerful, vulnerable, and frequently unnecessary; however, on some platforms, they may be impossible to remove. Documentation and help systems (including manual pages) are at best an education for attackers, and at worst another source of vulnerabilities. Attackers have been known to hide programs and files among manual pages. Make sure that you have the information internally, but remove it from all bastion hosts.
Before deleting programs like compilers, make sure you've finished using them yourself; make sure you've built, installed, and tested everything you're going to need on this machine, such as the tools for auditing the system (discussed in Section 11.6, "Running a Security Audit", later in this chapter).
Instead of simply deleting key tools you'd expect an attacker to use, such as the compiler, you might want to replace them with programs that raise an alarm (for example, sending electronic mail or tripping your pager) when someone tries to run them. You might even want to have the programs halt the system after raising the alarm, if you believe it's better for the machine to be down than under attack. This is a prime way to humiliate yourself, however; you yourself are probably the one person most likely to forget where you are when you try to run a forbidden command. It's also a good way to set yourself up for denial of service attacks.
You'll want to do two scans looking for things to delete:
- Walk through all the standard directories for binaries on your system (everything that's in root's path or in the default user path). If you're unsure whether a program is needed, turn off execute permission on it for a while (a few days) before you remove or encrypt it and see what happens. You may also want to run the machine for a while before you do the scan and check the access times on files to see if they've been used.
- Use find to look for every file on the system that has the setuid or setgid bit turned on. The arguments to find differ radically from system to system, but you will probably want something like this:
find / -type f \( -perm -04000 -o -perm -02000 \) -ls
- Some versions of find provide special primitives for identifying setuid and setgid files.
11.5.3. Mount Filesystems as Read-Only
Once you've configured a bastion host, you don't want it to change, so you should mount as many filesystems as possible as read-only. How much of the machine you can protect this way will depend on the version of Unix that you're running and the services that you're providing. A machine that you're using as a packet filtering router may be able to run with all of its disk space protected; a machine that's providing mail service will need space to keep temporary files in, if nothing else.On a service host, you have to provide a certain amount of writable filesystem space for things like scratch space, system logs, and the mail spool. You might be able to use a RAM disk for this; however, you'll have to be sure that your operating system supports it, that you have enough RAM, and that you think you can afford to lose the contents of the RAM disk (for example, email in transit between internal hosts and the Internet) whenever your machine reboots.
With most versions of Unix, you'll also have to either provide writable disk space for memory swapping or turn off swapping. Many versions of Unix do not allow you to turn off swapping; however, they will usually allow you to use a separate disk for swap space, and that disk can safely be left writable. Using a RAM disk will increase your memory usage to the point where you will probably need swap space.
Systems based on BSD 4.4-Lite (for instance, current releases of NetBSD, FreeBSD, and the BSDI product) have a new immutable attribute that can be set on a per-file basis. If a file is marked "immutable", the file cannot be changed, not even by root, unless the system is running in single-user mode. If your operating system provides this capability, use it to protect your programs and configuration files from tampering by an attacker. (We recommend this approach only if you cannot use hardware write protection, or as an additional layer of security to use with hardware write protection. Because it's implemented in software, it is more likely to be compromisable.)
|  | |
| 11.4. Installing and Modifying Services |  | 11.6. Running a Security Audit |
