Securing Services

Tightening services means determining what services do and don't have to be running on a particular computer by determining its production role in the environment. High-security environments are easy to secure because you turn nearly every service off. Normal security environments are a bit tougher to secure because you must make security cost-benefit trade-offs.

High-Security Minimal Services

A high-security environment is one in which very little risk can be taken. An example is a public-facing web server or Internet bastion host supporting a security gateway or firewall. In these cases, every possible service that isn't needed can be disabled or removed.

The following services can be disabled on high-risk computers, if not needed: Application Layer Gateway Service, Application Management, ASP.NET State Service, Automatic Updates, Background Intelligent Transfer Service, Computer Browser, DHCP Client, Error Reporting, Help and Support, HTTP SSL, IPSec Services, Logical Disk Manager, Logical Disk Manager Administrative Service, Microsoft Software Shadow Copy Provider, Netlogon, Network Connections, Network Location Awareness, Performance Logs and Alerts, Portable Media Serial Number Service, Print Spooler, Remote Access Auto Connection Manager, Remote Access Connection Manager, Remote Desktop Help, Remote Registry, Removable Storage, Resultant Set of Policies, Smartcard, Special Administration Console Helper, Task Scheduler, Telephony, Terminal Services, Themes, Uninterruptible Power Supply, Upload Manager, Virtual Disk Service, Volume Shadow Copy, WMI Performance Adapter, and Workstation. If followed, a high-risk computing environment could potentially remove dozens of normally active or manually enabled services, significantly decreasing security risk in that environment.

Normal Security Environments

Which default services should be tightened in a normal security environment? Overall, Microsoft has done a good job in XP Pro and later. Most companies can leave the default settings and have a relatively good set of security on the default options. However, any service with LocalSystem access is potentially high risk, but turning them off often disables needed legitimate services. Sadly, some higher than normal risk services (e.g., RPC, Plug and Play, Server, Spooler, Workstation, etc.) are constantly exposed and constantly under attack. There isn't much we can do but keep patches up to date and try to prevent external malware from attacking internal computers.

Basic Recommendations

Table 7-5 describes which services could be disabled in most environments without large adverse effects. The main recommendation is to disable any service that is not being used for a legitimate production requirement. This always includes services such as Themes. Disable Wireless Zero Configuration if the computers do not use wireless. This advice even includes disabling legitimate services, which can have legitimate production value, if they are not used.

The basic recommendations made in Table 7-5 are tighter than you would find in most other guides. That's because most guides recommend keeping enabled services that you might not use but that don't currently have a demonstrated vulnerability against them. This book errs on the side of caution and assumes every service can be used in an exploit. If you don't need it, turn it off! Less attack surface equals less risk.

Make an enterprisewide list of what services are acceptable on your various servers and workstations. You should have different lists for different roles (i.e., file server, web server, etc.). Ensure that unnecessary services are disabled, or at least set to manual. If you are just beginning to harden your services, take baby steps. Turn off one service, or just a few, and reboot the computer a few times, running all your existing applications over a day or two to see whether any problems result. Carefully document any removed or disabled services by date. That way, if an application problem comes up in the future, you can use your disabled service list as a way to rule its involvement in or out.

Other Guides

Microsoft has excellent security guides for legacy, normal, and high-risk environments at www.microsoft.com/technet/security/prodtech/windowsserver2003.mspx and http://go.microsoft.com/fwlink/?linkid=15160. Many people used to go to the National Security Agency's (NSA) web site (http://www.nsa.gov) for Windows security advice. The NSA has approved Microsoft's default security templates, governing services recommendations, and the default templates for Windows XP Pro and Windows Server 2003.

The Center for Internet Security (www.cisecurity.org) has the best general-application Windows security guides available. Their CIS Benchmarking tools are available for Windows NT and later, Linux, FreeBSD, and Cisco routers (and more). What makes the tools great is that you can read the accompanying documentation to learn what is recommended and why, and then run a benchmarking tool to learn how your current environment differs. The CIS group has done an outstanding job!

