should I enable HIPS, in addition to autosandbox?

what would be the advantages to enabling HIPS also, on top of autosandbox?
If I understand right, HIPS will not monitor autosandboxed files, and files with trusted status will trigger neither autosandbox nor HIPS.
So what is the advantage to enabling both?
Let’s assume that autosandbox is set to the default settings for proactive config, such that it applies globally.

EDIT: I’m just trying to understand how things work. Maybe HIPS produces certain types of alerts for trusted processes?

Why do you think there are always advantages? :slight_smile:
Here’s a disadvantage: functions that are blocked by default might get allowed by user.

that’s interesting.
Do you mean that HIPS, when disabled, operates in the background according to a set of default rules?
If so, are these default rules affected in any way by the HIPS settings, for instance, “enhanced protection mode”?

Sorry. I confess it was an abrupt explanation. I was actually following your sentence to (kind of) demonstrate why it might not be a good idea,

HIPS will not monitor autosandboxed files
assuming that you were referring to actual *alerts* then you'd get these for blocked functions. Some applications do some dangerous stuff. It's really hard to judge by request keyboard access flag and others. In the end, you will allow what is dangerous, blocked by default.

Now, you mention monitor but restrictions are applied most of the time to Auto-Sandbox with HIPS. You could say that it is not really that deactivated which is a good thing.

Makes sense? :slight_smile:

and that’s why some people consider Auto-Sandbox as the first line of defense.

HIPS is on just as an added awareness to when an unrecognized file is about to be executed and it will enforce whatever rules are set in HIPS rules. This includes CIS self-protection such as preventing trusted apps from accessing comodo processes in memory or terminating comodo processes. Also you can control what sandboxed applications are allowed to do when sandboxed when you define certain HIPS access rights rules. For example, sandboxed applications are allowed to access the DNS/RPC client service (\RPC Control\DNSResolver COM Interface) so they can use windows built-in DNS resolver to perform DNS lookups. If however you set block for DNS Client Service in the HIPS access right rule window for that application, it won’t be able to use the built-in DNS resolver of Windows. Another set of access rights you can control for sandbox apps is the Windows/WinEvent hook and protected COM Interfaces access rights.

let’s say I disable HIPS, and just leave autosandbox on.
Now, I trust a certain program, which allows it to run outside of sandbox.
So HIPS, even though disabled, will block this program from messing with COMODO itself,
Is there anything else HIPS will do, in such a situation, or is disabled HIPS just a self-protection function?

If HIPS is disabled then anything that is running outside the sandbox will be able to do anything to the system including messing with comodo processes. The self-protection and the HIPS rules will only take affect if HIPS is enabled. Hence it is better to leave HIPS enabled even if you run unknown files in the sandbox as it will provide some additional benefits as stated before.

[at]futuretech, thanks for your explanation

[at]qmarius, also thanks, but I am still trying to wrap my head around your interesting posts (and I mean “interesting” in a good way). In connection with HIPS alerts, you commented: “In the end, you will allow what is dangerous, blocked by default”.
Could you please elaborate a little bit what is blocked by default? And what does “default” mean, in this context? Does it mean COMODO’s behavior when HIPS is disabled, or what?

EDIT: People make a big deal out of the fact that COMODO’s HIPS can detect advanced threats such as process hollowing, etc.
I just don’t understand how and where this capability comes into play. If you trusted the file, you don’t get HIPS alerts for its actions, so the process hollowing will take place.
And if the file is not trusted, you should have blocked it long before it got to the point of process hollowing.

Well futuretech explained it but OK. I’ll stick to a specific configuration for better illustration.
Auto-Sandbox disabled, HIPS enabled.

It’s a generic answer. I couldn’t tell you a list of specific actions that are blocked. Not that I do not want to but only a dev would know precisely. However, as you know, these actions (that are monitored by HIPS) are grouped into objects and activities. (There are probably more things there but I will stick with these for simplicity.)
Back to my example : You, as user, cannot know if you receive an alert with keyboard access what it will do. You are powerful indeed since you used almighty HIPS but. And there’s a but. Will the application access your keyboard? Sure. Could it block your keyboard input? It’s possible. Can it do other nasty stuff? Of course.

Basically what you are saying, if you will allow me to paraphrase, is that the user can’t know just from the HIPS alerts whether he is getting into danger or not. So it’s better not to even start guessing whether this action or that permission will end up malicious.
Please correct if I didn’t get you right.

Yes. Do note that it depends: in most situations HIPS will save you anyway. (eg you will be informed when unknown executable is launched.)

Conclusion: HIPS only is not bullet proof.

// alerts orientated design

just curious: what are those exceptional cases where HIPS alone will not protect? Doesn’t HIPS always give an alert when an unknown file wants to execute?

Can’t think of any now. There’s a much lower chance to find one with beta version anyway. :slight_smile:

I saw a post from a comodo tester, he says similar to you, that HIPS alerts are less reliable than autosandbox alerts. I am referring to post #14

Tester more than likely had disabled verbose mode alerts under HIPS settings which is default for the Internet security config. This option determines the behavior of the kind of rules that are set for each access right for the application. For example with verbose mode enabled, when an unknown application attempts to modify say a protected file/folder, you will get alerted for each specific file/folder like C:\somepath\to\file1, C:\somepath\to\file2, etc, but with verbose mode disabled you will only get one alert for each access right. To see this in action run comodo leak test non-sandboxed with HIPS verbose mode on and look at how the rule is created when you answer with ‘remember my answer’ selected. Then remove the rule for CLT and run it again with verbose mode alerts disabled, you will see the difference in amount of alerts displayed and the way each access right is set to block.

The problem is, if you run something inside the sandbox and it doesn’t work properly, what will you do?
Most likely, you will set an auto-sandbox rule to ignore that program, then start it again outside the sandbox.
Like this, if HIPS is ON, you can still have control over it. If HIPS is OFF, most likely you’ll get infected (if the program turns to be malicious).

So, what I do is to use the “Proactive Security” configuration with both HIPS and auto-sandbox ON.

There is a reason why it doesn’t work. It’s not like they make it less compatible on purpose. Compared to competitors it’s way superior (from that point of view).

I agree, Comodo auto-sandbox is way superior to nearly any competitor, especially because it’s auto :slight_smile:
This is why it’s ON by default in all the preset configurations.

About HIPS, it’s OFF only in the Internet Security configuration, while it’s ON in Firewall and Proactive Security configurations.

I think HIPS also affects the FW behavior. I have already posted a comparison of firewall against some leak tests:

This guy testes CIS 6. If I remember correctly, CIS 6 didn’t have the option to auto-sandbox unknown files as fully virtualized, but only as partially limited, limited, restricted and untrusted (the fully virtualized option was only for on-demand sandbox).
By the way, the firewall test shows that CIS FW scores quite well only if HIPS is ON ( column 1 and 2 of the comparison ), while it scores poorly when HIPS is OFF ( column 8 )

On the other hand, both cruelsister and chiron (two of the most skilled security-oriented users) suggests to set CIS to Proactive Security configuration, but turn HIPS OFF:

So, I’m a bit confused :-\