

                   Doctor Web, Ltd.

             Dr.Web(R) Daemon for FreeBSD 
                Administrator Manual

                   Version 4.33

====================================================================
The material published herein is the property of Doctor Web, Ltd.
and may not be reproduced in any form without written permission of
Doctor Web, Ltd. and proper attribution.

Dr.Web is a registered trademark of Doctor Web, Ltd.

Other product names mentioned herein are trademarks or registered
trademarks of their respective companies.

There might be further improvements and changes in the software not
described in this manual. The corrected and supplemented versions of
this manual are available at www.drweb.com.
====================================================================

(C) Doctor Web, Ltd., 2005
Russia, Moscow - Saint Petersburg
http://www.drweb.com/


          CONTENTS

1. INTRODUCTION    
  1.1. What is this manual about?      
  1.2  What is the Dr.Web(R) Daemon for Unix?   
  1.3. Dr.Web's reqirements to OS and hardware      
2. INSTALLING Dr.Web(R)
  2.1. Installing Dr.Web(R) for FreeBSD 
  2.2. Package registration. License key file  
  2.3. Updating programs and virus bases       
3. USING Dr.Web(R) DAEMON   
  3.1. Location of package files       
  3.2. The Dr.Web(R) Daemons command line options
  3.3. Configuring the Dr.Web(R) Daemon  
  3.4. Starting the Dr.Web(R) Daemon     
  3.5. Verifying availability of the Dr.Web(R) Daemon    
  3.6. Check modes of the Dr.Web(R) Daemon (local scanning)    
4. CONTACTS



                       1. INTRODUCTION

1.1. What is this manual about

The present manual describes the Dr.Web antivirus program for
Unix-based systems - Linux, FreeBSD, SunOS Solaris and OpenBSD.

The manual is meant for the employee concerned in the antivirus
security (antivirus security system administrator), named
administrator in this manual.

It is generally known, that counteraction to viruses in Unix-based
operating systems (further named as Unix-systems) has two
peculiarities. The first of them concerns the protection of the local
system and user data from the destructive impact of viral programs.
The second peculiarity deals with the diagnostics and neutralization
of viruses when using Unix-systems as platforms for communication
services, first of all, in mail servers, file servers of local
networks, etc. While the viruses can be (and in most cases they are)
designed not specifically for Unix-systems - through local networks
and mail services they distribute ordinary Windows-viruses, including
macro viruses for Word, Excel and other office applications.

The Dr.Web antivirus program for Unix-systems performs two functions.
On the one hand, it is the Dr.Web scanner for detection and curing the
viruses on the local computer. On the other hand, the package includes
the resident component (the daemon) Dr.Web Daemon (drwebd), which can
be used almost in any data processing layouts as an external plug-in
of the antivirus filter. For example, mail systems (such as
Communigate Pro, Sendmail, Postfix, Exim, QMail, ZMailer and other)
can be rather easily and flexibly tuned for using the Dr.Web Daemon to
check the e-mail messages transmitted by the mail server.

The first aspect is reflected in a separate document (readme.scanner).

The aspect of using the Dr.Web Daemon will be covered in the present
manual. Here, we would like to emphasize the following points:

- general notions on the programs, the differences between the
  versions (chapter 1);
- program's installation from packages of different formats (chapter 2);
- setting and using the daemon (chapter 3).

At the end of this manual you will find the contact information of the
technical support service.

The Dr.Web antivirus program is in constant development. The add-ons
of the databases of the known viruses are released, as a rule, several
times a day. The program itself gets upgraded too. The diagnostics
techniques and counteraction to viruses, as well as integration with
other applications of Unix-systems get constantly improved in the
program. Besides, the list of applications compatible with Dr.Web is
expanding. And it is not improbable, that some settings and functions
of the current version will differ from those described in this
manual. To get the present-day information on the program read the
electronic documentation included into the delivery package, as it
will be described in section 3.1.


1.2. What is the Dr.Web(R) Daemon for Unix?

The Dr.Web Daemon is a constantly loaded antivirus module, which
allows, by instruction from filtering programs to scan files on a
drive or data transferred through a socket. The request is sent
through a special protocol via unix- or tcp-sockets. In all other
respects, the Dr.Web Daemon has similar with other products of the
Dr.Web family functionalities:

- It uses the same kernel and virus bases as other scanners of
  the family;
