LXF78:HTTP прокси-сервер для защиты корпоративной сети

Версия 15:19, 12 марта 2008

Сергей Иванов анализирует существующие Unix-решения с открытым исходным кодом.

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

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

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

Рассмотрим возникающие задачи и способы их решения.

Авторизация пользователей

Первая задача, которая возникает перед администратором прокси, – авторизация и идентификация пользователей для выхода в Интернет через прокси. Поддержка прокси таких схем авторизации как NTLM, MSNT, SMB, LDAP, существенно облегчает решение поставленной задачи. Идентификация особенно важна, когда необходимо решить вопросы аудита и фильтрации трафика.

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

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

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

Второй вариант – использование механизма «прозрачного прокси» («transparent proxy» или, более точно – перехватывающего прокси – «intercepting proxy»). Реализация данного механизма заключается в автоматическом перенаправлении HTTP-запросов пользователей на прокси сервер. Перенаправление осуществляется на шлюзе, который соединяет внутреннюю сеть с Интернетом. В прокси требуется поддержка определения оригинального адреса пользователя, отправившего запрос. Часто шлюз и прокси физически представляют один сервер, особенно в небольших сетях. Поскольку данный вариант интеграции не требует настроек пользовательской машины, достигается эффект «прозрачности» доступа пользователя во внешнюю сеть.

Таким образом, «прозрачный» режим требует поддержки и со стороны прокси сервера, и со стороны шлюза, но позволяет достичь простоты в сопровождении.

Если в качестве шлюза используется сервер, поддерживающий протокол WCCP, есть смысл организовать «прозрачное» проксирование с использованием этого протокола. Протокол позволяет отслеживать статус прокси-сервера, и если сервер стал недоступен, организовать перенаправление иначе. Это позволит избежать отказа в обслуживании (DoS).

Кэширование трафика и балансировка нагрузки

Поддержка кэширования входящего трафика – одно из важных требований к прокси-серверу. Запрашиваемые пользователем объекты сохраняются в постоянном кэше на диске, и в случае если запрос происходит повторно, объект извлекается из кэша, а не скачивается из Интернета. Это позволяет экономить входящий трафик, что часто имеет большое значение для компании. Когда сеть объединяет большое количество рабочих станций, нагрузка на прокси-сервер многократно увеличивается. В этом случае применяется каскадирование прокси-серверов, и точка доступа во внешнюю сеть получается распределенной за счет увеличения количества серверов.

Для взаимодействия между ними используется протокол ICP, который позволяет быстро определить наличие кэшированной копии объекта на прокси-сервере. ICP используется только для обмена контрольной информацией; обмен данными между прокси-серверами происходит через протокол HTTP. За счет равномерного распределения данных между разными прокси-серверами достигается балансировка нагрузки. Равномерность такого распределения обеспечивается специальными алгоритмами и протоколами, такими как CARP и Round-robin. Применение CARP обеспечивает более равномерное распределение нагрузки и оптимизирует поиск кэшированных копий объектов на прокси-серверах, поскольку использует hash-алгоритм, основанный на URL.

Аудит и фильтрация информации

Контроль информации, которая циркулирует между клиентом и сервером, – типичная задача, которая стоит перед компанией. Для такого контроля необходимо решить задачи аудита и фильтрации информации. Для реализации этих задач был разработан протокол ICAP (Internet Content Adaptation Protocol). Протокол позволяет осуществлять модификацию HTTP-запросов и HTTP-ответов, а поскольку это единственные запросы, которые циркулируют между прокси и пользователями, полный контроль над трафиком обеспечен. С помощью ICAP-протокола можно производить различного рода действия над HTTP-трафиком, такие как антивирусная проверка, блокирование спама, предоставление доступа к приватным ресурсам, блокирование доступа к порно-ресурсам, учет трафика и многое другое. Одно из самых популярных применений ICAP –фильтрация вирусов. Чтобы получить картину в целом, рассмотрим принцип работы ICAP. Прокси-сервер выступает в качестве ICAP-клиента, который взаимодействует с ICAP-сервером, используя протокол ICAP. Конечный пользователь взаимодействует с серверами через прокси, используя протокол HTTP. Таким образом, поддержка ICAP-протокола конечному пользователю не нужна, и адаптация HTTP-сообщений происходит для него «прозрачно».

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

Что же дальше?

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