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

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

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


    Мифы о наличии прокси сервера

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

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

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

      +2
      >>Если кому-то интересны исходники редиректора на perl, могу выложить, но там очень мало интересного ;)

      Экий вы интеллигентный, аж противно :)
      Выкладывайте-выкладывайте. Интересно…
        +2
        aborche.com/tst/squid/
        ну вот как-то так. Там правда не особенно интересно.
        +1
        очень и очень интересно, поскольку openDNS сервис весьма популярный а приличного редиректора для него пока никто не написал.
        использование же сервиса напрямую, не даёт такой гибкости как хотелось бы
          +1
          в апдейте скрипты для опроса opendns в режиме реального времени.
          +1
          я бы даже сказал что некоторое how to вполне уместно… раз уж сказали А… то говорите и Б тоже :)
            0
            ниже текст адресован вам.
            0
            выше по ссылке сам кеширующий редиректор.
            на порту 6051 сидит сервер который дёргает категории.
            Вариант с opendns самый простой, потому что он доступен всем и бесплатен.
            Вариант на который затачивались мы, это база OrangeWeb Filter, которая входит в состав продуктов IBM, которая естественно стоит денег. Принцип один и тотже. Даёшь сайт — получаешь категорию. Проблема в том, что расшифровать базу OrangeWeb Filter нельзя, а вот зацепиться к ней удалось. Разобрав формат взаимодействия с родным редиректором я написал свой демон который дергает из базы категории сайтов. Открыть доступ на online скрипт проверки не решусь, ибо опасаюсь хабраэффекта. В привате могу дать ссылку для доступа к базе через web интерфейс.
              0
              мы используем на данный момент обвязку squidGuard + urlblacklist.com. Тоже присматривались к OrangeWeb Filter/Можете в личку скинуть скрипт на посмотреть?
                0
                OrangeWeb входил в состав Kerio WinRoute, а зимой они его заменили на свою разработку WebFilter, котороая первые полгода была заметно хуже решения IBM, да и сейчас иногда встречается какой-нибудь сайт Администрации Удмуртии, находящийся в категории порно :-)
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  В апрейте к посту скрипты. можете потестить.
                  нужен catserver.pl и testfilter.pl
                  ставите модули IO::Multiplex + LWP::Simple, запускаете catserver.pl

                  на соседней консоли запускаете testfilter.pl и кормите его именами доменов
                  –3
                  >Миф3
                  любой человек знает что это бред. дома у каждого в россии уже стоит 1+мбит/с, а на работе бывает столько же на всю контору в 50-500 человек.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Вы тэг айрони потеряли или действительно так считаете?
                        0
                        похоже тэг «замкадье» был бы акутальнее
                      0
                      Terms of Use не нарушаете? Нет риска что они вас как-нибудь отрубят и пользователи всей сети не смогут пользоваться интернетом?
                        0
                        в отношении OpenDNS? а чем отличается запрос урла блокировки от запроса урла для категоризации. Я не использую их DNS сервера. Они просто напросто не нужны.
                          0
                          Ну сервис это их хлеб как бы. Им нужно поставлять вам (вашим пользователям) контент в неизменном виде.

                          Нет времени читать полностью но там сразу бросается в глаза:

                          «Except as expressly authorized by OpenDNS in writing, you agree not to sell, license, rent, modify, distribute, copy, reproduce, transmit, publicly display, publicly perform, publish, adapt, edit or create derivative works from such Content.»

                          «Reproducing, copying or distributing any Content, materials or design elements on the Site for any other purpose is strictly prohibited without the express prior written permission of OpenDNS.»

                          «OpenDNS may terminate your access to all or any part of the Service at any time, with or without cause, with or without notice, effective immediately.»
                            0
                            Сервис оно конечно их хлеб, только хлебом их кормят сами пользователи которые категоризируют сайты у них на проекте.
                            В данном посту использование сервиса ничем не отличается от штатного использования их DNS серверов для категоризации. В любом случае скачивается страница блокировки с сайта, в любом случае идут банерные показы с этой страницы блокировки. Кликов вот только нет.
                            Это примерно равносильно утаскиванию иконки с погодой с gismeteo.ru, только с тем учётом, что тащится не иконка, а страница целиком.
                            Данная статья призывает думать немного по другому не руководствуясь общепринятыми стандартами и шаблонами настройки squid. Категоризатор opendns это всеголишь пример для оптимизации определённых повторяющихся действий.
                              0
                              Штатный сервер насколько я понимаю на закрытые и несуществующие DNS показывает рекламу.

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

                              Кроме того, автоматическим способом занижаете CTR объявлений, что наверняка не понравилось бы рекламодателям и оператору рекламы.

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

                              Категоризация сайтов это непрерывная довольно трудоемкая задача, вряд ли вообще существуют провайдеры такого рода контента которые будут раздавать его бесплатно.

                              Я вообще считаю что ограничивать интернет пользователям техническими методами по типу содержимого нельзя.
                                0
                                это настолько же нелегально как использовать поисковые машины в процессе раскрутки сайтов. и вариант того, что раскручиваемый сайт будет забанен на поисковике тоже есть. В любом случае принимая то или иное решение каждый для себя оценивает риски. Что рискованней? утечка данных в интернет или возможность быть заблокированным за нецелевое использование?
                                Техническая блокировка скажем по ежечаснообновляемым именам malwaredomains это один из лучших вариантов ограничения возможности поступления к Вам какойлибо гадости. Использование антивирусов не всегда эффективно, особенно по отношению к новым червям и троянам. Блокировка тора из той же серии.

                                неделю назад кто-то из сотрудников словил какую-то гадость. Касперский о ней не знал, но категоризатор пристрелил возможность гадости отправить нужные данные наружу.

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

                                  Если ваш антивирус не работает — смените его, введите правильный ACL на компьютерах пользователей и используйте SRP.

                                  Чтобы находить уже зараженные компьютеры известными вирусами, используйте IDS/IPS-системы.

                                  Чтобы блокировать непредумышленные утечки используйте DLP-систему.
                                    0
                                    это не наезд, просто обсуждаю возможности :)
                                      0
                                      вы как я посмотрю идеалист ;) но не бывает абсолютно защищённых систем кроме тех у которых выключено питание.
                                      С известными вирусами справляется Каспер, с неизвестными ISS OrangeFilter входящий в состав IBM MFS. Но и в них есть дыры, простой запрос по malware доменам в категоризатор ISS, показал что больше половины сайтов из malware списка там просто не учтены.
                                        0
                                        мне сама идеология не нравится блокирования по категориям, да еще и по домену: отправлять инфу малварь может и на твитер, и на айпишник, и на домен третьего уровня и по smtp (так они кстати и делают).

                                        Без анализа контента на месте трудно что-то определить. У тех пользователей, инфа которых поценнее надо ограничивать например побольше — отключатьб iframe например, или яваскрипт и прочее.

                                        Сам лично антивирусы вообще на пользовательских компах не ставлю, т.к. не вижу в них смысла — использую SRP.
                                          0
                                          если уж делать эффективную систему то надо учитывать категоризацию и домен как некий оценочный бал используемый в расчете общего бала, который включает и другие факторы — заголовки запроса например, а не принимать решение о блокировке на основе самого домена.
                                            0
                                            сразу видно что у вас нету банк-клиентов ;) попробуйте там отключить iframe и javascript. ага
                                              0
                                              Почему нет, есть. В таких случаях блокируется файрволом все кроме банк-клиента.
                                              В случаях биржевой торговли на ммвб/ртс соединение устанавливается внутри приватной сети.
                                                0
                                                позвольте поинтересоваться из какой Вы финансовой компании или банка?
                                                  0
                                                  Моя компания предоставляет услуги ит-поддержки. Компания «Кадмус» cadmus.ru
                                                    0
                                                    просто некоторые клиенты — брокерские конторы и банки.
                                                      0
                                                      мне их жаль. увы.
                                                        +1
                                                        у меня есть благодарственные письма :)
                                                      0
                                                      Если услуги поддержки такие же как на этом сайте soft.cadmus.ru/, то у вас очень перспективная команда.
                                                        0
                                                        НЛ есичо ;)
                                                          0
                                                          Иронию зачел.

                                                          Этот домен, что очевидно, в работе не используется.

                                                          Вам просто неинтересно дальше продолжать диалог?
                                                            0
                                                            смотря о чем. это стало больше похоже на чат и прикладывание линейки к разным местам.
                                                              +1
                                                              Я стараюсь привести аргументацию, которая критикует ваше решение с блокировкой домена по категории предоставленной провайдером контента.

                                                              Я распинаюсь т.к. так получилось что я прочитал статью еще вчера у вас в ЖЖ и поэтому есть мысли на этот счет.
                                                                0
                                                                Без проблем. давайте обсудим этот момент.
                                                                Сможете ли Вы создать список сайтов скажем для блокировки файлообменников?
                                                                rapidshare, ifolder и т.д.?
                                                                Сами собственноручно если руководство поставит перед Вами такую задачу. Как Вы поступите? возьмёте готовый список или потратите несколько недель на выяснение списков этих серверов? Какова вероятность вашей ошибки и её цена для компании?
                                                                  0
                                                                  Ну на месте менеджера я бы задался вопросом — зачем блокировать файлообменники?

                                                                  А на месте исполнителя сказал бы что это невозможно.

                                                                  Но, например, смог бы контролировать все файлы отправляемые POST и больше 10 мб на уровне логгирования и архивированные под паролем на уровне принятия решения на основе анпрмиер от какого пользователя файл.
                                                                    0
                                                                    принятия решения об отправке POST-а*
                                                                      0
                                                                      Ваши сотрудники никогда не участвовали в закрытых тендерах или презентациях. При условии того, что пользователям необходим доступ в интернет, но ограничена возможность отправки документов куда либо доступными средствами.
                                                                        0
                                                                        я говорю что некоторым можно, а некоторым нет. Но контролируются по этому признаку все и всегда можно увидеть что какой-то пользователь сливает что то большое.

                                                                        Да и ни это обсуждаем, просто предложил как варинат для решения задачи с файлообменниками.

                                                                        Это вообще не сильно актуально, т.к. если сотрудникам нужен какой-то доступ (вообще, любой), а он перекрыт то они говорят об этом ит-службе, берут ответственность за использование доступа и получают его.
                                                  0
                                                  Кстати, компьютеры с выключенным питанием могут украсть, или они могут сгореть при пожаре :)
                                                0
                                                в предпоследней строке имел ввиду: неизвестными вирусами.
                                      0
                                      Сомневаюсь что OpenDNS будут мелочиться и отрубать какую то Российскую от которой кол-во запросов не превышает 50к в день, у них в день по несколько биллионов их и ничего живут
                                        0
                                        ну дело не в том что могут-не могут, а в том — законен такой метод или нет :)
                                          0
                                          Хорошо переформулируем вопрос, если они не могут определить значит законен, и еще можно положим в локальной сети поставить DNS сервер BIND например организовать на нем DNS кэш и сделать что бы он передавал запросы на OpenDNS сервера, при правильной настройке на стороне OpenDNS будет виден только 1 IP — от BIND
                                            0
                                            ну т.е. если что-то воровать и никто об этом не знает, то делать это можно и законно, а если узнали то нет? :)

                                            Кстати, в статье вообще не упоминают о DNS сервисе.
                                              0
                                              С каких пор DNS запросы воровство?
                                                0
                                                В статье вообще не упоминают о DNS сервисе.
                                                0
                                                если еще раз прочитать абзацы про OpenDNS там написано, что «при попадании сайта в определенную категорию пользователю отдаётся подменный IP адрес который ведет на страницу блокировки»
                                                Зачем использовать DNS если Вы сразу можете попасть на страницу блокировки.

                                                Если Вы знаете, что на той остановке на которой Вы стоите останавливается нужный Вам транспорт, зачем спрашивать об этом у прохожих?
                                                  0
                                                  ну вот и я говорю — кеш днс не нужен т.к. dns вы не использовали. :)
                                                    0
                                                    давай спросим у opendns что они думают по этому поводу, зачем гадать?
                                          0
                                          Интересно, а почем не рассмотрены такие «классические» редиректоры, как rejik и squidGuard?
                                          Поддержка ACL, BerkleyDB в роли хранилища — очень приличная скорость получается
                                            0
                                            у BerkleyDB есть одна проблема, чтобы обновить данные из файла его нужно перечитать. При нагруженной системе перечитывание файла размером в несколько метров и засасывание его в память может занимать достаточное количество времени. попробуйте в squid прогрузить список в несколько тысяч доменов.
                                            Про rejik и squidGuard я уже написал выше. они классические, но для применения настроек требуют рестарта squid. в случае редиректора с кешируемыми запросами к внешним acl серверам рестарт не нужен в принципе. Всё происходит в realtime.
                                              0
                                              Проделанная вами работа вызывает уважение и realtime правка acl — это круто, но на деле даже обновление бан-листов режика не приводит к хоть скольно-нибудь значимым перебоям в раздаче интернета. исключительно личный опыт.
                                            +1
                                            У меня всего 100 компьютеров в сети, но после squid -k reconfigure телефон не краснеет.
                                              0
                                              Абсолютно с вами согласен, вы меня опередили.
                                              Ничего страшного, если один запрос, в тот самый момент перечитывания конфига оборвется.
                                              Но если у вас крив^Wнеправильный конфиг, то нужно его сначала вручную проверить, и только потом скармлить сквиду, дабы исключить накаливания телефона.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                Всегда, первое что делаю, это меняю параметр shutdown_lifetime максимум на 5 секунд!
                                                Рекомендую вам к прочтению habrahabr.ru/blogs/squid/56290/, там это описывается.
                                                ЗЫ за эти 30 секунд, первое время, успевал столько нового о себе узнать…
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                клево!
                                                только для терминальных бездисковых станций не будет работать,
                                                в далеком 2006м описал у себя настройку по авторизации ntlm, ничо так, работало :)
                                                  0
                                                  Proxy server — ЗЛО.
                                                  UDP-трафик строем идет коту под хвост

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

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