In this section
•Specifying Paths to Scanned Objects
The SpIDer Guard for NSS monitor operates as a daemon (usually, it is started by the Dr.Web ConfigD configuration daemon at the startup of the operating system). This monitor controls only those NSS volumes that are specified in its settings (the ProtectedVolumes parameter). The file system point on which NSS volumes are mounted is detected automatically. The list of monitored NSS volumes is not automatically adjusted upon their mounting or unmounting. When new or modified files are found on NSS volumes, the monitor instructs the Dr.Web File Checker component to scan them.
|
The NSS volume monitor has the following feature: if a threat is detected in a file upon its copying (to a protected volume or within an NSS volume), SpIDer Guard for NSS marks only the copy of the file as containing the threat. The original file is considered safe until an attempt to access it is performed; in addition, the file located on the NSS volume is scanned only upon modification.
If the QUARANTINE action is set for some threat types in NSS volume monitor settings, an object containing a threat of this type is immediately quarantined again on attempt to restore such object from quarantine to an NSS volume. For example, the default settings:
quarantine all incurable objects. Thus, if an incurable object is restored from quarantine to an NSS volume, this object is immediately quarantined again. |
Specifying Paths to Scanned Objects
The SpIDer Guard for NSS volume monitor scans only those file system objects that are located in protected NSS volumes (the ProtectedVolumes parameter) and paths to which do not match those specified in the ExcludedPath parameter or match the paths specified in the IncludedPath parameter. At the same time, the IncludedPath parameter has priority over the ExcludedPath parameter: if a path to an object is specified in both parameters, the object is scanned. Exclusions can be useful when, for example, files in some directory are frequently modified, which results in constant repeated scanning of these files and thus increases system load. If it is known with certainty that frequent modification of files in a directory is caused by a trusted program rather than by malware, you can add the path to this directory or to these files to the list of exclusions. In this case, the SpIDer Guard for NSS volume monitor stops reacting to modification of these files. The IncludedPath parameter is useful for scanning some objects that are located inside the path specified in the ExcludedPath parameter.
Let us consider the following configuration:
ProtectedVolumes = |
In case of such settings, the monitor scans all files in the vol3 volume (no limits on scanning), all files in the vol2 volume (except files in the /sys directory and in all its subdirectories). In the vol1 volume, only files in the /path2 directory are skipped; however, files in other directories of this volume that are not contained in /path2 are scanned together with the objects in the /path2/incl directory.
|
Specifying the same path (in this case, vol1/path) in both lists is useless, because this is equivalent to setting no restrictions to scanning of this path. In addition, specifying the vol2/doc path in the IncludedPath parameter is also useless, because the exclusion scope set for the vol2 volume covers only the /sys directory. |
The IncludedPath and ExcludedPath parameters accept file masks (wildcards). For example, the setting:
ExcludedPath = vol1/*.txt |
excludes all files that match the *.txt mask from scanning in the vol1 volume (the volume mounted on the vol1 directory of the mounting point of NSS volumes). Case sensitivity of paths specified in the IncludedPath and ExcludedPath parameters is defined by NSS settings.
|
Refer to the Integration with NSS Volumes section for information about integrating Dr.Web Server Security Suite with the file service. |