Installation manual

14
predefined port and reload the ESETS daemon service.
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.