Материал из Linuxformat.

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

Содержание 1 Авторизация пользователей 2 Интеграция в сеть 3 Кэширование трафика и балансировка нагрузки 4 Аудит и фильтрация информации 5 Что же дальше? 6 Delegate 7 Oops! 8 Squid 2.5 9 Squid 3.0 10 Сводная таблица возможностей

В настоящее время количество угроз безопасности в сети Интернет растет с каждым годом. Это особенно касается пользователей 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 может быть весьма полезен в небольших сетях для решения простых задач, поскольку весьма прост в конфигурации. В таких сетях загрузка прокси будет небольшой, и проблемы с производительностью не возникнут.

Oops!

Альтернатива Squid.

• Версия: 1.5.23
• Web: www.oops-cache.org
• Цена: бесплатно, по лицензии GPL

Это полноценный HTTP прокси-сервер, который был разработан в качестве альтернативы Squid. Поддерживаются протоколы HTTP, FTP, SSL-туннелирование.

Основными целями, которые преследовали разработчики Oops!, были: модульность, высокое быстродействие, простота конфигурирования, длительная бесперебойная работа. Oops! – это кэширующий прокси-сервер.

Хранение кэшированных объектов реализовано в одном или нескольких файлах. Каждый файл содержит внутри себя файловую систему. Для взаимодействия с кэш-серверами поддерживается протокол ICP. Oops! полноценно поддерживает режим прозрачного проксирования, поскольку опирается не только на данные HTTP-заголовка, но и на NAT. Поддерживается протокол WCCP, что позволяет оптимально использовать режим прозрачного прокси. Для авторизации пользователей поддерживается PAM, LDAP, стандартный файл паролей. Также доступна авторизация через MySQL, PostgreSQL. Для сбо- ра статистики реализована поддержка протокола NetFlow. Контроль доступа осуществляется через набор правил, определяемых через ACL.

Помимо очевидных плюсов существуют и минусы. Отсутствует поддержка протокола CARP, в результате балансировка нагрузки между различными серверами не может быть выполнена с максимальной эффективностью. Хотя вариантов авторизации довольно много, не поддерживаются схемы NTLM, MSNT. Отсутствует поддержка протокола ICAP, что затрудняет решение задач фильтрации. Благодаря поддержке NetFLow и ACL, задачи аудита могут быть решены, но эффективное решение для фильтрации трафика не реализовано. После рассмотрения основных плюсов и минусов c точки зрения поддерживаемых возможностей перейдем в архитектуре Oops!

В Oops! используется модель, где каждое соединение обрабатывается отдельным потоком.

Если с точки зрения простоты программирования этот подход имеет свои преимущества, то с точки зрения производительности он далеко не оптимален. В общем-то это одно из основных отличий от архитектуры Squid, который вообще не требует использования потоков и использует однопроцессную модель. За счет выбранной модели разработчики Oops! стремились обеспечить лучшее масштабирование на SMP-системах.

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

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

Возвращаясь к использованию потоков вообще, хотелось бы заметить, что они и по сей день работают не на всех Unix-системах одинаково эффективно, а на момент создания Oops! реализацию потоков можно было назвать полноценной только в Solaris, для которой он, собственно, и разрабатывался.

При большой нагрузке у Oops! возникают серьезные проблемы с производительностью на большинстве Unix-систем, а зачастую он попросту зависает. Таким образом, основные требования для сервера – бесперебойная работа и высокая производительность – не выполнены. Тем не менее Oops! вполне можно использовать в небольших сетях благодаря простоте настройки.

Squid 2.5

Стандарт де-факто.

• Версия: 2.5.SATBLE13
• Web: www.squid-cache.org
• Цена: бесплатно, по лицензии GPL

Вот уже много лет Squid является наиболее популярным высокопроизводительным HTTP прокси-сервером на Unix-системах. Поддерживаются такие протоколы, как HTTP, SSL, FTP, Gopher. Squid может работать как в режиме кэширующего прокси, так и в режиме HTTP-акселератора. Хранилище кэшированных объектов реализовано в виде модульной виртуальной файловой системы. Используемые файловые системы определяются конфигурацией Squid. Поддерживаются следующие системы: ufs, diskd, aufs, coss. Список модулей может быть легко расширен. По умолчанию используется ufs. Модули diskd и aufs используются для оптимизации работы с файловой системой при большой нагрузке. При необходимости распределения нагрузки кэш-сервера могут каскадироваться, взаимодействуя по протоколу ICP.

Поддержка Round-robin и CARP обеспечивает балансировку нагрузки между серверами. Поддерживается полноценная работа в режиме «прозрачный прокси». Поддержка протокола WCCP позволяет использовать прозрачный режим наиболее эффективно. Довольно распространенный протокол SNMP для поддержки удаленного контроля и управления также поддерживается Squid. Это позволяет отслеживать его поведение с единой консоли администратора.

