Checklist: Top four Windows services to disable -- maybe

The decision to disable some services often depends on whether or not your security needs outweigh your business needs. This checklist identifies four services to disable -- maybe.

A reader wondered if I would consider remote registry services a candidate for disablement, or disablement "at times." I'm really glad he asked that question because disabling services is often an "it-depends" decision, making the need for various services controversial. I hate to appear wishy-washy but here are four services you should disable -- maybe.

CAUTION: As with any recommended change to computer settings, don't implement this advice on production machines...

without testing changes first in a test network. To properly deploy you must understand what you hope to accomplish and the possible consequences. Never blindly follow advice.

You may download a printer-friendly version.

 Checklist: Top four Windows services to disable -- maybe
Disable Remote Registry -- maybe
Remote Registry enables remote users to modify registry settings on a computer. If it is disabled, only locally logged on users can modify the registry. Use of these services does not eliminate the requirement that users be authorized to edit the registry. Permissions are configured on registry keys and if you don't have permission you're not going to edit them regardless of where you are logged on. Nevertheless, you really don't want to take chances when it comes to the registry.

Disabling this service used to be high on Windows security hardening lists. It's less often mentioned now because disabling it prevents many remote administration tools from working. For example, Microsoft Security Baseline Analyzer cannot successfully scan a computer if this service is not running.

However, I have to agree, in many environments, the security benefits of auditing vulnerabilities and patching remote clients in an automatic and easy fashion far outweigh the risk of unauthorized users gaining access to remote computer registries. While that access might happen, it's almost certain that an unpatched system will be compromised by any number of worms and viruses. Still, highly critical and sensitive systems will benefit from removing any potential risk, and they are often managed using tools that do not require this service. You'll have to determine your exposure here, based on the nature of your network and data, as well as your ability to otherwise perform administrative tasks.

Disable Automatic Updates -- maybe
Automatic Updates is required to allow Windows systems to contact Microsoft, check if relevant updates exist, download and install them. Automatic updates can also be driven by a local network system update server or by a third-party patching product. While all of this seems great (Who wouldn't want an easy way to keep systems patched?), there are times when leaving this service enabled is less than desirable. Do you want, for example, the thousands of Windows systems on your network individually connecting to Microsoft, downloading and installing patches before you've tested the patches? Increasing the utilization of network and Internet bandwidth has never been a desirable outcome. Put the correct solution for your network in place and, if warranted, disable Automatic Updates.
Disable Secondary Logon (also known as "Run As") -- maybe
Secondary Logon (a.k.a. RunAs) is a cool way for administrators to do ordinary work (e-mail, Word, Excel) as ordinary users, yet perform administrative tasks without logging off and then back on again. You'll often find me singing its praises and the need for this type of service. It makes the list of controversial services, however, because of the way some third-party applications work.

I'm talking about software that supports biometric authentication instead of passwords. Some of these products can be bypassed by using RunAs: The user password is retained and stored, and if you are able to log on to the system, you can elevate your privileges to administrator using RunAs and an administrative account and password. Products that allow this activity may or may not advise you to disable RunAs.

If you are evaluating alternatives to the password, do take the time to actually test them and what happens when using RunAs. Do pay attention to vendor documentation. After all, the benefits of using the more secure authentication device may outweigh the hassle of disabling this secondary logon service.

Disable Print Spooler -- maybe
Print Spooler is required if the server will be a print server. Most servers are not, in fact, most servers are not even used to send print jobs to a print server. How come the service is enabled by default? If Print Spooler is running, it may be possible to create a denial-of-service attack by sending lots of very large print jobs its way. Prevent this annoying possibility and reduce server attack surface (the potential for vulnerabilities) by disabling this service on all servers that are not print servers.

Roberta Bragg
Roberta is author of "Hardening Windows systems" and a resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker.

Click to ask Roberta a question or purchase her book here. Also, if you have specific questions or comments about any of Roberta's checklists, click to e-mail her directly. Copyright 2004

Dig Deeper on Enterprise desktop management