Стартовая страница модуля

Служба, позволяющая клиентам выполнять косвенные запросы к другим сетевым службам. Сначала клиент подключается к прокси-серверу и запрашивает какой-либо веб-ресурс, расположенный на другом сервере. Затем прокси-сервер либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша (если кто-то из клиентов уже обращался к этому ресурсу). В некоторых случаях запрос клиента или ответ сервера может быть изменён прокси-сервером в определённых целях.

Также, прокси-сервер позволяет анализировать проходящие через сервер 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-адресов и пользователей, которые авторизовались на прокси-сервере с использованием веб-авторизации.

Содержимое кэша

В закладке «Журнал» находится сводка всех системных сообщений от прокси-сервера. Журнал разделен на страницы, кнопками «вперед» и «назад» вы можете переходить со страницы на страницу, либо ввести номер страницы в поле и переключиться сразу на нее.

Записи в журнале выделяются цветом в зависимости от вида сообщения. Обычные сообщения системы отмечены белым цветом, сообщения о состоянии системы (включение/выключение, обработка кэша) - зеленым, ошибки - красным.

В правом верхнем углу модуля находится строка поиска. С ее помощью вы можете искать в журнале нужные вам записи.

Журнал всегда отображает события за текущую дату. Чтобы посмотреть события в другой день, выберите нужную дату, используя календарь в левом верхнем углу модуля.

ICRA (Internet Content Rating Association) - новая инициатива, разрабатываемая независимой некоммерческой организацией с тем же названием. Основная цель данной инициативы - защита детей от доступа к запрещенному содержимому. Данная организация имеет соглашения с множеством компаний (крупные телекоммуникационные и компании-разработчики ПО) для обеспечения более надежной защиты.

ICRA предоставляет программное обеспечение, которое позволяет проверять специальную метку, возвращаемую сайтом, и принимать решение о доступе к этим данным. Программное обеспечение работает только на платформе Microsoft Windows, но благодаря открытой спецификации существует возможность создания реализаций фильтрующего ПО и для других платформ.

Цели и задачи, решаемые данной организацией, а также все необходимые документы можно найти на сайте ICRA - http://www.icra.org/ .

К достоинствам этого подхода можно отнести то, что для обработки данных нужно только специальное программное обеспечение и нет необходимости обновлять базы адресов и/или категорий, так как вся информация передается самим сайтом. Но недостатком является то, что сайт может указывать неправильную категорию, а это приведет к неправильному предоставлению или запрещению доступа к данным. Однако эту проблему можно решить (и она уже решается) за счет использования средств подтверждения правильности данных, таких как цифровые подписи и т. п.

Фильтрация трафика в мире Web 2.0

Массовое внедрение так называемых технологий Web 2.0 сильно усложнило контентную фильтрацию веб-трафика. Поскольку во многих случаях данные передаются отдельно от оформления, существует возможность пропуска нежелательной информации к пользователю или от пользователя. В случае работы с сайтами, применяющими такие технологии, необходимо делать комплексный анализ передаваемых данных, определяя передачу дополнительной информации и учитывая данные, собранные на предыдущих этапах.

В настоящее время ни одна из компаний, выпускающих средства для контентной фильтрации веб-трафика, не позволяет производить комплексный анализ данных, передаваемых с использованием технологий AJAX.

Интеграция с внешними системами

Во многих случаях достаточно острым становится вопрос об интеграции систем контентного анализа с другими системами. При этом системы контентного анализа могут выступать как клиентами, так и серверами или в обеих ролях сразу. Для этих целей было разработано несколько стандартных протоколов - Internet Content Adaptation Protocol (ICAP), Open Pluggable Edge Services (OPES). Кроме того, некоторые производители создавали собственные протоколы для обеспечения взаимодействия конкретных продуктов друг с другом или со сторонним программным обеспечением. Сюда можно отнести протоколы Cisco Web Cache Coordination Protocol (WCCP), Check Point Content Vectoring Protocol (CVP) и другие.

Некоторые протоколы - ICAP и OPES - разработаны так, что могут использоваться для реализации как сервисов контентной фильтрации, так и других сервисов - переводчики, размещение рекламы, доставка данных, зависящая от политики их распространения, и т.п.

Протокол ICAP

В настоящее время протокол ICAP пользуется популярностью среди авторов ПО для контентной фильтрации и создателей программного обеспечения для определения вредоносного содержимого (вирусы, spyware/malware). Однако стоит отметить, что ICAP в первую очередь разрабатывался для работы с HTTP, что накладывает много ограничений на его использование с другими протоколами.

