LXF78:HTTP прокси-сервер для защиты корпоративной сети
|
|
|
Сергей Иванов анализирует существующие 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. Для получения наиболее полной картины, целесообразно сравнить эти продукты не только с точки зрения поддерживаемых возможностей, но и с точки зрения архитектуры. Ведь именно архитектура определяет дальнейшую судьбу продукта, как в области применения, так и в области развития. Итак, рассмотрим каждый из них.
Delegate
Многоцелевой прокси-сервер.
- Версия: 9.1
- Web: www.delegate.org
- Цена: бесплатно для применения в небольших сетях (до 500 пользователей)
Многоцелевой прокси-сервер, работающий с различными TCP-, UDP-протоколами, такими как HTTP, HTTPS, FTP, NNTP, SMTP, SOCKS, IMAP, ICP и т. д. Delegate работает как прокси уровня приложения (application-level), который пропускает через себя различные протоколы, производя необходимые изменения в данных. Также Delegate может быть использован как прокси для передачи любых данных между клиентом и сервером по протоколам TCP, UDP. Являясь прокси уровня приложения, Delegate обеспечивает виртуальное представление ресурсов, расположенных на различных серверах. В случаях HTTP, FTP, NNTP, Delegate может выступать самостоятельным сервером. Поддерживается фильтрация данных. Для фильтрации используется собственный интерфейс CFI (Common Filtering Interface). В качестве фильтров могут быть использованы как внутренние средства Delegate, так и обычные внешние приложения (sed, awk...), работающие со стандартным вводом/выводом. В случае когда Delegate выступает в качестве HTTP прокси-сервера, для хранения объектов может быть использован постоянный кэш, размещенный на диске. Поддержка протокола ICP позволяет эффективнее взаимодействовать с другими кэш-серверами. Авторизация пользователей, если она необходима, происходит через PAM и собственную службу авторизации DGAuth.
Для ограничения загрузки сервера поддерживается ограничение по количеству соединений, тайм-ауту. Если взглянуть на Delegate, создается ощущение, что он представляет собой гигантский запутанный конструктор, из которого можно смастерить практически любой прокси-сервис.
Тем не менее функциональности для кэширующего прокси недостаточно.
Прозрачное HTTP-проксирование поддерживается не полностью, поскольку реализация опирается только на данные «Host:» HTTP-заголовка, а он не всегда присутствует. Не поддерживаются протоколы WCCP, CARP. Вместо стандартного протокола ICAP поддерживается свой собственный интерфейс фильтрации, что затрудняет встраивание стандартных сервисов фильтрации и аудита. Не поддерживаются схемы авторизации NTLM, MSNT, что затрудняет интеграцию в сеть, построенную на технологии Windows.
Скажем несколько слов об архитектуре Delegate. Сервер каждого протокола работает в отдельном процессе и при каждом соединении с пользователем порождает новый процесс.
Для пересылки информации по каналу данных в протоколе FTP создаются дополнительные процессы. Фильтры также создают дополнительные процессы для запуска внешних программ фильтрации. Скорость работы таких фильтров оставляет желать лучшего. Когда количество клиентов достигает хотя бы тысячи, создается большое количество процессов, что ведет к неразумному расходу ресурсов и большой загрузке системы.
Несмотря на все перечисленные недостатки, Delegate может быть весьма полезен в небольших сетях для решения простых задач, поскольку весьма прост в конфигурации. В таких сетях загрузка прокси будет небольшой, и проблемы с производительностью не возникнут.
