To totally unlock this section you need to Log-in
Login
Your organizations might consist of hundreds, if not, thousands of client computers. People are working with those machines day by day, using both software you installed on those machines and software they brought with them from home, or downloaded from the internet.
SRPs comes to give chances that some pieces of software take not part in the process of giving your users productivity rather than providing them gaming fun or a platform to share files. If you follow Microsoft Best Practices you’re somewhat lucky: your users work as non-administrators and therefore have (hopefully!) not sufficient rights to install most of the software found out there. But some kinds of software (pretty much all that doesn’t need access to system directories and HKLM-registry sub nodes) will install anyway.
Not only good software, any kind of harmful software, spyware, Trojans and other malicious files can be downloaded from the internet, received via email or shared via some kind of file sharing tool. How would you handle those programs? How would you block the application of, let’s say VBS files that are a known thread to email users when sent via an attachment. If you have to mess with all this, you might be a candidate for Software Restriction Policies.
Software Restriction Policies are a feature of Active Directory Group Policy.
You can – explained on a low basis – define software that can be run or can’t be run on client computers – depending on given criteria; and users cannot circumvent it. With Software Restriction Policies (SRP) you can fight successfully against the following threads: mean viruses and Trojans, ActiveX controls (allow or disallow specific ones), installation of software (that for example is not the ones you want to run on client computers) and application of malicious Email attachments.
SRP works based on a ruleset that you define. The rules get read from the first one to the last – the one rule that matches the started application best, gets applied. The precedence and importance of the rules will be described later.
You can configure SRP with the following node: Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies\ by right-clicking the node and selecting New Software Restriction Policies.
Depending on your wishes, you can have a strict policy, which means Deny all software except the ones that I white-list with my rules or a less strict policy which allows to run any software on the computer and only blocks the ones you define. Your decision should be based on the target client environment that you have.
If you have a white-list of software that can and should run on the clients, use the strict policy and deny anything else. But be sure to have a phone near you, angry people might call you because of that
There are five rules to identify software are:
The hash rule will identify software by a hash value given by the software. You as the administrator specify the executable and the system creates a hash value from it. Any application, no matter what it’s called, what its location is or from where it gets executed, will be blocked.
The hash value is unique to the software. There is no chance that a hash value you create for an application will block another. The hash rules consists of three parts that belong together: the MD5 or SHA1 hash value of the file, the file length in bytes and the hash algorithm id – separated by :.
Using the hash rule is useful if you have a certain piece of software previously installed on machines; or an application that does not get updated too frequently. As if updates can both change the file size and the hash value of an application, the hash rule will not apply any more. Otherwise: it is good if you want to block a specific version of a program (because it is broken or has a known vulnerability). Keep that in mind!
Certificate Rules specify a signed certificate from the publisher. You could for example require, that all applications run on your client computers, have a certificate issued by a certificate authority (such as VeriSign or a Windows Server PKI). You could handle ActiveX controls with this.
Zone rules can restrict or allow software that is downloaded over a Internet Explorer zone. As you surely know, Internet Explorer categorizes sites and locations (both inter- and intranet) in zones. These zones are: My Computer, Trusted Sites, Internet, Intranet and Restricted Sites. As of a Microsoft Whitepaper, this only applies to Windows Installer packages (*.MSI) and not any software downloaded with Internet Explorer.
Path rules define logical paths on the harddisk or network locations, programs are allowed or disallowed to run from. You can give a fully qualified path to an application that shall be configured or give the path to a folder – in the latter case, all programs and applications within the folder will be treated according to your rule. You can also use wildcards in your path description, to match as many programs as possible. The following are valid examples:
C:\Program Files\SomeApp\*.doc – triggers all .DOC files in that folder
\\fileserver0??\share\hiddenFiles – gets all shares hiddenFiles on the file servers \\fileserver000\ to \\fileserver099\
C:\temp\evil.* – will catch all evil.* files, no matter what file extension they have.
You can even use environment variables in your path rules, for example:
%WINDIR%\Folder\*.vbs – will catch all VBS files in the Windows directory
Other environment variables, such as %HOMEDRIVE%, %HOMEPATH%, %PROGRAMFILES% and %TEMP% will work as well. By using the path rules, you need to understand in what order or manner the rules will be applied. In general, the most specific rule given gets applied. If there is no rule matching the file 100%, the next better rule that matches gets applied. If there is no rule to your file and location, the general execution mode will be applied (‘Run all software’ or ‘Block all software’). The precedence is as follows, from most specific to less specific:
C:\Folder1\Folder2\Folder3\myFile.ext
C:\Folder1\Folder2\Folder3\*.ext
*.ext
C:\Folder1\Folder2\Folder3\
C:\Folder1\Folder2\
Registry path rules can be useful if you need to restrict access to a file or folder on the disk with a path that is given in the registry. Some programs store paths in the registry, for example the Windows platform SDK: %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PlatformSDK\Directories\Install Dir% points to %Program Files%\Platform SDK by default.
By creating a rule on that registry path, you can trigger access to it very easy.
In your SRPs, it can be possible that multiple rules apply to a piece of software that you might want to block. SRP therefore provides a testing priority for your rules – once more from specific to less specific. The most accurate and specific rule for an applications wins and the order is:
Hash Rule
Certificate Rule
Path Rule
Zone Rule
Default Rule
So if a hash rule is defined, that matches a program to be executed, the hash rule will be applied (no matter whether it’s configured to Unrestricted or Disallowed) and other rules like path rules or zone rules (that also might match) aren’t applied. The hash rule wins.
You can also define other settings on the application of SRPs – for example that Administrators are excluded from the policy so that they can run anything they want on the machine. You can also define how DLL libraries shall be handled, if they get blocked, too or if they are allowed to be called and executed.
How to SRPs work, technically?
I also like to lose some words about the application of SRPs and how they actually work. They are not simply on the file that gets set – there is a separate CSE (Client Side Extension) for this built into Windows XP and newer. That is the reason why SRP won’t work with Windows 2000 clients and before.
To make things even more complicated, the CSE has changed from Windows XP to Windows Server 2003.
I’ll give an example. Let’s say you have your domain computer and want to restrict a certain program, for example game.exe. The domain computer is running Windows XP and you’re currently logged on and running the game. You now switch over to the domain controller or any other machine with access to the Group Policies and define a GP with SRP that deny the application of game.exe – via hash rule for example. You link the GP to the OU where your domain computer belongs to and refresh the policy with gpupdate.exe /force on the client. The policy gets applied. What happens next?
At the moment: nothing. You’re still able to run your game.exe game as long as you want. Until you close it. SRP work together with the shell. If you fire up cmd or explorer.exe (no matter by hand or on logon, what happens automatically), they check what applications are allowed to run and which are not. They actually get the message from SRP to block or run an application. But they only check that when they get started. So if you’re going to open up Start->Run and execute ‘game.exe’ on our domain computer (with still no reboot or logoff/logon since we forced gpupdate), you’ll be surprised to see, that game.exe is still able to run. The point is, that explorer is already running and didn’t get the message from SRP on startup, that game.exe is blocked.
It simply runs it. If you fire up Start -> Run and give cmd a try – and type there game.exe, you’ll see that game.exe is restricted. As we opened up a new CMD, it would check with SRP what software can be run and which can’t and deny access to game.exe.
The application of SRP depends on the shell and the programs that call and run your applications. Don’t be surprised, when you roll out a SRP and some machines won’t pick them up, even after a few days. They just might have not been rebooted.
Windows Server 2003 SRP work a little easier. As soon as you link the policy to the OU and the policy gets read and applied, Windows Server 2003 will no longer allow to run an instance of the forbidden application. No matter if the machine was rebooted or the user re-logged in. Windows Server 2003 doesn’t have to wait for explorer.exe or cmd to catch the new forbidden applications.
Precedence of software restriction policies rules
You can apply several software restriction policies rules to the same software. The rules are applied in the following order of precedence, from highest to lowest:
Hash rule
Certificate rule
Path rule
Internet zone rule
For example, if you create a hash rule with a security level of Unrestricted for a software program that resides in a folder that has a path rule assigned to it with a security level of Disallowed, the program will run. The hash rule takes precedence over the path rule.
If two path rules are assigned to the same object, the more specific rule takes precedence. For example, if there is a path rule for C:\Windows\ with a security level of Disallowed, but there is also a path rule for C:\Windows\System32\ with a security level of Unrestricted, the more specific path rule takes precedence. Software programs in C:\Windows\ will not run, but programs in C:\Windows\System32\ will run.
If two identical rules with differing security levels are applied to software, the more conservative rule takes precedence. For example, if two hash rules--one with a security level of Disallowed and one with a security level of Unrestricted--are applied to the same software program, the rule with a security level of Disallowed takes precedence, and the program will not run.
 |  |