ESET GATEWAY SECURITY User manual

ESET Gateway Security
Installation Manual
and User’s documentation
we protect digital worlds

2ESET Gateway Security
Table of contents
1. Introduction .........................................................................................3
2.Terminology and abbreviations..........................................................5
3. Installation............................................................................................. 9
4. Product’s Roadmap............................................................................11
5.Integration with Internet Gateway services...................................15
5.1. Transparent HTTP/FTP proxy conguration........................................16
5.2. Manual HTTP/FTP proxy conguration............................................... 17
5.2.1. Manual proxy conguration of Mozilla Firefox.............................17
5.2.2. Manual proxy conguration of Squid Web Proxy Cache............18
5.3. Large HTTP Objects Handling..................................................................19
5.3.1. Method of deferred scan....................................................................... 19
5.3.2. Partial scan technique............................................................................ 19
5.4.ESETS plug-in lter for SafeSquid Proxy Cache..................................20
5.4.1. Operation principle..................................................................................20
5.4.2. Installation and conguration..............................................................20
6. Important ESET Gateway Security mechanisms...........................23
6.1. Handle Object Policy.................................................................................. 24
6.2. User Specic Conguration..................................................................... 24
6.3. Black-list and white-list..............................................................................25
6.4. Samples Submission System................................................................... 26
6.5. World WideWeb Interface..........................................................................26
6.6. Remote Administration..............................................................................27
7. ESET Security system update...........................................................29
7.1. ESETS update utility.................................................................................... 30
7.2. ESETS update process description........................................................ 30
8. Let us know..........................................................................................31
A. ESETS setup process description.....................................................33
A.1. Setting ESETS for scanning of HTTP communication -
transparent mode................................................................................................34
A.2. Setting ESETS for scanning of FTP communication - transparent
mode.........................................................................................................................34
Appendix A. PHP License .....................................................................37
ESET Gateway Security
Copyright © 2008 ESET, spol. s r.o.
ESET Gateway Security was developed by ESET, spol. s r.o. For more
information visit www.eset.com.
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, spol. s r.o. reserves the right to change any of the described
application software without prior notice.
This product includes PHP software, freely available from http://www.
php.net/software/.
REV.20080429-005

Chapter 1:
Introduction

4ESET Gateway Security
Dear user, you have acquired ESET Gateway Security - probably the best security system
running under the Linux/BSD/Solaris OS. As you will soon nd out, the system using the state-
of-the-art ESET 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/Solaris OS server.
In the rest of this chapter we review a key features of the system.
• TheESETanti-virusscanningenginealgorithmsprovidethehighestdetectionrateand
the fastest scanning times.
• TheESETGatewaySecurityisdevelopedtorunonthesingle-processoraswellasonthe
multi-processor units.
• ItincludesuniqueadvancedheuristicsforWin32wormsandback-doors.
• Inbuiltarchiversunpackarchivedobjectswithout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.
• Allexecutivedaemons(exceptesets_dac)runundernon-privilegeduseraccountto
enhance security.
• Thesystemsupportsselectivecongurationspecicforuserorclient/serveridentication.
• Sixlogginglevelscanbeconguredtogetinformationaboutsystemactivityand
inltrations.
• Conguration,administrationandlicensemanagementcanbeprovidedusingintuitive
and user friendly World Wide Web Interface.
• ThesystemsupportsESETRemoteAdministrationformanagementinlargecomputer
networks.
• TheESETGatewaySecurity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and
other relevant events.
Toruneciently,ESETGatewaySecurityrequiresjust16MBofhard-diskspaceand32MBof
RAM. It works 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 ESET products.

Chapter 2:
Terminology
and abbreviations

