Jump to content

Exceptions not working


Palps
 Share

Go to solution Solved by MichalJ,

Recommended Posts

Hi together,

 

I have currently the issue, that some of my exceptions are not working.

 

ESET is detecting the following false positive:

post-10739-0-97134000-1462261241_thumb.jpg

 

It seems, that BackupExec is running because for every detection I am getting another shadow copy path.

file:////Device/HarddiskVolumeShadowCopy11/ProgramData/Druva/inSyncCloud/inSyncServer4/detectav.exe

file:////Device/HarddiskVolumeShadowCopy6/ProgramData/Druva/inSyncCloud/inSyncServer4/detectav.exe

Now I tried to adapt our exceptions with the following paths and processes but every morning I am getting the false positive again.

Path exclusions:

post-10739-0-34854700-1461838255_thumb.jpg

Process exclusions:

post-10739-0-01940000-1461838261.jpg

 

How is the syntax or which kind of wildcards are working for the exceptions?

Would really appreciate your help.

 

Thanks.

Edited by Palps
Link to comment
Share on other sites

Hi Gonzalo Alvarez,

 

the knowledge base article just shows the same place where it took the screenshot of my exception processes/paths.

I configured already the settings which are described in the article but they are not working, but thanks anyway :)

Link to comment
Share on other sites

  • ESET Staff

Do you have any set of exclusions created by a different policy lover in the hierarchy?
As the exclusions list is considered as a one setting, one list overwrites another one. Also, if you set "force flag" for the master list, this is not appended, not overwritten.

What I would suggest, is to try to remove all policy assignments including "any form of exclusions" from the target client, and set the exclusions locally on the affected computer.

Please let us know, if this helped.

Edited by MichalJ
Link to comment
Share on other sites

  • Administrators

We are not sure if excluding Shadow copy volumes using a wildcard will work. Try excluding "\device\harddiskvolumeshadowcopy*\*.*" or "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy*\*.*"

Link to comment
Share on other sites

Do you have any set of exclusions created by a different policy lover in the hierarchy?

As the exclusions list is considered as a one setting, one list overwrites another one. Also, if you set "force flag" for the master list, this is not appended, not overwritten.

What I would suggest, is to try to remove all policy assignments including "any form of exclusions" from the target client, and set the exclusions locally on the affected computer.

Please let us know, if this helped.

 

Thanks MichalJ for your answer. That's what I also already thought about. But I requested the configuration on the ERA of the affected client and the configuration is showing the exceptions. I also checked the configuration directly on the client and also there I could see the configured exceptions, so they are not overwritten by a lower policy.

I will try the solution posted by Marcos before I configure the exceptions locally because we have many servers and I don't want to do all the configuration manually. This should work by policy.

 

 

We are not sure if excluding Shadow copy volumes using a wildcard will work. Try excluding "\device\harddiskvolumeshadowcopy*\*.*" or \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy*\*.*

 

I will try to add the paths like you explained. Have to check tomorrow morning again if the threat occurred again.

 

Thank you both for you fast support, appreciate it.

Link to comment
Share on other sites

Hi again,

 

unfortunately the Eicar test file is still reported.

post-10739-0-28185600-1462260546_thumb.jpg

 

I have the following exceptions (applied by policy, screenshot from server)

post-10739-0-18896400-1462260976_thumb.jpg

 

Do you have some additional ideas?

 

Thanks!

 

Link to comment
Share on other sites

  • ESET Staff
  • Solution

I have checked with developers, try to configure exclusions as:

\Device\HarddiskVolumeShadowCopy?\ProgramData\Druva\inSyncCloud\inSyncServer4\*

\Device\HarddiskVolumeShadowCopy??\ProgramData\Druva\inSyncCloud\inSyncServer4\*

Please let us know, if it helped.

 

Also, if you are using the ESET File Security, which supports the process exclusions, you should set a process exclusion by a full path to the "beremote.exe", as that is the process you would like to exclude.

Btw, what is the name of the backup software you are using? We would like to replicate the issues you are experiencing, to improve how product handles / processes the exclusions, and how we communicate it to the users.

Edited by MichalJ
Link to comment
Share on other sites

I have checked with developers, try to configure exclusions as:

\Device\HarddiskVolumeShadowCopy?\ProgramData\Druva\inSyncCloud\inSyncServer4\*

\Device\HarddiskVolumeShadowCopy??\ProgramData\Druva\inSyncCloud\inSyncServer4\*

Please let us know, if it helped.

 

Also, if you are using the ESET File Security, which supports the process exclusions, you should set a process exclusion by a full path to the "beremote.exe", as that is the process you would like to exclude.

Btw, what is the name of the backup software you are using? We would like to replicate the issues you are experiencing, to improve how product handles / processes the exclusions, and how we communicate it to the users.

 

Thank you for your answer. Very appreciate it.

I adapted the exceptions like you proposed. I will check tomorrow morning again if the threat was found again.

 

I don't want to exclude the whole "beremote.exe" process because this is doing the backup and maybe it will detect some other threats also.

We are using Symantec Backup Exec. The backup is running during the night and on the next morning I have the threat alerts on our client backup server due to the eicar test files reported by the real-time file system protection.

Link to comment
Share on other sites

I have checked with developers, try to configure exclusions as:

\Device\HarddiskVolumeShadowCopy?\ProgramData\Druva\inSyncCloud\inSyncServer4\*

\Device\HarddiskVolumeShadowCopy??\ProgramData\Druva\inSyncCloud\inSyncServer4\*

Please let us know, if it helped.

 

This solved the problem with the shadow copies.

Thank you very much for your support!

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...