Knowledge Base

Creating Whitelist Overrides in the Endpoint console


Userlevel 7
Global whitelist overrides can now be set on a file or folder level as well as the traditional MD5 (Message-Digest algorithm 5) level in Endpoint Protection. This upgrade allows greater flexibility in the deployment of overrides and means that multiple related MD5 overrides no longer have to be whitelisted individually, instead the whole associated directory can simply be whitelisted.
 
Note: If you detect or remove a file before an exclusion or override is in place, you will need to uninstall then reinstall or ensure that the detected files are restored from quarantine. If the files are still located locally in the quarantine or block/allow tab, the exclusion does not work.
 
To create a whitelist override:
1. Log in to your Endpoint Protection console.
    The Endpoint Protection console displays, with the Status tab active.
 


 
2. Click the Overrides tab.
 


 
3. The system displays the Overrides panel, with the Whitelist tab active.
 


 
4. Click the Create button.
 


 
The system displays the Create override window.
 


 
5. In the Override Name field, enter a name for the override.
 


 
6. Do one of the following:
  • If you're done, click the Save button.
  • To create a Folder/File override, continue with this procedure.
Note: To use File/Folder overrides please make sure endpoints are running version 9.0.1 or higher of Webroot SecureAnywhere Endpoint Protection. Earlier versions support MD5 overrides only.
 
7. In the New Whitelist Entry window, select the Path/File radio button.
 


 
The system displays the Create override window with the relevant fields.
 


 
8. Use the information in the following table to populate the fields. 
 
FIELD
DESCRIPTION

Override Name
Enter a name for the override.

Override Type
You have already selected the Path/File radio button.

File Mask
Target a file or group of files by specifying a file mask with optional wildcards, for example, *.exe to target all executable files in the selected folder. This will default to all files in the selected folder/path if not specified.

Path/Folder Mask
The folder to target with the override. You can specify an absolute path, for example,
x:myfolder
or a system variable with optional path, for example,
%SystemDrive%myfolder.
Default supported environment variables are displayed when you type % (percent)however you may choose to use any variable you have setup on the target machine with the exception of user variables which are not supported. You may not use %temp% for example as this refers to a specific users temp directory (‘username/temp/’). Wildcards are not supported.

Include Sub-folders
Select this checkbox to apply the override to all sub-folders within this folder.

Detect if Malicious
If this setting is enabled Webroot will continue to protect the user against threats originating from the selected file/folder whitelist override but will disable monitoring and journaling. This is primarily used to improve performance when monitoring and journaling is being applied to a large number of files with an unknown determination. Disabling this setting will provide a true whitelisting, allowing files to run without Webroot protection.

Global (GSM) Override
Selecting this will make the Override global for every site under the current GSM Console.

Apply to Policy
Do either of the following:
  • Select Yes to apply the Override to a specific policy, global policies included.
  • Select No to apply to all policies on the selected site.

9. When you're done, click the Save button.
 



7 replies

Userlevel 5
I regularly find that some whitelist overrides (MD5 or folder) just plain don't work.  I'm experiencing this right now, where after making exceptions for a path, and three MD5 exceptions for a program, it is still getting blocked from running.
 
I recommend putting up a KB article to troubleshoot reasons why whitelisting might not be working; I'd also look into whether the whitelist process always works properly.
What wildcards are supported in the file mask? This only shows "*". Is "?" supported to match a single character?
 
Does the path/folder mask also support wildcards?
I just received a reply from Webroot Support through my IT group that MD5's are ignored and any exe's in the Override list are not scanned. What is the reason for this loophole? Are the Paths also ignored if I chose that Override approach?
Please advise.
I sent many MD5's of exe's I develop to my IT dept that manages our installed Webroot SecureAnyWhere EndPoint Protection. As a trial, I asked for the MD5 that Webroot reports for 1 of my exe's. Unfortunately, it does not match what I sent. Is there any mixing of 'Filename' or 'Path' to the actual file contents when calculating the MD5 hash? As a check, I calculated my MD5 with Microsoft's FCIV.exe utility and several online websites and they all agree. But, not Webroot? Please advise.
Userlevel 7
@jgdaqs, if it hasn't already been submitted as a Feature Request I highly recommend you do so & our Product Team will review it
I think it would be paramount to offer a place where we can all collaborate on whitelist and blacklists that we each have, so that we can have the community come together on making the product better. I've got a bunch of admin tools from the likes of nirsoft.net that get blocked by default, so I have a bunch of md5's on a whitelist, all related to those tools. If we could catagorize the blacklist/whitelist functionality, with more granular controls, I think creativing such lists would be easier and more beneficial.
Userlevel 5
Reading the below:
 
Path/Folder Mask = The folder to target with the override. You can specify an absolute path, for example, ‘x:myfolder’ or a system variable with optional path, for example, ‘%SystemDrive%myfolder’
 
Does one need the at the end of the path, or not?  Is there a best practice?

Reply

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept or continue browsing you agree to our cookie policy. Learn more about our cookies.

    Accept cookies Cookie settings