AppLocker

Transcription

In this video from ITFreeTraining I will look at AppLocker. AppLocker allows the administrator to control which applications can be run. By controlling the applications that can be run on the local computer, this prevents the user running unauthorized applications. This video will look at what are the client requirements for AppLocker, the advantages of AppLocker and how to use AppLocker. AppLocker was first added to Windows in Windows 7 and Windows Server 2008 R2. It replaces Software Restriction Policies which were available in previous versions of Windows. AppLocker provides more features and includes a wizard making it easier to configure than Software Restriction Policies. Since AppLocker is aimed towards business, it is only available in business editions of Windows. These are Windows 7 Enterprise, Windows 7 Ultimate and Windows 8 Enterprise. AppLocker can also be used in Windows Server 2008 R2 standard, Enterprise and Datacenter editions or Windows Server 2012 Standard and Datacenter. If you are running an operating system that supports AppLocker, AppLocker allows you achieve a number of results other than controlling which software is run. AppLocker can be used for Application Inventory and statistics collecting. When AppLocker is configured for audit-only mode, an event is recorded in the Event Log when software is executed. These events can be collected for further analysis. This can be done in software like Excel or programmatically using a scripting language like PowerShell. The next advantage of AppLocker is that it prevents unauthorized software from being run. If an application is not in the rules configured in AppLocker it can be blocked. This prevents users from installing software on the computer as well as running unauthorized software. For example, they could not run unauthorized software they downloaded from the internet or brought in from another source, for example using removable media. The next advantage with AppLocker is that since it allows you to control which software can be executed, it helps with license conformance. By restricting which software can be run on a client computer you can say with confidence that the software that is running in your company has been purchased and corrected licensed. In some cases the software may be free and does not require a license. AppLocker allows for Software standardization. Many companies have strict rules on which versions of software can be used. Even if the software is free they still want to control which versions are used. AppLocker ensures that new versions of software are not used until they are approved. You could with a little clever rule creation prevent earlier editions of software being run, but not prevent a new version. This includes new versions of software that have not officially been released yet. AppLocker works by creating rules that are used to determine what happens when a program is run. There are 3 different rules that it supports. The first is publisher. The Publisher rule is the most versatile but does rely on the application being digitally signed. Most software sold today should be. The digital signature allows the company that created the application to be determined. The signature also allows other details like the version of the software to be determined. Using this information you can create a rule that tests for different versions. For example, you could create a rule that requires a minimum version of software to be installed. The rule would also allow newer versions of the software to be used. This includes software that has not been released yet. You could also create a rule that allows software from only certain publishers, for example you could allow all software that was created from Microsoft. The next rule type is a hash rule. This rule creates a hash value of the application used to identify it. A hash value is created by a mathematical process which effectively takes a file and reduces it down to one value. When an application is launched, the application is checked against the hash value to see if there is a match. If there is, the rule is executed. Hash values are a good solution if there is no digital signature. The problem with hash rules though is that it only takes one bit to change in the file and the hash value will no longer match. This means that hash rules cannot check for newer versions of the file. If a newer version of the software is released, a new hash rule needs to be created for the new version of that software. The last rule type is the path rule. This rule is created based on a directory path on the drive. You could essentially allow or disallow certain software to be run based on which directory it is in. For example, you could create rules that allow software to be run that are located in the Program files directory but deny software that is run from the desktop or user documents folders. You can start to see that by using a combination of these rules you can achieve some good results. I will now change to my Windows Server 2008 R2 computer to see how to configure AppLocker. To configure AppLocker, I will first open Group Policy Management from the start menu. In order to configure AppLocker for Group Policy it only requires an up to date version of Group Policy Management. For this reason, you could configure AppLocker on a client computer that does not support AppLocker, for example on a Windows Vista client as long as you have a Group Policy Management tool that supports AppLocker. Of course, no matter which version of Group Policy Management you use, this does not allow AppLocker to be used on that computer. For example, you could configure the Group Policy for AppLocker on a Windows 8 computer running the Professional edition, however the settings configured for AppLocker will not work unless the client operating system is Windows 8 Enterprise. To configure the Group Policy settings for AppLocker, I will edit the New York Policy found under the New York OU. First of all I will configure the service that is required for AppLocker. If this service is not running on the client, the AppLocker settings will be ignored. By default this service is not running. I will now navigate down through to Computer Configuration, Policies, Windows Settings, Security Settings and System Services. The service that I need to enable is Application Identity. Once I open the settings I will select Define This Policy Setting and set the Startup Mode to automatic. This ensures that when the client computer starts up, the Application Identity service starts running which will enable AppLocker to work. Now that the service is configured, I will now need to configure AppLocker. The settings for AppLocker are found in Security Settings as well under the folder Application Control Policies. Once I expand into Application Control Policies, notice the AppLocker section. Before I start configuring AppLocker, I will first start with the AppLocker Properties. To open this, select the option, “Configure Rule Enforcement. “If I tick the box configured under executable rules, notice that I have the option Audit only. I would recommend that when you deploy AppLocker in your organization configure it in audit mode first. This will allow you to test your configuration out first before deploying it. If you select the option Enforce Rules, this will enforce any rules that have been defined rather than simple log the result. The Audit only and Enforce rules options are available for the Windows Installer and scripts if you wish to use AppLocker with MSI packages or scripts like VBScript. If I exit out of here and scroll down to the bottom, notice that this gives you an overview of what rules have been created. In this case, no rules have been created as yet. There are three different areas where rules can be created. Executable rules, Windows Installer and Scripts rules. In this case I will create some rules for executables. Once in the executables rules section, I will right click the white space and select the option, Automatically Generate Rules. This will launch a wizard that will create a set of rules based on the software on this computer. In this case I have used a server to create the rules. In a production environment you can use a client workstation to create the rule set. This will allow the wizard to see the kinds of software that your organization is using therefore creating rules on these applications. The computer that is used to create these rules does not need to support AppLocker. As long as it supports the use of a new enough version of Group Policy Management to create the Group Policy, this computer can be used to configure AppLocker. The first screen of the wizard will ask which folder that you want to analyse. In this case I will leave it on the default of Program files. On the next screen you can decide which type of rules that you want the wizard to create. The top option will create publisher rules for files that are digitally signed. If you use this option, you can choose to use hash rules if the file does not have a digital signature, or the second option of a path rule for non-digitally signed files. The last option will create hash rules as required. Which option you choose will give you the same results, however remember that publisher rules will also take into consideration different versions of the software. Since hash rules are file based, there will be more rules than if you used publisher rules. For these reasons I would recommend using publisher based rules. The last option, “Reduce the number of rules created by grouping similar files,” will allow the wizard to analyze the rules that it will create to see if there are any overlaps. I would recommend leaving this option on as it will greatly reduce the number of rules created. The less rules you have, the easier it will be to manage. The last screen of the wizard will allow you to review what results the wizard has created. If you want to see which files were reviewed, you can select the option, “review files that were analyzed.” You can see here the Wordpad executable was found and identified and since the file was digitally signed the publisher was determined as Microsoft. Scrolling down to the bottom and you can also see that the Internet Explorer executable was also found, just to mention two of the applications found. If I go back to the previous screen, I can also select the option View Rules that will be automatically created. You can see here that of all the files analyzed only six rules will be created. The top rule is a hash rule as the executable was most likely not signed. Below this you can see a publisher rule is being created. None of these rules have been created as yet, so if I press OK and then press create, the rules will now be created. Notice that I get a warning dialog asking if I want to create default rules. Default rules determine what will happen if no other rules match, without any default rules, this may prevent system files from being allowed to run so in this case I will press yes. Notice that six rules have been created plus three default rules. At the top is a default rule which allows all programs under the program files directory to be run. Under this is another default rule that allows all programs under the windows directory to be run. If you want to manually create a rule, right click the white space and select the option, Create new rule. Once I am past the welcome of the new rule creation wizard, the next screen will ask what the action of this rule will be. In this case I select deny, an application that matches this rule will not be allowed to run. On this screen I can also select which users and groups this rule will apply to. On the next screen I can select which type of rule to create. In this case I will leave it on the default of Publisher rule and move on to the next screen. On the next screen I can browse to the location of the executable I want to create the rule for. In this case I will browse to the Program files directory and select the executable for Google Chrome. Once the executable has been selected, information about the executable can be read. You can see at the bottom, the version number has been identified as version 22. As you go up the information becomes less specific until at the top the publisher is listed. If I slide the sliding scale up, I can change the matching of the rule to less specific settings. In this case the rule will look for the Publisher Google and the product Chrome. Filename and version number will not be considered by the rule. If you want to use different values than the ones given you can select the option at the bottom, “Use custom values”. Now that I have the settings that I want, I will press the next button. On the next screen you can configure exceptions for the rule. This is a useful screen that can replace having to create additional rules. For example, let’s say you wanted to give the user access to only a particular version of Google Chrome. On this screen you could add the version of Google Chrome you wanted to run. So effectively this rule would say, Deny all versions of Google Chrome except this one. In this case I will not add any exceptions and move on. On the last screen you can configure a name for the rule and add a description if you wish. Once complete, press the create button and the rule will be created. You can see that a new rule has been created which will prevent Google Chrome from running. I will now change to my Windows 8 computer to see the affect that creating these rules has had. The computer was off while the changes were made to ensure that when it started up the computer configuration for group Policy was applied. Once I am at the welcome screen, I will go to the desktop and select the icon on the desktop Google Chrome. Notice that I now get an error message telling me that, “Your system administrator has blocked this program. For more information, contact your system administrator.” This shows that AppLocker is working. Thanks for watching this video from ITFreeTraining. For more free videos and courses please see our YouTube channel or website. See you next time.