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.