
        Antivirus program Doctor Web for FreeBSD (version 4.32)

             Copyright (c) 1992-2004, Igor Daniloff
    Igor Daniloff's antivirus laboratory, DialogueScience, Inc.
                                                               
                  Dr.Web (R) Daemon for FreeBSD
                  System administrator manual


1. What is Dr.Web Daemon for FreeBSD ?
2. Two words about installation
3. Setting up Dr.Web Daemon
4. About the license keys
   4.1 Getting license or demo key 
   4.2 The license key installation
5. Launching Dr.Web Daemon
6. Verifying Dr.Web Daemon operability
7. Checking modes realized by Dr.Web Daemon (local scanning)
8. Contacts


                1. What is Dr.Web Daemon for FreeBSD ?

Dr.Web Daemon is an antivirus daemon, that in point of fact is an improved
antivirus scanner. But in contrast to the scanner loading bases and the
scanning module at every new start, the daemon loads these components
only once, when starting, and is always ready in the memory awaiting the
next scanning task. Besides, the daemon can carry out a few scans
simultaneously which provides on average faster response. In other respects
Dr.Web Daemon has the same facilities as the other products of the Dr.Web
family:

- it uses the kernel and the virus base used by all the other scanners of
the family;
- detects and cures all the known viruses; 
- performs scanning of packed files and archives.
Besides, recently the option of mail filtering based on header analyzing
has been added in Dr.Web Daemon.

The fact that the daemon is always ready to function and has a comprehensible
and accessible protocol for scanning requests makes it a suitable
component for creating antivirus filters for mail systems and file servers.
Developers of Dr.Web suggest the ready solutions on integration Dr.Web Daemon
with CommuniGatePro, Sendmail, Postfix, Exim, QMail and Zmailer mail
systems, and also the solution on integrating with Samba file servers.
There may obviously be other fields of application of Dr.Web Daemon,
although the listed ones are by now the principal ones.


                 2. Two words about installation

Doctor Web distribution is delivered in two formats.

- as FreeBSD packages drweb-4.32-freebsdX.tgz
- as tarball archive (drweb-4.32-freebsdX.tar.gz), containing in addition to the 
proper archived program modules the installation script; this delivered variant 
is not connected with any concrete distribution. If installing this type of
distribution Doctor Web has its own hierarchy in /usr/local/drweb.

Both forms include all the necessary components for installing and running
Doctor Web. The only requirement is that if you are installing rpm package
the distribution of the system must support this . If you are using
tarball package the only manual installation is possible.

Doctor Web delivered in the form of bsd package gets installed as usually -
with the help of rpm package management utility:

> pkg_add drweb-4.32-freebsd4.tgz

executed with administrator rights. 

If you want to use tarball archive for installation: unpack tarball-archive,
directory drweb-4.32-freebsd4 will been created and will contains a directory
tree. This tree you should copy to root directory (or place in your system as you
want, you should edit drweb32.ini in this case). Example:

