AppLocker Default Rules

Hello all!

I've read a few of the threads here on Windows AppLocker, and I'm curious what the opinion is on using the default rules alone - Should one go beyond that and what's recommended? I've seen lots of information on how to set up rules, but very little on best practices to doing so.

Will be used on a Win7 laptop using a standard account.

Thanks in advance!

 

The thing to watch out for is that there are a lot of user writable folders from within C:\windows\ . You need to deny these entries on all groups you configure SRP/Applocker with. You can search which folders these are by running this tool:

Accesschk
http://technet.microsoft.com/en-us/sysinternals/bb664922

This thread has some good info
https://www.wilderssecurity.com/showthread.php?t=272761

Also, make sure you disable RunAs.exe . Its very easy to bypass SRP/Applocker via this command (this does not effect shift+ right click-runas).

 

Not necessary if using a whitelist of Publisher/hash rules. With the weaker path rule approach then, yes, this is necessary.

 

hpmnick, thank you! This is excellent information!

As for disabling runas.exe: Better to do that through AppLocker or just disable the Secondary Logon service?

 

I'm a bit leery doing whitelist rules under Windows... You never know what Microsoft Update will throw your way

I'm trying to keep the rules relatively generic; For example, unless someone can give me a good reason, I expected to keep the default that lets everyone execute EXE's from Program Files, as only admins can write there (so nothing would be in place unless I installed it).

 

I've done it through Applocker/SRP (depending on the OS). I'm thinking that disabling the secondary logon service will also prevent you from shift+right clicking (which I find myself using all the time).. but I'm not sure about this.

 

IMO, path rules are the only rules that are easy to maintain. Hash rules are just impossible, and publisher rules are nice, but there are many many publishers, and not all .exe's are signed or have consistent publisher info.

Path rules are pretty fool proof, and it works in conjunction with the concept of some common security models. You shouldn't be able to execute what a normal user writes. I don't care if its signed by a publisher I trust, if the user adds it, I don't want them running it until they have my approval.

For the most part, the program files folder and the windows folder are separated from standard user rights. There are some exceptions, but they are easy enough to fill with a deny rule.

This is the only way I've been successful with any type of anti-executable implementation.. but I'm speaking from the perspective of managing 150+ computers running completely different software than one another. If its just a personal computer we are talking about, I'm sure the other methods are much more flexible..

 

Yes, path rules are easier to maintain than hash rules. It is important, however, to restrict the directories that a standard user can write to.

From Microsoft:

 

This is not an issue at all since the only places they can copy the file to are places they are not allowed to run files from. Ideally, if you were to make a venn diagram, the set of folders that a user has write access to and the set of folders they can execute files from should have ZERO overlap.

What you are citing is true, but only if you have not locked down the folders you have white-listed.

Publisher rules can be very useful, but again the problem comes from simplicity. If I have a machine with 20 different software publishers, I have to allow all of them. Then I have another machine that also has 20 software publishers, but some are different... Then, maybe some computers I don't want people to install certain software (their own browser, or whatever), but I don't want to disallow the publisher. It is still workable, but now my rules have to be granular. Personally, I think publisher rules work great as something to compliment path rules. For instance, if I have an app that wants to update or run something in user space (i.e. user temp folder), I can use a publisher rule to avoid whitelisting a specific path in userland.

A lot of people might find my approach heavy handed, but if I don't install it or deploy it, I don't want people running it. I realize though, that this may not apply to everyone.. and probably would be down right annoying if it was on a PC for personal use.

 

Thank you all for the replies, it was very informative! I ended up following something similar to the links provided above, using almost the default rules with exceptions for user-writeable areas under the Windows directory.

I ended up having to add additional Publisher allow rules for Apple and Symantec (figures on both), and I made as suggested a Deny Publisher/File rule on RunAs.exe.

So far, no complaints, and everything is working great.

 

glad it helped... I find it really does a very effective job of stopping malware, especially when you have high risk users at the controls..

 

Its just me on the box; While I don't consider myself high risk (just anal-retentive ), either way I get to sleep better at night now!

 

I came across an interesting behavior with AppLocker.

I have a folder, which I'll call Folder A. In there, I got sub-folders and also a few batch files.

Folder A is in user space.

I wanted to explicitely prevent execution in Folder A. But, I also wanted to allow the execution of the batch files. I could easily create a new folder inside Folder A, and then place the batch files there. But, I wanted them in the main folder.

I created a Deny rule for Folder A.

According to this article:

That's what I did. I prevented execution in Folder A, with exceptions for the batch files. If I'm understanding it right, the exception rules should allow the batch files to execute.

Execution still got blocked. After testing some workarounds, it seems that by having a deny rule with exception(s) PLUS an allow rule for those batch files, allows execution of the batch files.

I'm trying to find documentation about this, but still couldn't find anything.

 

Not sure if this helps, but...

Understanding Rule Exceptions

http://technet.microsoft.com/en-us/library/ee460954(WS.10).aspx

 

I've seen that before, but it doesn't fit in what I did, though. Thanks anyway

