NOD32 5.2.9.1 with COMODO

Hi guys! Just would like to ask if someone's using NOD32 version 5 together with COMODO firewall + Defense + (without AV installed). Will it be a problem if I leave the HIPS module of NOD32 on? I'd rather prefer to not turn it off as I presume this will disable the self-protection as well.

 

It's been a while since I used Comodo with Defense +, and it was before I upgraded to NOD32 version 5, which has HIPS. Defense + is a type of HIPS, so I think it might conflict with HIPS in Eset. I don't believe that turning off HIPS disables self-protection in NOD32; however, if I were choosing, I'd turn off Defense + and just use the firewall in Comodo. That way you can use HIPS in NOD32 without any concern about a conflict.

 

you should believe that. Marcos has confirmed that.
On the other hand, v4 intercepts dangerous behaviors, such feature was extended to the user in v5 with customizable rules

 

Thank you for your replies. So far I haven't noticed any problems or performance degradation having both turned on. In case there are such, I'll probably revert to version 4 of NOD32. Defense+ is a very important layer for me to switch it off and disabling NOD32 self-protection is also an unacceptable solution for me.

 

Why should I believe that turning off HIPS also disables self-defense? There are two check boxes in HIPS setup. One is to enable HIPS and the other is to enable self-defense. Just uncheck HIPS. Leave self-defense checked. That seems simple enough to me.

 

this is precisely what i do. i run comodo with defense+ set aggressively and HIPS on NOD32AV disabled. i also try to kill commands that i feel have crossover (like protocol analysis on comodo, since ekrn.exe is already monitoring web traffic in real time)
i have noticed no increase in cpu or RAM use.

and as has been said, no, "self-defense" does not deactivate on NOD32 because you've disabled HIPS.

 

According to marcos in version 5 a disabled hips,disables self protection but I can't confirm this.In version 6 beta it is not a issue at all and if you disable the hips and leave self protection checked it can't be killed off through task manager end processes self protection works fine.

 

I hope Marcos will further clarify this, because it sounds like a major bug if the options in the HIPS settings are not what they seem to be. I have HIPS enabled and self-defense enabled as well. I'm not using Comodo and have not for some time, but that's my choice.

OK, I couldn't wait for Marcos. I disabled HIPS but left self-defense checked in version 5.2.9.1. I see that there is a problem. With only HIPS disabled, egui.exe can be "ended" in Task Manager and without a whimper. On the other hand, ekrn.exe cannot be ended, but there is no notice. It just isn't removed from the list of processes. So in 5.2.9.1 self-defense sort-of-half works, which isn't good enough. It's nice to hear that it works correctly in version 6 beta. After testing, I re-enabled HIPS and all is back as it should be. With both items checked, a notice pops up saying that the process could not be ended and access is denied. The 6 beta looks like a good bet, but this seems to be something that should have been caught in the development of version 5.x since it is so fundamental to the security of the application. Oh well . . . . .

Added: Just uninstalled 5.2.9.1 and then installed 6.0 beta. I disabled HIPS but left self-defense enabled. Restarted and found that 6.0 beta behaves exactly the same way as 5.2.9.1. With HIPS disabled but self-defense enabled, the task manager can "end" egui.exe but does not end ekrn.exe. So, this is not fixed in 6.0 beta, so far as I can see. This is on a system running XP SP3, so the OS version may make a difference. I will now try restarting egui.exe by starting the program from the programs list in explorer. OK, there is no complaint restarting the program, as opposed to the way it behaved in version 5.2.9.1. It loads and shows that HIPS is disabled. However, I can still end the egui.exe process in task manager, which doesn't seem right. Nevertheless, since ekrn.exe is still running and the interface can be reloaded and the icon doesn't go red when I reload the program, that must be an improvement.

 

Agree