AppGuard 4.x 32/64 Bit - Releases

you will still get report until they decide to stop doing home users versions.

 

I would consider switching now to 5.X but would still like to know if one can import the .xml from 4.X. Still waiting for answer on that ...

 

Wait until the next version 5 release to make the switch. There are pending changes that will make it sufficiently different from version 4 that "importing" the appguardpolicy.xml might very well not work.

I can't tell you if it will work until I actually have the next version in my hands.

 

But isn't it better to make the switch now then, while it might work? Or am I missing something.

 

why would you use something now, that might be irrelevant later?

 

It is possible that even the current 5.2.9.1 xml might not be "importable" to the next version. In other words, the upgrade to the next 5.X version might require a complete uninstall\reinstall.

Like I said, I won't know until I actually have the next version in my own hands.

You might as well prepare yourself and expect that you will have to re-build any custom policies.

 

OK, thanks.

Edit: I would rather not mess around right now with new AG anyway. It looks like there may possibly be incompatibility problems with AG in the latest HMP.A beta build 579.

 

If i'm not mistaken and if I recall correctly you don't need to import .xml from v4 to v5 as the .xml is not deleted after uninstalling v4...

 

That would be great, but will await confirmation from @Lockdown.

 

Thank you!

 

Just tested it I can assure you that it will retain the .xml from v4 as i'm now currently using v5 its only temporary as I don't have a license. http://i66.tinypic.com/w9iiq8.jpg.

 

Users maybe have to prepare to "start from the beginning" after the next 5.x-upgrade. Settings will not be retained:

 

Thought @paulderdash was referring to the current v5...my bad

 

@mood @paulderdash and others; it is too early to think about that , Q&A and us (closed-beta testers) don't even have our hands on the next build. So just enjoy the actual one in the meantime; once it will be available , we will give you more infos.

 

Yes, it's too early to think about it

 

OK, thanks @Duotone @mood @guest
But I really do wish BRN would build an export / import function into the next 5.X version to facilitate retention of settings, as requested before in this thread.
To rebuild a custom and hardened .xml would really be a PITA.
I will stay on 4.4.6.1 for now, and just wait and see. No reason to migrate to 5.X now, if it isn't going to benefit me.

 

The export\import will not be implemented this build. When it is introduced, it will be implemented only in the business version.

 

It was HMP.A cryptoguard and wipeguard causing the BSODs. AppGuard and HMP.A are compatible.

 

I asked about it a while back. The answer I got is that they "think" copy-pasting the policy xml will work. "Think" isn't a definitive answer. So the best course of action is to simply wait until I can actually test it for myself.

 

An uninstall of AppGuard leaves the policy xmls behind; it isn't a clean uninstall. The user must manually delete all the AppGuard remnants after an uninstall.

That the policy xmls remain on the system after an uninstall does not automatically mean those xmls will work in the next 5.X version.

 

The hardened xml...

The hardened xml disables vulnerable processes that aren't needed on a day-to-day basis. It applies the principle of reducing your system's attack surface.

What does the hardened xml accomplish in terms of overall security ?

It very likely will block an exploit run sequence at an earlier point in the run sequence than without it. Also, provides increased protections against attacks that use Powershell - like Poweliks.

Finally, adding the writeable C:\Windows directories to User Space protects against malicious payloads from being executed from those directories. If you don't indiscriminately execute unknown shortcuts on your system, then you have little to worry about. I would think most people that visit this thread would not explore an unknown shortcut that unexpectedly shows up on their desktop by launching it - but instead would check Properties > Target.

How's that ?

Here's a single example...

Disabling Powershell in the hardened xml prevents the creation of encrypted keys in HKCU. Allowing Powershell as a Guarded App permits the encrypted keys to be added to the registry, but they cannot execute because AppGaurd blocks creation of their auto-runs.

Bottom line:

With or without the hardened xml, AppGuard protects your system.

Do I need to use the hardened xml if I am using a robust anti-exploit soft ?

Probably not. If you already have a solid anti-exploit soft installed on the system, then using a hardened xml would be tantamount to a "just-in-case" insurance policy. Besides, if a Guarded process is exploited, AppGuard will block the payload from executing, prevent the creation of auto-runs, prevent process memory attacks\tampering, and thereby neuter the exploit payload.

What about the writeable directories in C:\Windows ?

It is recommended to add those to User Space. If a program needs to execute updates or some other legitimate process from one of the directories, you allow that directory. It's a very simple concept - and I don't understand why some users have problems implementing it. The same applies to disabled processes in the hardened xml. If it's needed, then allow it. Most people here know full well that what they are about to allow is safe\legitimate, but some still won't choose the easy workaround, but instead keep trying the same thing over-and-over even though it is apparent that what they are trying to do won't work.

What about protecting appguardpolicy.xml against ransomware ?

Make the appgaurdpolicy.xml directories Private Folders.

I should point out that ransomware is only a threat with AppGuard protections enabled if you use "Allow User Space Lauches - Guarded" via the AppGuard tray icon. I expect most users that visit this thread know not to do this with unknown\untrusted files - so they won't get themselves into trouble in the first place.

So what the hell should I do with the vulnerable process list ?

Other security softs need to be fortified by disabling vulnerable processes a whole lot more than AppGuard.

But AppGuard can be used to protect other security related softs.

How's that ?

For a single example...

Rollback RX is susceptible to malware tampering of bcdedit.exe, bootcfg.exe, etc. To protect Rollback RX you disable boot utilities in AppGuard.

How do I know what to do - when and with which softs ?

Put in the time and effort and learn on your own. Learning by doing will increase your knowledge and experience. IT security knowledge and experience will provide a measure of safety that no security software can provide...

 

Thanks for going into this detail @Lockdown.
Yes, I'm sure more-or-less out of the box AG would be fine, especially in my layered setup and maybe I will revert to this if / when I move to 5.X.
Your posts on the vulnerable processes originally piqued my interest, and I like to play .
I had previously tried adding them to ERP, not AG, but found them easier to maintain in AG, the ability to use * wildcards in User Space being one reason.
But ... all points taken.

 

That is how you learn - by doing. "Playing" = doing = learning. More people should do more of it.

Doing it yourself means you can see with your own eyes - what, when, how, and why. You determine for yourself what is practical, a good idea versus a bad one, what is accurate infos and what is mis-\dis-information, etc. Most importantly, what works for you on your specific system.

 

Should I worry about this block?

 

I have seen these blocks too, and not just for chrome. You can ignore these "c:\windows\rescache"-blocks.