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.
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 thousands 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 information 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 seewhat 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
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
This chapter is concerned with the basics of the e-mail messaging system, also commonly called
e-mail serversystem, 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.
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 emails 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 sequentially in one file located within user home directory; MAILDIR with e-mail stored in a separate 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 message 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 interpretation 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 interception 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 delivered 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 structure 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’. After 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 parameters 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 appropriatemodule. 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 = "localhost").
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 arestarting 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
Loading...
+ 36 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.