ICAP принят группой Internet Engineering Task Force (IETF) в качестве стандарта. Сам протокол определяется документом "RFC 3507" с некоторыми дополнениями, изложенными в документе "ICAP Extensions draft". Эти документы и дополнительная информация доступны с сервера ICAP Forum - http://www.i-cap.org .

Архитектура системы при использовании протокола ICAP изображена на . В качестве клиента ICAP выступает система, через которую передается трафик. Система, выполняющая анализ и обработку данных, называется сервером ICAP. Серверы ICAP могут выступать в роли клиентов для других серверов, что обеспечивает возможность стыковки нескольких сервисов для коллективной обработки одних и тех же данных.

Рисунок 1. Схема взаимодействия серверов и клиентов ICAP

Для взаимодействия между клиентом и сервером используется протокол, похожий на протокол HTTP версии 1.1, и те же способы кодирования информации. Согласно стандарту ICAP может обрабатывать как исходящий (REQMOD - Request Modification), так и входящий (RESPMOD - Response Modification) трафик. Решение о том, какие из передаваемых данных будут обрабатываться, принимается клиентом ICAP, в некоторых случаях это делает невозможным полный анализ данных. Настройки клиента полностью зависят от его реализации, и во многих случаях невозможно их изменить.

После получения данных от клиента сервер ICAP выполняет их обработку, а если это необходимо, то и модификацию данных. Затем данные возвращаются клиенту ICAP, и он их передает дальше серверу или клиенту, в зависимости от того, в каком направлении они передавались.

Наиболее широкое применение протокол ICAP нашел в продуктах для защиты от вредоносного кода, поскольку он позволяет использовать эти проверки в различных продуктах и не зависит от платформы, на которой выполняется клиент ICAP.

К недостаткам использования ICAP можно отнести следующее:

• дополнительные сетевые взаимодействия между клиентом и сервером несколько замедляют скорость передачи данных между внешними системами и потребителями информации;
• существуют проверки, которые необходимо выполнять не на клиенте, а на сервере ICAP, такие как определение типа данных и т.п. Это актуально, поскольку во многих случаях клиенты ICAP ориентируются на расширение файла или на тип данных, сообщенный внешним сервером, что может стать причиной нарушения политики безопасности;
• затрудненная интеграция с системами, использующими протоколы, отличные от HTTP, не позволяет использовать ICAP для глубокого анализа данных.

Протокол OPES

В отличие от ICAP протокол OPES разрабатывался с учетом особенностей конкретных протоколов. Кроме того, при его разработке учитывались недостатки протокола ICAP, такие как отсутствие установления подлинности клиентов и серверов, отсутствие аутентификации и др.

Так же как и ICAP, OPES принят группой Internet Engineering Task Force в качестве стандарта. Структура взаимодействия сервисов, протокол взаимодействия, требования к сервисам и решения по обеспечению безопасности сервисов изложены в документах RFC 3752, 3835, 3836, 3837 и других. Список регулярно пополняется новыми документами, описывающими применение OPES не только к обработке интернет-трафика, но и к обработке почтового трафика, а в будущем, возможно, и других видов протоколов.

Структура взаимодействия серверов OPES и клиентов (OPES Processor) изображена на . В общих чертах она подобна схеме взаимодействия серверов и клиентов ICAP, но есть и существенные отличия:

• имеются требования к реализации клиентов OPES, что делает возможным более удобное управление ими - задание политик фильтрации и т.п.;
• потребитель данных (пользователь или информационная система) может оказывать влияние на обработку данных. Например, при использовании автоматических переводчиков получаемые данные могут автоматически переводиться на тот язык, который используется пользователем;
• системы, предоставляющие данные, также могут оказывать влияние на результаты обработки;
• серверы обработки могут использовать для анализа данные, специфичные для протокола, по которому данные были переданы клиенту OPES;
• некоторые серверы обработки данных могут получать более важные данные, если они находятся в доверительных отношениях с клиентом OPES, потребителями и/или поставщиками информации.

Рисунок 2. Схема взаимодействия клиентов и серверов OPES

Все перечисленные возможности зависят исключительно от конфигурации, применяемой при внедрении системы. За счет этих возможностей использование OPES более перспективно и удобно, чем использование протокола ICAP.

В скором будущем ожидается появление продуктов, поддерживающих OPES наравне с протоколом ICAP. Пионером в разработке и использовании OPES является компания Secure Computing со своей линейкой продуктов Webwasher.

Поскольку в настоящее время нет полноценных реализаций, использующих OPES, то нельзя делать окончательные выводы о недостатках данного подхода, хотя теоретически пока остается лишь один недостаток - увеличение времени обработки за счет взаимодействия между клиентами и серверами OPES.

