Operating Principles

Top  Previous  Next

The SpIDer Guard for NSS monitor operates as a daemon (usually it is started by the configuration daemon Dr.Web ConfigD at the startup of the operating system). This monitor controls only the volumes which are specified in the settings (NssVolumesMountDir and ProtectedVolumes parameters). 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 a volume, the monitor instructs the Dr.Web Scanning Engine to scan the file. 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.

Figure 1. Diagram of the components’ operation

In this scheme, the following notations are used:

 

— Dr.Web for UNIX as a whole and external Dr.Web applications together with systems which are not included in the solution.

 

— external to Dr.Web for UNIX programs and products for its integration.

 

— Components that are included in Dr.Web for UNIX engine. Other product components use the engine as a service that performs anti-virus checks.

 

— Service components designed to perform particular anti-virus protection functions (for example, scanning file system objects, updating virus databases, managing the operation of the product).

 

— Components that provide the user with the interface for Dr.Web for UNIX.

 

— Quarantine as a set of file system directories which store isolated malicious files.

Components marked with a dashed line can be missing depending on the distribution.

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.

Specifying paths to scanning objects

The monitor of NSS volumes SpIDer Guard for NSS checks only those objects that are located in protected volumes (the NssVolumesMountDir and ProtectedVolumes parameters) 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 parameter IncludedPath is better be used if you want to allow scanning of some objects that are located inside the path specified in the ExcludedPath parameter.

Consider an example of the monitor configuration:

NssVolumesMountDir = /media/nss
ProtectedVolumes =
ExcludedPath = vol1/path1, vol1/path2, vol2/sys
IncludedPath = vol1/path1, vol1/path2/incl, vol2/doc

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.