Operating Principles

Top  Previous  Next

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.

For some operating systems an already compiled kernel module is supplied together with SpIDer Guard. If a kernel module is not compiled for the operating system that uses SpIDer Guard, use the source code files, provided by Doctor Web to build and install the kernel module manually (for instructions, refer to the Building kernel module for SpIDer Guard) section.

When 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 Enginescanning engine. The operation scheme is shown in the picture below. The scheme of the monitor operation is shown in the Figure below.

Figure 12. Diagram of the components’ operation

To define file system objects that must be monitored, SpIDer Guard uses two configuration parameters:

IncludedPath—paths to be monitored (monitoring scope).

ExcludedPath—paths to be excluded from monitoring (exclusion scope).

Thus, only those files are monitored which paths are specified in the IncludedPath parameter and not specified in the ExcludedPath parameter. If a path is specified in both parameters, the IncludedPath parameter has higher priority than the other parameter: the objects are monitored by Samba file system monitor SpIDer Guard (for details on the algorithm to define objects to be included or excluded from monitoring, see below).

Example:

Let us assume that the lists contain the following paths:

IncludedPath = /a, /b/c, /d/file1
ExcludedPath = /b, /d/file1, /b/c/file2

Then the file system monitor SpIDer Guard will monitor access to:

All files in the /a directory

All files in the /b/c directory except for file2.

To the /d/file1 file.

With these settings, the monitor does not control operations with other files.

Note that specifying /b path in the ExcludedPath list is syntactically valid, but has no effect: files in this directory are not monitored anyway as this path is not within the monitoring scope specified in the IncludedPathlist.

Specifying exclusion in the ExcludedPath list 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.

The file system monitor SpIDer Guard automatically detects mounting and demounting of new file system volumes (for example, on USB flash drives, CD/DVD, RAID arrays) and adjusts the list of monitored objects, if required.

Defining Whether an Object is Monitored

To define whether a file system object is to be monitored, the file system monitor SpIDer Guard, when detecting a file operation, does the following:

1.Gets information on the process that performed the file operation. If the executable path of this process (name of the executable file and its full path) is specified in the ExcludedProc list, the modified object is not within the monitoring scope and will not be scanned; the procedure ends.

2.Otherwise the monitor gets the full path to the modified object.

3.This path is checked if it is specified in the IncludedPath or ExcludedPath lists.

4.If the path coincides with one of the items in the IncludedPath list, the object is scanned; the procedure ends.

5.If the path coincides with one of the items in the ExcludedPath list, the operation is ignored and the object is not scanned; the procedure ends.

6.If the path is not specified in any of the lists, the path is changed to another path which is one level up.

7.If this result path is empty, the procedure ends. Otherwise, the procedure goes to step 3.

The procedure continues until the result path of an iteration coincides with an item of either IncludedPath or ExcludedPath, or until the system root directory is reached.