0672319659
Chapter 7: Windows 2000 Services
In Windows 2000, a service is essentially a program that runs at startup independent of any user. Most of the functions a server performs, such as file sharing, are run as services. Most services run with SYSTEM privileges. SYSTEM is a special account that the operating system uses to perform priveledged operations on the system. Most services are started before any user logs in to the system. Running in the background, services normally do not allow user interaction, and most of their communication with the user is through entries in the event log.
Services have their benefits and their disadvantages. The benefits are clear:
Services do not require a user to log in at the console to begin execution.
Services run independent of any user logged in to the console.
Services have sufficient privileges to perform any system operations.
Services can be configured to run at startup and automatically restart if they fail.
However, consider the disadvantages:
Because most services have SYSTEM privileges, exploiting a service often results in obtaining SYSTEM privileges.
Because services do not interact with the desktop, a user sitting at the console is normally not aware if a service is started.
Services can be confusing, and it is not always clear if a service should be running.
In this chapter, we will discuss some service strategies and review the security ramifications of each Windows 2000 service.
Understanding How Services Work
Because services run independently of the user, they are controlled by a process named the Service Control Manager (SCM). The SCM knows about all services installed on a system and which ones are currently running. It also makes sure that autostart services are run at startup, and it handles user requests to start and stop services.
When Windows 2000 is started, the SCM determines which services must be started, and it logs each one in to the system to obtain a security token. Although most services will log in as SYSTEM, a service can be set to log in as any locally authorized user provided the user account has the Log on as a Service right assigned to them in the Domain Security Policy MMC Snap-in found under the Administrate Tools. Assigning a user account to run the service can be accomplished by using the Services MMC Snap-in found under the Administrative Tools. By selecting a service and viewing its properties, an administrator can set the user account the service runs under, as shown in Figure 7.1. By default, every service that comes with Windows 2000 is automatically installed to run as SYSTEM. Normally, when it comes to security, you run an application with least privilege. That means that only the minimal set of privileges required to accomplish the task should be assigned. However, SYSTEM is an account with full access to everything, so giving every service that kind of access clearly breaks the rule of least privilege.
){kind=link}
The alternative is to spend the time to create service accounts that have lesser privileges and set each service to use those accounts. However, because creating and managing those accounts is a headache that most administrators would rather not deal with, permissions are rarely changed from the default. Furthermore, it is difficult to know if reducing a service's permissions will cause the service to stop functioning, and most administrators do not have the time to research each individual service.
Figure 7.1 Services can be set to log in as local system or a specified account.
To add to this problem, auditing the SYSTEM account yields countless event log entries and does not allow you to distinguish between the activities of different services.
Rather than going through the trouble of giving each service its own logon and experimenting with the rights of each, we control services in other ways. We make sure that only administrators can start services, remove unsafe services, and make sure that the SYSTEM account cannot access certain files, such as cmd.exe. Sure, there is a certain amount of exposure by running services as SYSTEM, but with some things, the amount of work does not warrant the returned benefit.