HTTPS и другие виды шифрованного трафика

По расчетам некоторых аналитиков, до 50% Интернет-трафика передается в зашифрованном виде. Проблема контроля шифрованного трафика сейчас актуальна для многих организаций, поскольку пользователи могут применять шифрацию для создания каналов утечки информации. Кроме того, шифрованные каналы могут использоваться и вредоносным кодом для проникновения в компьютерные системы.

Существует несколько задач, связанных с обработкой шифрованного трафика:

• анализ данных, передаваемых по зашифрованным каналам;
• проверка сертификатов которые, используются серверами для организации шифрованных каналов.

Актуальность этих задач возрастает с каждым днем.

Контроль передачи шифрованных данных

Контроль передачи данных, пересылаемых по зашифрованным каналам, является, наверное, самой важной задачей для организаций, сотрудники которых имеют доступ к Интернет-ресурсам. Для реализации этого контроля существует подход, называемый "Man-in-the-Middle" (в некоторых источниках его также называют "Main-in-the Middle"), который может использоваться злоумышленниками для перехвата данных. Схема обработки данных для данного метода дана на .

Рисунок 3. Процесс обработки шифрованных данных

Процесс обработки данных выглядит следующим образом:

• в Интернет-броузер пользователя устанавливается специально выписанный сертификат для установления соединения с прокси-сервером;
• при установлении соединения с проксисервером он использует известный сертификат для расшифровки передаваемых данных;
• расшифрованные данные анализируются так же, как и обычный HTTP-трафик;
• прокси-сервер устанавливает соединение с сервером, на который должны быть переданы данные, и использует для шифрации канала сертификат сервера;
• возвращаемые от сервера данные расшифровываются, анализируются и передаются пользователю, зашифрованные сертификатом прокси-сервера.

При использовании данной схемы обработки шифрованных данных могут возникать проблемы, связанные с подтверждением истинности пользователя. Кроме того, требуется выполнение работы по установке сертификата в Интернет-броузеры всех пользователей.

Сейчас на рынке предлагаются следующие продукты для контроля передачи шифрованных данных: Webwasher SSL Scanner компании Secure Computing, Breach View SSL TM , WebCleaner.

Проверка подлинности сертификатов

Вторая задача, возникающая при использовании шифрованных каналов передачи данных, - проверка подлинности сертификатов, предоставляемых серверами, с которыми работают пользователи.

Злоумышленники могут осуществлять атаку на информационные системы, создавая ложную запись в DNS, перенаправляющую запросы пользователя не на тот сайт, который им необходим, а на созданный самими злоумышленниками. С помощью таких подставных сайтов могут быть украдены важные данные пользователей, такие как номера кредитных карт, пароли и т.п., а также под видом обновлений программного обеспечения может быть загружен вредоносный код.

Для предотвращения подобных случаев и существует специализированное программное обеспечение, выполняющее проверку соответствия сертификатов, предоставленных сервером, тем данным, о которых они сообщают.

В случае несовпадения система может заблокировать доступ к таким сайтам или осуществить доступ после явного подтверждения пользователем. Обработка данных при этом выполняется практически тем же способом, что и при анализе данных, передаваемых по шифрованным каналам, только в этом случае анализируются не данные, а сертификат, предоставляемый сервером.

Фильтрация почтового трафика

При использовании электронной почты, организации сталкиваются с необходимостью обеспечения защиты как для входящего, так и для исходящего трафика. Но задачи, решаемые для каждого из направлений, довольно сильно различаются. Для входящего трафика необходимо обеспечить контроль вредоносного кода, фишинга и нежелательной почты (спама), в то время как в исходящей почте контролируется содержимое, передача которого может привести к утечке важной информации, распространению компрометирующих материалов и тому подобных вещей.

Большинство продуктов, существующих на рынке, предоставляют контроль только входящего трафика. Это осуществляется за счет интеграции с антивирусными системами, реализации различных механизмов защиты от нежелательной почты и фишинга. Многие из этих функций уже встраиваются в почтовые клиенты, но полностью решить задачу они не могут.

Защита от фишинга чаще всего осуществляется путем сравнения получаемых почтовых сообщений с имеющейся базой адресов сайтов и сообщений. Такие базы предоставляются поставщиками программного обеспечения.

Для защиты пользователей от спама в настоящее время существует несколько способов:

