"Dr.Web for UNIX file servers" Administrator's manual

Doctor Web
Dr.Web®
for UNIX file servers
(OS Linux, FreeBSD and Solaris x86)
Administrator Manual
Version 5.0.0.1

© 2003-2009 Doctor Web. All rights reserved.
This document is a property of Doctor Web. No part of this document may be reproduced, published or transmitted in any form or by any means for
any other purpose than the purchaser’s personal use without proper attribution.
TRADEMARKS
Dr.Web is a registered trademark of Doctor Web.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
UNIX® is a registered trademark of The Open Group.
Other trademarks, registered trademarks and company names used in this document are property of their respective owners.
DISCLAIMER
In no event shall Doctor Web and its resellers or distributors be liable for errors or omissions, or any loss of profit or any other damage caused or
alleged to be caused directly or indirectly by this document, the use of or inability to use information contained in this document.
Dr.Web for UNIX file servers (OS Linux, FreeBSD and Solaris x86)
Version 5.0.0.1
Administrator Manual
Release date: 24.12.09
Doctor Web Head Office
2-12A, 3rd str. Yamskogo polya
Moscow, Russia
125124
Web site: http://www.drweb.com
Phone: +7 (495) 789-45-87
Refer to the official web site for regional and international office information.
2

Contents
1. Introduction...............................................................................................................................................5
1.1. What is this Manual about............................................................................................................................5
1.2. Terms and abbreviations..............................................................................................................................5
1.3. System requirements...................................................................................................................................6
1.4. Package files location...................................................................................................................................6
1.5. Configuration files........................................................................................................................................7
2. Installation and deinstallation.................................................................................................................10
2.1. Installation from distribution package for UNIX systems...............................................................................10
2.1.1. On computers using X Window system................................................................................................11
2.1.2. On computers working in command-line mode.....................................................................................11
2.2. Installation of Dr.Web Samba SpIDer from source codes..............................................................................12
2.3. Removal of distribution package for UNIX systems.......................................................................................13
2.4. Upgrade of distribution package for UNIX systems.......................................................................................14
2.5. User interface of graphical installer.............................................................................................................15
2.6. User interface of graphical uninstaller.........................................................................................................19
3. «Dr.Web for UNIX file servers» solution startup....................................................................................22
3.1. For Linux and Solaris..................................................................................................................................22
3.2. For FreeBSD..............................................................................................................................................22
3.3. Preparing OS protected by SELinux to interaction with Scanner and Daemon................................................22
4. Software registration. License key file....................................................................................................24
5. Updating components and virus databases.............................................................................................25
6. Updating module Dr.Web Updater...........................................................................................................26
6.1. Cron configuration.....................................................................................................................................26
6.2. Command line parameters..........................................................................................................................26
6.3. Configuration.............................................................................................................................................27
6.4. Updating process.......................................................................................................................................29
7. Console Scanner Dr.Web Scanner............................................................................................................30
7.1. Command Line Parameters.........................................................................................................................30
7.2. Configuration.............................................................................................................................................32
7.3. Start.........................................................................................................................................................38
8. Antivirus Module Dr.Web Daemon...........................................................................................................40
8.1. Command Line Parameters.........................................................................................................................40
8.2. Configuration.............................................................................................................................................40
8.3. Start.........................................................................................................................................................48
8.4. Signal Processing.......................................................................................................................................49
8.5. Verifying Availability of Dr.Web Daemon......................................................................................................49
8.6. Scanning Modes........................................................................................................................................52
9. Integrating Daemon with Samba File Server..........................................................................................53
9.1. Requirements............................................................................................................................................53
9.2. Plug-in of Dr.Web Samba SpIDer Module.....................................................................................................53
9.3. Start.........................................................................................................................................................53
9.4. Configuration.............................................................................................................................................54
9.5. Interaction with Distributed File System (MS DFS).......................................................................................59
10. «Dr.Web console for UNIX file servers»................................................................................................61
10.1. Installation..............................................................................................................................................61
10.2. Basic configuration...................................................................................................................................68
10.3. User interface..........................................................................................................................................69
10.3.1. «Configuration»...............................................................................................................................70
10.3.1.1. «General settings» tab..............................................................................................................71
10.3.2. «Quarantine»...................................................................................................................................72
11. Contact information...............................................................................................................................73
Appendix 1. The License Policy....................................................................................................................74
3

