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

12.4. Disabling Nonrequired Services

When you have a secure machine, you can start to set up the services on it. The first step is to remove the services that you don't want to run. Consult Chapter 10, "Bastion Hosts", for more information about deciding which services you don't want to run. The main idea is to remove all services that you don't actually need for the machine to do the work it's designed to do, even if they seem convenient or harmless.

12.4.1. How Are Services Managed Under Windows NT?

There are two parts to service management. First, the administrative interfaces, which you use to install, remove, and configure services, and to manually start and stop them. Second, the underlying mechanisms, which automatically handle services and make them continuously available. You do not normally need to know about these mechanisms in order to administer a machine. We discuss them here for two reasons:

If you end up building a particularly specialized bastion host, you may need a very fine degree of comprehension and control over the services, in which case you will need this information.
People who are accustomed to administering Unix hosts expect to have this level of information, and will attempt to control services at this level, only to become confused and hostile when they run into some of the more obscure side effects of the differences between the two operating systems.

Under Windows NT, the tool that is normally used to install services that are provided by Microsoft is the Networking control panel. Services that are provided by other vendors will come with their own installation programs. Some services are configured from the Networking control panel, while others have their own configuration and management programs.

The tool that is used to manually start and stop services is the Services control panel. The Services control panel can also set up some generic configuration information for services, but any service-specific parameters have to be managed separately. Windows 2000 gives more information and control from the Services control panel than Windows NT 4; a number of things are accessible only from the registry in Windows NT 4 but are nicely presented in the user interface in Windows 2000 (for instance, information about which services depend on each other).

The rest of this section discusses the underlying mechanisms; you may feel free to ignore it if you do not need control of services beyond that presented by the user interface.

Services under Windows NT are always started by the Service Control Manager (SCM). (The SCM is unfortunately completely different from the user-visible Services control panel.) Services can be started as part of the boot process or on demand. Services started during boot can start at any time from the very beginning (for services with a "boot" startup type) to after users are already able to log in (for services with an "autostart" type). While Unix boot mechanisms specify an explicit order for services to start up in, Windows NT services specify their dependencies and type, and the operating system figures out what order to start them in. This is in general more effective at letting you add new services and get them started correctly but makes it harder to calculate the order that services actually start in.

"On demand" can also cover a range of situations. Most commonly, it means that the service starts when a user starts an application that needs the service.[24] "On demand" services can also be started explicitly from the Services control panel, or any other application that talks to the Service Control Manager (for instance, the SQL Service Manager). Services that are RPC providers (directly or through DCOM) will be started if there is a request for them. Finally, services can have dependency information, and a demand service can be started because a service that depends on it attempts to start. This can create a situation where a service is marked as demand but actually starts at boot time, because a service that depends on it is marked as autostart.

[24]Note that this depends on the application explicitly attempting to start the service; "on demand services" will not be started simply because an application demands them, despite the name.

Not everything that you think of as a service will appear in the Services control panel. Some things that behave like services are implemented entirely or in part as drivers that are loaded into the operating system and do not run as separate processes at all. These are not actually services from the operating system's point of view, and they are listed in the Devices control panel instead of the Services control panel. They are, however, listed as services in the registry, with registry entries in the following:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

This lists all services in alphabetical order, and you will have to look at the value for "Start" to see if they are turned on and when they start up.

Not everything in the Services section of the registry is a network server; the registry also includes normal device drivers and filesystem drivers in this section, and some things that function as servers in the context of the local machine function as clients in the Internet context. That is, they provide a centralized service for programs running on the local machine, but they do not accept requests from other hosts. For instance, a DHCP service is installed by default; it acts as a client, requesting information from a DHCP server. However, it then distributes this information to other processes on the machine, which makes it a service from the operating system's point of view. There is no straightforward way to tell whether something is a purely local service or a network service, or whether something marked as a filesystem driver is a genuine filesystem driver or part of a network service.

Just to add a final note of confusion, there is no need for one Windows NT service to be implemented as one executable. For performance reasons, multiple Windows NT services may be implemented in the same executable (for instance, the simple TCP/IP services, DHCP, and Berkeley LPD print service are all in the same executable). What the executable does will be controlled by the registry entries for the relevant services. It's also possible for one service to be made up of more than one file, with one running as a kernel driver for maximum speed and the other running as a normal service to avoid burdening the kernel too far. And, in fact, it's not at all uncommon for both these things to happen at once, so that a service is split into a kernel driver and a standard service, and the standard service shares an executable with several others.