• сравнение получаемых сообщений с имеющейся базой сообщений. При сравнении могут применяться различные методики, включая использование генетических алгоритмов, которые позволяют вычленить ключевые слова даже в случае их искажения;
• динамическая категоризация сообщений по их содержимому. Позволяет очень эффективно определять наличие нежелательной корреспонденции. Для противодействия этому методу распространители спама используют рассылку сообщений в виде изображения с текстом внутри и/или наборы слов из словарей, которые создают шум, мешающий работе данных систем. Однако в будущем возможны антиспамовые системы, способные распознавать текст внутри изображений и таким образом определять их содержимое;
• серые, белые и черные списки доступа позволяют описывать политику приема почтовых сообщений с известных или неизвестных сайтов. Применение серых списков во многих случаях помогает предотвратить передачу нежелательных сообщений за счет специфики работы ПО, рассылающего спам. Для ведения черных списков доступа могут использоваться как локальные базы данных, управляемые администратором, так и глобальные, пополняемые на основе сообщений пользователей со всего мира. Однако использование глобальных баз данных чревато тем, что в них могут попасть целые сети, в том числе и содержащие "хорошие" почтовые сервера.

Для борьбы с утечками информации используются самые разные способы, основанные на перехвате и глубоком анализе сообщений в соответствии со сложной политикой фильтрации. В этом случае возникает необходимость корректного определения типов файлов, языков и кодировок текстов, проведения семантического анализа передаваемых сообщений.

Еще одно из применений систем для фильтрации почтового трафика - создание шифрованных потоков почты, когда система автоматически подписывает или шифрует сообщение, а на другом конце соединения производится автоматическая расшифровка данных. Этот функционал очень удобен, если вы хотите обрабатывать всю исходящую почту, но она должна доходить до адресата в зашифрованном виде.

Фильтрация мгновенных сообщений

Средства для передачи мгновенных сообщений (Instant messaging) постепенно переходят в разряд активно используемых инструментов во многих компаниях. Они обеспечивают быстрое взаимодействие с сотрудниками и/или клиентами организаций. Поэтому совершенно закономерно, что развитие средств, которые, кроме прочего, могут оказаться и каналом для утечки информации, привело к появлению инструментов для контроля передаваемой информации.

В настоящее время для обмена мгновенными сообщениями наиболее часто используются протоколы MSN (Microsoft Network), AIM (AOL Instant Messaging), Yahoo! Chat, Jabber и их корпоративные аналоги - протоколы Microsoft Live Communication Server (LCS), IBM SameTime и Yahoo Corporate Messaging Server. На территории СНГ широкое распространение получила система ICQ, которая сейчас принадлежит компании AOL и использует практически такой же протокол, что и AIM. Все указанные системы выполняют практически одно и то же - передают сообщения (как через сервер, так и напрямую) и файлы.

Теперь почти у всех систем появились возможности и для звонков с компьютера на компьютер и/или на обычные телефоны, что создает определенные трудности для систем контроля и требует поддержки VoIP для реализации полноценных прокси-серверов.

Обычно продукты для контроля IM-трафика реализуются как прикладной шлюз, выполняющий разбор передаваемых данных и блокирующий передачу запрещенных данных. Однако есть и реализации в виде специализированных серверов IM, которые осуществляют необходимые проверки на уровне сервера.

Наиболее востребованные функции продуктов для контроля IM-трафика:

• управление доступом по отдельным протоколам;
• контроль используемых клиентов и т.п.;
• контроль доступа отдельных пользователей:
  • разрешение пользователю общения только в пределах компании;
  • разрешение пользователю общения только с определенными пользователями вне компании;
• контроль передаваемых текстов;
• контроль передачи файлов. Объектами контроля являются:
  • размер файла;
  • тип и/или расширение файла;
• направление передачи данных;
• контроль наличия вредоносного содержимого;
• определение SPIM;
• сохранение передаваемых данных для последующего анализа.

В настоящее время контроль за передачей мгновенных сообщений позволяют выполнять следующие продукты:

• CipherTrust IronIM компании Secure Computing. Данный продукт имеет поддержку протоколов AIM, MSN, Yahoo! Chat, Microsoft LCS и IBM SameTime. Сейчас это одно из самых полных решений;
• IM Manager компании Symantec (разработан компанией IMLogic, которая была поглощена Symantec). Этот продукт имеет поддержку следующих протоколов - Microsoft LCS, AIM, MSN, IBM SameTime, ICQ и Yahoo! Chat;
• Antigen for Instant Messaging компании Microsoft также позволяет работать практически со всеми популярными протоколами для передачи мгновенных сообщений;
• Webwasher Instant Message Filter, компании Secure Computing.

Продукты других компаний (ScanSafe, ContentKeeper) обладают меньшими возможностями по сравнению с перечисленными выше. Стоит отметить, что две российские компании - "Гран При" (продукт "SL-ICQ") и "Мера.ру" (продукт "Сормович") - предоставляют продукты для контроля за передачей сообщений с использованием протокола ICQ.