> tar xzf drweb-4.32-freebsd4.tar.gz
> cp -a drweb-4.32-freebsd4/* /

Also you need create drweb account and setup correct permissions:

> chown -R drweb /usr/local/etc/drweb
> chown -R drweb /usr/local/drweb
> chown -R drweb /var/drweb


                3. Setting up Dr.Web Daemon

Naturally, you can run the daemon with the default settings, but it is
better to set it so that it would conform to your requirements and
conditions of utilization. The file drweb32.ini gets read by Dr.Web Daemon
from the directory /usr/local/etc/drweb. To use another configuration file you should
specify the full path to it in the command line key when starting Dr.Web
Daemon, e.g.:

$ /usr/local/sbin/drwebd -ini=/usr/local/etc/drwebd.ini

The configuration file drweb32.ini is a text file (so you can edit it in
your favorite text editor) organized in the following way:

--- beginning of the file ---
[Section 1 name]
Parameter1 = value1, ..., valueK
.....
ParameterM = value1, ..., valueK

.....

[Section X name]
Parameter1 = value1, ..., valueK
.....
ParameterY = value1, ..., valueK
--- end of the file ---

The ";" character (semicolon) at the beginning of the line marks a commented
line skipped by Dr.Web Daemon when reading the parameters from the .ini file.

It is extremely important to note that if a parameter determining Dr.Web 
Daemon is not set, it does not mean it has no value, it means that the 
default value will be applied (a common mistake coming along with the 
procedure of setting). Only few parameters are optional or have no default 
values, which will be specially indicated below. The values may be put 
in quotes (and should be put in quotes if they contain blanks). Some 
parameters may have a few values separated by "," (comma), it will be 
clearly indicated in the description of the parameter. If values are 
enclosed into {} in the parameter value field description, the parameter 
can take only one of them.

All parameters used by Dr.Web Daemon are described in default drweb32.ini


                4. About the license keys

        4.1 Getting license or demo key 

To activate Dr.Web Daemon for FreeBSD a license key file (drweb32.key) 
is required. You can receive the key by one of the following ways:

PURCHASE WITH AUTHORIZED PARTNERS OF DOCTOR WEB, Ltd.

You can purchase the license for the Dr. Web antivirus with authorized
partners of Doctor Web, Ltd. At the moment of purchase you will receive a
personal license with the key file, or a registration number for
registration on the web-site, which will allow you to obtain the key file
by yourself.

Find the addresses of our partners at the web-site of Doctor Web, Ltd. 
in the Purchase section (http://buy.drweb.com/).

Find the conditions of purchase at the web-site of Doctor Web, Ltd. 
in the Purchase section (http://buy.drweb.com/).

REGISTER THE PRODUCT  GET YOU LICENSE KEY FILE.

If you have already purchased the serial number you can generate the key on
the web-site of Doctor Web, Ltd. in the registration section
(http://buy.drweb.com/register/) by filling in the form. Input the serial
number into the form. The key will be immediately forwarded to the email
address specified by you. A link will be also generated enabling you to
download the key file directly from the site.

Be attentive while writing the email address!

DEMO KEY

To test the product before purchase ask for a test key at our web-site 
(http://download.drweb.com/demo/) or from our authorized partners.


        4.2 The license key installation

The Key parameter is described in both sections because keys for
Dr.Web Daemon and the scanner differ. Having purchased a license or getting 
trial license for Dr.Web Daemon you will obtain a new key file
(usually it is drweb32.key). Now you should change parameter Key in section
[Daemon] of drweb32.ini. To link up the new key file you should the value of 
the Key parameter by the full path to drweb32.key file:

For example, "Key = /usr/local/drweb/drweb32.key".

Important note: the key file is not a text file. It may not be edited in
any way, neither automatically nor converted by some programs. It often
happens that a too smart mail program converts the key file from DOS 
(with CR LF line ends (in hexadecimal notation 0D 0A) into UNIX 
(with LF line ends (in hexadecimal notation 0A)).

Loading of the daemon with the full-functional registration key looks like
the following:

=== cut ===
Tue Jul 13 13:30:38 2004 Dr.Web (R) daemon for FreeBSD, version 4.32.0 (2004-07-07)
Tue Jul 13 13:30:38 2004 Copyright (c) Igor Daniloff, 1992-2004
Tue Jul 13 13:30:38 2004 Doctor Web Ltd., Moscow, Russia
Tue Jul 13 13:30:38 2004 Support service: http://support.drweb.com
Tue Jul 13 13:30:38 2004 To purchase: http://sales.drweb.com
Tue Jul 13 13:30:38 2004 Tel. +7(095) 789-45-87 Fax +7(095) 789-45-97
Tue Jul 13 13:30:38 2004 Loading /var/drweb/bases/drwebase.vdb - Ok, virus records: 46736
Tue Jul 13 13:30:38 2004 Loading /var/drweb/bases/drw43201.vdb - Ok, virus records: 263
Tue Jul 13 13:30:38 2004 Total virus records: 46999
Tue Jul 13 13:30:38 2004 Key file: /usr/local/drweb/drweb32.key
Tue Jul 13 13:30:38 2004 Registration number: XXXXXXXXXXX
Tue Jul 13 13:30:38 2004 File license: Unlimited
Tue Jul 13 13:30:38 2004 Mail license: Unlimited
Tue Jul 13 13:30:38 2004 Daemon is installed, active interfaces:  /var/drweb/run/.daemon  0.0.0.0:3000
=== cut ===

The daemon finish his work if the key file specified in parameter Key of [Daemon] section is failed to read 
(wrong path, permission denied), expired, blocked or invalid.

                5. Launching Dr.Web Daemon

When loading daemon does the following:

- searches and loads the configuration file; if the file was not found,
Dr.Web Daemon terminates loading. Path to the configuration file may be
specified in launching parameters with the help of the key
-ini:{path/to/your/drweb32.ini} or default value may be used
(/etc/drweb/drweb32.ini). At launching some parameters get validated. If
parameter value turns out to be inadmissible, default value is taken;

- localization file gets loaded, if fixed. If it fails, messages in
English are used;

- log file is created. Note: the user under whose rights the daemon
operates, should have write access to the directory containing the log
file;

- key file gets loaded according to the path specified in drweb32.ini.
If the key is not found the daemon continues launching but it will operate
in a very restricted mode (packed file, electronic messages etc. do not get
checked);

- if the User parameter is set (or UserID) the daemon tries to change its
rights;

- search module gets loaded (drweb32.dll). If it is not found (errors in
configuration file) or damaged loading is terminated;

- then the bases with virus descriptions get loaded. Bases are searched
according to the paths set in the configuration file, loading order is
not fixed; if a base is damaged or absent loading will continue;

- the daemon "come untied" of the terminal, that is why the further
problems will not be output to the terminal, but only logged in the log
file;

- socket gets created. In case of TCP there may be more than one of them;
if any of them failed when creating loading continues. In case of UNIX
socket make sure that the user under whose rights the daemon is run has
write and read access to the directory containing the socket. The users
whose rights are used by integrating modules should have execution access
to the directory and write and read access to the socket file;

- then the so called pid file gets created. In this file information on the
descriptor of daemon process and transport addresses at which the daemon is
available is stored. Another extremely important note: the directory with
the pid file must be accessible for writing for the user under whose rights
the daemon is run, and so if you have the User parameter specified, you
should re-specify the pid file parameter also, because the default directory
/var/run is not accessible for writing for users. If the creation of the pid
file failed loading is terminated.


                6. Verifying Dr.Web Daemon operability

If no problems occurred when loading it will result in the ready-to-work
daemon - i.e. a fixed number of the scanners always ready to operate. You
can check whether the socket has been created by giving netstat -a command.
In case of TCP sockets:

--- 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 ---

In case of Unix sockets:

--- 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   /var/drweb/run/.drwebd
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 that means there have occurred
loading problems.

To check Dr.Web Daemon operability you can use the console client for the
daemon (drwebdc). Run it to get the service information on daemon. Drwebdc 
prints all avaliable options if you run it without parameters.
For TCP socket:

$ drwebdc -nHOSTNAME -pPORTNUM -sv -sb

For Unix socket:

$ drwebdc -uSOCKETFILE -sv -sb

The following information should appear:

--- cut ---
- Version: Dr.Web Daemon 4.31
- Loaded bases:
Base /var/drweb/bases/drwtoday.vdb contains 191 records.
Base /var/drweb/bases/drw43120.vdb contains 339 records.
Base /var/drweb/bases/drw43119.vdb contains 279 records.
Base /var/drweb/bases/drw43118.vdb contains 229 records.
Base /var/drweb/bases/drw43117.vdb contains 240 records.
Base /var/drweb/bases/drw43116.vdb contains 207 records.
Base /var/drweb/bases/drw43115.vdb contains 219 records.
Base /var/drweb/bases/drw43114.vdb contains 285 records.
Base /var/drweb/bases/drw43113.vdb contains 358 records.
Base /var/drweb/bases/drw43112.vdb contains 257 records.
Base /var/drweb/bases/drw43111.vdb contains 234 records.
Base /var/drweb/bases/drw43110.vdb contains 353 records.
Base /var/drweb/bases/drw43109.vdb contains 285 records.
Base /var/drweb/bases/drw43108.vdb contains 263 records.
Base /var/drweb/bases/drw43107.vdb contains 255 records.
Base /var/drweb/bases/drw43106.vdb contains 324 records.
Base /var/drweb/bases/drw43105.vdb contains 397 records.
Base /var/drweb/bases/drw43104.vdb contains 244 records.
Base /var/drweb/bases/drw43103.vdb contains 345 records.
Base /var/drweb/bases/drw43101.vdb contains 227 records.
Base /var/drweb/bases/drw43102.vdb contains 337 records.
Base /var/drweb/bases/drwebase.vdb contains 45256 records.
Total 51124 virus-finding records.
--- cut ---

If no correspondent information has been viewed 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 may clear out 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 Dr.Web daemon
ERROR: cannot retrieve daemon version
Error -12
--- cut ---

Then take the test file eicar.txt (from the distributive package), turn it
into the program eicar.com with the help of the text editor (for instructions
see the file itself) and try to check it with the daemon. 
For TCP socket:

$ drwebdc -nHOSTNAME -pPORTNUM -f eicar.com

For Unix socket:

$ drwebdc -uSOCKETFILE -f eicar.com

Such a command must result in the following diagnostics:

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

If it did not appear you should: 
- check in the daemon's log file if there is a record about checking that file
- enable enhanced diagnostics (see above).

If the checking has been completed correctly it means that the daemon is
operable.


                7. Checking modes realized by Dr.Web Daemon (local scanning)

Dr.Web Daemon has two main check modes:
- checking memory fragments received from socket;
- checking files on disc.

Let's dwell on these two modes at length. The first mode enabled, Dr.Web
Daemon receives check data from the socket, practically it is a certain
data fragment. It may be named or not - it will effect only form of logging
in Dr.Web Daemon's log file. Example of working in the mode is adduced in
the previous chapter - client read the file and sent it to the daemon for
checking. Basically the daemon can check any data fragment, not necessarily
a file.

The mode when the daemon scans the chosen file on disc is much more
efficient. Here only path to the file is reported to the daemon by the
client (whatever it is - console client or mail filter), the file itself
does not get transmitted. Attention!!! Important note: the path should be
specified in relation to the daemon (clients may located on other computers
etc.). What are the advantages of this mode? Firstly, it is more efficient,
secondly, it makes it easier to create an operational circuitry with curing
(for example, on file servers). But this mode requires a thorough right
setting, because the daemon must have read access to such a file, and in
the case of mail files and using of cure\remove actions - also write access. 
In the skillfully set system the daemon in most cases does not require 
administrator rights (root). But you should pay special attention to it when 
using it with mail servers because filters usually work under the name of 
mail system (which does not use root rights neither). In the most favorable 
mode filter created a file with the message (having received it from mail 
system) and reports its location to the daemon. At this point the rights to 
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 in the mail subsystem group, or to run the daemon under 
the mail system user.                    

                8. Contacts

Doctor Web program gets constantly developed, for fresh updating information 
and news please visit our site:

http://www.drweb.com

Marketing dept.: 
  E-Mail: sales@drweb.com
Support:
  WWW: http://support.drweb.com
  E-Mail: support@drweb.com

Please include following information in your problem report: 

- full name and version of your unix distribution
- Dr.Web version that is logged during program start

- versions of applications and filters which use Dr.Web Daemon.