4
Protection of file servers (http://products.drweb.com/fileserver/unix/).................................................................74

Introduction
1. Introduction
1.1. What is this Manual about
This Manual describes the following Dr.Web® solutions for file servers in UNIX® based operating systems:
●«Dr.Web for UNIX file servers» for Linux;
●«Dr.Web for UNIX file servers» for FreeBSD;
●«Dr.Web for UNIX file servers» for Solaris.
As far as all these solutions for various UNIX based operating systems («UNIX systems» hereinafter) differ from each
other only slightly, then hereinafter all of them will be referred to as «Dr.Web for UNIX file servers». Critical differences
will be described in separate chapters and paragraphs.
Manual is designed for the person responsible for antivirus protection and security («Administrator» hereinafter).
Protection of file servers in UNIX systems consists of checking content of shared directories on viruses to prevent virus
expansion and contamination of the whole network. Viruses can be (and in most cases, they are) designed not directly
for UNIX systems. Through local networks ordinary Windows viruses are distributed, including macro-viruses for Word,
Excel and other office applications.
«Dr.Web for UNIX file servers» solution consists of three major components:
●Scanning package Dr.Web Scanner detects and cures viruses on local system.
●Antivirus package Dr.Web Daemon can be used almost in any data processing schemes as an external antivirus filter
plug-in.
●Dr.Web Samba VFS SpIDer is a monitor of file operations for Samba file servers. It is implemented as a plug-in for a
VFS interface (Virtual File System) in Samba. At the same time it works as a client of Dr.Web Daemon. Dr.Web
Samba VFS SpIDer package allows to integrate all other packages with Samba file servers.
In the present manual basic steps of setup, adjustment and startup procedures of «Dr.Web for UNIX file servers» solution
will be discussed.
●general information (chapter 1);
●installation of Dr.Web solution for file servers in UNIX systems (chapter 2);
●startup of Dr.Web solution for file servers in UNIX systems (chapters 3-4);
●usage of updating package Dr.Web Updater (chapters 5-6);
●usage of console scanner Dr.Web Scanner (chapter 7);
●usage of antivirus package Dr.Web Daemon (chapter 8);
●usage of Dr.Web Samba VFS SpIDer (chapters 9-10).
In the end of this Manual you will find technical support service contact information.
Dr.Web products are being constantly developed. Add-ons to virus databases are released daily or even several times a
day. New versions of programs appear. Diagnostics techniques and methods of antivirus protection, as well as integration
with other applications of UNIX systems are improved regularly. Besides that, the list of applications compatible with
Dr.Web is constantly expanding, therefore some settings and functions described in this Manual will slightly differ from
current program version. To get up-to-date program information please refer to documentation files included in delivery
package.
1.2. Terms and abbreviations
The following terms and abbreviations are used in this Manual (table 1).
Table 1. Legend.
5

Terms and abbreviations
Legend
Please note...
/var/drweb/
OS
Interpretation
Important remark or instruction
File and directory names, excerpts
from configuration files, parameter
definition examples, system library
and file names
Operating system
To define directories to which components of the software complex are installed, specific conventional symbols are used:
%bin_dir, %etc_dir and %var_dir. Depending on the used OS, these symbols refer to the following directories:
for Linux and Solaris:
%bin_dir = /opt/drweb/
%etc_dir = /etc/drweb/
%var_dir = /var/drweb/
for FreeBSD:
%bin_dir = /usr/local/drweb/
%etc_dir = /usr/local/etc/drweb/
%var_dir = /var/drweb/
1.3. System requirements
«Dr.Web for UNIX file servers» solution is compatible:
●with Linux distributions with kernel version 2.4.x and later;
●with FreeBSD version 6.x and later for Intel x86 platform;
●with Solaris version 10 for Intel x86 platform.
Installed Samba v.3.0.x to v.3.4.x is also required.
Dr.Web hardware requirements are similar to command line interface (CLI) hardware requirements for the appropriate
OS. No more than 20 Mb of disk space is required to install «Dr.Web for UNIX file servers» solution.
Depending on the range of problems to be solved by «Dr.Web for UNIX file servers» solution and total system load during
its operation, hardware requirements may vary widely.
1.4. Package files location
«Dr.Web for UNIX file servers» solution is installed by default to %bin_dir, %etc_dir and %var_dir directories.
OS-independent directory tree is created in these directories:
●%bin_dir ― executable modules of Dr.Web solution and updating package Dr.Web Updater (perl script
update.pl);
●%bin_dir/lib/ ― antivirus engine as loadable library (drweb32.dll). In the same subdirectory various
service libraries for packages of «Dr.Web for UNIX file servers» solution can reside;
●%var_dir/bases/*.vdb ― databases of known viruses;
●%etc_dir/drweb32.ini ― main configuration file;
●%etc_dir/smb_spider.conf ― Dr.Web Samba VFS SpIDer configuration file;
6
●%bin_dir/lib/ru_scanner.dwl, %bin_dir/lib/ru_daemon.dwl ― language files for Dr.Web
Scanner and Dr.Web Daemon packages;

Package files location
●%bin_dir/doc/ ― documentation. All documentation is presented in plain text files in English and Russian
(KOI8-R and UTF-8 encodings) languages;
●%bin_dir/doc/samba/ ― documentation for Dr.Web Samba VFS SpIDer module and shell script updatelinks.sh
for automatic creation and update of symbolic links;
●%var_dir/infected/ ― quarantine directory to move infected or suspicious files to if such reaction is
specified in settings for Dr.Web software system components.
1.5. Configuration files
Setup of Dr.Web software system components is performed using configuration files. Configuration files are plain text files
(so they can be modified with any text editor) with the following structure:
--- beginning of file ---
[Section 1 name]
Parameter1 = value1, ..., valueK
...
ParameterM = value1, ..., valueK
...
[Section X name]
Parameter1 = value1, ..., valueK
...
ParameterY = value1, ..., valueK
--- end of file ---
If the line begins with «;» or «#» symbols, it is considered to be the line of comments. These lines are skipped when
reading parameters from the configuration file.
If any parameter is commented out or not specified, it does not mean that this parameter has no value. In this case the
hardcoded default value will be used. Only few parameters are optional or do not have default values. Every such case
will be described separately.
When a parameter is set incorrectly Dr.Web software system outputs error message and terminates.
When any unknown parameter is found in configuration file, packages of Dr.Web software system continue execution and
output a warning into the log file.
Parameter values can be enclosed in quotation marks (and must be enclosed in quotation marks when contain white
spaces). Some parameters can have several values. These values can be delimited by comma, or each value can be set in
a separate string of configuration file. Possibility to have multiple values is clearly stated in parameter description.
Examples:
Multiple values delimited by commas:
Names = XXXXX, YYYYY
Multiple values set in several strings:
Names = XXXXX
Names = YYYYY
All parameters in this Manual are described in the following way:
ParameterName = {parameter type | possible values}
Parameter description.
7

Configuration files
{possibility to have multiple values}.
Default value:
ParameterName = {value | empty}
Parameters are described in the order they are presented in the corresponding configuration file.
Parameter type can be:
●Numerical value ― parameter value is an integer positive number;
●Time ― parameter value is set in time measurement units. Value is a positive number followed by time
measurement unit type (s ― seconds, m ― minutes, h ― hours; case insensitive). If time measurement unit type
is omitted, value is considered to be set in seconds.
Examples: 30s, 15m;
●Capacity ― parameter value is set in memory capacity measurement units (either disk space or memory
capacity). Value is an integer number followed by memory capacity measurement unit type (b ― bytes, k ―
kilobytes, m ― megabytes, g ― gigabytes; case insensitive). If memory capacity measurement unit type is
omitted, value is considered to be set in bytes.
Examples: 20b, 15k;
●Path to file | directory ― parameter sets file or directory location within file system;
●Actions ― actions to be performed with objects induced a reaction of «Dr.Web for UNIX file servers» solution
components. Set of acceptable actions for different parameters may vary, and in this case it is clearly specified in
the description of each parameter separately.
All possible actions:
●Cure ― cure the infected file;
●Move ― remove the infected file to quarantine directory;
●Truncate ― cut the file to zero length;
●Delete ― delete the infected file;
●Rename ― rename the infected file;
●Ignore – skip the file;
●Pass ― output information about the file to log only (for Dr.Web Scanner package);
●Report ― output information about the file to log only.
●Address ― socket addresses of Dr.Web software system components and external packages. These parameters
are specified in type:address format. The following address types are acceptable:
●inet - TCP sockets are used, address is specified in port@hostname format. hostname can be either
direct IP address or host domain name.
Example: Address = inet:3003@localhost;
●local – local UNIX sockets are used, address is a path to socket file.
Example: Address = local:/var/drweb/run/.drwebd;
●PID ― real address of the process must be read from its pid-file. This address type is acceptable only in
some cases, and in such case it will be explicitly indicated in parameter description.
●Text ― parameter value is a text string, which can be enclosed in quotation marks (and must be enclosed in
quotation marks when contain white spaces);
8

Configuration files
●Strings and files ― sets of text values delimited by commas. If parameter value is set in
file:/path_to_file format, then text values are taken from the file path_to_file. In this file each
text value must be specified in a separate line. If it appears to be impossible to read values from
path_to_file file, components of «Dr.Web for UNIX file servers» solution continue execution and output a
warning into the log file;
●Other values ― some parameters may have parameter types not described in this list.
Logging for Dr.Web software system components may be exceptionally detailed (when Debug value is specified, and
logged information is used for debugging) or may be omitted (when Quiet value is specified, and no information is
logged at all). For all parameters responsible for logging values are taken from the following list: Quiet, Error, Info,
Alert, Notice, Warning, Verbose, Debug.
Dr.Web Daemon and Dr.Web Scanner components have the following log detalization levels: Error, Info, Notice,
Warning, Alert. Dr.Web Updater component work with levels: Quiet, Error, Alert, Info, Debug, Verbose.
Dr.Web Samba VFS SpIDer component uses the following values when specifying log detalization levels: Debug,
Verbose, Info, Alerts, Errors, Quiet.
9

Installation and deinstallation
2. Installation and deinstallation
Below you can find detailed description of «Dr.Web for UNIX file servers» solution installation and deinstallation
procedures for Linux. Administrator (root) privileges are necessary to perform all these operations.
You must carefully uninstall all other packages of earlier product versions (delivered in rpm or deb formats) from previous
installations.
«Dr.Web for UNIX file servers» solution distribution package for UNIX systems is delivered in EPM format (script-based
distribution package with installation and removal scripts and standard install/uninstall GUIs) designed to use with ESP
Package Manager (EPM). Please note, that all these scripts belong only to EPM-package itself, not to any of the
components of Dr.Web software system.
Installation, deinstallation and upgrade procedures for «Dr.Web for UNIX file servers» solution can be carried out in the
following ways:
●via install/uninstall GUIs;
●via install/uninstall console scripts.
In the process of setup dependencies are supported. For installation of some components, other components must be
previously installed (for example, drweb-daemon requires drweb-common and drweb-bases components to be
already installed). With dependencies such step-by-step installation will be performed automatically.
In the process of deinstallation dependencies are supported only for graphical uninstaller. When deinstallation is
performed with uninstall console scripts, only explicitly specified component will be removed.
Please note, that if you install «Dr.Web for UNIX file servers» solution to the computer, where some other Dr.Web
products have been previously installed from EPM-packages, then at every attempt to remove some modules via uninstall
GUI you will be prompted to remove absolutely all Dr.Web modules, including those from other products. Please, pay
special attention to the actions you perform and selections you make during deinstallation to avoid accidental removal of
some useful components.
Please note, that during initial installation only software itself is installed. None of the components are started after setup
or after reboot.
2.1. Installation from distribution package for UNIX systems
«Dr.Web for UNIX file servers» solution is distributed as a self-extracting package drweb-fileservers_5.0.X_[OS
name].run (i.e. drweb-file-servers_5.0.X_linux.run – for Linux OS,
drweb-file-servers_5.0.X_bsd.run — for FreeBSD OS and drweb-fileservers_5.0.X_solaris.run
— for Solaris OS, where X is the version number). The following components are
included into this distribution:
●drweb-common: contains main configuration file drweb32.ini, libraries, documentation and directory
structure. During installation of this component drweb user and drweb group will be created;
●drweb-bases: contains antivirus search engine (Engine) and virus databases. It requires drweb-common
package to be previously installed;
●drweb-updater: contains update utility (Updater) for Engine, virus databases and content-specific black lists. It
requires drweb-common package to be previously installed;
●drweb-daemon: contains Dr.Web Daemon executable files and its documentation. It requires drweb-bases
package to be previously installed;
●drweb-scanner: contains Dr.Web Scanner executable files and its documentation. It requires drweb-bases
package to be previously installed;
●drweb-smbspider: contains compiled libraries for different versions of Samba servers. It requires drwebcommon
package to be previously installed;
10

Installation from distribution package for UNIX systems
●drweb-smbspider-src: contains source codes to enable user compile libraries for his own version of Samba
server or system architecture;
●drweb-file-servers-doc: contains Administrator manual in english and russian languages.
2.1.1. On computers using X Window system
To install all the components of «Dr.Web for UNIX file servers» solution automatically you may use either console (CLI) or
the default file manager of your GUI-based shell. In the first case allow the execution of the corresponding self-extracting
package with the following command:
and then run it:
# chmod +x drweb-file-servers_5.0.X_[OS name].run
# ./drweb-file-servers_5.0.X_[OS name].run
As a result drweb-file-servers_5.0.X_[OS name] directory will be created, and install GUI will be initialized
(for the detailed description of graphical user interface refer to the subsequent chapters of this Manual). If startup has
been performed without root privileges, install GUI will try to gain appropriate privileges by itself.
If you want only to extract the content of the package without starting install GUI, use --noexec command line
parameter:
# ./drweb-file-servers_5.0.X_[OS name].run --noexec
After you extract the content, you may initialize install GUI and continue setup with the following command:
# drweb-file-servers_5.0.X_[OS name]/install.sh
If it is impossible or unacceptable to use install GUI, you may use corresponding install scripts. Run executable
*.install files in console with the following commands:
# drweb-file-servers_5.0.X_[OS name]/[component_name].install
If you want to perform installation without any additional movements (eg. confirmations on various setup stages), you
may use now command line parameter. Please note, that if you choose to use this parameter, you automatically confirm
and accept the Software License Agreement. (Text files with Software License Agreement in english and russian
languages - LICENSE and LICENSE.ru – are included in the distribution package.)
2.1.2. On computers working in command-line mode
When you get access to the Unix server, copy installation package to the temporary directory and extract its content.
# mkdir /tmp/fileservers/
# cp /root/drweb/fileservers/drweb-file-servers_5.0.X_[OS name].run
/tmp/fileservers/
# cd /tmp/fileservers/
# chmod +x /tmp/fileservers/drweb-file-servers_5.0.X_[OS name].run
# /tmp/fileservers/drweb-file-servers_5.0.X_[OS name].run -–noexec
All extracted files will be saved to the /tmp/fileservers/drweb-file-servers_5.0.X_[OS name]
directory.
Run executable *.install files for all necessary components with the following commands:
# drweb-file-servers_5.0.X_[OS name]/[component_name].install
Setup procedure is identical for all the packages. Immediately after start you will be prompted to confirm your intention
to perform the installation. After that you will be offered to read and accept the Software License Agreement (by entering
yes in reply to the corresponding system question).
11

Installation from distribution package for UNIX systems
You can also use now command line parameter to perform installation without any additional movements (e.g.
confirmations on various setup stages).
During the installation the following processes take place:
●original configuration files are recorded to the %etc_dir/software/conf/ directory with the following
names: [configuration_file_name].N;
●operational copies of configuration files are placed to the corresponding directories of the installing software;
●other files are installed. If in the corresponding directory file with the same name already exists (e.g. after
inaccurate removal of previous versions of the packages), it will be overwritten with the new file, and its copy will
be saved as [file_name].O. If some [file_name].O file already exists in this directory, it will be replaced
with the new file of the same name;
●update-links.sh script is executed. It checks for the version of Samba server and then creates a symbolic link
in /usr/lib/samba/vfs/ directory to the library from %bin_dir/lib/ directory for the specific Samba
version. Please note, that if two different versions of Samba were installed in one directory, then the symbolic link
will be created for only one of them. If different versions of Samba were installed in separate directories, then for
each Samba individual symbolic link will be created. The following lines will be output to log for each Samba
installed.
Example for Linux OS:
--- cut ---
Update links for /usr/sbin/smbd
create symlink /opt/drweb/lib/libsmb_spider.so.3.X.X --> /usr/lib/samba/vfs/
smb_spider.so
Please, update your config /etc/samba/smb.conf
--- cut ---
2.2. Installation of Dr.Web Samba SpIDer from source codes
If you use some other versions of Samba or Samba for 64-bit operating system, you can compile Dr.Web Samba SpIDer
from source codes included in drweb-smbspider-src distribution package. To perform this operation you will also
need source codes of your Samba (corresponding packages can be downloaded from Samba.org web-site at
http://us1.samba.org/samba/ftp/old-versions/).
To compile Dr.Web Samba SpIDer from source codes, perform the following actions:
●Install drweb-smbspider-src package:
# drweb-file-servers_5.0.X_[OS name]/drweb-smbspider-src.install
If you want to perform installation without any additional movements (eg. confirmations on various setup stages),
you may use now command line parameter. Please note, that if you choose to use this parameter, you
automatically confirm and accept the Software License Agreement. (Text files with Software License Agreement in
english and russian languages - LICENSE and LICENSE.ru – are included in the distribution package.)
After the installation drweb-smbspider-5.0.0.src.tar.gz tarball-archive will appear in /usr/src/
directory.
●Change your directory to /usr/src/ and extract content of the archive:
# tar -xzvf drweb-smbspider-5.0.0.src.tar.gz
Please note, that for Solaris OS a differenr set of commands is required to extract content of the archive:
# gunzip drweb-smbspider-5.0.0.src.tar.gz
12

Installation of Dr.Web Samba SpIDer from source codes
# tar -xvf drweb-smbspider-5.0.0.src.tar
●Change your directory to /usr/src/drweb-smbspider-5.0.0.src and execute the following command:
# ./configure –with-samba-source=/directory/with/source/codes/of/Samba
By default Samba binary is taken from /usr/sbin/. But if there several versions of Samba are installed on your
computer or some alternative location has been chosen for installation of the sole Samba, then path to the
directory with Samba binary must be specified manually with --with-smbd command line parameter.
Example:
# ./configure --with-smbd=/directory/with/Samba/binary –with-sambasource=/directory/with/source/codes/of/Samba
Please note, that for the successful execution of this command m4 macro processor, GCC compiler system and
make utility must be installed to your system.
●Complete the compilation of Dr.Web Samba SpIDer and install it with the following commands:
# make
# make install
After make command is executed a libsmb_spider.so library is created and placed to the hidden folder in
the directory with Dr.Web Samba SpIDer source codes.
During the execution of make install command the following actions are performed:
• libsmb_spider.so library is copied to the /opt/drweb/lib/ directory;
• libsmb_spider.so is renamed to libsmb_spider.so.X.Y.Z (where X.Y.Z is the
version number of the Samba, path to which was specified for the configure command),
• a symbolic link pointing to the renamed library is created
/directory/with/Samba/libraries/vfs/smb_spider.so. (where path to the
directory with Samba libraries is taken from the Samba binary specified for the configure
command).
2.3. Removal of distribution package for UNIX systems
To remove all the components of «Dr.Web for UNIX file servers» solution via uninstall GUI, initialize it with the following
command:
# drweb-file-servers_5.0.X_[OS name]/remove.sh
For the detailed description of graphical user interface refer to the subsequent chapters of this Manual.
If it is impossible or unacceptable to use uninstall GUI, you may use corresponding uninstall scripts. Run executable
*.remove files in console with the following commands:
# drweb-file-servers_5.0.X_[OS name]/[component_name].remove
If you want to perform deinstallation without any additional movements (eg. confirmations on various uninstall stages),
you may use now command line parameter.
After deinstallation you can also remove drweb user and drweb group from your system.
During the deinstallation the following processes take place:
●original configuration files are removed from the %etc_dir/software/conf/ directory;
●if operational copies of configuration files were not modified by the user, they are also removed. If the user has
made any changes to them, they will be preserved;
13
●other Dr.Web files are removed. If during the installation a [file_name].O copy of some old file has been
created, this file will be restored under the name it had before the installation.

Removal of distribution package for UNIX systems
●license key files and log files are preserved in corresponding directories;
●update-links.sh script is executed with --remove parameter. It removes symbolic link usr/lib/samba/
vfs/smb_spider.so. Please note, that if there were several symbolic links for different versions of Samba, all
of them will be removed. The following lines will be output to log:
--- cut ---
Remove link /usr/lib/samba/vfs/smb_spider.so
Please, update your config /etc/samba/smb.conf
--- cut ---
2.4. Upgrade of distribution package for UNIX systems
Upgrade process combines install and uninstall procedures. If you want to upgrade «Dr.Web for UNIX file servers»
solution you must download the latest version of corresponding software, remove the previous version (refer to p. 2.3 of
this Manual for the detailed description of deinstallation) and install the new one (refer to p. 2.1 of this Manual for the
detailed description of setup).
When you upgrade «Dr.Web for UNIX file servers» solution, its license key files, log files and configuration files that have
been modified by the user are preserved in corresponding directories.
14

User interface of graphical installer
2.5. User interface of graphical installer
When you run install GUI with the following command:
# drweb-file-servers_5.0.X_[OS name]/install.sh
setup program window appears.
Figure 1. «Welcome» screen
Navigation is performed with «Back» and «Next» buttons. Setup can be aborted at any moment by clicking
«Cancel» button. In the «Install Type» screen you can choose preferable installation type: typical configuration
of «DrWeb for file servers» with all the components selected by default, or custom configuration.
Figure 2. «Install Type» screen
If you choose «Custom Configuration», you will be offered to select necessary components for the subsequent
installation from the list on the «Select Software» screen.
15

User interface of graphical installer
Figure 3. «Select Software» screen
Please note, that if for installation of any component some other components must be previously installed, all
corresponding dependencies will be selected for installation automatically. For example if you select «DrWeb
Antivirus Daemon» checkbox, «DrWeb Bases» and «DrWeb Common Files» checkboxes will be selected
as well.
If you click «Install All» button, all components will be selected. If you click «Install None» button, all
selection marks will be removed.
When you select everything you consider necessary (or if you have selected typical configuration on the previous stage),
you will be offered to overview and confirm all the choices made on the «Confirm» screen.
Figure 4. «Confirm» screen
16

User interface of graphical installer
On the next screen you will be offered to take notice of Software License Agreement and accept it to continue the
installation. With «Language» menu you may choose preferred display language (english or russian) for the Software
License Agreement.
Figure 5. «License» screen
On the «Installing» screen log of installation process is output in real-time mode.
Figure 6. «Installing» screen
At the same time log of installation process is written to install.log file from the drweb-fileservers_5.0.X_[OS
name] directory.
The last «Finish» screen contains notification about the necessity of further setup in order to provide proper operation
of «Dr.Web for UNIX file servers» solution.
17

User interface of graphical installer
Figure 7. «Finish» screen
Click the «Close» button to close setup program window.
18

User interface of graphical uninstaller
2.6. User interface of graphical uninstaller
When you run uninstall GUI with the following command:
# drweb-file-servers_5.0.X_[OS name]/remove.sh
deinstallation program window appears.
Figure 8. «Welcome» screen
Navigation is performed with «Back» and «Next» buttons. You can quit the program at any moment by clicking
«Cancel» button. On the next «Select Software» screen you will be offered to select components for the
removal from the list. All corresponding dependencies will be selected for deinstallation automatically.
Please note, that if you installed «Dr.Web for UNIX file servers» solution to the computer, where some other Dr.Web
products have been previously installed from EPM-packages, then absolutely all Dr.Web modules will be included in the
list of components available for removal, including those from other products. Please, pay special attention to the actions
you perform and selections you make during deinstallation to avoid accidental removal of some useful components.
Figure 9. «Select Software» screen
19

User interface of graphical uninstaller
If you click «Remove All» button, all components will be selected. If you click «Remove None» button, all
selection marks will be removed.
When you select everything you consider necessary, you will be offered to overview and confirm all the choices made on
the «Confirm» screen.
Figure 10. «Confirm» screen
On the last «Removing» screen log of deinstallation process is output in real-time mode.
Figure 11. «Removing» screen
20

User interface of graphical uninstaller
Click the «Close» button to close deinstallation program window.
21

«Dr.Web for UNIX file servers» solution startup
3. «Dr.Web for UNIX file servers» solution startup
3.1. For Linux and Solaris
To run the «Dr.Web for UNIX file servers» solution you must do the following:
●register the software;
●place the key file drweb32.key to the directory for Dr.Web executable files (default directory for UNIX systems is
%bin_dir). Please note, that if you want to use key file from the different location, you must specify full path to
it as a Key paremeter value of main configuration file drweb32.ini;
●configure the software by making necessary changes to configuration files. Please refer to the corresponding
chapters of this Manual for the detailed information on configuration;
●in drwebd.enable file from %etc_dir directory set 1 as a value of ENABLE variable to enable startup of
Dr.Web Daemon. If it is not required to run Dr.Web Daemon (properly configured and working Daemon on some
other computer in the network is used), ENABLE value must be set to 0 (it is also used as default value);
●run Dr.Web Daemon with the following command:
$ %bin_dir/drwebd
3.2. For FreeBSD
To run the «Dr.Web for UNIX file servers» solution you must do the following:
●register the software;
●place the key file drweb32.key to the directory for Dr.Web executable files (default directory for UNIX systems is
%bin_dir). Please note, that if you want to use key file from the different location, you must specify full path to
it as a Key paremeter value of main configuration file drweb32.ini;
●configure the software by making necessary changes to configuration files. Please refer to the corresponding
chapters of this Manual for the detailed information on configuration;
●add the following line to /etc/rc.conf file: drwebd_enable="YES" – to enable startup of Dr.Web
Daemon. If it is not required to run Dr.Web Daemon (properly configured and working Daemon on some other
computer in the network is used), then you can just not include the specified line in the rc.conf file.
●run Dr.Web Daemon with the following command:
$ %bin_dir/drwebd
3.3. Preparing OS protected by SELinux to interaction with Scanner and Daemon
22
To set up successful operation of Dr.Web Scanner and Dr.Web Daemon components in OS protected by SELinux, you must
compile politics for operation with corresponding modules drweb-scanner and drweb-daemon.
Please note, that templates used in compilation of modules for politics may vary widely, depending on the type of Linux
distribution, its version, set of SELinux politics and user settings. To receive more detailed information on compilation of
politics you may refer to corresponding documentation on your Linux distribution.
To create necessary politics you may use policygentool command, which takes two parameters: the name of the
policy module (interaction with which has to be adjusted) and the full path to the corresponding executable.
Example:
# policygentool drweb-scanner %bin_dir/drweb.real - for Scanner.
# policygentool drweb-daemon %bin_dir/drwebd.real - for Daemon.
You will be prompted to enter a few common domain characteristics, and for each module three files will be created:
[module_name].te, [module_name].fc and [module_name].if.

Preparing OS protected by SELinux to interaction with Scanner and Daemon
To compile the [module_name].te file execute the following command:
checkmodule -M -m -o module-name [module_name].te
Please note, that for successful policy compilation a checkpolicy package must be installed to the system.
To compile a required policy execute the following command:
semodule_package -o [module_name].pp -m module-name
To install the new policy module into the module store execute the following command:
semodule -i [module_name].pp
23

Software registration. License key file
4. Software registration. License key file
24
User privileges for using «Dr.Web for UNIX file servers» solution are controlled by special file called license key file.
License key file contains the following information:
●list of Dr.Web components licensed to user;
●license expiration date;
●other restrictions (for example, number of protected PCs).
License key file has *.key extension and by default must be placed in directory for Dr.Web executable files. License key
file is digitally signed to prevent its editing. Edited license key file becomes invalid. It is not recommended to open your
license key file in text editors to avoid its accidental corruption.
Users who have purchased «Dr.Web for UNIX file servers» solution from Dr.Web certified partners obtain the license key
file. The parameters of the key file are specified according to the license user has paid for. The license key file contains
the name of the user (or a company name), and the name of the selling company. For evaluation purposes users may
also obtain demo key file. It allows user to enjoy full functionality of the «Dr.Web for UNIX file servers» solution, but has
a limited term of use, and no technical support is provided.
License key file may be supplied as a file with *.key extension, or as a zip archive containing license key file.
License key file may be received using one of the following ways:
●sent by e-mail as a zip archive containing license key file with *.key extension (usually after registration on the
web site). Extract license key file using the appropriate archiving utility and copy/move it to the directory for
Dr.Web executable files (default directory for UNIX systems is %bin_dir);
●included into the distribution package;
●supplied on a separate media as a file with *.key extension. In this case user must copy it manually to the
%bin_dir directory.
License key file is sent to user via e-mail usually after registration on the web site (web site location is specified in
registration card accompanying the product). Visit the site, fill in the web form with your customer data and submit your
registration serial number (printed on the registration card). As a result of this procedure license is activated, and license
key file is created for the serial number provided. Then it is sent to user on the e-mail address specified.
It is recommended to keep license key file until it expires, and use it when reinstalling or repairing «Dr.Web for UNIX file
servers» solution installation. If the license key file is damaged or lost, it can be recovered by the same procedure as
during license activation. In this case you must use the same product serial number and customer data you have entered
during the registration, only e-mail address can be changed (in this case license key file will be sent to the new e-mail
address). If serial number matches any entry in Dr.Web database, the corresponding key file will be dispatched to user by
automatic system using e-mail address provided.
Registration with the same product serial number can be performed up to 25 times. If you need to recover lost license
key file after 25th registration, you must make a request for license key file recovery on
http://support.drweb.com/request/, and also specify all data used during registration, valid e-mail address and detailed
description of the situation. Request will be considered by Dr.Web technical support service engineers, and after approval
license key file will be provided to user via automatic support system or dispatched via e-mail.
Path to license key file of the certain component must be specified as a Key parameter value in corresponding
configuration file (drweb32.ini).
Example:
Key = %bin_dir/drweb32.key
If license key file specified as Key parameter value is failed to read (wrong path, permission denied), expired, blocked or
invalid, the corresponding component terminates. When less than two weeks left until the license expiration, Dr.Web
Scanner outputs warning message at start and Dr.Web Daemon notifies user via e-mail. Messages are sent at every
startup, restart or reload of the Daemon for every license key file installed. To enable this option you must set up
MailCommand parameter in [Daemon] section of drweb32.ini configuration file.

Updating components and virus databases
5. Updating components and virus databases
Components of «Dr.Web for UNIX file servers» solution require regular updating. For successful operation of antivirus and
traffic filtering modules, virus databases of the known viruses and content-specific black and white lists must be updated
regularly.
Dr.Web virus databases contains several *.vdb files, representing separate parts of it. On update servers these files are
also stored in lzma-archives. When new viruses appear, small files (only several Kbytes in size) with base segments
describing these viruses are released for amendment.
Add-ons are the same for all supported platforms. There are two types of them: daily "hot" add-ons (drwtoday.vdb)
and regular weekly updates (drwXXXYY.vdb), where XXX is for antivirus engine version number, and YY is a
sequential number, beginning from 00 (for example, the first regular update for version 5.0 will be named
drw50000.vdb).
«Hot» add-ons may be issued daily or even several times a day to provide effective protection against new viruses. This
type of add-ons must be installed over the old ones: i.e. previous drwtoday.vdb file will be overwritten. When new
regular add-on is released, all records from drwtoday.vdb are copied to drwXXXYY.vdb, and new empty
drwtoday.vdb file is issued.
If you want to update virus databases manually, you must install all missing regular add-ons first, and then overwrite
drwtoday.vdb file.
To add the add-on to the main virus databases, place the corresponding file to the directory for «Dr.Web for UNIX file
servers» solution executable files (%var_dir/bases/ by default) or to any other directory specified in the
configuration file.
Signatures for virus-like malicious programs (adware, dialers, hacktools, etc.) are supplied in two additional files -
drwrisky.vdb and drwnasty.vdb - with the structure similar to virus databases. These files are also updated
regularly: dwrXXYYY.vdb and dwnXXYYY.vdb are for regular updates, and dwrtoday.vdb and
dwntoday.vdb are for «hot» updates.
From time to time (as brand new viruses and antivirus techniques appear), new versions of the antivirus package are
released, containing the updated algorithms, implemented in the antivirus Engine. At the same time, all released add-ons
are brought together, and the new package version is completed with the updated main virus databases with descriptions
of all known viruses. Usually, when upgrading the package to the new version the portability of bases is assured: i.e. new
bases can be linked up to the old Engine. Please note, that this does not guarantee detection or curing of new viruses, as
it requires upgrading of algorithms in the antivirus engine.
After regular updating, virus databases attain the following structure:
●drwebase.vdb ― general virus database, received with the new version of the package
●drwXXXYY.vdb ― regular weekly add-ons;
●drwtoday.vdb ― «hot» add-ons issued daily or several times a day;
●drwnasty.vdb ― general database of malware, received with the new version of the package;
●dwnXXXYY.vdb ― regular weekly add-ons;
●dwntoday.vdb ― «hot» add-ons issued daily or several times a day;
●drwrisky.vdb ― general database of riskware, received with the new version of the package;
●dwrXXXYY.vdb ― regular weekly add-ons;
●dwrtoday.vdb ― «hot» add-ons issued daily or several times a day.
25

Updating module Dr.Web Updater
6. Updating module Dr.Web Updater
For automatic receipt and installation of the anti-virus add-ons and content-specific black and white lists you must use a
special updating module Dr.Web Updater.
Updating module is a script update.pl written in Perl. It can be found in directory containing executable files of
«Dr.Web for UNIX file servers» solution.
Dr.Web Updater settings are stored in [Updater] section of the main configuration file (drweb32.ini by default)
from %etc_dir directory. If you want to use alternative configuration file, specify the full path to it by command line
parameter at start.
To run the script use the following command:
$ %bin_dir/update.pl [parameters]
6.1. Cron configuration
For Linux: a special file with user settings will be created in /etc/cron.d/ during installation of the software complex.
It will enable interaction between cron and Dr.Web Updater.
For FreeBSD and Solaris: manual configuration of cron is required to enable its interaction with Dr.Web Updater. For
example, when you use FreeBDS you may add the following string to the crontab of drweb user:
*/30 * * * * /usr/local/drweb/update.pl
If you work with Solaris, the following set of commands can be used:
# crontab -e drweb
# 0,30 * * * * /opt/drweb/update.pl
6.2. Command line parameters
At this stage, two formats of the command line parameters for Dr.Web Updater are supported. Using the first format
version, you can specify only one parameter - full name of the used configuration file. With the second version the
following parameters can be specified in any order:
●--ini=path_to_configuration_file
●--what=component_to_be_updated
Instead of component_to_be_updated value scanner or daemon values must be used. If value of this
command line parameter is not specified, information from configuration file is used.
Also --not-need-restart parameter can be specified as command line parameter. It can be used in several ways:
●If this parameter is not specified, all daemons (Dr.Web Daemon in «Dr.Web for UNIX file servers» solution) will be
restarted after update.pl script finishes its work. (Note: daemons will be restarted only if any of their
components has been updated/removed/added during script operation.).
●If --not-need-restart parameter is specified, but no value is set for it, none of the daemons will be
restarted after update.pl script finishes its work, even if any of their components has been updated/removed/
added during script operation.
●Daemons names can be used as values for --not-need-restart parameter. Several names can be specified in
one string, without white spaces and with comma, used as delimiter. Values are case insensitive. Daemons, which
names are specified as parameter values, will not be restarted.
Example:
$ %bin_dir/update.pl --not-need-restart=drwebd
26

Configuration
6.3. Configuration
27
Description of configuration file structure and parameter types can be found in p. 1.5 of this Manual. Parameters are
described in the order they are presented in main configuration file.
[Updater] section.
UpdatePluginsOnly = {Yes | No}
With Yes value specified Dr.Web Updater will not update Daemon and Scanner. It will update only plug-ins.
Default value:
UpdatePluginsOnly = No
Section = {Daemon | Scanner}
Specifies from which section Updater will take settings to determine program version, paths to virus databases, etc. Value
of this parameter can be overridden by --what= command line parameter at start.
Default value:
Section = Daemon
ProgramPath = {path to file}
Path to the Daemon/Scanner. It is used by Dr.Web Updater for getting the product version and API information of the
installed executable file.
Default value:
ProgramPath = %bin_dir/drwebd
SignedReader = {path to file}
This program is used by Dr.Web Updater to read signed files.
Default value:
SignedReader = %bin_dir/read_signed
LzmaDecoderPath = {path to file}
Path to program used for unpacking of lzma-archives.
Default value:
LzmaDecoderPath =
LockFile = {path to file}
Path to lock file used to prevent sharing of certain files during their processing by Dr.Web Updater.
Default value:
LockFile = %var_dir/run/update.lock
CronSummary = {Yes | No}
If Yes value is specified, Dr.Web Updater will output statistics on each session to stdout. This mode can be used to
send administrator notifications by email, if Updater is run by the cron daemon.
Default value:
CronSummary = Yes
DrlFile = {path to file}
Path to file containing list of accessible Dr.Web updating servers. Dr.Web Updater selects the server from this list in a
random manner. This file is signed by Doctor Web and must not be modified by the user. It is updated automatically.
Default value:

Configuration
DrlFile = %var_dir/bases/update.drl
DrlDir = {path to directory}
Path to directory where signed *.drl files with lists of update servers for every plug-in are stored.
Default value:
DrlDir = %var_dir/drl/
Timeout = {numerical value in seconds}
Maximum time for download of updates.
Default value:
Timeout = 90
Tries = {numerical value}
Number of attempts to be made by Dr.Web Updater to establish a connection with update server.
Default value:
Tries = 3
ProxyServer = {proxy server name or IP}
Name or IP address of proxy server used.
Default value:
ProxyServer =
ProxyLogin = {proxy server user login}
User login for proxy server.
Default value:
ProxyLogin =
ProxyPassword = {proxy server user password}
User password for proxy server.
Default value:
ProxyPassword =
Log settings for Dr.Web Updater are specified below:
LogFileName = {path to file}
Log file name. You can specify syslog as log filename and logging will be carried out by syslogd system service. In
this case SyslogFacility and SyslogPriority parameters must be also specified. As syslogd uses several
files for logging various events of different importance, these two parameters and syslogd configuration file (usually /
etc/syslogd.conf) determine location where information is logged to.
Default value:
LogFileName = syslog
SyslogFacility = {Daemon | Local0 .. Local7 | Kern | User | Mail}
Log type when syslogd system service is used for activity logging (please refer to syslog documentation for further
details).
Default value:
SyslogFacility = Daemon
28
LogLevel = {Debug | Verbose | Info | Warning | Error | Quiet}

Configuration
Log verbosity level.
Default value:
LogLevel = Verbose
6.4. Updating process
The updating process includes the following stages:
●Dr.Web Updater reads the configuration file.
●Parameters to be used are located in [Updater] section of main configuration file, except for the following:
EnginePath (serves both to determine the Daemon version and to specify the directory, where updated
drweb32.dll file is downloaded), VirusBase (serves to specify the directory, where updated virus
databases are downloaded.), UpdatePath (serves to specify the directory, where all other updated files are
downloaded) and PidFile (serves to specify path to file, from which the drwebd process identifier used for
the restart of the Daemon is read).
●Dr.Web Updater requests the list of updates from the server, then tries to download lzma-archives of the
corresponding bases. If no lzma-archives are found, it downloads necessary bases in *.vdb and *.dws formats.
To extract files from lzma-archives special lzma-utility is used, path to which is specified by LzmaDecoderPath
parameter value in the [Updater] section of main configuration file.
●Downloaded updates are placed to the corresponding directories as described above.
29

Console Scanner Dr.Web Scanner
7. Console Scanner Dr.Web Scanner
7.1. Command Line Parameters
30
Dr. Web Scanner is a command line interface (CLI) program operating in command line mode (or X Window terminal
emulator). To run Dr.Web Scanner you can use the following command:
$ ./drweb -path [command line parameters]
where - is the path to scanned directory or the mask for checked files.
When Scanner is started only with argument without any parameters specified, it scans the specified directory
using the default set of parameters. In the following example user home directory is being checked:
$ ./drweb -path ~
When scan is finished, Scanner outputs information about all detected infected and suspicious files in the following
manner:
/path/file infected [virus] VIRUS_NAME
After presenting information about infected or suspicious files, Scanner outputs summary report in the following manner:
Report for "/opt/drweb/tmp":
Scanned : 34/32 Cured : 0
Infected : 5/5 Removed : 0
Modifications : 0/0 Renamed : 0
Suspicious : 0/0 Moved : 0
Scanning time : 00:00:02 Speed : 5233 KB/s
Numbers divided by slash «/» mean: the first one - total number of files, the second one - number of files in archives.
Please note, that Dr.Web distribution package contains special text file readme.eicar.rus. With the text editor you
can easily create the eicar.com program (refer to instructions inside readme.eicar.rus file for more details),
which is used to test antiviruses and therefore is included in all virus databases.
The following report will be output:
%bin_dir/doc/eicar.com infected by Eicar Test File (Not a Virus!)
Like any other UNIX program Dr.Web Scanner supports numerous command line parameters. They are separated from
specified path by white space and are prefixed by hyphen «-». To get complete list of parameters, start Scanner with
-?, -h or -help parameters.
Main program parameters can be classified in the following way:
●scan area parameters;
●diagnostics parameters;
●actions parameters;
●interface parameters.
Scan area parameters determine where the virus check must be performed. They include:
●path — specify path for scan. Several paths can be specified in one parameter;
●@[+] ― check objects listed in . Plus «+» instructs Scanner not to delete files from the list of
objects after scan is completed. List file may contain paths to directories that must be scanned regularly, or list of
files to be checked only once;
●sd ― recursive search and scan of files in subdirectories starting from the current directory;

Command Line Parameters
●fl ― follow links, both to files and directories; links causing loops are ignored;
31
●mask — ignore masks for file names.
Diagnostics parameters determining what types of objects must be scanned for viruses:
●al ― scan all files on specified drive or in specified directory;
●ar[d|m|r][n] ― scan files in archives (ARJ, CAB, GZIP, RAR, TAR, ZIP, etc.). d - delete, m - move, r - rename
archives containing infected objects, n - archiver name output disabled. Archives can be in simple (*.tar) or
compressed forms (*.tar.bz2, *.tbz);
●cn[d|m|r][n] ― scan files in containers (HTML, RTF, PowerPoint,..). d - delete, m - move, r - rename
containers containing infected objects, n - container type output disabled;
●ml[d|m|r][n] ― scan files in mailboxes. d - delete, m - move, r - rename mailboxes, containing infected
objects; n - mailbox type output disabled;
●upn ― scan executable files packed with LZEXE, DIET, PKLITE, EXEPACK with compression type output disabled;
●ex ― diagnostics using file masks (see FilesTypes parameter in configuration file);
●ha ― heuristic analysis (search for unknown viruses).
Actions parameters determine what actions must be performed if infected or suspicious files are detected. They include:
●cu[d|m|r] ― cure infected files: d - delete, m - move, r - rename infected files;
●ic[d|m|r] ― actions for incurable files: d - delete, m - move, r - rename incurable files;
●sp[d|m|r] ― actions for suspicious files: d - delete, m - move, r - rename suspicious files;
●adw[d|m|r|i] ― actions for files containing adware: d - delete, m - move, r - rename, i - ignore;
●dls[d|m|r|i] ― actions for dialers: d - delete, m - move, r - rename, i - ignore;
●jok[d|m|r|i] ― actions for joke programs: d - delete, m - move, r - rename, i - ignore;
●rsk[d|m|r|i] ― actions for potentially dangerous programs: d - delete, m - move, r - rename, i - ignore;
●hck[d|m|r|i] ― actions for hacktools: d - delete, m - move, r - rename, i - ignore;
Interface parameters configure Scanner report output and include:
●v, version – output information about product and Engine versions;
●ki – output information about key file and its owner (in UTF8 encoding only);
●foreground[yes|no] – enable Scanner to run in foreground or in background;
●ot ― output information to standard output (stdout);
●oq ― disable information output;
●ok ― display «Ok» for not infected files;
●log= ― logging to specified file;
●ini= ― use alternative configuration file;
●lng= ― use alternative language file. If English interface has been chosen during installation,
you may specify ru_scanner.dwl file to display reports in Russian.
You can use hyphen «-» postfix to disable the following parameters:
-ar -cu -ha -ic -fl -ml -ok -sd -sp
For example, if you start Scanner with the following command:

Command Line Parameters
$ drweb -path -haheuristic
analysis (enabled by default) will be disabled.
By default (if Scanner configuration was not customized and no parameters were specified) Scanner starts with the
following parameters:
-ar -ha -fl- -ml -sd
Default Scanner parameters (including scan of archives, packed files and mailboxes, recursive search, heuristic analysis,
etc.) is sufficient for everyday diagnostics and can be used in typical cases. You can also use hyphen «-» postfix to
disable some parameters, as it was explained above.
Disabling scan of archives and packed files will significantly decrease antivirus protection level, because in archives
(especially, self-extracting) enclosed in e-mail attachments viruses are distributed. Office documents potentially
susceptible to infection with macro viruses (Word, Excel) are also dispatched via e-mail in archives and containers.
When you run Scanner with default parameters, no cure actions and no actions for incurable and suspicious files are
taken. For these actions to be performed, you must specify corresponding command line parameters explicitly.
Set of actions parameters may vary in particular cases. We recommend the following:
●cu ― cure infected files and system areas without deletion, moving or renaming infected files;
●icd ― delete incurable files;
●spm ― move suspicious files;
●spr ― rename suspicious files.
When Scanner is started with Cure action specified, it will try to restore the previous state of infected object. It is
possible only if detected virus is known virus, and cure instructions for it are available in virus database, though even in
this case cure attempt may fail if infected file is seriously damaged by virus.
If infected files are found inside archives they will not be cured, deleted, moved or renamed. To cure such files you must
manually unpack archives to the separate directory and instruct Scanner to check it.
When Scanner is started with action Delete specified, it will delete all infected files from disk. This option is suitable for
incurable (irreversibly damaged by virus) files.
Action Rename makes Scanner replace file extension with a certain specified extension (*.#?? by default, i.e. first
extension symbol is replaced with «#» symbol). Enable this parameter for files of other OS (e.g., DOS/Windows)
detected heuristically as suspicious. Renaming helps to avoid accidental startup of executable files in these OS and
therefore prevents infection by possible virus and its further expansion.
With action Move enabled Scanner will move infected or suspicious files to the quarantine directory
(%var_dir/infected/ by default). This parameter actually has a little value because infected and suspicious files
for other OS can not bring any damage to UNIX system. Moving of suspicious files for UNIX system itself can cause
system malfunction and failure.
Recommended Scanner command line for everyday use looks as follows:
$ drweb -path -cu -icd -spm -ar -ha -fl- -ml -sd
Such command line can be saved as a text file and converted into the simple shell script by the following command:
# chmod a+x [file name]
However, default parameters can be changed in Scanner configuration file, which is described in the next section.
7.2. Configuration
32
Scanner can be used with default settings, but it is much more convenient to set it up according your specific
requirements and situations. Scanner settings are stored in configuration file ( drweb32.ini by default) which is
located in %etc_dir directory. To use another configuration file specify full path to it with command line parameter,
e.g.:

Configuration
$ %bin_dir/drweb -ini=%bin_dir/etc/drweb.ini
Description of configuration file structure and parameter types can be found in p. 1.5 of this Manual. Parameters are
described in the order they are presented in main configuration file.
[Scanner] section.
EnginePath = {path to file, usual extension is *.dll}
Location of drweb32.dll module (Engine). This parameter is also used by update utility.
Default value:
EnginePath = %bin_dir/lib/drweb32.dll
VirusBase = {list of paths (masks) to files, usual extension is *.vdb}
Masks for loading virus databases. This parameter is also used by update utility. Multiple values are allowed.
Default value:
VirusBase = %var_dir/bases/*.vdb,%var_dir/bases/*.VDB
UpdatePath = {path to directory}
This parameter is used by update utility (update.pl) and is mandatory.
Default value:
UpdatePath = %var_dir/updates/
TempPath = {path to directory}
Directory for Engine to create temporary files. Usually it is not used, but sometimes appears to be necessary for
unpacking archives or when system is short of memory resources.
Default value:
TempPath = /tmp/
LngFileName = {path to the language file, usual extension is *.dwl}
Language file location.
Default value:
LngFileName = %bin_dir/lib/ru_scanner.dwl
Key = {path to license key file, usual extension is *.key}
Key file location (license or demo).
Default value:
Key = %bin_dir/drweb32.key
OutputMode = {Terminal | Quiet}
Information output mode at start: Terminal outputs to console, Quiet disables output.
Default value:
OutputMode = Terminal
HeuristicAnalysis = {Yes | No}
Enable/disable heuristic detection of unknown viruses. Enabling heuristic analysis allows detection of unknown viruses
using knowledge about specific architecture of viral code. Approximate nature of this type of virus detection makes us
talk about «suspicious», not «infected» objects. With this option disabled only known viruses will be detected by Dr.Web.
Some programs may trigger heuristic analyzer name files «suspicious» by mistake due to code similar to virus structure.
Besides, this mode may slightly increase time of virus scan. These considerations may lead you to disabling heuristic
analysis. At the same time, heuristic analysis improves reliability of antivirus protection. We recommend you to send all
33

Configuration
files detected by heuristic analyzer to developers using http://vms.drweb.com/sendvirus/ (preferably) or via e-mail
newvirus@drweb.com. Follow this procedure to upload files: make password protected archive, include password in
message body and attach Scanner report.
Default value:
ScanPriority = {value}
HeuristicAnalysis = Yes
Scanner process priority. Value must be within –20 (highest priority) to 20 (lowest priority) range.
Default value:
ScanPriority = 0
FilesTypes = {list of extensions}
File types to be checked «by type», i.e. when ScanFiles parameter (explained below) has ByType value. «*» and
«?» symbols are allowed. This parameter can be multi-string (specified lists are summed up).
Default value:
FilesTypes = EXE, COM, SYS, OV?, BAT, BIN, DRV, PRG, BOO, SCR, CMD,
VXD, 386, DLL, FON, DO?, XL?, WIZ, RTF, CL*, HT*, VB*, JS*, INF, AR?, ZIP, R??,
PP?, OBJ, LIB, HLP, MD?, INI, MBR, IMG, CSC, CPL, MBP, SHS, SHB, PIF, SO, CHM,
REG, XML, PRC, ASP, LSP, MSO, OBD, THE*, NWS, SWF, BMP, MPP, OCX, DVB, CPY, MSG,
EML
FilesTypesWarnings = {Yes | No}
Notify about files of unknown types.
Default value:
FilesTypesWarnings = Yes
ScanFiles = {All | ByType}
Additional restriction for files to be checked. With ByType value set, file extensions specified either by default or in
FilesTypes parameter (or parameters) are considered. Mode All is always enabled for files in mailboxes. ByType
value can be used only in local scan mode.
Default value:
ScanFiles = All
ScanSubDirectories = {Yes | No}
Enable/disable scanning subdirectories contents.
Default value:
ScanSubDirectories = Yes
CheckArchives = {Yes | No}
Enable/disable extracting files archived with ZIP (WinZip, InfoZIP, etc.), RAR, ARJ, TAR, GZIP, CAB and other archivers.
Default value:
CheckArchives = Yes
CheckEMailFiles = {Yes | No}
Enable/disable checking files in mailboxes.
Default value:
CheckEMailFiles = Yes
34

Configuration
ExcludePaths = {list of paths (masks) to be excluded from scan}
Masks for files which should not be checked.
Default value:
ExcludePaths = /proc,/sys,/dev
FollowLinks = {Yes | No}
Enable/disable following symbolic links.
Default value:
FollowLinks = No
RenameFilesTo = {rename mask}
Mask for renaming infected or suspicious files if action Rename is specified. For example, when rename mask looks like:
#?? - the first character of file extension will be replaced by «#» symbol, and all other subsequent characters will be
preserved. If file has no extension, it will consist only of «#» symbol.
Default value:
RenameFilesTo = #??
MoveFilesTo = {path to directory}
Path to quarantine directory.
Default value:
MoveFilesTo = %var_dir/infected/
EnableDeleteArchiveAction = {Yes | No}
Enable/disable action Delete for compound objects (archives, mailboxes, html pages) if they contain infected files.
Please note: with this option enabled the whole compound object will be deleted (archive, mailbox, etc.), not only
infected file or message. Use this option carefully!
Default value:
EnableDeleteArchiveAction = No
InfectedFiles = {Report | Cure | Delete | Move | Rename | Ignore}
Sets program reaction when file infected with known virus is detected. Allowable parameter values include:
●Report ― output information to log file;
●Cure ― try to cure an object (only for InfectedFiles parameter);
●Delete ― delete infected file;
●Move ― move file to directory specified by MoveFilesTo parameter;
●Rename ― rename file using mask specified by RenameFilesTo parameter;
●Ignore – skip the file.
Default value:
InfectedFiles = Report
Delete, Move and Rename actions, specified for archives, containers and mailboxes containing infected files, are
applied to the whole archive, container or mailbox!
Similar values are also used for the following parameters:
●SuspiciousFiles ― file is probably infected by unknown virus;
35
●IncurableFiles ― file is infected and incurable (used only if InfectedFiles = Cure);

Configuration
●ActionAdware — file contains program for displaying advertisements (adware);
●ActionDialers — file contains dialer program;
●ActionJokes — file contains joke program, which can frighten or irritate user;
●ActionRiskware — file contains dangerous program, which can be used not only by its legitimate user, but also
by the intruder;
●ActionHacktools — file contains hacking tool;
●ActionInfectedMail ― mailbox contains infected file;
●ActionInfectedArchive ― archive (ZIP, TAR, RAR, etc.) contains infected file;
●ActionInfectedContainer ― container (OLE, HTML, PowerPoint, etc.) contains infected file.
For all these parameters same values as for InfectedFiles parameter (except for Cure action) can be specified.
Default value for each parameter:
SuspiciousFiles = Report
IncurableFiles = Report
ActionAdware = Report
ActionDialers = Report
ActionJokes = Report
ActionRiskware = Report
ActionHacktools = Report
ActionInfectedMail = Report
ActionInfectedArchive = Report
ActionInfectedContainer = Report
LogFileName = {path to log file}
Log file name. You can specify syslog as log filename and logging will be carried out by syslogd system service. In
this case SyslogFacility and SyslogPriority parameters must be also specified. As syslogd uses several
files for logging various events of different importance, these two parameters and syslogd configuration file (usually /
etc/syslogd.conf) determine location where information is logged to.
Default value:
LogFileName = syslog
SyslogFacility = {Daemon | Local0 .. Local7 | Kern | User | Mail}
Log type when syslogd system service is used for activity logging (please refer to syslog documentation for further
details).
Default value:
SyslogFacility = Daemon
SyslogPriority = {Alert | Warning | Notice | Info | Error}
Log priority when syslogd system service is used.
Default value:
LimitLog = {Yes | No}
SyslogPriority = Info
36

Configuration
Enable/disable limit for log file size. When LogFileName = syslog, parameter value is ignored. When Scanner is
started it checks log file size and if it exceeds MaxLogSize parameter value, log file contents get cleared and log file is
started from scratch.
Default value:
LimitLog = No
MaxLogSize = {value in Kbytes}
Maximum log file size. Can be used with LimitLog = Yes only. Each time Scanner starts, size of the log file is
checked. If it is greater then MaxLogSize parameter value, log file will be overwritten. Set this parameter value to 0 if
you do not want log file to be unexpectedly modified at start up.
Default value:
MaxLogSize = 512
LogScanned = {Yes | No}
Enable/disable logging of information about all scanned objects, not only about infected and suspicious.
Default value:
LogScanned = Yes
LogPacked = {Yes | No}
Enable/disable logging of additional information about files packed with DIET, PKLITE and other utilities.
Default value:
LogPacked = Yes
LogArchived = {Yes | No}
Enable/disable logging of additional information about files archived with various archiving utilities.
Default value:
LogTime = {Yes | No}
LogArchived = Yes
Enable/disable logging of time for each record. Parameter is not used if LogFileName = syslog.
Default value:
LogTime = Yes
LogStatistics = {Yes | No}
Enable/disable logging of total scan statistics.
Default value:
LogStatistics = Yes
RecodeNonprintable = {Yes | No}
Nonprintable characters output mode for given terminal.
Default value:
RecodeNonprintable = Yes
RecodeMode = {Replace | QuotedPrintable}
Decoding mode for nonprintable characters if RecodeNonprintable = Yes. When RecodeMode = Replace
all nonprintable characters are substituted with RecodeChar parameter value (see below). When RecodeMode =
QuotedPrintable all nonprintable characters are converted to Quoted Printable format.
37

Configuration
Default value:
RecodeMode = QuotedPrintable
RecodeChar = {"?" | "_" | ...}
Symbol to replace nonprintable characters if RecodeMode = Replace.
Default value:
RecodeChar = "?"
The following parameters can be used to reduce archive scan time (some objects in archives will not be checked).
MaxCompressionRatio = {value}
Maximum compression ratio, i.e. ratio of unpacked file size to packed file size (inside archive). If the ratio exceeds
specified value, file will not be extracted and therefore will not be checked.
Default value:
MaxCompressionRatio = 5000
CompressionCheckThreshold = {value in Kbytes}
Minimum size of file inside archive beginning from which compression ratio check will be performed (if it is specified by
MaxCompressionRatio parameter value).
Default value:
CompressionCheckThreshold = 1024
MaxFileSizeToExtract = {value in Kbytes}
Maximum size of file extracted from archive. If file size inside archive exceeds specified value, it will be skipped.
Default value:
MaxFileSizeToExtract = 500000
MaxArchiveLevel = {value}
Maximum archive nesting level (archive in archive in archive, etc.). If archive nesting level exceeds specified value, it will
be skipped.
Default value:
MaxArchiveLevel = 8
7.3. Start
To start Dr.Web Scanner you can use the following command:
$ %bin_dir/drweb
If %bin_dir directory is added to PATH environment variable, you can run Dr.Web Scanner from any directory only by
typing «drweb». However, the last variant (as well as making a symbolic link to Dr.Web Scanner executable file in
directories like /bin/, /usr/bin/, etc.) is not recommended due to security reasons.
Dr.Web Scanner can be started both with Administrator and user privileges. In the last case virus check will be executed
only in directories, where user has read access, and infected files will be cured only in directories, where user has write
access (usually it is user home directory, $HOME). There also exist some other restrictions when Scanner is started with
user privileges, for example, with moving and renaming infected files.
After Scanner is started, it outputs the following information: program name, platform name, version number, release
date and contact information. Then it shows user registration information and statistics about loaded virus databases
including add-ons (if installed):
Dr.Web (R) Scanner for Linux, v5.0.0 (February 19, 2009)
38

Start
Copyright (c) Igor Daniloff, 1992-2009
Support service: http://support.drweb.com/
To purchase: http://buy.drweb.com/
Program version: 5.0.0.10060
Engine version: 5.0.0.9170
Loading /var/drweb/bases/drwtoday.vdb - Ok, virus records: 1533
Loading /var/drweb/bases/drw50012.vdb - Ok, virus records: 3511
--------------------------------------------
Loading /var/drweb/bases/drw50000.vdb - Ok, virus records: 1194
Loading /var/drweb/bases/dwn50001.vdb - Ok, virus records: 840
Loading /var/drweb/bases/drwebase.vdb - Ok, virus records: 78674
Loading /var/drweb/bases/drwrisky.vdb - Ok, virus records: 1271
Loading /var/drweb/bases/drwnasty.vdb - Ok, virus records: 4867
Total virus records: 538681
Key file: /opt/drweb/drweb32.key
Key file number: XXXXXXXXXX
Key file activation date: XXXX-XX-XX
Key file expiration date: XXXX-XX-XX
After this report shell invitation is returned.
All other Scanner actions (detection, cure, etc.) require additional command line parameters.
39

Antivirus Module Dr.Web Daemon
8. Antivirus Module Dr.Web Daemon
Dr.Web Daemon is a permanently loaded Dr.Web antivirus module, which can scan for viruses files on disk or data,
transferred through socket on request from other components. Requests are made using special protocol via UNIX
sockets or TCP sockets. Dr.Web Daemon uses the same antivirus engine and virus databases as Scanner and is able to
detect and cure all known viruses.
Dr.Web Daemon is always running and has clear and easy protocol for sending scanning requests, which makes it a
perfect solution to be used as antivirus filter for file servers. «Dr.Web for UNIX file servers» solution is a ready-made
solution for integrating Dr.Web Daemon with Samba file servers v.3.0 or later.
8.1. Command Line Parameters
Like any other UNIX program Dr.Web Daemon supports command line parameters. They are separated from specified
path by white space and are prefixed by hyphen «-». To get complete list of parameters, run Daemon with -?, -h or -
help parameters.
Dr.Web Daemon has the following command line parameters:
●-ini= ― use of alternative configuration file;
●-lng= ― use of alternative language file. If English interface has been chosen during
installation, specify ru_daemon.dwl to display program messages in Russian language;
●--foreground= - setting up Daemon operation mode at start. If «Yes» value is specified, Daemon
will work in foreground; with «No» value specified, Daemon will operate in daemon mode.
8.2. Configuration
Daemon can be used with default settings, but it is much more convenient to set it up according your specific
requirements and situations. Daemon settings are stored in configuration file ( drweb32.ini by default) which is
located in %etc_dir directory. To use another configuration file specify full path to it by the command line parameter at
start.
Description of configuration file structure and parameter types can be found in p. 1.5 of this Manual. Parameters are
described in the order they are presented in main configuration file.
[Daemon] section.
EnginePath = {path to file, usual extension is *.dll}
Location of drweb32.dll module (Engine). This parameter is also used by update utility.
Default value:
EnginePath = %bin_dir/lib/drweb32.dll
VirusBase = {list of paths (masks) to files, usual extension is *.vdb}
Masks for loading virus databases. This parameter is also used by update utility. Multiple values are allowed.
Default value:
VirusBase = %var_dir/bases/*.vdb,%var_dir/bases/*.VDB
UpdatePath = {path to directory}
This parameter is used by update utility (update.pl) and is mandatory.
Default value:
UpdatePath = %var_dir/updates/
TempPath = {path to directory}
40

Configuration
Directory for Engine to create temporary files. Usually it is not used, but sometimes appears to be necessary for
unpacking archives or when system is short of memory resources.
Default value:
TempPath = %var_dir/spool/
LngFileName = {path to language file, usual extension is *.dwl}
Language file location. If value of this parameter is not specified, all messages will be displayed in English.
Default value:
LngFileName =
Key = {path to file, usual extension is *.key}
Key file location (license or demo).
Default value:
Key = %bin_dir/drweb32.key
Please note, that Daemon and Scanner can have different license key files. In this case you must change the value of this
parameter correspondingly. Daemon can use several license key files simultaneously. For each of them Key parameter
value in [Daemon] section of drweb32.ini file must be specified. In this case Daemon tries to merge all license
permissions from all available license key files.
MailAddressesList = {path to file}
This parameter is used only if you have e-mail license for 15 or 30 addresses. Specified file must contain a list of e-mail
addresses (15 or 30 as specified by the license, one e-mail address per line), for which both incoming and outgoing
messages will be checked. Aliases are considered as separate addresses.
Default value:
MailAddressesList = %etc_dir/email.ini
OutputMode = {Terminal | Quiet}
Information output mode at start: Terminal outputs to console, Quiet disables output.
Default value:
OutputMode = Terminal
RunForeground = {Yes | No}
Disables/enables daemon mode for Dr.Web Daemon. With «Yes» value it can no longer act in the background without
controlling terminal. This option can be used by certain monitoring utilities (i.e., daemontools).
Default value:
User = {user name}
RunForeground = No
User account with appropriate privileges to be used by Daemon. It is strongly recommended to create a separate
«drweb» user account, which will be used by Daemon and filters. It is not recommended to run Daemon with root
privileges, although it may take less time to set it up. This parameter value cannot be changed when reloading
configuration using SIGHUP.
Default value:
User = drweb
UserID = {numeric ID}
GroupID = {numeric ID}
41

Configuration
Identifiers of user and group with appropriate privileges to be used by Daemon. These parameters are ignored, if User
parameter value is specified. Values of these parameters cannot be changed when reloading configuration using
SIGHUP.
Default value:
UserID =
GroupID =
PidFile = {path to file}
Specified file contains Daemon PID and UNIX socket (if Socket parameter enables usage of UNIX socket) or port
number (if Socket parameter enables usage of TCP socket). If more than one Socket parameter is specified, this file
will contain information on all the sockets (one per line). This file is created every time Daemon starts.
Default value:
PidFile = %var_dir/run/drwebd.pid
BusyFile = {path to file}
File where Daemon execution flag is stored. This file is created by a Daemon's child process upon a receipt of the
corresponding command and removed after successful execution of this command. Filenames created by each Daemon
child process are appended by a point and ASCIIZ representation of PID (e.g.,
/var/run/drwebd.bsy.123456).
Default value:
BusyFile = %var_dir/run/drwebd.bsy
MaxChildren = {numeric value}
Maximum amount of simultaneously working child processes. The main process does not perform a scan, so the
maximum number of Daemon processes will be equal to MaxChildren + 1. Recommended value range is from 4 to 16
processes per CPU.
Default value:
PreFork = {Yes | No
MaxChildren = 16
Child process creation mode. If parameter is set to «No», new scanning process is created for each query. If parameter
is set to «Yes», Daemon will create child scanning processes in advance in amount equal to MaxChildren value
(explained above) immediately after start. PreFork mode is very efficient, but it consumes more memory resources
(because all created scanning processes are memory-resident). Please note, that you must restart Daemon after
changing PreFork parameter value. This parameter value cannot be changed when reloading configuration using
SIGHUP.
Default value:
PreFork = Yes
MailCommand = {command}
Command used by Daemon and update utility for sending out notifications and information bulletins on new updates to
user (administrator) via e-mail. If less than two weeks left until the key file (or one of the key files) expires, Daemon
starts sending out notifications every time system starts, restarts or reboots.
Default value:
MailCommand = "/usr/sbin/sendmail -i -bm -f drweb – root"
NotifyPeriod = {numeric value}
42

Configuration
This parameter value specifies the length of a period (in days) before the license expiration date, from the beginning of
which Daemon starts sending out notifications of license renewal. When parameter value is set to 0 Daemon starts
sending out notifications immediately after the key file expires.
Default value:
NotifyPeriod = 14
NotifyFile = {path to file}
File with a timestamp of last notification of license renewal. It is send out to administrator after the key file expires.
Default value:
NotifyFile = %var_dir/.notify
NotifyType = {Ever | Everyday | Once}
Frequency of dispatch of notifications about license expiration. Once - notification is sent only once. Everyday -
notification is sent daily. Ever - notification is sent every time Daemon restarts or every time bases update.
Default value:
NotifyType = Ever
FileTimeout = {value in seconds}
Maximum time for Daemon to perform a scan of one file.
Default value:
FileTimeout = 30
StopOnFirstInfected = {Yes | No}
Enables/disables termination of the process of message scan after the detection of first virus. «Yes» value may
considerably reduce mail-server load and message scan time.
Default value:
ScanPriority = {value}
StopOnFirstInfected = No
Daemon process priority. Value must be within –20 (highest priority) to 20 (lowest priority) range.
Default value:
ScanPriority = 0
FilesTypes = {list of extensions}
File types to be checked «by type», i.e. when ScanFiles parameter (explained below) has ByType value. «*» and
«?» symbols are allowed. This parameter can be multi-string (specified lists are summed up).
Default value:
FilesTypes = EXE, COM, SYS, OV?, BAT, BIN, DRV, PRG, BOO, SCR, CMD,
VXD, 386, DLL, FON, DO?, XL?, WIZ, RTF, CL*, HT*, VB*, JS*, INF, AR?, ZIP, R??,
PP?, OBJ, LIB, HLP, MD?, INI, MBR, IMG, CSC, CPL, MBP, SHS, SHB, PIF, SO, CHM,
REG, XML, PRC, ASP, LSP, MSO, OBD, THE*, NWS, SWF, BMP, MPP, OCX, DVB, CPY, MSG,
EML
FilesTypesWarnings = {Yes | No}
Notify about files of unknown types.
Default value:
FilesTypesWarnings = Yes
43

Configuration
ScanFiles = {All | ByType}
44
Additional restriction for files to be checked. With ByType value set, file extensions specified either by default or in
FilesTypes parameter (or parameters) are considered. Mode All is always enabled for files in mailboxes. ByType
value can be used only in local scan mode.
Default value:
ScanFiles = All
CheckArchives = {Yes | No}
Enable/disable extracting files archived with ZIP (WinZip, InfoZIP, etc.), RAR, ARJ, TAR, GZIP, CAB and other archivers.
Default value:
CheckArchives = Yes
CheckEMailFiles = {Yes | No}
Enable/disable checking files in mailboxes.
Default value:
CheckEMailFiles = Yes
ExcludePaths = {list of paths (masks) to be excluded from scan}
Masks for files which should not be checked.
Default value:
ExcludePaths = /proc,/sys,/dev
FollowLinks = {Yes | No}
Enable/disable following symbolic links.
Default value:
FollowLinks = No
RenameFilesTo = {rename mask}
Mask for renaming infected or suspicious files if action Rename is specified. For example, when rename mask looks like:
#?? - the first character of file extension will be replaced by «#» symbol, and all other subsequent characters will be
preserved. If file has no extension, it will consist only of «#» symbol.
Default value:
RenameFilesTo = #??
MoveFilesTo = {path to directory}
Path to quarantine directory.
Default value:
MoveFilesTo = %var_dir/infected/
BackupFilesTo = {path to directory}
Directory for backup copies of infected files if requested action was Cure.
Default value:
BackupFilesTo = %var_dir/infected/
LogFileName = {path to log file}
Log file name. You can specify syslog as log filename and logging will be carried out by syslogd system service. In
this case SyslogFacility and SyslogPriority parameters must be also specified. As syslogd uses several

Configuration
files for logging various events of different importance, these two parameters and syslogd configuration file (usually /
etc/syslogd.conf) determine location where information is logged to.
Default value:
LogFileName = syslog
SyslogFacility = {Daemon | Local0 .. Local7 | Kern | User | Mail}
Log type when syslogd system service is used for activity logging (please refer to syslog documentation for further
details).
Default value:
SyslogFacility = Daemon
SyslogPriority = {Alert | Warning | Notice | Info | Error}
Log priority when syslogd system service is used.
Default value:
LimitLog = {Yes | No}
SyslogPriority = Info
Enable/disable limit for log file size. When LogFileName = syslog, parameter value is ignored. When Daemon is
started it checks log file size and if it exceeds MaxLogSize parameter value, log file contents get cleared and log file is
started from scratch.
Default value:
LimitLog = No
MaxLogSize = {value in Kbytes}
Maximum log file size. Can be used with LimitLog = Yes only. Each time Daemon starts, size of the log file is
checked. If it is greater then MaxLogSize parameter value, log file will be overwritten. The same thing happens when
Daemon receives SIGHUP signal. Set this parameter value to 0 if you do not want log file to be unexpectedly modified
at start up.
Default value:
MaxLogSize = 512
LogScanned = {Yes | No}
Enable/disable logging of information about all scanned objects, not only about infected and suspicious.
Default value:
LogScanned = Yes
LogPacked = {Yes | No}
Enable/disable logging of additional information about files packed with DIET, PKLITE and other utilities.
Default value:
LogPacked = Yes
LogArchived = {Yes | No}
Enable/disable logging of additional information about files archived with various archiving utilities.
Default value:
LogTime = {Yes | No}
LogArchived = Yes
45

Configuration
Enable/disable logging of time for each record. Parameter is not used if LogFileName = syslog.
46
Default value:
LogTime = Yes
LogProcessInfo = {Yes | No}
Enable/disable logging of every scanning process PID and filter address (host name or IP) from which scanning has been
activated. This data is placed before each record.
Default value:
LogProcessInfo = Yes
RecodeNonprintable = {Yes | No}
Nonprintable characters output mode for given terminal.
Default value:
RecodeNonprintable = Yes
RecodeMode = {Replace | QuotedPrintable}
Decoding mode for nonprintable characters if RecodeNonprintable = Yes. When RecodeMode = Replace
all nonprintable characters are substituted with RecodeChar parameter value (see below). When RecodeMode =
QuotedPrintable all nonprintable characters are converted to Quoted Printable format.
Default value:
RecodeMode = QuotedPrintable
RecodeChar = {"?" | "_" | ...}
Symbol to replace nonprintable characters if RecodeMode = Replace.
Default value:
RecodeChar = "?"
Socket = {PORT [interfaces] | FILE [access]}
Description of a socket used for communication with Daemon. The first string describes TCP socket. PORT value is for
decimal port number, interfaces value is for the list of interface names or IP-addresses for incoming requests.
Example:
Socket = 3000 127.0.0.1, 192.168.0.100
The second string describes UNIX sockets. FILE value is for socket name, access is for access permissions definition
in octal form.
Example:
Socket = %var_dir/.drwebd 0660
Number of Socket parameters is not limited. Daemon will work with all correctly described sockets. To enable receipt of
requests vial all available interfaces set 3000 0.0.0.0 as a value of this parameter.
Default value:
Socket = %var_dir/run/.daemon
SocketTimeout = {value in seconds}
Maximum time for data transfer via socket (file scanning time is not included).
Default value:
SocketTimeout = 10

Configuration
ListeningQueue = {value}
47
Maximum queue size for sockets. Value may vary from 0 to SOMAXCONN constant (its value depends on the OS).
Default value:
ListeningQueue = 128
The following parameters can be used to reduce archive scan time (some objects in archives will not be checked). If
object falls under restrictions set by these parameters, ArchiveRestriction procedure is applied.
ArchiveRestriction parameter value is specified in configuration files of various filters.
MaxCompressionRatio = {value}
Maximum compression ratio, i.e. ratio of unpacked file size to packed file size (inside archive). If the ratio exceeds
specified value, file will not be extracted and therefore will not be checked.
Default value:
MaxCompressionRatio = 500
CompressionCheckThreshold = {value in Kbytes}
Minimum size of the file inside archive, beginning from which maximum compression ratio check will be performed (if it is
specified by MaxCompressionRatio parameter value).
Default value:
CompressionCheckThreshold = 1024
MaxFileSizeToExtract = {value in Kbytes}
Maximum file size to extract file from archive. If file size inside archive exceeds specified value, it will be skipped.
Default value:
MaxFileSizeToExtract = 40960
MaxArchiveLevel = {value}
Maximum archive nesting level (archive in archive in archive, etc.). If archive nesting level exceeds specified value, file
will be skipped.
Default value:
MaxArchiveLevel = 8
As it was stated above, Dr.Web Daemon has built-in e-mail filtering capabilities based on the message header analysis.
Filtering rules are specified in configuration file. Compliance check is performed sequentially, until the first matching rule
is found. Then the corresponding rule is applied. None of the filtering rules specified are applied automatically. To enable
the header analysis you must specify appropriate parameters in built-in filters. If you work with custom solutions based
on Dr.Web Daemon you must set up special flags.
Compliance with any of the Reject* rules cancels further message scanning.
Compliance with any of the Accept* rules enables anti-virus check.
ScanEncodedHeaders = {Yes | No}
Enables/disables message header processing before decoding. For example, «Yes» value combined with
RejectCondition Subject = "iso-8859-5" allows to filter out all messages with Subject field in iso-
8859-5 encoding. Please note, that with «Yes» value all encoded headers will be scanned twice: before and after
decoding.
Default value:
ScanEncodedHeaders = No
RejectCondition {set of rules}

Configuration
AcceptCondition {set of rules}
Description of filtering rules for message headers. Each rule contains header name and regular expression describing
value of this field. Several rules can be combined by round brackets and logical operators OR and AND.
Example:
RejectCondition Subject = "money" AND "Content-Type" = "text/html"
Also it is possible to use «!=» (not equal) operator.
Filtering rules may also include some special conditions. No "HEADER" condition allows filtering out messages, where
specified header fields are absent. HEADER = "8bit" allows filtering out messages with header fields containing 8-bit
symbols.
MissingHeader {fields list}
List of essential headers. Messages without specified headers will be filtered out. For example, MissingHeader
"To", "From".
FilterParts = {Yes | No}
Enables/disables applying rules, set by RejectPartCondition and AcceptPartCondition parameters.
Default value:
FilterParts =
RejectPartCondition {set of rules}
AcceptPartCondition {set of rules}
Set of filtering rules for message headers. These parameters are similar to RejectCondition and
AcceptCondition, but are applied only to particular message parts. Set of rules can be defined as FileName =
{mask}, where «mask» is a POSIX 1003.2 compatible regular expression. Filtering by these rules is enabled only
when FilterParts parameter is set to «Yes» (explained above).
8.3. Start
When Daemon is started (with default settings) the following actions are performed:
●configuration file is located and loaded. If configuration file is not found loading process terminates. Path to
configuration file can be specified at startup, by the command line parameter -ini:
{path/to/your/drweb32.ini}, or default value (%etc_dir/drweb32.ini) can be used. At start
several parameters get validated, and if parameter value is not allowable default value is applied;
●language file is loaded from the location specified in configuration file. If language file is not found, all messages are
displayed in English;
●log file is created. User account used by Daemon must have appropriate privileges to write to the directory where
log file is situated. Please note, that users have no write access to the default /var/log/ directory. If User
parameter is specified, you must also redefine LogFileName parameter and provide alternative location;
●key file is loaded from the location specified in configuration file. If the key file is not found, loading process
terminates;
●if User parameter (or UserID and GroupID) parameter is specified, Daemon will offer to create an appropriate
user account (default value: «drweb») and to use it with the permissions provided;
●Engine (drweb32.dll) is loaded. If Engine is damaged or not found (because of some errors in configuration
file), loading process terminates;
●virus databases are loaded in arbitrary sequence from the location specified in configuration file. If virus databases
are damaged or absent, loading process proceeds;
48

Start
●Daemon enters daemon mode, so all information about loading problems can not be output to console and is
written to log file;
●socket for interaction between Daemon and other «Dr.Web for UNIX file servers» solution modules is created. When
TCP-sockets are used, there can be several connections (loading continues if at least one connection is
established). When UNIX socket is used, Daemon's user account must have appropriate privileges to read from
the directory containing this socket and write to it. User accounts for modules must have execution access to the
directory itself and write and read access to the socket file. Please note, that users have no write or execution
access to the default /var/run/ directory. If User parameter is specified, you must also redefine Socket
parameter and provide alternative location. If socket can not be created, Daemon loading stops;
●pid-file with Daemon PID information and transport addresses is created. User account used by Daemon must have
appropriate privileges to write to the directory containing pid-file. Please note, that users have no write access to
the default /var/run/ directory. If User parameter is specified, you must also redefine PidFile parameter
and provide alternative location. If pid-file is not created, loading process terminates.
8.4. Signal Processing
Dr.Web Daemon can also receive and process the following signals:
●SIGHUP ― reload of configuration file;
●SIGTERM ― correct termination of Daemon process;
●SIGKILL ― forced termination of Daemon process (if any problems have emerged).
8.5. Verifying Availability of Dr.Web Daemon
49
If no evident problems have occurred during load, Daemon is ready to work. To make sure Daemon was loaded correctly,
run:
$ netstat -a
to check whether all necessary sockets were created.
If TCP sockets are used:
--- cut ---
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:3000 *:* LISTEN
raw 0 0 *:icmp *:* 7
raw 0 0 *:tcp *:* 7
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 0 [ ACC ] STREAM LISTENING 384 /dev/gpmctl
unix 0 [ ] STREAM CONNECTED 190 @0000001b
unix 1 [ ] STREAM CONNECTED 1091 @00000031
unix 0 [ ACC ] STREAM LISTENING 403 /tmp/.font-unix/fs7100
unix 4 [ ] DGRAM 293 /dev/log
unix 1 [ ] STREAM CONNECTED 1092 /dev/gpmctl
unix 0 [ ] DGRAM 450
unix 0 [ ] DGRAM 433

Verifying Availability of Dr.Web Daemon
unix 0 [ ] DGRAM 416
50
unix 0 [ ] DGRAM 308
--- cut ---
If UNIX sockets are used:
--- cut ---
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
raw 0 0 *:icmp *:* 7
raw 0 0 *:tcp *:* 7
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 0 [ ACC ] STREAM LISTENING 384 /dev/gpmctl
unix 0 [ ] STREAM CONNECTED 190 @0000001b
unix 1 [ ] STREAM CONNECTED 1091 @00000031
unix 0 [ ACC ] STREAM LISTENING 1127 /opt/drweb/run/drwebd.skt
unix 0 [ ACC ] STREAM LISTENING 403 /tmp/.font-unix/fs7100
unix 4 [ ] DGRAM 293 /dev/log
unix 1 [ ] STREAM CONNECTED 1092 /dev/gpmctl
unix 0 [ ] DGRAM 450
unix 0 [ ] DGRAM 433
unix 0 [ ] DGRAM 416
unix 0 [ ] DGRAM 308
--- cut ---
If output to console differs from the result given above and any of the sockets from the list is missing, some errors during
load have occurred.
To run functional test and obtain service information use console client for Daemon (drwebdc).
If TCP sockets are used:
$ drwebdc -nHOSTNAME -pPORTNUM -sv -sb
If UNIX socket is used:
$ drwebdc -uSOCKETFILE -sv -sb
Client's output to console must contain all the parameters supported. The following information should appear:
--- cut ---
- Version: DrWeb Daemon 5.00
- Loaded bases:
Base /var/drweb/bases/drwtoday.vdb contains 5 records.
Base /var/drweb/bases/drw50003.vdb contains 409 records.
Base /var/drweb/bases/drw50002.vdb contains 543 records.
Base /var/drweb/bases/drwebase.vdb contains 51982 records.

Verifying Availability of Dr.Web Daemon
Base /var/drweb/bases/drw50001.vdb contains 364 records.
51
Total 53303 virus-finding records.
--- cut ---
If output to console differs from the result given above, try to run drwebdc in enhanced diagnostic mode.
If TCP sockets are used:
$ drwebdc -nHOSTNAME -pPORTNUM -sv -sb -v
If UNIX socket is used:
$ drwebdc -uSOCKETFILE -sv -sb -v
More detailed output may clarify the situation:
--- cut ---
dwlib: fd: connect() failed - Connection refused
dwlib: tcp: connecting to 127.0.0.1:3300 - failed
dwlib: cannot create connection with a DrWeb daemon
ERROR: cannot retrieve daemon version
Error -12
--- cut ---
Open readme.eicar.rus test file from distribution package and follow instructions to make eicar.com program
in text editor. Then try to scan it with Daemon.
If you have license for mail servers with 50 and more addresses:
For TCP sockets:
For UNIX socket:
$ drwebdc -nHOSTNAME -pPORTNUM -e -f eicar.com
$ drwebdc -uSOCKETFILE -e -f eicar.com
If you have license for mail servers with 15 or 30 addresses:
For TCP sockets:
$ drwebdc -nHOSTNAME -pPORTNUM -e -FEMAIL_ADDRESS -REMAIL_ADDRESS -f
eicar.com
For UNIX socket:
$ drwebdc -uSOCKETFILE -e -FEMAIL_ADDRESS -REMAIL_ADDRESS -f eicar.com
where EMAIL_ADDRESS is one of addresses from email.ini.
If you have license for file servers or file-servers:
For TCP sockets:
For UNIX socket:
$ drwebdc -nHOSTNAME -pPORTNUM -f eicar.com
$ drwebdc -uSOCKETFILE -f eicar.com
Output to console must contain the following information:
--- cut ---
Results: daemon return code 0x20

Verifying Availability of Dr.Web Daemon
(known virus is found)
--- cut ---
If diagnostics failed and no output appeared, check Daemon’s log file for the record on the event. If there is no record,
try to run drwebdc in enhanced diagnostic mode. If you receive the same output that is given above, Daemon is ready
to work.
8.6. Scanning Modes
Dr.Web Daemon has two major scanning modes:
●scanning chunks of data received from socket;
●scanning files on disk (local scan).
In the first mode Daemon receives from socket chunks of data for scan. They can be named or anonymous (this will
affect only the way records are made in Daemon’s log file). Daemon can perform scan of any chunk of data received from
socket, even a file. For example, in the previous section of this Manual console client for Daemon reads the file specified
and sent it to Daemon for scan. Operation in this mode can be enabled by specifying No as a value of LocalScan
parameter in smb-spider.conf configuration file.
In the second mode Daemon performs scan of the selected file on disk. Two major advantages of local scan mode are
increased productivity and simplicity. Local scan mode is much more efficient. Console client or mail filter sends Daemon
only a path to file, not the whole file. Since clients can be located on different computers, the path must be specified with
regard to the actual location of Daemon. Besides that, usage of this mode simplifies creation and deployment of reliable
solutions for content scan and curing of infected files (e.g. on file servers). Operation in this mode can be enabled by
specifying Yes as a value of LocalScan parameter in smb-spider.conf configuration file.
Please note, that local scan mode requires more accurate adjustment of user privileges. Daemon must have read access
to each file specified. If you run Daemon on mail server with Cure and Delete options enabled, you must allow write
access either.
Usage of Daemon with mail servers requires special attention because mail filters usually act on behalf of the mail system
and use its privileges. In local scan mode mail filter usually creates a file with the message received from the mail system
and provides Daemon a path to it. At this point you must carefully specify access permissions to the directory where
filters create appropriate files. We recommend either to include user whose privileges are used by Daemon into the mail
subsystem group, or to run Daemon with the privileges of the mail system user.
Properly adjusted system doesn't require Daemon to use root privileges.
52

Integrating Daemon with Samba File Server
9. Integrating Daemon with Samba File Server
9.1. Requirements
●Installed Dr.Web Daemon v.4.44 or higher;
●Dr.Web Samba SpIDer plug-in module;
●Samba v.3.0.x to v.3.4.x.
9.2. Plug-in of Dr.Web Samba SpIDer Module
Add the following section to Samba configuration file (/etc/samba/smb.conf by default):
--- cut ---
[drweb_audit]
comment = Dr.Web protected directory
path = /directory/to/protect/
vfs objects = smb_spider
writeable = yes
browseable = yes
guest ok = yes
public = yes
--- cut ---
You must restart Samba file server after editing the configuration file.
9.3. Start
Dr.Web Samba SpIDer monitor is activated, when the first client opens a shared resource at the server. After its
initialization the following actions are performed:
●versions of Dr.Web Samba SpIDer interface and Samba server are checked;
●Dr.Web Samba SpIDer reads the configuration file (%etc_dir/smb_spider.conf by default);
●Dr.Web Samba SpIDerr starts monitoring clients file operations.
At the first and second stages Dr.Web Samba SpIDer outputs information to the system log (syslog). By default the
following values are specified for parameters, controlling operation of syslogd system utility:
SyslogFacility = Daemon
SyslogPriority = Info
The recommended starting order is the following:
●Dr.Web Daemon;
●Dr.Web Samba VFS SpIDer.
Please note, that If Daemon is started with the privileges not sufficient to read from (for anti-virus check) and write to
(for deletion, cure, etc.) files on a shared resource, it will operate in non-local scan mode by default and receive all
necessary files via socket. In this mode total system performance will be considerably reduced.
If you want to assure best performance, please pay special attention to providing Daemon with all the privileges
necessary to access shared resources.
53

Configuration
9.4. Configuration
54
Dr.Web Samba VFS SpIDer can be used with default settings, but it is much more convenient to set it up according your
specific requirements and situations. Dr.Web Samba VFS SpIDer settings are stored in configuration file (smbspider.conf
by default) which is located in %etc_dir directory. To use another configuration file specify full path
to it in the smb.conf configuration file by adding the following string:
smb_spider: config = /my/new/path/smb_spider.conf
Description of configuration file structure and parameter types can be found in p. 1.5 of this Manual. Parameters are
described in the order they are presented in main configuration file.
Address = {FAMILY : ADDRESS}
List of socket addresses of Dr.Web Daemon. Addresses in the list are delimited by comma and specified in
FAMILY:ADDRESS format.
FAMILY part can have one of the following values:
●inet — TCP sockets are used, ADDRESS is PORT@HOST;
●local — UNIX socket is used, ADDRESS is SOCKETFILE;
●pid — real address of Daemon process from its pid-file is used, ADDRESS is PIDFILE.
Default value:
Cache = {Yes | No}
Address = pid:%var_dir/run/drwebd.pid
Allows caching of the resolved IP address of Daemon's host. Otherwise its IP address will be requested each time the
necessity to scan a file emerges. This parameter is used only if Daemon uses TCP sockets for communication.
Default value:
Cache = Yes
Timeout = {value in seconds}
Timeout for the one scanning session. When parameter value is set to 0, maximum time for scan of one file is not limited.
Default value:
Timeout = 120
UseTcpNodelay = {Yes | No}
TCP_NODELAY parameter can be used to set up operation of TCP socket if there are any problems with the network.
Please, do not change the default value, if your connection to the network is stable, and the network itself operates fine.
Default value:
UseTcpNodelay = No
HeuristicAnalysis = {Off | On}
Enable/disable heuristic detection of unknown viruses. Enabling heuristic analysis allows detection of unknown viruses
using knowledge about specific architecture of viral code. Approximate nature of this type of virus detection makes us
talk about «suspicious», not «infected» objects. With this option disabled only known viruses will be detected by Dr.Web.
Some programs may trigger heuristic analyzer name files «suspicious» by mistake due to code similar to virus structure.
Besides, this mode may slightly increase time of virus scan. These considerations may lead you to disabling heuristic
analysis. At the same time, heuristic analysis improves reliability of antivirus protection. We recommend you to send all
files detected by heuristic analyzer to developers using http://vms.drweb.com/sendvirus/ (preferably) or via e-mail
newvirus@drweb.com. Follow this procedure to upload files: make password protected archive, include password in
message body and attach Scanner report.
Default value:

Configuration
HeuristicAnalysis = On
StripPath = {numeric value}
Allows to remove the certain amount of segments from the beginning of specified scan path. When value of this
parameter is set to 0, path stays unmodified. When value is set to 1, the first segment is removed, including slash («/»)
symbol. When value is set to 2, two segments are removed from the beginning of the path, including corresponding slash
(«/») symbol.
Example:
If we have /some/path/to/file.ext specified as a scan path, then:
●when StripPath = 1, the path will look like the following:
path = some/path/to/file.ext
●when StripPath = 2, the path will look like the following:
Default value:
path = path/to/file.ext.
StripPath = 0
PrefixPath = {path to file}
Specifies path segment to be added to the beginning of scan path after its processing by StripPath parameter. Please
note, that value of this parameter must not be ended with slash («/») symbol. Required slash will be inserted to the new
scan path automatically.
Example:
If we have /some/path/to/file.ext specified as a scan path, and after processing by StripPath parameter
with 2 set as a value it looks like the following:
path = path/to/file.ext
then after automatic insertion of slash symbol and processing by PrefixPath = /just/another, it will look like
the following:
path = /just/another/path/to/file.ext
Default value:
PrefixPath =
MaxFileSizeToScan = {value in Kbytes}
Maximum size of file for scan. When parameter value is set to 0, maximum file size is not limited.
Default value:
MaxFileSizeToScan = 0
ScanMode = {onWrite | onRead | onAccess}
This parameter can have one of the following values:
●onAccess — files will be scanned on each attempt to open or run them and also on closing after creation or
modification.
●onRead — files will be scanned on each attempt to open or run them, only. This mode allows to increase operation
speed, but decreases antivirus protection level (infected file can be copied to the shared directory and executed by
the user, who has local access to shared resource, not via Samba-server).
●onWrite — files will be scanned on closing after creation or modification, only. This mode allows to increase
Default value:
operation speed, but decreases antivirus protection level (infected file can be copied to the shared directory and
executed by the user, who has local access to shared resource, not via Samba-server).
ScanMode = onAccess
55

Configuration
RewriteDataBase = {Yes | No}
56
When parameter value is set to Yes, cache for md5 hashes of infected and clean files is created from scratch each time
new user accesses shared directory. All data cached during previous session is overwritten.
Default value:
RewriteDataBase = Yes
BlockedCacheSize = {size in bytes}
Size of cache to store md5 hashes of scanned infected (and therefore blocked) files. When parameter value is set to 0,
md5 hashes are not cached. This parameter allows to increase operation speed, because if md5 hash of requested file is
the same as cached md5 hash, file is considered infected and is not sent to Daemon for repeated scan.
Default value:
BlockedCacheSize = 4096
AllowedCacheSize = {size in bytes}
Size of cache to store md5 hashes of scanned clean files. When parameter value is set to 0, md5 hashes are not cached.
This parameter allows to increase operation speed, because if md5 hash of requested file is the same as cached md5
hash, file is considered clean and is not sent to Daemon for repeated scan.
Default value:
LocalScan = {Yes | No}
AllowedCacheSize = 4096
Allows to use local scan mode, when Daemon receives not the whole file, but only the path of it. With LocalScan =
Yes Daemon will operate in local scan mode.
Default value:
LocalScan = Yes
In non-local scan mode or when Daemon does not have sufficient permissions to access certain file, Dr.Web Samba VFS
SpIDer can perform actions with files independently.
LicenseLimit = {reject | pass}
Action to be applied to files which have not been scanned due to license expiration. Possible values are: pass — allow
access to file, reject — block access to file.
Default value:
LicenseLimit = reject
Infected = {reject | quarantine | discard | rename | cure}
Action to be applied to files, infected with known virus. Possible values are: cure — try to cure infected file, rename —
rename file and block access to it, discard — delete file, quarantine — move file to quarantine and block access to
it, reject — block access to file. Rename mask looks like: #?? - the first character of file extension is replaced by «#»
symbol, and all other subsequent characters are preserved. If file has no extension, it will consist only of «#» symbol.
Default value:
Infected = quarantine
Suspicious = {reject | quarantine | discard | rename | pass}
Action to be applied to suspicious files (possibly infected with unknown virus). Possible values are: pass — allow access
to file, rename — rename file and block access to it, discard — delete file, quarantine — move file to quarantine
and block access to it, reject — block access to file.
Default value:

Configuration
Suspicious = quarantine
Incurable = {reject | quarantine | discard | rename}
Action to files that cannot be cured. Possible values are: rename — rename file and block access to it, discard —
delete file, quarantine — move file to quarantine and block access to it, reject — block access to file.
Default value:
Incurable = quarantine
Adware = {reject | quarantine | discard | rename | pass}
Action to be applied to adware. Possible values are: pass — allow access to file, rename — rename file and block
access to it, discard — delete file, quarantine — move file to quarantine and block access to it, reject — block
access to file.
Default value:
Adware = quarantine
Dialers = {reject | quarantine | discard | rename | pass}
Action to be applied to dialer programs. Possible values are: pass — allow access to file, rename — rename file and
block access to it, discard — delete file, quarantine — move file to quarantine and block access to it, reject —
block access to file.
Default value:
Dialers = quarantine
Jokes = {reject | quarantine | discard | rename | pass}
Action to be applied to joke programs, which can scare or annoy user. Possible values are: pass — allow access to file,
rename — rename file and block access to it, discard — delete file, quarantine — move file to quarantine and
block access to it, reject — block access to file.
Default value:
Jokes = quarantine
Riskware = {reject | quarantine | discard | rename | pass}
Action to be applied to riskware. Possible values are: pass — allow access to file, rename — rename file and block
access to it, discard — delete file, quarantine — move file to quarantine and block access to it, reject — block
access to file.
Default value:
Riskware = quarantine
Hacktools = {reject | quarantine | discard | rename | pass}
Action to be applied to programs used to gain unauthorized access to computer systems. Possible values are: pass —
allow access to file, rename — rename file and block access to it, discard — delete file, quarantine — move file
to quarantine and block access to it, reject — block access to file.
Default value:
Hacktools = quarantine
Archives = {reject | quarantine | discard | rename}
Action to be applied to archives containing infected files. To enable deletion of such archives set
EnableDeleteArchiveAction = Yes in main configuration file drweb32.ini. Possible values are: rename
— rename archive and block access to it, discard — delete archive, quarantine — move archive to quarantine and
block access to it, reject — block access to archive.
57

Configuration
Default value:
Archives = quarantine
SkipObject = {reject | pass}
Action to be applied to files, which cannot be scanned by Daemon (password protected or broken archives, symbolic links
or non regular files). Possible values are: pass — allow access to file, reject — block access to file.
Default value:
SkipObject = pass
ArchiveRestriction = {reject | pass}
Action to be applied to archives, which cannot be scanned by Daemon due to the excess of limits set for archives in main
configuration file drweb32.ini. Possible values are: pass — allow access to file, reject — block access to file.
Default value:
ArchiveRestriction = pass
ScanningErrors = {reject | pass}
Action to be applied to files causing Daemon errors during scan (e.g. Daemon has run short of memory or does not have
proper privileges for further processing). Possible values are: pass — allow access to file, reject — block access to
file.
Default value:
ScanningErrors = reject
ProcessingErrors = {reject | pass}
Action to be applied to files causing Samba SpIDer errors during scan (e.g. Samba VFS SpIDer was not configured
properly or cannot connect to Daemon). Possible values are: pass — allow access to file, reject — block access to
file.
Default value:
ProcessingErrors = reject
SendNotifyToUser = {Off | On}
Allows to notify users about detection of a virus in a file. Windows Messenger (WinPopup) is used for sending
notifications in Windows systems. LinPopup (for Linux) is used for sending notifications in UNIX systems. UNIX users
must have properly configured message receiving utility to receive these notifications.
Default value:
SendNotifyToUser = off
SendNotifyToAdmin = {Off | On}
Allows to notify Administrator about events emerging during scan (e.g. detection of a virus). Windows Messenger
(WinPopup) is used for sending notifications in Windows systems. LinPopup (for Linux) is used for sending notifications in
UNIX systems. For UNIX systems it is also possible to send notifications via e-mail. To enable this option add the
following line to smb.conf configuration file:
message command = /usr/bin/mail -s 'Messages from %f on %m' {address} < %s ; rm
%s
where {address} is e-mail address of the Administrator.
Default value:
SendNotifyToAdmin = off
AdminAddress = {Address}
58

Configuration
IP address of Administrator's computer.
Default value:
AdminAddress = "127.0.0.1"
ShellScriptForBlockedFile = {path to file}
Path to shell script to be initialized upon blocking of the file. Dr.Web Samba VFS SpIDer passes to script the following
parameters: FileName — name of the infected file; UserName — login name of the user, who have tried to open
infected file; UserHost — name of the host from which user have tried to open infected file; DaemonReport —
report from the Daemon. Example of such script can be found in %bin_dir/doc/samba/ directory (file
smb_script.sh).
Default value:
ShellScriptForBlockedFile =
Quarantine = {path to directory}
Path to quarantine directory.
Default value:
Quarantine = %var_dir/infected/
QuarantineFilesMode = {access permissions}
Access permissions to files in quarantine.
Default value:
QuarantineFilesMode = 0660
Level = {Debug | Verbose | Info | Alerts | Errors | Quiet}
Log verbosity level.
Default value:
Level = Info
SyslogFacility = {Local7 | ... | Local0 | Daemon | Mail}
Log type when syslogd system service is used for activity logging (please refer to syslog documentation for further
details).
Default value:
SyslogFacility = Daemon
SyslogPriority = {Alert | Notice | Info | Debug}
Priority of record when using syslogd system service.
Default value:
SyslogPriority = Info
Dr.Web Samba VFS SpIDer can also receive configuration information from Dr.Web Agent module. To enable this option
insert the following line to smb.conf configuration file:
smb_spider: config = %var_dir/ipc/.agent
9.5. Interaction with Distributed File System (MS DFS)
59
Distributed File System allows administrators to organize shared folders located on different servers into the integrated
structure with its own hierarchy design and directory names – so that the user will consider it a separate resource and be
able to navigate it without needing to know the server names or shared folders hosting the data.

Interaction with Distributed File System (MS DFS)
Dr.Web Samba VFS SpIDer can work with Samba-based MS DFS only if installed on backend servers. If Dr.Web Samba
VFS SpIDer is installed on frontend server, it will be able to check only those files, which are written exactly to this server
(or read directly from it).
60

«Dr.Web console for UNIX file servers»
10. «Dr.Web console for UNIX file servers»
Setup and configuration of «Dr.Web for UNIX file servers» can be performed via separate web interface «Dr.Web console
for UNIX file servers». It is implemented as a plug-in to Webmin (detailed information about Webmin interface is available
on its official website at http://www.webmin.com/).
To achieve optimal performance of «Dr.Web console for UNIX file servers» web interface, please, make sure that the
following Perl modules are installed to your system:
●XML::Parser — Perl module for parsing XML documents;
●XML::XPath — set of modules for parsing and evaluating XPath statements;
●CGI — Perl module enabling operation with Common Gateway Interface;
●Text::Iconv — Perl interface to iconv() codeset conversion function;
●perl-devel (or libperl-dev, depending on the UNIX distribution) — a package to build Text::Iconv;
●JSON — Perl module for parsing and converting to JSON (JavaScript Object Notation).
If some modules are missing, it is recommended to install them from console. Names of the modules may vary, but
usually they are included into the following packages: perl-Convert-BinHex, perl-IO-stringy, perl-
XML-Parser, perl-XML-XPath. For installation in rpm-systems it is recommended to choose noarch.rpm
packages.
Web interface layout and appearance may differ depending on Webmin version and browser used. All screenshots
provided in this document were made with Webmin 1.450 and Firefox 3.0.7 (Mozilla/5.0 (Windows; U; Windows NT 5.1;
ru; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7) using default settings.
10.1. Installation
To start working with «Dr.Web console for UNIX file servers», do the following:
●set up Webmin;
●download installation packages with Webmin modules from the Dr.Web website at http://download.drweb.com/:
drweb-lib-web-5.0.0.tar.bz2 with common libraries and drweb-samba-web-5.0.0.tar.bz2
with the web interface of «Dr.Web console for UNIX file servers»;
●plug in both modules to Webmin.
Webmin modules can be plugged in and their additional parameters can be set up via Webmin's web interface.
Figure 12. Main page of Webmin web interface
61

Installation
Installation of the new modules can be performed on «Webmin Configuration» page of the «Webmin» section
of main menu, in «Webmin Modules» subsection.
Figure 13. «Webmin Configuration» page
To install necessary modules, click the «Browse» button near the «From local file» text field on the «Webmin
Modules» page. A separate browser window will be opened to provide navigation through folders and files. Choose
the corresponding installation package from the list.
Figure 14. «Webmin modules» subsection
62

Installation
One click on any item from the list selects it to the field below. With the second click on previously selected folder, it
opens. With the second click on previously selected file, navigation window closes, and full path to selected file appears
in «From local file» text field. You may also click «OK» button when you are finished with selection of required
file.
After finishing with selection of the installation package file, click the «Install Module» button. Please note, that
common libraries (from drweb-lib-web-5.0.0.tar.bz2 package) must be installed before the «Dr.Web console
for UNIX file servers» web interface (from drweb-samba-web-5.0.0.tar.bz2 package).
After installation is finished, in «Servers» section of main menu a link to the new «Dr.Web console for UNIX
file servers» module will appear.
Figure 15. Link to the new «Dr.Web console for UNIX file servers» module
63

Basic configuration
10.2. Basic configuration
To adjust the language of Webmin and «Dr.Web console for UNIX file servers» web interfaces, go to the «Change
Language and Theme» page in «Webmin» section of main menu.
Figure 16. «Change Language and Theme» page
If you want to russify both web interfaces, choose «Russian KOI8 (RU_SU)» or «Russian CP1251
(RU_RU)» option from the «Webmin UI language -> Personal choice..» drop-down menu. If you
choose «Russian UTF-8 (RU.UTF-8)» option, only «Dr.Web console for UNIX file servers» web interface will be
russified.
On the same page you can change layout of Webmin web interface (with the «Webmin UI theme -> Personal
choice..» drop-down menu) and set new password to access Webmin (in the «Webmin login password ->
Set to..» text field).
To save and apply all changes, click «Make Changes» button and refresh the page afterwards.
At the very top of «Dr.Web console for UNIX file servers» pages «Module config» link is located, under which basic
module settings are gathered. There you can specify path to configuration file smb_spider.conf.
Figure 17. Module configuration
64

User interface
10.3. User interface
Please note, that you will not be able to use standard browser «Back» function navigating through the «Dr.Web console
for UNIX file servers» chapter. If you click «Back» button or corresponding key combination, you will get straight to the
previous chapter from main menu.
Figure 18. «Dr.Web console for UNIX file servers»
65

User interface
On the right side of the module header information about current versions of Dr.Web Samba VFS SpIDer and Dr.Web web
interface is shown.
Under the module header there are two sections: «Quarantine» and «Configuration». By default «General
Settings» tab of «Configuration» section is opened.
10.3.1. «Configuration»
Parameters values can be selected from drop-down menus or specified manually in corresponding text fields.
After changing any parameter value, you can immediately undo the change or restore default value only with one click on
the corresponding icon appeared beside. You will be able to restore default values at any time, even after you save the
changes.
To revise all changes made on current tab use «Preview» button. On the appeared screen you can choose whether to
save or not all changes or some of them (by unchecking the box against each changed value). If something seems not
ready, return to the previous screen by clicking «Continue editing» button.
Figure 19. Preview screen
When you click «Save» or «Save and apply» button, notification message appears. Click on it to return to main
screen.
Figure 20. Save screen
66

User interface
10.3.1.1. «General settings» tab
Figure 21. General settings
Values for parameters on this tab can be selected from drop-down menus or specified manually in corresponding text
fields. Detailed description of almost each parameter can be found in corresponding reference under «more» link.
67

User interface
10.3.2. «Quarantine»
When action «move» is specified as a value for parameters from «General settings» tab, blocked objects are
placed in quarantine directory. Suspicious files are put in corresponding directory in whole. On the main page of
«Quarantine» section you will find list of links to these files and will be able to download any of them for more
detailed inspection.
Figure 22. Quarantine
You can delete any file from quarantine directory by selecting corresponding checkbox and clicking «Delete» button.
68

Contact information
11. Contact information
«Dr.Web for UNIX file servers» solution is being constantly improved. The news and latest information on its updates are
available on the web-site http://www.drweb.com/.
Sales department:
http://buy.drweb.com/
e-mail: sales@drweb.com.
Technical support service:
http://support.drweb.com/
e-mail: support@drweb.com.
Please include the following information into your problem report:
●full name and version of your UNIX distribution;
●Dr.Web product version;
●configuration files of the components installed;
●log files of the components installed.
69

Appendix 1. The License Policy
Appendix 1. The License Policy
«Dr.Web for UNIX file servers» solution is available as a separate product and as a part of «universal» and «economy»
Dr.Web kits. Types of licenses vary correspondingly.
All licenses can be purchased for definite terms, i.e. for 1, 2 or 3 years. Amount of protected file servers may also vary.
License terms, their quantitative parameters and limitations may be different for various regional partners of Doctor Web,
or may be revised hereafter. To learn more about regional license terms, contact our partner in your region. List of the
trusted partners of Doctor Web can be found on the corporate web site http://partners.drweb.com/list/.
During the whole license term client have the right to receive updates from the Dr.Web Global Updating system servers
and to receive a technical support from Doctor Web and its partners.
Protection of file servers (http://products.drweb.com/fileserver/unix/)
«Dr.Web for UNIX file servers» solution is being licensed according the number of file servers used. Minimal license covers
protection of 1 file server.
70