ESET NOD32 ANTIVIRUS - FOR LINUX MAIL SERVERS User manual

NOD32 for Linux Mail Servers
Installation Manual
and
Users’ Documentation
Copyright 2005, Eset, s.r.o.
(for use with FreeBSD)

NOD32 for Linux Mail Server (for use with FreeBSD), First Edition
Published on 11th March 2005
Copyright © 2005 Eset s.r.o.
All rights reserved. No part of this documentation may be reproduced, stored in a retrieval system or transmitted in any form or by
any means, electronic, mechanical, photocopying, recording, scanning, or otherwise without a permission in writing from the author.
Eset s.r.o. reserves the right to change any of the described application software without prior notice.
Revision History
Revision 2.14-1 (11/03/2005)
Chapter with alternative methods using NOD32 Command Line Interface (nod32cli) added.
Revision 2.13-2 (10/02/2005)
Chapter with tips and tricks for NOD32LMS configuration added.
Revision 2.13-1 (01/01/2005)
Authorized transcription of NOD32 for Linux Mail Servers (version 2.13-1) user’s guide.

Table of Contents
1. Introduction .......................................................................................................................................... 1
2. How to navigate through this guide ................................................................................................ 3
3. Mail server in UNIX OS environment............................................................................................. 5
4. NOD32LMS package installation..................................................................................................... 9
5. NOD32LMS configuration............................................................................................................... 11
5.1. NOD32LMS - own configuration......................................................................................... 11
5.2. Scanning of the inbound e-mail messages..........................................................................13
5.2.1. Renaming the original MDA and its replacement by NOD32MDA..................14
5.2.2. Setting of NOD32MDA (in MTA) as MDA............................................................16
5.2.2.1. Setting Sendmail MTA ................................................................................. 16
5.2.2.2. Setting Postfix MTA ...................................................................................... 17
5.2.2.3. Setting Qmail MTA ....................................................................................... 18
5.2.2.4. Setting MTA Exim version 3........................................................................20
5.2.2.5. Setting MTA Exim version 3 (more general).............................................21
5.2.2.6. Setting MTA Exim version 4........................................................................23
5.3. Scanning the outbound e-mail messages............................................................................ 24
5.4. Content filtering in MTA....................................................................................................... 27
5.4.1. Content filtering in MTA Postfix .............................................................................27
5.4.2. Content filtering in MTA Sendmail.........................................................................28
5.4.3. Content filtering in MTA Exim ................................................................................29
5.5. Alternative methods of scanning e-mails. ..........................................................................30
5.5.1. Scanning e-mail messages using AMaViS .............................................................30
5.5.1.1. amavis............................................................................................................. 31
5.5.1.2. amavisd .......................................................................................................... 32
5.5.1.3. amavisd-new ................................................................................................. 32
6. NOD32 system update and maintenance...................................................................................... 35
6.1. Basic concept of NOD32 system update. ............................................................................35
6.1.1. NOD32 modules organization.................................................................................35
6.1.2. NOD32 mirror creation............................................................................................. 36
6.1.3. Generation of NOD32 scanner loading modules..................................................36
6.2. Subordinate mirrors creation................................................................................................ 37
6.3. Automatic update of the virus definitions database.........................................................38
6.3.1. Structure and use of automatic update script .......................................................38
6.3.2. Periodic update of the virus definitions database ................................................39
7. Tips and tricks .................................................................................................................................... 41
7.1. Dropping messages marked by NOD32 as deleted in MTA Postfix...............................41
7.2. NOD32LMS and TLS support in MTA................................................................................41
8. Let us know ......................................................................................................................................... 45
A. Installed content of NOD32LMS package................................................................................... 47
iii

iv