6ESET Gateway Security
In the following text we review terms and abbreviations used in this documentation. Note
that in this documentation (PDF format only) a boldface font is reserved for product components
names and in this chapter also for newly dened terms and abbreviations. Note also that terms
and abbreviations dened in this chapter are emphasized later in this documentation (PDF
format only).
ESETS
ESET Security is a common acronym for all security products developed by ESET, spol. s r.o. for
Linux OS, BSD OS and Solaris. It is also the name (or its part) of the software package containing
the products.
RSR
Abbreviation of ‘RedHat/Novell(SuSE) Ready’. Note that we support also so called RedHat
Ready and Novell(SuSE) Ready variation of the product. The dierence from the “standard”
Linux version is that the RSR package meets criteria defined by FHS (File-system Hierarchy
Standard defined as a part of Linux Standard Base) document required by the RedHat Ready and
Novell(SuSE) Ready certificate. This means for instance that the RSR package is installed as an
add-on application, i.e. the primary installation directory is ‘/opt/eset/esets’.
ESETS daemon
Main ESETS system control and scanning daemon esets_daemon.
ESETS base directory
The directory where ESETS loadable modules containing for instance virus signatures database
are stored. Further in this documentation we use abbreviation @BASEDIR@ for the directory. The
directory location is as follows:
Linux: /var/lib/esets
Linux RSR: /var/opt/eset/esets/lib
FreeBSD: /var/lib/esets
NetBSD: /var/lib/esets
Solaris: /var/opt/esets/lib
ESETS configuration directory
A directory where all files related with the ESET File Security configuration are stored. Further
in this documentation we use abbreviation @ETCDIR@ for the directory. The directory location
is as follows:
Linux: /etc/esets
Linux RSR: /etc/opt/eset/esets
FreeBSD: /usr/local/etc/esets
NetBSD: /usr/pkg/etc/esets
Solaris: /etc/opt/esets
ESETS configuration file
Main ESET File Security configuration file. The absolute path of the file is as follows:
@ETCDIR@/esets.cfg
ESETS binary files directory
The directory where the relevant ESET File Security binary files are stored. Further in this
documentation we use abbreviation @BINDIR@ for the directory. The directory location is as

7
follows:
Linux: /usr/bin
Linux RSR: /opt/eset/esets/bin
FreeBSD: /usr/local/bin
NetBSD: /usr/pkg/bin
Solaris: /opt/esets/bin
ESETS system binary files directory
The directory where the relevant ESET File Security system binary files are stored. Further in
this documentation we use abbreviation @SBINDIR@ for the directory. The directory location is
as follows:
Linux: /usr/sbin
Linux RSR: /opt/eset/esets/sbin
FreeBSD: /usr/local/sbin
NetBSD: /usr/pkg/sbin
Solaris: /opt/esets/sbin
ESETS object files directory
The directory where the relevant ESET File Security object files and libraries are stored. Further
in this documentation we use abbreviation @LIBDIR@ for the directory. The directory location is
as follows:
Linux: /usr/lib/esets
Linux RSR: /opt/eset/esets/lib
FreeBSD: /usr/local/lib/esets
NetBSD: /usr/pkg/lib/esets
Solaris: /opt/esets/lib
chapter 2 Terminology and abbreviations

Chapter 3:
Installation

10
This product is distributed as a binary le:
esets.i386.ext.bin
where‘ext’isaLinux/BSD/SolarisOSdistributiondependentsux,i.e.‘deb’forDebian,‘rpm’
for RedHat and SuSE,‘tgz’for other Linux OS distributions,‘fbs5.tgz’for FreeBSD 5.xx,‘fbs6.tgz‘ for
FreeBSD 6.xx, ‘nbs4.tgz‘ for NetBSD 4.xx and‘sol10.pkg.gz‘ for Solaris 10.
Note that the Linux RSR binary le format is:
esets-rsr.i386.rpm.bin
In order to install or update the product, use statement:
sh ./esets.i386.ext.bin
resp. for Linux RSR variation of the product, use statement:
sh ./esets-rsr.i386.rpm.bin
As a result the product’s User License Acceptance Agreement is shown. Once you have
conrmed the Acceptance Agreement, the installation package is placed into the current
working directory and relevant information regarding the package’s installation, un-installation
or update is printed into terminal.
Once the package is installed and the main ESETS service is running, in Linux OS you can
check its operation by using command:
ps -C esets_daemon
In case of BSD OS you can use a command:
ps -ax | grep esets_daemon
In case of Solaris you can use a command:
ps -A | grep esets_daemon
You will see the following (or similar) message on return:
PID TTY TIME CMD
2226 ? 00:00:00 esets_daemon
2229 ? 00:00:00 esets_daemon
where at least two ESETS daemon 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 ESETS scanning process.
ESET Gateway Security