Фильтрация VoIP

Растущая популярность средств для передачи звуковой информации между компьютерами (называемых также Voice over IP (VoIP)) заставляет принимать меры к контролю передачи такой информации. Есть разные реализации для звонков с компьютера на компьютер и/или на обычные телефоны.

Существуют стандартизированные протоколы для обмена такой информацией, сюда можно отнести Session Instatiation Protocol (SIP), принятый IETF и H.323, разработанный ITU. Эти протоколы являются открытыми, что делает возможным их обработку.

Кроме того, существуют протоколы, разработанные конкретными компаниями, которые не имеют открытой документации, что сильно затрудняет работу с ними. Одной из самых популярных реализаций является Skype, завоевавший широкую популярность во всем мире. Эта система позволяет выполнять звонки между компьютерами, делать звонки на стационарные и мобильные телефоны, а также принимать звонки со стационарных и мобильных телефонов. В последних версиях поддерживается возможность обмена видеоинформацией.

Большинство имеющихся на данный момент продуктов можно разделить на две категории:

• продукты, которые позволяют определить и блокировать VoIP-трафик;
• продукты, которые могут определить, захватить и проанализировать VoIP-трафик.

• продукты компании "Dolphian", позволяющие определить и разрешить или запретить VoIP-трафик (SIP и Skype), который инкапсулирован в стандартный HTTP-трафик;
• продукты компании Verso Technologies;
• разные виды межсетевых экранов, обладающие такой возможностью.

• продукт российской компании "Сормович" поддерживает захват, анализ и сохранение голосовой информации, которая передается по протоколам H.323 и SIP;
• библиотека с открытым кодом Oreka () позволяет определить сигнальную составляющую звукового трафика и выполнить захват передаваемых данных, которые затем можно проанализировать другими средствами;
• недавно стало известно, что разработанный фирмой ERA IT Solutions AG продукт позволяет перехватывать VoIP-трафик, передаваемый при помощи программы Skype. Но для выполнения такого контроля необходимо установить специализированный клиент на компьютер, на котором работает Skype.

Фильтрация peer-to-peer

Использование сотрудниками различных peer-to-peer (p2p) сетей несет следующие угрозы для организаций:

• распространение вредоносного кода;
• утечка информации;
• распространение данных, защищенных авторским правом, что может привести к судебному преследованию;
• снижение производительности труда;

Существует большое количество сетей, работающих в формате peer-to-peer. Есть сети, имеющие центральные серверы, используемые для координации пользователей, а есть сети полностью децентрализованные. Во втором случае их особенно трудно контролировать с помощью таких стандартных средств как межсетевые экраны.

Для решения данной проблемы многие фирмы создают продукты, позволяющие детектировать и обрабатывать p2p-трафик. Для обработки p2p-трафика существуют следующие решения:

• SurfControl Instant Messaging Filter, который обрабатывает p2p наравне с обработкой мгновенных сообщений;
• пакет Websense Enterprise также предоставляет пользователям средства для контроля p2p-трафика;
• Webwasher Instant Message Filter позволяет контролировать доступ к различным p2p-сетям.

Использование этих или других, не перечисленных здесь, продуктов резко сокращает риски, связанные с доступом пользователей к p2p-сетям.

Unified Threat Management

Решения, соответствующие концепции Unified Threat Management, предлагаются многими производителями средств защиты. Как правило, они построены на базе межсетевых экранов, которые кроме основных функций выполняют еще и функции контентной фильтрации данных. Как правило, эти функции сосредоточены на предотвращении вторжений, проникновения вредоносного кода и нежелательных сообщений.

Многие из таких продуктов реализуются в виде аппаратно-программных решений, которые не могут полностью заменить решения для фильтрации почтового и интернет-трафика, поскольку работают лишь с ограниченным числом возможностей, предоставляемых конкретными протоколами. Обычно их используют для того, чтобы избежать дублирования функций в разных продуктах, и для обеспечения гарантий, что все прикладные протоколы будут обрабатываться в соответствии с одной базой известных угроз.

Наиболее популярными решениями концепции Unified Threat Management являются следующие продукты:

• SonicWall Gateway Anti-Virus, Anti-Spyware and Intrusion Prevention Service обеспечивает антивирусную и другую защиту данных, передаваемых по протоколам SMTP, POP3, IMAP, HTTP, FTP, NetBIOS, протоколам Instant Messaging и многим потоковым протоколам, применяемым для передачи аудио- и видеоинформации;
• серия устройств ISS Proventia Network Multi-Function Security, выполненных в виде программно-аппаратных комплексов, обеспечивает блокировку вредоносного кода, нежелательных сообщений и вторжений. В поставку включено большое число проверок (в том числе и для VoIP), которые могут быть расширены пользователем;
• аппаратная платформа Network Gateway Security компании Secure Computing, кроме защиты от вредоносного кода и нежелательных сообщений, также имеет поддержку VPN. В составе этой платформы объединены практически все решения Secure Computing.

