Because services run unattended at startup, they are well suited to server-type applications such as Web services. However, this characteristic has its drawbacks because a user can be unaware that a service is running. Although some services might open a window or dialog box that is visible to the user, little or no user interaction typically occurs with services, so a user can run a number of default services and never be aware of the potential security risks. Recent Internet worms such as Nimda exploit the fact that users can unknowingly run Web servers on their workstations. The infected workstations spread the worm to thousands of computers across the Internet.

Some services, particularly those used by enterprise management tools such as Microsoft® Systems Management Server, Microsoft Operations Manager, and Tivoli, need to log on using a domain user account because they typically require access across the entire domain and possibly to other trusted domains as well. In other scenarios, using a domain user account to run services was once standard practice, but recently organizations have recognized it as a security risk.

The user name and password information for each service that uses a domain or local user account is stored in the registry, which an attacker can exploit when he or she gains administrative access to the computer. As a result, security exposure occurs whenever you configure a service to log on as a user.

Because a security exposure is created whenever a service is configured to log on as a domain user account, the potential to exploit this vulnerability increases based on various factors, including:

• Number of servers on which a given domain user account is configured to run services. In a well-managed server environment, all servers should be equally secure. If an organization does not secure all its servers equally, the potential for exploit increases with each poorly secured server. The more servers on which the domain-authenticated service runs, the more opportunities exist for someone to exploit the security vulnerability. For example, one service might use the same domain account to authenticate itself on hundreds or thousands of servers within an organization. Therefore, if an attacker compromises one of these servers and steals the user name and password used by the service, the attacker can gain access to all other servers that run the service.
• Scope of network privileges for any domain user account configured to run a service. The larger the scope of privilege, the greater the number of resources at risk. Domain administrator accounts are high risk, because the scope of the vulnerability to the network is all the computers residing in the domain, including domain controllers. Additionally, if this domain user account has local administrator privileges on one or more other servers, the potential for repeated exploitation of the security vulnerability exists.
  It is especially important to protect the network resources that administrator-level accounts access, because domain administrator credentials create transitive vulnerabilities and opportunities for escalation across the domain. These credentials are typically used for interactive or remote logons on all computers in the domain; therefore, when the credentials are compromised, all computers in the domain are vulnerable to attack.

Several different scenarios of service vulnerability exist, each with different levels of security risk. These scenarios are described in the following figure and the following table. All accounts in the following figure are assumed to be domain accounts. Each account is running at least one service on one of the servers.

Descriptions of domain accounts in the diagram:

• Account A has Administrator-equivalent privileges to more than one domain controller.
• Accounts A, B, C, and D have Administrator-equivalent privileges on more than one member server.
• Account E has Administrator-equivalent privileges on only a single member server.

The priority levels used in the following table are:

• Critical risk level. The scenario immediately jeopardizes corporate security.
• High risk level. The scenario compromises corporate security, but security is not immediately jeopardized.
• Medium risk level. The scenario is important, but security exposure does not involve a high security server.
• Low risk level. If you eliminate the scenario, it has little effect on security goals.

The following table provides a detailed description of the service vulnerability scenarios and their subsequent vulnerability priority levels. Table 2.1: Security Vulnerability Scenarios

Services are prime vulnerability points for attackers to access the local server or other servers on the network. If you do not need to use a particular service, you should disable it. By disabling unnecessary services, you quickly and easily reduce the attack surface, and gain additional performance benefits by not running these superfluous services.

To protect a service successfully, you must be aware of its vulnerabilities and minimize the service's exposure to them.

A service must log on as an account to access resources and objects on the operating system. If you assign an account to a service that does not have appropriate permissions to log on, the Services snap-in for the Microsoft Management Console (MMC) automatically grants that account the required Log on as a Service user right on the computer being managed. Microsoft Windows Server™ 2003 includes the following three built-in local accounts used as the logon accounts for various system services:

• Local System account
  The Local System account is a predefined local account that can start a service and provide the security context for that service. It is a powerful account that has full access to the computer, including the directory service when used for services running on domain controllers. The account acts as the host computer account on the network and as such has access to network resources just like any other domain account. On the network, this account appears as DOMAIN\<machine name>$. If a service logs on using the Local System account on a domain controller, it has Local System access on the domain controller itself, which, if compromised, could allow malicious users to change anything in the domain they wanted. Windows Server 2003 configures some services to log on as the Local System account by default. The actual name of the account is NT AUTHORITY\System, and it does not have a password that an administrator needs to manage.
