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, 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.
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.[1] "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.
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\Parametersor
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.
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:
A list of service groups that this service depends on. This is relatively rarely set. The main group of interest for networking purposes is "TDI", which is the group that contains base network interface drivers.
A list of services that this service depends on. A service that depends on LanmanServer is almost certainly a network server. Services that depend on LanmanWorkstation are probably not network servers but are clients. Services that depend on one of the other networking groups (NetDDE, TCPIP, NetBT, or AppleTalk, for instance) may be either servers or clients, but your suspicions should be aroused.
This is the name shown in the Services or Devices control panel.
This shows what to do if this service won't run. Check here before you disable the service! If this is set to 0x02 or 0x03, and you disable the service, the machine will reenable it by restoring the previous configuration. If that doesn't work, at 0x03, it will refuse to boot. Possible values are shown here.
Value | Meaning |
|---|---|
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. |
This is the group name that is used in DependOnGroup. Anything in TDI or Network is networking related.
This is the location of the executable, which tells you what to remove or rename if you want to be sure that the service cannot be easily reenabled.
This is actually the name of the account that the service runs under, if it runs as an independent process. Almost all services run as LocalSystem (which is the most privileged account on the system). In order to run as any other user, the service needs to provide a password for the user, which is stored separately, in the Secrets section of the registry. If the service is a kernel driver, this specifies which kernel object will load it.
This indicates whether or not it is a Plug and Play service, and if so, what kind. Normally, network services are not Plug and Play.
This key indicates when the service should be started. Possible variables are as follows.
Value | Meaning |
|---|---|
0x00 | Boot |
0x01 | System |
0x02 | Autoload |
0x03 | On demand |
0x04 | Disabled (filesystem drivers will load anyway) |
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.
As we discussed in Chapter 10, 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, 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.
You will need to reboot the machine after you change the service configuration. When it has been rebooted, you should check to make certain that the services are actually off and that the machine is still functional. One way to check that a service is turned off is to use the netstat utility to list the network ports the machine is listening on.
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.
If you feel uncertain about removing executables, consider encrypting them instead. Use an encryption program that has a stable implementation of a standard algorithm, like Network Associates' version of PGP (see Appendix B, for information about how to get this package).
Certain services are essential to the operation of the machine, and you'll probably need to leave these enabled, no matter what else the machine is configured to do. On a Windows NT system, nothing in the Services tab of the Networking control panel is actually required for basic functionality. In the Services control panel, the critical services include:
This is what puts things in the event log, even for local programs.
This is required if the machine will be running services that need to authenticate users (for instance, FTP or HTTP servers).
This is part of the encrypted filesystem support and should be left enabled.
Many servers use loopback RPC calls and will not work if RPC is not available.
In some circumstances you will also need these services:
This is required if you're using IPsec to secure network connections.
This is required if the machine will be authenticating accounts for other machines or from other machines (for instance, if it's a member server in a domain or a primary domain server for a domain that contains other servers). A bastion host should use only local accounts, in which case this service is not required.
This is either pointless or critical, depending on your hardware configuration. It is not network-accessible in either case. Note that it is even required for correct functioning of peripherals on some server configurations that have no hot-swappable components.
This is required if you have a smart card reader and want to use it for authentication; it depends on Plug and Play.
This is needed for printing (even local printing) to work. You can remove it if you are not going to print.
In addition, you'll obviously need server processes for the services that you've decided to provide on your bastion host (e.g., real or proxy Telnet, FTP, SMTP, and DNS servers).
As discussed earlier, there are three separate places where you can disable services for Windows NT:
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.
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:
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'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.)
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.
This provides networking either over phone lines or via PPTP (which is discussed further in Chapter 14). It should not be installed unless the machine will provide or use dial-up networking or virtual private networking services.
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.
This package consists of echo, chargen, discard, daytime, and quotd, which are discussed further in Chapter 22. 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 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.
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.
As we discussed in Chapter 10, 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).[2] 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.
[1] 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.
[2] 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.