 |  |
10.10. Disabling Nonrequired Services
Once you've completed the basic process of securing your bastion host, go on to the next step: disabling any services that aren't absolutely necessary for the bastion host to provide. You will want to disable all services except the ones you have decided to provide, and the supporting services necessary for those to run, as described earlier. You may not always know which services are the required support services, particularly because service names tend to be cryptic and uninformative.How do you know which services to disable? There are three simple rules to apply:
- If you don't need it, turn it off.
- If you don't know what it does, turn it off (you probably didn't need it anyway).
- If turning it off causes problems, you now know what it does, and you can either turn it back on again (if it's really necessary) or figure out how to do without it.
If you can live without a service, it should be turned off. It's worth suffering some inconvenience. This means that you're going to need to think very carefully about services. You'll be disabling not just services you never heard of and never used, but also services you've purposefully enabled on other machines (and, unfortunately, services you've never heard of because they're considered too basic ever to do anything to). Look at every service and ask yourself "How could I avoid enabling this? What do I lose if I turn it off ?"
10.10.1. How to Disable Services
The first step in disabling services is ensuring that you have a way to boot the machine if you accidentally disable a critical service. This could be a second hard disk with a full boot partition on it or a CD-ROM drive with the operating system install disk. It could even be a second installation of the operating system on the same hard disk. You need to be ruthless; if you can't reboot when you delete the wrong thing, at best you're going to be over-cautious about deleting things, and at worst you're going to end up with an unusable computer. (These fallback operating systems are also useful places to copy files from or compare files to if things go wrong.)Second, you must save a clean copy of every file before you modify it. Even when you're just commenting things out, every so often your fingers slip, and you delete something you didn't mean to, or you change a critical character. If you are using a user interface to change things instead of directly modifying files, you may not know what files are actually being changed, so you may need to simply back up the entire system. If possible, do this with another disk, rather than with a standard program and a tape; if you have to back out a change, you will want to be able to replace just the files that are actually involved, and that's easiest to determine by comparing things on disk. On Windows NT, you should note that the registry is not backed up or copied by normal procedures; be sure that you include it. You will also want to build a new Emergency Repair Disk (which includes the most important parts of the registry) immediately before you begin the reconfiguration.
When you disable a service, you should also disable all services that depend on it. This will prevent nasty warning messages and will also mean that reenabling a service will not result in a cascade of unfortunate surprises as other services are also turned on.
Finally, we've said it before and we'll say it again: you should not connect a machine to a hostile network until it has been fully configured. That means that all of your work on disabling services should be done with the machine either entirely disconnected from the network, or on a safe test network. The reason that you are disabling services is that they are unsafe, and if you are connected to a hostile network, they may be exploited before you finish disabling them.
10.10.1.1. Next steps after disabling services
In general, you'll need to reboot your machine after you have changed the configuration files. The changes won't take effect until you do so.After you have rebooted and tested the machine, and you are comfortable that the machine works without the disabled services, you may want to remove the executables for those services (as long as they are not used by other services). If the executables are lying around, they may be started by somebody -- if not you, some other system administrator, or an intruder. A few services may even be executable by nonroot users if they use nonstandard ports.
If you feel uncertain about removing executables, consider encrypting them instead. You should use a program that provides genuinely strong encryption. The Unix crypt program is not appropriate; neither are many of the available packages for Microsoft systems. Instead, use a more secure encryption program like snuffle or something that uses the DES or IDEA algorithm. Choose a secure key; if you forget the key, you're no worse off than if you'd deleted the files, but if an intruder gets the key, you're considerably worse off.
10.10.2. Running Services on Specific Networks
In some cases, you want to run services that need to respond to only one network on a machine with multiple network interfaces. You may be able to limit those services to just the networks you wish to use them on. Under Unix, this usually means specifying which IP addresses and/or network interfaces you want the service to respond to as part of the service's startup options; this will be slightly different for every service, and not all services provide this facility. Under Windows NT, only a few basic services can be controlled this way. In the Networking control panel, go to the Bindings tab and set it to show bindings for all adapters. Select the services that you wish to turn off and press the Disable button.
10.10.3. Turning Off Routing
If you have a dual-homed host that is not supposed to be a router, you will need to specifically disable routing. In order to act as an IP router, a dual-homed host needs to accept packets that are addressed to other machines' IP addresses, and send them on appropriately. This is known as IP forwarding, and it's usually implemented at a low level in the operating system kernel. An IP-capable host with multiple interfaces normally does this automatically, without any special configuration.Other machines have to know that the dual-homed host is a router in order to use it as such. Sometimes this is done simply by configuring those machines to always route packets for certain networks to the dual-homed host (this is called static routing). ore often, however, the dual-homed host is configured to broadcast its routing capabilities via a routing protocol such as Routing Information Protocol (RIP). Other machines hear these routing broadcasts and adjust their own routing tables accordingly (this is called dynamic routing). This broadcast of routing information by the dual-homed host is usually done by an additional program (for example, routed or gated on a Unix system), which often has to be turned on explicitly.
To use a dual-homed host as a firewall, you need to convert it to a nonrouting dual-homed host; you take a machine that has two network interfaces, and you configure it so it can't act as a router between those two interfaces. This is a two-step process:
- Turn off any program that might be advertising it as a router; this is usually relatively straightforward.
- Disable IP forwarding; this can be equally easy or considerably more difficult, and may require modifying the operating system kernel.
What is source routing ? Normal IP packets have only source and destination addresses in their headers, with no information about the route the packet should take from the source to the destination. It's the job of the routers in between the source and the destination to determine the most efficient route. However, source-routed IP packets contain additional information in the IP header that specifies the route the packet should take. This additional routing information is specified by the source host -- thus the term "source-routed".
If you are not going to screen your dual-homed host, you will need to patch your operating system so that it rejects source-routed packets. Consult your vendor, and/or appropriate security mailing lists (discussed in Appendix A, "Resources") for information on how to do this on your platform.
10.10.4. Controlling Inbound Traffic
As we discussed in Chapter 8, "Packet Filtering", many general-purpose computers are provided with packet filtering packages. Even when these packages are not adequate for building packet filtering routers, they can provide an extra level of protection for bastion hosts. If packet filtering is available to you, you should set it up so that it allows only the traffic that you intend to support. In most configurations, this will be multiply redundant; it will duplicate protections provided on routers, and most of the rules will prevent connections to services that don't exist anyway. This is a useful kind of redundancy, which will help to protect you from configuration errors.Packet filters will also keep you from successfully adding new services to the machine. You should document the filters carefully to avoid puzzling failures later.
10.10.5. Installing and Modifying Services
Some of the services you want to provide may not be provided with your operating system. Others may be provided with servers that are inappropriate for use in a secure environment or are missing features you probably want (for example, stock fingerd and ftpd ). Even those few remaining services that are provided, secure, and up to date in your vendor's operating system release usually need to be specially configured for security.For information on general schemes for protecting services in the operating system you are using, see Chapter 11, "Unix and Linux Bastion Hosts", and Chapter 12, "Windows NT and Windows 2000 Bastion Hosts ", as appropriate. For detailed information about individual services, including advice on selecting HTTP, NNTP, and FTP servers, see the chapters relevant to the services you want to provide (for instance, Chapter 15, "The World Wide Web", for HTTP; Chapter 16, "Electronic Mail and News", for NNTP; and Chapter 17, "File Transfer, File Sharing, and Printing", for FTP).
10.10.6. 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:
- Finalize the operating system configuration.
- Remove all unnecessary programs.
Mount as many filesystems as possible as read-only.
10.10.6.1. Finalize the operating system configuration
Once you've deleted all the services that aren't used on a day-to-day basis, you'll find that it is very difficult to work on the bastion host -- for example, when you need to install new software packages or upgrade existing ones. Here are some suggestions for what to do when you find it necessary to do extensive work on the bastion host:
- Write all the tools to tape before deleting them, and then restore them from tape when needed. Don't forget to delete them each time after you're done.
- Set up a small, external, alternate boot disk with all the tools on it. Then, plug the disk in and boot from it when you need the tools. Don't leave the disk connected during routine operations, however; you don't want an attacker to be able to mount the disk and use the tools against you.
- Either disconnect the bastion host from the network or disconnect your network from the Internet before you begin.
- Give the bastion host back the tools you'll need to use (as we've described earlier).
- After you've finished your work on the machine, return it to its normal (stripped down) operating condition.
- Reconnect the bastion host to the network or your network to the Internet.
10.10.6.2. Mount filesystems as read-only
Once you've got the bastion host configured, you don't want anybody (particularly an attacker) to be able to change the configuration. To guard against this happening, mount the filesystems on the bastion host as read-only if possible (particularly the filesystems that contain program binaries) to protect against tampering.It's much better if you can use hardware write-protect; an attacker may be able to remount disks with write permission without getting physical access to the machine, but it's not going to do any good if the hardware write-protect on the disk is on. Many SCSI disks have a "write-disable" jumper or switch you can set. If you find powering the disk down and removing it from the case unacceptable as a way to get write access, you could wire this jumper to an external switch on the drive enclosure.
10.10.7. Running a Security Audit
Once you've got the bastion host reconfigured, the next step is to run a security audit. There are two reasons for doing this. First, it gives you a way to ensure you haven't overlooked anything during system setup. Second, it establishes a "baseline", or a basis for comparison, against which you can compare future audits. In this way, you'll be able to detect any tampering with the machine.10.10.7.1. Auditing packages
Most auditing packages have two basic purposes:
- Checking for well-known security holes
- These are holes that have been uncovered by system administrators, exploited by attackers in system break-ins, or documented in computer security books and papers.
- Establishing a database of checksums of all files on a system
- Doing this allows a system administrator to recognize future changes to files -- particularly unauthorized changes.
How do you use the various auditing packages to audit your system? The details of what you do depend upon which package you're using. (See the documentation provided with the packages for detailed instructions.) This section provides some general tips.
You will need to do some configuration. Don't just install the program, run it, and expect you'll get reasonable results. Expect to go through several iterations of running the auditing package, getting warnings, and reconfiguring your machine or the auditing package to get rid of warnings. When you get warnings, you have to decide whether the auditing package is wrong, or you are. There will be some cases where the right thing to do is to turn off checks, but it shouldn't be your automatic response.
10.10.7.2. Use cryptographic checksums for auditing
Checksums are very helpful in auditing. An intruder who changes a program or configuration file will almost certainly correct the modification dates afterwards, so you can't use these dates as a reliable index. Comparing every file to a baseline copy avoids that problem but takes a lot of time and requires that you store a copy of every single file, effectively doubling your storage requirements. Storing checksums is probably your best bet.A checksum is a number calculated on data that is designed to detect changes to the data. This is useful for a communications channel; if a sender calculates a checksum as data is being sent and a receiver does the same, then the two can simply compare checksums to see if the data was changed during transmission. You can also do exactly the same checksum calculation for files, but instead of sending the file elsewhere, you recalculate and compare the checksum at a later time. Calculating checksums can be time consuming because you have to read the contents of every file, but it is not as time consuming as reading everything twice and doing a bit-by-bit compare. In addition, storing a checksum takes up much less space than storing an entire file. However, checksums are not full representations of the file, and every checksum algorithm has cases where it will give the same checksum for two different files. This is called a collision, and checksum algorithms are designed to make this unlikely to occur for the differences they are designed to detect.
In order for a checksum to be useful in detecting unauthorized changes to files, it must have several characteristics:
- It must be practically impossible to deliberately create a file that has a checksum that matches another. This can be achieved by designing the algorithm so that it cannot be reversed and run backwards (you can't start with a checksum and use a known method to create a file that produces that checksum).
- The checksum must be of a large enough size so that you cannot create a list of files, one for each value the checksum can have, and match a given checksum that way. In practical terms, this means that a useful checksum should be larger than 128 bits in size.
- If you change something only very slightly in the file, the checksum must change by a large amount.
You will sometimes hear rumors that these algorithms are vulnerable to the same sort of trickery that can be used with standard checksums. This is not true; there are no known incidents where anybody has managed to subvert a cryptographic checksum. These rumors are based on three grounds:
- They're due to confusions with CRC-style checksums, which are in fact often subverted.
- They're due to incidents in which people have missed changes when using cryptographic checksums because intruders have been able to rewrite the checksum database or replace the checksumming program.
- They're due to misunderstanding of some technical arguments about the security of early cryptographic checksums. Such algorithms are no longer used because of theoretical weaknesses, but those weaknesses were never exploited and are not present in current cryptographic checksums.
10.10.8. Connecting the Machine
Now that you have the machine fully secured, you can finally connect it to its destination network and run it. You want to do this when you're going to be around to see what happens; don't make it the last thing you do before that long overdue vacation.
