The following procedure shows how to restrict an application from running using AppLocker. For more details about AppLocker and the available options read articles Part 1, Part 2 and Part 3. The following example shows how to restrict the windows notepad application from executing :
- Use an administrator account to perform these while make sure that a standard user account without administrative privileges exists on the computer. Verify that the Notepad application runs before starting configuring AppLocker. Read more…
In part 3 of this AppLocker series, we will go through the rules that AppLocker uses to allow or block specific applications. Firstly, note that explicitly defined Block rules (non generic) override any Allow rules (generic). Secondly, note that if you don’t set a default policy to allow all applications, then any application that has no Allow policy will not be allowed to execute. When creating rules you can take two different approaches, either you allow all applications to run with specific ones set as blocked, or leave the default behavior of AppLocker and then allow specific applications to run (remember to allow administrators full allow permissions and everyone to run system applications). However, it is recommended to start implementing AppLocker rules by performing an audit exercise prior to the actual enforcement of rules.
When you enable AppLocker, the default behavior is secure, that is, Block. This rule is sometimes called the fallback Block. It is worth mentioning again the importance of setting a default Allow rule at least for the administrators (local or domain) as enabling AppLocker without any allows rules may render your computer unusable! AppLocker is organized into four areas called rule collections. The four rule collections are executable files, scripts, Windows Installer files, and DLL files. The following are the file formats included in each rule collection:
- Executable rules – .exe .com
- Windows Installer rules - .msi .msp
- Scripts rules – .ps1 .bat .cmd .vbs .js
- DLL rules - .dll .ocx
Rule conditions are criteria that the AppLocker rule is based on. Primary conditions are required to create an AppLocker rule. The three primary rule conditions are publisher, path, and file hash.
Unlike the Software Restrictions Policies, the AppLocker Application Control Policies are available only in Windows 7 Enterprise and Ultimate editions, and all editions of Windows Server 2008 R2. AppLocker policies build upon the Software Restriction Polices functionality but have additional features which make them far more powerful and useful. One of the main enhancements is the ability to specify which users can run specific applications. Now, rules can be based on file attributes such as, file name, file version, etc. You can create exceptions to rules and assign a rule to a security group or an individual user. The various added features are audit-only mode, policy import and export, rule collection, PowerShell support, custom error messages and a wizard to create multiple rules at once. The Policies are found in the Computer Configuration\Windows Settings\Security Settings\Application Control Policies node.
The first caution worth noting is when you are upgrading computers to Windows 7 with enabled Software Restriction Policies. If you implement AppLocker policies to the upgraded computer, then only the AppLocker rules are enforced. Secondly, AppLocker depends on the Application Identity Service which is set to a Manual startup state by default. Before setting the service to start automatically make sure that the policies are correctly set as incorrect rules may turn your computer unusable. Finally, keep in mind that when DLL rules are used users may experience a reduction in performance as AppLocker checks DLLs when the application is loading.
Creating Default Rules