• Local Service account
  The Local Service account is a special built-in account that has reduced privileges similar to an authenticated local user account. This limited access helps safeguard the computer if an attacker compromises individual services or processes. A service that runs as the Local Service account accesses network resources as a null session; that is, it uses anonymous credentials. The actual name of the account is NT AUTHORITY\LocalService, and it does not have a password that an administrator needs to manage.
• Network Service account
  The Network Service account is a special built-in account that has reduced privileges similar to an authenticated user account. This limited access helps safeguard the computer if an attacker compromises individual services or processes. A service that runs as the Network Service account accesses network resources using the credentials of the computer account in the same manner as a Local System service does. The actual name of the account is NT AUTHORITY\NetworkService, and it does not have a password that an administrator needs to manage.

Important: If you change the default service settings, you might prevent key services from running correctly. It is especially important to use caution when you change the Startup type and Log on as settings for services that are set to start automatically by default.

Several categories of user accounts can log on as a service. Each category has its own capabilities and privileges:

• Local User accounts
  This category contains the accounts that you create locally on a computer, for example, with the Local Users and Groups management console. These accounts have very limited privileges on the local computer unless you specifically grant them higher privileges or add them to groups that already possess those privileges.
• Local Administrator accounts
  This category includes the built-in Administrator account that you create and use when you first install Windows Server 2003 or Microsoft Windows® XP on the computer. It includes any other user accounts that you subsequently create and add to the built-in Administrators group. Members of this group have full and unrestricted access to the local computer.
• Domain User accounts
  This category includes accounts that you create in the domain, for example, by using the Active Directory® Users and Computers management console. These accounts have limited privileges in the domain unless you specifically grant them higher privileges or add them to groups that already possess those privileges.
• Domain Administrator accounts
  This category includes the built-in domain Administrator account that you create and use when you first install Active Directory. It includes any other user accounts that you subsequently create and add to the built-in local Administrators group or to the Domain Admins or Enterprise Admins groups. Members of these groups have complete and unrestricted access to the domain and, in the case of the Enterprise Admins group, to the entire forest.

With versions of Windows released prior to Windows XP and Windows Server 2003, almost all services included with the operating system used the Local System account by default. Programs that run in this context have unlimited privileges on the local computer,which presents an obvious security risk. With the release of Windows Server 2003, the developers changed the default settings to make the environment more secure. One of these changes is that a smaller number of services now run under the Local System account by default. Instead of using the Local System account, many common services now use the Local Service or Network Service account. These accounts have a much lower level of privileges than the Local System account and, therefore, present a lower security threat.

Many services still log on as the Local System, including Automatic Updates, Computer Browser, Messenger, and the Windows Installer service. Others do not. For example, the Alerter service used the Local System account in Windows 2000 but uses the Local Service account in Windows Server 2003.The DNS Client used the Local System account in Windows 2000 but uses the Network Service account in Windows Server 2003. The following table lists the services that no longer use the Local System account in Windows Server 2003, and lists which service account they now use.

Caution: Do not attempt to change the accounts that services provided with the Windows Server 2003 operating system use, because doing so can cause serious problems and potentially stop important services from running successfully. For example, the DNS Client service uses the Network Service account because the DNS Client service must access network resources such as DNS servers. This service does not work with the Local Service account or any other account that cannot authenticate to network resources.

Table 2.2: New Service Account Settings in Windows Server 2003

The path to success in service security includes understanding the nature of the services available in the networked environment and establishing procedures to protect the use of them. This section examines three core principles that you should follow when you plan to run services securely:

• Know your system
• Use the principle of least privilege
• Use the principle of least service
  
  If you can successfully incorporate these principles into your IT security procedures, they will help you attain an appropriate level of service security.

Although this recommendation seems obvious, many organizations are not fully aware of the roles and services that run on all their computers.

To know whether your computers are secure or not, you must know the services that run on your computers and their properties. This information is critical to help keep your servers secure. Consider the value of a table of services and service property settings for services that run on your computers, so that you can immediately evaluate your risks. To create such a table can initially be a long and complex process, but it is well worth the effort because it is vitally important to understand the properties of a known good configuration for your different server roles.

Several tools can help you create a list of service properties and running services. These tools include:

