Application Control Policies can be used to restrict what
programs a user is allowed to run. They can be created at the local Group
Policy level or the Domain GPO level. There are 4 different types of Applocker
RULES that you can implement, depending on what type of executable you want to
control access to.
·
Executable Rules – EXE’s, COM’s, etc.
·
Script Rules – batch files, VB scripts, etc.
·
AppX Rules – AppX Packages (Windows 8.1/Server
2012 R2 Metro Interface programs)
·
Windows Installer Rules – Windows Installer
Packages and MSU Packages
After choosing what type of executable file you want to
control, you can choose the corresponding rule type. Then, you will be able to
choose the criteria for that rule type. Applocker rule criteria are things such
as file path, publisher, and file hash. Criteria allow you to be more granular
with your selections. Rather than saying you want to block access to ALL
executable’s on a computer, you can choose to block access to executable’s
published by a certain vendor, or found in a specified directory.
Applocker can be found in the Group Policy Editor at:
Computer Configuration > Windows Settings > Security Settings >
Application Control Policies. By right-clicking on the Applocker node, you can
configure rule enforcement. You have the option to enforce rules or audit rules
based on rule type. Auditing will allow
you get a good grasp on what Applocker
will do in your environment if you are unsure.
Clicking the Advanced tab of this window will allow you to
configure rule enforcement for Dynamic Link Libraries. It’s best to leave DLL
rule enforcement disabled, because it can cause a system to suffer dramatic
performance hits.
Underneath the Applocker node, you will find nodes for the 4
different rule types. You can create new rules by right clicking on any of
these nodes and clicking “Create New Rule”. Before creating any rules, I advise
you to create the default rules. Doing this will ensure that users are still
able to run programs in the Program Files directory and the Windows directory.
Also, members of the built-in Administrators group will be allowed to run ANY
files.
When creating custom Applocker rules, you can choose to
allow or deny the program, and what group the rule will apply to (by default,
the “Everyone” special identity is always selected).
You will also be able to choose the criteria for the
executable that you are controlling.
If the executable has a digital signature from the software publisher,
choose “Publisher”. Doing so will give you even more options:
This allows you to really drill down and get granular with
the rule. Microsoft allows us to control access to the file based on the
Publisher, the Product Name, the File Name, and even the File Version.
Creating rules based on File Path criteria is not advised,
being that if the file jumps directories, the rule will no longer apply. I also
don’t advise using the File Hash criteria. My reason behind this is, if the
file gets updated, the hash changes. If that happens, the rule is no longer
valid.
After choosing the criteria type you would like to use, you
can choose to create exceptions, if any. When multiple rules conflict, the
order of precedence is Publisher, File Hash, and then File Path. So Publisher
rules will always override File Hash rules, File Hash rules will always
override File Path rules, and you get the point…
Finally, in order for your endpoint workstations to process
Applocker rules, the Application Identity Service must be running. I like to
control this with the same GPO that I configure Applocker in.
No comments:
Post a Comment