Note that the kernel drivers by themselves do not provide services. They are simply an efficient way of providing data to the actual servers. Unix people who are attempting to disable services on Windows NT often disable the actual service, note that the port is not listed as open in netstat, and then become severely distressed when port scans show that something is listening to the port. This is a symptom of split service that's using a kernel driver, not of some horrible secret way that the operating system is preventing you from turning off the server and then lying about it. The server is off; the port is not bound; but the kernel driver is picking up the data and throwing it away. No significant security problem is involved, and if you wish to get rid of the apparent problem, you can use the Devices control panel to disable the relevant device.

The Resource Kit provides a command named sc that presents information about the running services and drivers; this gives you a much more usable interface than the registry and removes the large amounts of information about services and drivers that aren't in use.

There is no standard way of giving options to individual services under Windows NT, aside from a few parameters dealing with startup order and dependencies, which are in well-defined places in the registry. You will have to research each server separately. In general, service parameters are stored somewhere in the registry -- the Microsoft-approved locations are in:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ServiceName\Parameters

HKEY_LOCAL_MACHINE\Software\CompanyName\ServiceName

but servers are free to put them anywhere they can write to, in or out of the registry. Normally, service authors should provide a management interface in the form of a control panel or a plug-in for the Microsoft Management Console, which will modify some or all of the parameters.

12.4.1.1. Registry keys

Here is an overview of the registry keys for services and their use in determining what services do in order to secure a bastion host:

DependOnGroup

Value

eaning

0x00

Ignore failure; continue without doing anything.

0x01

Produce a warning dialog box.

0x02

Switch to the last known good configuration if one is available; otherwise, boot anyway.

0x03

Count this boot as a failure, switch to the last known good configuration if one is available, and fail to boot if not.

Group

Disabled (filesystem drivers will load anyway)

Tag

Value

eaning

0x01

Kernel-mode device driver

0x02

Filesystem driver

0x04

Arguments to network adapter

0x10

Server, standalone process

0x20

Server, can share address space

Subkeys

12.4.1.2. Other ways to start programs under Windows NT

All the descriptions in the previous section are about official Windows NT services. There are several other ways to automatically start programs under Windows NT, and you may run into "services" that use one of these other methods. In general, this is an extremely bad sign. These are not genuine Windows NT services; they are almost certainly originally written to run under other operating systems, and there is very little chance that they will be either secure or reliable. If at all possible, you should avoid running such programs on bastion hosts, or for that matter, other security-critical hosts.

The following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\BootExecute

contains a command line that is executed at boot time. This is normally used to run autocheck to do filesystem checking and, as far as we know, is never used by legitimate services. Because it runs early in the boot process, it would be a tempting place to hide a virus.

The following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion

contains three keys that are used to start programs at user login: Run, RunOnce, and RunServices. These are normal ways to start persistent programs under Windows 95/98 and may be used by legitimate programs that are designed for that environment. Some programs may also still use a model where they configure a persistent program to autostart when a particular user logs in, under the expectation that the machine will be set up to log that user in automatically at bootup.

Programs started in these ways may behave like services from the user's point of view, but they are not services from the operating system's point of view and are not managed by the Service Control Manager. This gives them very different security models. In particular, unless otherwise configured, the SCM runs services using the System account, which has the odd property that it is all-powerful on the local machine but is incapable of using the network. Programs started at user login will run as the user who just logged in, which will make significant changes to the permissions they have. A regular user will have more access to the network and to user files than the System account, but less access to operating system files and capabilities (meaning that a program that is auto-started at login instead of being a service will have more opportunities to be hostile and fewer to be useful).

Run models that require a user to be logged in are a significant security problem under Windows NT, because having a user logged in adds vulnerabilities. If you can't avoid servers like these, try to convert them to services using the Resource Kit's srvany.exe.

12.4.2. How to Disable Services Under Windows NT

As we discussed in Chapter 10, "Bastion Hosts", there are four general precautions to take when disabling services:

Make sure that you have a way to boot the machine if you disable a critical service (for instance, a secondary hard disk with a full operating system image or a bootable CD-ROM).
Save a clean copy of everything you modify so that you know how to put it back the way it was if you do something wrong. Since it's hard to identify modified files precisely on Windows NT, you should have a full backup of the system, including a dump of the registry.
When you disable a service, disable everything that depends on it.
Don't connect the machine you are trying to protect to a hostile network before you have completed the process of disabling services. It is possible for the machine to be compromised while you are preparing it.

