Jump to content

Excluded Directories Still Being Scanned by Managed Mac Clients


grettir
 Share

Recommended Posts

The short version:

 
1. It seems that managed Mac clients are only partially honoring exclusions.
a. Eicar test files placed in excluded directories are being ignored, as expected.
b. Files in excluded directories are still being scanned on access, which is not as expected.
2. Unmanaged Mac clients appear to be honoring exclusions correctly.
 
 
The long version:
 
My MacBook Pro is affectionately referred to by my colleagues as the "Wind Tunnel" because its fans are constantly going at high speed. And its fans are constantly going at high speed because my managed ESET client is constantly scanning files in directories that have supposedly been explicitly excluded from scanning.
 
A good example is Backblaze's working directory. Since Backblaze is constantly updating its indexes, logs, etc, there's always a lot of churn going on, so I've explicitly excluded Backblaze's working directory…
    /Library/Backblaze.bzpkg/*.*
…via policy (as specified in numerous Knowledgebase articles). And I can tell the exclusion is working (at least in part) because when I place a copy of the Eicar test file in the /Library/Backblaze.bzpkg/ folder (or one of its sub-folders), the ESET client ignores it.
 
But the moment a Backblaze backup kicks off, my managed ESET client starts scanning every file that is accessed in Backblaze's supposedly-excluded working directory, pegging the CPU, and causing the fans on my MacBook Pro to start screaming.
 
Here's a screenshot that shows both the exclusion in the client, as well as the client completely ignoring that exclusion:
 
post-14089-0-21799000-1476404001_thumb.gif
 
The same is true of Time Machine backups, as well. Even though I've gone to great lengths to exclude every possible permutation of Time Machine path and volume name, ESET starts churning through every accessed file in those supposedly excluded directories/volumes the moment a Time Machine backup starts.
 
I've only seen this behavior with managed clients. If I install a standalone version of the exact same client with the exact same exclusions, the exclusions work as expected. Even with Backblaze and Time Machine backups happening simultaneously, files in those excluded directories never show up in the scanned objects stream and my fans hum along quietly.
 
But the moment I connect the ESET client to a Remote Administrator server, the scanned objects stream becomes a raging torrent of files in directories that it should be ignoring, and my fans kick into overdrive.
 
I've tried adding/removing policies, creating new policies from scratch, and applying those policies at different levels in the group hierarchy. I've tried uninstalling and reinstalling the client multiple times, as well as going from managed to unmanaged and back again. I've also tried different syntax permutations for the exclusions (including two wildcard symbols (*.*), one wildcard symbol (*), and no wildcard symbol at the end of the path), but the problem remains.
 
Any ideas? I'm out of them…
 
 
 
 
Link to comment
Share on other sites

Sorry. I obviously need to revisit my Tech Support 101 textbooks:

 

ESET Endpoint Security for macOS 6.3.85.1
ESET Remote Administrator (Server), Version 6.4.304.0
 
Client testing done on MacOS Sierra 10.12 (16A323).
Link to comment
Share on other sites

  • Administrators

The path to the last "scanned" file does not mean that the file was scanned but that it was processed by real-time protection before exclusions were evaluated and a scan was performed. It has worked that way on Windows since v1 or v2 and we're already at version 10.

To test exclusions, put eicar to an excluded folder and see if it's detected upon access.

Link to comment
Share on other sites

The path to the last "scanned" file does not mean that the file was scanned but that it was processed by real-time protection before exclusions were evaluated and a scan was performed. It has worked that way on Windows since v1 or v2 and we're already at version 10.

To test exclusions, put eicar to an excluded folder and see if it's detected upon access.

 

First of all, the sentence "The path to the last 'scanned' file does not mean that the file was scanned…" is pretty hilarious. Although that would go a long way toward explaining why "'excluding' a file does not mean that the file is excluded."

 

Second, if files displayed in the "Scanned objects" stream aren't actually being scanned, then explain the following:

 

1. When using an unmanaged client, files in excluded directories never appear in the "Scanned objects" stream when they are accessed.

2. When using a managed client, files in excluded directories always appear in the "Scanned objects" stream when they are accessed.

 

Either:

 

a.) Your "Scanned objects" logging/display code is broken since, in your scenario, all accessed files should appear in the "Scanned objects" stream regardless of whether the client is managed or not.

 

…or…

 

b.) When your client says it is "scanning" an object it is actually scanning an object.

 

Third, as I specified in the title of my post, we're talking about the Mac client here, not Windows.

 

And last, but not least, I think I described the results of my Eicar testing in rather good detail. Either you didn't actually read my post before you responded (likely) or my descriptive prose needs some work (also very likely). And I think you may have also skipped over the reply from an ESET Staff member who stated that the behavior that I described has been confirmed by your QA team and is being tracked as a bug.

 

 

P.S. I apologize for the snark. It's been a rough Monday morning…

Edited by grettir
Link to comment
Share on other sites

  • 2 weeks later...

Good afternoon,

 

I am having the same issues as described with excluding accepted file paths and applications. Just checking to see if a fix has been identified? 

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...