SRP vs VoodooShield

[softie15]

Hi folks, I am trying to understand the following question for Win10 Pro protection.

Say I setup SRP using approach described at
How to make a disallowed-by-default Software Restriction Policy
(and also illustrated in tutorial like one at the end of this post). In short, I allow only things to run from a couple of well known Windows locations that cannot be written to by my user account.

Is there any point in adding VoodooShield to that system? What additional benefits does VS provide then?

I understand VS prevents anything unknown from running but if I already specified I only trust those limited locations and if I cannot even write to them, what additional protection would VS provide?

My apologies if this is a dumb question.

Thanks!

P.S. Youtube video for SRP:

 

[softie15]

Thanks Andy! Looking forward to your answers!

I had not heard of cruelsister's settings. Do you mean this video from Jan 2017? (Sorry I could not find a direct link from her profile, so I googled it).

I'll look into it as soon as possible. In general, I run Comodo Proactive Config with HIPS/FW in Safe Mode and with very tuned Trusted Vendors, but I always look for improvements to the setup. I also use their Sandbox in the form of the Secure Shopping. Would some of the cruelsister's settings be better for smoother work w SRP settings? I don't always use Comodo Auto-Sandboxing functionality because I had some windows-update related issues with it in the past. Perhaps it's time to try it again.

 

[Andy Ful]

Do you have any Windows Updates issues with actual config? Comodo HIPS can sometimes break Windows Updates.

 

[Deleted member 65228]

What I ultimately want to do is to have as secure as possible of a setup for Win 10 Pro + Comodo Firwall/HIPS + Avira AV + Excel/Word + Acrobat Reader + MS PDF writer + Browser (e.g. Firefox) + basic windows utilities (e.g. Notepad/Wordpad/Calculator/Paint).

Literally all you need to do is download and run nothing unless you know it is clean (e.g. trusted source with verification) and to not be click-happy when browsing online, web-based threats can be just as devastating with spear phishing and other alike attacks.

You can have a configuration from the NSA and it will mean nothing if you have bad habits.

 

[cruelsister]

Softie- I'll be releasing a Comodo Setup video this weekend. It will cover Installation, Setup, Browser sandboxing (if you care to do so), and Password protection of Comodo on a shared computer.

I have it done, just deciding on the music (something mellow, preferably minus drums).

 

[shmu26]

Do you see any issues with Disallow rule for cmd.exe?

Disabling cmd.exe can break certain programs or functions, it depends what you are running on your system. It is harder to get away with disabling cmd than it is to disable wscript or powershell.

 

[cruelsister]

Yeah, the trick is to determine WHAT is using cmd and disallow that if it is deemed malicious. Actually this is the same case with wscript, vbs, and Powershell. Dumb protection will just stop these from running. Smart protection will stop the initiator (if malicious).

 

[softie15]

Do you have any Windows Updates issues with actual config? Comodo HIPS can sometimes break Windows Updates.

No issues lately, as I currently don't have auto-sandboxing on. I had issues in the past but it was related to auto-sandboxing, it was never HIPS for me.

You can have a configuration from the NSA and it will mean nothing if you have bad habits.

Do you mean applying NSA baseline? I already applied whatever I felt was relevant from CIS and Australia baselines, but I don't think that's enough protection on its own (and I may have left some holes due to usability or my lack of understanding of certain features). Ideally I want to lock up the system as much as possible in terms of what it can run.

Disabling cmd.exe can break certain programs or functions, it depends what you are running on your system. It is harder to get away with disabling cmd than it is to disable wscript or powershell.

(highlighting mine)

Win 10 Pro + Comodo Firwall/HIPS + Avira AV + Excel/Word + Acrobat Reader + MS PDF writer + Browser (e.g. Firefox) + basic windows utilities (e.g. Notepad/Wordpad/Calculator/Paint). Nothing else needs to run for this (standard) user.

@cruelsister: looking forward to your new video. One feature I am fond of is to always run my browser in Comodo Secure Shopping for sensitive sites and in Virtual box for the rest. Would be curious what you think about capabilities of those. I am not sure if I am smart enough for "smart" protection, but I am more paranoid than most and so I am looking for the best protection I can find given my know-how limitations

 

[shmu26]