Chapter 4:
Product’s Roadmap

12 ESET Gateway Security
Once the product package has been successfully installed, it is time to become familiar with
its content.
The structure of ESET Gateway Security is shown in the gure 4-1. The system is composed of
the following components.
CORE
CoreofESETGatewaySecurityconsistsofESETSdaemonesets_daemon.Thedaemonuses
ESETSAPIlibrarylibesets.soandESETSloadingmodulesem00X_xx.dattoprovidebasesystem
tasks: scanning, maintenance of the agent daemon processes, maintenance of the samples
submissionsystem,logging,notication,etc..Pleaserefertoesets_daemon(8)manualpagefor
details.
AGENTS
The purpose of ESETS agent modules is to integrate ESETS with the Linux/BSD/Solaris Server
environment. Please note a special chapter in this document devoted to the topic.
UTILITIES
The utility modules are particular fraction of the system. They are developed to provide
simple and eective management of the system. They are responsible for relevant system tasks,
e.g. license management, quarantine management, system setup and update. 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 esets.cfg(5) manual page, an essential information source regarding ESETS conguration.
After the product is successfully installed, all its conguration components are stored in
ESETS conguration directory. The directory consists of the following les.
Figure 4-1. Structure of ESET Gateway Security.
esets_ss.so
esets_http
esets_ftp
AGENTS esets_lic
UTILITIES
esets_quar
esets_setup
esets_update
scanning
engine
CORE
system
service
esets.cfg
license
scripts
WWW INTERFACE
CONFIGURATION

13
@ETCDIR@/esets.cfg
This is the most important conguration le as it maintains the major part of the product
functionality. 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 ESETS 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 ESETS daemon as well as
default values of ESETS scanning engine conguration options. Parameters in agent sections are
used to dene conguration options of so-called agents, i.e. modules used to intercept various
data ow types in the computer and/or its neighborhood and prepare this data for scanning.
Note that besides the number of parameters used for the system conguration, there is also a
number of rules determining organization of the le. To become familiar with this knowledge,
pleaserefertoesets.cfg(5),esets_daemon(8)manualpageandalsotomanualpagesrelatedto
relevant agents.
@ETCDIR@/certs
This directory is used to store the certicates used byESETS WWW Interface for authentication
(seeesets_wwwi(8)fordetails).
@ETCDIR@/license
This directory is used to store the product(s) license key(s) you have acquired from your
vendor. Note that the ESETS daemon will always check only this directory to evaluate license key
validityunlessitisredenedbyESETScongurationleparameter‘license_dir‘.
@ETCDIR@/scripts/license_warning_script
This script, if enabled by ESETS 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.
@ETCDIR@/scripts/daemon_notication_script
Thisscript,ifenabledbyESETS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.
chapter 4 Product’s Roadmap

Chapter 5:
Integration with Internet
Gateway services

