Operating Principles |
The file system monitor SpIDer Guard operates in user space (user mode) using either mechanism or a special Linuxkernel 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 kernel versions support 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 mode and then the mode. If neither of these two modes can be used, the component exits.
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). Let us assume that the lists contain the following paths:
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.
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. |