Operating Principles

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 which are specified in its settings (the ProtectedVolumes parameter). The file system point where NSS volumes are mounted, is detected automatically. The monitor does not detect automatically, when a new NSS file system volume is mounted or unmounted. When a new or modified file is found on the NSS volumes, the monitor instructs the Dr.Web File Checker component to scan it.

NSS volumes 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 infected file. The threat in the original file will not be detected. This file will be considered safe until an attempt to access this (original) file is performed or until it is modified if the file is located on an NSS volume.

If Quarantine action is specified for some threat type in NSS volumes monitor settings, the object containing a threat of this type will be placed to quarantine again on attempt to restore this object from quarantine to an NSS volume. For example, the following default settings:

NSS.OnKnownVirus = Cure
NSS.OnIncurable = Quarantine

move all incurable objects to quarantine. At that, when any incurable object is restored from quarantine to an NSS volume, this object is automatically returned to quarantine.

The monitor of NSS volumes SpIDer Guard for NSS checks only those objects that are located in protected volumes (the ProtectedVolumes parameter) and the specified paths to which either do not coincide with those specified the in the ExcludedPath parameter or matches the paths specified in the parameter IncludedPath. This parameter has priority over the parameter ExcludedPath—if the path to an object is specified in the both parameters, the object is scanned. It can be useful when, for example, files in some directory 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 virus 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 NSS volume monitor SpIDer Guard for NSS stops responding to modification of these objects. The IncludedPath parameter is better be used if you want to allow scanning of some objects that are located inside the path specified in the ExcludedPath parameter.

According to the specified parameters, the monitor checks all files in the volume vol3 (no limits on scanning), all files in the volume vol2 (except files in the /sys directory and in all its subdirectories). In the volume vol1, files in the /path2 directory are not checked; however, files in other directories of this volume, together with the content of the /path2/incl directory, are checked. Note that there is no sense to specify the same path (in this case, vol1/path) in the both lists because it means that there is no limits on the path scanning. Specifying the path vol2/doc in the IncludedPath parameter is also useless because this directory is not located in the exclusion scope set for the volume vol2 and contains only the /sys directory.

Parameters IncludedPath and ExcludedPath allow to use file masks (wildcards). For example, the following configuration

excludes from scanning on the volume vol1 (the volume mounted to the directory vol1 of the mounting point of the NSS volumes) all files that match the “*.txt” mask. Case sensitivity of paths indicated in parameters IncludedPath and ExcludedPath is defined by the NSS settings.