Как стать автором
Обновить

Трудности администрирования прокси серверов в больших компаниях (Часть 2)

Время на прочтение 9 мин
Количество просмотров 9.4K
В предыдущей статье я описал основные проблемы подстерегающие администраторов в больших компаниях.

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


Напомню исходные данные:
— SQUID 3.0 with pf transparent mode
— Внешний категоризационный сервис Orange Filter Database
— Количество клиентов 300-350
— пиковое количество запросов до 300 в секунду
— Внутренний категоризатор с данными сайтов bigblacklist, rejik и прочих.

Проблема первая: DHCP
Использование статически прописанных адресов компьютеров в больших сетях является моветоном с точки зрения администрирования сети, и несет в себе много других проблем. Однако и DHCP не является панацеей решения всех проблем.
Рассмотрим случай использования AD и ISC-DHCPd. Основной проблемой является правильная синхронизация базы адресов DHCPd в AD. Вариантов тут не много. Открывать корневую доменную зону на «Unsecure» модификацию чревато возможным спуфингом(подменой) адресов в сети. Доменные компьютеры при получении адреса по DHCP и при инициализации сетевого интерфейса, при загрузке машины, автоматически регистрируются в DNS на домен контроллерах(если не указана другая настройка). Проблемы начинаются при подключении в сеть компьютеров не имеющих отношение к домену. Сразу отмету вопросы про MS DHCP Server. Microsoft DHCP сервер конечно всем хорош, за исключением удобства управления им, а также работы с масками мак адресов для динамической конфигурации устройств. Но речь не о нём. Для того чтобы правильно зарегистрировать обратную зону без использования MS DHCP Server лучше всего использовать связку ISC-DHCPd и ISC-Bind. На Bind поднимаются обратные зоны для ваших подсетей и настраивается обновление зон по ключу, путём прописывания ключа в конфиг dhcpd и bind. На домен контроллерах обратные зоны ставятся как secondary или forward для правильного обратного резолва. При выдаче адреса хосту, dhcpd автоматически обновит обратную зону на bind, а bind пошлёт сигнал обновления зоны домен контроллерам.

Проблема вторая: Выключенные хосты
Использование FQDN для хостов разрешенных к доступу в конфигах squid и прочих приводит к тому, что в один прекрасный момент, если хост давно не обновлял свои A и PTR записи, его имя не будет найдено в DNS. Что в свою очередь приведёт к падению процесса который пытался это имя отрезолвить(если не используется какой-либо workaround для этой проблемы). Занесение всех имён хостов в /etc/hosts при использовании dhcpd приводит к несвоевременному обновлению информации. Одним из вариантов решения является авторизация в редиректоре по имени хоста с предварительным обратным резолвом IP адреса.
Что это даёт? Данная схема позволяет не привязываться к IP адресу хоста увеличивая гибкость настройки. Схема проста:
— в external acl отправляются данные в виде "<IP Address> <URI>"
— для адреса делается gethostbyaddr и результат сравнивается с настройками external acl
— для уменьшения нагрузки на DNS результат gethostbyaddr кешируется на определённое количество времени.
— если полученное имя нам не подходит — правило не применяется, если подходит — применяется.

Проблема третья: «Нельзя то, что можно другим. Можно то, чего другим нельзя»
Проблема не столько конфигурационная, сколько логическая и общая для всех систем контроля доступом. Большинство систем управления доступом подразумевают однозначное определение прав. Либо «разрешено», либо «запрещено». Без учёта возможного вхождения ресурса в несколько категоризационных групп. Лучшим вариантом разграничения доступа будет использование методов проверки «allow,deny» и «deny,allow».
Примем по умолчанию «allow = 0, deny = 1».
Для метода «allow,deny» будет работать правило логического ИЛИ, сначала мы разрешаем доступ ко всему и проверяем вхождение домена в запрещающую категорию. (0 or 1 = 1)
Для метода «deny, allow» будет работать правило логического И, сначала мы запрещаем доступ ко всему и проверяем вхождение домена в разрешающую категорию. (1 and 0 = 0)

