Software Restriction Policies

Our second favorite "tweak" is also not a tweak. It is technology used to prevent, or allow, software to execute on the system. Software restriction policies (SRPs) can be used, for example, to prevent any account from executing certain files even when those files cannot be removed. We used the tftp.exe tool to upload the attack tools to a compromised server. You cannot delete tftp.exe unless you disable system file protection. However, you can set up an SRP that prevents attackers from executing tftp.exe. Software restriction policies can identify the file four different ways:

• By Internet Explorer security zone
• By full or relative path
• By a certificate used to sign the files
• By a hash

SRP that is quite restrictive. It consists of the following rules:

• All files underneath the %systemroot% directory can execute (a path rule).
• All files underneath the %systemroot%\system32 directory can execute (a path rule).
• Certain chosen files underneath the %systemroot% directory are restricted (a path rule).
• Certain chosen files underneath the %systemroot% directory are restricted (a hash rule).

In addition, the default security level is set to Disallowed, meaning only those files explicitly listed can be executed. With this policy set, the system will boot and you can log on. However, many of the Start menu items are blocked because they are located under \Documents and Settings and that location is blocked. For instance, you cannot launch the command prompt from the Start menu, but you can do it from the Run dialog.

SRP applies in order of specificity. Because the %systemroot% rule is more specific than the blanket rule, it takes precedence. Because a hash rule is always more restrictive than a path rule, the hash rules take precedence. Note, however, that a hash rule is specific to a particular version of a file. If the file is updated to a newer version, the hash rule is no longer valid. Hence, we also have a path rule to restrict these files, just in case we forget to update the hash rule.

A full discussion of how to use these options is quite lengthy, and the interested reader is referred to the Security Resource Kit, by Smith and Komar, MS Press, 2002, which has a lengthy discussion on SRP. The Windows XP Security Guide also has a discussion on SRP.

Of course, ideally, you should set up an SRP that allows execution only of those files that are necessary for operating the server, but doing so is quite complicated. Windows binaries are not signed directly, and therefore a certificate rule would not be valid. (Windows binaries do have an associated digital signature, but it is not attached to the file; it is stored in the manifest, called nt5.cat.) Thus the simplest approach is the one we used above where everything is restricted and particular things are allowed using a combination of hash and path rules.

What breaks? The simple answer is potentially everything, but hopefully nothing. SRP, correctly used, will ensure that the system can perform its intended function and absolutely nothing else. SRP, incorrectly used, will turn your system into a boat anchor. SRP is another setting you should never roll out on a production network until you are 100 percent certain that the systems will not break. Virtual machines are absolutely wonderful for developing and troubleshooting software restriction policies because you just reboot and discard the undo file should the system not function properly.