AppLocker implementation

See Flash not working with SRP.

 

acr, for your first question there're a few different easy ways explained in this thread - one you were involved in no less. Personally, the Auto-generate method is my favourite.

 

OK looks like I have that remedied now. Thanks.

 

I'm going over it again and trying to figure it all out.

 

Check out post #6, link at bottom, on how to troubleshoot AppLocker issues.

 

ok, I re-set everything to audit only. I guess let it run a few days and then check back?

 

Sure, or even sooner than that. Just launch the apps that you suspected were being blocked, then check the AppLocker logs.

 

After that I just audit per rule or is there any way to import all the rules at once?
thanks

 

Anyone know the answer to this? Sorry for being a pain.

 

If I understand your question, you would simply create an allow rule for anything that's being blocked that you don't want blocked. An example is let's say I want to run PSISetup.exe (let's assume for demonstration purposes it's a single file executable) from my desktop, but I forgot to create a rule for that file at that location. The logs show me exactly what is blocked and where it's blocked at, so I might create a Publisher rule (safest type) for PSISetup.exe, choosing my desktop as the location, and choosing only my user name as the user allowed to run it. That's about it. You would do the same thing for any other program you don't want AppLocker blocking.

Keep in mind once you have AppLocker rules set up the way you like and you're satisfied everything's secure, you need to export the ruleset for safe keeping.

 

ok thanks....so I may try the slider not quite so far as some of my apps update and change their version number quite often, for instance Google Chrome. So for an app like that I could just choose "file name" instead of "file version". If that approach is used, though, is applocker any more efficient than say something like Malware Defender or Comodo D+?

 

I just go with the default slider position. It's very secure. Keep in mind publisher rules only work on apps that are digitally signed by the app's developer, otherwise hash or path rules can be used. Hash is more secure (some might disagree) than path rules, but hash rules have to be updated whenever a hash rule-governed app is updated. So if, for example, you've just updated a program and find it's not working properly or at all, then just check the Applocker logs to see if it was blocked. It will have been blocked due most likely to either an updated hash or because you installed it to a different location. Applocker is built into Windows unlike 3rd party HIPS applications, so I would say it's more efficient because you don't have to worry about bugs so much. AppLocker may have a more simplistic approach as well, but it does the job superbly.

 

ok I have added Google Chrome which was giving me problems before. Maybe once I'm able to work my way through applocker a few times everything will become easier. I am wondering if using applocker under a standard account with DEP if real time antivirus protection is needed. I may just use some on demand scanners for downloads and the virustotal uploader...or else just set everything in avast to low and add comodo since it has the sandbox....deciding whether to keep prevx active as well....oh the choices

 

I don't use real-time av with my setup.

All I use is a single, currently updated on-demand av (MBAM). I'm not necessarily suggesting you should do the same, only, rather, what is most comfortable for you.

 

What's the preferred way to white list scripts? I have an error report from MS Word that needs to run a script so I can send the error to MS. I think that's the deal. Anyway, when I look for a path I just end up in a user temp file. There were 3 blocked scripts and all 3 were for the same action but they all ended up with different names. So where I'm at- it does not look safe to enable by path since that looks to just run to a user temp file. I can't white list by name since the scripts seem to generate a different name each time they are ran. Same with hash. The path looks suspect. What do I do?

here's the path- %OSDRIVE%\USERS\ADMIN\APPDATA\LOCAL\TEMP\TMPA5DA.VBSt

 

Anyone know?

 

These can be tricky because of the changing names, but they are happening legitimately. I use the default rule for administrators, get rid of the two user (Everyone) default rules, then Autogenerate rules for users from the Program Files, Program Files (x86) and Windows directories. The path is not suspect. What to do in your case because of the changing file names, I'm not sure, but start by using my method, then test the error sending functionality of Word.

 

I don't understand what you wrote. I have to get a fax sent off and am unable to do so because a script is not allowed to run. If nothing else I'm going to just disable applocker for now.

 

It's a shame if you disable it just because of a problem with Word. Can you provide a screenshot of the error(s) in Event viewer->Applications and services logs->Micropsoft->Windows->Applocker? otherwise please see the screenshots.

*EDIT* it looks like you're running as admin, because in the path you give the user's name is admin. Is it your intent to use AppLocker running as admin or a standard user?

 

I'll try this and see what happens. thanks

 

Good. When you're done you should have a lot of rules similar to the screenshot, which shows just a portion of what I've got. Please note also the default global allow all rule for not only the built-in administrators account but also for the admin account (madisonB\admin) that I created when setting up Windows. You should do the same.

 

So you recommend hash instead of path on scripts? I chose path then seen your screen shot- should I change to hash?

mine looks like the pic now-

 

My intent is to run as admin.

Also, should I do the auto generate rules for the installers, .exe and dll's the same as the scripts?

 

Too bad you're running as admin. However, you could once you auto generate rules for everything, delete the default rule for your admin account (not the Built-in administrator account). Also ,do yourself a favour and don't bother with dll's. You are bound to run into headaches.

 

Because of a recently reported vulnerability with Windows Powershell, I went about looking for the most effective way to block it to fit my ruleset type (because I use mostly auto-generated rules - Publisher, Hash, Path), so "Allow with Exceptions" seemed to be the most robust. It works but I found it is necessary to create the exceptions for all Publisher rules with the "Microsoft Windows Operating System" name in them, including the neosmart (EasyBCD) rule. This is a bit of an inconvenience, but clearly necessary, because adding the exceptions to only the %WINDIR% rule is not enough to prevent Standard users from launching it. Powershell resides under the %SYSTEM32% directory.