Для авторизации пользователей поддерживаются NTLM, MSNT, LDAP, SMB, что позволяет легко интегрировать Squid в сеть Microsoft. Одна из удобных возможностей, которую поддерживает Squid – ограничение пропускной способности по настраиваемым критериями. Такая функциональность позволяет ограничить использование канала в Интернет для определенных групп пользователей. Особенно важной такая функциональность становится в условиях экономии трафика, поскольку позволяет устанавливать свою пропускную способность для разных типов трафика.

Для управления доступом и сервисами используется мощное средство – ACL. На основании данных HTTP-заголовка и URL, используя ACL, можно выполнить статическую фильтрацию трафика. К сожалению, с динамической фильтрацией трафика дела обстоят несколько хуже. Кроме redirector, других возможностей для внешнего контроля данных в Squid не пре- дусмотрено. В экспериментальной версии Squid 2.5 поддерживается протокол ICAP, но его реализация обладает рядом серьезных недостатков:

• не поддерживается фильтрация FTP-трафика. Для реализации такой фильтрации необходимо объединять два прокси-сервера;

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

• неполная поддержка ICAP RFC.

Возможно, именно эти недостатки помешали включить поддержку ICAP в стабильную ветку.

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

Из перечисленных выше продуктов Squid – самое высокопроизводительное решение.

Высокое быстродействие и переносимость обеспечивается выбранной архитектурой. Squid использует однопроцессную архитектуру, когда один процесс обслуживает все операции ввода/вывода в неблокирующем режиме. Состояния дескрипторов отслеживаются с помощью функций poll, select и т.д. Для оптимизации некоторые виды действий, такие как dns-запросы или операции с диском, могут быть выделены в отдельные процессы. Вспомогательные процессы взаимодействуют с основным через IPC-функции.

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

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

Сетевая модель, лежащая основе архитектуры Squid, – одна их самых оптимальных, хотя и не достаточно учитывает SMP-системы. Распределение обслуживания сетевых соединений между несколькими процессами (потоками) позволило бы улучшить масштабируемость.

На базе Squid реализовано довольно много проектов. Некоторые из них перечислены на http://www.squid-cache.org/products.html. Это и специализированные устройства, и выделенные сервера. Очевидно, что Squid может быть адаптирован под самые различные задачи.

Squid 3.0

Адаптирован под самые различные задачи.

• Версия: 3.0
• Web: www.squid-cache.org

Новая веха в судьбе Squid.

Основные отличия от версии 2.5:

• Конвертирование исходного кода из С в C++. Довольно важный шаг, поскольку облегчит сопровождение продукта и расширение функциональности.

• Поддержка ICAP. Поддерживается не только адаптация HTTP-трафика, но и FTP.

• Переработана сетевая часть. Оптимизирована работа со стандартными функциями select, poll. Добавлена поддержка более высокопроизводительных интерфейсов отслеживания состояния дескрипторов: epoll, /dev/poll, kqueue. Поскольку Squid обрабатывает все сетевые соединения одним процессом, а эффективность poll/select функций сильно падает при большом числе дескрипторов, данная оптимизация позволяет ускорить работу сетевой части.

• Улучшена поддержка CARP. В ранних версиях поддержка по умолчанию отсутствовала, что создавало неудобства в использовании, поскольку требовалась пересборка Squid. В версии 3.0 поддержка CARP присутствует по умолчанию.

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

• Улучшена работа в режиме акселератора. Более удобные и понятные опции конфигурации, повышен уровень безопасности.

• Улучшена поддержка SSL. Добавлена поддержка SSL peers, поддержка сертификатов клиента, поддержка аппаратных SSL-ускорителей при помощи OpenSSL, более защищенная работа с SSL-ключами.

• Переработана поддержка IPC.

• Расширена поддержка ACL. Добавлены новые методы.

Список изменений довольно большой. Вполне понятно, почему разработчики решили сделать эти изменения в новой ветке, а не развить ветку 2.x. Проделана большая работа, которая позволит дать толчок дальнейшему развитию продукта.

Среди добавленных возможностей хотелось бы особенно выделить поддержку протокола ICAP: возможность, которая позволит решать задачи аудита и фильтрации в полном объеме. Хотелось бы отметить, что реализация ICAP в Squid 3.0 – не наследие неэффективной экспериментальной версии из ветки 2.5, а новая, более производительная реализация. Поддержка ICAP позволит интегрировать в Squid антивирусы и другие внешние сервисы для обработки HTTP-трафика, что сделает сеть более защищенной.

Последняя версия 3.0 уже вышла на финальную стадию стабилизации, вновь добавленные возможности позволят ей стать достойной заменой версии 2.5.

---

Сводная таблица возможностей

	ICP	CARP	WCCP	Авторизация	NetFlow	SNMP	Xephem	Сетевая модель	Ограничение полосы пропускания
Delegate	да			PAM, DgAuth				процесс на соединение
Oops!	да		да	LDAP, SQL, PAM	да			поток на соединение
Squid 2.5	да	небходима пересборка	да	NTLM, MSNT, PAM, SMB, LDAP, NCSA...		да		один процесс на все соединения	да
Squid 3.0	да	да	да	NTLM, MSNT, PAM, SMB, LDAP, NCSA...		да	да	один процесс на все соединения	да