Battle Malware with Win2k3 Software Restriction Policies

Welcome back to our look at software restriction policies for Windows Server 2003. In part one, we looked at the basic principles of software restriction policies, and how they can be used to control the software that is allowed to run on a system. In this article, we'll look at the process of actually creating a software restriction policy.

Before we begin, it is worth clarifying what we can and cannot cover in this article. While we will show you the basic steps required to create a policy, we won't be looking at how you deploy software restriction policies on a complex network. Such an explanation would require a huge amount of space, and there are simply too many variables. Instead, by looking at the basic configuration process, you can take the information provided here and use it as platform from which to plan your own software restriction policy deployment.

Getting Down to Business

Figure 1. (Click for a larger image)

To start the configuration process for a software restriction policy, first locate a group policy object (GPO) on a site, domain or organizational unit for which you want to configure a policy. For the purposes of our demonstration, we'll configure the software restriction policy for computers within an organizational unit (OU). You can either use the properties of an existing GPO for your chosen object, or create a new GPO specifically for your software restriction policy. Creating a new GPO is a good idea, because if you have a problem with the policy settings, you can simply disable the entire GPO without affecting any of your other group policy settings.

The software restriction policies node of the GPO is located under Computer Configuration > Windows Settings > Software Restriction Policies. When you first open the GPO to the software restriction policies node, you will see the screen shown in figure 1.

As you can see, there are no policies assigned by default. To create a policy, right click the Software Restriction Policies node and select New Software Restriction Policies from the menu. After the policy is created, you will see the screen shown in figure 2.

Figure 2. (Click for a larger image)

The first step in configuring your actual software restriction policy is to set the default security level from within the Security Levels subfolder. A black circle with a tick mark, as shown in figure 3, indicates the currently selected security level. As you can see the level is set to "Unrestricted," which is the default.

Figure 3. (Click for a larger image)

After configuring the default security level, you can now set up the exception rules. As you may recall from part one, the exception rules determine what software will be allowed to run if the default level is "Disallowed," or not to run if the default security level is set to "Unrestricted." For the purposes of this discussion, we'll leave the level as "Unrestricted," and configure an exception that will prevent a specific application from running.

Creating an Exception Rule

As discussed in part one, exceptions are created using rules. There are four types of rule supported by software restriction policies: hash, certificate, path and Internet Zone. The rule creation process is very straightforward, so for the purposes of this discussion we'll just look at creating a hash rule.

Figure 4. (Click for a larger image)

To create a hash rule, first locate the "Additional Rules" subfolder under Software Restriction Policies node. As you can see in figure 4, a number of path rules are created by default.

Right-click the "Additional Rules" subfolder and select New Hash Rule from the menu. The "New Hash Rule" dialog will appear. For our new rule, we'll prevent the Calculator program (Calc.exe) from being run.

First, use the Browse button to find the executable associated with the file you want to block. When you have selected the file, the hash value of the file is created and listed in the "File Hash" field. In addition, properties like the name, version, etc. of the file will automatically appear in the "File Information" field. The completed rule should look like the own shown in Figure 5. Once you click OK, the exception rule will be created.

Figure 5. (Click for a larger image)

The process for creating the other rules is essentially the same, though in each case you configure the appropriate criteria (certificate, path or Internet Zone name) for each of the respective rules. Once you have configured all of the required exceptions, you are ready to configure the Enforcement rules, and the Designated File Types.

Enforcement Rules

Figure 6. (Click for a larger image)

Enforcement rules, which again are configured from within the software restriction policies node, allow you to configure whether local administrative users are exempted from the policies, and also to define whether library files (such as dynamic link libraries (DLL's)) are included in the policy. The key consideration here is that if you do include DLL's, and the default rule is "Disallow," you will need to create an exception for each and every DLL associated with the applications you use. Considering that a single application can have hundreds of associated DLL's, this would be a daunting task. Alternatively you can exclude DLL's from the rule. This means you only need to concerned with the applications themselves. You can see the "Enforcement" configuration dialog in Figure 6.

Designated File Types

Like enforcement rules, the "Designated File Types" dialog is accessed through the main software restriction policies node. The configurable list allows you to specify the types of files that will be affected by the software restriction policy. This list is of less concern if you are using the Unrestricted default security level, as the exceptions explicitly define what applications cannot be run. In contrast, when using a default security level of disallowed, the designated file types list becomes critical, as it determines whether or not an application is subjected to the software restriction policy. The default list of file types is very comprehensive, but if you do want to add or remove a file type you can do that from within the "Designated File Types" dialog shown in Figure 7.

Figure 7. (Click for a larger image)

Once you have completed your configuration, you can test your policy by attempting to run the blocked application. Remember though, that as software restriction policies are applied through Group Policy, you must either wait for the policy to be refreshed automatically, or trigger a manual update using the Gpupdate.exe command line utility. If the policy is configured correctly and refreshed, an attempt to run a blocked application will result in an error message like the one shown in Figure 8.

Troubleshooting

As we discussed in part one, implementation of software restriction policies should only be completed after extensive testing. However, even the most comprehensive test may hide an issue that becomes immediately apparent in a live environment.

Figure 8. (Click for a larger image)

If you do find yourself experiencing problems, an easy way to get around the software restriction policy is to reboot into safe mode. The policies are not applied in safe mode, so at the very least you will be able to determine whether or not it is the policy that is causing a problem. If the problem appears to be with the software restriction policy, consider disabling the GPO. As discussed earlier, this is much easier to do if you have created a separate GPO for the software restriction policy.

Summary

Our aim in this and the previous article was to give you a solid understanding of software restriction policy fundamentals. There can be no doubt that a successful deployment of these policies will take some serious planning. However, if you are looking for a way to provide an extra measure of security to your network, software restriction policies are deserving of your time and attention.