Существуют и другие продукты, но перечисленные выше имеют массовое распространение.

Перехват данных

Перехват данных (Lawful interception) практически всегда использовался спецслужбами для сбора и анализа передаваемой информации. Однако в последнее время вопрос перехвата данных (не только Интернет-трафика, но и телефонии, и других видов) стал очень актуальным в свете борьбы с терроризмом. Даже те государства, которые всегда были против таких систем, стали использовать их для контроля за передачей информации.

Поскольку перехватываются различные виды данных, часто передаваемые по высокоскоростным каналам, то для реализации таких систем необходимо специализированное программное обеспечение для захвата и разбора данных и отдельное программное обеспечение для анализа собранных данных. В качестве такового может использоваться ПО для контентной фильтрации того или иного протокола.

Пожалуй, самой известной из таких систем является англо-американская система Echelon, которая долго использовалась для перехвата данных в интересах различных ведомств США и Англии.

Среди российских продуктов можно упомянуть решения от компании "Сормович", позволяющее захватывать и анализировать почтовый, звуковой и Интернет-трафик.

Продукты компании "Инфосистемы Джет"

"Инфосистемы Джет" работают на рынке контентной фильтрации уже больше шести лет. Начало было положено системой для фильтрации почтового трафика, затем разработки перешли в другие области применения контентной фильтрации, и компания не собирается останавливаться на достигнутом.

В последние полгода произошло несколько событий, связанных с продуктами контентной фильтрации, выпускаемыми компанией. Речь идет о выходе четвертой версии системы мониторинга и архивирования почтовых сообщений (СМАП) "Дозор-Джет" и начале разработки второй версии системы контроля веб-трафика (СКВТ) "Дозор-Джет". Оба продукта имеют много отличий и нововведений по сравнению с предыдущими версиями.

Кроме названных продуктов в компании разработано другое программное обеспечение, также связанное с проблемами контентной фильтрации, - библиотеки определения типов данных и модуля определения типов и распаковки данных для Lotus/Cerberus.

СМАП "Дозор-Джет"

Итак, в четвертой версии СМАП "Дозор-Джет" реализованы новые возможности, обеспечивающие более высокий уровень фильтрации почтовых потоков. Изменения, затронувшие систему, можно разделить на несколько разделов:

• общие изменения;
• изменения в подсистеме фильтрации;
• изменения в подсистеме управления;
• изменения в модулях расширения.

Некоторые изменения кардинально отличают данный продукт от тех, что предлагаются другими компаниями. Об этом будет рассказано в соответствующих разделах.

Переход на новую версию осуществляется без потери наработанных политик фильтрации - для этого разработаны средства миграции данных и документация по их использованию.

Дополнительную информацию о СМАП "Дозор-Джет" можно найти на продуктовом сайте компании "Инфосистемы Джет": http://www.jetsoft.ru/ или из других выпусков бюллетеня Jet Info, электронная версия: .

Общие изменения

К общим изменениям относятся такие, которые затрагивают все части системы, например:

• поддержка Unicode - все части системы используют Unicode в качестве внутренней кодировки данных. Это изменение позволяет использовать систему в многоязычных средах и поддерживать разные языки как для обработки писем, так и для пользовательского интерфейса. Есть возможность мгновенного переключения языка подсистемы управления. В настоящий момент для нее реализована поддержка русского, английского и японского языков;
• переработана схема базы данных, что позволило повысить скорость закладки сообщений в архив и ускорить поиск по архиву;
• отправка сообщений выделена в отдельную подсистему, это повысило надежность обработки сообщений и упростило интеграцию с внешними почтовыми системами;
• в поставке системы теперь идут типовые политики, в которых находятся наиболее часто используемые условия, пометки и другие объекты политики фильтрации;
• в качестве баз данных используются Oracle 10g и PostgreSQL 8.x, что позволило увеличить объемы хранения без существенного изменения требований к серверам баз данных. Кроме того, в настоящее время ведется работа над модулем взаимодействия с Microsoft SQL Server для предприятий, на которых не используется СУБД Oracle.

Эти изменения существенное повлияли на архитектуру системы и позволили исключить большую часть ограничений и недостатков, существовавших в предыдущих версиях.

Изменения в подсистеме фильтрации

Изменения в подсистеме фильтрации оказали существенное влияние на производительность системы. К ним можно отнести:

