Eset NOD32 INSTALLATION

w e p r o t e c t d i g i t a l w o r l d s
NOD32 for Linux/BSD File Server
Installation Manual and User’s documentation
NOD3 2 for Linux/B SD Fil e Ser ver, First Editi on Publ ished on 6th Decemb er 200 6 Copyr ight © 2006 E set, s. r.o.
NOD3 2 for Linux/B SD Fil e Ser ver was develo ped by Eset , s.r.o. Fo r more informa tion v isit w ww.eset. com. All rights reser ved. No part of thi s docu mentati on may be repro duced, stored in a re trieva l syste m or tran smitted in an y form or by any mea ns, ele ctroni c, mech anical, photo copying, record ing, sc anning, or othe rwise witho ut a pe rmissi on in writin g from the auth or. Eset, s.r.o. res erves the ri ght to change any of t he des cribed applic ation softwa re with out pr ior noti ce.
Eset , spol. s r. o. Svora dova 1, 811 0 3 Brati slava, Slovak Republ ic
http ://ww w.eset.s k/en
Table of contents
1. Introduction ........................................................... 3
2. Installation .............................................................. 5
3. Product’s Roadmap .................................................. 7
4. Integration with Linux/BSD File System ....................11
5. Important NOD32LFS/NOD32BFSMechanisms ............19
6. NOD32 system update and maintenance ...................23
2
NOD32 for Li nux/BSD File Ser ver
Chapter 1:
Introduction
1 Intro duction
Dear user, you have acquired NOD32 for Linux/BSD File Server - NOD32LFS/NOD32BFS - probably the best anti­virus system running under the Linux/BSD OS. As you will soon nd out, the system using, the state-of-the -artNOD32 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.
NOD32 scanning engine algorithms provide both the highest detection rate and the fastest scanning times.
The system is developed to run on the single-processor units as well as on themulti-processor units.
It includes unique advanced heuristics for Win32 worms and back-doors.
InbuiltNOD32 archivers unpack archived objectswithout the need for any external programs.
In order to increase speed and eciency of the system, its architecture is based on the running daemon (resident
program) where all the scanning requests are sent to.
The system supports selective scanner conguration specic for user or client/server identication.
Six various levels of logging can be congured to get information about system activity and inltrations.
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 congured to notify any person in case of detected inltration. To run eciently, the system
requires just 16MB of hard-disk space and 32MB of RAM. The system runs smoothly under the 2.2.x, 2.4.x and 2.6.x
Linux OS kernel versions and also under 5.x, 6.x FreeBSD OS kernel versions.
From lower-powered, small oce servers to enterprise-class ISP servers with thousands of users, the system delivers the performance and scalability you expect from a UNIX based solution and the unequaled security of NOD32.
4
NOD32 for Li nux/BSD File Ser ver
Chapter 2:
Installation
2 Installa tion
This product is distributed as a binary le. Its format for Linux OS is:
nod32ls.i386.ext.bin
where ’ext’ is a Linux OS distribution dependent sux, 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 product1 The RedHat and Novell (SuSE) Ready variation of the binary le format is:
nod32ls-rsr.i386.rpm.bin
Slightly dierent format is used to name the binary le for BSD OS,
nod32bs.i386.ext.tgz.bin
where ’ext’ stands for BSD OS distribution dependent sux, i.e. ’fbs4’ for FreeBSD 4.xx, ’fbs5’ for FreeBSD 5.xx and ’fbs6’ for FreeBSD 6.xx OS distributions.
In order to install or update the product on Linux OS, use the statement:
sh ./nod32ls.i386.ext.bin
resp. the RedHat Ready or Novell (SuSE) Ready variation of the product is installed using the following statement:
sh ./nod32ls-rsr.i386.rpm.bin
In case of BSD OS, the install statement is as follows.
sh ./nod32bs.i386.ext.tgz.bin
As a result the User License Acceptance Agreement related with the product is shown. Once you have conrmed the Acceptance Agreement, the whole installation package is extracted into the current working directory and relevant information regarding installation or update of the package extracted as well as information necessary for uninstall the already installed package is printed into terminal.
Once the package is installed and the main NOD32 daemon service is running, in Linux OS you can check its operation by using command:
ps -C nod32d
In case of BSD OS you can use a similar command:
ps -ax nod32d | grep nod32d
You will see the following (or similar) message on return:
PID TTY TIME CMD
2226 ? 00:00:00 nod32d
2229 ? 00:00:00 nod32d
where at least two main NOD32 daemon ’nod32d’ processes running in the background have to be present. One of the processes is so-called process and threads manager of the system. The other serves as NOD32 scanning process.
 The dierence from the original RedHat and SuSE Linux OS package is that the RedHat Ready and Novell SuSE Ready package