Chapter 1. Introduction
Dear user, you have acquired NOD32 for Linux Mail Servers (for use with FreeBSD) -
NOD32LMS - probably the best antivirus system for e-mail servers running under the FreeBSD
operating system. As you will soon realize, the system has unsurpassed scanning speed and
detection rate, combined with a very small footprint that makes NOD32 the ideal choice for
any FreeBSD mail server.
The following is a short summary of its key features.
•NOD32 scanning engine algorithms provide both the highest detection rate and the fastest
scanning times.
•It includes unique advanced heuristics for Win32 worms and backdoors.
•The system solution is MTA-independent (mail server independent).
•Inbuilt NOD32 archivers unpack archived e-mail attachments without the need for any exter-
nal programs.
•In order to increase speed and efficiency of the system, its architecture is based on the running
daemon (resident program) where all the scanning requests are sent to.
•Six various levels of logging can be configured to get information about system activity and
infiltrations.
•One of the major advantages is the fact that the system installation does not require external
libraries or programs except for libc.
•The system can be configured to notify any person in case of detected infiltration.
•Moreover, information about infiltration can be configured to be written into an e-mail header,
footer and subject.
To run efficiently, the NOD32LMS requires just 5MB of hard-disk space and 8MB of RAM. The
system supports most popular mail server software including Sendmail, Postfix, Qmail, Exim
and runs smoothly under 4.X and 5.X FreeBSD distributions.
From lower-powered, small office mail servers to enterprise-class ISP mail servers with thou-
sands of users, NOD32LMS delivers the performance and scalability you expect from a UNIX
based solution and the unequaled security of NOD32.
1

Chapter 1. Introduction
2

Chapter 2. How to navigate through this guide
This guide is assumed to be the complex users’ guide into the NOD32LMS system. It covers in-
formation on configuration and maintenance of the system in order to run efficiently for various
supported FreeBSD OS distributions and various e-mail server systems.
Therefore, assuming you are a typical system administrator being too busy to read all these
pages, here are some hints on how to surf through this guide with just catching the most relevant
information necessary to setup and run.
First, look into the common messaging system scheme (next section) to see what the NOD32LMS
is able to do for you. Identify the proper implementation of the NOD32LMS into your system
and skip directly to the section that discusses the appropriate scenario.
Second, identify an e-mail server system running on your FreeBSD OS and browse through just
the appropriate sections of this guide. All the guide sections are done in a manner that the e-mail
server system name always appears in the section title, in case the section is system specific.
Third, look into the foreword to each chapter to get information related to relevance of the
information stored in the chapter. Often you will get a hint to skip directly to the section that
contains just the step by step statement information in order to suffice what is necessary.
Fourth, besides the information in this guide, there exists manual pages related to the individual
components of the NOD32LMS package. The pages are always a useful reference for getting
actual information on the accurate components setting options that are not all mentioned here.
Lastly, note that the guide is divided in a following manner:
Chapter 1
Introduction.
Chapter 2
This text, that you have almost finished reading.
Chapter 3
Common scheme of the UNIX OS messaging system. Gives you an overview on what
NOD32LMS can do for you.
Chapter 4
Leads you step by step to install the system.
Chapter 5
Lists e-mail server specific configurations.
Chapter 6
Will help you keep your system up to date.
Chapter 7
Contains tips and tricks on configuration of NOD32LMS.
3

Chapter 2. How to navigate through this guide
Chapter 8
Contains information on where to send your questions or remarks.
4

Chapter 3. Mail server in UNIX OS environment
This chapter is concerned with the basics of the e-mail messaging system, also commonly called
e-mail server system, however, e-mail server is only part of the more complex messaging system.
For better understanding of the NOD32LMS operation, knowledge of the messaging system
basic principles is of paramount importance. Therefore we do not recommend to skipping this
section unless this knowledge is already acquired.
The following diagram is a rough scheme of the UNIX OS e-mail messaging system.
Figure 3-1. Scheme of UNIX OS e-mail messaging system.
MDA
MAILBOX
MTA
MUA
INTERNET
E−mail Server
PIPE
FILE
Clients
Computer
(SMTP)TCP PORT 25 (SMTP)
TCP PORT 110 (POP3)
OR 143 (IMAP) TCP PORT 25 (SMTP)
S1
S2
S3
Client
5

