Целью данных записок является создание простой в управлении и, в то же время, гибкой в настройке системы фильтрации интернет трафика. Строить мы ее будем на основе 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 является использование знака "?" в адресной строке запроса. Например адрес одного из баннеров Украинской баннерной сети выглядит так :

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

Обращаю Ваше внимание на строку 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. Ну а Вы как всегда берите новейший.

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

# 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

# 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. Многие наступают на грабли с версией базы данных. Судя по разговорам на форумах многие люди как и я лично убедились на собственной шкуре, в том неприятном факте что удачной сборки удалось достигнуть только с версей базы 3.2.9. В свою очередь, Berkeley DB не соберется без libtool. Довольно запутаная получается цепочка. Но бояться не стоит. Берем из коллекции портированных приложений и как обычно, выполняем распаковку, копиляцию, а затем и установку.:

# tar zxvf libtool-1.3.4.tar.gz
# cd libtool-1.3.4

# ./configure
# gmake 
# gmake install

С выполнение этих действий не должно возникнуть никаких сложностей. Скачиваем Berkeley DB 3.2.9. Забираем два патча здесь или . И снова:

# 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 

Распаковываем и компилируем:

# 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:

# gmake 
# gmake test 
# gmake install 

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

# mkdir /usr/local/squidGuard/log

Официальный список блокируемых доменов можно взять на сайт Так же доступен список от <. И еще один хороший список от . Кратко сравним их между собой:

Итак, вполне очевидно, что лучше всего взять список 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 появилось несколько поддиректорий. В свою очередь, в каждой из них лежат файлы:

Если бы мы взяли официальный список 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

}

rewrite mp3 {

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

log rewr_mp3

}

dest porn {

domainlist porn/domains

urllist porn/urls

log porn

}

dest ads {

domainlist ads/domains

urllist ads/urls

log ads

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

}

dest banners {

domainlist banners/domains

expressionlist banners/expressions

urllist banners/urls

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

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

}

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

}

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 

log default

}

}

Кстати не забудьте скачать мою баннеров. Потом вы сможете вносить в нее свои собственные записи. Иначе при запуске 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 раз. Поэтому мы напишем для перестройки баз и перезапуска 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 к редиректору выглядит так:

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

redirector_bypass on

redirect_program /usr/local/squidGuard/bin/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

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

В качестве маленького бонуса можно наладить автоматическое обновление базы доменов. Для скачивания файла базы доменов нам понядобится программа . Конечно можно было обойтись и стандартным fetch. Но все же wget работает надежнее. Распаковываем и ставим как обычно.

# tar zxvf wget-1.8.2.tar.gz
# cd wget-1.8.2
# ./configure
# gmake
# gmake install

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

# where wget

/usr/local/bin/wget