Фаршировка кальмараСергей «grinder» Яремчук (grinder@ua.fm, tux.in.ua) Хакер, номер #115, стр. 115-122-1 Squid: ограничиваем скорость, аутентифицируем клиентов и смотрим в логиВозможностей у Squid столько, что разработчики часто даже не успевают их подробно описывать. Общая настройка, как правило, проблем не вызывает. Cложности начинаются, когда необходимо настроить ограничения на использование канала, организовать доступ к прокси при помощи внешних средств или выбрать программу для работы с журналами. Все поделим поровнуСитуация, когда один канал нужно справедливо разделить между пользователями, отнюдь не редкость. В Squid регулировка пропускной способности канала производится при помощи пулов. За настройки отвечает группа параметров «Delay Pools». Большинство параметров этой секции требуют компиляции squid с опцией '--enable-delay-pools'. По умолчанию – так и есть. Узнать параметры сборки установленного Squid, можно введя команду «squid –v». Принцип ограничения скорости прост. Каждый запрашиваемый объект сначала попадает в буфер, а только затем передается клиенту. Каждый пул определяется двумя параметрами: скоростью заполнения и размером буфера. Если объем данных меньше размера буфера, то клиент получает их с максимальной скоростью, но при достижении лимита информация будет выдаваться в соответствии с установками. По мере опустошения пула Squid будет получать остальную часть запрашиваемой информации. Скорость заполнения пула зависит от класса. Для каждого пула при помощи delay_class должен быть установлен один из пяти классов (до версии 2.6 – один из трех):
Отсюда можно сделать вывод, что чем выше класс, тем через большее количество ограничений проходит соединение. Так для четвертого класса сначала действуют общие ограничения, затем ограничения подсети, отдельного узла и, наконец, для пользователя. Не стоит ожидать, что пользователь получит четко прописанную часть канала, если его подсеть выбрала свой лимит. Класс для пула задается при помощи параметра 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 delay_pools 2 # 2 пула delay_class 1 2 # пул 1, класс 2 delay_class 2 3 # пул 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 (смотри ][ за май этого года), можно ввести ограничения по времени, протоколам, типу файлов и др. Например, при помощи такой конструкции легко ограничить скорость любителям качать мультимедиа: 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. Но чтобы правила работали верно, их нужно располагать в том порядке, в котором они должны применяться. Например, если одним пользователям устанавливаются ограничения по адресу, а другим по времени, то сначала следует прописать пул для первых, а затем для вторых. Будь внимателен! Аутентификация в 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 Пробуем подключиться к прокси-серверу. Чтобы не вводить каждый раз логин и пароль, их можно указать в настройках клиентского браузера. Аутентификация в AD с LDAPПри наличии Active Directory или сервера каталогов оптимальным вариантом будет использование единого хранилища. При большом количестве пользователей такой вариант упрощает администрирование, так как не нужно для каждого юзера создавать еще и учетную запись на прокси. Для работы с AD есть две схемы: аутентификация с использованием Kerberos + Samba (winbind) или получение информации об учетных записях при помощи LDAP. Первый вариант считается официальным и подробно расписан на сайте проекта (wiki.squid-cache.org/ConfigExamples/WindowsAuthenticationNTLM). Поэтому будем разбираться со вторым. Это несколько более универсальный способ, так как его можно использовать с любым 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 все пользователи, входящие в указанную группу, будут выходить в интернет. Настройка SARGНа данный момент мы имеем полностью настроенный Squid, но расслабляться пока рано. В одно прекрасное утро начальство захочет узнать, на каких сайтах бывают сотрудники компании, и сколько времени они там проводят. Всю нужную информацию можно найти в логах сквида: $ sudo tail -f /var/log/squid/access.log | awk \ '{print$3 " " $8 " " $7}' Считывать вручную – хотя и вполне реально, но уж очень неудобно. К счастью, для этого прокси-сервера написано невероятное количество анализаторов логов. Одним из самых популярных решений является SARG (Squid Analysis Report Generator), который выдает подробную статистику по пользователям. На сайте проекта sarg.sf.net, кроме исходных текстов, можно найти пакеты для большого количества систем: 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 многие рекомендуют использовать Free-SA (free-sa.sf.net) – более легок и быстро создает отчеты. В перспективе кроме Squid, Postfix, Qmail и CGP будут поддерживаться журналы других серверов. Еще один шустрый конкурент – LightSquid (lightsquid.sf.net). Он прост в установке и по сравнению с SARG занимает меньше места на жестком диске. ЗаключениеКак видишь, распределение канала и настройка доступа с аутентификацией пользователей – не такая уж сложная штука. Возможность использования учетных записей AD или LDAP на порядок упрощает администрирование. Добавив к этой схеме программу для анализа журналов, ты всегда будешь знать кто, когда, где и сколько :). Через Squid можно организовать работу ICQ. В самом Squid для этого ничего делать не нужно. Должен быть разрешен доступ к порту 443 и метод CONNECT (по умолчанию так и есть). Большинство ICQ-клиентов позволяют указать в настройках прокси-сервер; при необходимости здесь же указываем логин и пароль для доступа. INFOВ зависимости от версии Squid параметры и возможные значения могут отличаться. Для примера в версии 2.6 в секции «Delay Pools» используется 50 параметров, а в новой 3.0 – только 44. Чтобы узнать, с какими параметрами собран Squid, используй команду «squid –v». В зависимости от назначения можно использовать один из пяти классов ограничений. Для каждого пула должна быть задана только одна строка delay_parameters. WWWБольшое количество дополнений к Squid можно найти на сайте freshmeat.net. WARNINGДля активации параметров в секции «Delay Pools» Squid должен быть собран с опцией '--enable-delay-pools'. |