Блог Гисматуллина Марата о компьютерах: squid

Показаны сообщения с ярлыком squid. Показать все сообщения

воскресенье, 19 октября 2008 г.

Система фильтрации интернет траффика на основе squidGuard + Apache + Squid + Berkeley DB

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

Вы можете спросить зачем нам нужны все эти сложности? Как любой другой ресурс интернет траффик имет обыкновение заканчиваться. Да и канал от нас к провайдеру не резиновый, Отсюда вывод - необходимо тем или иным образом ограничить аппетиты пользователей. С другой стороны если начальство поймает кого-то из сотрудников за просмотром порносайтов или скачиванием 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 сервера. А мультимедий файлы скачиваемые пользователями можно подменять на лету своими собственными заготовками, что позволит донести до пользователя добавочную информацию. Только представьте себе пользователь качает музыку в формате mp3 запускает ее в winamp и слышит строгий голос директора отчитыващий его за такое хулиганство.

Обоснование выбора редиректора SquidGuad

Многие администраторы уже столкнувшиеся с вышеописанным комплексом проблем могут утверждать, что они легко решатся с помощью штатных средств 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 претендовали squirm и Jesred. После тестирования от squirm пришлось отказаться, потому что список фильтрации поддерживается всего один на всех пользователей. Соответственно запретить что-либо конкретному пользователю не представляется возможным. Запрещать приходится либо всем, либо никому. К тому же список сайтов приходится хранить в виде довольно сложных и неудобных для восприятия регулярных выражений. По моему мнению, такое ограничение не позволяет использовать squirm в сетях средних и больших размеров.
Затем мне под руку попался Jesred. Несмотря на то, что Jesred является модернизированным потомком squirm и имеет более гибкий синтаксис файла шаблонов, он все еще страдает от тех же детских проблем. Единственное улучшение в этой области достаточно высокая скорость работы и возможность пропускать запросы некоторых пользователей без фильтрации. Как Вы понимает в этом случае ни о каком гибком разграничении полномочий пользователей и речи быть не может.

Используемый нами SquidGuard тоже является редиректором. Давайте коротко опишем его возможности.

* может разрешить доступ некоторой группе пользователей только к некоторым сайтам
* блокирует доступ пользователей к определенному списку адресов
* позволяет запретить доступ к определенному списку адресов
* помогает блокировать доступ к сайтам на основе списка регулярных выражений
* запрещает пользователям использовать IP адреса вместо доменных имен внутри URL
* позволяет запретить доступ к определенному списку адресов
* дает возможность перенаправить пользователей, пытающихся получить доступ к запрещенным страницам, на другую страницу, где им будет объяснена причина запрета
* помогает перенаправить запросы на доставку часто скачиваемый файлов, таких как MSIE, Netscape Navigator или ICQ, к их локальным копиям
* позволяет использовать разные политики доступа в зависимости от времени дня, текущей даты, дня недели
* дает возможность гибкой настройки процесса протоколирования обрабатываемых запросов

Платформа и вспомогательное ПО

Ну что же, теперь когда с формальностями и изучением начальной теории покончено, приступим к установке.
Как я уже говорил строить нашу систему фильтрации мы будем на основе FreeBSD 4.5 + Squid + SquidGuard + Berkeley DB 3.2.9 + Apache.

Стоит отметить что обсуждаемые в этой статье приемы будут работать и на основе Linux. В принципе такой комплекс можно построить на любой Unix совместимой системе. Главной проблемой будет неоходимость найти версии SquidGuard и Squid для этой системы. Вместо Apache можно использовать любой другой Web сервер. Кстати Web сервер можно запустить на одельной машине под управлением любой операционной системы. В то же время можно использовать уже существующий Web сервер. Не стоит отчаиваться, если база данных Berkeley DB еще не портирована для Вашей платформы. SquidGuard легко может работать и без нее. Я думаю, нижеприведенных инструкций по настройке Apache и Squid хватит, что бы установить их в комплектации по умолчанию. Для получения более подробных сведений вам стоит посетить следующие сайты:

http://apache.lexa.ru
http://www.squid-cache.org
http://squid.opennet.ru

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

Установка и настройка Squid

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

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

# mkdir /usr/local/squid/cache

А тут у нас будут лежать журналы работы Squid.

