Udostępnij za pośrednictwem

First post: a pragmatic approach towards AppLocker policies

  • Artykuł

AppLocker is a very powerful security tool within Windows 7 and Windows 2008 R2. You can control and audit every program, MSI or script that a user (tries) to start. A good overview of what AppLocker is and does, can be found here (but I’m sure you’ll find a lot of other interesting sites when Bing’ing it)

Looks great, but how do you deploy AppLocker in a large environment, where you have lots of system administrators in many sites and you’re the security guy that needs to set the policy?

Best approach is (as usual): keep it simple!

In short: how does it work?

AppLocker allows you to control which applications can be started by (specific groups of) users; you identify the applications by “publisher rules” (e.g. WinWord.exe, version 12.0.0.0 or higher, Publisher: Microsoft, etc), “hash rules” (SHA256 hash) or “path rules” (C:\program files\CompanyX\AppY.exe).

The rule can be either an “allow rule” or a “deny rule” and each rule allows you to specify exceptions (e.g. in a path rule, you can specify that users are allowed to execute anything under the “c:\program files” directory, except e.g. “C:\program files\CompanyX\AppY.exe”). Exceptions only exist for Publisher and Path rules, but the exceptions themselves can be specified in any combination of the 3 rule categories.

And last but not least, the rule can apply to a certain group of users (default: everyone).

Ok, but how do I define now an AppLocker policy for 20.000+ computers, in 200 locations, managed by 100 different system administrators with no common application baseline?

Well, if you have a very motivated, skilled and very security aware staff of System Administrators who’s first concern is security and are willing to support you, you might want to start with identifying all applications + versions, create AppLocker publisher rules for each one of them, combine everything in a nice, big policy and have 1 or more FTEs available to update the AppLocker policy on a daily basis.

If you don’t have that, following pragmatic and simple approach might you get started anyway with AppLocker:

The basic idea for this approach is to prevent as much as possible that non-admin users would be able to execute files (.exe's) they downloaded themselves.

In order to do that, you create a simple AppLocker policy that allows users only to execute programs from "trusted locations": c:\windows and c:\program files (actually %windir% and %programfiles%) using path-rules.

Next, add all writeable sub-directories in those 2 directories as exceptions on these path-rule. To find the user-writeable subdirectories, you can use the AccessEnum tool from sysinternals. So, the %windir%\temp directory amongst others should be part of this exception list (this way, you can also blocked users from using utilities like arp.exe, etc). On a newly installed Windows 7, I identified following directories under %windir% that are writeable for normal users (non admin) and should be added to the exception list:

%WINDIR%\debug\WIA

%WINDIR%\PCHEALTH\ERRORREP\QHEADLES\*

%WINDIR%\PCHEALTH\ERRORREP\QSIGNOFF\*

%WINDIR%\PLA\Reports\*

%WINDIR%\PLA\Rules\*

%WINDIR%\PLA\Templates\*

%WINDIR%\Registration\CRMLog\*

%WINDIR%\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\*

%WINDIR%\System32\com\dmp\*

%WINDIR%\System32\FxsTmp\*

%WINDIR%\System32\LogFiles\WMI\*

%WINDIR%\System32\spool\drivers\color\*

%WINDIR%\System32\spool\PRINTERS\*

%WINDIR%\System32\Tasks\*

%WINDIR%\System32\Tasks\Microsoft\Windows\CertificateServicesClient\UserTask-Roam\*

%WINDIR%\System32\Tasks\Microsoft\Windows\MemoryDiagnostic\CorruptionDetector\*

%WINDIR%\System32\Tasks\Microsoft\Windows\MemoryDiagnostic\DecompressionFailureDetect

%WINDIR%\System32\Tasks\Microsoft\Windows\PLA\*

%WINDIR%\System32\Tasks\Microsoft\Windows\PLA\System\*

%WINDIR%\System32\Tasks\Microsoft\Windows\RemoteApp and Desktop Connections Update\*

%WINDIR%\System32\Tasks\Microsoft\Windows\SideShow\SessionAgent\*

%WINDIR%\System32\Tasks\Microsoft\Windows\SyncCenter\*

%WINDIR%\System32\Tasks\Microsoft\Windows\WindowsColorSystem\Calibration Loader\*

%WINDIR%\System32\Tasks\User_Feed_Synchronization-{F3998D1D-6B67-45B6-BE78-9A1176A90B

%WINDIR%\Tasks\*

%WINDIR%\Temp\*

%WINDIR%\Temp\Cookies\*

%WINDIR%\Temp\History\*

%WINDIR%\Temp\Temporary Internet Files\*

%WINDIR%\tracing\*

Local site admins can create exceptions on this base policy using a delta-GPO in which they list additional directories using AppLocker path-rules, e.g. for apps that are installed in a subdirectory directly under the c:\ or e.g. for the App-V Q:-drive. The advantage of this approach is that it is very lightweight, easy to understand and maintain. (For some other apps, e.g. exe's on thumb-drives to unlock the drive (e.g. IronKey), you must create publisher rules or hash-rules, since path rules won’t work in this situation.)

If your focus is mainly "policy-enforcement", this approach works pretty well (so far in my experience); you have to assume though that, even with a lot of testing, malicious users (or hackers) will find some day a writeable directory that is not excluded in the path rules; but it does protect against somebody trying to download something occasionally and execute it; or against the majority of automated attacks... (or against less skilled hackers ;-); and it does also prevent users from downloading and installing Google Chrome or Firefox themselves under their profile-directories (thereby circumventing all the IE security policies you have created).

Did this post help you? Let me know ...

Comments

  • Anonymous
    January 01, 2003
    Thanks for the feedback, Orange; I corrected it meanwhile in the blog-post...

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    December 21, 2010
    Are you kidding? Hopefully some of those locations are virtualized and not actually user-writable. What possible reason would exist for a C:WindowsTempCookies folder to be writable by all users?