@softie15 It is not so hard to check cmd.exe, instead of me sitting here and trying to guess.
Go into the Comodo file list and search for the two instances of cmd.exe (one is in system32 and the other is in syswow64), mark them as unrecognized, and see what prompts you do or don't get. If you don't see both of them in the Comodo file list, it is because it never actually ran on your system -- so there is your answer for that one.
On a x64 system, you very often have two instances of Windows system processes. (one is in system32 and the other is in syswow64)

 

[Andy Ful]

No issues lately, as I currently don't have auto-sandboxing on. I had issues in the past but it was related to auto-sandboxing, it was never HIPS for me.
...
Win 10 Pro + Comodo Firwall/HIPS + Avira AV + Excel/Word + Acrobat Reader + MS PDF writer + Browser (e.g. Firefox) + basic windows utilities (e.g. Notepad/Wordpad/Calculator/Paint). Nothing else needs to run for this (standard) user.
...

The simplest solution would be CF with @cruelsister settings, then on your semi-locked system, you can even drop Avira. But, on Windows 10 this solution did not work - either for you nor for me.
Yet, you can try improving your relationship with CF on Windows 10 Pro, by delaying Windows Updates. Then, you can temporarily turn off CF protection, make Windows Updates, and run CF scan to see if some new files have Unrecognized mark. Next, you can manually change those files to trusted, and turn on CF protection. This should be done once a month.
.
If the above will fail, then it would be better to adopt built-in Windows default-deny security: Windows Defender + Group Policy hardening (SRP, Exploit Guard, blocking macros in MS Office, etc.). That will be more secure and much more stable than your actual setup, but will require some learning.

 

[shmu26]

Cmd.exe i

@softie15 It is not so hard to check cmd.exe, instead of me sitting here and trying to guess.
Go into the Comodo file list and search for the two instances of cmd.exe (one is in system32 and the other is in syswow64), mark them as unrecognized, and see what prompts you do or don't get. If you don't see both of them in the Comodo file list, it is because it never actually ran on your system -- so there is your answer for that one.
On a x64 system, you very often have two instances of Windows system processes. (one is in system32 and the other is in syswow64)

But keep in mind that cmd.exe is used by various Windows functions, such as troubleshooters, for instance. Maybe for updating, too. Also needed sometimes for software installation. So you never know when you will need it.
That's why it is better to restrict it (like in Appguard), or monitor it like CS said, rather than completely block it.

 

[show-Zi]

In the past, I have thought about whether I can monitor cmd and Bowershell in Comodohips.
In paranoid, if I apply the rule 'ask all' to those file, can I monitor the behavior before execution?

 

[softie15]

The simplest solution would be CF with @cruelsister settings, then on your semi-locked system, you can even drop Avira. But, on Windows 10 this solution did not work - either for you nor for me.
Yet, you can try improving your relationship with CF on Windows 10 Pro, by delaying Windows Updates. Then, you can temporarily turn off CF protection, make Windows Updates, and run CF scan to see if some new files have Unrecognized mark. Next, you can manually change those files to trusted, and turn on CF protection. This should be done once a month.
.
If the above will fail, then it would be better to adopt built-in Windows default-deny security: Windows Defender + Group Policy hardening (SRP, Exploit Guard, blocking macros in MS Office, etc.). That will be more secure and much more stable than your actual setup, but will require some learning.

Hi Andy, ideally, I'd prefer to have Comodo (for fw/hips/SecureShopping), Avira (better AV than comodo) AND the SRP for whitelisting. It's possible Comodo will fail me at some point and I'd love to have extra layer(s) of protection help me then. I like running Comodo without auto-sandboxing so I don't have to worry about windows updates. I realize I lose the auto-sandbox feature but hoping my other protections will work sufficiently well. Also, on Comodo forums, people are suggesting that autosandboxing should not be interfering with Windows Updates; so I plan to try that in future, when I have a stable running system fully configured in other ways. If you could help me with understanding SRP based on those questions I had posted, I am hoping to come up with a reasonable whitelisting layer in addition to the other security software.

I think you are saying there is a way to setup Windows Defender / Windows Firewall to provide better protection than Comodo/Avira combo, but I'd like to attack one problem at a a time; and since I have a working Comodo/Avira combo I've used and liked (and again, those extra features like secure shopping in Comodo), I am just hoping for now to learn the best SRP setup that can work with them.