16 ESET Gateway Security
The ESET Gateway Security protects organization’s HTTP and FTP services against viruses,
worms, trojans, spyware, phishing and other internet threats on the level of Internet Gateway
Servers. Note that under the term Gateway Servers we understand layer-3 Gateways of ISO/OSI
model, i.e. routers. In this chapter we review the process of the product integration with the
services introduced.
5.1. Transparent HTTP/FTP proxy conguration
Conguration for transparent proxying is based on standard routing mechanism shown in
the following gure.
Figure 5-1. Scheme of ESET Gateway Security as a transparent proxy.
The conguration is created naturally as kernel IP routing tables are dened on each local
network client. These routing tables are used to set-up static routes to the default network
gateway server (router). Note that it is done automatically in case of the DHCP network. Using
this mechanism all the HTTP (resp. FTP) communication with the outbound servers is routed
via network gateway server where ESET Gateway Security must be installed in order to scan the
communication for inltrations. For this purpose, a generic ESETS HTTP (resp. FTP) lter - esets_
http (resp. esets_ftp) has been developed.
In order to congure ESET Gateway Security for scanning of HTTP (resp. FTP) messages routed
through the network gateway server, enter the command:
esets_setup
Follow instructions provided by the script. Once ‘Available installations/un-installations’ oer
appears, choose ‘HTTP’ (resp. FTP) option that will provide you with the appropriate module
‘install/uninstall’options. Choose the one called‘install’. This will automatically set-up the module
to listen to predened port and redirect IP packets originating from the selected network and
with HTTP (resp. FTP) destination port to the port where esets_http (resp. esets_ftp) listens. This
means that only requests originally sent to HTTP (resp. FTP) destination port will by scanned. If
other ports are under interest, an equivalent redirection rules have to be assigned.
Note that the installer in default mode shows all steps it is going to perform and provide also
the backup of the conguration that may be restored later at any time.The detailed installer utility
steps for all possible scenarios are described also in the appendix A of this documentation.
Client
User Agent
Client
Router
Local Network
User Agent
INTERNET
User Agent
Eset Gateway Security
Client

17
5.2. Manual HTTP/FTP proxy conguration
The manual proxy conguration (see gure 5-2) is characteristic by explicit specifying of
parent proxy listen address and port in the conguration of proxied user agent.
Figure 5-2. Scheme of ESET Gateway Security as a manual proxy.
The proxy server in this case usually modies requests and/or responses transferred, i.e. works
in the non-transparent mode. The manual proxying support of esets_http has been tested with
the wide range of most common user agents, i.e. proxy caches (Squid Proxy Cache, SafeSquid),
client browsers (Mozilla Firefox, Opera, Netscape, Konqueror). In general every HTTP user agent
supporting manual parent proxy settings will cooperate with esets_http module. In the next we
describe manual proxy conguration setting of esets_http with Mozilla Firefox and with Squid
Web Proxy Cache that are one of the most common HTTP user agent applications.
5.2.1. Manual proxy conguration of Mozilla Firefox
The manual HTTP/FTP proxy conguration of esets_http with the Mozilla Firefox is described
in general by the left side of the gure 4-2.
Note that this conguration allows to install ESET Gateway Security anywhere within the local
network including gateway server and also user agent’s computer.
In this example we congure esets_http to listen to port 8080 of the computer with local
network IP address 192.168.1.10 by specifying the following parameters within [http] section of
main ESETS conguration le:
agent_enabled = yes
listen_addr = ”192.168.1.10”
listen_port = 8080
Notethattheparameter‘listen_addr’canbespeciedalsoasthehostnamevisiblefromthe
local network.
In order to set up Mozilla to use esets_http one has to select the ‘Edit’ menu from the menu
bar and from there ‘Preferences’ (in older versions of Mozilla one has to select ‘Tools’ menu and
from there‘Options’).Then click on‘Connection settings’found under‘General’settings and select
chapter 5 Integration with Internet Gateway services
Client
User Agent User Agent User Agent
ClientClient
Gateway
Local Network
Eset Gateway security
INTERNET
Proxy Cache

