Integration with Squid Proxy Server

To integrate Dr.Web ICAPD with a Squid HTTP proxy server, you will need to review the current values of parameters in the Dr.Web ICAPD‘s settings section (the [ICAPD] section) and change them if necessary:

•In the ListenAddress parameter, specify the address of the network socket (<IP address>:<port>) which will be listened to by Dr.Web ICAPD waiting for connections from an HTTP proxy server (by default, the 127.0.0.1:1344 socket is used).

•In Block* parameters, enable or disable blocking of the respective website categories and threat types by Dr.Web ICAPD.

•If required, you can use the WhiteList and BlackList parameters to define the websites that must not be blocked and the websites that must be blocked. Note that the BlackList parameter has higher priority than the WhiteList parameter, that is, if the same website is included in the values of both parameters, access to this website will be blocked.

•To configure access to websites in a more fine-grained way (on the basis of various conditions), you can also edit the scanning rules.

The default values of the UsePreview, Use204 and AllowEarlyResponse parameters in the Dr.Web ICAPD’s section of the settings allow the component to use the corresponding features of the Internet Content Adaptation Protocol (ICAP) (i.e. allow it to use the ICAP preview mode, to return the 204 status code not only in the ICAP preview mode, and to start sending an “early” response before the entire request has been received from the proxy server). It is recommended that you do not change the default values if no problems with HTTP request processing occur.

After all settings are adjusted, restart Dr.Web for UNIX Internet Gateways (use the command drweb-ctl reload). You can also restart the configuration daemon Dr.Web ConfigD (use the service drweb-configd restart command).

To enable interaction between Squid and Dr.Web ICAPD, edit the squid.conf configuration file (usually located in /etc/squid3/) to allow using ICAP. To configure Squid, set the following parameters:

4.Allowing to transfer clients’ data (i.e. the IP address and the user name of a user who has passed authentication at the proxy server) to use it inside the rules of Dr.Web ICAPD (optionally).

5.Enabling the support of constant connections between Dr.Web ICAPD and Squid (optional; using constant connections is not obligatory, but this increases the performance of the simultaneous use of Squid + Dr.Web ICAPD).

•To make Squid check HTTP requests (REQMOD) and HTTP responses (RESPMOD) via the ICAP, add two ICAP services of the corresponding types.

•To make Squid use Dr.Web ICAPD as an ICAP service, the address and port specified in icap_service should match the address and port specified in the ListenAddress parameter in the Dr.Web ICAPD‘s settings.

•Dr.Web ICAPD will not work with Squid, if the icap_preview_size parameter value is not 0.

•Squid forms the “Client’s IP address” and “Username” values automatically and redirects them to Dr.Web ICAPD as headers of its ICAP request. The correctness and availability of this data is not guaranteed. Dr.Web ICAPD assumes that the user name and the user’s IP address are transferred by the proxy server in the X-Client-Username and X-Client-IP headers; and assumes that only those value encoding methods are used that are defined by default in Squid‘s settings. For this reason, when configuring Squid, it is recommended that you do not change the parameter values that influence the method of transferring this data (like icap_client_username_encode and icap_client_username_header).

The used Squid version should be built with the support of ICAP (that is, compiled with the --enable-icap-client option). Otherwise, it is not possible to establish connection between Squid and Dr.Web ICAPD.

The list of parameters that can be configured depends on the version of the Squid server that you are using (below you can find the description of configuring the following Squid versions: 3.2 (and later), 3.1, and 3.0). If the strings mentioned bellow are already in the configuration file, their values should be changed to the specified ones. If the mentioned parameters are already in the file, but they are commented out, uncomment them. If there are no required parameters in the Squid configuration file, add them to the file, for example, to the end.

Only the #1 and #2 steps are obligatory for configuring interaction between Dr.Web ICAPD and Squid. If other settings, out of those which are mentioned below, are not required, do not add them to the Squid configuration file.

#1
icap_enable on

#2
icap_service i_req reqmod_precache bypass=0 icap://127.0.0.1:1344/reqmod
icap_service i_res respmod_precache bypass=0 icap://127.0.0.1:1344/respmod

adaptation_access i_req allow all
adaptation_access i_res allow all

#3
icap_preview_enable on
icap_preview_size 0

#4 (In Squid 3.2, the icap_send_client_ip and icap_send_client_username parameters have been renamed)
adaptation_send_client_ip on
adaptation_send_username on

#5
icap_persistent_connections on

#1
icap_enable on

#2 (In Squid 3.1, the format used to configure a service has been changed and the icap_access parameter has been renamed)
icap_service i_req reqmod_precache bypass=0 icap://127.0.0.1:1344/reqmod
icap_service i_res respmod_precache bypass=0 icap://127.0.0.1:1344/respmod

adaptation_access i_req allow all
adaptation_access i_res allow all

#3
icap_preview_enable on
icap_preview_size 0

#4
icap_send_client_ip on
icap_send_client_username on

#5
icap_persistent_connections on

#1
icap_enable on

#2
icap_service i_req reqmod_precache 0 icap://127.0.0.1:1344/reqmod
icap_service i_res respmod_precache 0 icap://127.0.0.1:1344/respmod

icap_class icapd_class_req i_req
icap_class icapd_class_resp i_res

icap_access icapd_class_req allow all
icap_access icapd_class_resp allow all

#3
icap_preview_enable on
icap_preview_size 0

#4
icap_send_client_ip on
icap_send_client_username on

#5
icap_persistent_connections on

If necessary, you can limit the size of data that Squid will send for scanning via the ICAP protocol. For this purpose, the configuration file must be added with a condition that must satisfy (or not satisfy) the content of the header Content-Length, for example:

(condition <name> will be true, if the header Content-Length in the server response contains a number larger than 999999).

Then the added condition should be used to allow or deny scanning of the server response via the ICAP protocol (the word all must be replaced in the connection parameters of Squid to the external ICAP server with the condition name <name>). Due to the fact that the example indicated above could be true when the header Content-Length has a number larger that 999999, we will use it to deny the scanning of responses, whose condition <name> is true:

#Squid 3.1 and later versions
adaptation_access i_res deny <name>

#Squid 3.0 and earlier versions
icap_access icapd_class_resp deny <name>

Presence of the header Content-Length is not guaranteed in the webserver response. If it is not available, the indicated method for size restriction of data, that is sent by Squid for scanning to the ICAP server, will not work.

For details on configuration of Squid in a more fine-grained way to restrict scanning of web traffic, see documentation of Squid. See, for example, http://www.squid-cache.org/Doc/.