- Detects and cures all known viruses;
- Checks packed files and archives.

Besides, the Dr.Web Daemon has the option of mail filtering based on
headers analysis.

Its constant readiness to function and comprehensible and simple
protocol for scanning requests makes it an appropriate component for
creating antivirus filters for mail systems and file servers.
Developers of Dr.Web offer ready solutions for integration of the
Dr.Web Daemon with CommuniGate Pro, Courier-MTA, Exim, Mobico MIO
Server, Postfix, QMail, Sendmail, Zmailer mail systems, as well as
with Samba file servers and applications using icap-protocol (Squid
and Shweby proxy servers). There obviously may be other fields of
application of the Dr.Web Daemon, those listed above are the principal
by now.


1.3. Dr.Web(R) requirements to OS and Computer

'
Dr.Web for FreeBSD works with FreeBSD versions 3.xdnl close if_freebsd

Regarding the hardware, the Dr.Web requirements are similar to those
of the console (text) mode for FreeBSD. To install the programs (the
scanner and the daemon) approximately 2,5 Mb of the disk space is
required.



                 2. INSTALLING Dr.Web(R)

NOTE. The distribution filenames and names of intermediate directories
created during the installation depend upon the antivirus version and
the OS.


2.1. Installing Dr.Web(R) for FreeBSD


NOTE. The examples sited below, for the better understanding purpose,
describe installation of the 4.33 antivirus for FreeBSD version 4.x.
In other cases, the names of files and directories will differ
respectively.

The Dr.Web distribution for this OS is delivered in two formats:

- as bsd package drweb-4.33-freebsd4.tgz, designed for FreeBSD
  packages managing system;
- as tarball-archive (drweb-4.33-freebsd4.tar.gz), for manual
  installation.

Follow the instruction to install the package:

> pkg_add drweb-4.33-freebsd4.tgz

If you want to use the tarball-archive for installation, unpack the
archive. The drweb-4.33-freebsd4 directory containing the directory
tree will be created. Copy the tree to the root directory (you can
also specify your own directory structure, but in this case you should
edit the program configuration file, see p.3.2).

Example:

