A Few Questions Regarding Appguard, Applocker, and EMET.

I'm currently planning a security overhaul and have been doing a good deal of research into a variety of security approaches. Originally, I had planned on using a limited user account, Applocker, EMET, and Sandboxie however now I'm interested in Appguard. Right now, I can't decide on which combination of these approaches I should go with. Appguard seems pretty similar to LUA + Applocker. I do understand that Appguard has a few more features like privacy mode and MBR protection however the main focus of Appguard seems to be its ability to prevent things from executing from user space. Applocker takes care of this quite well, with the hotfix of course. My knowledge of Appguard is limited, but guarded applications can only write to user space, correct? If that is the case, then doesn't running under a LUA automatically make everything "guarded" because that is the only location that LUA's have write access to (with a few exceptions)?

Now to throw in EMET, is Appguard's memory guard the same thing as SEHOP in EMET?

One final question is about Appguard's memory read protection. How critical of a feature is this? I don't really know in depth how malware can attack a computer, but it seems to me that this would only be important if I was using Truecrypt or Bitlocker.

Hopefully by the end of this thread, I will have picked my approach to malware protection

 

Wanna know a secret? If you don't play high end games, run Linux and skip ALL of the security junk. Mint is nice, Mageia is highly secure, and it will run much faster due to no overhead from protection apps.

If you insist on running Windows, download from reputable sources, don't surf porn, and avoid cracks and torrents, keep your apps updated, run Chromium/Chrome, and is unlikely the average person will become infected. Toss in a nice AV with a URL-Inspection system if you like, but that's really all that is needed IMO. These days I pay more attention to products with robust URL filtering, as they provide much of the front end to your system, and can greatly reduce the chance of infection. Commtouch(Bullguard) is top kit, but there are plenty of other options out there such as host files, prevx, threatdefender, etc.

Shouldn't need anything more than that.

 

@Crusher
When you own an ultimate windows, it is possible to blend a windows build-in security setup which sort of (except for memory protection) equals AppGuard.
Using windows internals is the hard way, just click on my sig, it is explained with a picture. In stead of sandboxie, I use the internal sandbox of Chrome.

The easy way (and when not having Ultimate) would be buying AppGuard, some members have coupled this with Sandboxie (on x64), easy way on x32 would also be DefenseWall (no x64).

@Bodhitree
Wanna know a secret, same can be done on Windows when buying ultimate

 

@Kees, Thanks for the reply. I have been looking into what you and Sully have been doing and I really dig it. While I have mentioned this, what is the deal with PGS and Lazy Admin? Did Lazy Admin replace PGS because the mrwoojoo site is down and I only found one mirror of PGS? I was under the impression that Lazy Admin was a download similar to PGS until I stumbled upon this. Is that what Lazy Admin is?

I do own x64 ultimate thanks to the university book store discount! I knew Appguard was similar, thanks for confirming. I do like the idea of using as much of Windows' features as possible and so I will do some more digging into Lazy Admin. One question that I have about the picture in your signature is what is the point of the "deny execution" ACL configuration? Isn't that covered by the SRP setup? The same thing goes with using GP to block autorun. Is it just for redundancy, in which case wouldn't you apply the same ACL rules to all folders in user space?

I'm a diehard Firefox fan so I'm not too sure if I would be willing to switch to Chrome. I have been using Sandboxie for a while now and find it very intuitive and easy to use. We'll see which direction I go. I also seem to recall an article stating that one of the upcoming Firefox releases will have a sand boxing feature similar to Chrome. I will have to find it.

 

Lazy Admin was intended as idea behind PGSv2. I know there is a prototype, but Sully is to busy doing work to finish this, so don't expect it to come any more.

Yes ACL is redundant, idea is at least two security mechansims ar involved to keep malware from entering/executing. It adds a Deny "execute file/traverse folder" for everyone to the threatgate folders. When setting a deny on root directory, windows image backup refuses to run (for backup, restore works).
USB has a deny "execute access" in Group Policy as 2nd barrier.

Lazy Admin is moving, currently I succeeded to blend SRP and AppLocker perfectly together (coverage, fine tuning, performance). The one in my sig is currently idea beheiond Lazy Admin, because I am an lazzy admin to.

 

Hi Kees,

nice picture illustrating sound and effective security, but one question...

...how have you managed to use SRP and AppLocker together?

Btw @ Crusher,

I would recommend utilize what your O/S has to offer + EMET.

 

When you say root directory, are you referring to C:\Users or C:\? What I meant was, shouldn't you deny "execute file/traverse folder" to all folders except for "Program Files" and "Windows"? To me, this would work because when using SRP or Applocker for white listing, those are the "Default" rules.

This is exactly what I am planning on doing now. I even consider EMET to be what Windows has to offer as it just makes it easier to enforce everything. I know you can download a hotfix from Microsoft that enables SEHOP, so I would assume that ASLR is already a built in feature that is not enabled. DEP is already built in as well as you can turn it on or off by going to "Adjust the appearance and performance of Windows." Actually, I'm going to enforce DEP the way Mechbgon says to and that is selecting "Turn on DEP for all programs and services except those I select" in the menu previously stated. If a program doesn't work, you just add an exception. To me, this is easier than explicitly adding programs to the list in EMET in order to add DEP.

 