• Service Controller Tool (sc.exe). This command-line tool is included with Windows Server 2003 and Windows XP. It provides a way to communicate with the Service Control Manager component from the command line to query and set service properties.
• Windows Management Instrumentation (WMI). This is a preinstalled component of the Windows Server 2003 and Windows XP operating systems that provides management information and control in an enterprise environment. By using industry standards, systems management administrators can use WMI to query and set information on desktop computers, applications, networks, and other enterprise components. Several management tools are WMI-enabled, including System Information, and the Dependencies component of the Services console. Service dependencies identify the services upon which the current service is dependent and the services that are dependent upon it. System administrators can also use WMI scripts to automate administration tasks.
• Windows Management Instrumentation command line (WMIC). WMI includes a command-line tool, WMIC, that provides a simple command-line interface to WMI to query and remotely manage computers that run Windows operating systems. You invoke WMIC by typing wmic at a command prompt. For example, to retrieve services information for a server called Server1, type the following at a command prompt:
  wmic /output:c:\services.htm /node:server1 service list full / format:htable
  Use Microsoft Internet Explorer to examine the resulting c:\services.htm file formatted as a Hypertext Markup Language (HTML) table. If your server name has spaces or special characters in it, include quotes around the name when you run the wmic command.
  
  

Note: There is another command-line tool available called sclist.exe, which is included in the Windows 2000 Server Resource Kit. This tool can show currently running services, stopped services, or all services on both local and remote computers. Sclist.exe can identify services that run on a physically remote computer or a computer that does not have a monitor attached, such as in a server rack.

Most security-related training courses and documentation discuss implementing the principle of least privilege. This principle is simple, but the impact of its implementation greatly increases security and reduces risk. The principle of least privilege states that you give an entity the least amount of access it requires to do its job and nothing more. In Windows Server 2003, this principle applies to both user accounts and computer accounts because in Active Directory, both user accounts and computer accounts are security principals, which means that they can both be assigned permissions and privileges.

One reason this principle works so well is that it forces you to assess your network resources and potential security risks. You must learn the access privileges that are actually needed for a given computer or user and then verify that only the required privileges are applied.

Running services more securely requires organizations to deploy services using a least privilege approach. Whenever possible, run services as the Local Service account, so that the account can only gain access to a single computer and not to the entire domain. Services that require authenticated network access might need to use the Network Service account, and you should deploy services that require broader implementation as the Local System account. If you determine that a domain-level administrator account is required to deploy a service, you should treat the server on which you deploy it as a high security server and protect it with the same measures you use for other highly sensitive network resources such as domain controllers. For more information about this topic, see the Create a High Security Servers Group for Domain Administrator Exceptions section in Chapter 3, “How to Run Services More Securely.”

Microsoft has thoroughly tested Windows Server 2003 to ensure that the core operating system services already run under the least privileged account; therefore, you should not usually need to modify these services. Your focus should be to secure the services that are not part of the operating system, such as those supplied as a component of other server product offerings, for example, Microsoft SQL Server™, Microsoft Operations Manager, and services that third-party software manufacturers provide.

You can use Group Policy in Windows Server 2003 to control specific services that can run on a computer or computers. To do this, open the Group Policy object for the organizational unit that contains the computer that you want to configure. Browse to the Computer Configuration\Windows Settings\Security Settings\System Services node and open the Properties page for the service that you want to control. In the Properties dialog box, define the service startup mode (Automatic, Manual, or Disabled) and set security permissions that control which user accounts can carry out particular operations on that service, such as stopping or starting the service.

For more information about what to consider when you decide which account type to use to run a service, see Figure 3.1, “Least Privilege Hierarchy for Service Deployment,” in Chapter 3, “How to Run Services More Securely.”

When you implement the principle of least privilege across your computers, it works in combination with the rule of knowing your system. How do you know if your computers run the minimal number of services if you do not know which services are actually running? By combining these two principles, your administrative staff can assess which services are running on a computer, their status, and the credentials that are in use for each server — then methodically change every possible service to the least privilege necessary. Monitor the computers to make sure no new services can be added without going through proper change-control procedures.

The principle of least service states that the operating system and the network protocols available on any networked device should run only the exact services and protocols required to support the business purpose. For example, if a server is not required to host any Web applications, you should remove or disable the World Wide Web service. Most operating systems and programs install many more services and protocols in their default configuration than are actually required for common usage scenarios.

