Several years ago, I was visiting a relative at his office for a day. During my visit, one of my relative’s co-workers was showing off a popular off road driving game that he had just boot legged. Of course everyone in the office just had to have a copy. What no one in the office knew was that the game was infected with a rather nasty virus and the company’s anti virus software was very outdated. Within a couple of hours, no one in the office could boot Windows and no one knew why. Everyone assumed that it must have something to do with the game, but no one could figure out why uninstalling the game couldn’t fix the problem. It wasn’t until I download an up to date anti virus program that the real problem was revealed and ultimately solved.
Don’t get me wrong. I am in no way against computer games. I will be the first to admit that when I need a brain break I will fire up a copy of Microsoft Flight Simulator 2004 or play a little Tetris to get the juices flowing. What I am against is users being able to install software onto corporate machines. As the horror story that I just told illustrates, serious problems can arise when users install unauthorized software. Even if the game in question hadn’t carried a virus, the simple fact that it was a boot leg copy could have exposed the company to fines and other litigation related to software piracy.
As if that weren’t enough, the game consumed a ton of hard disk space and also decreased the available network bandwidth when users played against each other It is for these reasons why I believe that it is very important to maintain control of the software running on your workstations.
Hopefully, you have a security policy in place that prevents users from installing software on their workstations. What you might not realize though is that Windows XP offers an additional weapon against unauthorized software. This weapon is called a software restriction policy. Just as the name implies, a software restriction policy allows you to control what software a user is and is not allowed to run.
Creating a Software Restriction Policy
A software restriction policy is actually a group policy element that can be applied either to a domain controller or to a workstation running Windows XP. For the purposes of this article, I will show you how to implement a software restriction policy within Windows XP.
Begin by logging on as the Administrator and opening the Control Panel. Next, click the Performance and Maintenance link followed by the Administrative Tools link. When the Administrative Tools window opens, double click on the Local Security Policy icon. Now navigate through the console tree to Security Settings | Software Restriction Policies. There are two nodes beneath the Software Restriction Policies container; Security Levels and Additional Rules. The Security Levels container displays the various security levels that you can apply to a policy rule. As you can see in Figure A, the only available security levels are Allowed and Disallowed.
Figure A: You may either allow an application to run or you can disallow it
The Additional Rules container contains the actual software restriction policies. From here you will create the necessary rules and then assign an action of either allow or disallow to the rules that you create. For example, the rules that you see in Figure B are set up to catch instances of Gator. If an application matches one of the rules that I have established, the Disallow action will prevent the application from running.
Figure B: The Additional Rules container contains the actual software restriction policies
To create a new software restriction policy, right click on the Additional Rules container and then select the type of rule that you want to create from the resulting shortcut menu. There are four different types of rules to choose from and they are explained in the sections below.
Certificate rules identify applications based on the way that the application has been digitally signed. Windows looks at the application’s certificate and compares it to the various software restriction policies to determine whether or not the application is allowed to run.
What makes a certificate rule unique is that it can’t be used to restrict .EXE or .DLL files from executing. Certificate rules only apply to Windows Installer packages and to scripts that have been digitally signed.
The most effective way to use a certificate rule is to permit applications to automatically be trusted based on the application’s digital signature. For example, if someone were to attempt to install a new security patch, you probably wouldn’t want to stop them. One way of making sure that the user is able to install the necessary patch is to allow any Windows Installer package that has been digitally signed by Microsoft to execute.
Another type of software restriction policy that you can create is based on a hash rule. A hash rule uses either an MD5 or an SHA-1 hash to identify an application. There are advantages and disadvantages to using a hash rule. The biggest disadvantage is that you must have a copy of the file that you want to restrict before you can create the rule because creating the rule requires you to create a hash of the file. On a more positive note though, since the rule is hash based, it will be effective even if the user renames or moves the file because those events don’t change the file’s hash. However, if a new version of the application comes out or if the user does something to modify the executable file, the hash rule will no longer work.
Hash rules are the most effective when there is a specific application that you want to block. For example, suppose that everyone in your office was feeling a bit nostalgic and you started having problems with everyone loading Pac-Man onto their systems. You could create a hash of the file pacman.exe and then create a hash rule to block the file from executing.
Internet Zone Rules
An Internet Zone rule is similar to a certificate rule in that it can only be used to restrict Windows Installer packages. The difference between an Internet Zone rule and a Certificate Rule is that an Internet Zone rule is designed to prevent users from downloading and installing software.
At the time of the download, Internet Explorer looks to see what zone the download site falls into. Internet Explorer classifies any Web site visited into either being in the Internet, Local Intranet, Trusted Site, or Restricted Site zone. You can create a software restriction policy that allows files to be downloaded and run if they come from the local intranet or from a trusted site, but that won’t allow files from other locations to be executed.
A path rule is used to restrict files from running based on the file’s location within the file system. For example, if you knew that Pac-Man gets installed by default to C:\Program Files\Pac-Man, you could restrict applications within that path from running. The down side to a path rule though is that if the user moves the file in question to a different location then the rule ceases to apply.
A more effective way of using a path rule is to create a default rule that prevents users from executing anything at all. You can then create other rules that allow users to execute programs found in system related paths. It is important to allow users to execute files in system related paths because otherwise Windows will not function correctly. The paths that you must permit access to are:
Before I end this article, I want to take a moment and talk about some best practices. It’s easy to become over zealous and create some really restrictive policies. However, if you are planning on creating some really restrictive policies, you need to plan and test carefully. As I mentioned earlier, you must create the policy in such a way that none of the major Windows components are prohibited from running. You must also keep in mind that sometimes applications launch other applications. Therefore if you were to allow all of the application found in the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run section of the registry to run unrestricted, you might still run into problems because some of those programs may need to launch other programs.
The biggest thing to remember is to test your policies thoroughly on a handful of machines before performing a large scale deployment, even if you are relatively sure that you have set the policies up correctly. Remember, it’s easy to accidentally restrict things like login scripts or temp files, and doing so can cause major problems.
As you can see, software restriction policies can do a good job of helping you to keep video games off of your network. At the same time though, it is easy to restrict a system so tightly that Windows no longer runs correctly. It is therefore critically important to thoroughly test the policies that you create prior to deploying them on a large scale.