18 ESET Gateway Security
‘Manual Proxy Conguration’. In the last step, one has to ll up the elds ‘HTTP Proxy’ (resp. ‘FTP
Proxy’) with the host name (resp. IP address) and related ‘Port’ elds with the port where esets_
http listens to (in this example an IP address ‘192.168.1.10’ and port 8080 shall be specied). For
reread of newly created conguration, reload ESETS daemon.
It is good to note that the conguration described here is not very suitable for networks with
higher number of client’s computers. The reason is that in this case the HTTP cache (if any) is
present only in user agent and thus the same source object is scanned multiple times when
requested from dierent user agents.
5.2.2. Manual proxy conguration of Squid Web Proxy Cache
The manual HTTP proxy conguration of esets_http with the Squid Web Proxy Cache is
described in general by the right side of the gure 4-2.
The signicant dierence from the previously described conguration is that the ESET
Gateway Security is installed in HTTP/FTP Gateway between proxy cache (Squid Web Proxy in
this example) and the Internet. Thus all the HTTP/FTP responses incoming to the network are
rst scanned for inltrations and afterward stored in the network dedicated cache, i.e. all once
requested source objects present within a proxy cache are already checked for viruses and no
additional check is necessary when requested again.
In this example we congure esets_http to listen to port 8080 of the gateway server with
local network IP address 192.168.1.10 by specifying the following parameters within [http]
section of ESETS conguration le:
agent_enabled = yes
listen_addr = ”192.168.1.10”
listen_port = 8080
Notethattheparameter‘listen_addr’canbespeciedeitherasthehostnamevisiblefromthe
local network or one may also use 0.0.0.0 address to let esets_http listen to all interfaces. In the
later case one has to be careful as also users outside the local network are allowed to use HTTP/
FTP scanner unless further security steps are provided to prevent from it.
In order to set up Squid to use esets_http as parent proxy one has to add the following lines
into the Squid conguration le (/etc/squid/squid.conf):
cache_peer 192.168.1.10 parent 8080 0 no-query default
acl all src 0.0.0.0/0.0.0.0
never_direct allow all
In the lines above we have set up the Squid to use http proxy listening on IP address
192.168.1.10 at port 8080 as a parent proxy. All requests processed by Squid will be thus passed
to this destination. The rest of the lines dene behavior of Squid to report error message in case
the parent proxy is down or becomes unreachable. There is an alternative way to set up Squid in
order to try direct connections when the parent proxy is unreachable. In this case the parameters
to add into Squid conguration le are as follows:
cache_peer 192.168.1.10 parent 8080 0 no-query
prefer_direct off
For reread of newly created conguration, reload ESETS daemon.

19
5.3. Large HTTP Objects Handling
Under the normal conditions esets_http handles every object transferred in a way that the
object is rst transferred from the HTTP server (resp. client) to esets_http, second, it is scanned
for inltration and last, it is transferred to the HTTP client (resp. server). Concerning large les (the
largeobjectswhosetransfertimeislargerthantimeoutdenedbytheparameterlo_timeout)
this becomes not very suitable scenario as the user agent’s timeout or user’s impatience can
cause interrupts or even canceling of the objects transfer. Therefore other methods to process
the large objects must be implemented.
5.3.1. Method of deferred scan
The esets_http implements standard so-called ‘deferred scan’ method of large les handling.
This means if object transferred becomes large the esets_http starts to send the object
transparently to an awaiting HTTP end-point (i.e. client or server). After the last part of the object
has arrived to esets_http, the object is scanned for inltrations. If the object has been found as
infected the last part of the object (current version of ESET Gateway Security denes last part as
last 4KB of object’s data) is not sent to the awaiting end-point and the connection with the end-
point is dropped. In parallel, the e-mail notication is sent to the Gateway administrator with
the relevant information about the dangerous le transfer. Note that the notication is sent only
in case of server to client data transfer. The URL of the source object is stored in this case in the
esets_http cache to block the source transfer if requested again.
In this place we would like to point out that the ‘deferred scan’ technique described above
presents potential risk for the computer whose user agent requested the infected large le for
the rst time. The risk resists in that even data transfer of an infected object has been deferred
some parts of already transferred data can contain executable danger code. That is why the ESET
developed modication of the‘deferred scan’ technique called ‘partial scan’ technique.
5.3.2. Partial scan technique
The ‘partial scan’ technique has been developed to safeguard ‘deferred scan’ method.
Operation principle of the ‘partial scan’ technique is based on the idea that scanning time of
a large object is negligible as compared to overall process time of the object. Note that this
condition is fullled in case of HTTP transfer of large object as signicantly higher time is needed
to transfer the object than to scan it for inltrations. This assumption allows us to perform more
than only one scan during the large object transfer.
Once parameter lo_partscan_enabled is enabled in [http] section of ESETS conguration
le the large object is scanned for inltrations during its transfer in some predened intervals and
data scanned are sent to awaiting end-point (i.e. to client or to server). Using this method there
is no way to pass any inltration to the computer whose user agent has requested the large
infected object as each portion of the data sent is already ensured to be secure.
It has been proved that in the common circumstances (by means the speed of the Gateway
local network connection is orderly higher than the speed of the Gateway connection to the
Internet) the process time of the large object transfer with the ‘partial scan’ technique used is
approximately the same as when the standard‘deferred scan’ method used.
chapter 5 Integration with Internet Gateway services

