Система фильтрации интернет-трафика::Журнал СА 4.2003
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 4900
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6152
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7390
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7734
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6786
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Система фильтрации интернет-трафика

Архив номеров / 2003 / Выпуск №4 (5) / Система фильтрации интернет-трафика

Рубрика: Администрирование /  Продукты и решения   | Дополнительные материалы

АНДРЕЙ БЕШКОВ

Система фильтрации интернет-трафика

Целью данных записок является создание простой в управлении и в то же время гибкой в настройке системы фильтрации интернет-трафика. Строить её мы будем на основе FreeBSD 4.5 + Squid + SquidGuard + Berkeley DB 3.2.9 + Apache. Стоит отметить, что обсуждаемые в этой статье приемы будут работать и на основе Linux. В принципе такой комплекс можно построить на любой UNIX-совместимой системе. Главная проблема – необходимость использования версий SquidGuard и Squid для этой системы. Apache можно заменить любым другим веб-сервером или использовать уже существующий веб-сервер. Кстати, веб-сервер можно запустить на отдельной машине под управлением любой операционной системы. Не стоит отчаиваться, если база данных Berkeley DB еще не портирована для вашей платформы. SquidGuard легко может работать и без нее.

Вы можете спросить, зачем нам нужны все эти сложности? Как и любой другой ресурс, интернет-трафик имеет обыкновение заканчиваться. Да и канал от нас к провайдеру не резиновый, отсюда вывод – необходимо тем или иным способом ограничить аппетиты пользователей. С другой стороны, если начальство поймает кого-то из сотрудников за просмотром порносайтов или скачиванием mp3, нагоняй получит не только провинившийся. Администратор будет виноват в том, что позволяет сотрудникам тратить оплачиваемый организацией трафик на всякую ерунду. В то же время стоит помнить, что каждая организация имеет свои правила использования ресурсов сети Интернет. Довольно часто в списке запретов можно встретить не только эротику, но и сайты анекдотов, форумы и чаты. Например, бесплатные почтовые сайты могут быть запрещены из соображения секретности. Одновременно можно запретить пользователям скачивать из внешней сети выполняемые файлы. Это существенно снижает опасность вирусного заражения сети.

Кроме того, перед нами все еще стоит задача экономии трафика. Существенно снизить его потребление поможет запрещение бесполезной для нас баннерной рекламы. Вы могли бы спросить, что в баннерах плохого? Squid – кеширующий прокси-сервер, соответственно, скачиваемые файлы ложатся в локальный кеш. При следующих запросах эти файлы уже не будут скачиваться из Интернета. Проблема в том, что баннерная реклама построена на применении механизма CGI (Common Gateway Interface), расшифровывается как «общий интерфейс шлюза». Характерным признаком которого является использование знака «?» в адресной строке запроса. Например, адрес одного из баннеров «Украинской Баннерной Сети» выглядит так: http://banner.kiev.ua/cgi-bin/bi.cgi?h" + user + "&"+ pid + "&" + page + "&2.

К сожалению, CGI используется не только для баннерной рекламы, но и для чатов, форумов, сетевых магазинов и прочей полезной сетевой функциональности. То есть везде, где необходимо получить от пользователя данные. Затем полученные данные должны быть обработаны, а результаты работы CGI необходимо вернуть пользователю. Значит для каждого пользователя не только запросы, но и ответы будут разными. Поэтому класть полученные документы в кеш squid бесполезно. По умолчанию squid не использует кеш при работе с динамическими документами. В свою очередь, это значит, что одни и те же баннеры будут выкачиваться бесконечно. Подменяя баннеры пустыми картинками с локального веб-сервера, можно значительно снизить количество потребляемого трафика.

Многие администраторы, столкнувшись с этими проб-лемами, могут утверждать, что они легко решаются с помощью штатных средств 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 500 МГц. Такой скорости удается добиться за счет того, что 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. На момент написания статьи это была самая свежая версия. Взять ее можно на http://www.squid-cache.org/Versions/v2/2.5. Рекомендуется всегда использовать самые новейшие из стабильных версий программ. Такой подход позволит в дальнейшем избежать многих проблем со стабильностью и безопасностью работы тех или иных инструментов.