Security Configuration Wizard

Windows Server 2003 Service Pack 1 came with the Security Configuration Wizard (www.microsoft.com/windowsserver2003/technologies/security/configwiz/default.mspx). It is an excellent tool for tightening Windows 2003 servers based upon the production role that they perform (i.e., file server, web server, Exchange server, etc.). The SCW conducts a series of interview like questions to ascertain what role(s) the server will be performing. It then leads the administrator through enabling or disabling various services (see Figure 7-7) based upon the roles chosen. SCW then makes a security template that can be applied (or rolled back) to the local server or any other computer that you wish. The resulting SCW file is an XML file that can be read or fed into other programs.

Figure 7-7

SCW is a great tool. Microsoft realized that most administrators don't have the time to become "services experts," so they automated the process as much as possible, although even the SCW tool doesn't automate the complete granularity of making a service-by-service decision. On hardened web servers and other high-security environments, I usually end up manually turning off more services than the SCW tool did. It's a great start though and one that I recommend on Windows Server 2003 SP1 and later computers. Future versions of Windows will continue to build on this excellent feature. For more information, see www.microsoft.com/windowsserver2003/technologies/security/configwiz/default.mspx.

How to Tighten Remaining Services

What about the services you can't uninstall or remove? Tightening services can be accomplished by disabling or removing unneeded services, using NTFS permissions to restrict the service, tightening the service account, and keeping patches up to date.

Disable or Remove Unneeded Services

If possible, uninstall or remove unneeded services. This is not always possible because Windows File Protection (WFP) will not allow you to remove, delete, or rename most default Windows services. Instead, mark the service with a Disabled Startup Type. Although a hacker or malware with admin access could potentially restart the service, disabling the service removes it from memory and prevents it from being used during an initial exploit. Remember that services marked Manual can often be started without much effort.

Use Permissions

Another excellent way to prevent unneeded services from launching is to use NTFS permissions. You can place Read-Deny or Read & Execute-Deny permissions on any service by researching its executable in the Services console or using Sc.exe. You can even use software restriction policies to prevent service image execution. This method will ensure that the service does not launch, although this hint is not easy to apply when one image file (e.g., Svchost.exe) is in charge of launching multiple services and you still need some of its services.

Instead, use the permissions available on each service in a GPO (see Figure 7-8). In every GPO you can define the Startup Type (i.e., Automatic, Disabled, or Manual) and push it down computers. This method is great when you need to turn off or enable a particular service across the enterprise in a short amount of time. GPOs also allow you to fine-tune permissions on the service object itself. You can give or take away various permissions that include deleting, starting, stopping, or pausing the service. I wish Microsoft allowed this inside of the Services console, but it doesn't.

Figure 7-8

You can also view and set Service permissions using two command-line utilities. And you can use Sc.exe to display (Sc sdshow) and set Service permissions (Sc sdset). See www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/.mspx for more details on Sc.exe. Unfortunately, setting permissions using Sc.exe requires knowledge and use of the hard-to-use Security Descriptor Definition Language (SDDL). See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/ace_strings.asp for details on SDDL. The command-line utility Subinacl.exe(www.microsoft.com/downloads/details.aspx?FamilyID=&displaylang=en) can also set Service permissions, and without having to know SDDL strings and syntax. Although you may have to download Subinacl.exe, while Sc.exe is frequently installed by default, the former is significantly easier to use and can be used to set permissions on files, folders, and registry keys, too.

Create a Custom Service Account

When possible, create and use custom service accounts. Most services, when they install, automatically install using the LocalSystem account as their host service account. If the service doesn't need full LocalSystem access, don't allow it. Instead, create a new service account and give it a name that is similar to regular users and doesn't stand out (e.g., Richard Collier). Give the service account the Logon as a service right (or let the Services console do it). Then give the service account identity the least amount of permissions and rights necessary to do its job.

Note 