@shmu86, thanks and yes, I was also concerned turning off cmd.exe access in that it may interfere with future updates of any of those software packages, even if so far I did not have a use for it. I guess this software tends to auto-update without user intervention; so I may not even be by the computer when they update (even if I configure Windows to only update on demand). On a side note, I wonder if it's safer to let Windows get updated in background instead of periodically manually logging in as Admin user while being online, and turning off other software just so I can update windows. I'd feel quite exposed then

 

[shmu26]

In the past, I have thought about whether I can monitor cmd and Bowershell in Comodohips.
In paranoid, if I apply the rule 'ask all' to those file, can I monitor the behavior before execution?

You don't need paranoid to monitor them. In Comodo 10 advanced settings, enable embedded code detection for them, and you will get all the prompts you need.
Another way to do it (this works also in earlier versions of Comodo) is to mark them as unrecognized. Make sure to do this with the 2 cmd and the 2 powershell (system32 and syswow64)

Hi Andy, ideally, I'd prefer to have Comodo (for fw/hips/SecureShopping), Avira (better AV than comodo) AND the SRP for whitelisting. It's possible Comodo will fail me at some point and I'd love to have extra layer(s) of protection help me then. I like running Comodo without auto-sandboxing so I don't have to worry about windows updates. I realize I lose the auto-sandbox feature but hoping my other protections will work sufficiently well. Also, on Comodo forums, people are suggesting that autosandboxing should not be interfering with Windows Updates; so I plan to try that in future, when I have a stable running system fully configured in other ways. If you could help me with understanding SRP based on those questions I had posted, I am hoping to come up with a reasonable whitelisting layer in addition to the other security software.

I think you are saying there is a way to setup Windows Defender / Windows Firewall to provide better protection than Comodo/Avira combo, but I'd like to attack one problem at a a time; and since I have a working Comodo/Avira combo I've used and liked (and again, those extra features like secure shopping in Comodo), I am just hoping for now to learn the best SRP setup that can work with them.

@shmu86, thanks and yes, I was also concerned turning off cmd.exe access in that it may interfere with future updates of any of those software packages, even if so far I did not have a use for it. I guess this software tends to auto-update without user intervention; so I may not even be by the computer when they update (even if I configure Windows to only update on demand). On a side note, I wonder if it's safer to let Windows get updated in background instead of periodically manually logging in as Admin user while being online, and turning off other software just so I can update windows. I'd feel quite exposed then

Either way to update Windows is good, but don't be afraid of your admin account. It is the safest way to do any action that asks for your admin password or pin. It is much riskier to type in your admin password while in SUA, than it is to switch to admin account with nothing special running over there in that account.
If you enter your password while in SUA, malware lurking in the background can take advantage of the elevation. But if you switch to admin account, and you have nothing special running over there, you are safe.

 

[cruelsister]

Show-Zi- There is no need to monitor cmd, Powershell, vbs, or wscript individually in CF if you are using the sandbox. The initiator (if malicious) of these things will be contained already, as would any cmd or PS script that occurs subsequent to the initial malware run.

 

[show-Zi]

@shmu26
@cruelsister
Thank you for your kind explanation.

 

[Andy Ful]

(1) For my desired setup, what are

(1a) recommended DFT list?
Default list from the manual: WSC, WS, VB, URL, SHS, SCT, SCR, REG, PIF, PCD, OCX, MST, MSP, MSC, MDE, MDB, LNK, JAR, ISP, INS, INF, HTA, HLP, EXE, DLL, CRT,CPL, COM, CMD, CHM, BAT, BAS, ADP, ADE
+ MSI
+ PS1, PS2, PSC1, PSC2, PS1XML, PS2XML
+ JS, JSE, VBE, VBS, WSF, and WSH
+ anything else??

(1b) recommendations as to which sponsors to Disallow? E.g. regedit.exe, others? all that are listed in Hard Configurator?

(2) What's the difference between
(2a) "blocking a sponsor" like powershell
(2b) manually creating SRP Disallow rule for "powershell.exe" and "powershell_ise.exe"
(2c) adding powershell extensions (PS1, PS2, PSC1, PSC2, PS1XML, and PS2XML) to DFT
(2d) <No PowerShell Exec.> option in Hard Configurator?

My understanding:
- 2a=2b
- 2c is complimentary to 2a/2b and both act on User Space files only (2b seems more powerful than 2a/2b)
- 2d simply sets HKLM\Software\Policies\Microsoft\Windows\PowerShell!EnableScripts to 0 to prevent any powershell execution, including those from System Space. I.e. 2d is even more powerful than others?

Why does this Warning in the manual say to NOT use (2c) + (2d)? "Do not add PS1, PS2, PSC1, PSC2, PS1XML, and PS2XML extensions, if <No PowerShell Exec.> is set to ‘ON’." Later however it says "In the unsafe environment, all the above restricting options should be activated, for the maximum PowerShell mitigation."...

So if I want as-safe-as-possible environment, should I have all of these settings setup?

More on (2d). The Hard Configurator manual says: "In Windows 64Bit there are two PowerShell Hosts (32Bit and 64Bit), but both are disabled/enabled by the below registry key"
- What about HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell key? Is it not used?
- Rather than edit registry would you recommend using GPO Admin Templates > Windows Components > Windows PowerShell > Turn on Script Execution -> set to Disabled?

So let's start. The DFT list from (1a) should be enough for your config.
Blocking sponsors means that you apply the general Disallowed rules (= rules without a path) for the vulnerable EXE files. For example, two Disallowed PowerShell rules look like:
powershell.exe
powershell_ise.exe
Those rules will block execution as standard user of the above executables in any folder. So (2a) = (2b).
(2d) <No PowerShell Exec.> means that execution of the PowerShell scripts (PS1, etc.) located on your disks will be blocked, but powershell.exe and powershell_ise.exe can be executed. So, the malicious Office documents will be allowed to run PowerShell commands or filelessly download the PS1 scripts from malicious websites and run them from memory.
(2d) includes (2c) and additionally blocks running scripts via command line, so If (2d) is activated then (2c) will do nothing.
Generally, (2b) is not more powerful than (2d) because powershell.exe can be copied to another location under a different filename and used to execute PS1 script - (2b) cannot stop this, but (2d) can.
There is also the second difference : (2b) works only if PowerShell is executed as standard user and (2d) works also when PowerShell is run as admin.
So, both (2b) and (2d) should be activated for security reasons Yet, (2b) can block some software from running PowerShell commands, so it should be tested if everything works well.
The options (2b), (2c), and (2d) works independently, and in the unsafe environment they may be all activated. But, indeed (2c) will be useful only when one malware will deactivate (2b) + (2d) and another malware will try to fool the user by convincing him to run PS1 script - that scenario is improbable in the wild, and rather impossible in the safe environment.

 

[softie15]

So let's start. The DFT list from (1a) should be enough for your config.
Blocking sponsors means that you apply the general Disallowed rules (= rules without a path) for the vulnerable EXE files. For example, two Disallowed PowerShell rules look like:
powershell.exe
powershell_ise.exe
Those rules will block execution as standard user of the above executables in any folder. So (2a) = (2b).
(2d) <No PowerShell Exec.> means that execution of the PowerShell scripts (PS1, etc.) located on your disks will be blocked, but powershell.exe and powershell_ise.exe can be executed. So, the malicious Office documents will be allowed to run PowerShell commands or filelessly download the PS1 scripts from malicious websites and run them from memory.
(2d) includes (2c) and additionally blocks running scripts via command line, so If (2d) is activated then (2c) will do nothing.
Generally, (2b) is not more powerful than (2d) because powershell.exe can be copied to another location under a different filename and used to execute PS1 script - (2b) cannot stop this, but (2d) can.
There is also the second difference : (2b) works only if PowerShell is executed as standard user and (2d) works also when PowerShell is run as admin.
So, both (2b) and (2d) should be activated for security reasons Yet, (2b) can block some software from running PowerShell commands, so it should be tested if everything works well.
The options (2b), (2c), and (2d) works independently, and in the unsafe environment they may be all activated. But, indeed (2c) will be useful only when one malware will deactivate (2b) + (2d) and another malware will try to fool the user by convincing him to run PS1 script - that scenario is improbable in the wild, and rather impossible in the safe environment.

Awesome info for sections (1) and (2)! Thanks! I am sure I will be coming back to this post a number of times...

Follow up questions for this post:

- any suggestions for (1b)?

- to implement (2d), I only need to set HKLM\Software\Policies\Microsoft\Windows\PowerShell!EnableScripts to 0, right? Nothing else is needed.

- with (2b), you mentioned "powershell.exe can be copied to another location under a different filename and used to execute PS1 script". Assuming SRP is effectively setup to deny execution on all directories that are writable (e.g. this means I applied your Hard Configurator 'Protecting Windows Folder' section rules for C:\Windows subdirectories that are writable), how is it possible for some software to copy powershell.exe to another location and then execute it? In other words, if malware copies to user space, it cannot execute it from there; and it also cannot copy to system space as it's not writable... ?

- You mentioned "(2b) can block some software from running PowerShell commands". I assume you mean (2b) is more likely to interfere with system stability than (2d). But if I followed your other points right, I would have thought (2d) is more likely to interfere because it prevents Admin powershell executions, unlike (2b). Am I missing something?

Again, thanks for the help and all the details!

 

[shmu26]

Show-Zi- There is no need to monitor cmd, Powershell, vbs, or wscript individually in CF if you are using the sandbox. The initiator d or PS finction (if malicious) of these things will be contained already, as would any cmd or PS script that occurs subsequent to the initial malware run.

Nevertheless, embedded code protection of Comodo is very good for stopping exploits that start, for instance, as macros in a Word doc. This way, the exploit is nipped in the bud, before it flowers and bears fruit.

 

[shmu26]

Do you have any Windows Updates issues with actual config? Comodo HIPS can sometimes break Windows Updates.

That's indeed a problem for advanced users of HIPS, but for CS settings, I would just make an exception in autocontainment for Windows folder and maybe Programs folder too. That should pretty much solve the issue of unrecognized files that were born in a Microsoft update.
Native Windows protection + a decent AV is enough protection for those folders, IMO.

 

[Andy Ful]

Awesome info for sections (1) and (2)! Thanks! I am sure I will be coming back to this post a number of times...

Follow up questions for this post:

- any suggestions for (1b)?

- to implement (2d), I only need to set HKLM\Software\Policies\Microsoft\Windows\PowerShell!EnableScripts to 0, right? Nothing else is needed.

- with (2b), you mentioned "powershell.exe can be copied to another location under a different filename and used to execute PS1 script". Assuming SRP is effectively setup to deny execution on all directories that are writable (e.g. this means I applied your Hard Configurator 'Protecting Windows Folder' section rules for C:\Windows subdirectories that are writable), how is it possible for some software to copy powershell.exe to another location and then execute it? In other words, if malware copies to user space, it cannot execute it from there; and it also cannot copy to system space as it's not writable... ?

- You mentioned "(2b) can block some software from running PowerShell commands". I assume you mean (2b) is more likely to interfere with system stability than (2d). But if I followed your other points right, I would have thought (2d) is more likely to interfere because it prevents Admin powershell executions, unlike (2b). Am I missing something?

Again, thanks for the help and all the details!

All sponsors can be dangerous, but when default-deny SRP is activated, this usually requires exploiting the system or exploiting the application that opens files with active content (Web pages, Office documents, PDF files, etc), or running malicious shortcut. If you protect those vectors of infection, then you can block as standard user PowerShell and CMD executables via SRP, and block Windows ScriptHost + PowerShell Script execution via Group Policies. This will also require checking if some software does not need to run BAT, CMD, PS1 or VBScript files. If you are the careful person then blocking sponsors is not required in the safe environment (home computer connected to NAT router).
.
If you will activate default-deny SRP with properly protected Windows subfolders, then the copy of PowerShell started as standard user will be blocked in the Userspace.
.
Blocking PowerShell sponsors via SRP can block the application from running PowerShell executables as standard user, so PowerShell cannot execute commands and run scripts. That does not involve system instability, because usually Windows tasks are not run as standard user.
.
You should decide if you want using reg tweaks or Group Policies (via gpedit.msc) to apply Windows policies.
You cannot use both solutions for the same policy. Hard_Configurator operates directly in the Registry and does not use Group Policies, so when using Group Policies you must find the right entries for every Hard_Configurator option.