@Crusher
On C:\ image won't start (it will run emergency recovery though). For ease of imaging and data backup and recovery, I allways move the user files to a data partition (including the email files of Outlook). Because SRP is not for admin, ACL is a different angle (to enhance granularity of protection) for implementing a deny execute for everyone. Also by playig with ACL, AppLocker and SRP and UAC (deny elevate unsigned), the protection varies from user level to kernel level. These mechanisms do not interfere, but enforce each other.

@Watt0114
I have a old dual core E5200 which does feel the difference when using dll protection on kernel level by AppLocker, it deals well with "all files" (all traditional executables) on SRP. I use UAC deny elevation of unsigned and with this setup, there is no irritating delay of a few secs when a signed programs requests elevation.

This is basically the trick

Software Restriction Policies
- Security levels: set default level to Basic User
- Additional rules: use only the default rules (generated after adding a SRP)
- Enforcement: All software files, All users except local administrators

Application Control Policies
- Enforcement: Exe and MSI

- Executable rules:
a) Allow everyone in Path Window and Program Files ==> default rules
b) Allow Administrators in Path %UserProfile%\AppData\Local\Temp\*
c) Allow Administrators in Path G:\* ==> my DVD drive
d) Deny Administrators in Path %UserProfile%\AppData\Local\Temp\*
- except Signed programs from Microsoft
- except Signed programs from Surfright/HitmanPro
- except Signed programs from Google/Chrome
e) Deny Administrators in Path G:\*
- except Signed programs from Microsoft

- Windows Installer Rules
a) Allow everyone from %Systemdrive%\Windows\Installer\* ==> default rule
b) Allow Administrators in Path %UserProfile%\AppData\Local\Temp\*
c) Allow Administrators in Path G:\* ==> my DVD drive
d) Deny Administrators in Path %UserProfile%\AppData\Local\Temp\* ----with same execeptions as with EXE
d) Deny Administrators in Path G:\* ----with same execeptions as with EXE

So now I have Best of Both worlds
a) Drive by protection (ACL in specified folders) for Everyone (optionally enforced with 1806 trick download protection)
b) Deny execute on all executables (SRP) for users in userspace
c) Deny elevate of unsigned (UAC) to protect adminspace (safe places)
d) Allow run from Temp and DVD for Admin on selected signed programs from
trusted publishers (and an implicite deny on all other directories in user space)

 

EMET sets general protection of OS, system wide, the extra EMET protection is set per application, see pic I only bothered to add threatgate programs to EMET

 

I forgot to mention in my last post that I was intending on running mainly under LUA which is why I had asked about denying everything but "Windows" and "Program Files" with ACL. I would expect there to be issues if you locked down those folders with ACL! As for EMET, I seemed to recall something different. I hadn't messed with it in a while. Thanks for pointing that out, and thanks for posting your "trick" and all the other help. I think I'm going to end up applying your Lazy Admin setup for my admin account and then running a LUA with applocker and ACL whitelisting the Windows and Program Files folders, keeping the other stuff of course.

 

Now I see what you mean, Kees, thanks! Your approach is nice. Use what's already available. No need for fluff

 

Certainly good for experienced home users but a nightmare to manage on large Enterprise Network as there are just way too many exceptions and rules to monitor and manage and users calling in for help. Managing the occasional infection (at least for me) turns out to be a lot less work involved.

 

It looks okay to me but i could be missing something; secure but not shackling the user. The path rules contain lots of wildcards for flexibility for using programs from common installation directories and when files change due to updates. The only one that confuses me is:

under -Executable rules

Code:

d) Deny Administrators in Path %UserProfile%\AppData\Local\Temp\*

it contradicts b)

maybe it's supposed to be:

Code:

d) Deny [b]Users[/b] in Path %UserProfile%\AppData\Local\Temp\*

?

 

No user deny
When there is no (allow) rule, Applocker handles this as implicite DENY. So deny for the User is not nessecary. Plus SRP also applies a deny execute (because of the basic user default level), preventing elevation requests to Admin. When there ar no Applocker rules, the SRP rules are applied (so Applocker prevails over SRP in conflict situations). So in my example AppLocker determines EXE + MSI files, SRP handles all the other executable extensions (com, dll, hta, etc)


Admin Allow + Deny on same path
With this double allow + deny with the exceptions specified in the Deny it is possible to setup a granular deny/allow set on Path and Publisher
a) Allow Admins on a certain directory
b) Deny Admins on a certain directory, except some publishers you define (like in the Example, Microsoft all programs, Google only for Chrome, Surfright only for HitmanPro).

 

Well in the Netherlands, for corporate enterprises, the value of the data lost is what determines the cost benefits equation, not just the cost for support.

For the central management of group policies there are enough tools to remotely manage and deploy them, there are also tools for giving old applications admin rights on selected PC's.users, see http://www.beyondtrust.com/Home/AllProducts/

 