Don't change the default service accounts or their passwords for any default Windows-installed service. Doing so could cause instability and result in technical support issues.

For example, most tape backup service accounts require an administrator-level account. In reality, all that most need is backup and restore rights and not Full Control-All permissions. The backup and restore rights (in group policy or local computer policy at Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignments\ Back up files and directories and Restore files and directories). Create a new service account and give it backup and restore rights instead of administrator.

Keep in mind that any custom service account stores its credentials locally, where they can be extracted by users with administrative-level access. This risk should be weighed against using a custom service account. But the practical reality is that if it requires admin access to exploit a custom service account, the intruder has admin access already and there are many things the intruder can do.

Determine Necessary Service Account Permissions

For other programs that you install, if it seems likely that the related service doesn't need administrator privileges or Full Control-Allow permissions to all files and folders, create a custom account instead. In most cases, all the service account needs is Modify access to its local files and folders, and Modify permissions to its related registry keys. To find out what permissions and access rights a service account needs, follow these instructions:

1. Temporarily make the service account a member of the Administrators group.

2. Configure the service to use the new custom service account.

3. Turn on Sysinternals' Filemon and Regmon utilities and filter for the service account's name and the services executable.

4. Turn on the service and let it do whatever it needs to do until you are satisfied it did all processes it was supposed to do (e.g., back up files).

5. Turn off Filemon and Regmon.

6. Analyze the results from the two monitoring utilities.

7. Apply the necessary permissions to the service account.

8. Remove the service account from the Administrators group.

9. Restart the service.

10. Monitor the computer and service for errors.

11. Check the event log for any errors.

Tighten the Service Account

Oftentimes you are stuck with using the default service accounts or allowing the service to use a highly privileged service account. Even though Microsoft attempted to tighten some services (see Table 7-3) by logging them on using the LocalService and NetworkService accounts, LocalSystem is used far too often. Nearly every service in Windows still logs on as LocalSystem. In most cases, these services need access only to the Windows and Windows\System32 directories and maybe to a few other locations. Giving LocalSystem to most services seems overkill. Unfortunately, I do not recommend changing any default Windows service to another logon type. Doing so might have some unforeseen impact, cause hereto unforeseen issues, and make your Windows computers harder to support. Instead, concentrate your service account tightening efforts on non-default services, particularly third-party services.

Use Strong Service Account Passwords

Even though you should not change passwords on the three default service accounts, be sure to create long (at least 15 characters) and complex passwords on your service accounts and change passwords more frequently than you do on your nonservice accounts. Consider using a script to automate service account password changes. Here's a link to an excellent article and script by Redmond Magazine and Don Jones to automate the process: http://redmondmag.com/features/article.asp?EditorialsID=398.

Lock the Service Account to the Local Computer

Consider tying the service account to just the local machine. Many administrators make the mistake of making a service account a domain administrator, when all the service account needs is local administrator rights to the local machine. If the latter requirement is true, lock the service account to the local machine. You can do so in Active Directory Users and Computers or User Manager, by choosing the service account object, choosing the Account tab, and selecting the Logon to button. There you can specify one or more NetBIOS or DNS computer names the account is allowed to log on to (see Figure 7-9).

Figure 7-9

This technique will ensure that if the service account is compromised by an intruder, they cannot start an island-hopping spree from one computer to the next target.

Keep Patches Updated

When some service buffer overflows happen, the best you can do is to wait for a vendor patch or use another third-party tool (e.g., firewall, IPS, etc.) to prevent the malicious code from reaching your vulnerable service. In most cases, vendors, like Microsoft, are relatively quick to provide a patch update when a common service is exploited. Keeping up on your patches will decrease your overall security risk. Of course, these days hackers are building service-attacking worms out the patches that vendors release. In August 2005, Microsoft released more than a handful of patch updates. Malicious coders reverse-engineered the patches and had exploit worms live on the Internet in less than three days, so just as important as keeping up on your patches is realizing that the window for applying a patch once it has been released is decreasing significantly.