Once you've set up your alternate boot process, start by going into the Networking control panel's Services tab and removing the things you don't need, which will probably be most, if not all, of them. Section 12.4.5, "Specific Windows NT Services to Disable", later in this chapter, provides more information about which services you should remove. The advantage of disabling services by removing them from the Services tab is that if possible, it removes the services altogether, and the only way to turn them on will be to reinstall them.

You can also disable services by setting them to the startup status "Disabled" from the Services control panel. This is very easy to undo later, which may not be desirable. On the other hand, doing anything more permanent involves untraditional and relatively risky moves. For instance, you can remove the registry keys for services you have disabled. Without the registry keys, the Service Control Manager can't start them, and you have to know what the keys should be in order to put them back. Removing the relevant executables is another solution, but as noted earlier, it's common for multiple Windows NT services to run as part of the same executable. If you want any of the services provided by a given executable, you will have to leave it.

Some Microsoft documentation claims that some services can be disabled by stopping them (from the Services control panel or the "net stop" command). This is not true; a stopped service will be restarted at boot time unless it is also disabled.

The Services tab of the Networking control panel
The Services control panel
The registry

You need to disable services from the registry only in very exceptional cases; you should be able to do everything you need from the Networking and Services control panels.

The Networking control panel

In general, nothing in the Services tab of the Networking control panel is actually required, and you should disable all of the services if possible. Here we list services with special considerations:

Microsoft DNS server (Server)

You do not normally want to run a DNS server on a bastion host unless that bastion host is dedicated to name service. You will therefore turn this off on most bastion hosts.

If you are building a bastion host to be a name server, the Microsoft DNS server is a reasonable choice for a DNS server to run, but in a bastion host configuration, you will need to keep two things in mind. First, you do not want a bastion host to rely on data from a WINS server on another machine, so the DNS server should not be configured to fall back to WINS unless the WINS server is on the same bastion host. Second, the DNS Manager (which is often used to configure the DNS server) relies on NetBT, which may not be available on a bastion host, so you may not be able to use it except at the console.

Microsoft TCP/IP printing (Server and Workstation)

Microsoft's implementation of lpr. Although lpr is not a secure protocol, it is often safer than using SMB printing, which cannot be enabled without enabling more dangerous services at the same time. Therefore, if you want to be able to print from a Windows NT bastion host, but do not have the resources to dedicate a printer, your best choice may be to install the Microsoft TCP/IP Printing subsystem on the bastion host and the print server and then disable the lpd server on the bastion host. (Do not use a bastion host as a print server, via any protocol; if you directly attach a printer to the bastion host, resign yourself to having it be a dedicated printer for that single host.)

NetBIOS interface (Default Server and Workstation)

The base for many of the Microsoft-native services. You will need it if you intend to use normal Microsoft networking. Ideally, you should avoid this service on bastion hosts.

Remote Access Service (Server and Workstation)

This provides networking either over phone lines or via PPTP (which is discussed further in Chapter 14, "Intermediary Protocols"). It should not be installed unless the machine will provide or use dial-up networking or virtual private networking services.

Server (Default Server and Workstation)

This is the server for inbound NetBIOS connections, including SMB connections. This includes file sharing, printer sharing, and remote execution of the Registry Editor, Event Viewer, and User Manager. You should probably remove it, although the machine will then be inaccessible via all normal Windows NT networking. If you need to use normal Windows NT networking (this is practically everything but FTP, HTTP, and SMTP), you should be sure that NetBT access is blocked at some other point and/or that the Server is unbound from high-risk network interfaces (see the discussion of configuring services to run on specific network interfaces).

Because of the way that NetBT name service works, a machine that has no Server service running will register its name correctly at boot time but won't be able to defend itself if another machine tries to claim the name. This may seem unimportant (who cares what happens to the NetBT name if the machine doesn't speak NetBT anyway?), but in fact, most Microsoft machines will look for a NetBT name before a DNS name, and attempts to reach the machine via HTTP or FTP from local clients will use NetBT resolution. If it's important to reach the machine from internal Microsoft machines, you need to protect it from masquerades. There are two ways to do this. If you have a reliable WINS configuration with a limited number of WINS servers, you can configure a static mapping for the name in each WINS server. If that is impractical, give the machine a name at least 16 characters long, and NetBT name resolution will be impossible, forcing clients to fall back to DNS, which is not vulnerable to the same sorts of trivial and/or accidental masquerading.

Simple TCP/IP services (Server and Workstation)

This package consists of echo, chargen, discard, daytime, and quotd, which are discussed further in Chapter 22, "Administrative Services". The standard advice is to avoid it unless you need one of the services; it is hard to imagine how you could possibly need any of them. Do not install it.

SNMP service (Server and Workstation)