The best way to set up a new server is to include a step in which the system administrator shuts down all but the bare necessities of the operating system. For example, in Windows operating systems prior to Windows Server 2003, it was common practice to close down the Alerter and Messenger services. In addition, ensure the correct placement of services on the network. For example, you should not place the Routing and Remote Access Service or Internet Information Services (IIS) on a domain controller because they run background services that can increase vulnerability on the domain controller. Microsoft best practice recommends that no additional services, other than those required to operate successfully as a domain controller should be run on a domain controller.

Using the approaches and principles discussed in the previous chapters of this guide, this chapter describes the tasks you must perform when planning to run services more securely.

To secure services, you should carry out the following tasks:

• Audit all servers to determine essential service properties.
• Determine which services actually need to run.
• Identify and eliminate all domain administrator accounts for services.
• Use a least-privilege hierarchy for service deployment.
• Create a high security servers group for domain administrator exceptions.
• Manage service account password changes.
• Enforce strong passwords.
• Automate testing for weak administrator passwords.

You must determine exactly how many servers exist within your organization. Although this task sounds simple, a large organization can find it surprisingly complex to identify every server it possesses and to determine to what degree the services on each computer require management. For example, computers that run in the perimeter network require significantly higher levels of service management to reduce the attack surface of these computers.

You should audit each server to list all the running services and record which logon credentials each service uses for authentication. You can use the following tools to help with this task:

• System Information in Microsoft® Windows Server™ 2003. You can use System Information to view a comprehensive list of the properties of all the services of the local computer or other remote computers. However, this method is not scalable to situations in which you need to audit large numbers of servers. To access this tool, click Start, point to All Programs, point to Accessories, point to System Tools, and then click System Information.
• Services management console. In the Services administration console, you can use the Log On tab of a service's properties page to find which account the service uses to log on for authentication purposes. You can also use the Dependencies tab to view the services upon which the current service depends and which services depend upon it. Dependency data is essential information to gather when you audit servers. This method, however, is not scalable to situations in which you need to audit large numbers of servers.
• Windows Management Instrumentation (WMI). Use WMI to obtain information about the services that run on all your servers. You can use WMI with programming tools or script utilities, such as Windows Scripting Host, to retrieve configuration details about most aspects of your computers or to make changes to your computers. Several management tools are WMI-enabled, such as System Properties, System Information, and the Dependencies component of Services. Service dependencies identify the services upon which the current service depends and the services that depend upon it.
• Windows Management Instrumentation command line (WMIC). WMI provides a simple command-line tool interface to WMI to manage remote computers that run Windows operating systems. WMIC interoperates with existing shells and utility commands, and you can easily extend it with scripts or other administration-oriented applications.
  For example, you can use the wmic service get command to obtain information about all properties for a specified service including its:
  
  • Description
  • DisplayName
  • ErrorControl
  • InstallDate
  • PathName
  • ProcessId
  • StartMode
  • StartName
  • Status

Example syntax: SERVICE GET Name,DisplayName,ProcessId,Started,StartMode, StartName

You can use the wmic service list brief command to retrieve a list of basic properties of all services installed as follows:

• ExitCode
• Name
• ProcessId
• StartMode
• State
• Status

You can use WMIC from any computer that has WMIC installed to manage any remote computer that runs WMI. The target computer does not need to have WMIC installed or running for WMIC to manage it remotely. To manage a computer remotely, you need to use the /node:<computername> command, which requests the computer to add to the list of nodes from which you want to retrieve information.

Example syntax: WMIC /NODE:Server1,Server2,Server3 SERVICE GET Name,DisplayName,ProcessId,Started,StartMode,SystemName

You can also provide the location of a text file that lists remote computers on which you want use WMIC to perform actions.

Example syntax: WMIC /NODE:@“C:\MyServerList.txt” SERVICE LIST BRIEF

You can use WMIC to ease tasks in the following typical scenarios:

• Local management of a computer. You are at the computer and use the WMIC command to manage it.
• Remote management of a computer. You are at one computer and use WMIC to manage another computer.
• Remote management of multiple computers. You are at one computer and use WMIC to manage multiple computers with a single command.
• Remote management of a computer using a remote session. You use remote session technologies such as Telnet or Terminal Services to connect to a remote computer and manage it with WMIC.

• Automated management using administrative scripting. Several other management tools are available to help audit, including:
• Other enterprise management tools.
  • Microsoft Systems Management Server
  • Tivoli
  • OpenView
  • Lieberman Software Service Account Manager

Creating a master list of servers and their services helps to identify and remedy service-related security risks.

You can use your audit to create inventories of all services that use:

• A domain user account with domain administrator privileges.
• A single domain user account used on more than one server.