# 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. Должно получиться примерно следующее:

# Обрабатывать запросы на порт 3128

http_port 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

# Здесь у нас будет храниться кеш. Отводим под него 5000 Мб.

# Приказываем создать 16 директорий первого уровня и 256 второго уровня.

cache_dir ufs /usr/local/squid/cache 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

ftp_user vasa@pupkin.ru

# Если Squid уже скачал 60% файла, а пользователь отказался его забирать, то все равно продолжать скачивать файл.

quick_abort_pct 60

# Время жизни запросов, завершившихся ошибкой. Например, «connection refused» или «404 Not Found»

negative_ttl 1 minutes

# Время жизни успешного DNS-запроса.

positive_dns_ttl 6 hours

# Время жизни DNS-запросов, завершившихся ошибкой.

negative_dns_ttl 5 minutes

# Поддержка нестандартных http-клиентов

half_closed_clients on

# Минимальные рекомендуемые права

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

# Ssl

acl SSL_ports port 443 563

# http

acl Safe_ports port 80

# ftp

acl Safe_ports port 21

# https, snews

acl Safe_ports port 443 563

# gopher

acl Safe_ports port 70

# wais

acl Safe_ports port 210

# unregistered ports

acl Safe_ports port 1025-65535

# http-mgmt

acl Safe_ports port 280

# gss-http

acl Safe_ports port 488

# filemaker

acl Safe_ports port 591

# multiling http

acl Safe_ports port 777

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

# Пользователь, от имени которого будет работать Squid

cache_effective_user nobody

# Группа, от имени которой будет работать Squid

cache_effective_group nogroup

# Включать ли IP-адрес клиента в заголовок http-запроса

forwarded_for on

# Разрешаем управлять кешем с помощью cachemgr.cgi. В качестве пароля будем использовать слово «passwd»

cachemgr_passwd passwd all

# Включаем сбор статистики по каждому клиенту

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. Мне кажется, что управлять доступом в одной точке гораздо удобнее. Но это опять же дело вкуса.

Настало время создать директорию, в которой у нас будет храниться кеш squid.

# mkdir /usr/local/squid/cache

А тут у нас будут лежать логи.

# mkdir /usr/local/squid/logs

Нужно позаботиться, чтобы директории /usr/local/squid/cache и /usr/local/squid/logs были доступны пользователю, от имени которого работает squid. Узнать имя этого пользователя можно так:

# cat /usr/local/squid/etc/squid.conf | grep cache_effectiv

cache_effective_user      nobody

сache_effective_group      nogroup

Получается, что пользователя зовут nobody, группа у него nogroup.

# chown -R nobody /usr/local/squid/cache /usr/local/squid/logs

# /usr/local/squid/sbin/squid -z

Внутри директории /usr/local/squid/cache создаем иерархию директорий для хранения кеш-файлов. Заглянув в /usr/local/squid/cache, вы сразу поймете, что имелось в виду под словом иерархия.

Запускаем squid.

# /usr/local/squid/sbin/squid -D

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

# tail -f /var/log/messages

Если все сделали правильно, тогда должны увидеть что-то подобное:

Oct 3 12:15:05 dns squid[139]: Squid Parent: child process 141 started

Это значит что, squid у нас заработал. Теперь примемся за установку Russian Apache. Я использовал весрсию 1.3.27 PL30.16. Ну а вы, как всегда, берите новейший дистрибутив ftp://ftp.lexa.ru/pub/apache-rus/apache_1.3.27rusPL30.16.tar.gz.

Распаковываем его и ставим в комплекте по умолчанию.

# tar zxvf apache_1.3.27rusPL30.16.tar.gz

# ./configure

# gmake

# gmake instal

Запускаем apache:

/usr/local/apache/bin/apachectl start

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

# mkdir /usr/local/apache/htdocs/replace

Кладем туда 1x1.gif и my.mp3. Берем модифицированный block.cgi и копируем его в /usr/local/apache/cgi-bin Выставляем ему нужные права:

# chown nobody:wheel /usr/local/apache/cgi-bin/block.cgi

