Setting Up AppLocker Rules

To begin, you must know how to configure application restriction rules in AppLocker. As with SRPs, you can use Group Policy Object (GPO) settings to configure and enforce AppLocker rules. You can also use PowerShell cmdlets to configure AppLocker rules (this option isn’t available for SRPs). (For information about using PowerShell cmdlets with AppLocker, see the MSDN Windows PowerShell Blog entry “Getting Started with AppLocker management using Powershell” at blogs.msdn.com/powershell/archive/2009/06/02/gettingstarted-with-applocker managementusing-powershell.aspx.)

The AppLocker
GPO is in the \Computer Configuration\Windows Settings\Security Settings\Application Control Policies container. Notice that you can also configure rules in the Software Restriction Policies container.

The two technologies can coexist—you can leverage SRPs on all Windows platforms after Windows XP and Windows Server 2003, but AppLocker is available only on Server 2008 R2 and Windows 7 Ultimate and Enterprise. Because the policy rules that the two technologies use are so different, Microsoft doesn’t provide an automatic conversion from SRP to AppLocker policies (e.g., if you upgrade a Server 2008 machine to Server 2008 R2).

AppLocker supports three rule types: Executable Rules, Windows Installer Rules, and Script Rules. These rule types are grouped in rule collections and appear as subcontainers of the AppLocker container in the GPO settings, as Figure 1 shows.

• E xecutable Rules can allow or prevent *.exe and *.com files from running.

• Windows Installer Rules can allow or prevent the execution of *.msi (Windows Installer) and *.msp (Windows Installer patching) files.

• Script Rules can allow or prevent the execution of different script file types (*.ps1, *.bat, *.cmd, *.vbs, *.js).

When you right-click one of the three rule collection containers, AppLocker gives you three options for creating rules: Create New Rule, Automatically Generate Rules, and Create Default Rules.


Create Default Rules. The preferred option for getting started with AppLocker rule definitions is Create Default Rules. Default rules are generated automatically; these rules are tailored to let Windows run and to let you do your administrative work—both of which are important, considering AppLocker’s default whitelisting approach and the risk of locking yourself out. As a safety net, AppLocker prompts you to automatically create the default rules if you try to create a new rule and haven’t yet created the default rules.

AppLocker’s default rules are relatively open. For example, they include a rule that gives members of the local administrators group access to all local files. An AppLocker best practice is to first create default rules, then refine them using more restrictive rules that you create manually through the Create New Rule option (which I explain later). Default rules can be created separately for each of the three rule types: Executable Rules, Windows Installer Rules, and Script Rules.

Automatically Generate Rules. With the Automatically Generate Rules option, AppLocker basically generates a whitelist for you. Based on the file folder you provide in the automatic rule generation wizard, AppLocker will propose a set of rules for the files in that particular folder. This important new AppLocker feature isn’t included in SRPs. With SRPs you must define the whitelist yourself. To create an AppLocker whitelist for a certain category of machines, I recommend that you use a reference computer. Sharing such a whitelist with other computers and importing the whitelist into a GPO is relatively simple thanks to AppLocker’s easy-to-use export/import mechanism.

To automatically generate a rule set, select Automatically Generate Rules from the Executable Rules, Windows Installer Rules, or Script Rules context menu. On the wizard’s first screen, select a file system location on the reference machine, indicate the users or groups you want the whitelist to apply to (an important option that isn’t available in SRPs), and provide a name for the resulting rule set.

Next, select whether you want to create rules based on the file’s hash or path. Using the hash thumbprint is the most unique way to identify a file, but it has the disadvantage of requiring revisions of the rule when the file is updated (e.g., after a patch cycle). In addition, using hashes can negatively affect system performance.

The wizard also gives you the option of reviewing the list of files that it analyzed (including cancelling creation of a rule for a given file), previewing the rules list, and searching the list.

Create New Rule. Another approach to creating App-Locker rules is to define them manually, through the Create New Rule option. You’ll typically use this option as a last step to refine the rules AppLocker created for you using one of the options that I discussed previously.

From the rule creation wizard, you can create new allow or deny rules for files, select the group or user you want the rule to apply to, and choose whether you want AppLocker to identify the files using the file’s hash, the file path (file system location), or the file’s publisher. AppLocker refers to these identification options as primary conditions. You can then further narrow down the identification of files by specifying exceptions to the primary condition in the wizard (hash-based, path-based, or publisherbased).

If you choose publisher-based identification, AppLocker will identify the file through the file’s digital signature that was applied by the publisher as part of its software signing process. You can use the slider bar to limit the identification of files to only the publisher name (most general) or expand identification as far as the exact file version (most specific). The wizard also lets you specify custom values for the publisher, product name, file name, and file version fields.

Note that AppLocker doesn’t offer the network zone (aka Internet zone) file identification option that SRPs provide, which lets you use the Internet zone of the website from which code was downloaded to identify the code.

Source of Information : Windows IT Pro June 2010

0 comments


Subscribe to Developer Techno ?
Enter your email address:

Delivered by FeedBurner