meets criteria dened by FHS Filesystem Hierarchy Standard dened as a part of Linux Standard Base document required by the RedHat Ready and Novell SuSE Ready certicate This means in particular that the package is installed as an addon application ie the primary installation directory is ’⁄opt⁄eset⁄nod’ instead of the base Linux OS directory structure However there are more dierences between the original and ’Ready’ variation of the product that are beyond the scope of this document
6
NOD32 for Li nux/BSD File Ser ver
Chapter 3:
Product’s Roadmap
3 Produ ct’s Roadma p
Once the product package has been successfully installed, it is time to become familiar with its content.
The struc ture of the NOD32LFS/NOD32BFS is shown in the gure 3-1. The system is composed of the following components.
Figure 3-1. Structure of NOD32LFS/NOD32BFS.
AGENTS
nod32dac
libnod32pac.so
nod32
CORE
nod32d libnod32.so nod32.00X
CONFIGURATION
nod32.cfg
license
scripts
templates
extern
UPDATE
nod32_update
nod32update
CORE
Core of the NOD32LFS/NOD32BFS consists of main NOD32 system control and scanning daemon module nod32d. The daemon uses NOD32 API library libnod32.so and NOD32 loading modules nod32.00X to provide essential system tasks: anti-virus scanning, maintenance of the agent daemon processes, maintenance of the samples submission system, logging, notication, etc.. To get detailed information on the main NOD32 system control and scanning daemon, refer to nod32d(8) manual page.
AGENTS
The purpose of NOD32 agent modules is to integrate the NOD32LFS/NOD32BFS with the Linux/BSD le system environment. Please note a special chapter in this document devoted to the topic.
UPDATE
The update utilities create a particular fraction of the system. They are built with only one purpose, i.e. update of NOD32 loading modules containing for instance virus signatures database, archives support, advanced heuristics support etc. Please note a special chapter in this document devoted to the topic.
CONFIGURATION
Proper conguration is the most important condition for the system operation. Therefore we describe all the related components in the rest of this chapter. We also strongly recommend to read nod32.cfg(5) manual page, an essential information source regarding NOD32LMS/NOD32BMS conguration.
After the product package is successfully installed, all the components related to its conguration and authorization are stored in directory
/etc/nod32
8
NOD32 for Li nux/BSD File Ser ver
Note that in case of RedHat Ready and Novell (SuSE) Ready variation of the NOD32 for Linux Mail Server the conguration and authorization directory is
/etc/opt/eset/nod32
The directory consists of the following les.
nod32.cfg
This is the most important conguration le as it maintains the major part of the product functionality. For this reason the le is further referred to as ‘main conguration le‘ or ‘main NOD32 conguration le‘. After exploring the le you can see that it is built from various parameters distributed within sections. Note the section names always enclosed in square brackets. In the main conguration le there is always one global and several so-called agent sections. Parameters in global section are used to dene conguration options of main NOD32 daemon ‘nod32d‘ as well as default values of NOD32 scanning engine conguration options. Parameters in agent sections are used to dene conguration options of so-c alled agents, i.e. modules used to intercept various data ow types in the computer and/ or its neighborhood and prepare this data for anti-virus scanning. Note that besides the number of parameters used for the system conguration, there is also a number of rules determining organization of conguration le. To become familiar with this knowledge. please refer to nod32.c fg(5), nod32d(8) manual page and also to manual pages related to relevant agents.
license
This directory is used to store the product license key you have acquired fromyour vendor. Note that the main NOD32 daemon will always check only this directory to evaluate license key validity unless it is redened by the main conguration le parameter ’nod32_lic_dir’.
scripts/nod32d_license_warning_script
This script, if enabled by main conguration le parameter ’license_warn_enabled’, is executed since 30 days (once per day) before product license expiration. It is used to send e-mail notication about the expiration status to system administrator.
scripts/nod32d_script
This script, if enabled by main conguration le parameter ’exec_script’, is executed in case the inltration has been detected by the anti-virus system. It is used to send e-mail notication about the event to system administrator.
chapt er 3 / Product ’s Roadmap
9
Loading...
+ 19 hidden pages