Using Windows software restriction policies to stop executable code
Software restriction policies are one way to prevent known malware and file-sharing applications from taking control of your network.
Software restriction policies (SRP) are a simple-to-use feature of every Windows environment that make it possible for you to control the execution of software.
In an operating environment with minimal variation, you can configure SRP to only allow the execution of specific software, and every other application will be denied (default deny), even to system administrators. In environments where cataloging every allowed application is not feasible, you can still use SRP to deny specific software you want to prevent -- known malware, P2P file sharing applications and remote control desktop applications such as VNC, for example.
|
||||
As of Windows 7 and Server 2008 R2, SRP has been replaced with AppLocker. This revised control scheme is more flexible than SRP, but only applies to Windows 7 and Server 2008. Because Windows 7 and Server 2008 are not yet widely deployed in most organizations, we will not discuss AppLocker in this tip.
As with other GPO items, you can access SRP by launching the Group Policy Editor, gpedit.msc; SRP is located under Computer Configuration > Windows Settings > Security Settings.
Software restriction policies only apply to executable files. To review or modify which files are considered executable, you can edit the Designated File Types policy. For example, if you wanted to prohibit Python scripts from executing, you could add *.py as an executable type. That would not stop the Python interpreter though, so you'd probably want to create a rule, under Additional Rules, to do that.
Group Policy software restriction rules
There are four types of rules, each of which uses different criteria for defining a matching file: path, hash, certificate and Internet zone. If multiple matches are found, then the most specific matching rule is applied.
Path rules match based on the file name and path. The path definition can include wildcards (?, *) and even environment variables such as %WINDIR%. If you want to block an executable simply based on the name of the file, you'd then have a path definition of "*filename.ext." To follow up on our Python example, we could block the Python interpreter by denying execution of any file with a path of "python.exe." Obviously someone could circumvent this by renaming the executable.
Hash rules use either the MD5 or SHA-1 hash of a file and its size to determine if a file matches a policy. This approach is more specific and therefore requires more effort for files that have multiple versions. It is ideal for indicating if a specific version of a file should, or should not, be able to execute. A hash rule for IE 6's executable, for example, would prevent IE 6 from running while not preventing execution of newer versions which have the same executable name.
Certificate rules allow or refuse operation of the executable based on the signing of that code. Certificate rules are very effective at preventing malware since malware is unlikely to be signed by a trusted signing agent.
Internet Zone rules match files based on where the file was downloaded from. Internet Zone rules only apply to MSI Windows installation packages and therefore reduce the flexibility of this option. If a MSI file is downloaded using Internet Explorer, the zone will be associated with it, and you can block or allow based on that criteria. A useful example would be to prevent Internet-zone packages from executing on servers.
SRP can be used for as a malware prevention mechanism to complement your antivirus product. Antivirus deployments are oftentimes incomplete or may have problems preventing the execution of certain types of malware. Use the antivirus logs to find file names that have been identified as malicious and create SRP policies that will match the executables. Note that many worms, droppers and Trojans use randomly-generated file names, so be careful not to waste your time by listing out random file names with path-based enforcement rules.
It's worth mentioning that desktop end users should not have administrative access to their desktops. Although removing administrative access seems to increase the administrative burden on IT, it ultimately reduces effort by preventing user-created problems. Furthermore, even trusted applications may still be used as the gateway to exploit your system; Internet Explorer, Adobe Reader and Microsoft Office have all contained vulnerabilities that allowed attacks to exploit the systems running these (normally) authorized applications.
Lastly, if you want this type of software control, but do not find Microsoft's software restriction policies to meet your needs, there are a variety of similar third-party products that do the same. Additionally, some desktop security and antivirus suites offer similar options to control software execution.
About the author
Tom Chmielarski is a senior consultant with GlassHouse Technologies, Inc.
Send comments on this technical tip to [email protected].
Join our IT Knowledge Exchange discussion forum; please use the midmarket security tag.