# chmod 500 /usr/local/apache/cgi-bin/block.cgi

block.cgi – это perl-скрипт, который будет вызываться каждый раз, когда пользователь попытается посетить запрещенную страницу. Взять его можно из архива с дистрибутивом squidGuard. В первоначальном варианте этот скрипт назывался squidGuard-1.2.0/samples/squidGuard.cgi.in. Можно использовать его, но все же лучше взять слегка модифицированный мною вариант. Мой скрипт, наверное, лучше, потому что руссифицированный. На его исправление ушло почти два часа.

Итак, все подготовительные работы окончены, и самое время взяться за установку squidGuard 1.2.0. Для его работы необходимо иметь Berkeley DB обязательно версии 3.2.9. В свою очередь, Berkeley DB не соберется без libtool. Довольно запутаная получается цепочка. Но бояться не стоит. Берем libtool из коллекции портированных приложений (http://www.freebsd.org/cgi/pds.cgi?ports/devel/libtool) и, как обычно, выполняем распаковку, компиляцию, а затем и установку:

# tar zxvf libtool-1.3.4.tar.gz

# cd libtool-1.3.4

# ./configure

# gmake

# gmake install

С выполнением этих действий не должно возникнуть никаких сложностей. Скачиваем Berkeley DB 3.2.9 с http://www.sleepycat.com/update/index.html. Забираем два патча http://www.sleepycat.com/download/patchlogs.shtml. И снова:

# tar zxvf db-3.2.9.tar.gz

Копируем патч-файлы в получившуюся после распаковки дистрибутива директорию db-3.2.9. Затем применяем их для модификации исходного кода.

# cp patch.3.2.9.1 patch.3.2.9.2 ./db-3.2.9

# cd /usr/local/src/db-3.2.9

# patch -p0 < patch.3.2.9.1

# patch -p0 < patch.3.2.9.2

А теперь снова компиляция.

# cd build_unix

# ../dist/configure

# gmake

# gmake install

Забираем squidGuard-1.2.0 с http://www.squidguard.org/download. Распаковываем и компилируем:

# tar zxvf squidGuard-1.2.0.tar.gz

# cd squidGuard-1.2.0

# ./configure --prefix=/usr/local/squidGuard --with-db=/usr/local/BerkeleyDB.3.2 --with-sg-config=/usr/local/squidGuard/squidGuard.conf

--with-sg-logdir=/usr/local/squidGuard/log --with-sg-dbhome=/usr/local/squidGuard/db

Разберемся с ключами, передаваемыми программе configure:

  • --prefix=/usr/local/squidGuard – директория, в которую будет установлен squidGuard;
  • --with-db=/usr/local/BerkeleyDB.3.2 – тут находится используемая в процессе компиляции библиотека BerkeleyDB.3.2;
  • --with-sg-config=/usr/local/squidGuard/squidGuard.conf –местонахождение файла конфигурации squidGuard;
  • --with-sg-logdir=/usr/local/squidGuard/log – директория для файлов протоколов;
  • --with-sg-dbhome=/usr/local/squidGuard/db – тут будут находиться списки блокируемых сайтов.

# gmake

# gmake test

# gmake install

Cоздаем для хранения файлов протоколирования работы squidGuard директорию /usr/local/squidGuard/log.

# mkdir /usr/local/squidGuard/log

Официальный список блокируемых доменов можно взять на сайте squidGuard – http://www.squidguard.org/blacklist. Также доступен список от MESD – http://squidguard.mesd.k12.or.us/blacklists.tgz. И еще один хороший список от Dansguardian – http://blacklist.dansguardian.org/cgi-bin/download.pl?type=download&file=bigblacklist.

Кратко сравним их между собой:

База

squidGuard

Mesd

dansguardian

Комментарии

ads

 

 

 

Реклама

adult

нет

 

 

Сайты для взрослых

aggressive

 

 

 

Агрессия

audio-video

 

 

 

Музыка и видео

chat

нет

нет

 

Чаты

forums

нет

 

 

Форумы

drugs

 

 

 

Наркотики

gambling

 

 

 

Азартные игры

hacking

 

 

 

Хакерство

local-block

нет

 

нет

Сайты заблокированные местным админом

local-ok

нет

 

нет

Сайты разрешенные местным админом

mail

 

 

 

Бесплатные почтовые сервера

porn

 

 

 

Порнография

proxy

 

 

 

Общедоступные прокси-сервера

publicite

нет

 

 

Опять реклама

redirector

нет

 

 

Анонимные прокси-сервера

violence

 

 

 

Насилие

warez

 

 

 

Пиратское программное обеспечение

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

Скачав себе один из списков, распакуем его в директорию /usr/local/squidGuard/db:

# tar zxvf blacklists.tgz -C /usr/local/squidGuard

# mv /usr/local/squidGuard/blacklists  /usr/local/squidGuard/db

В директории /usr/local/squidGuard/db появилось несколько поддиректорий. В свою очередь, в каждой из них лежат файлы:

  • domains – список доменов;
  • urls – список адресов, используемых для блокирования одельной страницы, а не всего домена;
  • expression – выражения, используемые при поиске в url. Например, sex, hot, teens, porno и т. д.

Если бы мы взяли официальный список squidGuard, то внутри каждой директории можно было бы увидеть файлы обновлений к базам с такими названиями:

  • domains.20020825.diff
  • domains.20020901.diff
  • domains.20020908.diff
  • domains.20020915.diff
  • domains.20020922.diff

Внутри каждого из этих файлов находятся записи вида:

+xratedpornsite.com

+209.51.157.43

-zena.cenhost.com

-scuzz.xtac.com

Также в директории находятся файлы:

  • urls.20020825.diff
  • urls.20020901.diff
  • urls.20020908.diff
  • urls.20020915.diff
  • urls.20020922.diff

С записями вроде:

-silva.org/look_at_me

+recom.it/fuck/beatrice

Записи, начинающиеся знаком «+», – это запрос на добавление строчки в главную базу. Соответственно, строки с минусом имеют обратное назначение. К сожалению, применить файлы обновления можно только к базе в формате Berkeley DB. Выполняется это действие командой:

# squidGuard -u

Мне кажется, что такой способ обновления не очень удобен. Поэтому нам следует либо отказаться от списка доменов, составленного squidGuard, либо написать конвертор обновлений в нормальный формат.

 Разобравшись с форматом базы, приступим к конфигурированию squidGuard. Cоздаем файл /usr/local/squidGuard/squidGuard.conf. И вносим в него вот это:

# тут у нас лежат логи

logdir /usr/local/squidGuard/log

# здесь базы

dbhome /usr/local/squidGuard/db

# описываем адреса отдела ИТ

src it-department {

ip 192.168.10.222-192.168.10.223     

}

# отдел доставки

src dostavka {

ip 192.168.10.101, 192.168.10.104    

}

# отдел снабжения

src snab {

ip 192.168.10.105

}

# говорим, что все обращения к файлам *.mp3 нужно перенаправить на http://192.168.10.9/replace/my.mp3

rewrite mp3 {

s@.*.mp3$@http://192.168.10.9/replace/my.mp3@r

# и запротоколировать это событие в файле /usr/local/squidGuard/log/rewr_mp3

log rewr_mp3    

}

# описываем базу порносайтов

dest porn {

domainlist porn/domains

urllist porn/urls

# записать протокол в файл /usr/local/squidGuard/log/porn

log porn

}

# описываем базу рекламы

dest ads {

domainlist ads/domains

urllist ads/urls

# записать протокол в файл /usr/local/squidGuard/log/ads

log ads

# подменяем все баннеры прозрачным изображением размером 1x1 пиксель

redirect http://192.168.10.9/replace/1x1.gif

}

# описываем свою собственную базу баннерных систем

dest banners {

domainlist banners/domains

# в этом файле записаны выражения типа baner, banner, ads,

# show_ads

expressionlist banners/expressions   

urllist banners/urls

# перенаправляем все запросы на прозрачный gif размером 1x1 пиксель

redirect http://192.168.10.9/replace/1x1.gif

log banners     

}  

# описываем домены, которые никогда не должны блокироваться вне зависимости от списка скачиваемого из сети

dest local-ok {

domainlist local-ok/domains   

urllist local-ok/urls

}

# описываем домены, которые должны быть заблокированы всегда вне зависимости от списка скачиваемого из сети

dest local-block {

domainlist local-block/domains

urllist local-block/urls

# и перенаправляем все запросы на block.cgi

redirect http://192.168.10.9/cgi-bin/block.cgi?clientaddr=%a&clientname=%n&clientident=%i&clientgroup=%s&targetgroup=%t&url=%u 

}

# начинаем раздавать права

acl {

# отделу ИТ можно все, кроме рекламы

it-department {

pass local-ok !banners !ads all

}

dostavka {

pass local-ok !porn !banners !ads !local-block all

redirect http://192.168.10.9/cgi-bin/block.cgi?clientaddr=%a&clientname=%n&clientident=%i&clientgroup=%s&targetgroup=%t&url=%u  

rewrite mp3

}

# отделу снабжения разрешаем только то, что определено в local-ok

snab {

# так можно дать пользователю доступ только к избранным сайтам

pass local-ok none

redirect http://192.168.10.9/cgi-bin/block.cgi?clientaddr=%a&clientname=%n&clientident=%i&clientgroup=%s&targetgroup=%t&url=%u

rewrite mp3

}

# действия, выполняемые по умолчанию, если пользователь не описан ни в одном src

default {

# блокируем все

pass none

redirect http://192.168.10.9/cgi-bin/block.cgi?clientaddr=%a&clientname=%n&clientident=%i&clientgroup=%s&targetgroup=

Not_Authorized&url=%u  

# пишем логи в файл /usr/local/squidGuard/log/default

log default

}

# закрываем список acl

}

Кстати, не забудьте скачать мою базу баннеров: http://onix.opennet.ru/files/banners.tar.gz. Потом вы сможете вносить в нее свои собственные записи. Иначе при запуске squidGuard будет жаловаться на ее отсутствие и становиться в режим холостой работы. В этом режиме он будет пропускать все запросы без обработки.

Покончив с файлом конфигурации, продолжим настройку squidGuard. Даем права пользователю, от имени которого будет работать squidGuard на директории log и db. Так же поступаем и с файлом squidGuard.conf.

# chown -R nobody /usr/local/squidGuard/log/usr/local/squidGuard/db

# chown nobody    /usr/local/squidGuard/squidGuard.conf

SquidGuard может работать с текстовыми базами данных, но в таком случае при каждом запуске ему приходится создавать в оперативной памяти бинарное дерево всех загружаемых баз в формате Berkeley DB. Этот процесс занимает длительное время. Подобных задержек можно избежать, если заранее самому создать базы в нужном формате. На моей машине после создания баз время загрузки сократилось почти в 10 раз. Поэтому мы напишем скрипт (http://onix.opennet.ru/files/rebuid_base.tar.gz) для перестройки баз и перезапуска squidGuard с новыми базами.

# cat > /usr/local/squidGuard/bin/rebuid_base.sh

#!/bin/sh

/usr/local/squidGuard/bin/squidGuard -C all

chown -R nobody /usr/local/squidGuard/db

killall -HUP squid

^D

Устанавливаем нужные права доступа на файл rebuid_base.sh. Убедимся, что этот скрипт имеет право запускать только пользовать root.

# chmod 100 /usr/local/squidGuard/bin/rebuid_base.sh

# /usr/local/squidGuard/bin/rebuid_base.sh

Запустив rebuid_base.sh, необходимо дождаться нормального завершения задачи. Теперь во всех директориях, упомянутых в разделах dest конфигурационного файла, появились файлы баз данных domains.db и urls.db.

Перед тем как подключать squidGuard к squid, необходимо протестировать его локально. Для начала немного теории. Squid передает данные на стандартный ввод редиректора. Редиректор, в свою очередь, обрабатывает запрос и выдает на стандарный вывод результаты своей работы. Затем squid забирает эти данные. Редиректор отвечает на запрос от squid либо пустой строкой, если перенаправление не требуется, либо измененным URL. Формат запроса от squid к редиректору выглядит так:

URL

Адрес клиента

Разделитель

Метод запроса

http://test.ru/win2000/setup.exe

127.0.0.1/

GET

Для того чтобы проверить, как squidGuard будет реагировать на запросы пользователей, скачиваем написанную мною тестовую программу test.tar.gz (http://onix.opennet.ru/files/test.tar.gz). Распаковываем ее и кладем полученный файл test.pl в /usr/local/squidGuard/bin/. Устанавливаем файлу test.pl разрешение на выполнение. Затем запускаем test.pl и вводим тестируемый адрес. После этого в файле result.txt смотрим результаты работы squidGuard. Набор тестируемых сайтов можно изменять прямо в файле test.pl. Если результаты теста вас удовлетворили, значит самое время объединить squidGuard и Squid. В файл /usr/local/squid/etc/squid.conf добавляем строки:

# если ни один из экземпляров squidGuard не отвечает, то работать напрямую

redirector_bypass on

# где находится squidGuard

redirect_program /usr/local/squidGuard/bin/squidGuard

# сколько экземрляров squidGuard запускать

redirect_children 1

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

# killall -HUP squid

В конце файла /usr/local/squidGuard/log/squidGuard.log ищем такие строки:

2002-10-15 16:11:04 [10653] squidGuard 1.2.0 started (1034683864.337)

2002-10-15 16:11:04 [10653] squidGuard ready for requests (1034683864.353)

Если они есть, значит все работает как положено. Теперь сделаем так, чтобы Squid и Apache запускались автоматически при каждой загрузке машины.

# cat > /usr/local/etc/rc.d/apache.sh

#!/bin/sh

/usr/local/apache/bin/apachectl start

^D

# cat > /usr/local/etc/rc.d/squid.sh

#!/bin/sh

/usr/local/squid/bin/squid -D

^D

# chmod 100 /usr/local/etc/rc.d/apache.sh /usr/local/etc/rc.d/squid.sh

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

В качестве маленького бонуса можно наладить автоматическое обновление базы доменов. Для скачивания файла базы доменов нам понадобится программа wget – http://www.freebsd.org/cgi/pds.cgi?ports/ftp/wget. Конечно, можно было обойтись и стандартным fetch. Но все же wget работает гораздо надежнее. Распаковываем и ставим как обычно.

# tar zxvf wget-1.8.2.tar.gz

# cd wget-1.8.2

# ./configure

# gmake

# gmake install

Смотрим, куда он у нас установился.

# where wget

Пишем скрипт (http://onix.opennet.ru/files/rebuid_ba-se.tar.gz), который будет выкачивать обновления с сайта MESD и класть их в директорию /usr/local/squidGuard/update. Затем архив с обновлениями будет распакован и скопирован в директорию /usr/local/squidGuard/bd. После этого будет произведена перестройка баз и перезапуск squid.

#cat > /usr/local/squidGuard/bin/update_blacklist.sh

#!/bin/sh

/usr/local/bin/wget -q --cache=off "http://squidguard.mesd.k12.or.us/blacklists.tgz" -O /usr/local/squidGuard/update/blacklist.tgz

tar zxvf /usr/local/squidGuard/update/blacklist.tgz -C /usr/local/squidGuard/update/

cp -R -f /usr/local/squidGuard/update/blacklists/* /usr/local/squidGuard/bd

rm -R /usr/local/squidGuard/update/blacklists

/usr/local/squidGuard/rebuid_base.sh

^D

Теперь даем нашему скрипту нужные права.

# chmod 100 /usr/local/squidGuard/bin/update_blacklist.sh

Создадим временную директорию, в которую будут распаковываться обновления.

# mkdir /usr/local/squidGuard/update

Настраиваем планировщик на выполнение нашего задания.

# crontab -e -u root

MAILTO="admin@test.ru"

1 0 * * 7 /usr/local/squidGuard/bin/update_blacklist.sh

Назначаем выполнение обновления на 0 часов 1 минуту каждого воскресенья. Уведомление о выполнении этого задания приказываем направлять на адрес admin@test.ru. Теперь осталось раздать всем пользователям подобающие права и можно отдыхать.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru