Understanding Windows Service Hardening

Windows Service Hardening (WSH) is a feature of Windows Vista and later versions that is designed to protect critical network services running on a system If a service is compromised, WSH reduces the potential damage that can occur by reducing the attack surface that could be potentially exploited by some forms of malicious code . Because network services (both those built into the operating system and those installed by third-party applications) are by their nature exposed to the network (which itself is usually connected to the Internet), they provide a vector by which attackers can try to compromise a system. WSH implements the following protection improvements over previous versions of Windows:

■ Configuring services to run whenever possible within the lower-privileged LocalService or NetworkService context instead of the LocalSystem context favored by many services in previous versions of Windows .

■ Implementing a new type of per-service security identifier (service SID) that extends the Windows access control model to services and the system resources they access. When a service is started by the Service Control Manager (SCM), the SID is added to the secondary SIDs list of the process token if the service opted for doing this .

■ Applying a write-restricted access token to the process for each service so that any attempt to access a system resource that does not have an explicit allow access control entry (ACE) for the service SID will fail.

■ Tightening control over the generic SvcHost . exe grouping and distribution of services .

■ Reducing the number of privileges assigned to services to only those needed by the service

Understanding Service SIDs

Service SIDs are of the form S-1-5-80-{SHA1 hash of short service name} and complement the existing set of user, group, machine, and special SIDs used by previous versions of Windows. Service SIDs are secondary SIDs that are added to the SIDs list of the service process token when the SCM starts the service. The primary SID for a service is the built-in identity (LocalService, NetworkService, or LocalSystem) under which the service runs.

To have a service SID added to its token, the service must first opt in to doing so . Opt in is normally done by the operating system or application when the service is started. Administrators can manually opt in user-mode services by using the sc sidtype command, which can configure the service SID as either RESTRICTED, UNRESTRICTED, or NONE. For example, sc sidtype service_name restricted will add the service SID for the service to its service process token and also make it a write-restricted token. This means, for example, that any registry key used by the service must be explicitly assigned permissions to allow the service to access it . On the other hand, sc sidtype service_name unrestricted adds the SID of the service so that access check operations requesting that SID on the service token will succeed. Finally, sc sidtype service_name none does not include any SID in the token . For more information, type sc sidtype ? at a command prompt.

NOTE To query the SID type of a service, you can use the sc qsidtype command.

Some services in Windows Vista and later versions ship out of box as UNRESTRICTED, and most services will fail to start if changed to RESTRICTED . Third-party applications, such as antivirus software, can be designed to opt in to having service SIDs and can be designed to run either RESTRICTED or UNRESTRICTED . If the local administrator changes an existing service SID type from NONE to UNRESTRICTED, she gets the service having SID type with probably zero regression or issues with this service . (A SID type of UNRESTRICTED is sufficient for network traffic filtering.)

NOTE The service SIDs of all the configured services per process are always present in the process. Only the running services have their SIDs enabled; the SIDS of non-running services are there, but in a disabled state. However, the filtering platform considers all SIDs to be activated, regardless of whether the service is in a disabled state.

Windows Firewall and WSH

You can use service SIDs to restrict ways that services can interact with system objects, the file system, the registry, and events. For example, by changing the permissions of the firewall driver object using the Windows Firewall service SID, this driver will accept communication only from the Windows Firewall service .

WSH also protects services by using rules similar to those used by Windows Firewall. These rules are called service restriction rules, and they are built into Windows and can specify things such as which ports the service should listen on or which ports the service should send data over. An example of a built-in WSH rule might be "The DNS client service should send data only over port UDP/53 and should never listen on any port." These rules add additional protection to network services because network objects, such as ports, do not support ACLs . ISVs can extend this protection to third-party services they develop by using the public Component Object Model (COM) APIs for WSH found at http://msdn.microsoft.com/en-us/library /aa365489.aspx. However, WSH rules don't actually allow traffic (assuming Windows Firewall is turned on); instead, they define the restricted traffic that can be allowed to/from a service, regardless of the administrator-created firewall rules . WSH rules are thus a sandbox for the service.

WSH rules are also merged into the filtering process performed when Windows Firewall with Advanced Security decides whether to pass or drop a packet. In other words, when making decisions about traffic destined to or originating from services, Windows Firewall rules and WSH rules work closely together to decide whether to allow or drop traffic . For more information on how service restriction rules merge with Windows Firewall rules, see the section titled "Understanding Windows Firewall Policy Storage and Rule Merge Logic" later in this chapter

NOTE An assumption behind WSH is that the services being protected are running under either the NetworkService or LocalService accounts. Services running under the LocalSystem account are omnipotent. In other words, they can turn off Windows Firewall with Advanced Security or ignore its rules; and therefore, they are not protected.

Was this article helpful?

0 0
The Ultimate Computer Repair Guide

The Ultimate Computer Repair Guide

Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.

Get My Free Ebook


Responses

  • jenson munro
    How to harden windows 7?
    3 years ago

Post a comment