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 the volumes which are specified in its settings (parameters NssVolumesMountDir and ProtectedVolumes). 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 Scanning Engine scanning engine to scan it. Another feature of the SpIDer Guard for NSS monitor is that it manages its own, separate, quarantine for threats detected on NSS volumes. A diagram of the monitor’s operation is shown in the figure below.

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 parameters NssVolumesMountDir and ProtectedVolumes) 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.