It would work if I wanted to allow different users/groups.

But, I was doing it for my standard user account only. Somehow, I just thought that having an explicit deny rule with exceptions, would automatically allow execution of the batch files. I guess it does not. I also needed to create permission rules.

So, what I've discovered is that, if you are blocking a folder, but want to allow the execution of certain files in it, you need to set exceptions to the deny rule and also create permission rules for those files. Otherwise they won't execute.

 

Okay, I see. You really are better off with a whitelist approach where you could only allow those batch files within that folder. This way everything else will be default denied. My advice, fwiw, is to avoid at all costs deny rules.

 

I understand what you're saying. But, I don't think it would apply to my approach, though. (I didn't want to create a new folder where I could place the batch files. lol)

I have the default rules, which means anything in user space is blocked already - unless AppLocker acts weird - and creating explicit deny rules is simply a way of being sure - hopefully - that what is to be blocked is blocked and what is to be allowed is allowed.

In my situation I wanted to explicitely deny what's in Folder A (which by default already is), except a few batch files.

Or, are you having something else under consideration, that I'm failing to see? If so, by all means... shoot.

Anyway, if nothing else, I think it was a good experiment. I would never have thought it would be needed to set exceptions to the deny rules and also to have permission rules.

 

Hi again, m00nbl00d,

it is very easy to accomplish what you want with an allow Path Rule as follows:

1. First I created a folder on desktop of my user account called FolderA
2. then I placed a bat file in it called test.bat and an executable called wfc.exe
3. then I created an Allow Path Rule in AppLocker under Scripts Rules with path as: "%OSDRIVE%\Users\*\Desktop\FolderA\test.bat" so that it applies to all users. If you have several .bat files then you could simply use a global entry of "*.bat" instead.
4. Tested this out and as expected it allows me to run the bat file but not the executable.

This is why I'm adamant that Allow rules are the best to use.

**EDIT**

I see we posted closely apart Then, again, simply create an allow rule as my above example, except of course in one of the already existing directories you have in mind. If you are using Deny rules to block things in user space, then please for your own sake get rid of them and use the recommended whitelist approach of Allow rules

 

Oh, yes. But, you're forgetting the key word here - An explicit deny rule for Folder A.

By having an explicit deny rule, it means that to run the files you need to do two things:

* Add exceptions in the Deny rule;
* Create permissions rules for the files in the Deny rule exceptions

And, in both situations, in my case, execution is allowed by hash.

 

No, I'm not forgetting, LOL. I'm trying to convince you to scrap Deny rules and use Allow rules only. IOW, simply allow only what you want, where you want, and AppLocker will deny everything else by default. In your case, instead of a path rule, you instead use a hash rule.

 

OK! Now I get you. Still , the reason why I create an explict deny rule simply has to do with the fact that I've witnessed AppLocker allowing execution of files (dlls) from user space. AppLocker failed blocking them.

I mentioned it sometime ago in another thread.

That's the reason I'm creating explicit deny rules for certain folders in user space. Hopefully the explicit deny rules won't allow strange events, like files that aren't suppose to be allowed, to be allowed execution.

I simply lost trust on the default rules. That is, anything else outside of the permissions scope of the default rules should be blocked execution. AppLocker has failed preventing files outside of those default allowed folders from executing.

I'm hopping that a deny rule does stop it whenever something like that happens again.

 

If you created Allow hash or Publisher non-path rules, then AppLocker will allow those to run anywhere else, as long as the Publisher cert or hash value matches. Maybe you could try Allow with exceptions for folders you don't want them to run in. Anyway, I'll have to try some testing next week (going camping tomorrow ) because I'm kinda curious about this, and I want to be sure things work as I'd expect them to

 

I didn't* have any Publisher rules. Until I came across that incident with AppLocker, I only had the default rules. This means that execution from elsewhere is supposedly blocked by default.

But, for weeks DLL files outside Windows and Program Files directories, were able to be executed by one other application. I simply never paid much attention to it, I must say. The application was working. Only when it stopped working is that I realized that DLLs (and whatelse) were being allowed.

* After the DLLs started to be blocked again, I created Publisher rules for the DLLs that are in user space, and only allowing current and future versions to be executed.

AppLocker simply failed blocking their execution. This is why I'm creating a few explicit deny rules. Hopefully such situation won't happen again. Unless there's some serious issue with AppLocker.

 

Okay that's interesting. Maybe AppLocker allows dlls to be launched if the application doing so is whitelisted by AppLocker? I've never paid too much attention to dll behaviour in AppLocker but I think when time permits I'll have to look at this, at least make sure I understand properly what's happening. Thanks for the info. More food for thought

 

No, AppLocker doesn't allow dlls to be launched by whitelisted applications, unless dll rules enforcement is disabled.

First, I actually thought that it had something to do with what Didier Stevens brought to our attention sometime ago. But, I contacted with the application's vendor, and they weren't making use of such bypasses. Then I thought it could be a bug in the application, but once I allowed the DLLs (stored in user space), it started to work again.