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 tutorial.

Note A n 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.