• новый парсер писем реализует механизмы "ленивой" распаковки писем и объектов. Этот механизм существенно повышает производительность, поскольку распаковка письма и объектов, его составляющих, производится только в том случае, когда имеется соответствующее условие (проверка типа файла, наличие текста в файле, наличие ошибок распаковки).
• Новая система определения типов позволяет очень точно определять типы передаваемых данных, и выбирать соответствующие обработчики.
• Новая система определения языков и кодировок корректно определяет кодировку и язык текстовых объектов и преобразует их во внутреннее представление подсистемы фильтрации - Unicode.
• В новой версии пометки привязываются не к письму, как это было раньше, а к объектам письма, что позволяет создавать более сложные политики фильтрации, например, все ли файлы зашифрованы, или определять, какой файл вызвал ошибку распаковки.
• В подсистеме фильтрации появились новые условия фильтрации:
  • условие для проверки времени суток - делает возможным реализацию отложенной доставки сообщений, для некоторых их видов, например, содержащих файлы с аудио- и видеоинформацией;
  • условие для проверки дня недели может использоваться для выявления необычной активности в нерабочие дни.
• Также были реализованы и новые действия:
  • отложенная доставка писем - обычно используется вместе с другими условиями, такими как размер письма или время отправки, и обеспечивает отправку писем после указанного времени;
  • приоритетная доставка писем обеспечивает ускоренную доставку некоторых видов писем.
• Новые распаковщики и конвертеры:
  • добавлена поддержка архивов 7zip, deb, rpm и cpio;
  • добавлен анализатор текстовых файлов, который позволяет выделить из текста бинарные данные закодированные с помощью base64, uuencode и quoted-printable. Эта утилита корректно обрабатывает неправильно пересылаемые письма (forwarded) и те случаи, когда пользователи стараются закодировать пересылаемые данные для обмана системы;
  • корректно обрабатываются файлы, rar, присоединенные к файлам других типов - MS Word, tiff, jpeg и другие;
  • сделано извлечение текстовых комментариев из всех типов архивов и файлов mp3.
• Антивирусная поддержка теперь реализуется только с помощью протокола ICAP, что позволяет использовать следующие антивирусы: Symantec, Trendmicro, DrWeb, Clamav (с помощью программы c-icap), Kaspersky ICAP Server и другие, имеющие поддержку ICAP.
• Появилась возможность подключения модулей предварительной обработки сообщений, и теперь для обработки сообщений можно применять антиспамовые системы сторонних производителей.

Изменения в подсистеме управления

Интерфейс управления системой претерпел кардинальные изменения. Он получил новый дизайн, для его реализации использована технология Ajax, что увеличило скорость отклика на действия пользователя системы. Общий вид нового интерфейса пользователя представлен на .

Рисунок 4. Общий вид интерфейса пользователя системы

Модуль сегментирования архива почтовых сообщений полностью переработан, чтобы обеспечить удобство работы с сегментами и сделать возможной автоматическое управление сегментами.

Модуль реконструкции переписан для использования новых возможностей - теперь можно удалять части писем основываясь не только на типе части письма, но и на пометках, установленных на эту часть.

Модуль полнотекстового поиска по архиву теперь входит в базовую поставку системы.

Модуль поддержки ЭЦП обеспечивает проверку ЭЦП письма, установить ЭЦП на письмо и зашифровать/расшифровать письмо. Поддерживаются разные алгоритмы шифрации, в том числе и ГОСТ.

СКВТ "Дозор-Джет"

Система контроля веб-трафика (СКВТ) "Дозор-Джет" - сравнительно новый продукт компании, но уже хорошо зарекомендовавший себя у пользователей. С момента его выпуска прошло полтора года, в настоящее время ведется активная разработка второй версии СКВТ "Дозор-Джет". В ней запланированы следующие изменения:

• кардинально переработан интерфейс пользователя:
  • для ускорения работы пользователей применяется технология Ajax, интерфейс становится более похожим на интерфейс 4-й версии СМАП "Дозор-Джет";
  • интерфейс пользователя поддерживает работу с разными языками - в настоящий момент это русский, английский и японский;
  • управление вспомогательными утилитами (выгрузка данных из базы, резервное копирование и т.п.) производится через веб-интерфейс с возможностью настройки работы по расписанию.
