Squid: ограничиваем скорость, аутентифицируем клиентов и смотрим в логи
Сергей «grinder» Яремчук (grinder@ua.fm, )
Возможностей у Squid настолько много, что разработчики часто даже не успевают их подробно описывать. Общая настройка, как правило, проблем не вызывает, сложности начинаются, когда необходимо настроить ограничения на использование канала, организовать доступ к прокси при помощи внешних средств или выбрать программу для работы с журналами.
Содержание:
- Все поделим поровну
- Аутентификация в Squid
- Аутентификация в AD с LDAP
- Настройка SARG
- Заключение
- Блок-врезка
- Боковые выносы
Ситуация, когда один канал нужно справедливо разделить между пользователями, отнюдь не редкость. В Squid регулировка пропускной способности канала производится при помощи пулов. За настройки отвечает группа параметров «Delay Pools». Большинство параметров этой секции требуют компиляции squid с опцией ′--enable-delay-pools′. По умолчанию так и есть. Узнать параметры сборки установленного Squid, можно введя команду «squid –v».
Принцип ограничения скорости прост. Каждый запрашиваемый объект сначала попадает в буфер, а только затем передается клиенту. Каждый пул определяется двумя параметрами: скоростью его заполнения и размером буфера. Если объем данных меньше размера буфера, то клиент получает их с максимальной скоростью, но при достижении лимита информация будет выдаваться в соответствии с установками. По мере опустошения пула Squid будет получать остальную часть запрашиваемой информации.
Скорость заполнения пула зависит от класса. Для каждого пула при помощи delay_class должен быть установлен один из пяти классов (до версии 2.6 — один из трех):
- ограничения действительны для всех;
- действуют общие ограничения, плюс индивидуальные ограничения для отдельных хостов (биты 25 – 32 сетевого адреса);
- действуют общие ограничения, плюс индивидуальные ограничения для сетей (биты 17 — 24) и отдельных хостов (биты 17 — 32);
- все, что определено в классе 3, плюс введены ограничения для конкретного пользователя;
- запросы группируются в соответствии с их тегами, определенными при помощи external_acl.
Отсюда можно сделать вывод, что чем выше класс, тем через большее количество ограничений проходит соединение. Так для четвертого класса сначала действуют общие ограничения, затем ограничения подсети, отдельного узла и, наконец, для пользователя. То есть не стоит ожидать, что пользователь получит четко прописанную часть канала, если его подсеть выбрала свой лимит.
Класс для пула задается при помощи параметра delay_class, аргументами которого являются номер пула и номер класса. Количество пулов задается параметром delay_pools. Например, создадим два пула и определим для каждого из них свой класс. Для этого прописываем в squid.conf следующие строки:
# vim /etc/squid/squid.conf
# Задаем списки доступа, по которым будем распределять юзеров по пулам
acl office src 192.168.1.0/24
acl office2 src 192.168.2.0/24
acl user src 192.168.1.20/32
acl boss src 192.168.1.12/32
# 2 пула
delay_pools 2
# пул 1, класс 2
delay_class 1 2
# пул 2, класс 3
delay_class 2 3
Принадлежность пользователей к пулу задается при помощи delay_access, его синтаксис напоминает http_access:
delay_access pool allow/deny ACL
Поиск пула для конкретного адреса будет происходить только до первого совпадения, поэтому при объявлении пулов необходимо соблюдать нужный порядок. В одной строке следует использовать только один ACL, если прописать их несколько, в пул попадет только первый. Также как и в http_access, чтобы в него не попал «лишний» адрес, каждый пул следует закрывать при помощи конструкции deny all.
delay_access 1 allow office
delay_access 1 allow user
delay_access 1 deny all
delay_access 2 allow office2
delay_access 2 allow boss
delay_access 2 deny all
http_access allow office office2 boss user
http_access deny all
В первый пул включены клиенты, описанные в ACL office и user, во второй — office2 и boss. Следует помнить, что ACL, не указанные в delay_access, будут выходить в Сеть без ограничений. Далее при помощи delay_parameters задаем ограничения по скорости для каждого пула. В зависимости от класса пула количество аргументов будет различным. Так для четвертого класса полный формат записи выглядит так:
delay_parameters пул общий сеть индивидуальный_пользователь
Соответственно, в третьем классе не используется последний аргумент, а во втором отсутствуют «сеть» и «пользователь». Количество пар должно соответствовать классу, если что-то пропустить, сквид откажется работать. Ограничения на каждой из позиций состоят из пары скорость_заполнения/объем_пула. Но следует помнить, что значения здесь указываются в байтах, а скорость провайдеры считают в битах. В позициях, в которых нет ограничений, устанавливаем -1:
delay_parameters 1 16000/16000 8000/8000
delay_parameters 2 32000/32000 -1/-1 16000/16000
То есть для первого пула установлено общее ограничение в 128К и 64К для индивидуального адреса. Для второго общее ограничение – 256К, лимита на подсеть нет, но есть установка для отдельного IP-адреса. Для каждого пула должна быть только одна строка delay_parameters.
Используя различные типы acl (смотри майский номер за 2008 год), можно ввести ограничения по времени, протоколам, типу файлов и др. Например, при помощи такой конструкции легко ограничить скорость любителям качать мультимедиа:
acl multimedia urlpath_regex -i .mp3$ .mpeg$ .avi$
delay_pools 3
delay_class 3 1
delay_access 3 allow multimedia
delay_access 3 deny all
delay_parameters 3 8000/8000
Теперь при закачке файлов указанных типов скорость выше 64 кбит подниматься не будет. Аналогично устанавливаются ограничения по времени. Например, чтобы уменьшить для всех пользователей скорость до 32 кбит в рабочее время, применяем следующее правило:
acl work_hours time M T W T F 9:00-18:00
delay_class 4 2
delay_access 4 allow work_hours
delay_access 4 deny all
delay_parameters 4 -1/-1 4000/4000
Таким же образом настраиваются ограничения по протоколам, адресам и другим типам ACL, поддерживаемым Squid. Но чтобы правила работали правильно, их следует располагать в том порядке, в котором они должны применяться. Например, если одним пользователям устанавливаются ограничения по адресу, а другим по времени, то сначала следует прописать пул для первых, а затем для вторых. Здесь нужно быть очень внимательным.
До этого момента списки доступа формировались на основе IP-адреса компьютера или его принадлежности к некоторой сети. Не редко возникает ситуация, когда за одним компьютером может работать несколько человек, и необходимо предоставить доступ только после того, как пользователь подтвердит свою личность путем ввода логина и пароля. 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
Пробуем подключиться к прокси-серверу. Чтобы не вводить каждый раз логин и пароль, их можно указать в настройках клиентского браузера.
Рис. 1. Теперь для доступа к Squid нужно ввести пароль
При наличии Active Directory или сервера каталогов оптимальным вариантом является использование единого хранилища. При большом количестве пользователей такой вариант упрощает администрирование, так как не нужно для каждого юзера создавать еще и учетную запись на прокси. Для работы с AD есть две схемы: аутентификация с использованием Kerberos + Samba (winbind) или получение информации об учетных записях при помощи LDAP. Первый вариант считается официальным и подробно расписан на , поэтому будем разбираться со вторым. Это несколько более универсальный способ, так как его можно использовать с любым LDAP сервером, вроде OpenLDAP. Для работы через LDAP следует завести отдельную учетную запись (пусть это будет squidproxy), причем, для AD можно использовать учетную запись с минимумом привилегий. Домен для примера возьмем domain.com.
Для начала проверяем, видит ли модуль squid_ldap_auth наш сервер:
$ /usr/lib/squid3/squid_ldap_auth -v 3 -b "cn=squidproxy,dc=domain,dc=com" -f "uid=%s" domain.com
В ответ на запрос вводим строку в виде — пользователь пароль. Если получаем OK, можно идти дальше. Вместо имени контроллера домена можно указать его IP-адрес. Второй вариант проверки — с помощью утилиты поиска ldapsearch, которая входит в пакет ldap-utils. При подключении к AD можно использовать вместо "cn=squidproxy,dc=domain,dc=com" более удобный вариант записи в виде squidproxy@domain.com. Также в AD имя учетной записи получается при помощи "sAMAccountName=%s", а в LDAP используем "cn=%s". В остальном отличий нет.
Если планируется аутентификация не только по пользователям, но и по группе, проверяем доступность групп:
$ /usr/lib/squid3/squid_ldap_group -R -b "dc=domain,dc=com" -f "(&(cn=%s)(memberOf=cn=%s,cn=Users, dc=domain,dc=com))" -D squidproxy@domain.com -w пароль -h domain.com
На запрос вводим строку – логин группа. С помощью параметра ′–w′ указывается пароль для доступа пользователя squidproxy к LDAP серверу.
Теперь переходим непосредственно к настройкам Squid. Фактически в конфиг squid.conf нужно внести всего две записи и установить разрешения:
auth_param basic program /usr/lib/squid3/squid_ldap_auth -R -D
squidproxy squidproxy@domain.com –w пароль -b «cn=squidproxy,dc=domain,dc=com»
-f «sAMAccountName=%s» domain.com
# Если нужны разрешения на основании групп, то подключаем и внешнюю группу
external_acl_type ldap_group %LOGIN /usr/lib/squid3/squid_ldap_group -R -b
«dc=domain,dc=com» -f «(&(cn=%v)(memberOf=cn=%a,dc=domain,dc=com))»
-D squidproxy@domain.com -W пароль domain.com
Формат этих команд описан в документации к Squid. Здесь задаем %LOGIN, для того чтобы пользователь перед проверкой на принадлежность к группе был сначала аутентифицирован. Некоторые LDAP сервера для передачи пароля используют TLS, чтобы подружиться с ними, достаточно добавить в команды параметр ′–Z′.
И дальше в squid.conf дописываем правила:
auth_param children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
acl ldap_group proxy_auth REQUIRED
http_access allow ldap_group
http_access allow localhost
http_access deny all
После перезапуска Squid все пользователи, входящие в указанную группу, будут выходить в интернет.
На данный момент мы имеем полностью настроенный Squid, но расслабляться пока еще рано. В одно прекрасное утро начальство захочет узнать, на каких сайтах бывают сотрудники компании, и сколько времени они там проводят. Всю нужную информацию можно найти в логах сквида, но считать вручную вроде:
$ sudo tail -f /var/log/squid/access.log | awk '{print$3 " " $8 " " $7}'
Хотя и вполне реально, но уж очень не удобно, да и не нужно. Для этого прокси-сервера написано невероятное количество анализаторов логов. Одним из самых популярных решений является SARG (Squid Analysis Report Generator), который выдает подробную статистику по пользователям. На , кроме исходных текстов, можно найти пакеты для большого количества систем: Gentoo, RedHat/Fedora, Debian, Slackware, SUSE, *BSD, Mac OS X и даже Windows с OS/2. Хотя в репозитариях пакетов большинства дистрибутивов все, что нужно, уже есть. Для просмотра отчетов SARG нам понадобится веб-сервер. В Ubuntu/Debian вводим:
$ sudo apt-get install sarg apache2
В Ubuntu настройки Apache можно не трогать, все будет работать с параметрами по умолчанию. В различных дистрибутивах и операционных системах файлы могут быть помещены в разные каталоги. В Ubuntu место дислокации — /etc/squid, конфигурационный файл называется sarg.conf.
$ sudo mcedit /etc/squid/sarg.conf
# Указываем язык, возможные значения: Russian-koi8,
# Russian_UTF-8, Russian-windows1251
language Russian_UTF-8
charset Cyrillic
# Файл со статистикой, обрати внимание, что в некоторых
# дистрах каталоги для Squid 3.0 называются squid3
access_log /var/log/squid3/access.log
# Включаем построение графиков
graphs yes
graph_days_bytes_bar_color green
# При необходимости можно ограничить просмотр отчетов
# password /etc/squid/sarg.passwd
# Каталог, в который помещаются отчеты
output_dir /var/www/squid-reports
# Сортировка юзеров в выводе по USER CONNECT BYTES TIME
topuser_sort_field BYTES reverse
user_sort_field BYTES reverse
# Установка лимита в мегабайтах, пользователи, превысившие его, попадают в
файл блокировок
# per_user_limit /etc/squid/sarg.user-deny 300
# Тип отчета, включаем все
report_type topusers topsites sites_users users_sites date_time denied auth_failures
site_user_time_date downloads
# Для удобства можно конвертировать логины и IP-адреса в реальные имена
# (файл должен содержать записи вида «userid/IP-address имя»)
usertab /etc/squid/sarg.usertab
Если output_dir находится вне корневого каталога Apache, в apache2.conf необходимо создать алиас с указанием пути и дать нужные права. К сожалению, при помощи per_user_limit можно указать лимит один на всех, без учета пользователей и групп.
Создание отчетов производится при помощи скрипта /usr/sbin/sarg-reports, который запускается при помощи cron:
$ sudo crontab –e
00 08-18/1 * * * sarg-reports today
00 00 * * * sarg-reports daily
00 01 * * 1 sarg-reports weekly
30 02 1 * * sarg-reports monthly
Теперь открываем браузер и заходим на страницу отчетов.
В последнее время вместо SARG многие рекомендуют использовать . Он более легок, имеет большую скорость создания отчетов, в перспективе кроме Squid, Postfix, Qmail и CGP будут поддерживаться журналы других серверов. Еще один быстрый конкурент — — прост в установке и по сравнению с SARG занимает меньше места на жестком диске.
Рис. 2. SARG покажет все сайты, где побывал юзер
Рис. 3. Отчет по посещенным сайтам в SARG
Рис. 4. Free-sa - хорошая альтернатива SARG
Рис. 5. Анализатор логов lightSquid
Как видишь, распределение канала и настройка доступа с аутентификацией пользователей — не такая уж и сложная штука. Возможность использования учетных записей AD или LDAP на порядок упрощает администрирование. Добавив к этой схеме программу для анализа журналов, ты всегда будешь знать кто, когда, где и сколько.
Через Squid можно организовать работу ICQ. В самом Squid для этого ничего делать не нужно. Должен быть разрешен доступ к порту 443 и метод CONNECT (по умолчанию так и есть). Большинство ICQ клиентов позволяют указать в настройках прокси-сервер, при необходимости здесь же указываем логин и пароль для доступа.
Рис. 6. Настройка прокси в миранде
INFO
-
В зависимости от версии Squid параметры и возможные значения могут отличаться. Для примера в версии 2.6 в секции «Delay Pools» используется 50 параметров, а в новой 3.0 — только 44.
Чтобы узнать, с какими параметрами собран Squid, используй команду
«squid –v» .В зависимости от назначения можно использовать один из пяти классов ограничений.
Для каждого пула должна быть задана только одна строка delay_parameters.
WWW
- Большое количество дополнений к Squid можно найти на сайте
WARNING
- Для активации параметров в секции «Delay Pools» Squid должен быть собран с опцией ‘—enable-delay-pools’.
Статья опубликована в июльском номере журнала «Xakep» за 2008 год.