# 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 у нас заработал. Идем дальше.

Установка и запуск Apache

Теперь примемся за установку Russian Apache. Если вы желаете то можете использовать стандартный 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

Кладем туда 1×1gif и 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. Можно использовать его, но все же лучше взять слегка модифицированный мною вариант. Мой, скрипт наверно, лучше, потому что руссифицированный. На его исправление ушло почти два часа., впрочем это еще не показатель качества исправлений, поэтому используйте мой скрипт на свой страх и риск.

Установка SquidGurad, Berkeley DB, libtool

Итак, все подготовительные работы окончены, и самое время взяться за установку squidGuard 1.2.0. Для его работы необходимо иметь Berkeley DB 3.2.9. Многие наступают на грабли с версией базы данных. Судя по разговорам на форумах многие люди как и я лично убедились на собственной шкуре, в том неприятном факте что удачной сборки удалось достигнуть только с версей базы 3.2.9. В свою очередь, Berkeley DB не соберется без 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/files/patch_329.tar.gz. И снова:

# 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 < prefix="/usr/local/squidGuard" db="/usr/local/BerkeleyDB.3.2" config="/usr/local/squidGuard/squidGuard.conf" logdir="/usr/local/squidGuard/log" dbhome="/usr/local/squidGuard/db" prefix="/usr/local/squidGuard" db="/usr/local/BerkeleyDB.3.2" config="/usr/local/squidGuard/squidGuard.conf" logdir="/usr/local/squidGuard/log" dbhome="/usr/local/squidGuard/db" type="download&file="bigblacklist." clientaddr="%a&clientname="%n&clientident="%i&clientgroup="%s&targetgroup="%t&url="%u" clientaddr="%a&clientname="%n&clientident="%i&clientgroup="%s&targetgroup="%t&url="%u" clientaddr="%a&clientname="%n&clientident="%i&clientgroup="%s&targetgroup="%t&url="%u" clientaddr="%a&clientname="%n&clientident="%i&clientgroup="%s&targetgroup="Not_Authorized&url="%u"> /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

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

URL адрес клиента разделитель метод запроса
http://test.ru/win2000/setup.exe 127.0.0.1/ - GET

Для того чтобы проверить как squidGuard будет реагировать на запросы пользователей, скачиваем написанную мною тестовую программу 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 добавляем строки:

redirector_bypass on
# если не один из экземпляров squidGuard не
# отвечает, то работать напрямую
redirect_program /usr/local/squidGuard/bin/squidGuard
# где находится squidGuard
redirect_children 1
# сколько экземрляров squidGuard запускать

Перезапускаем 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

Если они есть, значит все работает как положено. Теперь сделаем так, что бы 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. Конечно можно было обойтись и стандартным 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

Пишем скрипт, который будет выкачивать обновления с сайта 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. Теперь осталось раздать всем пользователям подабающие права и можно отдыхать.

Автор Бешков Андрей
Взято на сайте onix.opennet.ru

Настройка squidGuard

SquidGuard - это очень полезное дополнение к Squid. Возможностей у него предостаточно, часто админы не используют и половину из них. С помощью squidGuard можно отфильтровывать и переадресовывать запросы по адресам, именам и регулярным выражениям. Определяет пользователей по адресам и логинам, которые можно распределять по группам с заданием собственных настроек и указанием временного промежутка.

Например, разрешить группе посещать только ресурсы из белого списка. Для ускорения обработки больших списков они хранятся в BerkeleyDB. Установка в Ubuntu сложностей не вызывает:

$ sudo apt-get install squidguard

Подключается squidGuard к Squid так же, как и остальные редиректоры, просто добавляем в squid.conf строку для запуска:

redirect_program /usr/bin/squidGuard
# Если конфигурационный файл находится в другом месте, указываем его так:
# redirect_program /usr/bin/squidGuard -c /usr/local/etc/squid/squidGuard.conf
redirect_children 5
redirector_bypass on

Все настройки squidGuard производятся в конфигурационном файле /etc/squid/squidguard.conf. Но вначале нужно пояснить структуру БД. Переменная dbhome указывает на каталог, в котором хранятся описания ресурсов. В Ubuntu и некоторых других дистрибутивах - это /var/lib/squidguard/db. При установке с помощью пакетов этот каталог пуст, поэтому придется самому позаботиться о его наполнении. Список blacklist можно взять как из архива исходных текстов программы, так и выбрать любой по ссылке Blacklists на сайте проекта. Списки, предлагаемые сторонними организациями, гораздо полнее и обновляются чаще, поэтому их и будем использовать. Например:

$ wget –c http://www.shallalist.de/Downloads/shallalist.tar.gz
$ sudo tar xzvf shallalist.tar.gz –C /var/lib/squidguard/db

В результате внутри обнаружишь целую структуру каталогов с названиями вроде ads, warez и прочее. Порядок следования очень важен, ведь в правилах указывается путь относительно dbhome. Внутри каждого каталога могут находиться следующие файлы:

- domains – список доменных имен и адресов сайтов (ad.count.com);
- urls – список конкретных ссылок на ресурс (site.com/banners);
- expressions - список регулярных выражений, ожидаемых в URL (adult|girls|avi|mp3 и т.д.).

Списков expressions в большинстве blacklist мало, и злоупотреблять ими не стоит, так как их использование сильно нагружает систему.
Еще один момент, связанный с обновлением списка. Например, может возникнуть ситуация, когда нужно добавить или убрать ресурс из balcklist, если это сделать в одном из указанных выше файлов, то при обновлении все изменения будут потеряны. Чтобы избежать этого, сохраняй изменения в нужном подкаталоге в файлах с расширением diff. Например, рядом с оригинальным domains пишем domains.diff. Формат его прост:

+ads.domain.com
-domain.com

Первый ресурс будет добавлен в базу, второй убран. При обновлении списка ситуация не изменится.

Создаем правила

Если в Squid ресурсы блокируются при помощи связки acl+http_access, то в squidGuard таких параметров намного больше. Например, чтобы описать и затем блокировать ресурсы, содержащие рекламу, добавляем следующее правило:

$ sudo mcedit /etc/squid/squidguard.conf

dest adv {
domainlist adv/domains
urllist adv/urls
expressionslist adv/expression
redirect http://localhost/block.html
}

dest warez {
domainlist warez/domains
urllist warez/urls
}

# И теперь создаем ACL
acl {
default {
pass !adv !warez all
}
}

В примере была создана категория adv, в которой при помощи трех параметров domainlist, urllist и expressionslist были подключены файлы, находящиеся в каталоге /var/lib/squidguard/db/adv. Описания для остальных ресурсов создаются также. Названия можно брать любые, обычно их выбирают по названию каталога или по назначению, чтобы потом легче было ориентироваться. В документации приведен список зарезервированных слов, советую с ним познакомиться. Список ACL с действием default является правилом по умолчанию.
Параметр dest аналогичен acl в squid.conf, то есть описывает внешний ресурс. Чтобы указать клиентские подключения, применяется src, в качестве значения ему можно передать: отдельный IP-адрес, адрес сети, домен или список пользователей.

src clients {
ip 192.168.1.2-192.168.1.50
}

src admins {
ip 192.168.1.55, 192.168.1.150
}

Временной диапазон задается просто:

time workhours {
weekly mtwhf 09:00-18:00
date *.04.01
}

Под описание work-time попадают дни от понедельника по пятницу (используются первые буквы английских слов) и время с 9 до 18. Плюс сюда же входит первое апреля каждого года.
Время можно использовать прямо в описании клиентов:

src managers {
ip 192.168.0.0/24
within workhours
}

Или непосредственно в acl. Теперь все описания собираем в конфиге:

$ sudo mcedit /etc/squid/squidguard.conf

acl {
# Этой группе режем все, и пускать менеджеров будем только в workhours
managers {
pass !warez !chat !porno !agressive !drugs !ads all
}
# В рабочее время режем все
clients within workhours {
pass !warez !chat !porno !agressive !drugs !ads all
} else {
pass !ads all # после работы только рекламу
}
# На то мы и админы
admins {
pass !adv all
}
default {
pass !adv all
}
}
Для упрощения я не добавлял описания ресурсов chat, porno и других. Когда правила записаны, создаем базу и устанавливаем права:

$ sudo squidGuard -d -C all
$ sudo chown -R squid /var/lib/squidguard/db/*

Хотя делать это необязательно, при первой загрузке базы будут созданы автоматически, но так можно убедиться в отсутствии ошибок. Для обновления конкретного списка вместо all указываем на конкретный файл. Если обновление производится из diff файла, то используем параметр ‘–u‘:

$ sudo squidGuard -u /var/lib/squidguard/db/ads/domains.diff

После чего перезапускаем Squid и проверяем работу.

Аутентификация пользователей в Squid

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

Squid поддерживает несколько вариантов аутентификации. Для проверки подлинности задействуется внешняя программа. Этого можно добиться, использовав тип ACL proxy_auth и указав в параметре auth_param (ранее authenticate_program) программу для аутентификации.

acl USERS proxy_auth REQUIRED
http_access allow USERS
http_access deny all
auth_param /usr/lib/squid/ncsa_auth /etc/squid/passwd
auth_param children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours

В первых трех строках объявлен новый acl и при помощи http_access разрешен доступ для всех клиентов, входящих в данный список. Значение REQUIRED указывает на то, что любой пользователь, прошедший аутентификацию, будет допущен. Как вариант, здесь можно прописать конкретные логины. В строке ниже указываем программу для аутентификации и расположение файла паролей. В разных дистрибутивах месторасположение ncsa_auth отличается. Найти его просто:

$ dpkg -L squid3 | grep ncsa_auth

Или для RPM:

# rpm -ql squid | grep nsca_auth

Параметр children позволяет задать максимальное количество процессов, используемых для аутентификации. Небольшое количество процессов может замедлить процесс аутентификации пользователей. Используя realm, можно определить сообщение Squid, выводимое юзеру в окне ввода пароля. В принципе, текст здесь можно ввести и на русском, только вот как он будет выведен пользователю, зависит от настроек браузера. И, наконец, credentialsttl указывает время кэширования пароля.
Файл паролей создается при помощи утилиты htpasswd, которая входит в состав пакета Apache. Создадим пользователя grinder:

$ sudo htpasswd -c /etc/squid/passwd grinder
New password:
Re-type new password:
Adding password for user grinder

Напомню, что ключ ‘–с‘ используется только однажды (для создания файла), в дальнейшем добавляем учетные записи с ключом ‘-b‘. Для удобства пароль можно указывать прямо в командной строке:

$ sudo htpasswd -b /etc/squid/passwd user 123456

Перезапускать Squid при изменении списка пользователей не требуется. Чтобы никто другой не мог получить доступ к файлу паролей, следует установить соответствующие права:

$ sudo chmod 440 /etc/squid/passwd
$ sudo chown squid:squid /etc/squid/passwd

Пробуем подключиться к прокси-серверу. Чтобы не вводить каждый раз логин и пароль, их можно указать в настройках клиентского браузера.

вторник, 23 сентября 2008 г.

SQUID: Настройка прокси-кэширующего сервера

Когда нужно предоставить совместный доступ к Web-сервисам с возможностью кэширования трафика, в первую очередь вспоминают о кэширующем прокси-сервере Squid. Это гибкое решение применяют и в мелких офисах с несколькими пользователями, и в корпоративных сетях со сложной топологией. Разберем, как настроить в Squid самые популярные функции - контроль доступа и работу с кэшем.

Для новичков - пара слов о самом Squid. Squid, он же “кальмар” (www.squid-cache.org) - приложение, позволяющее организовать прокси/кэширующий сервер для HTTP, FTP и некоторых других популярных протоколов. Поддерживается работа с защищенными TLS/SSL соединениями, кэширование DNS, возможно использование Squid в качестве прозрачного или реверсного прокси. Распространяется по лицензии GNU GPL. Работает во всех популярных вариантах Unix систем - GNU/Linux, *BSD, MAC OS X, SunOS/Solaris. ЕСть и для Windows.
В качестве примера буду использовать Ubuntu, как более удобного дистрибутива, но сказанное относится и к остальным дистрибутивам или ОС (установка происходит по разному, в различных дистрибуивах). Надо отметить, что сейчас параллельно развивается две ветки: 2.х и 3.х.Третья ветка перешла в разряд Stable в конце прошлого года, и разработчики рекомендуют ее к использованию. В репозитарии Ubuntu, начиная c Festy Fawn (7.04), есть и пакеты с третьей версией Squid. По описываемым в статье параметрам отличий у них практически нет, возможно только некоторые специфические.
Установка кальмара в Ubuntu довольно проста:
$ sudo apt-get install squid squid-common

Или, для Squid 3:
$ sudo apt-get install squid3 squid3-common
После инсталяции Squid будет запущен с установками по умолчанию. При первом запуске возможна ошибка “FATAL: Could not determine fully qualified hostname. Please set ‘visible_hostname’”. Это значит, что по дефолту разрешение имени узла, на котором работает Squid, осуществляется при помощи gethostname(). В зависимости от установок DNS он иногда не может однозначно определить имя, которое будет фигурировать в журналах и выводах об ошибках “Generated … by server.com (squid/3.0.STABLE2)”, поэтому просит тебя помочь. Все настройки Squid производяться в единственном файле /ect/squid/squid.conf. В нем до невероятности много параметров и бросаться менять их все и сразу не стоит. Просмотреть список парметров, убрав пустые и закомментированные строки, можно при помощи команды:
$ sudo grep -v “^#” /ect/squid/squid.conf | sed -e ‘/^$/d’
Формат squid.conf стандартен для Unix. Каждая запись состоит из строк вида: “параметр значение”. Строки, начинающиеся со знака решетки, - комментарии. Для удобства настройки все параметры разбиты по секциям. разбиение чисто условно и свои параметры можно заносить в любое место файла. Возможно подключение внешнего файла с настройками при помощи include. Помни, что установки применяются в порядке очередности.
Для начала запустим Squid, устранив ошибку, указанную выше. Заносим в конфиг строку с именем сервера Squid (необязательно должно совпадать с доменным):
visible_hostname mysquid
И запускаем:
$ sudo /ect/init.d/squid start
В настройках по умолчанию сквид принимает входящие соединение на 3128/tcp. Командой “netstats - ant / grep 3128″ проверяем, слушается ли этот порт. Если все ОК, настраиваем веб-браузер для работы через прокси-сервер и выходим в Сеть. Но сейчас это возможно только с localhost. Чтобы в интернет могли попасть остальные пользователи локальной сети, нужно установить соответствующие разрешения, используя контроль доступа.

НАСТРАИВАЕМ ДОСТУП

Изменив параметр http_port, мы можем подвесить Squid только на внутренний сетевой интерфейс:
http_port 192.168.0.1:3128
Чтобы разрешить всем пользователям сетей 19.168.0.0, 172.16.0.0 и компьютера 192.168.1.1 подключаться к Squid, добовляем описание нового списка доступа в секцию “ACCESS CONTROL”:
acl localhost src 192.168.0.0/24 172.16.0.0/12 192.168.1.1
Переменные чувствительны к регистру, но, применив параметр “ac1 -i”, это можно исправить. Чуть дальше покажу как. Если нужно настроить доступ не для всей сет, а для отдельных ее узлов, проще записать их адреса в файл (по одному в строке), которой и указать в качестве последнего параметра. Третья строка - тип списка доступа. В нашем случае используется src (от source). При помощи других параметров можно задать внешний адрес (dst), MAC-адрес (arp), деменное имя (srcdomain,dstdomain), порт (port), протокол (proto), время (time) и много друго. Фактически, работа по организации доступа сводится к описанию объекта в acl, а затем разрешению или запрету работы объекта при помощи http_access с требуемыми параметрами. Например, чтобы указать рабочее время, применем такую конструкцию:
acl work_hours time M T W T F 9:00 - 18:00
В описании используется первые буквы английского языка, соответствующие дням недели. В секции “ACCESS CONTROL” уже описаны некоторые ACl, в частности, описываются номера некоторых портов (привожу не все) b ACL, соотвестствующий всем адресам:
acl SSL_ports port 443 563 873
acl Safe_ports port 80 21 443 563 1025-65535
acl all src 0.0.0.0/0.0.0.0
Следует внимательно просмотреть весь список и закомментировать строки с портами ненужных или неиспользуемых сервисов. Когда списки составлены, при помощи параметра http_access разрешаем или запрещаем доступ указанному ACL. Общий формат вызова такой:
http_access allow|deny [!]название_ACL
Восклицательный знак инвентирует значение списка, то есть звучит, как “все кроме”. По умолчанию используется правило:
http_access deny all
Его мы обязательно помещаем в конец списка рулесетов. В этом случае все соединения, которое не разрешены явно, будут блокированы. Майнтэйнеры, собирающие пакеты в дистрибутивах, как правило, добавляют и несколько своих правил.
Чтобы разрешить подключение к Squid с указанных адресов и работу только с нужными портами, пишем:
http_access allow localnet
http_access deny !Safe_ports
http_access deny !SSL_ports
Сохраняем результат и перезапускаем Squid:
$ sudo/ect/init.d/squid restart
Проверяем. Если все нормально, идем дальше. Чтобы не перерастраивать клиентские системы, проще использовать iptables:
iptables -t nat -A PREROUTING -i eth1 \
-p tcp -m tcp –dport 80 -j DNAT \
–to-destination 192.168.0.1:3128

iptables -t nat -A PREROUTING -I eth0 -p tcp -m tcp \
–dport 80 -j REDIRECT –to-ports 3128
А вот ее один пример. Нам нужно, чтобы компьютеры с определенными IP могли выходить в инет только в рабочее время. Без проблем:
acl workip src 192.168.1.100 192.168.1.200-
192.168.1.210
http_access deny!work_hours workip
Получается не очень читабильно, но можно сделать так:
http_access allow work_hours workip
http_access deny workip
первая строка разрешит доступ при совпадении двух ACL: рабочее время и IP-адрес. Вторая запретит доступ всех записанных в ACL workip при несовпадении с первым правилом (тоесть в другой временной промежуток).

ЗАПРЕТ БАНЕРОВ И САЙТОВ

Одна из функций, которая делает Squid востребованным, - зпрет доступа к определенным интернет ресурсам. Это реализованно на той же сладкой парочке: acl и http_access. Зная адрес ресурса, можно просто закрыть доступ к конкретному адресу или целевой подсети:
acl denynet dst 194.55.0.0/16
http_access deny denynet
Но всмето того, чтобы использовать адрес, удобнее при помощи dstdomain указать домен назначения. Например, запретим доступ к сервисам вроде RapidShare:
acl rapida dstdomain .rapidshare.com .rapidshare.de
http_access deny rapida

НАСТРОЙКА КЭША

Борьбас баннерами - не единственная возможность сэкономить трафик. нельзя обойти стороной настройку кэширования. В Ubuntu кэш по умолчанию размещается в каталоге /var/spool/squid. В других дистрибутивах может быть иначе. Чтобы не искать, посмотри значение переменной cache_dir. Формат ее такой:
cache_dir type путь размер L1 L2 [options]
Например:
cache_dir ufs /var/spool/squid 10249 16 256
Поле type определят тип кэша: ufs (unix file system), aufs и diskd. Обычно используется ufs как наиболее надежный. Максимальный размер, после которого кэш будет очищаться, установлен по умолчанию в 100 Мб. При серьезных нагрузках он быстро заполнится, поэтому есть смысл увеличить его до нескольких гигабайт (я увеличил до 10 Гб). Удобно, что можно использовать несколько cache_dir, установив кэш на разных дисках, - положительно скажется на производительности. В Squid каждый кэшируемый объект распологается в отдельном файле, а сами файлы не сваливаются в одно место, благодаря механизму работы с двухуровневой иерархией каталогов. Количество каталогов первого и второго уровней определяют параметры L1 и L2. По умолчанию их значения 16 и 256, соответственно. Дополнительно для каждого cache_dir можно определить параметр read-only (только чтение) и max-size (максимальный размер объекта).
Максимальный размер объекта в кэше определяется переменной maximum_object_size. значение по умолчанию - 4Мб, есть смысл его увеличить:
maximum)object_size 10240 KB
Аналогично, есть пример minimum_object_size, отвечает за минимальный размер объекта, по дефолту он отключен (значение 0).Объем ОЗУ, используемый Squid для хранения обрабатываемых объектов, определяется пармаетром cache_mem (по умолчанию - 8 Мб). при большом размере кэша лучше увеличить это значение, тем более что объемы современных ОЗУ это позволяют. Иначе Squid будет сбрасывать всю информацию на диск, что замедлит его работу. Но это еще далеко не все. например, отключенный по умолчанию параметр reload_info_ims разрешает игнорировать nocache или reload и выдать объект из кэша. Это нарушение стандарта HTTP, но большинство серверов умеют корректно обрабатывать такой запрос, поэтому включаем:
reload_into_ime on
Вместо глобальной установки можно задать такой параметр для некоторых типов файлов.
Документация на странице reload_into_ims отсылает нас к не менее интересной директиве refresh_pattern, которая управляет параметрами кэширования:
refresh_pattern [-i] regex min percent max [options]
В regex пишем регулярное выражение, которое будет отвечать правило. Проверка производится до первого совпадения. Поэтому последним всегда устанавливается “.” - то есть правило для всех объектов. Параметр min и max указывают на минимальное и максимальное время в минутах, в течение которого объект считается новым. В percent указывается процент от времени последней модификации объекта. В min рекомендуется устанавливать 0, чтобы корректно работать с динамически обновляемыми страницами. В версии Squid 2.x по умолчанию используется инструкции:
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher:1440 0% 1440
refresh_pattern . 0 20% 4320
В версии 3.0 перед “.” добавлена строка:
refresh_pattern (cgi-bin|\?) 0 0% 0
В поле options через пробел указываются дополнительные параметры. В версии 2.х параметров семь, в 3.х добавилось еще два. Большинство из них идут в разрез со стандартами HTTP, и их использование может вызвать проблемы при работе с некоторыми серверами. Однако они весьма полезны для оптимизации кэша и понадобятся в дальнейших настройках:
- override-expire - в нарушение стандарта заставляет игнорировать параметр expire, то есть время актуальности объекта;
- override-lastmod - игнорирует время последней модификации объекта, переданного сервером;
- reload-inti-ims, ignore-reload - изменяет или игнорирует клиентские запросы nocache или reload и принудительно выдает объект, хранящийся в кэше;
- ignore-no-cache, ignore-private, ignore-auth - игнорирует заголовки “Pragma: no-cache”, “Cache-control: no-cache”, “Cache-control: private” и “Cache-control: public”, принудительное кэшируя такой объект. Параметры, появившиеся в третьей версии:
- ignore-no-store - Игнорировать заголовок “Cache-control: no-store”;
- refresh-ims - заставляет проверять наличие новой версии файла при получении от клиента if-Modified-Since.
В самом простом случае вместо правил по умолчанию можно написать одно правило, заставляющее принудительно кэшировать объекты на целый год:
refresh_pattern . 518400 80% 518400
override-expire override-lastmod reload-into-ims
ignore-no-cache ignore-private ignore-auth ignore-no-store
Устанавливаем размер кэша побольше и забываем о Squid. Это даст весьма ощутимую экономию трафика. Но таокй подход не всегда приемлен, да и кэш быстро заполнится старыми файлами. Поэтому лучше установить свои варианты кэширования для различных типов файлов. Например, часто на сайтах проектов экзешники, архивы и некоторые другие типы файлов имеют постоянный адрес, вроде server.com/current.exe. Укажем для таких файлов время хронения в месяц:
refresh_pattern \.exe$ 43200 100% 43200
override-expire override-lastmod reload-into-ims
ignore-no-cache ignore-private ignore-auth ignore-no-store

refresh_pattern \.zip$ 43200 100% 43200
override-expire override-lastmod reload-into-ims
ignore-no-cache ignore-private ignore-auth ignore-no-store
И так далее. Схожим образом “вырезаем” рекламу. Так как довольно трудно создать универсальное правило для acl/http_access и всегда можно допустить ошибку, рекламу проще кэшировать, чем блокировать:
refresh_pattern http://ad\. 43200
100% 43200 override-expire override-lastmod
reload-into-ims ignore-no-cache ignore-
private ignore-auth ignore-no-store
refresh_pattern http://click\. 43200
100% 43200 override-expire override-lastmod
reload-into-ims ignore-no-cache ignore-
private ignore-auth ignore-no-store
refresh_pattern http://count\. 43200
100% 43200 override-expire override-lastmod
reload-into-ims ignore-no-cache ignore-
private ignore-auth ignore-no-store
Это наиболее простой способ. При тщательном изучении логов можно составить коллекцию URL, которые стоит поместить в вечный кэш.
В настройки Squid, не так уж и сложен. Если не считешь удобную ручную настройку, обратись к Webmin, где большинство установок можно произвести в наглядной форме. Базовая настройка занимает минут 10. После определенной доводки пользователи будут радоваться скорости открытия страниц, да и по карману сильно не ударит.