we protect digital worlds NOD32 for Linux/BSD Mail Server Installation Manual and User’s documentation
Table of contents NOD32 for Linux/BSD Mail Server, First Edition Published on 6th December 2006 Copyright © 2006 Eset, s.r.o. NOD32 for Linux/BSDMail Server was developed by Eset, s.r.o. For more information visit www.nod32.com.sg. NOD32 for Linux Mail Server was developed in co-operation with ProWeb Consulting. For more information visit www.pwc.sk. All rights reserved.
Chapter 1: 1 Introduction Introduction
Dear user, you have acquired NOD32 for Linux/BSD Mail Server - NOD32LMS/NOD32BMS - probably the best antivirus system running under the Linux/BSD OS. As you will soon find out, the system using, the state-of-the-art NOD32 scanning engine, has unsurpassed scanning speed and detection rate, combined with a very small footprint that makes it the ideal choice for any Linux/BSD OS server. In the rest of this chapter we review a key features of the system.
Chapter 2: 2 Installation Installation
This product is distributed as a binary file. Its format for Linux OS is: nod32ls.i386.ext.bin where ’ext’ is a Linux OS distribution dependent suffix, i.e. ’deb’ for Debian Linux OS distribution, ’rpm’ for RedHat and SuSE Linux OS distributions, ’tgz’ for other Linux OS distributions. Note that we support also RedHat Ready and Novell (SuSE) Ready variation of the product . The RedHat and Novell (SuSE) Ready variation of the binary file format is: nod32ls-rsr.i386.rpm.
Chapter 3: 3 Product’s Roadmap Product’s Roadmap
Once the product package has been successfully installed, it is time to become familiar with its content. The structure of the NOD32LMS/NOD32BMS is shown in the figure 3-1. The system is composed of the following components. Figure 3-1. Structure of NOD32LMS/NOD32BMS. AGENTS NOD32SMTP NOD32SMFI NOD32PIPE NOD32MDA NOD32CLI CORE NOD32D LIBNOD32.SO NOD32.00X CONFIGURATION nod32.
/etc/nod32 Note that in case of RedHat Ready and Novell (SuSE) Ready variation of the NOD32 for Linux Mail Server the configuration and authorization directory is /etc/opt/eset/nod32 The directory consists of the following files. nod32.cfg This is the most important configuration file as it maintains the major part of the product functionality. For this reason the file is further referred to as ‚main configuration file‘ or ‚main NOD32 configuration file‘.
e-mail header | From: . | To: -------------------------e-mail body | text of . | . | content . | list of . | content e-mail body of lms_sig_header_infected.html infiltrations found by the scanner of lms_sig_footer_infected.html The following footnote templates are used in e-mails found as clean: e-mail header | From: . | To: -------------------------e-mail body | text of . | . | content . | list of . | content e-mail body of lms_sig_header_clean.
Chapter 4: 4 Integration with E-mail Messaging System Integration with E-mail Messaging System
This chapter describes integration of the NOD32LMS/NOD32BMS with the variety of known email messaging systems. Knowledge of e-mail messaging system basic principles (figure 4-1) is of paramount importance for understanding of the NOD32LMS/NOD32BMS operation. Figure 4-1. Scheme of UNIX OS e-mail messaging system. MTA - Mail Transport Agent A program (for instance sendmail, postfix, qmail, exim, INTERNET etc.) providing e-mail messages transfer among local and remote domains.
4.1. Scanning of inbound e-mail messages Scanning of the inbound e-mail messages is performed during the messages transfer between MTA and MDA. Scheme of this process is in the figure 4-2. The incoming e-mail is intercepted by nod32mda module, scanned by main NOD32 daemon ’nod32d’ and delivered to MAILBOX using original MDA. As shown in the figure, the virus scanning can be enabled by proper configuration setting of MTA and nod32mda module. It is also apparent that the solution is MDA independent.
configuration will be broken as the new version of MDA will cancel the link to nod32mda module. 4.1.2. Setting of NOD32MDA (in MTA) as MDA This section contains a more rigorous approach to provide scanning of inbound messages. Note: Some MTA modules may be configured to not use MDA component for e-mail messages delivery. In this case, it is necessary to configure them in a way to use any, by NOD32LMS/NOD32BMS supported MDA (for instance procmail or maildrop). 4.1.2.1.
not a full-blown MDA, it is rather a wrapper; the ‘mda_path‘ parameter in this case has the following format: mda_path = “/usr/lib/sm.bin/sensible-mda“ To reread of newly created NOD32 configuration, enter the following command: /etc/init.d/nod32d reload To accomplish the whole procedure, one has to restart the MTA Sendmail. Note that NOD32LMS/NOD32BMS provides you with the option to define NOD32 scanning engine parameters individually for recipient users (resp. recipient domains).
recipient user to nod32mda module using its command line interface. Note that in case you would like to pass any command line parameter to the whole nod32mda agent it is necessary to prepend the parameter by sentence ‚--‘, otherwise the parameter will be assumed to be passed to original MDA specified by the ‘mda_path‘ parameter. Thus for instance to pass command line option --user to nod32mda agent the ‘mailbox_command‘ option has to be defined in the following way.
nod32mda module first. Still there remains to provide that all messages processed by nod32mda will be passed back to QMail’s program for further message delivery.
condition = “${if eq {$received_protocol}{virus-scanned} {0}{1}}“ transport = nod32_transport verify = false Note that above entry has to be placed as a first of the DIRECTORS CONFIGURATION section. You also have to define an appropriate TRANSPORTERS CONFIGURATION entry responsible for e-mail messages delivery to nod32mda agent.
parameter has to be defined as follows: command = /opt/eset/nod32/bin/nod32mda -oMr virus-scanned $local_part@$domain \ -- --user $local_part 4.1.2.5. Setting NOD32MDA in MTA Exim version 4 Let’s look inside the exim configuration file ’/etc/exim4/exim4.conf’ to become familiar with its content. It is typically compound from TRANSPORTS CONFIGURATION section and ROUTERS CONFIGURATION section. Usually there is a ROUTERS CONFIGURATION entry ’localuser’ responsible for e-mail messages local delivery.
/etc/init.d/nod32d reload To accomplish the whole procedure, one has to restart the MTA Exim. Note that NOD32LMS/NOD32BMS provides you with the option to define NOD32 scanning engine parameters individually for recipient users (resp. recipient domains). In this case it is necessary to pass the information about the recipient user to nod32mda module using its command line interface.
case you use ipchains (resp. iptables) tool for network filtering an appropriate rules will be as follows. Kernel 2.2.X: ipchains -I INPUT -p tcp -s 192.168.1.0/24 -d 0.0.0.0/0 25 \ -j REDIRECT 2525 Kernel2.4.X: iptables -I PREROUTING -t nat -p tcp -s 192.168.1.0/24 --dport 25 \ -j REDIRECT --to-ports 2525 Now all the communication arrives to the nod32smtp that can be checked in the module logging output.
4.3. Content Filtering in MTA Content filtering method is in the present a well known method used to screen and/or exclude certain defined information from the Internet or its part. Concerning an e-mail server system the best place to implement content filtering method is the MTA agent as an e-mail communication traffic nod. The advantage of such an implementation is that it allows one to scan e-mails inbound as well as outbound in the same implementation algorithm.
4.3.2. Content filtering in MTA Sendmail The nod32smfi module is a third-party program with the purpose to serve as a content filter for MTA Sendmail. Using Sendmail’s Milter interface the nod32smfi accesses all e-mail messages being processed by MTA Sendmail. In order to enable filtering, enter the following lines into the [smfi] section of main NOD32 configuration file. agent_enabled = yes smfi_sock_path = “/var/run/nod32smfi.sock“ In the next step, modify the ’/etc/mail/sendmail.
and place it as a first in the DIRECTORS CONFIGURATION section and you have to define special ROUTERS CONFIGURATION entry: # ROUTERS CONFIGURATION nod32_router: driver = domainlist route_list = “* localhost byname“ condition = “${if eq {$received_protocol}{virus-scanned} {0}{1}}“ transport = nod32_transport verify = false and place it as a first in the ROUTERS CONFIGURATION section.
user to nod32mda agent, the parameter ‘command‘ defined in TRANSPORTS CONFIGURATION entry must by as follows: command = /usr/bin/nod32mda -oMr virus-scanned $local_part@$domain \ -- --user $local_part resp. in case of RedHat Ready and Novell (SuSE) Ready variation of this anti-virus product used, the ’command’ parameter has to be defined as follows: command = /opt/eset/nod32/bin/nod32mda -oMr virus-scanned $local_part@$domain \ -- --user $local_part 4.3.4.
NOD32 configuration file. In case the absolute path to the exim is ‘/usr/sbin/exim‘ the parameter ‘mda_path‘ will be as follows: mda_path = “/usr/sbin/exim“ To reread the newly created NOD32 configuration, enter the following command: /etc/init.d/nod32d reload To accomplish the whole procedure, one has to restart the MTA Exim. Note that our product provides you with the option to define NOD32 scanner parameters individually for recipient users (resp. recipient domains).
To accomplish the whole procedure, one has to restart the MTA Qmail. 4.4. Alternative methods of content filtering Although mechanisms described in previous sections are concerned to be the basic mechanisms of the e-mail messages scanning, there exists yet other possibilities that are all described in this section. 4.4.1. Scanning e-mail messages using AMaViS AMaViS - A Mail Virus Scanner is a tool that interfaces your MTA and several anti-virus scanners.
@virusname = ($output =~ /virus=“([^“]+)“/g); do_virus(); } else { do_log(0,“Virus scanner failure: $nod32cli (error code: $errval)“); } } Note that the above modification provides accepting of the message only in case it was originally clean. The rest of non-error states returned by the anti-virus will be treated in a way that the message will be dropped.
### http://www.eset.com/ [’ESET Software NOD32 Command Line Interface v 2.52’, ’/opt/eset/nod32/bin/nod32cli’, ’--subdir {}’, [0], [1,2], qr/virus=“([^“]+)“/ ], Please, note the NOD32 scanning status values written within square brackets of the above setting. They are set to follow the same performance of Amavis cooperation as defined by default in the section discussing Amavis configuration. User is free to modify the above text, however, it is not recommended unless he is sure about the consequences.
NOD32 for Linux/BSD Mail Server
Chapter 5: 5 Important NOD32LMS/NOD32BMS Mechanisms Important NOD32LMS/ NOD32BMS Mechanisms
5.1. User Specific Configuration User Specific Configuration mechanism is implemented in the product in order to provide user with enhanced configuration functionality. It allows to define NOD32 anti-virus scanner parameters selectively for client/server identification. Regarding the NOD32LMS/NOD32BMS the NOD32 anti-virus scanner parameters can be defined individually for first recipient and/or sender of the e-mail messages processed.
5.2. Handle Object Policy The Handle Object Policy (see figure 5-1) is a mechanism that provides handling of the scanned objects depending on their scanning status. The mechanism is based on so-called action configuration options (’action_on_processed’, ’action_on_infected’, ‚action_on_uncleanable‘, ‚action_on_notscanned‘) combined with Anti-Virus enabling configuration option (‚av_enabled‘). To get detailed information on these configuration options, please refer to the nod32.cfg(5) manual page.
server_addr = “localhost“ server_port = 2525 In the following we provide the [smtp] section with the reference to special configuration file ’nod32smtp_spec.cfg’ where the black-list or white-list will be defined. [smtp] agent_enabled = yes listen_addr = “localhost“ listen_port = 2526 server_addr = “localhost“ server_port = 2525 user_config = “nod32smtp_spec.
accepted without scanning. Please, note the character ’|’ placed in front of the header name of the special section in case of sender address and not placed there in case of recipient address. To get description of the special header name syntax, please refer to the appropriate NOD32 agent module manual page (in this case it is nod32smtp(1)). 5.4.
NOD32 for Linux/BSD Mail Server
Chapter 6: 6 NOD32 System Update and Maintenance NOD32 System Update and Maintenance
6.1. Basic concept of NOD32 system update In order to keep the anti-virus system effective, it is necessary to keep NOD32 virus signatures databse up to date. The nod32update utility has been developed for this purpose. To get details on the operation of the utility, read the nod32update(8) manual page. Basic concept of the NOD32 system update is composed from two parts. 6.1.1.
module (nod32.005) and ThreatSense.NET support module (nod32.006) in the directory: /var/lib/nod32 resp. in RedHat Ready and Novell (SuSE) Ready variation of the product the target directory is as follows: /var/opt/eset/nod32/lib Note that the above directory is exactly the NOD32 base directory where main NOD32 daemon loads NOD32 modules from. 6.2.
NOD32 for Linux/BSD Mail Server
Chapter 7: 7 Tips and Tricks Tips and Tricks
This chapter is devoted to describe tips and tricks concerned with configuration of NOD32LMS/NOD32BMS. This means it describes configuration of NOD32LMS/NOD32BMS in circumstances when for instance MTA is configured to use other software with similar functionality or with functionality that could normally lead to misconfiguration of NOD32LMS/NOD32BMS. 7.1.
data encryption in communication between local MTA and Internet and still use the ’content filtering’ methods. In MTA Sendmail content filtering there is no problem with SMTP TLS support at all as the Sendmail Milter does not relay on the SMTP communication and content filtering is done rather internally. On the other hand the Postfix uses SMTP protocol for data communication between content filter and MTA.
NOD32 for Linux/BSD Mail Server
Chapter 8: 8 Let us know Let us know
Dear user, this guide should have given you a good knowledge about the product installation, configuration and maintenance. However, writing a documentation is a process that is never finished. There will always be some parts that can be explained better or are not even explained at all. Therefore, in case of bugs or inconsistencies found within this documentation, please report a problem to our support center http://www.nod32.com.