SNMP is a dangerous service that provides a great deal of information and control with very little security, and you should normally avoid it. Many references will advise you to install SNMP in order to get TCP/IP performance statistics in the Performance Monitor. If you install SNMP for this reason, you will also have installed the SNMP agent service, which you do not need to run and which should be disabled from the Services control panel.

If you do wish to run the SNMP agent, you must run a version of Windows NT later than 4.0 Service Pack 4; versions before that do not correctly handle settings and will provide read and write access to the "public" community. You should also be sure to configure the SNMP Security Properties (available from the Network control panel in Services SNMP Service Security):

If you have an SNMP monitoring station, leave Send Authentication Trap on, and configure the correct address for the station into the Traps panel. This will cause the machine to send a warning message if it receives a request with an invalid community name in it. (This is all this option does; it does not actually enable any authentication beyond SNMP's default method, which uses the community name as a form of cleartext password.)

Edit the Accepted Community Names so that "public" is no longer accepted, and the only accepted value is an unguessable name unique to your site. Do not leave this field blank! If this field is blank, any community name will be accepted, and all SNMP requests will be valid.

Set Only Accept SNMP Packets from These Hosts. You must include a host here; put in your SNMP monitoring station's address if you intend to use one, or use 127.0.0.1 (the loopback address). Note that this relies on authenticating by source address. If attackers can forge an accepted address on an incoming packet, they can reset important networking parameters. This is especially dangerous because it is an attack that does not require reply packets to be useful. Do not use an SNMP monitoring station unless you can prevent forged packets with its address from reaching the machine.

12.4.5.1. The Services control panel

Once you have removed the services you don't want, there should be relatively little left in the Services control panel. You will probably want to disable all but the necessary services previously discussed and the services you intend to provide. You should be particularly careful to disable the UPS service and the Schedule service unless you are absolutely certain that they are required and you have taken steps to protect them from misuse. Both of these services have known vulnerabilities.

12.4.6. Turning Off Routing

As we discussed in Chapter 10, "Bastion Hosts", most machines with more than one network interface will automatically attempt to route traffic between interfaces. You do not normally want a bastion host to do this. If you are not trying to configure a bastion host that is also a router, you should turn off routing, which is a three-part process:

Turn off services that advertise the system as a router.
Turn off IP forwarding, which actually does the routing.
If necessary, turn off source routing separately.

Under Windows NT, turning off IP forwarding can be done either from the Networking control panel (under Protocols

TCP/IP

Routing), by unchecking Enable IP Forwarding or from the registry by setting the following key to 0:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter

It will automatically be off if there is only one network interface. If you later add a second network interface, Windows NT may helpfully turn it on for you. Be sure to turn it off after you install all the interfaces you intend to have on the machine. In addition, the TCP/IP Properties dialog will not inform you if the registry change it is trying to make fails; you should verify by exiting and returning to the dialog to make certain that your change is still shown, or better yet by simply checking the value in the registry.

As Microsoft points out, the ease with which this can be changed is not particularly comforting from a security point of view:

A major concern with [using a dual-interface Windows NT machine with routing turned off as a firewall] is that the separation between the Internet and your intranet depends on a single option in the TCP/IP configuration (or in the associated Registry entry)... An individual familiar with Windows NT configuration tools and administrative permissions can find and change the Router check box in a matter of minutes.

-- Microsoft Windows NT Resource Kit Internet Guide, Chapter 3

This is a major understatement on their part; an individual who actually remembers where to find it ought to be able to change it in well under a minute. In order to slow down an attacker, and also decrease your chances of accidentally reenabling IP forwarding yourself, set the permissions on the Parameters key so that Administrator has the same Special Access rights that Everyone has (Query Value, Create Subkey, Enumerate Subkeys, Notify, and Read Control) and additionally has Write DAC (so that if you want to change things later you can).[25] Note that this will create one situation in which TCP/IP Properties appears to work, but your changes silently disappear; in this situation, this is not necessarily a bad thing.

[25]If Everyone has Full Access permissions, you have failed to install current service packs on the machine. You are likely to have severe security problems.

12.4. Disabling Nonrequired Services

12.4.1. How Are Services Managed Under Windows NT?

12.4.1.1. Registry keys

12.4.1.2. Other ways to start programs under Windows NT

12.4.2. How to Disable Services Under Windows NT

12.4.3. Next Steps After Disabling Services

12.4.4. Which Services Should You Leave Enabled?

12.4.5. Specific Windows NT Services to Disable

12.4.5.1. The Services control panel

12.4.6. Turning Off Routing