Работая в компании с количеством сотрудников в несколько сотен человек, поневоле задумываешься о безопасности сети, данных и рабочих мест сотрудников.
Ниже я опишу несколько методов оптимизации работы, которые помогают решать часть проблем корпоративной безопасности при помощи прокси серверов.
Мифы о наличии прокси сервера
Миф1: Proxy server — ЗЛО.
Сам по себе Proxy server не зло, злом он становится в кривых руках администраторов, которые зачастую не понимают принципов его работы и неверно его настраивают под нужды компании.
Миф2: Proxy server нужен администратору чтобы унизить пользователя.
Системные администраторы, использующие прокси сервера для ограничения доступа, не ставят перед собой цели стать богами над пользователями в иерархии обслуживаемой компании. Методики ограничения доступа к определенным категориям сайтов обеспечивают дополнительную безопасность как пользователей, так и компании в целом. Если Вы готовы поспорить с этим, то ниже по тексту я приведу несколько примеров защиты пользователей при использовании прокси сервера.
Миф3: Трафик настолько дешев, что использование прокси сервера просто нерентабельно.
В наше время развитого подключения к сети всех до единого, даже домохозяек и детей, нагрузка на некоторые ресурсы сети становится головной болью администраторов этих ресурсов, а также администраторов сетей обеспечивающих доступ к этим ресурсам. Прокси сервер может снизить нагрузку как на интересующие компанию ресурсы, уменьшить время доступа ко многим объектам с ресурсов за счет их кеширования, а также повлияет на снижение объёма трафика поступающего на интерфейс компании.
Основные проблемы и ограничения при большом количестве пользователей
Одной из самых больших проблем является аутентификации большого количества пользователей для обеспечения доступа в сеть. Проблема не столько техническая сколько архитектурная. При использовании механизмов аутентификации, используемых в прокси серверах(в данной статье мы рассматриваем SQUID), пропадает возможность прозрачной фильтрации запросов пользователей. В свою очередь при использовании прозрачной фильтрации пропадает возможность использования аутентификации пользователей. Т.е. эти две вещи взаимоисключаемые в работе.
Варианты аутентификации делятся на несколько типов и представляют собой внешние приложения, которые согласно получаемых от клиента данных производят проверку данных в какой-либо базе. Основные методы аутентификации описаны в FAQ wiki.squid-cache.org/Features/Authentication и заново их тут описывать особого смысла нет.
У каждого типа аутентификации есть свои недостатки:
LDAP — при использовании в большом домене может привести к значительному увеличению нагрузки на доменконтроллеры.
NSCA — неудобен с точки зрения синхронизации паролей в домене и на proxy сервере.
SMB(MSNT) — удобен для использования, но велик риск при случайном отключении от домена потерять контроль над сервером, т.к. для авторизации используются приложения Samba сервера и включение proxy сервера в домен как члена домена.
Согласно архитектуре squid все положительные запросы аутентификации кешируются, что в принципе может повлечь за собой нецелевое использование сервера заблокированными аккаунтами в зависимости от времени жизни кешированных данных.
Аутентификация по ident может вызвать проблемы связанные с увеличением нагрузки на сеть, а также на снижение скорости ответов proxy сервера при высокой загруженности клиентских машин. Довольно часты случаи сбоя аутентификации по ident и выдаче имени пользователя NT\SYSTEM вместо реального имени пользователя работающего за машиной.
Аутентификация по IP адресу подразумевает под собой статическое выделение IP адресов в локальной сети или резервирование адресов на dhcp сервере.
К сожалению при использовании прозрачного кеширования ни один из методов аутентификации кроме ident и IP не работает, что накладывает определенные ограничения для контроля доступа. Так как большое количество запросов к домен контроллерам чревато их возможной перегрузкой и последующим отказом, мы будем рассматривать IP Based аутентификации пользователей. Многим из Вас это может показаться неправильным, но в большинстве случаев выбора особо нет.
Автоматическая настройка прокси-сервера на клиентских станциях
Так как прописывание на рабочих станциях настроек прокси-сервера вручную работа довольно нудная и неблагодарная, существует несколько способов помогающих настроить браузер на требуемый адрес.
Первый способ это использование доменных групповых политик. Метод прост и удобен, за исключением момента смены имени proxy-сервера или его переносе на другой IP адрес. В зависимости от настроек доменные политики могут обновляться в различных временных промежутках(по умолчанию 1 раз в 45 минут), что может повлечь за собой задержку применения новых настроек.
Вторым способом является раздача ссылки на proxy сервер через DHCP. Метод безусловно хороший, за исключением необходимости перезагружать компьютер или вызывать процедуру обновления IP адреса на компьютере пользователя. К сожалению метод работает только для Internet Explorer.
Третий способ это создание вспомогательного WPAD(Web Proxy Auto-Discovery) домена и файла wpad.dat, которые позволяют динамически менять настройки подключения к прокси-серверу, всего-лишь путём закрытия/открытия браузера. Для обеспечения работы механизма необходимо создать в текущем домене(DNS зоне по умолчанию) запись WPAD IN A с указанием IP адреса вебсервера с которого будет скачиваться файл автоматической конфигурации. В корне этого сервера необходимо разместить файл wpad.dat. Файл представляет собой кусок javascript кода, который в зависимости от различных условий может отдавать различные адреса прокси сервера для различных адресов и доменов, а также указывать метод доступа к ресурсам. Описание формата файла wpad.dat можно найти в интернете. Единственным условием успешного использования wpad файла является отключение его кеширования в доменной политике предприятия. Время кеширования этого файла по умолчанию достаточно велико, в связи с чем лучше обеспечить его обновление при открытии новой сессии.
Идеальный ACL
Squid позволяет создавать правила для разграничения доступа основываясь на определенных условиях и ответах внешних программ или аутентификационных модулей.
Изменение конфигурационного файла сквида, а также файлов вызываемых из конфигурационного файла(внешние списки пользователей или доменов и т.д), требуют перезапуска процесса squid. При изменении конфигурационных файлов и перезапуске squid возможен вариант падения процесса сервера. К сожалению в высоконагруженных системах с сотнями пользователей случайная остановка сервера чревата красным телефоном примерно через несколько секунд. Понятное дело, что нахождение проблемы скорее всего не займёт много времени, но нервы будут испорчены разъярёнными пользователями.
Идеальным вариантом является создание одного внешнего acl который будет рулить доступом вместо squid, но не будет требовать перезагрузки процесса прокси-сервера. Вариант внешнего acl может быть как двухзвенным, так и трёхзвенным. Всё зависит от архитектуры которая Вам удобна.
Множество администраторов используют модули управления доступом типа SAMS, SquidGuard, Rejik и прочие. Эти модули используют двухзвенную структуру. Squid обращается к внешнему редиректору и анализирует ответы от него. В тот же самый момент есть маленький набор утилит либо web интерфейс, который изменяет конфигурационные файлы редиректора. Но при обновлении этих файлов всётаки нужен рестарт squid как процесса-хозяина для обновления настроек редиректоров.
Практически идеальной является схема при которой squid+редиректор(с логикой) с одной стороны, независимый блок хранения настроек и обслуживающий сервер с другой. Т.е. блок с настройками скажем это база данных в SQL или в memcached. А редиректор это агрегатор запросов, который из базы данных вытаскивает необходимую информацию для определения доступа пользователя. Обслуживающий же сервер это инструмент для формирования базы доступа. В данном случае остановки и перезапуска сервера squid не требуется и все настройки можно менять в реальном режиме времени.
Практическое решение
Возникает резонный вопрос «Почему это до сих пор не реализовано?»
Ответ на него простой «Не существует универсального инструмента под все случаи жизни, каждый выбирает инструмент который его устраивает»
Так получилось, что поиски инструмента для нашей компании не увенчались успехом. В одних инструментах не хватало гибкости конфигов, в других скорости работы и надежности редиректоров. Смешивание нескольких инструментов в единую конфигурацию зачастую ведет к тотальной несовместимости и увеличению трудозатрат на поддержание системы.
Поэтому мы решили реализовать свой вариант. Данный вариант является рабочим прототипом и нацелен в основном на тестирование нагрузки, которую может дать proxy сервер с 600-1000req/сек.
Сразу оговорюсь, что основной задачей данного прототипа было ограничение доступа пользователей согласно определённым категориям с динамическим изменением списков доступа в реальном режиме времени.
Еще более конкретной задачей было оградить пользователей от посещения фишинговых сайтов, а также сайтов с malware и прочими гадостями.
Для примера был взят сервис opendns, позволяющий категоризировать сайты и ограничивать доступ для определенных адресов включая функцию родительского контроля.
В чём смысл работы сервиса OpenDNS?
OpenDNS предоставляет пользователю возможность выбрать некоторое количество категорий и перенастроить свои DNS серверы на сервера OpenDNS для обеспечения функции фильтрования. Когда посещаемый сайт попадает в одну из категорий которую выбрал пользователь, пользователю возвращается подмененный IP адрес сайта ведущий на страницу блокировки с перечислением категорий сайта.
Взяв эту страницу за основу можно написать маленький скрипт возвращающий по запросу список категорий сайта.
Список категорий сайтов вполне конечен, он может быть вынесен в отдельный файл и пронумерован для дальнейшего использования.
Итак. Мы имеем файл с категориями пронумерованными скажем от 1 до 40, имеем список пользователей(IP адресов) которых мы хотим оградить от посещения малвари и фишинговых сайтов. Какой метод проверки категорийности нам выбрать в редиректоре?
Вариантов несколько, все имеют своё преимущество и недостатки. По умолчанию мы будем использовать кеширование сайтов и принадлежащих им категориям. Т.е. перед проверкой категории сайта мы сначала смотрим в кеш, а потом если категории в кеше нет, то обращаемся к сайту категоризатора. Редиректоров при этом должно быть несколько, чтобы исключить задержки и увеличить скорость обработки.
Вариант 1: SQL таблица
Пользователи и разрешенные им категории живут в sql таблице, кешированные имена доменов и их категории живут там же. Всё удовольствие будет занимать 1-2 запроса.
Основная проблема будет в момент распухания количества кешированных доменов и их категорий, она частично решается введением правильных индексов, но при 600 запросах в секунду выборка из таблицы в несколько тысяч записей может оказаться довольно долгой и ресурсоёмкой операцией. Для обновления данных нам будет необходимо ввести поле timestamp по которому мы будем удалять записи старше определённого возраста. Удалять записи можно из скрипта по крону или через определенное количество запросов прямо из редиректора.
Вариант 2: MemCached
Вариант с моей точки зрения более удобный, так как позволяет делать простые таблицы и работать с данными в виде «Ключ=Значение». Скорость выборки из memcached намного выше скорости выборки из SQL, поэтому нагрузка на сервер может быть существенно снижена. Однако данный вариант требует установки дополнительного демона memcached, а также наличия достаточного количества памяти на машине. Схема позволяет кластеризовать обслуживание запросов, а также использовать один инстанс для нескольких прокси серверов.
Вариант 3: Perl Cache::FastMmap
Облегченная версия memcached(образно говоря) которая позволяет использовать файл лежащий на диске в качестве shared memory объекта. Несколько клиентов могут работать с этим файлом одновременно и читать/хранить данные в виде «Ключ=Значение». Также эта схема обеспечивает сохранность данных при падении редиректоров или самого демона squid.
Мы выбрали последний вариант, так как он давал большую гибкость при работе на локальной машине.
Схема хороша еще и тем, что в качестве категорий можно подгружать любые внешние списки адресов сайтов, а также блоков IP адресов. При таком построении системы можно использовать любое количество категоризаторов. Скажем для блокировки Tor сети достаточно только загрузить список Tor серверов обновляя его по кронтабу и назначив Tor серверам определённую категорию. Тоже самое с malware доменами. Для ускорения обработки данных по IP адресам можно использовать Radix Tree, но это зависит от задач которые Вы решаете.
При работе с базой Cache::FastMmap мы сделали схему при которой максимально ускорена обработка данных.
Категории для пользователей описываются в формате: ip_cat=perm
где IP — ip адрес пользователя
cat — номер категории
perm — правило(allow/block)
Данные для адреса 0.0.0.0 являются общими для всех и позволяют блокировать или открывать нужные категории всем пользователям, оставляя возможность персональной блокировки/разблокировки для каждого конкретного случая.
Категории сайтов были в формате domainname=cat1;cat2;cat3 и т.д.
Так как Cache::FastMmap имеет встроенный механизм удаления устаревших данных, то проблема с контролем за обновлением базы отпала сама собой.
Эффективность кеширования результатов оказалась довольно хорошей.
Помещено сайтов в кеш: 125077 объектов
Прочитано сайтов из кеша: 4226793 объектов
Здесь не учитываются повторы объектов помещенных в кеш. Просто общие данные вход/выход.
Собственно чем я хочу закончить этот пост.
Используя современные механизмы обработки данных можно построить быструю и производительную систему обеспечивающую все потребности по ограничению доступа для пользователей.
Какую систему будете строить Вы — решать только Вам. Механизмы которые тут описаны очень легко воспроизводимы на любом языке программирования.
Если кому-то интересны исходники редиректора на perl, могу выложить, но там очень мало интересного ;)
UPD: Дабы не быть голословным выкладываю скрипты для работы с opendns.
aborche.com/tst/squid/catserver.pl.txt — категорийный демон который таскает категории с opendns.com
aborche.com/tst/squid/testfilter.pl.txt — скрипт который ждёт на стандартном вводе имени домена и отсылает его на категорийный сервер(используется для тестирования и проверки)
aborche.com/tst/squid/pradm.pl.txt — редиректор для squid который запрашивает сайты у категорийного демона и решает пускать или нет.
aborche.com/tst/squid/categories.conf — файл с категориями
aborche.com/tst/squid/squid.conf — пример вызова редиректора из squid.
© Aborche 2009
Ниже я опишу несколько методов оптимизации работы, которые помогают решать часть проблем корпоративной безопасности при помощи прокси серверов.
Мифы о наличии прокси сервера
Миф1: Proxy server — ЗЛО.
Сам по себе Proxy server не зло, злом он становится в кривых руках администраторов, которые зачастую не понимают принципов его работы и неверно его настраивают под нужды компании.
Миф2: Proxy server нужен администратору чтобы унизить пользователя.
Системные администраторы, использующие прокси сервера для ограничения доступа, не ставят перед собой цели стать богами над пользователями в иерархии обслуживаемой компании. Методики ограничения доступа к определенным категориям сайтов обеспечивают дополнительную безопасность как пользователей, так и компании в целом. Если Вы готовы поспорить с этим, то ниже по тексту я приведу несколько примеров защиты пользователей при использовании прокси сервера.
Миф3: Трафик настолько дешев, что использование прокси сервера просто нерентабельно.
В наше время развитого подключения к сети всех до единого, даже домохозяек и детей, нагрузка на некоторые ресурсы сети становится головной болью администраторов этих ресурсов, а также администраторов сетей обеспечивающих доступ к этим ресурсам. Прокси сервер может снизить нагрузку как на интересующие компанию ресурсы, уменьшить время доступа ко многим объектам с ресурсов за счет их кеширования, а также повлияет на снижение объёма трафика поступающего на интерфейс компании.
Основные проблемы и ограничения при большом количестве пользователей
Одной из самых больших проблем является аутентификации большого количества пользователей для обеспечения доступа в сеть. Проблема не столько техническая сколько архитектурная. При использовании механизмов аутентификации, используемых в прокси серверах(в данной статье мы рассматриваем SQUID), пропадает возможность прозрачной фильтрации запросов пользователей. В свою очередь при использовании прозрачной фильтрации пропадает возможность использования аутентификации пользователей. Т.е. эти две вещи взаимоисключаемые в работе.
Варианты аутентификации делятся на несколько типов и представляют собой внешние приложения, которые согласно получаемых от клиента данных производят проверку данных в какой-либо базе. Основные методы аутентификации описаны в FAQ wiki.squid-cache.org/Features/Authentication и заново их тут описывать особого смысла нет.
У каждого типа аутентификации есть свои недостатки:
LDAP — при использовании в большом домене может привести к значительному увеличению нагрузки на доменконтроллеры.
NSCA — неудобен с точки зрения синхронизации паролей в домене и на proxy сервере.
SMB(MSNT) — удобен для использования, но велик риск при случайном отключении от домена потерять контроль над сервером, т.к. для авторизации используются приложения Samba сервера и включение proxy сервера в домен как члена домена.
Согласно архитектуре squid все положительные запросы аутентификации кешируются, что в принципе может повлечь за собой нецелевое использование сервера заблокированными аккаунтами в зависимости от времени жизни кешированных данных.
Аутентификация по ident может вызвать проблемы связанные с увеличением нагрузки на сеть, а также на снижение скорости ответов proxy сервера при высокой загруженности клиентских машин. Довольно часты случаи сбоя аутентификации по ident и выдаче имени пользователя NT\SYSTEM вместо реального имени пользователя работающего за машиной.
Аутентификация по IP адресу подразумевает под собой статическое выделение IP адресов в локальной сети или резервирование адресов на dhcp сервере.
К сожалению при использовании прозрачного кеширования ни один из методов аутентификации кроме ident и IP не работает, что накладывает определенные ограничения для контроля доступа. Так как большое количество запросов к домен контроллерам чревато их возможной перегрузкой и последующим отказом, мы будем рассматривать IP Based аутентификации пользователей. Многим из Вас это может показаться неправильным, но в большинстве случаев выбора особо нет.
Автоматическая настройка прокси-сервера на клиентских станциях
Так как прописывание на рабочих станциях настроек прокси-сервера вручную работа довольно нудная и неблагодарная, существует несколько способов помогающих настроить браузер на требуемый адрес.
Первый способ это использование доменных групповых политик. Метод прост и удобен, за исключением момента смены имени proxy-сервера или его переносе на другой IP адрес. В зависимости от настроек доменные политики могут обновляться в различных временных промежутках(по умолчанию 1 раз в 45 минут), что может повлечь за собой задержку применения новых настроек.
Вторым способом является раздача ссылки на proxy сервер через DHCP. Метод безусловно хороший, за исключением необходимости перезагружать компьютер или вызывать процедуру обновления IP адреса на компьютере пользователя. К сожалению метод работает только для Internet Explorer.
Третий способ это создание вспомогательного WPAD(Web Proxy Auto-Discovery) домена и файла wpad.dat, которые позволяют динамически менять настройки подключения к прокси-серверу, всего-лишь путём закрытия/открытия браузера. Для обеспечения работы механизма необходимо создать в текущем домене(DNS зоне по умолчанию) запись WPAD IN A с указанием IP адреса вебсервера с которого будет скачиваться файл автоматической конфигурации. В корне этого сервера необходимо разместить файл wpad.dat. Файл представляет собой кусок javascript кода, который в зависимости от различных условий может отдавать различные адреса прокси сервера для различных адресов и доменов, а также указывать метод доступа к ресурсам. Описание формата файла wpad.dat можно найти в интернете. Единственным условием успешного использования wpad файла является отключение его кеширования в доменной политике предприятия. Время кеширования этого файла по умолчанию достаточно велико, в связи с чем лучше обеспечить его обновление при открытии новой сессии.
Идеальный ACL
Squid позволяет создавать правила для разграничения доступа основываясь на определенных условиях и ответах внешних программ или аутентификационных модулей.
Изменение конфигурационного файла сквида, а также файлов вызываемых из конфигурационного файла(внешние списки пользователей или доменов и т.д), требуют перезапуска процесса squid. При изменении конфигурационных файлов и перезапуске squid возможен вариант падения процесса сервера. К сожалению в высоконагруженных системах с сотнями пользователей случайная остановка сервера чревата красным телефоном примерно через несколько секунд. Понятное дело, что нахождение проблемы скорее всего не займёт много времени, но нервы будут испорчены разъярёнными пользователями.
Идеальным вариантом является создание одного внешнего acl который будет рулить доступом вместо squid, но не будет требовать перезагрузки процесса прокси-сервера. Вариант внешнего acl может быть как двухзвенным, так и трёхзвенным. Всё зависит от архитектуры которая Вам удобна.
Множество администраторов используют модули управления доступом типа SAMS, SquidGuard, Rejik и прочие. Эти модули используют двухзвенную структуру. Squid обращается к внешнему редиректору и анализирует ответы от него. В тот же самый момент есть маленький набор утилит либо web интерфейс, который изменяет конфигурационные файлы редиректора. Но при обновлении этих файлов всётаки нужен рестарт squid как процесса-хозяина для обновления настроек редиректоров.
Практически идеальной является схема при которой squid+редиректор(с логикой) с одной стороны, независимый блок хранения настроек и обслуживающий сервер с другой. Т.е. блок с настройками скажем это база данных в SQL или в memcached. А редиректор это агрегатор запросов, который из базы данных вытаскивает необходимую информацию для определения доступа пользователя. Обслуживающий же сервер это инструмент для формирования базы доступа. В данном случае остановки и перезапуска сервера squid не требуется и все настройки можно менять в реальном режиме времени.
Практическое решение
Возникает резонный вопрос «Почему это до сих пор не реализовано?»
Ответ на него простой «Не существует универсального инструмента под все случаи жизни, каждый выбирает инструмент который его устраивает»
Так получилось, что поиски инструмента для нашей компании не увенчались успехом. В одних инструментах не хватало гибкости конфигов, в других скорости работы и надежности редиректоров. Смешивание нескольких инструментов в единую конфигурацию зачастую ведет к тотальной несовместимости и увеличению трудозатрат на поддержание системы.
Поэтому мы решили реализовать свой вариант. Данный вариант является рабочим прототипом и нацелен в основном на тестирование нагрузки, которую может дать proxy сервер с 600-1000req/сек.
Сразу оговорюсь, что основной задачей данного прототипа было ограничение доступа пользователей согласно определённым категориям с динамическим изменением списков доступа в реальном режиме времени.
Еще более конкретной задачей было оградить пользователей от посещения фишинговых сайтов, а также сайтов с malware и прочими гадостями.
Для примера был взят сервис opendns, позволяющий категоризировать сайты и ограничивать доступ для определенных адресов включая функцию родительского контроля.
В чём смысл работы сервиса OpenDNS?
OpenDNS предоставляет пользователю возможность выбрать некоторое количество категорий и перенастроить свои DNS серверы на сервера OpenDNS для обеспечения функции фильтрования. Когда посещаемый сайт попадает в одну из категорий которую выбрал пользователь, пользователю возвращается подмененный IP адрес сайта ведущий на страницу блокировки с перечислением категорий сайта.
Взяв эту страницу за основу можно написать маленький скрипт возвращающий по запросу список категорий сайта.
#!/bin/sh
wget "http://block.opendns.com/controller.php?url=$1&ablock=" -q -O - | grep '<p class="light">' | sed -E 's/(.*)in: (.*)/\2/' | sed -E 's#</.>##'
Список категорий сайтов вполне конечен, он может быть вынесен в отдельный файл и пронумерован для дальнейшего использования.
Итак. Мы имеем файл с категориями пронумерованными скажем от 1 до 40, имеем список пользователей(IP адресов) которых мы хотим оградить от посещения малвари и фишинговых сайтов. Какой метод проверки категорийности нам выбрать в редиректоре?
Вариантов несколько, все имеют своё преимущество и недостатки. По умолчанию мы будем использовать кеширование сайтов и принадлежащих им категориям. Т.е. перед проверкой категории сайта мы сначала смотрим в кеш, а потом если категории в кеше нет, то обращаемся к сайту категоризатора. Редиректоров при этом должно быть несколько, чтобы исключить задержки и увеличить скорость обработки.
Вариант 1: SQL таблица
Пользователи и разрешенные им категории живут в sql таблице, кешированные имена доменов и их категории живут там же. Всё удовольствие будет занимать 1-2 запроса.
Основная проблема будет в момент распухания количества кешированных доменов и их категорий, она частично решается введением правильных индексов, но при 600 запросах в секунду выборка из таблицы в несколько тысяч записей может оказаться довольно долгой и ресурсоёмкой операцией. Для обновления данных нам будет необходимо ввести поле timestamp по которому мы будем удалять записи старше определённого возраста. Удалять записи можно из скрипта по крону или через определенное количество запросов прямо из редиректора.
Вариант 2: MemCached
Вариант с моей точки зрения более удобный, так как позволяет делать простые таблицы и работать с данными в виде «Ключ=Значение». Скорость выборки из memcached намного выше скорости выборки из SQL, поэтому нагрузка на сервер может быть существенно снижена. Однако данный вариант требует установки дополнительного демона memcached, а также наличия достаточного количества памяти на машине. Схема позволяет кластеризовать обслуживание запросов, а также использовать один инстанс для нескольких прокси серверов.
Вариант 3: Perl Cache::FastMmap
Облегченная версия memcached(образно говоря) которая позволяет использовать файл лежащий на диске в качестве shared memory объекта. Несколько клиентов могут работать с этим файлом одновременно и читать/хранить данные в виде «Ключ=Значение». Также эта схема обеспечивает сохранность данных при падении редиректоров или самого демона squid.
Мы выбрали последний вариант, так как он давал большую гибкость при работе на локальной машине.
Схема хороша еще и тем, что в качестве категорий можно подгружать любые внешние списки адресов сайтов, а также блоков IP адресов. При таком построении системы можно использовать любое количество категоризаторов. Скажем для блокировки Tor сети достаточно только загрузить список Tor серверов обновляя его по кронтабу и назначив Tor серверам определённую категорию. Тоже самое с malware доменами. Для ускорения обработки данных по IP адресам можно использовать Radix Tree, но это зависит от задач которые Вы решаете.
При работе с базой Cache::FastMmap мы сделали схему при которой максимально ускорена обработка данных.
Категории для пользователей описываются в формате: ip_cat=perm
где IP — ip адрес пользователя
cat — номер категории
perm — правило(allow/block)
Данные для адреса 0.0.0.0 являются общими для всех и позволяют блокировать или открывать нужные категории всем пользователям, оставляя возможность персональной блокировки/разблокировки для каждого конкретного случая.
Категории сайтов были в формате domainname=cat1;cat2;cat3 и т.д.
Так как Cache::FastMmap имеет встроенный механизм удаления устаревших данных, то проблема с контролем за обновлением базы отпала сама собой.
Эффективность кеширования результатов оказалась довольно хорошей.
Помещено сайтов в кеш: 125077 объектов
Прочитано сайтов из кеша: 4226793 объектов
Здесь не учитываются повторы объектов помещенных в кеш. Просто общие данные вход/выход.
Собственно чем я хочу закончить этот пост.
Используя современные механизмы обработки данных можно построить быструю и производительную систему обеспечивающую все потребности по ограничению доступа для пользователей.
Какую систему будете строить Вы — решать только Вам. Механизмы которые тут описаны очень легко воспроизводимы на любом языке программирования.
Если кому-то интересны исходники редиректора на perl, могу выложить, но там очень мало интересного ;)
UPD: Дабы не быть голословным выкладываю скрипты для работы с opendns.
aborche.com/tst/squid/catserver.pl.txt — категорийный демон который таскает категории с opendns.com
aborche.com/tst/squid/testfilter.pl.txt — скрипт который ждёт на стандартном вводе имени домена и отсылает его на категорийный сервер(используется для тестирования и проверки)
aborche.com/tst/squid/pradm.pl.txt — редиректор для squid который запрашивает сайты у категорийного демона и решает пускать или нет.
aborche.com/tst/squid/categories.conf — файл с категориями
aborche.com/tst/squid/squid.conf — пример вызова редиректора из squid.
© Aborche 2009