Chapter 3. Mail server in UNIX OS environment
The meaning of abbreviations used in the scheme of figure 3-1 is as follows.
MTA (Mail Transport Agent)
A program (for instance sendmail, postfix, qmail, exim, etc.) receives e-mail messages from
local and/or remote domains and forwards it for further delivery. Generally speaking, MTA
is an agent providing mail transfer among other e-mail servers MTAs and/or MUAs (see
below).
MDA (Mail Delivery Agent)
A program (maildrop, procmail, deliver, local.mail, etc.) providing delivery of an e-mail
into a particular mailbox.
MUA (Mail User Agent)
An e-mail processing program (MS Outlook, Mozilla Mail, Eudora, etc.) that allows user to
access and manage e-mail messages (i.e. read, compose, print them etc.).
MAILBOX
A file or a file structure on a disk serving as the storage space for e-mails. Note: There
are several formats of Mailboxes in FreeBSD OS. (e.g.: an old fashioned format where e-
mails for each user are stored sequentially in one user appropriate file located in directory
/var/spool/mail; MBOX (a bit newer but still an old format) with e-mails stored sequen-
tially in one file located within user home directory; MAILDIR with e-mail stored in a sep-
arate file within a hierarchical directory structure.
Now the scheme in the figure 3-1 represents a typical e-mail gateway placed at an entrance to
some local network. This means that the e-mail server receives data communication typically
via TCP port 25 (SMTP - Simple Mail Transfer Protocol is used within this process). The mes-
sage received is transfered by the local MTA either to another remote e-mail server system or
the message is delivered by using local MDA into the appropriate MAILBOX (we assume that
each user belonging to the local network has a corresponding MAILBOX located at the server).
It is then a responsibility of the client’s local MUA to provide download and/or correct inter-
pretation of the message at the client’s computer. To get the data from an e-mail server system
the MUA uses typically TCP port 110 (POP3 - Post Office Protocol) or TCP port 143 (IMAP -
Internet Message Access Protocol). On the other hand if a user at the client’s computer would
like to send an e-mail message to the Internet, it is again the responsibility of the local MUA to
deliver the message via TCP port 25 (SMTP) to the local MTA (located at an entrance to the local
network) that will take care of the further message delivery.
The operating principle of NOD32LMS system is based on the idea of data communication in-
terception at the various phases of its transfer and of scanning this communication by NOD32
scanning engine. Those locations are marked in the figure 3-1 by symbols S1, S2 and S3. In the
following text we will distinguish between three scenarios of e-mail message scanning which
basically corresponds to the referred marks:
6

Chapter 3. Mail server in UNIX OS environment
•Scanning of inbound e-mail messages (We define the term "inbound message" for e-mail mes-
sage with the target address corresponding to the destination located at the local domain.
Similarly the "outbound message" will be a message bound to some remote domain via its
target address.) marked in the figure by symbol S1, is used to protect e-mail messages deliv-
ered from the outside Internet to the local MAILBOX-es belonging to local users.
•Scanning of outbound messages marked in the figure by symbol S2 is used to protect the
e-mail messages sent by local user MUAs to the outside Internet.
•Bi-directional scanning (usually known also as content filtering in MTA) marked by symbol
S3 is devoted to check both directions (or even all directions) of the e-mail messages flow.
Note: Bi-directional scanning scenario is more complex than the other two methods previously
discussed. The bi-directional scanning checks not only message flow directed from Internet to a
local network or vice versa. Indeed, this scanning also takes care of the messages that will come
to the gateway server and are further routed to the different remote domains. Therefore in a
general case this kind of scanning can be used typically as a checkpoint between two different
Internet networks. From this point of view, concerning our local e-mail gateway, this kind of
scanning is not necessarily required, as this creates a much higher load on the server computer
than previously discussed scenarios.
7

Chapter 3. Mail server in UNIX OS environment
8

Chapter 4. NOD32LMS package installation
Before further explanations concerned with NOD32LMS, let’s first install the whole thing. In
order to do so, one has to download the appropriate packages from the NOD32 server. Use your
favorite web browser to navigate to the NOD32 download page
http://www.nod32.com/download/download.htm
At this page you can see a set of NOD32LMS packages listed for various UNIX OS distributions.
Identify the appropriate distribution of the actual OS installed on your computer and download
the appropriate package.
Note: For the download process to succeed, the username and password for authentication
against the NOD32 server is required. You will receive both from your vendor.
In order to install NOD32LMS from a tgz file related to FreeBSD distribution, copy the file
nod32lms-x.xx-x.i386.fbs.tgz, for instance, into the directory /usr/local/src. Unpack the file
tar -xvzf nod32lms-x.xx-x.i386.fbs.tgz
and copy the individual components of the package into the corresponding subdirectories of
the root directory. For this purpose check the appendix A to see complete NOD32LMS package
content installed at the proper location.
After copying the NOD32LMS components you should see a short scripts in the
/usr/local/etc/rc.d directory that correspond to the individual NOD32LMS daemon
components. For instance
/usr/local/etc/rc.d/nod32d.sh
is the initialization script for nod32d daemon used. In order to start this daemon you have to
write the following command line statement
/usr/local/etc/rc.d/nod32d.sh start
Similar statement is valid for stopping the appropriate daemon, i.e.
/usr/local/etc/rc.d/nod32d.sh stop
The other daemons of NDO32LMS can be started and/or stopped in a same way by using their
appropriate scripts. Use your favorite editor to explore the functionality of above scripts.
9

Chapter 4. NOD32LMS package installation
10

Chapter 5. NOD32LMS configuration
This chapter describes the process of the NOD32LMS configuration. In the first section the struc-
ture and meaning of all NOD32LMS configuration files will be discussed. The rest of the chapter
is devoted to individual scenarios related configurations as discussed briefly in chapter 3.
5.1. NOD32LMS - own configuration
All the necessary configuration files concerned with functionality of NOD32LMS are stored
within a directory
/etc/nod32
In the following text all the files stored within this directory are going to be discussed.
/etc/nod32/nod32.cfg
This is a most important file, commonly known also as ’main NOD32 configuration file’. Af-
ter exploring the file you can see that its structure is composed from various parameters of
NOD32LMS that are all distributed within sections (note the section names are always enclosed
in square brackets - []) . There is always one global and several special sections in the file. The
configuration of the whole system (i.e. key features discussed within Introduction to this guide
and much more) is provided by setting parameters used within individual sections. The param-
eters defined within a global section are valid for all modules (sometimes we call those modules
’agents’) of NOD32LMS. The parameters defined within a special section, on the other hand,
are valid only for an appropriate agent of NOD32LMS. At this point we should describe the
individual parameters meaning, however, we will not do it here as it is done in manual pages
corresponding to the appropriate module. For instance the parameters that can be used in global
and also in special sections are described in the manual page concerned with daemon nod32d
(main NOD32LMS daemon). The manual page can be invoked using the following statement
man nod32d
Similarly, the parameters that can be only used in the special sections are described in the
manual pages concerned with individual modules, i.e. nod32mda, nod32smtp, nod32smfi and
nod32cli.
We recommend the user to use these resources always when referring to the parameters of
NOD32LMS components. Refer to the appendix A to see a full list of manual pages installed.
Let’s return to the description of the structure of the main configuration file. It is good to note
that every parameter listed in the global section has a lower priority than the same parameter
listed in the module section. The only exception is concerned with the parameters reported in
the manual page for daemon nod32d as private, which are used only by nod32d daemon. These
are typically the logging parameters as there is only daemon nod32d that provides you with
logging of NOD32LMS activity and infiltrations detected by the system.
11

Chapter 5. NOD32LMS configuration
To finish a general description of the main configuration file, we will yet make a remark on the
parameters type. Note that there are basically three types of parameters in the configuration file,
e.g.:
integer
Integer parameters accept integer values. For instance (listen_port = 2526).
string
String parameters accept the strings delimited by quotation marks (server_addr = "local-
host").
logical variable
Logical variables accept two values: yes or no. For instance (scan_obj_emails = yes) or
(scan_obj_emails = no).
/etc/nod32/nod32.auth
This is the so called ’user authentication file’ that is used to authenticate the user against the
NOD32 server when making an update of the virus signatures database. We will not discuss the
meaning of the file here as it is done later in chapter 6 with more details.
/etc/nod32/sig_*.html.example
When browsing through the /etc/nod32 directory you have probably noticed a set of files
whose names are starting with same prefix ’sig’ and ending with suffix ’html.example’. These are
the html templates that can be used to define the text, inserted as a footnote, into the scanned
e-mail messages (use your favorite editor to explore the files). In order to enable this feature,
you have to set an appropriate option in the main configuration file (write_to_emails) that can
be defined in a global section of the file as well as in the individual modules section of the file
depending on what level of footnote writing we would like to achieve in appropriate individual
modules (see nod32d manual page for detail). The other requirement to enable the custom html
templates is to remove the suffix ’.example’ from all the file names of the templates. In this case
the NOD32LMS system will ignore the default footnote text and will use the text predefined
in the html files instead. The meaning of the individual files can be explained directly in the
structure of e-mail footnotes inserted.
When NOD32 system has detected infiltration in the e-mail message, the following footnote
template is written into the footnote when enabled.
e-mail header | From:
. | To:
----------------------------
e-mail body |
. |
. |html text of the file sig_header_infected.html
. |
. |list of infiltrations found by the scanner
. |
. |html text of the file sig_footer_infected.html
12

Chapter 5. NOD32LMS configuration
When NOD32 system has not detected any infiltration in the e-mail message, the following
footnote template is written into the footnote when enabled.
e-mail header | From:
. | To:
----------------------------
e-mail body |
. |
. |html text of the file sig_header_clean.html
. |
. |list of infiltrations found by the scanner
. |
. |html text of the file sig_footer_clean.html
/etc/nod32/nod32d_script
There is one more file within /etc/nod32 directory. It is a NOD32LMS notification script. In case
NOD32 scanner has found an infiltration within a scanned message, this script (if enabled) is
used to send a notification about the event to any person defined within a script. This func-
tionality is enabled by logical parameter of the main configuration file (exec_script = yes). To
get more information on this topic, read the section NOTIFICATION within the nod32d manual
pages.
13

Chapter 5. NOD32LMS configuration
5.2. Scanning of the inbound e-mail messages
Scanning of the inbound e-mail messages is performed at the time of message transmission
between MTA and MDA (as marked by symbol S1 in figure 3-1). The generic scheme of the
process is shown in the figure 5-1.
Figure 5-1. The scheme of the inbound e-mail message delivery without (left part of the
figure) and with (right part of the figure) the NOD32 scanning.
MTA
MDA
MAILBOX
MTA
MDA
MAILBOX
NOD32MDA NOD32D
FILE
PIPE
PIPE
FILE
FILE
The incoming e-mail is scanned by nod32mda module supported by daemon nod32d. Scanned
e-mail is afterward forwarded to the original MDA for further delivery to the MAILBOX.
As shown in the figure 5-1, the virus scanning feature can be enabled by appropriate configu-
ration setting of the MTA agent and nod32mda module. It is also apparent from the figure that
the solution is MDA independent.
Note: The majority of mail servers use procmail or maildrop (MDA). The nod32mda module
supports any MDA. The following MDAs were tested: procmail, maildrop, deliver and lo-
cal.mail.
In general, the virus scanning feature can be enabled in two ways described below.
14

Chapter 5. NOD32LMS configuration
5.2.1. Renaming the original MDA and its replacement by
NOD32MDA
This is a simple approach even without a need to make any changes in the agent MTA. But
still, prior starting with the proper setup modification, the user is required to know exactly
what MDA agent is used by the system. This information can be grabbed only by exploring the
MTA configuration file. More information on how to do this is described shortly for individual
MTAs always at the start of the appropriate subsections 5.2.2.1. (sendmail), 5.2.2.2. (postfix),
5.2.2.3. (qmail), 5.2.2.4. (exim version 3 or less) and 5.2.2.4. (exim version 4). Please, check the
appropriate text parts and then return here. For illustration purposes, we will use the MDA
procmail.
In the next step we have to find the location of the MDA. In order to do so we use the following
command:
which procmail
that will give as the full path to agent MDA in return. Now the most important part of the
modification is to rename the original procmail binary file to procmail.real:
mv /usr/bin/procmail /usr/bin/procmail.real
and create the soft link to module nod32mda with the name ’procmail’ located in the directory
where the original MDA procmail was found, i.e. with the name ’/usr/bin/procmail’:
ln -s /usr/bin/nod32mda /usr/bin/procmail
With the above modifications, we have ensured that all the messages originally sent by the MTA
for delivery to MAILBOX (by using an original MDA) will now be primarily sent to module
nod32mda. Still there remains the second part of the modification to provide that all messages
processed by nod32mda will be sent to the original procmail MDA (at this time renamed to
procmail.real). In order to do so, we have to modify parameter ’mda_path’ within the section
[mda] of the main NOD32LMS configuration file (/etc/nod32/nod32.cfg) as follows:
mda_path = "/usr/bin/procmail.real"
After all of the above modifications one has to restart the daemon nod32d in order to reread the
new configuration of NOD32LMS.
Note that in the above example we have used procmail as an MDA, however, the whole pro-
cedure can be done with any other known MDA which is a great advantage of this approach.
On the other hand, there is a potential problem within this configuration that may occur in
circumstances of MDA software upgrade. Indeed, once we will decide to upgrade the MDA
software (for instance procmail in our case), the upgrading mechanism will provide the new bi-
nary file /usr/bin/procmail that will cancel the link to nod32mda scanning module created by
the above procedure and the configuration will be broken. Thus, even if the approach suggested
in this section works in all cases, it is always necessary keep in mind that the problem of the
15

Chapter 5. NOD32LMS configuration
link cancellation may occur and one has always, after the MDA software upgrade, to repeat the
whole procedure described above.
5.2.2. Setting of NOD32MDA (in MTA) as MDA
This section contains a more rigorous approach to provide scanning of inbound messages than
the one described in the previous section. Even if the approach described here requires modi-
fication of the MTA configuration, we recommend it due to the fact that it does not bring the
potential problems, described at the end of the previous section, to the system.
Note: Some MTA modules may be configured to not need an MDA component to deliver e-
mails. In such (very rare) cases, it is necessary to configure the MTA to use any, by NOD32LMS
supported, external MDA (for instance procmail or maildrop).
5.2.2.1. Setting Sendmail MTA
An MTA Sendmail stores all its configurations in one file /etc/mail/sendmail.cf (in older op-
erating systems it can be stored in /etc/sendmail.cf). The procedure described here will there-
fore be done only with this one file and of course with the main NOD32LMS configuration file
(/etc/nod32/nod32.cfg).
First one has to grab information on the MDA used by Sendmail. This can be found in the Send-
mail configuration file (/etc/mail/sendmail.cf) in the section called ’Local and Program Mailer
specification’ at the parameter ’P’ (in the sentence starting with word ’Mlocal’). Yet, before per-
forming any changes to the Sendmail configuration file, please, make a back-up of this file (for
example with the name sendmail.cf.orig). Now let’s return to the description of the sendmail.cf
parameters. The parameter ’P’ represents the full path to the MDA used. In order to involve
’nod32mda’ module into the message processing, one has to replace this path by the appro-
priate ’nod32mda’ module path (i.e. /usr/bin/nod32mda). At the same time the appropriate
change has to be done for parameter ’A’ (located at the same sentence of Sendmail configura-
tion file). Note that the ’A’ parameter contains the file name of the original MDA component
followed by some switches. These switches represent macros used by Sendmail when process-
ing a message. Therefore none of the switches may be changed when modifying the name of the
original MDA component at the parameter ’A’. For instance, if the original MDA component
path is /usr/bin/procmail, the appropriate sentence in the Sendmail configuration file can look
like this.
Mlocal, P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPhnu9,
S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
T=DNS/RFC822/X-Unix,
A=procmail -t -Y -a $h -d $u
After the modifications have been performed, the appropriate sentence will look like this.
Mlocal, P=/usr/bin/nod32mda, F=lsDFMAw5:/|@qSPhnu9,
S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
T=DNS/RFC822/X-Unix,
A=nod32mda -t -Y -a $h -d $u
16