AppLocker – Part 2: Understanding AppLocker 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.
This condition identifies an application based on its digital signature and extended attributes. The digital signature contains information about the company that created the application (the publisher). The extended attributes, which are obtained from the binary resource, contain the name of the product that the application is part of and the version number of the application. The digital signature is extracted from the application file hence, you do not need to obtain a certificate from the publisher. You can specify file versions with the publisher rule which makes this rule effective even when the specified application is updated. Also, the publisher condition remains active even if the location of the application changes.
This condition identifies an application by its location in the file system of the computer or on the network. AppLocker uses path variables for directories in Windows. AppLocker can only interpret AppLocker path variables. You can specify a folder and the rule would apply to the entire contents of that folder including all subfolders. Recall that the path rules can be easily weakened by moving a file to another location!
When the file hash condition is chosen, the system computes a cryptographic hash of the identified file. In other words, an application which is not digitally signed can be restricted by a file hash rule instead of a publisher rule. With AppLocker you can create a hash rule for a set of files which is not possible with Software Restriction Policies.
AppLocker rule behavior
A rule can be configured to use either an allow or deny action:
- Allow – You can specify which files are allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
- Deny - You can specify which files are not allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
It is recommended to use allow actions with exceptions because deny actions override allow actions in all cases. Deny actions can also be circumvented. In the next article, I will explain the four rule collections.