AppLocker implementation

The concept is very close to SRP. So close that it actually replaces it. In Ultimate and Entreprise versions of Win 7, SRP, even if set up, is simply bypassed if AppLocker is set up as well. SRP is still there for means of back compatibility.

AppLocker is located in the Local Security Policy (administration tools) at the same place you can find SRP.

How to set it up.

First the meaning of AppLocker is to implement a further layer of security when running in a limited user account called standard user in Win 7 and by denying the execution of executable files, script and batch files, Windows installer files, and DLL (and Activex) files that do not meet the rules configured.

I propose to show how to create a default set of rule for AppLocker and to activate it. Sorry for the pictures, my win 7 is in French and Russian only.

Under your admin account, run as admin the Local Security Policy:


In the left pane, right-click on AppLocker and select Properties.
For every rule, tick Configured and from the drop down menu select apply rules. Once done, go to the Advanced tab, and tick to activate the DLL Rules.

You should get this :

Just press Ok.

In the next message we will create the default rules.

 

Now you should see this:


Only a simple thing to do, right-click on each of the sub-menus in the left panel:
- executable rules
- DLL rules
- script rules
- Windows Installer rules,

and select "Create default rules". This will auto-generate the by default rules (similar to SRP - but once created spend time analysing them - you will see how smart they are!)

An example:

 

Now you believe you are done, but unfortunately, there is a last step to go through. this is about the activation of the windows sevice, absolutely necessary to allow the enforcement of AppLocker.

Still under your admin account, run as admin the submenu Services in your Administration Tools, and look for the service "Application Identity (not sure about the exact name in english):


Its true name is AppIDSvc, as you can see after doubleclicking the Application Identity line:


On this very same window, just click on start, and on the start up type, select automatic. This will start the service now and at every windows start up. Press OK and you're done.

From now on your AppLocker policy is active, and will be at every boot!

Enjoy!

 

Very nice!

I don't have my Windows 7 laptop here right now, but I'll see if I can upload some English screenshots here.

 

Nicely done, Lucy, enough to get people off on the right foot. There is also some recommended, at least imo, reading here, including step-by-step and Applocker operations guides.

If I may comment briefly from my own experience with it:

• Try to think white-listing rules as opposed to deny rules.
• Learn about the "Audit only" option to use when you think your policy is blocking something it shouldn't - make sure to read: Testing and Updating an Applocker policy before you enforce a custom-created policy.
• Create as many Publisher rules as possible, followed by Hash, then Path.
• Take a look at the "Automatically Generate Rules..." option
• Once you are satisfied with the policy upon its completion, export it for safe keeping.
• Take note you can restrict any rule you like to selected users or administrators only. Handy when you don't want certain application(s) to be used by just anyone.

I have found Applocker to be rock-solid. Unless it's in the policy whitelist, it does not execute - Period. This is even enforced in the user's temp folder.

 

What i believe that still SRP based policies are more customizable then AppLocker based policy. AppLocker can be used to manage four different types of files: executable (.exe), Windows Installer (.msi and .msp), script (.bat, .cmd, .js, .ps1, and .vbs), and DLL (.dll and .ocx). Each of these file types is managed in its own rule collection whereas SRP can be used to many types of file extension.

AppLocker can't block .inf or .pif extensions whereas SRP can block user to execute it.

 

I believe it is possible to restrict the execution of the supplemental executable types through AppLocker. I will try tonight and update this thread if I am successful.

I am pretty sure now I think about it that we can forbid pif, inf, ini,... execution through customized rule. Time will tell...

 

Looking for your reply, but what i feel that AppLocker can be used on limited number of file extensions...and the same was also mentioned on MSDN Technet library.

 

Could AppLocker be used together with SRP at the same time? If possible, this would provide an extra layer of protection over SRP.

 

Short answer: No. SRP is automatically "switch off" as soon as AppLocker is activated.

 

I tried to add rules using extensions but they are not enforced.

It seems that, well, I was talking a bit too early when I said it should be a way to add more executable types.

Sorrry.

NB: I carry on, who knows...

 

So, It makes AppLocker less secure then SRP, even though it was claimed otherwise?

I can't believe that Microsoft did it again. Gave up security for the ease of use

 

Looks like Applocker isn't the silver bullet you were hoping for Try this: enable it, setup all your rules, focusing on Publisher as priority, then hash then path, always run as LUA, use the common sense you most certainly have...and enjoy. Enjoy the speed. Enjoy the simplicity. Enjoy the stability.

If this isn't enough for you, then you can always revert to SRP or go with a full blown HIPS if that suits your concerns better.

 