Проблема четвёртая: «Внешняя категоризация доменов»
Большинство существующих на данный момент решений категоризации для squid подразумевают под собой использование offline баз данных переведённых из текстовых файлов, скачанных из интернета, в формат какой-либо базы данных понятной редиректору. Обычно это BerkeleyDB со всеми вытекающими отсюда удобствами и неудобствами. BerkeleyDB очень удобна для обработки больших объёмов данных, но абсолютно неудобна при контроле за содержимым этих баз данных, так как у неё отсутствует элемент контроля времени жизни значения. В итоге для обновления базы необходим её повторный отчёт с полным сбросом ранее внесённых данных. Лучшим вариантом работы с базой является дифференциальное или инкрементальное обновление данных внутри базы.
Почему я завёл речь о внешней категоризации доменов?
При большой нагрузке на сервер, категоризирование домена основанное на внешних источниках данных может привести к возникновению перегрузки. Для балансировки и выравнивания нагрузки необходимо промежуточное кеширование полученных данных от категоризационного сервера.
Рассмотрим вариант блокировки TOR соединений при помощи dnsbl. Для этого существуют две доменные зоны tor.dan.me.uk и torexit.dan.me.uk, первая содержит список tor клиентов, вторая содержит список tor нод которые могут маршрутизировать трафик через себя. При нагрузке от 100 до 200 запросов в секунду — в минуту мы получим 6000 или 12000 запросов на dns сервер. Не каждому локальному DNS серверу такая нагрузка будет по душе. Можно уменьшить количество запросов к dnsbl серверу путём исключения проверки всех хостов к которым происходит обращение, а также ограничением проверки для хостов которые инициируют соединения. Так или иначе, чем больше внешних категоризационных сервисов мы используем для определения категории хоста или домена, тем больше системных ресурсов мы должны на это потратить.
Какой выход из данной ситуации?
Выход по моему мнению только один. Это использование механизмов кеширования запросов с возможностью регулирования времени жизни в кеше. Обновление кеша можно производить как полной перезаливкой данных, так и путём дифференциального и инкрементального обновления. Система должна работать автоматически без участия администратора и не «падать» при недоступности какого-либо используемого ресурса.
Этот же метод категоризации домена можно использовать для определения открытых прокси серверов, malware и прочих вредоносных серверов. Список dnsbl доменов можно найти на www.robtex.com/ip/127.0.0.1.html#blacklists. Многие из Вас сейчас захотят сказать: «так это dnsbl списки использующиеся для проверки почты на спам!», но ответ будет прост: «чем отличается проверка хоста на принадлежность к спаму от проверки на принадлежность к malware? ничем !»
Еще раз хочу предупредить, что данная схема может вызвать очень сильное снижение скорости доступа в сеть в зависимости от доступности DNS серверов и количества передаваемых запросов.

Проблема пятая: «Один домен второго уровня, много доменов третьего уровня и выше»
Как разрешить домены третьего уровня, запретив домен второго уровня? Часть блокировочных сервисов подразумевают однозначную блокировку домена по имени домена второго уровня. Белые списки доменов конечно есть, но зачастую они действуют на всех. Рассмотрим вариант с ограничением доступ к домену «yandex.ru»(как пример многоуровневого дерева доменов). У нас есть необходимость дать одному пользователю доступ только к почте и календарю, закрыв всё остальное в этом домене. А другому разрешить всё в этом домене кроме почты. Самый простой метод решения это сделать это в виде: «user1: +mail.yandex.ru +calendar.yandex.ru -yandex.ru», «user2: -mail.yandex.ru». Но не все редиректоры позволяют такую схему. По сути своей, методика вычисления разрешения для домена второго уровня такая же как для домена третьего и выше уровней за исключением того, что корневой домен второго уровня может не иметь категории. Корневой домен второго уровня для ускорения поиска должен иметь информацию о доменах верхних уровней, чтобы уменьшить количество проверок.
Скажем есть домен «vasya.pupkin.home.drive.narod.ru», мы имеем определённую категорию для домена третьего уровня — drive.narod.ru — «Users Drives», в то время как домен второго уровня «narod.ru» может быть категоризирован как «Users Homepages». Вполне понятно, что имея 2 категории для домена второго и третьего уровней, бессмысленно проверять домены уровней выше третьего. Например мы запросили url «vasya.super.puper.good.narod.ru». Первой проверкой должен стать домен «good.narod.ru», т.к. у нас есть информация, что у нас есть категоризированный домен в доменах третьего уровня. Если на данном уровне категория для запрашиваемого домена найдена не будет, то будет проверен уровень следующий ниже(т.е. второй) и в итоге запрашиваемый url получит категорию «Users Homepages» всего за два прохода проверок вместо 5.

Проблема шестая: Корректная идентификация пользователя на внутренних информационных ресурсах
При перенаправлении пользователя на страницу которая объясняет почему заблокировано соединение, возникает ситуация при которой информационная страница видит вместо адреса пользователя — адрес прокси сервера. Можно использовать внутренние заголовки прокси сервера типа «Forwarded for» и «via proxyaddress», но это достаточно небезопасно для путешествий вне компании. Поэтому лучшим решением будет использование скрипта автоматической конфигурации клиентского компьютера(WPAD). Поиск по гуглу даст Вам исчерпывающую информацию о методах конфигурирования данного файла. Смысл заключается в том, что при автоматической настройке браузера пользователя можно задавать на какие ресурсы нужно идти через прокси сервер, а на какие идти напрямую. Например на внутренние интранет сайты нету никакого смысла ходить через прокси.

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

Проблема восьмая: proxy failover и целостность конфигурации
Если у Вас большая сеть, то рано или поздно всё-таки встаёт вопрос о резервировании сервера. В данном случае камнем преткновения является целостность и идентичность конфигурации на всех ваших прокси серверах. Хочется иметь конфиг где-то централизовано и управлять тоже из любого места без привязки к какому-нибудь серверу. Вынос конфига в memcached или mysql был бы идеальным вариантом.

Вот. К чему собственно я всё это писал? :)
Хочу поделиться со всеми желающими своей разработкой.
Проект называется PRADM(Proxy Administration Kit)
В настоящее время в проект входят два компонента. Это редиректор обеспечивающий контроль доступа и категоризационный сервер позволяющий работать со списками ресурсов, ip адресов и бесконечным количеством категорий. Оба компонента рассчитаны на непрерывную работу и управляются в реальном режиме времени без необходимости дёргать squid для обновления конфигурации.

Все компоненты написаны на perl с использованием некоторого количества внешних модулей:
memcached 1.4.4
perl 5.8.9 (with defined-or)
Cache::Memcached::Fast
Digest::MD5
URI::URL
MIME::Base64

основные места расположения некоторых файлов(для тех кто захочет попробовать)
pradm — /usr/local/squid/scripts
category server — /usr/local/squid/catdbserver/
логи pradm — /usr/local/squid/logs/redir.log
конфиг pradm.conf — /usr/local/etc/squid/pradm.conf

Состав компоненты pradm:
pradm.conf.example — пример конфига
pradm.pl — скрипт редиректора
md5.pm — вспомогательный модуль с сервисными функциями
squid.conf — пример файла squid.conf для вызова редиректора как external acl
reloadconfig.pl — скрипт загружающий конфигурацию в memcached
showperm.pl — скрипт показывающий данные по заданному хосту
Директория web:
error.cgi — скрипт обеспечивающий вывод информации о блокированном ресурсе, а также управляющий продлением доступа в сеть(должен лежать в /cgi-bin/ вашего веб сервера ссылка на который указана в squid.conf
stop.gif и wpad.dat — должны лежать в DocumentRoot вашего веб сервера ссылка на который указана в squid.conf

Состав компоненты catdbserver
README — краткая информация как пользоваться загрузчиком категорий.
categoryloader.pl — скрипт формирующий файл базы данных для категорийного сервера.
catserver.pl — сам категорийный сервер
testfilter.pl — скрипт проверки работоспособности вашего категорийного сервера.
updatelists.sh — скрипт выгрузки списка malware domains с внешних ресурсов и загрузки их в категорийный сервер.

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

Исходники проекта:
aborche.com/pradm/source/pradm.tar.gz
aborche.com/pradm/source/catdbserver.tar.gz

Пока что в разработке категорийный сервер под SQL(сервер готов, оптимизируется скорость добавления доменов в базу). Также в разработке memcached категорийный сервер(есть проблемы с индексированием данных в базе memcached сервера)
Краткая аннотация по возможностям проекта aborche.com/pradm
Если есть вопросы — то задавайте, с удовольствием на них отвечу.

Aborche 2010
Теги:
Хабы:
+53
Комментарии 22
Комментарии Комментарии 22

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн