Operating Principles

In this section:

•General Information.

•Defining Areas of the File System to be Monitored.

•Enhanced File Monitoring Mode.

General Information

The file system monitor SpIDer Guard operates in user space (user mode) using either fanotify mechanism or a special Linux kernel module (LKM—Linux kernel module) developed by Doctor Web. It is recommended that you use the automatic mode (Auto), which will allow the component to define the best operation mode on startup, as not all Linux kernel versions support fanotify used by the monitor. If the component cannot support the specified integration mode, the components exits after startup. If the auto mode is selected, the component attempts to use the fanotify mode and then the LKM mode. If neither of these two modes can be used, the component exits.

Once new or modified files are detected, the monitor sends to the Dr.Web File Checker file checker component a task to scan these files. The component then initiates their scanning by the Dr.Web Scanning Engine scan engine. The operation scheme is shown in the picture below. When operating via the fanotify system mechanism, the monitor can block access to files (of all types of files or only executable files—PE, ELF, scripts with a preamble #!) which are not scanned yet until they are fully scanned (see below).

Defining Areas of the File System to be Monitored

To optimize the check of the file system, SpIDer Guard controls requests only to those files that are in the file system scopes specified in the configuration. Each scope is defined as a path to some directory of the file system tree and is named as a protected space. A collection of all protected spaces forms a single monitoring scope controlled by the monitor. In addition, you can specify a collection of directories needed to be excluded from monitoring in the component settings (exclusion scope). If you did not specify any protected spaces in the component settings, the monitoring scope controls all the file system tree. This implies that those files are monitored if they belong to the monitoring scope and do not belong to the exclusion scope.

Specifying exclusion can be useful when, for example, some files are frequently modified, which results in constant repeated scanning of these files and, thus, can increase system load. If it is known with certainty that frequent modification of files in a directory is not caused by a malicious program but is due to operation of a trusted program, you can add the path to this directory or these files to the list of exclusions. In this case, the file system monitor SpIDer Guard stops responding to modification of these objects, even if they are within the monitoring scope. Moreover, you can add a program to the list of trusted programs (the ExcludedProc configuration parameter). In this case, file operations of this program will not cause scanning even if the modified or created files are monitored. Similarly, if necessary, you can disable monitoring and scanning of files located in the other file systems that are mounted to the local file system (for example, external file server directories mounted via CIFS). To specify file systems whose files should not be scanned, use the ExcludedFilesystem parameter.

Protected spaces, as parts of monitoring scopes with the specified scan parameters, are set in the component settings as named sections, whose names contain a unique identifier assigned to the protected space. Each section describing the protected space contains the Path parameter that defines the path to the file system storing the space directories (i.e. the file system tree fragment that is monitored within this space) and the ExcludedPath parameter that defines a local (with respect to Path) exclusion scope inside the protected space. Note that the ExcludedPath parameter can contain standard file masks (i.e. the '*' and '?' characters). You can also specify a global exclusion scope, using the ExcludedPath parameter specified outside the sections describing protected spaces. All catalogs belonging to this scope, including the directories of protected spaces, will be excluded from monitoring. Each protected space can be appended only with a global and its own exclusion scope: if one space is nested to another, the exclusion settings, specified for the enclosing space, are not applied to the nested space. In addition, each protected scope settings has the logical parameter Enable which determines whether the file monitoring is enabled or not. If this parameter is set to No, or the Path parameter has an empty value, the space contents is not monitored.

Consider an example of setting the monitor and exclusion scopes. Suppose the following parameters are set in the component settings:

It means that files located in the /directory1 directory and its subdirectories, except the /directory1/tmp folder, are monitored. Files whose full names match the mask /directory1/*.tmp are also not monitored (except the nested scope /directory1/directory2 to which this mask is not applied despite the fact that the scope is nested in the protected space space1). Files in the /directory3 directory are not monitored.

Enhanced File Monitoring Mode

SpIDer Guard can use three monitoring modes:

•Regular (set by default)—SpIDer Guard monitors file access (creation, opening, closing, and running) and requests the file scanning. If a threat is detected upon the scan, an action is applied to neutralize the threat. Apps are allowed to access the file until the file scanning is finished.

•Enhanced control of executable files—SpIDer Guard monitors files considered as non-executable like in the regular mode. Access to files that are considered as executable is blocked at the access attempt until the file scanning is finished.

•“Paranoid” mode—SpIDer Guard blocks access to a file at any access attempt until the file scanning is finished.

Dr.Web File Checker stores scan results in cash during the specified period of time, so when an app access the file which scan results are in cash, the file will not be rescanned, the cashed scan result will be used instead. Despite that, the “paranoid” mode significantly slows down access to files.

To configure monitoring mode change the BlockBeforeScan parameter value in the component settings.