Disabling Nonrequired Services (Building Internet Firewalls, 2nd Edition)

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.

Any service provided by the bastion host might have bugs or configuration problems that could lead to security problems. Obviously, you'll have to provide some services that users need, as long as your site's security policy allows them. But if the service isn't absolutely necessary, don't borrow trouble by providing it. If a service isn't provided by the bastion host, you won't have to worry about possible bugs or configuration problems.

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.

Unfortunately, turning off IP forwarding does not always turn off all routing. On some systems, you can turn off IP forwarding, but the IP source-routing option usually remains a security hole.

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".

When a router receives a source-routed packet, it follows the route specified in the packet, instead of determining the most efficient route from source to destination. The source-routing specification overrides the ordinary routing. Because of the way the routing code is implemented in many operating systems, turning off IP forwarding does not disable forwarding of source-routed packets. It's implemented completely separately and must be turned off separately, often by completely different (and more difficult) mechanisms.

Source-routed packets can easily be generated by modern applications like the Telnet client that's freely available on the Internet as part of the BSD 4.4 release. Unless you block source-routed packets somewhere else, such as in a router between the dual-homed host and the Internet, source-routed packets can blow right past your dual-homed host and into your internal network.

Worse still, source routing goes both ways. Once source-routed packets make their way to an internal system, the system is supposed to reply with source-routed packets that use the inverse of the original route. The reply from your internal system back to the attacker will also blow right through your dual-homed host, allowing two-way connection through a firewall that was supposed to block all communications across it.

Fortunately, it is now common practice for firewalls to ignore all source routing, either by dropping packets with source routing or by stripping the source routing itself. In addition, systems that will accept source routes will rarely include them on the return packet.

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.

You don't want an intruder to attack the machine while you're working on it. To keep that from happening, follow these steps:

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.

You may find it easier to simply remove the bastion host's disk and attach it to an internal host as a nonsystem disk; you can then use the internal host's tools without fear of having them remain available when the bastion host is returned to service. This procedure also guarantees that the bastion host is not vulnerable to compromise from the outside while you are doing the work, since it is entirely nonfunctional while its disk is removed and not susceptible to accidental reconnection.

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.

Several very good automated auditing packages are freely available on the Internet.

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.

Once you've used the tools described in the previous section to create your initial baseline, store a copy of the tools and these initial audit results somewhere safe. Under no circumstances should you store the only copy of the baseline or the tools on the bastion host. Prepare for the worst: if someone were to break into the bastion host and tamper with the only copy of the baseline audit, this would compromise your ability to use the audit later on to detect illicit changes on the system. If intruders can change the auditing software, it doesn't matter whether they can change the baseline; they could simply set up the auditing software to reproduce the baseline. Keeping a copy of the baseline audit on a floppy disk or magnetic tape that's locked up some place safe is a good way to protect against such a compromise. Preferably, you don't want an intruder to even read the audit results; why tell them what you expect the system to look like and what files you aren't watching?

Periodically, (e.g., daily or weekly, depending on your own site's needs and capabilities), audit the machine once again and compare the new audit to the baseline. Make sure you can account for any differences you find. Ideally, you should automate this periodic reaudit so it happens regularly and reliably. Unfortunately, this is easier said than done. It can be difficult to arrange automatic audits that can't be defeated by "replay" attacks. In a replay attack, an attacker who has compromised your auditing system simply sends you a recording of a prior good audit whenever your system invokes the automatic auditing capability. The most practical defense against this is to run your automated auditing system often enough that it's unlikely an attacker could break in, discover the auditing system, and subvert it (covering his tracks) before the next audit runs. This suggests that you should run an audit at least daily. It may help to run the audit at random intervals, although it can be difficult to automate this well. It is better to run the audit at frequent but predictable intervals than to rely on human beings remembering to run it by hand.

If you start receiving warnings from the auditing system and you decide that they are incorrect, you should immediately reconfigure the auditing system or the operating system so that the warnings go away. If you get used to getting warnings, you will end up ignoring important new messages. Also, if you go on vacation, your replacement may not realize that the messages are benign and may take drastic action to remedy nonproblems.

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.

A checksum algorithm that has these characteristics is sometimes called a cryptographic checksum. Cryptographic checksums are discussed further in Appendix C, "Cryptography".

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.

It is important not to run checksums on files that are supposed to change and to update checksum data promptly when you make intentional changes. If there are frequent false warnings from the checksum system, you will miss genuine problems.