One tip: don't mess with ACL on Windows and Program File directories. Use SRP and Applocker instead to place allows (which is the default) on those folders.

 

That is what I have been trying to say! I meant all folders but those two for ACL and only those two folders for SRP/Applocker.

 

Okay, good! English/American is not my first language, missed that.

 

Thanks for the clarification, but now after understanding that you are combining both AppLocker and SRP, and the way you've explained the double Allow + Deny with exceptions, I'm really puzzled

• I understand that no Allow for specific users is implicit Deny. I avoid Deny rules almost completely, other than for USB drives, so I use a Deny %HOT% rule.
• The way I understand it, when AppLocker and SRP policies are combined in the same Domain, SRP policy is ignored.
• Deny rules override Allow rules in all cases, so I don't know how your double rules can function the way you intend them to.

Sorry, maybe I don't see the forest through the trees but I'm confused about some things in your policy.

I know you want to run as "Lazy Admin" and that's perfectly fine because of the user token placed on the admin user when UAC is used, but for under the %appdata% directories, why not just create Allow rules for the signed file types, and use specific Path rules for anything else? Alternatively, use Deny for that location with exceptions for the signed files as well as required Path rules. Hash could be used as well, but they are a headache to manage.

The example Deny w/Exceptions rule below is not the best, but it illustrates where the Path is denied and exceptions for both Publisher and Path rules are made within one rule. Why not go something like this route?

 

I noticed that from some of the screen shots you've posted. Not a problem!

 

Agreed but many other ways to manage the risk without causing expense in other areas. I'm well aware of group policies and the tools - I'm also the Administrator of KiXtart.org (actually in the Netherlands) where most of us are Network Admins.

For every policy you invoke the domain and the local computer take a small hit in performance.

Not recommended but even if one allowed the user to be a local admin on the system and didn't install antivirus.

If I have the users data backed up continuously and a good imaging program I can reimage the computer faster than I can remove some infections.

There are also methods to fully automate the process remotely. I can pick for example 10 computers that are having any type of issue whether it be malware or software corruption and tell them to reboot and reimage themselves on reboot and be back up and on the domain and running in under 15 minutes without user intervention except to say yes or no to do it.

Anyways... most Network Admins are already up and running and doing things the way the company or previous admins have set it up and can certainly make up their own minds how they want to mange it. I'm not trying to convince any Admins to use or not use this method for their networks.

I have very few malware related issues and very few help desk calls. Myself and one other tech manage about a half thousand desktops and a few dozen servers in 3 different geographical locations without using policies and most user requests are still answered in under 4 hours so overall I think we're doing okay.

Cheers

 

OKAY

First %HOT% can't find a reference on this.


Secondly, changed the rules (see image), making it easier to read.

Still facing one problem: the installer of ZeroVulnability Lab (ExploitShield-Setup.exe) has a strange exception: when I add an publisher or hash rule it does not work like HitmanPro or Piriform:
- Allow Administrators on Publisher "ZeroVulnerabilityLabs, Inc. etc..." it does not install with Run as Admin
- Allow Administrators on Publisher "all signed programs" it does not install with Run as Admin
- Allow Administrators on Hash of ExploitShield-Setup.exe. it does not install with Run as Admin
- Only a blank allow Administrators on Path "C:\Users\Kees\AppData\Local\Temp\*" does lead to a succesfull install,

Any ideas how to tackle this?

 

Hi Kees,

for %HOT%... http://technet.microsoft.com/en-us/library/ee460944(v=ws.10).aspx

As for the rules you show, they may be too restrictive for Administrators. i'll have to see later (have to go to work soon). If the programs you allow for consist of only digitally signed files, then you should be oky, but there may be some that include both signed and unsigned, so your Publisher-only rules are too limiting. This is why the defaults for AppLocker allow administrators full Path as "*", but yours are limiting to Publisher only. Hope this makes sense.

EDIT

Just a little experiment: changed the default Built-in\administrators allow to run all files "*" to Publisher only, Techsmith, then tried installing Snagit executable installer (which I created the Publisher rule from) and AppLocker denied me. Event Viewer showed that the installer attempted to execute a dll under the User's Temp folder. It looks like you need the global allow "*" path for Built-in administrators if you want to install programs. There's usually more than just the signed files going on during an install so a Publisher rule is too restrictive.

 

Kees, may you tell something about this: https://www.wilderssecurity.com/showthread.php?t=333016&page=3 post n. 53 ? Thanks.

 

See PM

Good suggestions , I reordered my rules along the ideas you mentioned and this works with less rules, see picture.

AppLocker: Users are allowed to run signed programs only, Admins all from safe places, allowing admins to elevate only signed executables AND installing from Temporary Folder of User and Admin limited to a set of trysted publishers/programs.
SRP: Run basic user (deny execution outside Windows and Program Files for Users), allowing Admins to use to Run as Admin

It is more restrictive as running basic user and at the same time offers more freedom by allowing installing/updating selected programs/publishers through "run as admin" UAC elevation in same profile (from Temp dir and Removable Drive).

Truely a Lazy Admin setup

thx