Библиотека сайта rus-linux.net
Система фильтрации интернет траффика на основе squidGuard + Apache + Squid + Berkeley DB
Бешков Андрей
tigrisha@regata.ru
Целью данных записок является создание простой в управлении и, в то же время, гибкой в настройке системы фильтрации интернет трафика. Строить мы ее будем на основе FreeBSD 4.5 + Squid + SquidGuard + Berkeley DB 3.2.9 + Apache. Стоит отметить что обсуждаемые в этой статье приемы будут работать и на основе Linux. В принципе такой комплекс можно построить на любой Unix совместимой системе. Главной проблемой будет неоходимость найти версии SquidGuard и Squid для этой системы. Вместо Apache можно использовать любой другой Web сервер. Кстати Web сервер можно запустить на одельной машине под управлением любой операционной системы. В то же время можно использовать уже существующий Web сервер. Не стоит отчаиваться, если база данных Berkeley DB еще не портирована для Вашей платформы. SquidGuard легко может работать и без нее.
Вы можете спросить зачем нам нужны все эти сложности? Как любой другой ресурс интернет траффик имет обыкновение заканчиваться. Да и канал от нас к провайдеру не резиновый, Отсюда вывод - необходимо тем или иным образом ограничить аппетиты пользователей. С другой стороны если начальство поймает кого-то из сотрудников за просмотром порносайтов или скачиванием mp3, нагоняй получит не только провинившийся. Администратор будет виноват в том, что позволяет пользователям тратить оплачиваемый организацией трафик на всякую ерунду. В тоже время стоит помнить что разные организации могут иметь различные правила пользования интернет. Довольно часто в списке запретов можно встретить не только эротику, но и сайты анекдотов, форумы и чаты. Например бесплатные почтовые сайты могут быть запрещены из сображения секретности. Одновремнно можно запретить пользователям скачивать из наружной сети выполняемые файлы. Это существено снижает опасность вирусного заражения сети.
В тоже время перед нами все еще стоит задача экономии траффика. Существенно снизить его потребление поможет запрещение бесполезной для нас баннерной рекламы. Вы могли бы спросить что в баннерах плохого? Squid - кеширующий прокси соответственно скачиваемые файлы ложатся в локальный кэш. При следующих запросах эти файлы уже не будут скачиваться из интернета. Проблема в том что баннерная реклама построена на применении механизма CGI. CGI (Common Gateway Interface) - расшифровыается как Общий интерфейс шлюза. Характерным признаком CGI является использование знака "?" в адресной строке запроса. Например адрес одного из баннеров Украинской баннерной сети выглядит так :
http://banner.kiev.ua/cgi-bin/bi.cgi?h" + user + "&"+ pid + "&" + page + "&2
К сожалению CGI используется не только для баннерной рекламы, но и для чатов, форумов, сетевых магазинов и прочей полезной сетевой функциональности. То есть везде где необходимо получить от пользователя данные. Затем полученне данные должны быть обработаны, а результаты работы CGI необходимо вернуть пользователю. Значит для каждого пользователя не только запросы, но и ответы будут разные. Поэтому класть полученые документы в кэш squid бесполезно. По умолчанию squid не использует кэш при работе с динамическими документами. В свою очередь это значит, что одни и те же баннеры будут выкачиваться бесконечно. Резко снизить количество потребляемого траффика можно подменяя банеры пустыми картинками с локального Web сервера.
Многие администраторы уже столкнувшиеся с вышеописанным комплексом проблем могут утверждать, что они легко решатся с помощью штатных средств Squid. Я не стану отрицать что Access Control List (Списки контроля доступа) сокращенно ACL, используемые в Squid это довольно мощный инструмент. Но для работы с ним требуется достаточно большой опыт. С другой стороны трудно представить каким образом администратор будет разбираться какие сайты он должен блокировать. Остается только всед за пользователями ходить на все часто посещаемые сайты, и постепенно запрещать неугодных. Учитывая количество сайтов интернет, а так же распространенность баннерной рекламы такой путь выглядит утопией. В начале такого ошибочного пути кажется что нужно всего лишь записывать все запрещенные сайты в отдельные файлы с помошью ACL записей типа:
acl porno src "/usr/local/squid/etc/porno.lst"
acl erotic src "/usr/local/squid/etc/erotic.lst"
А затем запрещать их всех скопом. Но обслуживание такой системы способно превратиться в головную боль уже на первой тысячи сайтов. Squid загружает списки контроля доступа в оперативную память. С добавлением новых сайтов размер файла будет постоянно расти. Соответственно и Squid будет занимать все больше оперативной памяти. В связи с тем что список запрещенных сайтов не упорядочен поиск в нем будет занимать довольно продолжительное время. Для сравнения Squidguard выполняет за 12 секунд 100.000 запросов к базе содержащей 205.900 записей. Тестирование проводилось на машине с процессором Pentium 500MHz. Такой скорости удается добиться за счет того, что SquidGuard хранит список сайтов в форме B-дерева. Как мы видим средствами Squid все вышеописанное выполнить достаточно тяжело. И тут в поле нашего внимания попадает класс программ под названием редиректоры. С разной степенью легкости эти программы позволяют решать наши проблемы. Используемый нами SquidGuard тоже является редиректором. Давайте коротко опишем его возможности.
- может разрешить доступ некоторой группе пользователей только к некоторым сайтам
-
блокирует доступ пользователей к определенному списку адресов
- позволяет запретить доступ к определенному списку адресов
- помогает блокировать доступ к сайтам на основе списка регулярных выражений
-
запрещает пользователям использовать IP адреса вместо доменных имен внутри URL
- позволяет запретить доступ к определенному списку адресов
-
дает возможность перенаправить пользователей, пытающихся получить доступ к запрещенным страницам, на другую страницу, где им будет объяснена причина запрета
- помогает перенаправить запросы на доставку часто скачиваемый файлов, таких как MSIE, Netscape Navigator или ICQ, к их локальным копиям
-
позволяет использовать разные политики доступа в зависимости от времени дня, текущей даты, дня недели
- дает возможность гибкой настройки процесса протоколирования обрабатываемых запросов
В качестве кандидатов на место SquidGuard претендовали squirm и Jesred. После тестирования от squirm пришлось отказаться, потому что список фильтрации поддерживается всего один на всех пользователей. Соответственно запретить что-либо конкретному пользователю не представляется возможным. Запрещать приходится либо всем, либо никому. К тому же список сайтов приходится хранить в виде довольно сложных и неудобных для восприятия регулярных выражений. По моему мнению, такое ограничение не позволяет использовать squirm в сетях средних и больших размеров.
Затем мне под руку попался Jesred. Несмотря на то, что Jesred является модернизированным потомком squirm и имеет более гибкий синтаксис файла шаблонов, он все еще страдает от тех же детских проблем. Единственное улучшение в этой области достаточно высокая скорость работы и возможность пропускать запросы некоторых пользователей без фильтрации. Как Вы понимает в этом случае ни о каком гибком разграничении полномочий пользователей и речи быть не может.
Ну что же, теперь когда с формальностями и изучением начальной теории покончено, приступим к установке.
Я думаю, нижеприведенных инструкций по настройке Apache и Squid хватит, что бы установить их в комплектации по умолчанию. Для получения более подробных сведений вам стоит посетить следующие сайты:
В процессе компиляции всего програмного обеспечения вместо стандартного make мною использовался gmake, но это опять же вопрос личных предпочтений. Мне кажется, что gmake работает стабильнее и быстрее.
В качестве прокси сервера я использовал squid 2.5.STABLE1. На момент написания статьи это была самая свежая версия. Взять ее можно здесь. Рекомендуется всегда использовать самые новейшие из стабильных версий программ. Такой подход позволит в дальнейшем избежать многих проблем со стабильностью и безопасностью работы той или иной программы.
# tar zxvf squid-2.5.STABLE1-src.tar.gz # cd squid-2.5.STABLE1 # ./configure # gmake # gmake install
После инсталяции редактируем файл конфигурации squid, находящийся в файле /usr/local/squid/etc/squid.conf.
Должно получиться примерно следующее:
| http_port 3128 | # Обрабатывать запросы на порт 3128 |
| hierarchy_stoplist cgi-bin ? | # Запрещаем кэшировать CGI |
| acl QUERY urlpath_regex cgi-bin \? | |
| no_cache deny QUERY | |
| cache_mem 64 MB | # Размер оперативной памяти отводимой под кэш |
| error_directory /usr/local/squid/share/errors/Russian-koi8-r | #Тут мы будем брать файлы стандартных сообщений об ошибках |
| maximum_object_size 16384 KB | # Максимальный размер объекта записываемого в кэш |
| cache_dir ufs /usr/local/squid/cache 5000 16 256 | # Здесь у нас будет храниться кэш. Отводим под него места 5000 мгб. Приказываем создать 16 директорий первого уровня и 256 второго уровня. |
| cache_access_log /usr/local/squid/logs/access.log | # Протокол доступа к кэшу |
| cache_log /usr/local/squid/logs/cache.log | # Тут находится протокол работы кэша |
| cache_store_log /usr/local/squid/logs/store.log | # Протокол работы менеджера кэша |
| ftp_user vasa@pupkin.ru | # Под этим пользователем будем ходить по Ftp |
| quick_abort_pct 60 | # Если Squid уже скачал 60% файла, а пользователь отказался его забирать, то все равно продолжать скачивать файл. |
| negative_ttl 1 minutes | # Время жизни запросов завершившихся ошибкой. Например "connection refused" или "404 Not Found" |
| positive_dns_ttl 6 hours | # Время жизни успешного DNS запроса. |
| negative_dns_ttl 5 minutes | # Время жизни DNS запросов завершившихся ошибкой. |
| half_closed_clients on | Поддержка нестандартных Http клиенттов |
| acl all src 0.0.0.0/0.0.0.0 | # Минимальные рекомендуемые права |
| acl manager proto cache_object | |
| acl localhost src 127.0.0.1/255.255.255.255 | |
| acl SSL_ports port 443 563 | # Ssl |
| acl Safe_ports port 80 | # http |
| acl Safe_ports port 21 | # ftp |
| acl Safe_ports port 443 563 | # https, snews |
| acl Safe_ports port 70 | # gopher |
| acl Safe_ports port 210 | # wais |
| acl Safe_ports port 1025-65535 | # unregistered ports |
| acl Safe_ports port 280 | # http-mgmt |
| acl Safe_ports port 488 | # gss-http |
| acl Safe_ports port 591 | # filemaker |
| acl Safe_ports port 777 | # multiling http |
| acl CONNECT method CONNECT | |
| acl users src "/usr/local/squid/etc/users.txt" | # описываем наших пользователей |
| http_access allow manager localhost | # Разрешаем соединения только по правильным портам. И раздаем всем права доступа |
| http_access deny manager | |
| http_access deny !Safe_ports | |
| http_access allow users | |
| http_access deny !Safe_ports | |
| http_access deny CONNECT !SSL_ports | |
| http_access deny all | |
| cache_mgr root@test.ru | # Адрес пользователя которого будут уведомлять о переполнении кэша |
| cache_effective_user nobody | # Пользователь от имени которого будет работать Squid |
| cache_effective_group nogroup | # Группа от имени которой будет работать Squid |
| forwarded_for on | # Включать ли IP адресс клиента в заголовок Http запроса |
| cachemgr_passwd passwd all | # Разрешаем управлять кэшем с помощью cachemgr.cgi. В качестве пароля будем использовать слово "passwd" |
| client_db on | # Включаем сбор статистики по каждому клиенту |
Обращаю Ваше внимание на строку acl users src "/usr/local/squid/etc/users.txt".
Она означает, что список пользователей, которым разрешен доступ к squid, находится
в файле /usr/local/squid/etc/users.txt
Файл списка имеет следующий формат:
#Петрова Наталья (Снабжение) 192.168.10.91/32 #Иванов Владимир (Доставка) 192.168.10.92/32 #Сергеев Игорь (Плановый отдел) 192.168.10.93/255.255.255.255 #Кривоухина Ирина (Лаборатория) 192.168.10.94/255.255.255.255 #Синицына Светлана (секретарь генерального директора) 192.168.10.95/255.255.255.255
Реально в списке содержатся не имена пользователей, а IP адреса их машин. Как Вы смогли убедиться все устроено достаточно просто. Отдельный файл со списком пользователей решено использовать, что бы не захламлять главный конфигурационный файл. Users.txt должен иметь те же права доступа, что и squid.conf для того что бы squid мог читать его содержимое.
# chown nobody:nogroup /usr/local/squid/etc/users.txt
Возможен и другой вариант управления доступом к web. При это доступ в наружнюю сеть средствами squid не ограничивается. Разграничением доступа в этом случае будет заниматься SquidGuard. Для тех пользователей, чей адрес не внесен в файл /usr/local/squidGuard/squidGuard.conf, производится перенаправление на страницу запрещения. Соответственно, эти пользователи никогда интернета не увидят. Чтобы добиться такого эффекта, нужно удалить из squid.conf строки:
acl users src "/usr/local/squid/etc/users.txt" http_access allow users http_access deny all
И добавить в squid.conf вместо них строку
http_access allow all
Мне больше нравится второй вариант разграничения доступа. Если использовать традиционную схему разграничения прав, то проверка прав доступа происходит дважды. Сначала внутри Squid а затем в SquidGuard. Мне кажется что управлять доступом в одной точке, вместо двух гораздо удобнее. Но это опять же дело вкуса и эстетика чистейшей воды.
| страницы: | 1, 2, 3, 4 |  |