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]

...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...

Thanks @Andy Ful , I always like to assume I am on insecure host and I am NOT careful ;-)

Sorry, but I was not exactly sure how to read above quote: are you suggesting that this is the most stable and safe setup:
- for CMD, block sponsor cmd.exe
- for WSH, block execution via Enable = 0 for the two HKLM\SOFTWARE\*\Windows Script Host\Settings keys
- for Powershell, do both - block sponsors ("powershell.exe" and "powershell_ise.exe") AND block execution via HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell key
?

I am hoping when you get a chance you could also answer the rest of my questions (4,5,6,7) in the earlier post. I appreciate your thoughtful and detailed responses!

In the mean time, I started applying the settings. With my simple Default-Deny SRP (no sponsor blocking or other denials of executions so far), I noticed that when I try to Run-As-Admin an empty x.bat file in User directory, it still gets denied. This is a surprise to me, since I thought Run-As-Admin could still run stuff from everywhere (I made sure locals admins are not included in Enforcement). But I guess not... (This video author ran into the same issue at 3:50, but did not really explain it away.)

To avoid polluting this thread, I also started a separate thread with some details I found on properly protecting Windows folder with SRP.

Best Regards,

Justin

 

[Andy Ful]

Thanks @Andy Ful , I always like to assume I am on insecure host and I am NOT careful ;-)

Sorry, but I was not exactly sure how to read above quote: are you suggesting that this is the most stable and safe setup:
- for CMD, block sponsor cmd.exe
- for WSH, block execution via Enable = 0 for the two HKLM\SOFTWARE\*\Windows Script Host\Settings keys
- for Powershell, do both - block sponsors ("powershell.exe" and "powershell_ise.exe") AND block execution via HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell key
?

Yes. Additionally, when you set SRP Default Security Level to "Basic User" (or Disallowed) then PowerShell is automatically set to ConstrainedLanguage mode.

I noticed that when I try to Run-As-Admin an empty x.bat file in User directory, it still gets denied.
...

That is normal for files with extensions on DFT list (except EXE). If you want to "Run as administrator" the BAT and CMD files then simply remove those extensions from DFT. They will be still protected via blocked sponsor (cmd.exe).
If you will have no other questions we can talk about next points.

 

[softie15]

- In Autoruns, I see cmd.exe is checked under HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\AlternateShell. Would blocking cmd.exe cause any issues with this? (hoping not based on experiment below)

- From my reading on WSH, it seemed to "only" be related to script engines like ActiveX and JScript, which I would guess Windows and my limited set of apps do not normally need. Curious why you think blocking WSH sponsors (cscript.exe and wscript.exe) may lead to system instability.

Minor side notes:
- probably does not make a difference, but I decided that instead of MS Office, I will use LibreOffice instead
- I changed File Rating of cmd.exe (in System32 and SysWOW64), System32...powershell.exe, System32\cscript.exe in Comodo to Unrecognized. (Comodo did not list other sponsor variants for these). Reboot succeeded! Phew. So far, not a single popup on those. I have not tried updates yet (everything's already updated) but ran a few apps without issues.

If you will have no other questions we can talk about next points.

Awesome! Ready! (The ones above are the last minor ones)

 

[Andy Ful]

- In Autoruns, I see cmd.exe is checked under HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\AlternateShell. Would blocking cmd.exe cause any issues with this? (hoping not based on experiment below)

No.
.

Curious why you think blocking WSH sponsors (cscript.exe and wscript.exe) may lead to system instability.

.
I do not think that blocking WSH (in any way) may lead to system instability in the normal home computer.
.

- probably does not make a difference, but I decided that instead of MS Office, I will use LibreOffice instead

.
You are safe from DDE vulnerability, OLE will be blocked by SRP. Anyway, you have to be careful and do not let executing macros.
.

- I changed File Rating of cmd.exe (in System32 and SysWOW64), System32...powershell.exe, System32\cscript.exe in Comodo to Unrecognized. (Comodo did not list other sponsor variants for these). Reboot succeeded! Phew. So far, not a single popup on those. I have not tried updates yet (everything's already updated) but ran a few apps without issues.

.
You should block also wscript.exe and powershell_ise.exe .
Some Windows scheduled tasks and some hardware updates (not Microsoft software) can use PowerShell, so you have to be cautious about blocking powershell.exe via Comodo.
When powershell.exe is blocked via SRP the above processes will bypass SRP protection, because usually, they are applied with admin rights.

 

[Andy Ful]

The last part of my previous post is also true when blocking cmd.exe via Comodo.

 

[softie15]

I do not think that blocking WSH (in any way) may lead to system instability in the normal home computer.

Thanks for confirmation! I had thought you implied WSH sponsor blocking may lead to instability, because (my interpretation of) your prior post recommended to block WSH execution for all but did not mention blocking sponsors (cscript.exe and wscript.exe)... unlike say, powershell, where you recommended both, blocking sponsors and the general execution via group policy / registry.

With this new clarification, I think you might be recommending to block WSH at both sponsor level and via registry/GPO without introducing any likely system instability (even if for a small increase in overall protection), is this right?

Side question this reminds me of: I noticed in Autorun that gathernetworkinfo.vbs is executed. Thankfully, your Hard Configurator guide reassures us that this one is not important. Do you happen to recommend trying to remove it from Autorun or via some proper way, or just letting it getting blocked / generating some noise in event viewer?

You should block also wscript.exe and powershell_ise.exe

Yes, I would have, but Comodo did not show their ratings among File Ratings. I am guessing because no execution had encountered these, and Comodo's own original scan did not deem useful to rate these files in any way for some reason... ? In any case, this was meant just as a test per @shmu26 recommendation to see what potential uses are out there, but I plan to reinstate Trusted ratings in Comodo for these and instead use SRP and block executions per your other recommendations.

Some Windows scheduled tasks and some hardware updates (not Microsoft software) can use PowerShell, so you have to be cautious about blocking powershell.exe via Comodo. When powershell.exe is blocked via SRP the above processes will bypass SRP protection, because usually, they are applied with admin rights.... also true when blocking cmd.exe via Comodo.

Ahh, good point, esp since I would not want scheduled tasks to fail due to Comodo interference!

This is why I assume you did not want to block cmd.exe via registry for all users. (Side note: I hope I can safely block cmd.exe for Non-Administrators only (via special mmc GPO Snap-in for Non-Admins only) in Administrative Templates -> System -> 'Prevent access to the command prompt')

However, I thought above you recommended blocking Powershell via Group policies (not sure which group policies, but I assume you meant for all users, or alternatively via HKLM\Software\Policies\Microsoft\Windows\PowerShell!EnableScripts key and perhaps also with HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell key).

Would not Group Policy / registry restriction on Powershell conflict with such scheduled tasks / hardware upgrades?

 

[Andy Ful]

If you apply Windows policies to block WSH and PowerShell script execution, then execution from disk both VBScript files and PowerShell scripts will be blocked. Furthermore, executing WSH by the command line is blocked, but executing PowerShell by command line is not. So additionally, the PowerShell sponsors should be blocked.

Yes, I would have, but Comodo did not show their ratings among File Ratings.

That is strange. It should be an option to add the file to the File Rating list. Can not you run those files manually to trigger Comodo rating?
.

This is why I assume you did not want to block cmd.exe via registry for all users. (Side note: I assume / hope I can block it for Non-admins only (via special mmc template) in Administrative Templates -> System -> 'Prevent access to the command prompt')

You cannot block CMD for all users via registry entry in HKLM. It is possible to do it for every user via registry entries in HKCU (for every account). The safer method is blocking cmd.exe via SRP.
.

However, I thought above you recommended blocking Powershell via Group policies (not sure which group policies, but I assume you meant for all users, or alternatively via HKLM\Software\Policies\Microsoft\Windows\PowerShell!EnableScripts key and perhaps also with HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell key).

Would not that conflict with such scheduled tasks / hardware upgrades?

Good point. This policy does not block PowerShell completely. It allows running PowerShell commands and cmdlets. But, even sometimes (rarely) this can interfere with some scheduled tasks / hardware updates. My wife uses this setting without problems (2 years).

 

[shmu26]

That is strange. It should be an option to add the file to the File Rating list. Can not you run those files manually to trigger Comodo rating?

Yes, running the file manually will make it appear on the file rating list.
If it isn't there, that means it never runs, so you probably can block it without issues.

 

[softie15]

Man, @Andy Ful , you are replying fast! I am sorry I must have been still editing / clarifying my post when you started your response

Also, thank you so much for bearing with me here... So, let me see if I get it now.

Big Picture

For WSH, we COULD restrict by both, the two HKLM\SOFTWARE\*\Windows Script Host\Settings keys AND blocking 2 sponsors but I think you are saying the former would cover the latter, and thus blocking 2 sponsors becomes unimportant. But there are no downsides in doing both, right?

For Powershell, blocking via changing registry might rarely be an issue for a scheduled task but personal experience shows it unlikely to be one. Blocking sponsors adds further security and thus should be done for improved security.

For CMD.exe, even if it were possible, it would have been too unstable to block at registry level for all. So just block "cmd.exe" sponsor. But I think it does not hurt to also block it at HKCU level, right? (Might even help if someone manages to rename cmd.exe?)

I hope I am getting it now!

Small questions that remain from this are:

- For powershell blocking via registry, your guide mentions blocking via HKLM\Software\Policies\Microsoft\Windows\PowerShell!EnableScripts key. Should HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell key also be used?

- I noticed in Autorun that gathernetworkinfo.vbs is executed. Thankfully, your Hard Configurator guide reassures us that this one is not important. Do you happen to recommend trying to remove it from Autorun or via some proper way, or just letting it getting blocked / generating some noise in event viewer?

 

[Andy Ful]

For WSH,... I think you are saying the former would cover the latter, and thus blocking 2 sponsors becomes unimportant. But there are no downsides in doing both, right?

.
Yes. Blocking only via policy is slightly more convenient. You can enable/disable it without logging off from the account.
.

For Powershell, blocking via changing registry might rarely be an issue for a scheduled task but personal experience shows it unlikely to be one. Blocking sponsors adds further security and thus should be done for improved security.

.
Yes.
.

For CMD.exe, even if it were possible, it would have been too unstable to block at registry level for all. So just block "cmd.exe" sponsor. But I think it does not hurt to also block it at HKCU level, right? (Might even help if someone manages to rename cmd.exe?)

.
You cannot copy cmd.exe to the Userspace and run - it won't run even on the standard computer without Comodo and SRP. Generally, the experienced user can block WSH and CMD (via SRP, Comodo or Policy), because nothing important in Windows system uses them. Some 3-rd party software can use them for managing printers, USB loaders, services, etc., so the events should be monitored and whitelisted.
.

- For powershell blocking via registry, your guide mentions blocking via HKLM\Software\Policies\Microsoft\Windows\PowerShell!EnableScripts key. Should HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell key also be used?

.
Changing the first key automatically changes the second. That is true for PowerShell but not for WSH.
.

- I noticed in Autorun that gathernetworkinfo.vbs is executed. Thankfully, your Hard Configurator guide reassures us that this one is not important. Do you happen to recommend trying to remove it from Autorun or via some proper way, or just letting it getting blocked / generating some noise in event viewer?

.
I recommend not removing it from autoruns. I can recommend for all blocked scripts, from time to time temporarily turn off blocking PowerShell, CMD, WSH, etc. and let Windows do what it wants to do.

 

[softie15]

Great! Thank you for clarifications!

... Some 3-rd party software can use them for managing printers, USB loaders, services, etc., so the events should be monitored and whitelisted.

Speaking of event monitoring, I noticed the Hard Configurator guide suggests to monitor event codes 865, 866, 867, 868, 882, 1000, 1007, and 1008. I plan to add a custom view for these events. If Event Viewer searches across ALL categories / logs for these Event codes, it takes a while. Do you know which categories / logs these codes can appear in? E.g. would Windows Logs -> Application and Windows Logs -> System be sufficient? Or do you recommend taking the hit and having it search across ALL categories or all of "Windows Logs" one?

... from time to time temporarily turn off blocking PowerShell, CMD, WSH, etc. and let Windows do what it wants to do.

Interesting! Any suggestions on how to do this in practice? E.g. Windows would normally be up-to-date already. So running update won't do anything. So, do you mean just letting Windows run in that state (offline?) for say a few hours? Or a day? How do you do this in practice?

 

[Andy Ful]

Great! Thank you for clarifications!
Speaking of event monitoring, I noticed the Hard Configurator guide suggests to monitor event codes 865, 866, 867, 868, 882, 1000, 1007, and 1008. I plan to add a custom view for these events. If Event Viewer searches across ALL categories / logs for these Event codes, it takes a while. Do you know which categories / logs these codes can appear in? E.g. would Windows Logs -> Application and Windows Logs -> System be sufficient? Or do you recommend taking the hit and having it search across ALL categories or all of "Windows Logs" one?

Windows Logs >> Application
Then look at the Source column for MsiInstaller or SoftwareRestrictionPolicies.
.

Interesting! Any suggestions on how to do this in practice? E.g. Windows would normally be up-to-date already. So running update won't do anything. So, do you mean just letting Windows run in that state (offline?) for say a few hours? Or a day? How do you do this in practice?

Simply turn off script protection, reboot computer and let it work. After an hour you can look at Task Manager to see if something makes busy the processor or disk. If not, then turn the protection on. Windows periodically makes system management and no one knows exactly what is required for it. Sometimes the script can be needed, sometimes not. Probably the diagnostic scripts are required when Windows finds some errors, so they will be rarely used.

 

[softie15]

@Andy Ful , you cleared up a lot of my questions. Thanks a ton! Going back to my earlier post and now that I have experimented more, thanks to your guidance, here are the remaining questions:

(1) I will disable (via both sponsors and registry settings for main standard user) cmd.exe + Powershell + WSH (this last one disabled for all users).
But there are a lot more potential sponsors out there! Should I go through all of the excubits blacklist and create Disallow rules for all?
Did you find any of them to be more "high risk" for system stability over others? (esp. in my limited-apps setup). I noticed in your tutorial part 3 you specifically called out a good example of regedit.exe.

(2) With Disallowed security level default, what's your recommendation for protecting lnk files?
Instead of removing LNK extension from Designated File Types, would it be safer to add Unrestricted rules for lnk files under 'C:\Windows', 'Program Files', 'Program Files (x86)', 'Desktop', 'Power Menu', 'Start Menu', 'Quick Launch', 'Taskbar', and 'Public Desktop' locations?

(3) I'd like to include DLL/OCX protection in my setup (Enforcement = "All software"). Hard Cofigurator guide indicates this can slow down the system sometimes, and crush Edge browser in Windows 10. I am not concerned about either one of those (planning to use Firefox or another browser). Do you know of any other issues I should watch out for?
Note: I checked that my autoruns shows DLLs in System space only.

(4) On our other thread re windows folder protection, you might have missed my latest reply (due to other posts that appeared since then). Please check out this post.

(5) Going back to original question... would VoodooShield be redundant or do you think it adds non-trivial protection for this emerging setup?
Summary of the setup: Disallowed default (incl. DLLs, for non-admins only), System dirs white-listed, protected Windows folder (as discussed in (3)), cmd/wsh/powershell sponsors (+others in (1)?) blocked, cmd/wsh/powershell executions blocked for main standard user + wsh blocked for all users.
I guess VoodooShield would protect against Admin background processes that might end up running behind the scenes, right? Do you think it is something worth installing then too?

 

[Andy Ful]

(1) I will disable (via both sponsors and registry settings for main standard user) cmd.exe + Powershell + WSH (this last one disabled for all users).
But there are a lot more potential sponsors out there! Should I go through all of the excubits blacklist and create Disallow rules for all?
Did you find any of them to be more "high risk" for system stability over others? (esp. in my limited-apps setup). I noticed in your tutorial part 3 you specifically called out a good example of regedit.exe.

.
There is no need to block all sponsors if you properly protect Web Browser, Office applications, and PDF editor/viewer. You can try to block all sponsors via SRP. Sometimes (rarely) regsrv32.exe or mmc.exe can be blocked when making Windows Updates, probably to configuring something after applying the update. So, you should check SRP events with Event Viewer after the update.
.

(2) With Disallowed security level default, what's your recommendation for protecting lnk files?
Instead of removing LNK extension from Designated File Types, would it be safer to add Unrestricted rules for lnk files under 'C:\Windows', 'Program Files', 'Program Files (x86)', 'Desktop', 'Power Menu', 'Start Menu', 'Quick Launch', 'Taskbar', and 'Public Desktop' locations?

The safest is not removing LNK extension from DFT list when using Disallowed Default Security Level. You can use right-click Explorer context menu option 'Open file location' on the shortcut and then run the executable. If you would remove LNK from DFT list, then the shortcuts would run command lines using sponsors, which can be dangerous.
If the above is not convenient for you then you have several solutions:

1. Block all sponsors and remove LNK from DFT list.
2. Do not remove LNK from DFT list , allow LNK only on Desktop.
3. Do not remove LNK from DFT list , allow LNK on Desktop, Power Menu, Start Menu, Quick Launch, Taskbar, and Public Desktop.

(3) I'd like to include DLL/OCX protection in my setup (Enforcement = "All software"). Hard Cofigurator guide indicates this can slow down the system sometimes, and crush Edge browser in Windows 10. I am not concerned about either one of those (planning to use Firefox or another browser). Do you know of any other issues I should watch out for?
Note: I checked that my autoruns shows DLLs in System space only.

There should be no problems if your applications are installed in Program Files ...
On the contrary, when you will use portable applications or programs that uses DLLs from the Userspace, then finding the blocked DLLs will be not easy, except those in the application folder.
.

(4) On our other thread re windows folder protection, you might have missed my latest reply (due to other posts that appeared since then). Please check out this post.

I will recheck your test for notepad.exe .
.

(5) Going back to original question... would VoodooShield be redundant or do you think it adds non-trivial protection for this emerging setup?
Summary of the setup: Disallowed default (incl. DLLs, for non-admins only), System dirs white-listed, protected Windows folder (as discussed in (3)), cmd/wsh/powershell sponsors (+others in (1)?) blocked, cmd/wsh/powershell executions blocked for main standard user + wsh blocked for all users.
I guess VoodooShield would protect against Admin background processes that might end up running behind the scenes, right? Do you think it is something worth installing then too?

I do not like Comodo + HIPS + VoodooShield on Windows 10.
.
Post edited - wrongly used RWX permissions.

 

[softie15]

.There is no need to block all sponsors if you properly protect Web Browser, Office applications, and PDF editor/viewer.

How do I properly protect those? If you have some links I should go through for protecting them, I am happy to try... With web browser, I like to assume that the sites I visit (even if some secure bank or government site), can always be compromised and serve me with some "bad" malware.

You can try to block all sponsors via SRP. Sometimes (rarely) regsrv32.exe or mmc.exe can be blocked when making Windows Updates, probably to configuring something after applying the update. So, you should check SRP events with Event Viewer after the update.

Thanks, so I think you are saying I should create Disallow SRP rules for all those entries listed in excubits site, except for regsrv32.exe and mmc.exe for best compromise between security and updateability. That's a lot of rules, but I know that's what I asked for :-(...

I wonder what's easier - "to properly protect Web Browser, Office applications, and PDF editor/viewer" or to add those entries. (Of course, the paranoid me wants to do both if it does not damage system stability.)

The safest is not removing LNK extension from DFT list when using Disallowed Default Security Level. You can use right-click Explorer context menu option 'Open file location' on the shortcut and then run the executable. If you would remove LNK from DFT list, then the shortcuts would run command lines using sponsors, which can be dangerous.
If the above is not convenient for you then you have several solutions:

1. Block all sponsors and remove LNK from DFT list.
2. Do not remove LNK from DFT list , allow LNK only on Desktop.
3. Do not remove LNK from DFT list , allow LNK on Desktop, Power Menu, Start Menu, Quick Launch, Taskbar, and Public Desktop.

What a great tip - I don't mind opening links via Explorer like you described! Thanks! So, I think implied here, no software should be using links. It's only me (the user clicking around) that should depend on link files, right?

There should be no problems if your applications are installed in Program Files ...
On the contrary, when you will use portable applications or programs that uses DLLs from the Userspace, then finding the blocked DLLs will be not easy, except those in the application folder.

Thanks. With my limited list of installed applications, I am hoping they will all work.

I do not like Comodo + HIPS + VoodooShield on Windows 10.

Hmm.. I was more curious about VoodooShield vs our SRP/sponsor-blocking settings...

But could you elaborate also on why Comodo + VS is bad? I am running that combo on another box that I have more control over and it seems to be doing Ok... ?

 

[Andy Ful]

I wonder what's easier - "to properly protect Web Browser, Office applications, and PDF editor/viewer" or to add those entries. (Of course, the paranoid me wants to do both if it does not damage system stability.)

It is better to properly protect Web Browser, Office applications, and PDF editor/viewer. Web Browser can be protected via sandboxing + secure DNS + some extensions (see @Prorootect posts). The best sandboxes have Edge and Chrome. SRP + script blocking can protect you from OLE in Office documents, and generally against trojan downloaders. You use Libre Office so there is no DDE vulnerability. You are fine with Office documents if you do not allow macros. But, even if you do it then 99% of macros are trojan downloaders which will be blocked by SRP+script blocking. The last thing - PDF viewers. PDF documents use very similar methods to Office documents, so 99% of them will be blocked by your config. Furthermore, there are some free pretty secure PDF viewers like Adobe Reader Touch (Universal Application from Windows Store, uses AppContainer) or STDU Viewer (desktop application, does not load active content).

Hmm.. I was more curious about VoodooShield vs our SRP/sponsor-blocking settings...
But could you elaborate also on why Comodo + VS is bad? I am running that combo on another box that I have more control over and it seems to be doing Ok... ?

.
Generally, the config based on 'SRP/sponsor-blocking/script-blocking' is more restrictive than VoodooShield (except Always ON mode). Both can give you very good protection. But using them together with Comodo + HIPS + Avira, won't be good for Windows stability and performance.
That applies also to any additional security.
You probably will not listen to my advice and will experiment with other security software, for fun of making security experiments. After years of experimenting, you will finally choose a simple security setup + knowledge + healthy habits.

 

[softie15]

It is better to properly protect Web Browser, Office applications, and PDF editor/viewer. Web Browser can be protected via sandboxing + secure DNS + some extensions (see @Prorootect posts). The best sandboxes have Edge and Chrome. SRP + script blocking can protect you from OLE in Office documents, and generally against trojan downloaders. You use Libre Office so there is no DDE vulnerability. You are fine with Office documents if you do not allow macros. But, even if you do it then 99% of macros are trojan downloaders which will be blocked by SRP+script blocking. The last thing - PDF viewers. PDF documents use very similar methods to Office documents, so 99% of them will be blocked by your config. Furthermore, there are some free pretty secure PDF viewers like Adobe Reader Touch (Universal Application from Windows Store, uses AppContainer) or STDU Viewer (desktop application, does not load active content).

Hi Andy, so help me understand this. As you pointed out, the main issue with deny-all "simple" SRP setup in the OP is that a malware embedded in compromised site or macro or PDF doc executes a sponsor that does something bad. I think you are saying that most malware will want to download its code first which will require it to use either cmd.exe or WHS or powershell, which my setup would block. However, as Iook down the excubits list, including *boot*exe, registry editing exe, install*exe, msiexec, etc, I get quite uneasy about all those other "sponsors" that malware could just run with some bad payload. I feel like I am missing something simple here. I think you are trying to say it will be very hard for malware to execute or do damage with all those dozens of entry points but I am not sure why.

Generally, the config based on 'SRP/sponsor-blocking/script-blocking' is more restrictive than VoodooShield (except Always ON mode). Both can give you very good protection. But using them together with Comodo + HIPS + Avira, won't be good for Windows stability and performance.
That applies also to any additional security.
You probably will not listen to my advice and will experiment with other security software, for fun of making security experiments. After years of experimenting, you will finally choose a simple security setup + knowledge + healthy habits.

I'd love a "simple" super-secure setup! I hope I have healthy habits. As I've been digging in on all these topics, I realize my knowledge is pretty bleak though. Thanks for expanding it BTW! ;-) Now, I thought each of those protections are complimentary to each other - 1 firewall +1 hips + 1 AV + 1 anti-exec (or two with the SRP setup I guess). I thought that was the standard advice - to have 1 of each? And yes, on my other, less secure setup, I actually do run voodooshield in AlwaysOn mode .. except when i need to install/upgrade something :-(.

 

[Andy Ful]

Hi Andy, so help me understand this. As you pointed out, the main issue with deny-all "simple" SRP setup in the OP is that a malware embedded in compromised site or macro or PDF doc executes a sponsor that does something bad. I think you are saying that most malware will want to download its code first which will require it to use either cmd.exe or WHS or powershell, which my setup would block. However, as Iook down the excubits list, including *boot*exe, registry editing exe, install*exe, msiexec, etc, I get quite uneasy about all those other "sponsors" that malware could just run with some bad payload. I feel like I am missing something simple here. I think you are trying to say it will be very hard for malware to execute or do damage with all those dozens of entry points but I am not sure why.

Something can also jump out of the Web Browser sandbox or you can download a malicious file and open it. Yet, if you will follow the advice from Compare Protection - SRP vs VoodooShield and do not install shady software, then your setup is pretty much strong, without blocking sponsors from the Excubits blacklist.
.

I'd love a "simple" super-secure setup! I hope I have healthy habits. As I've been digging in on all these topics, I realize my knowledge is pretty bleak though. Thanks for expanding it BTW! ;-) Now, I thought each of those protections are complimentary to each other - 1 firewall +1 hips + 1 AV + 1 anti-exec (or two with the SRP setup I guess). I thought that was the standard advice - to have 1 of each? And yes, on my other, less secure setup, I actually do run voodooshield in AlwaysOn mode .. except when i need to install/upgrade something :-(.

VoodooShield can replace SRP, but it can also conflict occasionally with some Anti-Virus programs and other security software (much more than SRP). Furthermore, Windows 10 does not like real-time protections other than its own. When you have more than one real-time protection, then you ask for problems. You have 2 (Avira + Comodo) and VoodooShield would be another one.
I think, that with your actual setup, you should rather think, how to physically secure your computer and data against thieves, tsunami, earthquake, and your little sister.

 

[softie15]

Something can also jump out of the Web Browser sandbox or you can download a malicious file and open it. Yet, if you will follow the advice from Compare Protection - SRP vs VoodooShield and do not install shady software, then your setup is pretty much strong, without blocking sponsors from the Excubits blacklist.

Well, I won't install anything shady knowingly or open any email attachments from people I know without scanning them first.. and I won't even open any Viagra emails at all (at least not for another 50 years ;-) )... My main concern is that I go to some normally good website, that just happened to get broken into recently and been silently distributing malware; or if I install one of those browser extensions, they themselves get hacked and I download a bad update from them (it HAD happened before). Then is there anything in the way of that malware executing regedit or msiexec or any other sponsor passing it malicious content?

When you have more than one real-time protection, then you ask for problems. You have 2 (Avira + Comodo) and VoodooShield would be another one

I see. I thought the issue would be to have more than one real-time protection for SAME thing. I use these for different functionalities though, which I thought should not conflict with each other (e.g. I don't have Comodo AV installed because I would have Avira AV, etc.). I get your warning though.

 

[Andy Ful]

Well, I won't install anything shady knowingly or open any email attachments from people I know without scanning them first.. and I won't even open any Viagra emails at all (at least not for another 50 years ;-) )... My main concern is that I go to some normally good website, that just happened to get broken into recently and been silently distributing malware; or if I install one of those browser extensions, they themselves get hacked and I download a bad update from them (it HAD happened before). Then is there anything in the way of that malware executing regedit or msiexec or any other sponsor passing it malicious content?

The attachment can be a 0-day executable, so scanning will fail. The best way is not bypassing the SmartScreen alert. SmartScreen has far less false positives than Virus Total or Comodo File Lookup.
Learn about ways to bypass SmartScreen, and be very cautious with such downloads.
.

I see. I thought the issue would be to have more than one real-time protection for SAME thing. I use these for different functionalities though, which I thought should not conflict with each other (e.g. I don't have Comodo AV installed because I would have Avira AV, etc.). I get your warning though.

Most real-time protections use similar techniques to monitor what is happening in the system. Of course, the worst scenario is when they are additionally trying to block the same thing.