Internet Content Adaptation Protocol (RFC , subject to errata) specifies how an HTTP proxy (an ICAP client) can outsource content adaptation to an external ICAP server. Most popular proxies, including Squid, support ICAP. If your adaptation algorithm resides in an ICAP server, it will be able to work in a variety of environments and will not depend on a single proxy project or vendor. No proxy code modifications are necessary for most content adaptations using ICAP.
Pros : Proxy-independent, adaptation-focused API, no Squid modifications, supports remote adaptation servers, scalable. Cons : Communication delays, protocol functionality limitations, needs a stand-alone ICAP server process or box.
One proxy may access many ICAP servers, and one ICAP server may be accessed by many proxies. An ICAP server may reside on the same physical machine as Squid or run on a remote host. Depending on configuration and context, some ICAP failures can be bypassed, making them invisible to proxy end-users.
ICAP Servers
While writing yet another ICAP server from scratch is always a possibility, the following ICAP servers can be modified to support the adaptations you need. Some ICAP servers even accept custom adaptation modules or plugins.
Traffic Spicer (C++)
POESIA (Java)
(Java and Javascript)
original reference implementation by Network Appliance.
The above list is not comprehensive and is not meant as an endorsement. Any ICAP server will have unique set of pros and cons in the context of your adaptation project.
More information about ICAP is available on the ICAP Forum . While the Forum site has not been actively maintained, its members-only newsgroup is still a good place to discuss ICAP issues.
Squid Details
Squid-3.0 and later come with integrated ICAP support. Pre-cache REQMOD and RESPMOD vectoring points are supported, including request satisfaction. Squid-2 has limited ICAP support via a set of poorly maintained and very buggy patches. It is worth noting that the Squid developers no longer officially support the Squid-2 ICAP work.
Squid supports receiving 204 (no modification) responses from ICAP servers. This is typically used when the server wants to perform no modifications on a HTTP message. It is useful to save bandwidth by preventing the server from sending the HTTP message back to Squid as it was received. There are two situations however where Squid will not accept a 204 response:
- The size of the payload is greater than 64kb.
- The size of the payload cannot be (easily) ascertained.
The reason for this is simple: If the server is to respond to Squid with a 204, Squid needs to maintain a copy of the original HTTP message in memory. These two basic requirements are a basic optimisation to limit Squid"s memory usage in supporting 204s.
Squid Configuration
Squid 3.1
Squid-3.1
icap_enable on icap_service service_req reqmod_precache bypass=1 icap://127.0.0.1:1344/request adaptation_access service_req allow all icap_service service_resp respmod_precache bypass=0 icap://127.0.0.1:1344/response adaptation_access service_resp allow alladaptation_access
adaptation_service_set
icap_client_username_encode
icap_client_username_header
icap_connect_timeout
icap_default_options_ttl
icap_enable
icap_io_timeout
icap_persistent_connections
icap_preview_enable
icap_preview_size
icap_send_client_ip
icap_send_client_username
icap_service
icap_service_failure_limit
icap_service_revival_delay
Squid 3.0
The following example instructs Squid-3.0 to talk to two ICAP services, one for request and one for response adaptation:
icap_enable on icap_service service_req reqmod_precache 1 icap://127.0.0.1:1344/request icap_class class_req service_req icap_access class_req allow all icap_service service_resp respmod_precache 0 icap://127.0.0.1:1344/response icap_class class_resp service_resp icap_access class_resp allow allThere are other options which can control various aspects of ICAP:
Definition - What does mean?
Internet Content Adaptation Protocol (ICAP) is a lightweight protocol providing simple object-based content vectoring for HTTP services. ICAP is used to extend transparent proxy servers. This frees up resources and standardizes the implementation of new features. It uses a cache to proxy all client transactions and process the transactions using ICAP Web servers, which are designed for specific functions such as virus scanning, content translation, content filtering or ad insertion.
ICAP performs content manipulation as a value added service for the appropriate client HTTP request or HTTP response. Thus the name "content adaptation."
This term is also known as Internet Content Adaption Protocol.
Techopedia explains Internet Content Adaptation Protocol (ICAP)
Internet Content Adaptation Protocol was proposed in 1999 by Danzig and Schuster of Network Appliance. Don Gillies enhanced the protocol in 2000 allowing pipelined ICAP servers. All three encapsulations permitted by HTTP 1.1 are supported. He also produced training materials for vendors about 2005.
ICAP leverages caches and proxies to aid in producing value-added services. The value-added services can be off-loaded from Web servers to ICAP servers. Then, Web servers can be scaled using raw HTTP throughput.
Despite the similarity, ICAP is not HTTP. And it is not an application running over HTTP.
Стартовая страница модуля
Служба, позволяющая клиентам выполнять косвенные запросы к другим сетевым службам. Сначала клиент подключается к прокси-серверу и запрашивает какой-либо веб-ресурс, расположенный на другом сервере. Затем прокси-сервер либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша (если кто-то из клиентов уже обращался к этому ресурсу). В некоторых случаях запрос клиента или ответ сервера может быть изменён прокси-сервером в определённых целях.
Также, прокси-сервер позволяет анализировать проходящие через сервер HTTP-запросы клиентов, выполнять фильтрацию и учёт трафика по URL и mime-типам. Кроме этого, прокси-сервер реализует механизм доступа в интернет по логину/паролю.
Прокси-сервер выполняет кеширование объектов, полученных пользователями из интернета и за счёт этого сокращает потребление трафика и увеличивает скорость загрузки страниц.
При входе в модуль отображается состояние служб, кнопка «Выключить» (или «Включить» если модуль выключен) и последние сообщения в журнале.
Настройки
Обычно для работы через прокси-сервер, необходимо указать его адрес и порт в настройках браузера. Однако, в случае если не используется авторизация пользователей по логину/паролю, то можно использовать функцию прозрачного прокси.
При этом все запросы по протоколу HTTP из локальной сети автоматически направляются через прокси-сервер. Таким образом появляется возможность фильтрации и учёта трафика по URL независимо от настроек клиентских компьютеров.
Порт работы прокси-сервера по умолчанию 3128, в настройке модуля вы можете изменить его на любой свободный порт.
Типы авторизации
Прокси-сервер ИКС поддерживает два способа авторизации: по ip-адресу пользователя, и по логину-паролю.
Авторизация по ip-адресу подходит для случаев, когда пользователь постоянно пользуется одним и тем же компьютером. Прокси определяет, какому пользователю принадлежит тот или иной трафик, исходя из ip-адреса его компьютера. Этот способ не подходит для терминальных серверов, так как в этом случае с одного ip-адреса работает несколько пользователей. Также этот способ не подходит для организаций, в которых пользователи постоянно перемещаются между рабочими местами. Кроме того, пользователь может сменить ip-адрес своего компьютера и, если не настроена привязка MAC-адреса к IP, ИКС примет его за кого-то другого.
Авторизация по логину/паролю решает проблему привязки пользователей к собственному компьютеру. В этом случае при первом обращении к любому интернет-ресурсу, браузер выдаст пользователю запрос логина/пароля для доступа в интернет. Если в вашей сети пользователи авторизуются в домене, вы можете установить тип авторизации «Через домен». В таком случае, если ИКС подключен к контроллеру домена и в из домена были импортированы пользователи, авторизация будет выполнена прозрачно, без запроса логина/пароля.
Кроме того, следует помнить о том, что авторизация на прокси используется только для http-трафика пользователей. Доступ в интернет для программ, использующих протоколы, отличные от http, регулируется межсетевым экраном, который имеет только один способ авторизации: по ip-адресу. Другими словами, если пользователь использует только авторизацию по логину/паролю, он не сможет пользоваться почтой, jabber-клиентом, torrent-клиентом и другими программами, не поддерживающими работу через http-прокси.
Веб-авторизация
Для того, чтобы авторизовать пользователей без прописанного прокси-сервера по имени пользователя и паролю, вы можете использовать веб-авторизацию (captive portal), включив соответствующий флажок. Веб-авторизация позволяет, к примеру, интегрировать страницу авторизации в корпоративный портал, и использовать его в качестве страницы авторизации. По умолчанию порт веб-авторизации 82, вы также можете изменить его на любой свободный.
Для того, чтобы не прописывать вручную прокси-сервер на каждой клиентской машине, вы можете воспользоваться автоконфигуратором. В браузере клиента должна быть выставлена опция «Автоматическая конфигурация прокси», все остальные настройки определит ИКС.
Он включается установкой флажка в соответствующей вкладке. Вы можете отметить один или несколько протоколов из доступных (HTTP, HTTPS, FTP).
Опция публикации скрипта автонастройки определяет, будет ли он доступен по ip-адресу сервера либо по созданному виртуальному хосту с доменным именем. При выборе виртуального хоста, он автоматически создастся в системе. Флажок «Создать запись на ДНС-сервере» автоматически добавит зону с нужными записями для этого виртуального хоста.
Публиковать скрипт автоконфигурации по DHCP - данный параметр передает настройки прокси всем DHCP-клиентам сервера.
Родительский прокси
Если в вашей организации несколько проксирующих серверов, расположенных иерархично, то вышестоящий для ИКС прокси-сервер будет являться его родительским прокси . Кроме того, в качестве родительского прокси может выступать любой узел сети.
Чтобы ИКС перенаправлял запросы, приходящие на его прокси-сервер, на родительский прокси, укажите его ip-адрес и порт назначения во вкладке «Родительский прокси».
Прокси-сервера могут обмениваться данными своих кэшей по протоколу ICP. В случае работы сети через несколько прокси это может значительно ускорить работу. Если родительский прокси поддерживает работу протокола, отметьте соответствующий флажок и укажите порт работы службы (по умолчанию 3130).
Выданные ip-адреса
В этой вкладке находится список Ip-адресов и пользователей, которые авторизовались на прокси-сервере с использованием веб-авторизации.
Содержимое кэша
В закладке «Журнал» находится сводка всех системных сообщений от прокси-сервера. Журнал разделен на страницы, кнопками «вперед» и «назад» вы можете переходить со страницы на страницу, либо ввести номер страницы в поле и переключиться сразу на нее.
Записи в журнале выделяются цветом в зависимости от вида сообщения. Обычные сообщения системы отмечены белым цветом, сообщения о состоянии системы (включение/выключение, обработка кэша) - зеленым, ошибки - красным.
В правом верхнем углу модуля находится строка поиска. С ее помощью вы можете искать в журнале нужные вам записи.
Журнал всегда отображает события за текущую дату. Чтобы посмотреть события в другой день, выберите нужную дату, используя календарь в левом верхнем углу модуля.
Для корректной интеграции системы необходимо также настроить работу прокси-сервера организации. Общим требованием к настройкам является необходимость настройки IP-адреса ICAP-сервера SecureTower на прокси-сервере. Для этого ICAP-модуль прокси-сервера должен быть настроен таким образом, чтобы заголовок отправляемого ICAP-серверу запроса включал поле X-Client-IP, содержащее IP-адрес пользователя. Запросы без указанного IP-адреса будут приняты, но не будут обслуживаться ICAP-сервером .
Среди прочих SecureTower поддерживает интеграцию с наиболее популярными прокси-серверами SQUID и MS Forefront.
SQUID
Система SecureTower поддерживает версии SQUID старше 3.0. При установке/компиляции прокси-сервера необходимо активировать опцию включения поддержки ICAP и в настройках ICAP указать следующие опции:
- icap_enable on
- icap_send_client_ip on - IP-адрес клиента
- icap_service_req service_reqmod_precache 0 icap://192.168.45.1:1344/reqmod, где 192.168.45.1 - IP-адрес ICAP-сервера SecureTower
- adaptation_access service_req allow all
MS Forefront
Для работы в сетях, организованных на базе прокси-сервера TMG Forefront, необходимо дополнительно установить ICAP-плагин, т.к. по умолчанию ICAP не поддерживается данным прокси-сервером. Плагин доступен по ссылке http://www.collectivesoftware.com/solutions/content-filtering/icapclient.
В настройках ICAP- плагина требуется указать адрес ICAP-сервера SecureTower. В результате все данные, переданные про протоколу HTTP(S) через прокси-сервер MS Forefront, будут сохранены ICAP-сервером SecureTower .
Минимальные системные требования для ICAP-сервера
- Процессор: 2 ГГц и выше, 2 ядра и более
- Сетевой адаптер: 100 Мбит/1 Гбит
- Оперативная память: не менее 6 ГБ
- Жесткий диск: 100 ГБ раздел для операционной системы и файлов SecureTower; второй раздел для хранения перехваченных данных из расчета 1,5 ГБ данных от каждого контролируемого пользователя за месяц плюс 3 % от объема перехваченных данных для файлов поисковых индексов
- Windows .Net Framework: 4.7 и выше
- Операционная система: Microsoft Windows Server 2008R2/2012/2016 x64
Администрирование
Я принимал участие в бета-тестировании icap-демона от Dr.Web, остался им доволен (несмотря на некоторые проблемы, не решенные на этот момент), но финансовая сторона вопроса меня сильно ограничивает, поэтому в очередной раз мой выбор пал на ClamAV.
Использование Squid с помощью ClamAV и c-icap для проверки web-трафика на вирусы
Предыстория
Для работы не понадобится работающий демон clamd, так что можете смело пропустить его конфигурирование (clamd.conf), если он не используется или не будет использоваться.
c-icap работает со своим антивирусным модулем, основанным на ClamAV, поэтому нам понадобится наличие в системе libclamav (достаточно установленного обычным способом ClamAV). В случае отсутствия в системе libclamav c-icap просто не соберется.
Установка и настройки c-icap с поддержкой ClamAV
Распакуем архив c_icap-220505.tar.gz в /usr/src (или туда, где у вас лежат исходные коды). Скрипт configure в каталоге с исходниками c-icap следует запускать со следующими параметрами:
$ ./configure --enable-static --with-clamav --prefix=/usr/local/c_icap
Или, например, так, если --prefix=/opt/clamav для configure от ClamAV:
$ ./configure --enable-static --with-clamav=/opt/clamav --prefix=/usr/local/c_icap
Демон c_icap собирается статически. --prefix также можно указать по вкусу. Можно собирать и сам демон:
Необходимо проверить, все ли верно собралось:
$ make check
И непосредственно установить c-icap в систему (в тот каталог, который был указан через --prefix):
# make install
Теперь необходимо исправить некоторые настройки в c-icap.conf. В случае нашего --prefix=/usr/local/c_icap не трудно догадаться, что конфиги лежат в /usr/local/c_icap/etc.
- User лучше поставить nobody, поскольку wwwrun, указанный по умолчанию, скорее всего отсутствует в системе.
- TmpDir /tmp - ваш каталог временных файлов.
- Далее необходимо настроить ACL - Access Control Lists - список IP-адресов, которые могут использовать данный ICAP-демон:
acl localsquid_respmod src 127.0.0.1 type respmod
acl localsquid src 127.0.0.1
acl externalnet src 0.0.0.0/0.0.0.0
icap_access allow localsquid_respmod
icap_access allow localsquid
icap_access deny externalnet
Так можно определить, откуда разрешен доступ к нашему сервису icap, а откуда - нет. Заметьте, что в данных ACL определяется не список непосредственных клиентов прокси-сервера, а именно список клиентов демона ICAP, т.е. список прокси-серверов (их IP-адреса).
Я составил ACL для случая работы демона ICAP и Squid на одном хосте.
- srv_clamav.ClamAvTmpDir /tmp - временный каталог для модуля ClamAV.
- srv_clamav.VirSaveDir /var/infected/ - каталог карантина. Другие аналогичные лучше закомментировать!
- srv_clamav.VirHTTPServer «DUMMY».
Можно попробовать и так:
Srv_clamav.VirHTTPServer "http://proxy.your_srv_name.ru/cgi-bin/get_file.pl?usename=%f&remove=1&file="
Необходимо некоторое пояснение: опция srv_clamav.VirSaveDir может быть задана несколько раз - таким образом, что инфицированные файлы будут сохраняться в множестве мест. Если задать одним из карантинных каталогов корень web-сервера, то можно дать пользователям возможность осознанно скачать инфицированный файл. Остается только воспользоваться файлом contrib/get_file.pl в исходных кодах c-icap.
У меня необходимости в этом не было.
Создайте каталог /var/infected и сделайте его владельцем пользователя nobody (chown nobody /var/infected).
Осуществим пробный запуск c-icap:
# cd /usr/local/c_icap/bin # ./c-icap
Если сообщений об ошибках нет, то стоит убедиться и в том, что c-icap прослушивает нужный сокет:
# netstat -apn | grep 1344
Если видим нечто похожее на следующую строку, все в порядке:
Tcp 0 0 *:1344 *:* LISTEN 24302/c-icap
Оставим демона c-icap работать и перейдем к дальнейшим настройкам.
Установка и настройка прокси-сервера Squid
Распакуем в /usr/src полученный ранее Squid:
# tar zxvf squid-icap-2.5.STABLE11-20050927.tgz
Перейдем в каталог с исходниками Squid и запустим configure так:
$ ./configure --enable-icap-support
До запуска configure в Squid от Dr.Web необходимо запустить bootstrap.sh, находящийся в корневом каталоге исходных кодов Squid. Если вы используете Squid от Dr.Web, то обязательно прочитайте документацию из пакета drweb-icapd!
Собираем Squid:
Устанавливаем:
# make install
Имеем установленный Squid в /usr/local/squid. Теперь изменим настройки в squid.conf.
Необходимо найти пару строк:
#acl our_networks src 192.168.1.0/24 192.168.2.0/24 #http_access allow our_networks
Раскомментировать их и установить собственное значение, вместо 192.168.1.0/24 192.168.2.0/24 (в моем случае пользователи прокси-серверs находились в сети 172.16.194.0/24):
Acl our_networks src 172.16.194.0/24 http_access allow our_networks
Перейдите в /usr/local/squid/var, создайте каталог cache. Теперь там же выполните команду:
# chown nobody cache/ logs/
Сменить владельца необходимо по той причине, что демон прокси-сервера будет запущен от пользователя nobody и не сможет писать логи и использовать кэш.
Осталось создать структуру каталогов для кэширования. Перейдите в /usr/local/squid/sbin и выполните:
# ./squid -z
По умолчанию параметр cache_dir в squid.conf задан так:
Cache_dir ufs /usr/local/squid/var/cache 100 16 256
Вы можете изменить путь к кэшу (например, если он расположен у вас на другом разделе или жестком диске), и тогда необходимо проверить права на указанный вами каталог.
На данном этапе мы имеем рабочий Squid, но без поддержки ICAP, т.е. обычной кэширующий прокси-сервер.
Добавим поддержку ICAP…
Добавление поддержки ICAP в squid.conf
Найдите по слову icap_enable и выставите значение icap_enable on. Найдите по слову icap_preview_enable и выставите значение icap_preview_enable on. Найдите по слову icap_preview_size и выставите значение icap_preview_size 128. Найдите по слову icap_send_client_ip и выставите значение icap_send_client_ip on. Найдите по слову icap_service и добавьте пару таких icap-сервисов:
Icap_service service_avi_req reqmod_precache 0 icap://localhost:1344/srv_clamav icap_service service_avi respmod_precache 1 icap://localhost:1344/srv_clamav
Найдите по слову icap_class и добавьте такой icap-класс:
Icap_class class_antivirus service_avi service_avi_req
Найдите по слову icap_access и добавьте следующие права доступа:
Icap_access class_antivirus allow all
Суммарно для поддержки ICAP в squid.conf должны быть добавлены следующие строки:
Icap_enable on
icap_preview_enable on
icap_preview_size 128
icap_send_client_ip on
icap_service service_avi_req reqmod_precache 0 icap://localhost:1344/srv_clamav
icap_service service_avi respmod_precache 1 icap://localhost:1344/srv_clamav
icap_class class_antivirus service_avi service_avi_req
icap_access class_antivirus allow all
На этом минимальное конфигурирование прокси-сервера закончено.
Запустим его:
# cd /usr/local/squid/sbin # ./squid
Если все верно, то сообщений в консоли быть не должно.
Проверка работоспособности
Добавьте прокси-сервер в вашем браузере (если проксирование не прозрачное) и откройте страницу http://www.eicar.com/anti_virus_test_file.htm .
Попытайтесь скачать файл eicar.com. Если вы видите подобное сообщение: «A VIRUS FOUND …» - значит все верно работает.
Обратите внимание, что кэш прокси-сервера не должен содержать инфицированных объектов! Поэтому перед началом использования Squid совместно с c-icap кэш лучше очистить. Так же учтите, что браузер имеет свой кэш.
Обновление антивирусных баз ClamAV
Добавьте freshclam в crontab. Реинициализация баз c-icap производится каждые srv_clamav.VirUpdateTime минут - этот параметр можно указать в c-icap.conf (по умолчанию, 15 минут).
Файл c-icap.magic и типы проверяемых объектов
Данный файл может быть найден в том же каталоге, что и c-icap.conf. Он представляет собой описание форматов различных групп типов файлов (TEXT, DATA, EXECUTABLE, ARCHIVE, GRAPHICS, STREAM, DOCUMENT - определенные группы в c-icap.magic по умолчанию). Антивирусная проверка строится по типам файлов, проходящих через проски-сервер. Некоторые типы, например, можно исключить или добавить свои типы.
Формат записи строки, для определения файла по его magic-числу (последовательности):
Offset:Magic:Type:Group:Desc
Offset - смещение, с которого начинается Magic-последовательность. Type и Group - тип и группа, к которой следует относить файл с данной magic-последовательностью. Desc - краткое описание, технической нагрузки не несет.
Для примера загляните в c-icap.magic.
Обратите также внимание, что в c-icap.conf параметр srv_clamav.ScanFileTypes определяет группы и типы файлов (можно прописывать и группы, и типы), которые следует проверять. Что определяет srv_clamav.VirScanFileTypes, я окончательно не понял, но подозреваю, что принудительно проверяемые группы файлов (EXECUTABLE и ARCHIVE по умолчанию).
В моем конфиге c-icap вышеописанные параметры выглядят так:
Srv_clamav.ScanFileTypes TEXT DATA EXECUTABLE ARCHIVE GRAPHICS STREAM DOCUMENT srv_clamav.VirScanFileTypes EXECUTABLE ARCHIVE
Возможные проблемы
- Squid выдает сообщение ICAP protocol error, страницы не открываются. Проверьте, верно ли вы указали ACL в c-icap.conf, в данном ACL должен быть разрешен доступ не для пользователей, а для прокси-сервера.
Попробуйте завершить процессы Squid и c-icap, а затем запустить их в следующем порядке: сначала c-icap, а затем Squid.
Также такая ошибка может возникать, если демону с-icap не хватает прав на запись в карантинный каталог или в лог-файлы.
Если проблема так и не решилась, то попробуйте запустить Squid с параметрами -d 10 -N -X:
# ./squid -d 10 -N -X И c-icap c параметрами -N -d 10 -D: # ./c-icap -N -d 10 -D Увидите подробную информацию, по которой можно разобраться, что и где не так.
- Squid выдает сообщение ICAP protocol error только на некоторых страницах (на одних и тех же).
Проверьте, есть ли у c-icap права на запись в карантинный каталог (а еще лучше сделать владельцем всех карантинных каталогов пользователя под которым запущен c-icap).
Попробуйте запустить c-icap и Squid в режиме отладки (как это сделать, сказано выше).
Также неплохо посмотреть логи c-icap.
Попробуйте снова загрузить объект, на котором возникает ошибка. Возможно вы узнаете намного больше о проблеме и сможете ее решить.
Итоги
Теперь и web-серфинг защищен от вирусов и прочих вредоносных кодов (в том числе и некоторые эксплоиты для MS IE). Как корпоративное решение для сервера с большой нагрузкой этот метод не опробован, но, думаю, может быть реализован (хотя бы потому, что нагрузку можно распределить на несколько ICAP-серверов). Как решение для небольшой организации - вполне актуально.
И помните, что разработчики пишут на своем сайте:
- >The Antivirus ClamAV service
- >This service is under development.
О некоторых принципах работы протокола ICAP на русском можно узнать из руководства DrWeb-ICAP - одна из успешных коммерческих реализаций протокола ICAP. Можно прочесть и RFC 3507.
Комфортной и безопасной работы!
Спасибо за внимание.