ESET RA v6 custom policy to disable HIPS doesn't work as expected

[terrum 1]

I'm using ESET RA v6 virtual appliance. I created a custom policy to disable HIPS feature on my ESET File Security v6 clients. All FS clients are members of a group and the policy is assigned to the group. When I check HIPS status in Setup menu on a client short after rebooting it (otherwise HIPS won't turn off), it says that HIPS is disabled. HIPS is also listed as disabled and grayed out in the Advanced Setup menu which is expected as I'm managing it via RA policy.

 

However, after some time HIPS gets automatically enabled on all FS clients (HIPS status in Setup menu - enabled, HIPS status in the Advanced Setup menu - disabled and grayed out, no changes in the policy). If I reboot a client again, HIPS gets turned off, but after some time it starts back on again!

 

Any ideas why this is happening? What I should be doing to keep HIPS turned off permanently?

 

Thanks.

[brummel 0]

Maybe I have the same problem - but with ESET Endpoint Antivirus v6.

I have disabled HIPS in the settings but still receive warning emails about "Communication with the driver failed. HIPS does not work."

[Marcos 5,074]

Regardless of the issue, why would you want to disable HIPS which is as crucial protection layer as real-time protection?

[brummel 0]

Regardless of the issue, why would you want to disable HIPS which is as crucial protection layer as real-time protection?

 

For me: Because I get warning emails that HIPS is not working. Most of my clients do send this email every some hours.

So I decided to disable HIPS until a new endpoint version is available or I have time to investigate this issue.

[Marcos 5,074]

For me: Because I get warning emails that HIPS is not working. Most of my clients do send this email every some hours.

So I decided to disable HIPS until a new endpoint version is available or I have time to investigate this issue.

With HIPS disabled, your computer won't be protected against new borne threats as HIPS is required by both Exploit blocker and Advanced memory scanner to scan already unpacked malware in memory after execution and thus prevent it from running and performing malicious actions.

Just to make it clear, a computer restart is required for disabling HIPS to take effect. Have the target machines been restated and you're still getting email notifications about HIPS not working?

[terrum 1]

Regardless of the issue, why would you want to disable HIPS which is as crucial protection layer as real-time protection?

There is a predefined policy that comes with ESET RA v6 right out of the box, it's called "File Security for Windows Server - Antivirus - Real-time scanner only" - the first one in the list, you can see it on my screenshot too. A description for this policy says something like "this policy provides balanced settings optimized for use on a server", and most importantly, the HIPS setting in that policy is disabled. So, my thinking goes "if the vendor of my antivirus solution was so kind to include a policy template that is "optimized for servers", why should I NOT use it on my servers?"

 

Anyways, we can leave that topic for another discussion, but the real problem here is why this specific HIPS setting (disable HIPS permanently) eventually gets ignored by all clients, even though I have an active policy in RA that should keep the HIPS disabled? Is there a bug in current versions of ERA or EFS or both?

Edited March 17, 2015 by terrum

[Marcos 5,074]

I've tried creating my own policy not based on a template which had only HIPS disabled and the setting was applied to computers in the group. However, I've tested it with Endpoint v6, not with EFSW. Could you test it the same way with Endpoint v6 to find out if that makes a difference and there's an issue with EFSW only?

[brummel 0]

Just to make it clear, a computer restart is required for disabling HIPS to take effect. Have the target machines been restated and you're still getting email notifications about HIPS not working?

 

The clients have been restarted more than once.

According to the configuration requested from the clients and shown in the admin console HIPS is disabled. But I still get the mails about HIPS not working.

Funny thing is: This happens only for one customer out of three and there is nothing special in the installation of the client computers (all Windows 7 Pro 64 bit).

Is there any log file I can request from the client which tells me something about why HIPS is not working?

[Marcos 5,074]

If you run "sc query ehdrv" with administrator rights, is it in the running state?

[brummel 0]

Yes it is running.

 

SERVICE_NAME: ehdrv
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

[Marcos 5,074]

What OS is installed on computers that are producing the HIPS warning? Could you please post the registry value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BuildLabEx and the version of EFSW you have installed along with information about installed modules from the About window?

[brummel 0]

BuildLabEx: "7601.18741.amd64fre.win7sp1_gdr.150202-1526"

As written earlier: Installed is ESET Endpoint Antivirus 6.1.2222.1 (german)

The current endpoint version was installed as an updated on v5 eset endpoint antivirus.

 

The same constellation is used for other customers and is running without HIPS warnings.

[brummel 0]

And the installed modules:

 

Signaturdatenbank: 11339 (20150318)
Soforteinsatz-Modul: 5696 (20150318)
Updates: 1056 (20150113)
Viren- und Spyware-Schutz: 1451 (20150224)
Advanced Heuristik: 1154 (20150129)
Archivunterstützung: 1221 (20150304)
Säuberungstechnologie: 1105 (20150120)
Anti-Stealth-Unterstützung: 1070 (20150209)
ESET SysInspector: 1245 (20141028)
Self-Defense-Unterstützung: 1018 (20100812)
Echtzeit-Dateischutz: 1009 (20130301)
Lokalisierungsunterstützung: 1322 (20150226)
HIPS-Unterstützung: 1166 (20150310)
Internet-Schutz: 1180 (20150304)
Datenbank: 1064 (20150303)
Konfigurationsmodul (33): 1054B (20150216)
 

[terrum 1]

I've tried creating my own policy not based on a template which had only HIPS disabled and the setting was applied to computers in the group. However, I've tested it with Endpoint v6, not with EFSW. Could you test it the same way with Endpoint v6 to find out if that makes a difference and there's an issue with EFSW only?

I did a test last night:

 

1. Created two new static groups, group#1 for endpoints, group#2 for servers.

2. In ERA v6 created two new separate policies from scratch with only HIPS setting disabled (enforced), one for v6 endpoints (EEA), one for v6 servers (EFSW).

3. Assigned a policy to a corresponding group (the endpoints policy to group#1, the servers policy to group#2).

4. Picked two EEA v6 endpoints running Win7 64bit and moved in the group#1, picked two EFSW v6 servers running Win2008R2 and moved in the group#2.

5. Checked the settings on all four clients: HIPS status in Setup menu - Enabled, HIPS status in the Advanced Setup menu - Disabled and grayed out.

6. Rebooted all four clients and checked HIPS status again: HIPS status in Setup menu - Disabled

7. Checked the status again this morning (8-9 hours after): HIPS status in Setup menu is now ENABLED on all four test clients!!! (HIPS status in the Advanced Setup menu still disabled and grayed out).

 

Of course, if I reboot a client again, the HIPS will disable, but after some time if will automatically turn back on again! So, there is certainly something fishy going on... any suggestions?