6. Integration with Internet Gateway services
ESET Gateway Security protects the organization’s HTTP and FTP services against viruses, worms, trojans, spyware, phishing and other internet threats. The term Gateway Server refers to layer 3, or the ‘router’ level of the ISO/OSI model. In this chapter, we review the process of integrating ESET Gateway Security with various services.
6.1 Transparent HTTP/FTP proxy configuration
The configuration for transparent proxying is based on a standard routing mechanism as shown in Figure 5-1 below:
Figure 5-1. Scheme of ESET Gateway Security as a transparent proxy
The configuration is created naturally as kernel IP routing tables are defined on each local network client. These routing tables are used to establish static routes to the default network gateway server (router). On a DHCP network, this is done automatically.
All HTTP (or FTP) communication with outbound servers is then routed via network gateway server, where ESET Gateway Security must be installed in order to scan the communication for infiltrations. For this purpose, a generic ESETS HTTP (or FTP) filter has been developed, called esets_http (or esets_ftp).
To configure ESET Gateway Security to scan HTTP (or FTP) messages routed through the network gateway server, enter the command:
@SBINDIR@/esets_setup
Follow the instructions provided by the script. When the ‘Available installations/un-installations’ offer appears, choose the
‘HTTP’ (or FTP) option to display the ‘install/uninstall’ options, then choose ‘install’. This will automatically configure the module to listen on a predefined port. It also redirects IP packets originating from the selected network and with HTTP (or FTP) destination port to the port where esets_http (or esets_ftp) listens. This means that only requests originally sent to HTTP (or FTP) destination ports will be scanned. If you also wish to monitor other ports, equivalent redirection rules must be assigned.
In default mode, the installer shows all steps which will be performed and also creates a backup of the configuration, which can be restored at any time. The detailed installer utility steps for all possible scenarios are also described in
appendix A of this
document.
11
6.2 Manual HTTP/FTP proxy configuration
The manual proxy configuration (see Figure 5-2) is characterized by explicitly configuring the proxied user agent to listen on a specific port and address of the parent proxy.
Figure 5-2. Scheme of ESET Gateway Security as a manual proxy
With this configuration, the proxy server usually modifies transferred requests and/or responses, i.e., non-transparent mode. The manual proxying functionality of esets_http has been tested with a wide range of common user agents (i.e., proxy caches) such as
Squid Proxy Cache and SafeSquid, as well as web browsers such as Mozilla Firefox, Opera, Netscape, and Konqueror. In general, any HTTP user agent which supports manual parent proxy settings will cooperate with the esets_http module. In the next section, we describe the manual proxy configuration setting of esets_http with Mozilla Firefox and Squid Web Proxy Cache, as these are the most common HTTP user agent applications.
6.2.1 Manual proxy configuration of Mozilla Firefox
The manual HTTP/FTP proxy configuration of esets_http with Mozilla Firefox is illustrated in Figure 5-2.
This configuration allows ESET Gateway Security to be installed anywhere within the local network, including the gateway server and the user agent’s computer.
In the example below, esets_http is configured to listen on port 8080 of a computer with local network IP address 192.168.1.10, by specifying the following parameters in the [http] section of the ESETS configuration file: agent_enabled = yes listen_addr = "192.168.1.10" listen_port = 8080
The parameter ‘listen_addr’ can also be the host name which is visible from the local network.
To configure
Firefox
to use esets_http, click Tools > Options from the main menu, and click Advanced. Click the Network tab and then click the Settings... button. In the Connection Settings window, select the Manual Proxy Configuration option. Finally, enter the host name or IP address in the HTTP Proxy (or FTP Proxy) field, and enter the Port values which esets_http listens on (in this example, IP address 192.168.1.10 and port 8080 shall be specified). To reread the newly created configuration, reload the ESETS daemon.
It should be noted that the configuration described here is not optimal for networks with a large number of client computers. This is because the HTTP cache (if any) is present only in the user agent - thus, the same source object is scanned multiple times when requested from different user agents.
6.2.2 Manual proxy configuration of Squid
The manual HTTP proxy configuration of esets_http with Squid is illustrated in the right hand side of Figure 5-2.
The significant difference from the previously described configuration is that ESET Gateway Security is installed on the HTTP/FTP
Gateway between the proxy cache (Squid in this example) and the Internet. All inbound HTTP/FTP communications are first scanned for infiltrations and then stored in the dedicated network cache. In other words, all previously requested source objects present within the proxy cache are already checked for viruses and no additional checking is necessary when requested again.
12
In the following example, esets_http is configured to listen on port 8080 of the gateway server, with a local network IP address of
192.168.1.10, by specifying the following parameters in the [http] section of the ESETS configuration file: agent_enabled = yes listen_addr = ”192.168.1.10” listen_port = 8080
Note that the parameter ‘listen_addr’ can be used to specify the host name visible from the local network and also can be used to allow esets_http to listen to all interfaces, by entering an address of 0.0.0.0. Use caution in the latter case, as users outside the local network would be allowed to use the HTTP/FTP scanner unless additional security is added to prevent this.
To set up Squid to use esets_http as a parent proxy, add the following lines to the Squid configuration file (/etc/squid/squid.conf): cache_peer 192.168.1.10 parent 8080 0 no-query default acl all src all never_direct allow all
If an earlier version (2.x) is installed, add the following lines to the Squid configuration file: 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 example above, Squid has been configured to use HTTP proxy listening at IP address 192.168.1.10 on port 8080 as a parent proxy. All requests processed by Squid will be passed to this destination. The remaining lines are used to configure error message reporting in the event that the parent proxy is down or becomes unreachable. To configure Squid to attempt direct connections when the parent proxy is unreachable, add the following parameters to the Squid configuration file: cache_peer 192.168.1.10 parent 8080 0 no-query prefer_direct off
To reread the newly created configuration, reload the ESETS daemon.
6.3 Internet Content Adaptation configuration
The Internet Content Adaptation is a well known method aimed at providing object-based content vectoring for HTTP services. It is based on the Internet Content Adaptation Protocol (ICAP) described in the RFC-3507 memo. Configuration for integrating the ICAP services is shown in Figure 5-3:
Figure 5-3. Scheme of ESET Gateway Security as a ICAP server.
The Proxy Cache receives the HTTP request from the User Agent and/or the response from the HTTP server and then encapsulates the message into the ICAP request. The Proxy Cache must also work in this case as the ICAP client and pass the ICAP request for the message adaptation to ESET Gateway Security, namely to a generic ESETS ICAP server - esets_icap. The module provides scanning of the encapsulated message body for infiltration. Based on the scanning result, it then provides an appropriate ICAP response which is sent back to the ICAP client, or to the Proxy Cache, for further delivery.
To configure ESET Gateway Security to scan HTTP messages which are encapsulated in ICAP requests, enter the command:
@SBINDIR@/esets_setup
Follow the instructions provided by the script. When the ‘Available installations/un-installations’ offer appears, choose the
‘ICAP’ option to display the ‘install/uninstall’ options. Choose ‘install’ to automatically configure the module to listen on a predefined port and reload the ESETS daemon service.
13
In default mode, the installer shows all steps which will be performed and also creates a backup of the configuration, which can be restored later at any time. The detailed installer utility steps for all possible scenarios are also described
in appendix A of
this documentation.
The second step of the ICAP configuration method is activating the ICAP client functionality within the Proxy Cache. The ICAP client must be configured in order to properly request the esets_icap for the infiltration scanning service. The initial request line of the ICAP request must be entered as follows:
METHOD icap://server/av_scan ICAP/1.0
or
METHOD icap://server/avscan ICAP/1.0
In the above example, METHOD is the ICAP method used, ‘server’ is the server name (or IP address), and /av_scan or /avscan is the esets_icap infiltrations scanning service identifier.
6.4 Long Transfer Handling
Under normal conditions, objects are first transferred from the HTTP server (or client) to esets_http, scanned for infiltrations and then transferred to the HTTP client (or server). For long transfers (longer than time defined by the parameter ‘transfer_delay’) this is not an optimal scenario - the user agent’s timeout setting or the user’s impatience can cause interrupts or even canceling of the object transfer. Therefore, other methods of processing must be implemented. These are described in the following two sections.
Method of deferred scan
With esets_http, a technique known as the deferred scan method of handling long transfers can be employed. This means if the transfer is too long, esets_http will begin to send the object transparently to an awaiting HTTP end-point, such as a client or server. After the last part of the object has arrived, the object is scanned for infiltrations. If the object has been found as infected, the last part of the object (last 4KB of object’s data) is not sent to the awaiting end-point and the connection to the end-point is then dropped. Meanwhile, an email message containing details about the dangerous file transfer is sent to the Gateway administrator. This email notification is sent only in a server-to-client data transfer. Additionally, the URL of the source object is stored in the esets_http cache in order to block the source transfer if requested again.
Be aware that the deferred scan technique described above presents a potential risk to the computer requesting the infected file for the first time. This is because some parts of the already transferred data can contain executable, dangerous code. For this reason, ESET developed a modified version of the deferred scan technique, known as the ‘intermediate scan’.
Intermediate scan technique
The intermediate scan technique has been developed as an additional safeguard to the deferred scan method. The principle of the
intermediate scan technique is based on the idea that the scanning time of a transfer is negligible compared to the overall processing time of the object. This concept is especially evident with long HTTP transfers, as significantly more time is needed to transfer the object than to scan it for infiltrations. This assumption allows us to perform more than one scan during an object transfer.
To enable this technique, the parameter ‘lt_intermediate_scan_enabled’ is entered in the [http] section of the ESETS configuration file. This will cause objects to be scanned for infiltrations during transfer in predefined intervals, while the data which has already been scanned is sent to an awaiting end-point such as a client or server. This method ensures that no infiltrations are passed to the computer whose user agent has requested the transfer, because each portion of the sent data is already verified to be safe.
It has been proven that in common circumstances where the speed of the gateway’s local network connection is higher than the speed of the gateway connection to the Internet, the total processing time of a long transfer using the intermediate scan technique is approximately the same as when the standard deferred scan method is used.
6.5 ESETS plug-in filter for SafeSquid Proxy Cache
In previous sections, we described the integration of ESET Gateway Security with HTTP and FTP services using esets_http and
esets_ftp. The methods described are applicable for the most common user agents, including the well known content filtering internet proxy SafeSquid.
http://www.safesquid.com
However, ESET Gateway Security also offers an alternative method of protecting Gateway services using the esets_ssfi.so module.
14
6.5.1 Operation principle
The esets_ssfi.so module is a plug-in to access all objects processed by the SafeSquid proxy cache. Once the plug-in accesses the object, it is scanned for infiltrations using the ESETS daemon. If the object is infected, SafeSquid blocks the appropriate resource and sends the predefined template page instead. The esets_ssfi.so module is supported by SafeSquid Advanced version 4.0.4.2 and later. Please refer to the esets_ssfi.so(1) man pages for more information.
6.5.2 Installation and configuration
To integrate the module, you must create links from the SafeSquid modules directory to the appropriate installation locations of the ESET Gateway Security package. In the following examples, it is assumed that SafeSquid is installed on a Linux OS in the ‘/opt/ safesquid’ directory.
mkdir /opt/safesquid/modules ln -s @LIBDIR@/ssfi/esets_ssfi.so /opt/safesquid/modules/esets_ssfi.so
ln -s @LIBDIR@/ssfi/esets_ssfi.xml /opt/safesquid/modules/esets_ssfi.xml
/etc/init.d/safesquid restart
To complete the SafeSquid plug-in installation, first logon to the SafeSquid Web Administration Interface. Select the Config menu from the main interface page and browse Select a Section to Configure until you find ESET Gateway Security. Click Submit and create the antivirus profile for the ESET Gateway Security section by clicking the Add button at the bottom. Define the below parameters within the list that appears and click Submit. Remember to save the Safesquid configuration by clicking the Save
settings button.
Comment: ESET Gateway Security
Profiles: antivirus
The SafeSquid plug-in is operational immediately after installation, but additional fine tuning should be performed. In the following paragraphs, we explain how to configure SafeSquid to use ESETS predefined blocking templates, in the event that a transferred source object is infected (or not scanned).
Logon to the SafeSquid Web Administration Interface. Select the Config menu from the main interface page and browse Select a
Section to Configure until you find ESET Gateway Security. Next, edit the newly created antivirus profile by clicking Edit at the bottom of the ESET Gateway Security section. Then define the following parameters in the list that appears:
Infected template: esets_infected
Not scanned template: esets_not_scanned
After submitting the list of templates, navigate to the Templates page of the main Config menu. You will see a Path parameter that defines the SafeSquid templates directory path. Assuming the parameter is ‘/opt/safesquid/safesquid/templates’, ensure that an appropriate directory exists and if not, create it. In order to access the ESETS predefined templates from within this directory, add the appropriate links using the following commands: ln -s @LIBDIR@/ssfi/templates/ssfi_infected.html \
/opt/safesquid/safesquid/templates/ssfi_infected.html
ln -s @LIBDIR@/ssfi/templates/ssfi_not_scanned.html \
/opt/safesquid/safesquid/templates/ssfi_not_scanned.html
Next, click Add in the Templates section to add the new template definitions to the SafeSquid configuration. The following parameters must be defined within the list that appears for the infected ESETS blocking page:
Comment: ESET Gateway Security infected template
Name: esets_infected
File: ssfi_infected.html
Mime type: text/html
Response code: 200
Type: File
Parsable: Yes
For the unscanned ESETS blocking page, the list is as follows:
Comment: ESET Gateway Security not scanned template
Name: esets_not_scanned
File: ssfi_not_scanned.html
Mime type: text/html
Response code: 200
Type: File
Parsable: Yes
To reread the newly created configuration, reload SafeSquid and the ESETS daemon.
15