I made a tutorial a couple weeks ago and posted it to this forum (and it's in English). You can find it here.

(Why someone would post a French tutorial to an English forum is beyond me).

 

It's pity that AppLocker doesn't block like SRP.

But still I bet I am soon going back to AppLocker, especially after this: http://code.google.com/p/chromium/issues/detail?id=10576

on newest built of chromium problem with AppLocker has been fixed.

 

Good to see the Chromium issue fixed Applocker does a great job. It's primary purpose, btw, is to make admin's job easier to maintain a locked down software profile in a typical enterprise environment - to prevent end users from installing unauthorized software. It's not an antimalware application. However, it blocks most of the common executable types and scripts and paired with an LUA account, it's pretty darn robust.

 

As i already said, AppLocker has a very specific definition of executable files. AppLocker defines executable files as .EXE or .COM files. Even though .BAT, .PIF, .INF and a few other formats are technically executable, they are not covered by the default executable file rules...which is again compromisation with system security.

Just as AppLocker has a specific definition for executable files, it also has a specific definition/rule for Windows Installer files. Windows Installer files are defined as .MSI and .MSP files...so that means these type are only going to be blocked.

Secondly, By default, users have full read / write / create rights to the C:\Windows\Temp directory. When the default executable rules are created, the user is automatically granted permission to execute applications residing in the C:\Windows\Temp directory, because it falls beneath the C:\Windows directory. This means that if a user could potentially install an application to the Temp directory and run it from that directory...Another Security Loophole

You can also see that in second configuration the default Windows Installer rules allows all users to run any Windows Installer file that is located in the %systemdrive%\Windows\Installer folder. In this case, the Windows Installer files do not even have to be signed...that means any file can be accessed from that folder which is not digitally signed....

These all points are based on my experience..If need correction please do let me know.

 

Questions for everyone:

Which of the two(Applocker or SRP) do you consider to be the better personal security choice and why?

Which of the two are you using or will you be using (if any at all) and why?

 

That's why the default rules should only be kept until such time the user has defined and verified a custom or, perhaps, auto-generated whitelist (very important to use whitelist as opposed to blacklist, especially since exceptions can be included in the rules) ruleset, or a combination of the two. I will check on your concern when I get home later, but I was not able to launch an execuatble file in my C:\users\appdata\....\temp folder when I tested yesterday. Remember, the whitelist defines unequivocally what can execute and where it can execute. If it's not whitelisted, it's not allowed to execute, although admittedly the executable types you mention not covered by Applocker could execute.

BTW, just as an aside, I do have evidence of Applocker blocking *.BIN files. Also, I would agree MS could have incorporated better file type control into Applocker. I guess they went with a balance between moderate securty and simplicity controling most common executables to make things easier for administrators to exercise control over the software environment.

I use Applocker because I find it far more efficent than SRP and it provides, for me anyway, excellent security. I don't need my hand completely held by a security application to keep my machine malware free. There should be some onus on the end user to exercise some common sense when avoiding malwre. Read some posts from Wilders member Mrkvonic to get a calm, cool perspective on pc security. There's a lot of common sense in his posts, even if you have to sometimes read between the lines. Case in point using common sense to avoid malware: I've had a coule of those stupid rogue av attempts to "scan" my computer and "find" malware. Just close the window instead of mindlessly clicking to download/install the file. I didn't even need security software to protect me in those cases. Common sense. That's it!

 

hmm.. Strange.
My LUA doesn't even have read access to the C:\Windows\Temp folder

 

In what way do you find Applocker to more efficient than SRP?

 

Hi Bro,

Here i am talking about C:\Windows\Temp folder, if a user access it from here then any executable file will execute, because it falls beneath the C:\Windows directory. I mean that any user could potentially install an application to the Temp directory and run it from that directory...

Secondly if you are sure that AppLocker can block *.BIN files then please let us know how you blocked it? As i guess its not possible with AppLocker. But still please let me know how you do it?

 

Far easier to setup than SRP, and Publisher and hash rules are better than path rules. An MS Technet article explains this somewhere (sorr no time to hunt for it atm - too busy).

I'll check later when I,m home on the Temp folder possible issue. As for *.BIN, it was a case where I had to create a whitelist rule to unblock it. I've posted somewhere in these forums about it (again, just no time to search for and link to it, but I'll elaborate when time permits).

EDIT: wait, found it quickly https://www.wilderssecurity.com/showthread.php?t=258922&highlight=applocker

 

I would like to ask opinions as well.

If SRP provides ability for path,zone,hash and certificate rules, how does Applocker seem better?

If SRP uses hierarchy to determine which rule has more 'wieght', and Applocker uses exclusions, how does Applocker seem better?

If SRP can handle more extensions (it seems) how does Applocker seem better?

The more I look at it (which is not much yet) the more I don't really see the point in it. I will look at some tech specs to see what the deal is, but from the outside view, I don't get why it is any more than SRP already is.

Of course, hopefully someone has used them both quite a bit and can shed some experienced view points that are relevant.

Sul.

 

It's all here in black, white and blue:

How does Applocker differ from Software restriction policies There's a lot more as well in the article. I'd recommend read the fine points to gain a decent understanding of what it's about and why MS developed it.

All I can say is you can always stick with SRP, or go with your favorite HIPS, or even combine the two if you're that paranoid or even one of your own custom-made registry fixes. Also, maybe take up your gripes with Microsoft, especially if you have MS MVP or similar creds; you might make some headway.