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

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

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


    Напомню исходные данные:
    — 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
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 22

      +7
      Алиллуйа, хабр — тортъ! Спасибо.
        +1
        Годная статья, спасибо. Добавил обе части в закладки.
        Но вы себе придумали немало головной боли, настояв на transparent режиме. Зачем он нужен? Прокси архитектурно правильнее размещать «сбоку», а не «в разрыв». В разрыв полезно разве что в маленьких организациях, где прокси+шлюз+всё_остальное на одном сервере.

        Ну и не смог удержаться:
        «чем отличается проверка хоста на принадлежность к спаму от проверки на принадлежность к malware? ничем !»
        Как минимум тем, что malware-хост может и не распространять СПАМ, правило работает только в одну сторону. Соответственно в эти rbl такой хост не попадет.
          +3
          речь примерно вот об этих списках.

          xbl.spamhaus.org Illegal 3rd party exploits, including proxies, worms and trojan exploits
          zombie.dnsbl.sorbs.net — List of networks hijacked from their original owners. Some already used for spamming.
          http.dnsbl.sorbs.net — List of Open HTTP Proxy Servers.
          rbl.efnetrbl.org -Hosts are added by our bots as users connect with hacked boxes and open proxies.

          Проверка по этим спискам может дать положительный результат если вы бродите по сети в поисках кряков или в поисках прона. Залив последние списки блокировки малвари случайно обнаружил несколько хостов которые уже резолвились в ранее виденные малваревые IP, но не детектились коммерческим фильтром.
            0
            ок, понятно. Я думал в этих rbl только хосты, которые спамят.
          0
          Что за хрень под копирайтом?
            0
            кажется галактика :)
              0
              похоже на черную дыру и джет, вылетающий из неё.
              Но это изображение художника, а не фото:
                0
                Монитор статьи
                0
                Если денег недостаточно или их совсем нет, то впринципе все правильно, хотя конечно головной боли не избежать.
                  0
                  А так уж ли надо дифференцировать доступ по пользователю/компу? Взять и завернуть ВСЕХ через прокси (прозрачный или не очень — благо на это тоже есть функция автоконфигурации) без разбора и фильтровать всех по одинаковым правилам. Если босс будет сильно вопить что ему как и всем доступ вконтакт с рабочнго места закрыли, можно для таких отдельный прокси поднять с ручным прописыванием на клиенте и обычной аутентификацией с хранением пароля в конфиге прокси-сервера, их же немного таких наверняка.
                    +2
                    Вы, похоже, никогда не работали системным/сетевым администратором в действительно крупных компаниях (где несколько тысяч сотрудников). То, что вы говорите, — это наколеночные решения для мелких компаний. А топик, как видно даже из названия, по проблемам администрирования в больших компаниях.

                    В крупных компаниях помимо общих правил для всех появляется отдел разработчиков, для которых нужны специфические правила доступа (в частности права для обмена бинарными exe/dll-файлами), потом отдел дизайнеров со своими заморочками и особенностями доступа, потом отдел по связям с общественностью, которые уверены, что им выход в инет ограничивать никак нельзя, ну и конечно куча боссов разного уровня со своими ассистентами и секретаршами — и их тоже раздражают некоторые ограничения.

                    В итоге получается, что в компании достаточно разношёрстная «цветовая дифференциация штанов», а у некоторых ещё и по несколько компьютеров, поэтому и на прокси приходится делать разные правила доступа в инет для разных категорий сотрудников.
                      +1
                      а еще в крупных компаниях есть такая вещь как синдром светофора. Когда что-то вдруг останавливается на полминуты, то тебе обязательно позвонят человек 20 сразу и спросят «а у нас с интернетом всё хорошо ?»
                      Хотя ты уже видишь проблему и скорее всего уже на неё отреагировал и скорее всего уже починил.
                        +3
                        Ну если в крупной компании все процессы грамотно налажены, то все юзеры звонят не администратору напрямую, а в хелпдеск. Поэтому в случае проблем админ получит только звонок от оператора хелпдеска, который скажет о массовых звонках, уточнит в чём проблема, спросит, что отвечать юзерам и каковы ожидаемые сроки устранения проблемы, а потом все остальные сотни звонков по той же проблеме будет отфутболивать уже сам хелпдеск.
                        А самого админа по этой проблеме кроме оператора хелпдеска может потревожить разве что ещё непосредственный начальник.
                        –1
                        Да, я работал только в средних компаниях — до 100 компьютеров и до 5 филиалов по стране и почти всегда был в своей деревне царём. Всех под одну гребёнку и не-ёт. Хотите эффективную IT-систему (с максимизацией надёжности и минимизацией издержек) — извольте терпеть некоторые ограничения, налагаемые принципом KISS, ведь чем сложнее сисема — тем ниже надёжность и выше TCO, а многих усложнений можно избежать, отказываясь от тех возможностей, необходимость которых для эффективного функционирования бизнеса никто не может уверенно обосновать.
                        +1
                        система разрабатывалась изначально как helper для блокировки разной малвари. Перед ней стоял коммерческий фильтр, но коммерческие фильтра не всегда успевают обновляться :( увы. Ну и потом оно обросло тем функционалом который описан в обоих статьях. А если система умеет то что может понадобиться, то почему её не использовать на полную катушку?
                        обычная аутентификация тут тоже вполне может работать. никто не запрещает в конфиге сквида указать вместо $SRC слово $LOGIN, и авторизовывать по логину. Просто в нашей конторе с этим проблемно. Во первых грузится AD, во вторых иногда возникали никому непонятные лаги на ровном месте(речь о сквиде 2.x на котором начинала строиться система)
                        0
                        От себя добавлю, что можно (но вопрос правильно ли !) ДНС от MS вынести полностью в ISC Bind, для 2008R правда надо поставить будет патч.
                          0
                          в этом решении админ борется большей частью сам с собой чем с malware.

                          в больших компаниях: McAfee Web Gateway (Webwasher), IronPort S-Serie, BlueCoat etc. В этих продуктах вышеназванных восьми проблем просто нет.

                          с чем можно поздравить автора — что он обеспечил себя работой на годá и теперь на него все моляться включая начальство. Можно приходить теперь на работу в свитере и небритым — все равно не выгонят, потому что в перл скриптах кроме него (и L.D.Stein'a) никто не разберется.

                          • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            >>все равно не выгонят, потому что в перл скриптах кроме него (и L.D.Stein'a) никто не разберется
                            Зря Вы так, последующий админ(если умный) рано или поздно раскопает все скрипты (или свои напишет, но с комментариями) — а вот предыдущего может и «пропеарить» на местном форуме, или ответить на телефонный звонок будущего работодателя того нерадивого админа.

                            А вообще у DNS_сервисов, будь то опенднс или редиректор есть принципиальный недостаток: они не обеспечивают блокировки веб-трафика в случае, если урл содержит IP-адрес (http://81.81.81.81/virus.js) — а такие есть, и их будет все больше…
                              0
                              Тема статистики и отчетов не раскрыта. Что используйте? Всем ли довольны?
                                0
                                Статку дёргаем тогда, когда видим что за сутки улетели к 40 гигам трафика. Обычный ежесуточный трафик около 30 гигов. Два канала на балансировке через pf — (10Mbit+100Mbit ) Unlim. Используем sarg. никто другой с файлами размером свыше 300 мег работать не умеет корректно. Попытки загона данных в базу были чреваты. увы.
                                  0
                                  рекомендую попробовать lightsquid для логов… работает существенно быстрее сарга

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

                              Самое читаемое