Operating Principles

In this section:

•General Information.

•Defining Areas of the File System to be Monitored.

•Enhanced File Monitoring Mode.

General Information

The SpIDer Guard file system monitor operates in user space (user mode) using the fanotify system mechanism or a custom Linux loadable kernel module (LKM) developed by Doctor Web. It is recommended that you use the automatic mode (Auto), which will allow the component to determine and use the best operation mode at startup, because 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 none of these modes can be used, the component shuts down.

Once new or modified files are detected, the monitor sends a task to the Dr.Web File Checker component to scan these files. The component then initiates their scanning by Dr.Web Scanning 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 the #! preamble) that are not scanned yet until they are scanned (see below).

Defining Areas of the File System to Be Monitored

To optimize file system scanning, 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 called a protected space. A set of all protected spaces forms a single monitoring scope controlled by the monitor. Besides the monitoring scope, you can specify a set of file system directories to be excluded from monitoring in the component settings (exclusion scope). If you did not specify any protected space in the component settings, the monitoring scope covers the entire file system tree. Thus, only those files are monitored which paths are covered by the monitoring scope and are not covered by 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 thus increasing the 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 of this directory or files modified in it to the list of exclusions. In this case, the SpIDer Guard file system monitor stops responding to modification of these objects, even if they are covered by the monitoring scope. Moreover, you can add the program processing the files to the list of trusted programs (the ExcludedProc configuration parameter). In this case, file operations of this program will not result in scanning even if they are covered by the monitoring scope. Similarly, if necessary, you can disable monitoring and scanning of files from other file systems that are mounted on the local file system (for example, external file server directories mounted via CIFS). To specify file systems which files should not be scanned, use the ExcludedFilesystem parameter.

Protected spaces, as parts of the monitoring scope with scan parameters specified for them, are set in the component settings as named sections, which names contain a unique identifier assigned to the protected space. Each section describing a space contains the Path parameter that defines a path in the file system storing directories of this protected space (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. * and ? characters). Besides local exclusion scopes, you can also specify a global exclusion scope by using the ExcludedPath parameter specified outside the sections describing protected spaces. All directories covered by this scope, including the directories of protected spaces, are excluded from monitoring. Only global and individual exclusion scopes can be applied to each protected space: if a space is nested in another, the exclusion settings specified for the enclosing space are not applied to the nested space. In addition, each protected scope settings have the Enable logical parameter which determines whether the files covered by this space are monitored. If this parameter is set to No, the contents of this space is not monitored. Moreover, the protected space is not monitored if the Path parameter has an empty value.

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

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

Enhanced File Monitoring Mode

SpIDer Guard can use three monitoring modes:

•Regular (set by default)—monitors file access operations (creation, opening, closing, and running). Scanning of a file, access to which has been allowed, is requested. If a threat is detected upon the scan, the action to neutralize the threat can be applied to the file. Applications are allowed to access the file until the file scanning is finished.

•Enhanced control of executable files—monitor files considered non-executable as in regular mode. SpIDer Guard blocks access to an executable file until its scanning is finished.

•“Paranoid” mode—SpIDer Guard blocks access to any file until its scanning is finished.

Dr.Web File Checker stores file scan results in specialized cache for a certain time, so reaccessing the same file does not lead to rescanning it if there is information in the cache; the result extracted from the cache is therefore displayed as the scan result. Despite this, the use of the “paranoid” monitoring mode leads to a significant slowdown in accessing files.

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