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.
Staging an application before moving it to the production environment is always recommended but how many times it is done! With AppLocker auditing we can verify which applications are affected without actually causing any problems to the end users. For each rule collection you have the option to configure it as enabled (enforced) or audit only. Therefore, we can say that there are three enforcement rules, which are Enforce rules, Audit only and not configured:
Not configured – This is the default setting. If enforcement is not configured but rules are present in the corresponding rule collection, those rules are enforced. Caution – do not assume that AppLocker is disabled!
Enforce rules – Rules are enforced.
Audit only – Rules are audited but not enforced. The audit-only enforcement mode helps you determine which applications are affected by the policy before enforcing the policy. When a user runs an application that is affected by an AppLocker rule, information about that application is added to the AppLocker event log.
The AppLocker event log is found in the event Viewer in the Application and Service Logs\Microsoft\Windows node and it contains the rule name, which files the rule affects, whether the file is allowed or blocked, the rule type and the SID of the user or group. The Enforcement tab is accessed by right clicking the AppLocker node, selecting Properties and clicking the Enforcement.
Now let’s see the four rules collections.
Executable rules apply to files that have .exe and .com extensions. I recommend that you create all default rules as we explained in the first article – link. To start a new executable rule, right click on the right hand side pane and click Create New Rule. You are asked to select the action (Allow or Deny) and the user or group affected by this rule. Next, you need to select the type of condition, that is, Publisher, Path or File Hash. Depending on the condition you choose, you are prompted to select the file/s or folder/s. Also you are prompted to add exceptions if you want. Exceptions as its name implies will exempt the selected file or folder from the rule. For example, you can Allow Everyone to run Windows applications except Registry Editor.
Windows Installer Rules
Windows installer rules are bound with files ending with an .msi and .msp extensions. These rules are intended to block or allow the installation of applications on computers. The default allow rules create a somehow secure environment as they allow all users to run only digitally signed windows installer files, allow all users to run only windows installer files located in %systemdrive%\Windows\Installer and allow local administrators to run all windows installer files. But the main benefit of this rule is when standard users need to have administrators’ privileges because of the business requirements. This rule would force restrictions on super users’ capabilities, however, in such scenario it is important to restrict access to the local group policies as well.
Script rules are bound with file extensions related to scripts such as, .psl, .bat. .cmd, .vbs and .js. The best condition to use with script rules is the File hash as most scripts are rarely digitally signed and scripts may be moved to a permissible location by a malicious user. In such scenario, whenever a script is modified it the rules must be re-created!
The main drawback of DLL Rules is performance degradation and for every DLL used by an application a corresponding rule is required. DLL rules are bound with libraries which have the .dll and .ocx file extensions. The DLL rules tab is accessed by right clicking the AppLocker node, selecting Properties and clicking the Advanced tab.
Automatically Generate AppLocker Rules
AppLocker allows you to automatically generate rules for all of the files within a folder. It will scan the specified folder and create the condition types that you choose for each file in that folder. The wizard helps you create groups of rules faster and can force a second condition if the primary condition cannot be implemented. For example, for all files that are digitally signed the wizard can create publisher rules while for the rest it creates file hash or path rules. It also can group similar files into one rule hence reducing the number of rules created.
Note: Before you can enforce AppLocker policies, you must start the Application Identity service by using the Services snap-in console.