The file system monitor SpIDer Guard can operate in both user space (user mode) and Linux kernel space (via LKM — Linux kernel module). It is recommended to use automatic mode (auto), which will allow the module to define the best operation mode on startup, as not all Linux kernel versions support fanotify used when the monitor operates in user mode. If the module cannot support the specified integration mode, the module exits after startup. If the auto mode is selected, the modules attempts to use the user mode and then — LKM mode. If neither of these two modes can be used, the module exits.
When new or modified files are detected, the monitor sends component Dr.Web File Checker a task to scan these files. The component then initiates their scanning by scanning engine Dr.Web Scanning Engine. The operation scheme is shown in the picture below.
Picture 36. Component operation scheme
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 takes precedence over the other parameter: the objects are monitored by Samba file system monitor SpIDer Guard (for details on the algorithm to define objects 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:
oall files in the /a directory
oall files in the /b/c directory except for file2
o/d/file1
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 IncludedPath list.
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 add 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 (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 monitorSpIDer 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.