Comodo Internet Security 12.2.4.8032 ignores rules for HIPS and Auto-Containment

Comodo Internet Security - CIS
1

System Details–
OS: Windows 10 Home
Architecture: 64-bit
Version: 22H2
Build: 19045.4412
CIS Version: 12.2.4.8032
CIS Database: 36780

Issues–
As the title suggests, CIS is ignoring my rules for HIPS and Auto-Containment. For the first issue, HIPS, I’ve (repeatedly) told it to unblock the afflicted files for both “the component(s) shown in ‘Blocked by’ column” and “for all security components”. There are several files this happens to, but two examples are:

“C:\Program Files (x86)\KeyCryptSDK\KeyCrypt64(2).dll”
“C:\Program Files (x86)\MSI\Dragon Center\Dragon Center.exe”

It continues to disregard the fact that they’re unblocked, and they appear in the Blocked Applications list several times a day. I’ve confirmed the files appear in the File List as Trusted, in the HIPS list as Allowed Application, and in the Auto-Containment list as Ignore.

For the second issue, I have created a File Group for an external hard drive containing my game library, and I have added it to HIPS as Allowed Application, and to Auto-Containment as Ignore. The File Group is named ‘Game Libraries’, and the included path is “E:\*”, which to my understanding means that all sub-directories are included. I’ve also added the File Group to the “Do not virtualize access to the specified files/folders” list.

While HIPS doesn’t flag anything on that drive, Auto-Containment consistently snags executables as Untrusted. When they get flagged, I exit them and change the file rating to Trusted, which only works some of the time. Again, multiple files are affected, but two examples are:

“E:\Steam\steamapps\common\habl\habl.exe”
“E:\Steam\steamapps\common\Parabellum\Parabellum\Parabellum.exe”

I’m not necessarily convinced this is a bug per se, as it’s an issue that’s followed me for a few versions of CIS; my guess is that it’s a configuration issue that I’m not seeing. I’m wondering if anyone here has run into this issue before, and with such persistence.

I appreciate any help or insight that might be provided.

EDIT: Since this site won’t let new users attach files, here’s a link to the exported configuration file.
https://drive.proton.me/urls/EQVNKVHNX8#y4JNtC4iINB0

2

Can you export and attach the configuration file that has the mentioned issues? Maybe some guys can help figure it out.

3

Ah, yes; knew I’d forgotten something. A link to the configuration file has been appended to the original post. Thank you for your reply.

4

I checked your configuration file and found all rules were as expected. I have some tips that may help.

  1. For your first issue, does HIPS still block these two files after unblocking? As far as I know, the .dll files are ineffective when directly added as a HIPS rule since they should be loaded by executive applications. You can check which application loads it when triggering the blocking, and then add a HIPS rule for the associated app. I have no idea why the “Dragon Center.exe” is still blocked with an allowed rule assigned.
  1. For your second one, the issue that CIS can not effectively process rules for the removable devices has been a long persistent issue. You can explicitly append the influenced paths in your ‘Game Libraries’ group. Good luck. :face_with_peeking_eye:

Besides, IMO, the “Log when this action is performed” item doesn’t need to be checked when an ignore rule has been assigned in the auto containment module.

5

Thank you for taking a look through the file, and for your advice.

  1. There’s definitely something dodgy in how HIPS acts with this issue. These programs will launch successfully at startup and sit minimized in the system tray as expected. After an indeterminate period of time, they’ll get flagged, and terminate. Regardless of if I tell HIPS to unblock them (again) or just leave them on the blocked list, I can re-launch them, and they’ll behave normally before disappearing again down the road. Per your comment, I added a rule for the executable linked to that .dll file. Within a couple hours of doing so, the .dll was flagged again, but not its parent executable.

One of the great mysteries of the universe, perhaps. Overall, since the programs still generally work, this isn’t system-breaking; it’s just mildly annoying. Though I do tend to keep an eye out for other programs that might be more severely impacted (like that time it flagged explorer.exe every day for a month, or when it waged weeks-long nuclear warfare on all the CIS components).

  1. Ah, understood. It’s a bit disheartening that it’s a known and longstanding issue, but at the same time, at least I know the universe isn’t picking on just me. I’ll start experimenting with granular paths and see how that plays out. You have a point about the logging; I imagine I’m going to de-select that.