• В подсистеме фильтрации:
  • добавлена фильтрация по любому из заголовков запросов или ответов;
  • добавлена фильтрация по командам протокола HTTP;
  • пользователь может быть аутентифицирован по нескольким признакам - имя/пароль, IP-адрес, MAC-адрес;
  • для установления категории сайта используются как внешние базы категорий сайтов, так и семантический анализ содержимого сайтов. Система поддерживает работу с базами категорий сайтов от компаний NetStar и ISS/Cobion;
  • реализована поддержка протокола ICAP для взаимодействия с антивирусным программным обеспечением;
  • для анализа текста в исходящих документах могут использоваться внешние конвертеры;
  • реализовано оповещение администратора при срабатывании заданных условий;
  • POST-запросы могут сохраняться в базу данных и могут быть проанализированы позднее.
• Сильно переработана подсистема отчетности:
  • добавлены новые типовые отчеты - Top-N пользователей по трафику, Top-N самых посещаемых сайтов, Top-N наиболее активно используемых форматов файлов и другие;
  • реализована возможность автоматической генерации отчетов по расписанию;
  • вывод результатов в различные форматы - HTML с картинками, PDF, CSV.

Вторая версия СКВТ "Дозор-Джет" планируется к выпуску на российский рынок в первом квартале 2007 года.

Межсетевой экран Z-2

Межсетевой экран Z-2 можно отнести к средствам, реализующим концепцию UTM. Система имеет в своем составе базовые средства контентной фильтрации передаваемых данных, включая их антивирусную проверку для всех протоколов, для которых существуют анализаторы протоколов.

В новой версии реализована антивирусная проверка передаваемых данных через ICAP в шлюзах HTTP, FTP, SMTP и POP3, что позволяет легко интегрироваться с рядом популярных AV-решений.

Для шлюза SMTP протокола реализована поддержка протокола SPF и механизма серых списков доступа (graylisting). В сочетании с другими возможностями по обработке SMTP потока это позволяет значительно сократить количество нежелательных писем до их обработки средствами контентной фильтрации, снижая нагрузку на них.

В качестве дополнительных возможностей можно выделить ограничение полосы пропускания в зависимости от типа содержимого в HTTP-шлюзе.

Система определения типов

Определение типов данных играет важную роль при разработке продуктов контентной фильтрации. Многие компании используют для этой цели широко распространенную утилиту file, хорошо известную пользователям UNIX-подобных операционных систем. Однако у этой утилиты есть многочисленные недостатки, которые приводят к частым ошибкам в определении типов. Поэтому компанией разработана собственная система определения типов, позволяющая сделать эту операцию очень точной.

Новая система определения типов данных обладает следующими возможностями:

• специализированный язык описания проверок типов данных позволяет реализовать очень сложные проверки. Это полноценный язык программирования со следующими возможностями:
  • поддерживаются типы данных: числа (big & little endian), строки, символы, списки;
  • поддержка множества операций - сравнения, арифметические, битовые, логические;
  • поддерживается прямая и косвенная адресация проверяемых данных, что позволяет анализировать информацию, основываясь на информации, считанной на предыдущих этапах анализа;
  • поддержка условных операторов позволяет сделать условия более гибкими;
  • форматированный вывод позволяет управлять выводом результатов;
  • возможность расширения языка проверок позволяет проанализировать даже очень сложные структуры.
• Возможно подключение дополнительных модулей анализа. На данный момент существуют следующие дополнительные модули анализа:
  • модуль определения типов для OLE-файлов - Microsoft Visio, Project, Word, Excel, PowerPoint;
  • модуль определения текста и методов его кодирования;
  • модуль определения исполняемых файлов MS-DOS (.com-файлы).
• Явное отображение сигнатур в mime-типы позволяет избежать дублирования информации (что присутствует в стандартной утилите file).

Модуль определения типов и распаковки данных для Lotus/Cerberus

Данный модуль является дополнением к программному обеспечению Cerberus для Lotus Domino, которое выполняет функции по анализу сообщений, передаваемых в рамках работы системы Lotus Domino. Однако эта система обладает малыми возможностями по анализу типов передаваемых данных. Для ее решения и разработан данный модуль.

Модуль позволяет выполнять следующие задачи:

• вести список разрешенных и запрещенных типов данных;
• для разрешенных типов данных можно указать дополнительную команду обработки данного типа файлов, например, распаковать архив или извлечь текст из файлов Microsoft Word.

Функционирует модуль под управлением операционной системы Microsoft Windows и в данное время успешно применяется в одном из крупнейших российских банков.

Заключение

Развитие информационных систем приводит к возникновению все новых и новых угроз. Поэтому развитие продуктов контентной фильтрации не только не отстает, но иногда даже и предвосхищает возникновение новых угроз, уменьшая риски для защищаемых информационных систем.

Администрирование

Я принимал участие в бета-тестировании 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.

Комфортной и безопасной работы!

Спасибо за внимание.

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 all

adaptation_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 all

There 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.