20 ESET Gateway Security
5.4. ESETS plug-in lter for SafeSquid Proxy Cache
In the previous sections we have described integration of ESET Gateway Security with the
Internet Gateway HTTP and FTP services using esets_http and esets_ftp. Although the methods
described are applicable for most common user agents including very well known content
ltering internet proxy - SafeSquid (http://www.safesquid.com) the ESET Gateway Security oers
for this special case also an alternative way to protect the Gateway services using esets_ss.so
module developed for this purpose.
5.4.1. Operation principle
The esets_ss.so module is a plug-in with the purpose to access all objects processed by
SafeSquid proxy cache using special interface developed by SafeSquid people for this purpose.
Once the plug-in accesses the object it is scanned for inltrations using ESETS daemon. If the
object is infected the SafeSquid blocks an appropriate resource and sends predened template
page instead. Note that esets_ss.so is supported by SafeSquid Advanced version 4.0.4.2 and
higher.
5.4.2. Installation and conguration
To integrate the module you have to provide links from the SafeSquid modules directory to
the appropriate installation locations of ESET Gateway Security package. In the following we
assume that the SafeSquid is installed on Linux OS in ‘/opt/safesquid‘ directory.
If version of SafeSquid installed is 4.2 or higher, enter the following commands:
ln -s @LIBDIR@/ss/esets_ss.so /opt/safesquid/modules/esets_ss.so
ln -s @LIBDIR@/ss/esets_ss.xml /opt/safesquid/modules/esets_ss.xml
If version of Safesquid installed is lower than 4.2, enter the following commands:
ln -s @LIBDIR@/ss/esets_ss.so /opt/safesquid/modules/esets_ss.gcc295.so
ln -s @LIBDIR@/ss/esets_ss.xml /opt/safesquid/modules/esets_ss.xml
To complete SafeSquid plug-in installation, log in to the SafeSquid Web Administration
Interface, select the ‘Cong‘ menu from the main interface page and browse down the sections
in ‘Select a Section to Congure‘ until ‘ESET Gateway Security‘ section found. Next, create the
‘antivirus‘ prole for the ‘ESET Gateway Security‘ section by pressing ‘Add‘ at the bottom of the
‘ESET Gateway Security‘ section and dene the following parameters in the list that appears
Comment: ESET Gateway Security
Proles: antivirus
Once SafeSquid plug-in installed it is ready to work, however, some more ne tunings in
the SafeSquid conguration are needed. In the next we at least congure SafeSquid to use
ESETS predened blocking templates in case the transferred source object is infected (resp. not
scanned).
Log in to the SafeSquid Web Administration Interface, select the ‘Cong‘ menu from the
main interface page and browse down the sections in ‘Select a Section to Congure‘ until ‘ESET
Gateway Security‘ section found. Next, edit the newly created‘antivirus‘ prole by pressing ‘Edit‘
at the bottom of the ‘ESET Gateway Security‘ section and dene the following parameters in the
list that appears