> tar xzf drweb-4.33-freebsd4.tar.gz
> cp -pR drweb-4.33-freebsd4/* /

Then, create a drweb account and set up correct permissions for the
directories created:

> chown -R drweb:drweb /usr/local/drweb/lib
> chown -R drweb:drweb /var/drweb


2.2. Package registration. License key file

User's rights to use the antivirus are regulated by the special file
called the key file. The key file contains, in particular, the
following information:

- list of antivirus components licensed to the user;
- the licensed version of the antivirus;
- the license term of the antivirus;
- virus definitions automatic updates period (also called
  the "subscription period" which may not be equal to the 
  license period);
- other restrictions (i.e. the number of protected PCs, etc.).

The key file has the key extension and must be located by default in
the installation directory.

WARNING. The key file has a write-protected  and therefore must
not be edited. Editing the file makes it invalid. Consequently, it is
not recommended to open your key file with a text editor, which may
occasionally corrupt it.

Users who have purchased the antivirus from the Doctor Web's certified
partners obtain a license key file. The parameters of the key file are
specified according to the license the 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 files. Demo key
files allow to enjoy full functionality of the program and the virus
definitions updates, but have a limited term of use and no users'
support is provided.

The key file may be supplied with the key extension, or as a zip
archive containing the key file.

The key file may be received in one of the following ways.

- Supplied or sent as a zip archive containing a file with the key
  extension (usually after the registration on the web site, explained
  below). Extract the key file using the appropriate archiving tool
  and place it to /usr/local/drweb directory.
- Included into the distribution package.
- Supplied on a media as a file with the key extension. The user
  should copy it manually to /usr/local/drweb directory.

The license key file is sent to users via email, as a rule, after the
registration on the web site (the location of the web site is
specified in the registration card accompanying the product). Visit
the indicated site, fill in the web form with the customer data and
put in the registration serial number (printed in the registration
card). The key file will be sent to the specified address.

NOTE. Key files for the daemon and for the scanner may differ. To
link up the new key file you should change the value of the Key
parameter in section [Daemon] of the drweb32.ini file (see p.3.2) by
the full path to the key file. For example, 

Key = /usr/local/drweb/drweb32.key

Since the 4.33 version it is possible to specify more that one key file.
Example:

Key = /usr/local/drweb/drwebFS.key
Key = /usr/local/drweb/drwebMS.key
Key = /usr/local/drweb/drwebGW.key

The daemon will try to collect together all possible licenses. For 
example, a two license keys were specified: one for 100 e-mail addresses
and second for 15 then a summary license will have 115 e-mail addresses.
Another example: one license is a "Mail Server" license and second is a 
"File Server" license then the summary license will includes both types
of licenses.
Important note: Do not mix "per e-mail" and "traffic" types of 
"Mail Server" license.

If all keys files specified in Key parameters of [Daemon] section
are failed to read (wrong path, permission denied) or expired or blocked

or invalid then the daemon terminates his work.

If less than two weeks till the key expires left, the scanner will
generate a message on it. The daemon in this situation can notify a
user via e-mail. The messages are sent for every installed key file at
every launch, restart or reload of the daemon, if less than two weeks
till the key expires left. To enable this option, the MailCommand
parameter in the [Daemon] section of the drweb32.ini file should be
set up (read p. 5.3).

2.3. Updating programs and virus bases

As any other antivirus package the Dr.Web antivirus requires regular
updating of the virus bases of the known viruses.

For automatic receipt and installation of the virus bases' add-ons a
special script should be used from the update subdirectory of the
program's executable files directory:

> /usr/local/drweb/update.pl

Details of settings and using of this script are described in a
separate document (readme.updater). 



           3. USING Dr.Web(R) DAEMON

This section describes the location of the Dr.Web program files, the
configuration file structure, and program's startup procedure.


3.1. Location of package files

The Dr.Web is installed by default to the directories further named as
/usr/local/drweb, /usr/local/etc/drweb and /var/drweb. The
subdirectories structure is created in these directories.

The /usr/local/drweb directory houses the executable program modules -
the scanner (drweb) and the daemon (drwebd).

In its lib subdirectory the antivirus kernel as a loaded library is
located (drweb32.dll).

The database of known viruses - /var/drweb/bases/drwebase.vdb.

Configuration file - /usr/local/etc/drweb/drweb32.ini.

Language resource files (e.g., for operation with Russian interface) - 
/usr/local/drweb/lib/ru_daemon.dwl.

The documentation is located in the /usr/local/drweb/doc subdirectory.
The program manuals are represented as usual text files in two
variants - in English and Russian (KOI8-R encoded).

In the subdirectory of the /usr/local/drweb/update directory a
perl-script for updating the program (update.pl) is located.

The subdirectory of the /var/drweb/infected is meant for moving
there files if the reaction of the program is set to detect the
infected or suspicious files.


3.2. The Dr.Web(R) Daemons command line options

As for any other Unix-program, the Dr.Web daemon supports command line 
options. They are separated from the specified path by a blank and 
prefixed by the - (hyphen) symbol. To get the complete list of options 
run the drweb program with the following options: -? or -help.

-ini=<file> - using alternative ini-file;

-lng=<file> - using alternative language file; if English interface is
chosen during the installation specify ru_daemon.dwl as such file to
display messages in Russian.


3.3. Configuring the Dr.Web(R) Daemon

You can run the daemon with the default settings, but it is better to
set it in compliance with your requirements and conditions of
operation. The drweb32.ini file is read by the Dr.Web Daemon from
/usr/local/etc/drweb directory. To use another configuration file, the
full path to it should be specified by the command line key when
running the Dr.Web Daemon, for example:

> $ /usr/local/drweb/drwebd -ini=/usr/local/drweb/drwebd.ini

The configuration file is a text file (can be edited by any text
editor) that has the following arrangement:

--- Beginning of file ---
[Name of section 1]
Parameter1 = value1, ..., valueK
.....
ParameterM = value1, ..., valueK

......

[Name of section X]
Parameter1 = value1, ..., valueK
.....
ParameterY = value1, ..., valueK
--- end of file ---

If the line begins with ";" or "#", it is considered a line of
comments; such lines are skipped by the scanner when reading
parameters from the ini-file.

If some parameter of the daemon is not specified, this does not mean
the parameter has no value, - the default value will be used (a common
mistake when setting the daemon up). Only some parameters are optional
or have no default values, which will be specially mentioned below.
The values can be included in brackets (they must be included in
brackets if contain blanks). Some parameters can have several values,
the "," (comma) plays the role of the separator; in the parameter
description it will be explicitly stated. If the values are included
in {} in the parameter value field in this description, it means the
parameter may take only one of these values.

The settings for the daemon are in the [Daemon] section of this file.

The parameters will be specified in the following way:

ParameterName = PseudoParameterValue
        Parameter description 
        May have or not several values
        Default value: 
                {value | unspecified}

Description of parameters in their succession mode in the
configuration file created when installing the program.

EnginePath = {path to a file, usual extensions is dll}
        The location of the drweb32.dll module (search module). This
        parameter is also used by the updating module to update the
        search module.
        Default value: 
                /usr/local/drweb/lib/drweb32.dll

VirusBase = {list of paths (masks) to files, usual extension is vdb}
        Masks for the linked up virus bases. This parameter is also
        used by the updating module to update the antivirus bases.
        Listing of several masks is allowable.
        Default value: 
                /var/drweb/bases

UpdatePath = {directory}
        This parameter is used by the program's updating module
        (update.pl) and should be obligatory specified, if it is used.
        Default value: 
                No

TempPath = {directory}
        This directory is used by the antivirus module (search engine)
        to create temporary files. When normally operated, this
        directory is almost not used, it is used for unpacking certain
        types of archives, when a system lacks memory resources.
        Default value: 
                empty (used /tmp)

LngFileName = {path to the language resource file, usual extension - dwl}
        Location of the localization file.
        Default value: 
                empty (in this case the messages are displayed in English)

Key = {path to a file, usual extension is key}
        Location of the key file (license or demo).
        Default value: 
                /usr/local/drweb/drweb32.key

MailAddressesList = {path to a file}
        This parameter is used only if you have a "per email" license
        for 15 or 30 addresses. A list of e-mail addresses (it should
        not exceed the licensed number)
OutputMode = {Terminal | Quiet}
        The information output mode at start: Terminal - to console, 
        Quiet cancels output.
        Default value: 
                Terminal

RunForeground = {Yes | No}
        The Yes value of this parameter disables the daemon's mode of
        the Dr.Web Daemon, i.e. its acting in the background without
        the controlling terminal. This option can be used by certain
        monitoring tools (or example, by daemon tools).
        Default value: 
                No

User = {user name}
        Defines a user whose rights the daemon is run under. It is
        recommended to add a special drweb user account on the host,
        which will be used in future by the daemon and some other
        filters. To use the Dr.Web Daemon with root rights is
        undesirable, still such solution requires less settings
        (especially in Samba-servers). NOTE. The value of this
        parameter is not subject to adjustment during the
        configuration reload "on the fly" (SIGHUP handling).
        Default value: 
                empty (which means the daemon will use the 
                privileges of the user it was run with)

UserID = {numeric ID}
GroupID = {numeric ID}
        ID of a group or of a user the daemon will use the rights to
        operate. The parameters are ignored, if the User parameter is
        specified. NOTE. The values of these parameters should not be
        changed during the configuration reload "on the fly" (SIGHUP
        handling).
        Default value: 
                empty

PidFile = {path to a file}
        A name of a file where the daemon's PID and socket will be
        written to at start (of the Socket parameter enables usage of
        the unix-socket) or the port number (if the Socket parameter
        enables usage of the tcp-socket).
        If several Socket parameters are specified, this file will
        contain information on all sockets set (one per each line).
        Default value: 
                /var/drweb/drwebd.pid

BusyFile = {path to a file}
        Daemon's busy file name: it is created by a daemon's scanning
        "copy" if commanded and removed after transmission of the
        result of its execution. The filename created by each "copy"
        of the daemon, supplemented with a point and ASCIIZ
        representation of PID (e.g., /var/run/drwebd.bsy.123456).
        Default value: 
                empty (file is not created)

MaxChildren = {value}
        Sets maximum number of simultaneously running child scanning
        processes. The main process does not perform the scan, thus
        the maximum number of the daemon's processes in the system
        will be 1 process greater than the set value. Recommended
        value range - from 3 to 16 processes per CPU.
        Default value: 
                16

PreFork = {Yes | No}
        Sets mode of child processes spawn procedure. If the parameter
        is set to "No", new child process will be spawned for each
        scanned object. If the parameter is set to "Yes", the Dr.Web
        Daemon will create as many child processes, as equals to the
        MaxChildren value (explained above) immediately after start.
        PreFork mode is a highly productive process, but consumes more
        memory resources (as child processes are always present in
        memory).
        NOTE. The value of this parameter cannot be changed during the
        configuration reload "on the fly" (SIGHUP handling).
        Default value: 
                No

MailCommand = {command}

        The command used by the daemon and the updater to send 
        notifications to a user (administrator) via e-mail. The daemon 
        uses this feature at every start (restart, reboot), if less than 
        two weeks till the key (one of key files) expires left. The daemon 
        sends a message to the standard input stream of the command. The 
        updater uses this feature to send information bulletins by 
        Doctor Web, Ltd., including also on the updates procedures of 
        the program files. Example:
        MailCommand = "/usr/sbin/sendmail -i -bm -f drweb -- root"
        Default value: 
                empty.

FileTimeout = {value in seconds}
        Maximum file scan time.
        Default value: 
                30

StopOnFirstInfected = {Yes | No}
        Cancel or not message checking after the first virus is
        detected. The value set to Yes may considerably minimize the
        mail server load and messages scan time.
        Default value: 
                No

ScanPriority = {value}
        Priority of the daemon's scanning processes. The value of this
        parameter should be within -20 (highest priority) to 20
        (lowest priority).
        Default value: 
                0

FilesTypes = {list of extensions}
        Types of files to be checked at scanning "by type", i.e. when
        the ScanFiles parameter (explained below) is set to ByType.
        The "*" and "?" symbols are allowable.
        Several lines with such parameter name are allowable; in this
        case the lines are summed up.
        Default value: 
                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

ScanFiles = {All | ByType }
        Additional restriction for files to be checked. With the
        ByType value set the so-called file extensions (i.e. the last
        suffix after "." in the filename, if "." is absent it means
        the file has no extension), the values of which are specified
        or set either by default, or in the FilesTypes parameter
        (parameters), are taken into account.
	NOTE. The All mode is always enabled in mail files. The ByType
	value can be interpreted only in the "local" scanning modes.
        Default value: 
                All

CheckArchives = {Yes | No}
        Whether or not unpacking of the archives in ZIP (WinZip,
        InfoZIP...), RAR, ARJ, TAR, GZIP and CAB formats should be
        performed.
        Default value: 
                Yes

CheckEMailFiles = {Yes | No}
        Whether or not files in e-mail formats should be scanned.
        Default value: 
                Yes

ExcludePaths = {list of paths (masks) to be excluded from check}
        Masks for files that should not be checked.
        Default value: 
                empty

FollowLinks = {Yes | No}
        Should the symbolic links be followed when scanning.
        Default value: 
                No

RenameFilesTo = {mask}
        Masks for renaming files if the Rename value is set for the
        given condition (an infected or suspicious file).
        Default value: 
                "#??" which means that the first character of a file
                "extension" will be replaced by "#", and two
                subsequent characters will remain. If the file has no
                "extension" it will consist of a "#" symbol.

MoveFilesTo = {directory}
        Directory for moved files. This parameter is used only when
        the daemon is integrated with on-access monitor for Samba.
        Default value: 
                /var/drweb/infected

BackupFilesTo = {directory}
        This directory is used to backup infected files, which have
        been cured.
        Default value: 
                empty (i.e. a copy is not created)

LogFileName = {name of a file}
        Log filename. You may specify "syslog" for the log filename
        and the logging will be done by means of the syslogd system
        service. When using syslog the SyslogFacility and
        SyslogPriority parameters (explained below) should be taken
        into account. As syslog utilizes several files for logging
        different events and different degrees of their importance,
        these two parameters and the content of the syslog
        configuration file (usually /etc/syslogd.conf) determine the
        location where the report will be logged to.
        Default value: 
                syslog

SyslogFacility = {Daemon | Local0 .. Local7 | Kern | User | Mail}
        Type of record when using syslogd system service.
        Default value: 
                User

SyslogPriority = {Alert | Warning | Notice | Info | Error}
        Priority of record when using syslogd system service.
        Default value: 
                Info

LimitLog = {Yes | No}
        The parameter determines whether or not to limit the log file
        size.
        Default value: 
                No

MaxLogSize = {value in Kb}
        This parameter sets the maximum log file size. It is used only
        if LimitLog = Yes.
        Default value: 
                512

LogScanned = {Yes | No}
        Whether or not information on all scanned objects, regardless
        the viruses were detected or not, should be logged.
        Default value: 
                No

LogInfected = {Yes | No}
        Whether or not information on infected files should be logged.
        Default value: 
                Yes

LogPacked = {Yes | No}
        Whether or not additional information on files packed with
        DIET, PKLITE, etc. utilities should be logged.
        Default value: 
                Yes

LogArchived = {Yes | No}
        Whether or not additional information on the archiving tools
        should be logged.
        Default value: 
                Yes

LogTime = {Yes | No}
        Whether or not the time for each record should be logged. The
        parameter is not used if the LogFileName is set to syslog.
        Default value: 
                Yes

LogProcessInfo = {Yes | No}
        Whether or not each record in the log file should be prepended
        by pid of the scanning process and a filter address (host name
        or IP) the scanning has been activated from.
        Default value: 
                Yes

RecodeNonprintable = {Yes | No}
        The output mode of invisible for this terminal symbols into
        the log file.
        Default value: 
        Yes

RecodeMode = {Replace | QuotedPrintable}
        If RecodeNonprintable is set to "Yes", the recode mode of
        invisible symbols is set. If the value is set to Replace, all
        these symbols will be replaced with the RecodeChar paramete
        value (explained below).
        Default value: 
                Replace

RecodeChar = {"?" | "_" | ...}
        If RecodeMode is set to "Replace", a symbol, which will
        replace all invisible symbols, is set.
        Default value: 
                "_"

Socket = {PORT [interfaces] | FILE [access]}
        Description of a socket used for communication with the
        daemon. The first form describes a tcp-socket: parameter
        "PORT" - decimal port number, "interfaces" - list of listening
        interface names or IP-addresses. Example:
        Socket = 3000 127.0.0.1, 192.168.0.100
        The second form describes unix-sockets, "FILE" - socket name,
        "access" - octal value of access rights. Example:
        Socket = /var/drweb/.drwebd 0660
        The number of "Socket" keys is not limited; the daemon will
        work with all correctly described sockets.
        Default value: 
                3000 127.0.0.1

SocketTimeout = {value in seconds}
        Time of the data receipt/transmission via the socket (file
        scanning time is disregarded).
        Default value: 
                10

ListeningQueue = {value}
        Defines sockets queue maximum size. The value may vary from 0
        to SOMAXCONN (its value depends on the OS version).
        Default value: 
                overridden by the SOMAXCONN value

The following parameters can be used to reduce the archives' scan time
(some objects in the archive will not be checked). If an object falls
under the restriction set by this parameter the ArchiveRestriction
action specified in configuration files of different filters is applied.

MaxCompressionRatio = {value}
        Maximum compression ratio, i.e. the ratio of the unpacked file
        size to the packed file size (inside an archive). If the ratio
        exceeds the value the file will neither be extracted, nor
        checked.
        Default value: 
                empty (all files are checked)

CompressionCheckThreshold = {value in Kb}
        Minimum size of a file inside an archive, beginning from which
        the compression ratio will be checked (if it is specified by
        the MaxCompressionRatio parameter).
        Default value: 
                empty (the parameter is not checked)

MaxFileSizeToExtract = {value in Kb}
        Maximum size of a file extracted from an archive. If the size
        of the file inside the archive exceeds this value it will be
        skipped.
        Default value: 
                empty (files of any size get extracted)

MaxArchiveLevel = {value}
        The maximum archive's nesting level (archive in archive, and
        then in archive, etc.).
        Default value: 
                empty (archives of any nesting level get extracted)

As it was stated above, the Dr.Web Daemon has the embedded options of
mail messages filtrering based on the messages' headers analysis.
Filtering rules are also specified in the configuration file, the
rules get checked the way they are set, i.e. the rule set first is
checked first. Setting the filtering rules does not mean they will be
automatically applied. To enable the headers' analysis you should
specify certain options in the delivered filters, or set special
flags, if using customized settings on the basis of the Dr.Web Daemon.
The search of correspondence to the rule is made till the first
appropriate rule is found - the action set for the rule is returned.

ATTENTION: An antivirus checking does not applied to a message
that has been matched by some Reject* rule.
A remained rules will not be checked and a message are going into
antivirus engine for checking if the message has been matched
by Accept* rule.

ScanEncodedHeaders = {Yes | No}
        Process or not message headers before decoding. For example,
        the Yes value and the RejectCondition Subject = "iso-8859-5"
        rule allow filtering of all messages with the Subject field in
        iso-8859-5 encoding. Be aware that with the Yes value set all
        headers will be scanned twice: before decoding and after it.
        Default value: 
                No

RejectCondition {set of rules} 
AcceptCondition {set of rules}
        Description of filter rules by message headers. The rules
        consist of a header name and a regular expression describing
        the given field value. Several rules can be combined by round
        brackets and OR or AND operations. Example:
        RejectCondition Subject = "money" AND "Content-Type" = "text/html"
        Also "!=" operator (not equal) can be used.
        Special filtering rules include conditions "No HEADER" (means
        absence of this field, e.g., following the rule
        "RejectCondition No From" the messages without the "From"
        field will be filtered), HEADER = "8bit" (the field contains
        8-bit symbols).
        Default value: 
                empty

MissingHeader {list of fields}
        Describes the list of header fields the absence of which in
        the message will enable filtering the message. Example:
        MissingHeader To, From.
        Default value: 
                empty

FilterParts = {Yes | No}
        The Yes value allows using the rules set by the
        RejectPartCondition and AcceptPartCondition keys.
        Default value: 
                No

RejectPartCondition {set of rules} 
AcceptPartCondition {set of rules}
        The parameters are similar to RejectCondition and
        AcceptCondition, but used for particular message parts. The
        rule set for these parameters admits using FileName = "mask",
        where "mask" is a POSIX 1003.2 compatible regular expression.
        Messages filtering by these rules is allowable only when the
        FilterParts key is set to Yes (explained above).
        Default value: 
                empty


3.3. Starting the Dr.Web(R) Daemon

The Daemon starts as follows:

- The configuration file is searched and loaded; if it is not found,
  the Dr.Web Daemon terminates loading. The path to the configuration
  file can be specified in the startup parameters by the key
  -ini:{path/to/your/drweb32.ini}, or the default value
  (/etc/drweb/drweb32.ini) can be used. Several parameters get
  validated at start, and, if the parameter value is not allowable the
  default value is applied.

- The localization file is loaded, if it is specified; if not, English
  dialogs are used.

- Log file is created.
  NOTE. A user under the rights of which the daemon operates should
  have a write access to the directory where the log file is located.

- The key file is loaded to the location specified in the
  configuration file. If the key file is not found, the daemon
  terminates loading.

- If the User (or UserID) parameter is set, the daemon tries to modify
  its privileges.

- The search module (drweb32.dll) is loaded. If the module is not
  found (errors in configuration file) or damaged, the loading
  terminates.

- After that, the bases with the virus definitions are loaded. The
  bases are searched in the locations specified in the configuration
  file; their loading order is not fixed. If the base is damaged or
  absent the loading will continue.

- The daemon "comes untied" of the terminal, that is why the reports
  on further problems cannot not be output to the terminal and get
  reported to the log file only.

- A socket is created. In case with tcp, there may be more than one of
  them; if any of them was not created the loading continues. In case
  with unix-socket: make sure a user under the rights of which the
  daemon operates has a read and write access to the directory
  containing the socket. The users whose rights are used by the
  integrating modules should have execution access to the directory
  and write and read access to the socket file.

- Then, the so-called pid-file is created; it stores information on
  the descriptor of the daemon's process and the transport addresses
  at which the daemon is accessible. There is one more important note:
  a user under the rights of which the daemon operates should have a
  write access to the directory with pid-file, that is why if the User
  parameter is specified, you should also obligatory reset the
  pid-file parameter, as the default /var/run directory has no write
  access for users. If pid-file was not created, the loading
  terminates.


3.4. Verifying availability of the Dr.Web(R) Daemon

The error free loading results in the ready-to-work daemon, i.e. a
fixed number of scanners always ready to operate. You can check
whether a socket is created by giving the netstat -a command. 
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
unix  0      [ ]     DGRAM            416
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 there are no created sockets viewed, it means there have occurred
some problems at loading.

To check the availability of the Dr.Web Daemon use the console client
for the daemon (drwebdc); run it to obtain the service information on
the daemon. If drwebdc is started with empty parameters the list of
all supported options will be printed.

For tcp-socket:
> $ drwebdc -nHOSTNAME -pPORTNUM -sv -sb

For unix-socket:
> $ drwebdc -uSOCKETFILE -sv -sb

the following information should appear:

--- cut ---
- Version: DrWeb Daemon 4.32
- Loaded bases:
Base /var/drweb/bases/drwtoday.vdb contains 5 records.
Base /var/drweb/bases/drw43203.vdb contains 409 records.
Base /var/drweb/bases/drw43202.vdb contains 543 records.
Base /var/drweb/bases/drwebase.vdb contains 51982 records.
Base /var/drweb/bases/drw43201.vdb contains 364 records.
Total 53303 virus-finding records.
--- cut ---

If such information is not displayed, try to enable the enhanced
diagnostics. For tcp-socket:
> $ drwebdc -nHOSTNAME -pPORTNUM -sv -sb

For unix-socket:
> $ drwebdc -uSOCKETFILE -sv -sb

The more detailed output will 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 ---

Then, take the readme.eicar test file (included into the
distribution), make the eicar.com program in a text editor (see
instructions inside the file) and try to check it by the daemon:

if you have license for mail server (50 and greater addresses):

For tcp-socket:
> $ drwebdc -nHOSTNAME -pPORTNUM -e -f eicar.com
For unix-socket:
> $ drwebdc -uSOCKETFILE -e -f eicar.com

if you have license for mail server (15 or 30 addresses):

For tcp-socket:
> $ 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, one of "protected" addresses (from email.ini))

if you have license for file server or internet-gateway:

For tcp-socket:
> $ drwebdc -nHOSTNAME -pPORTNUM -f eicar.com

For unix-socket:
> $ drwebdc -uSOCKETFILE -f eicar.com

The command must result in the following diagnostics:

--- cut ---
Results: daemon return code 0x20 (known virus is found)
--- cut ---

If failed, you should:

- study the daemon's log file for the record on the check of this file;
- enable enhanced diagnostics (explained above).

If the check was successful, it means that the daemon is operable.


3.5. Check modes of the Dr.Web(R) Daemon (local scanning)

The Dr.Web Daemon provides for two basic check modes:

- check of the memory fragment received from a socket;
- check of a file on a disk.

Let us treat in details these two modes. The first mode enabled, the
Dr.Web Daemon obtains data for check from a socket; actually, it is a
fragment of data. This fragment can be named or not, - this will
affect only the form of logging in the Dr.Web Daemon's log file. Read
the previous section for the example of such operation of the daemon -
the client read the file and sent it to the daemon for check.
Basically, the daemon can check any data fragment; it should not
always be a file.

But much more efficient is the mode when the daemon checks the
definite file on a disk, - i.e. the client (be it a console client, or
a mail filter) reports to the daemon the path to a file only, but does
not transmit the whole file.

NOTE. The path should be specified in relation to the daemon (as
clients can be located on other computers, etc.).

What are the advantages of such mode? Firstly, it is more productive;
secondly, it is much easier to create an operational circuitry with
curing (e.g., on file servers). But this mode requires a careful
rights setting, as the daemon should have a read access to such file;
in case with mail files, if the curing and deletion are enabled it
should also have a write access. In the skilfully set system the
daemon, in most cases, does not require administrator's (root) rights.
But you should pay special attention to it when using it with mail
servers, because filters usually run under the name of the mail system
(which also does not use root rights). In the most favourable mode the
filter creates a file with a message (having received it from the mail
system) and reports its location to the daemon. At this point the
right access the directory where filters will create files should be
carefully allotted. We would recommend either to enclose the user
whose rights are used by the daemon into the mail subsystem group, or
run the daemon under the mail system user.



                         4. CONTACTS

Dr.Web program gets constantly developed, for fresh updating
information and news please visit our site:
  http://www.drweb.com

Marketing dept.:
  http://buy.drweb.com
  e-mail: sales@drweb.com

Support:
  http://support.drweb.com
  E-Mail: support@drweb.com

Please include following information in your problem report:

- full name and version of the UNIX distribution;
- the Dr.Web program version;
- versions of applications and filters the Dr.Web Daemon is integrated
  with;
- configuration files of the daemon and the applications the Dr.Web
  Daemon is integrated with;
- log files of the daemon, filters and other applications the
  Dr.Web Daemon is integrated with.
