Записки IT специалиста

В прошлых частях нашего цикла мы рассмотрели, как настроить Squid для аутентификации пользователей через ActiveDirectory, однако просто проверять подлинность пользователя в большинстве случаев недостаточно. Требуется гибко управлять доступом пользователей к сети интернет основываясь на их членстве в группах безопасности AD, такая схема позволит администраторам использовать привычную и понятную модель управления, в тоже время задействовав все возможности прокси-сервера Sqiud.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Перед тем, как двигаться дальше, вспомним, чем отличается авторизация от аутентификации, тем более, что некоторые администраторы путают эти понятия. Аутентификация - проверка подлинности пользователя, которая позволяет убедиться, что он действительно тот, за кого себя выдает. Авторизация - проверка прав аутентифицированного пользователя на доступ к тому или иному объекту.

Для авторизации на прокси-сервере мы будем использовать членство в группах Active Ditectory, при этом можно использовать как уже существующие, так и вновь созданные группы. Мы рекомендуем создать свой набор групп, чтобы избежать путаницы. Например, для разграничения пользователей по доступу к различным ресурсам можно создать группы (будут использоваться для примеров в дальнейшем):

• squid-admin - администрация и IT-персонал, фильтрация не производится.
• squid-user - остальные пользователи, фильтрация по общему списку.
• squid-whitelist - ограниченная группа пользователей, доступ только к ресурсам из "белого" списка.

А для ограничения скорости группы:

• squid-speed-unlim - группа без ограничения скорости.
• squid-speed-2-10mb - ограничение скорости 2 Мбит/с на пользователя и 10 Мбит/с на группу

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

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

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

Настройка Kerberos-авторизации на основе групп безопасности Active Directory

Для выполнения ряда действий: аутентификации, авторизации, редиректа, логгирования и т.п. Squid использует специальные программы - хелперы. Это позволяет гибко наращивать функциональность программы без ее усложнения, нужно - подключили, нужно - изменили, не нужно - выключили. С полным списком хелперов Squid можно ознакомиться здесь: Squid helpers.

Несмотря на то, что, начиная с версии Squid 3.2 (вышла в августе 2012 г.) доступен хелпер ext_kerberos_ldap_group_acl, позволяющий получать данные о членстве пользователя в доменных группах с использованием протокола Kerberos, подавляющее большинство инструкций в сети продолжают использовать хелпер ext_ldap_group_acl, который передает учетные данные по сети в открытом виде, в лучшем случае через SSL.

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

Но не обошлось без ложки дегтя в бочке меда. В поставку Squid в Ubuntu Server 14.04 данный хелпер не входит. Попытка собрать его самостоятельно не увенчалась успехом, собранный нами хелпер радостно сообщал нам, что данный вид авторизации не поддерживается.

В тоже время аналогичная версия Squid в Debian 8 прекрасно работала с этим хелпером. Поэтому была предпринята попытка использовать в Ubuntu хелпер из поставки Debian, что оказалось верным решением. Ниже мы выкладываем хелпер для Squid 3.3.8 архитектуры amd64 (т.е. для 64-битных систем).

Скачать ext_kerberos_ldap_group_acl (Sqiud 3.3.8 amd64)

Если вы используете Debian, то следующие действия можете пропустить и сразу перейти к настройке хелпера.

Перейдем в домашнюю директорию и скачаем хелпер с данного сайта:

cd~
wget "https://interface31.ru/tech_it/files/squid3.3.8/ext_kerberos_ldap_group_acl"

После чего скопируем его в директорию с хелперами:

cp ext_kerberos_ldap_group_acl /usr/lib/squid3

и сделаем его исполняемым:

chmod +x /usr/lib/squid3/ext_kerberos_ldap_group_acl

Теперь приступим к его настройке (отсюда инструкция для Debian и Ubuntu снова общая). Сначала установим необходимые для работы с AD библиотеки:

apt-get install libsasl2-modules-gssapi-mit

После чего проверим хелпер запустив его отдельно:

/usr/lib/squid3/ext_kerberos_ldap_group_acl -a -d -i -g squid-user -D INTERFACE31.LAB

Ключи -d и -i предназначены для отладки, -g указывает желаемую группу, членство в которой мы хотим проверить, -D обозначает область Kerberos в которой производим проверку. Запустив хелпер просто вводим имя пользователя и получаем результат проверки: OK - если пользователь входит в группу и ERR - если не входит.

Убедившись, что все работает как надо, перейдем к настройке Squid, в конфигурационном файле, в самом начале секции ACL добавим строки:

external_acl_type squid-admin ttl=300 negative_ttl=60 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g squid-admin -D INTERFACE31.LAB
external_acl_type squid-user ttl=300 negative_ttl=60 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g squid-user -D INTERFACE31.LAB

И так далее, пока не перечислим все необходимые нам группы. Чтобы избежать путаницы, мы дали внешним элементам ACL такие же имена, как и доменным группам, вы можете называть их на свое усмотрение.

Ниже зададим элементы ACL, соответствующие группам, названия также будут совпадать с именами групп в AD.

acl squid-admin external squid-admin
acl squid-user external squid-user

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

http_access allow auth

Для проверки можете его заменить на:

http_access allow squid-admin
http_access deny squid-user

Сохраним и проверим конфиг:

squid3 -k check

Перезапустим squid:

service squid3 restart

Проверяем, пользователям, входящим в группу squid-admin доступ будет разрешен, а членам группы squid-user - запрещен.

Пример разграничения доступа к ресурсам сети на основе URL-фильтрации

Чтобы не быть голословными рассмотрим несколько примеров, например, разграничим доступ к ресурсам на основе групп, как было указано в начале материала. Подробнее о настройке URL-фильтрации читайте в соответствующей статье. Допустим у нас есть несколько списков, которым соответствуют элементы ACL graylist - список нежелательных сайтов и whitelist - "белый" список для ограниченной группы.

Один из вариантов списков доступа может выглядеть так:

http_access allow squid-admin
http_access deny graylist
http_access allow squid-user
http_access allow squid-whitelist whitelist
http_access deny all

Данный вариант реализует схему, когда при нахождении сразу в нескольких группах пользователю предоставляются максимальные привилегии. Если нужно сделать наоборот, то расположим списки следующим образом:

http_access allow squid-whitelist whitelist
http_access deny squid-whitelist
http_access deny squid-user graylist
http_access allow squid-user
http_access allow squid-admin
http_access deny all

Пользователям, не входящим ни в одну группу, доступ будет полностью запрещен. Некоторым читателям могут показаться избыточными правила вида http_access deny squid-whitelist, ведь все равно данный пользователь должен попасть под правило http_access deny all, однако вспомним, что в начале статьи мы обращали ваше внимание на то, что все случаи нужно прописывать явно, так как если этого списка не будет, то пользователь, входящий сразу в несколько групп получит доступ по одному из следующих списков, чего в данном варианте быть не должно.

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

Мы снова не будем останавливаться подробно на механизме ограничения скоростей, про это написано здесь. А перейдем к конкретной задаче. В начале статьи мы создали две группы, для пользователей без ограничения скорости и группу с ограничением в 2 Мбит/с на пользователя и 10 Мбит/с на группу, не вошедшие в группы пользователи должны ограничиваться на уровне 1 Мбит/с на пользователя, 5 Мбит/с на группу. Будем также считать, что названия ACL соответствуют названиям доменных групп.

Перейдем в конфигурационном файле в раздел DELAY POOL PARAMETERS и создадим три пула четвертого класса.

delay_pools 3
delay_class 1 4 # Unlim (100 Mbit)
delay_class 2 4 # 2 Mbit user / 10 Mbit group
delay_class 3 4 # 1 Mbit user / 5 Mbit group

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

Ниже зададим списки доступа:

delay_access 1 allow squid-speed-unlim
delay_access 1 deny all
delay_access 2 allow squid-speed-2-10mb
delay_access 2 deny all
delay_acesss 3 allow all

При членстве сразу в нескольких группах пользователь получит максимально доступную скорость, так как первыми указаны правила для более быстрого пула, чтобы сделать наоборот просто поставьте списки для пула 2 выше, чем списки для пула 1.

Наконец зададим параметры пулов:

delay_parameters 1 -1/-1 -1/-1 -1/-1 12000000/12000000
delay_parameters 2 -1/-1 -1/-1 -1/-1 250000/1250000
delay_parameters 3 -1/-1 -1/-1 -1/-1 125000/625000

Напоминаем, что параметры скорости в пулах задаются в байтах, поэтому значение в битах/с необходимо разделить на 8, например, 2 Мбит/с = 250 КБ/с. Также в пулах четвертого класса не следует задавать последний параметр (скорость пользователя) в виде -1/-1, следует указать полную ширину канала или заведомо большее значение, в нашем случае задано значение 100 Мбит/с = 12 МБ/с.

Как видим, ничего сложного в авторизации пользователей Squid на основе групп AD нет, в тоже время использование данного механизма дает в руки администратора мощный инструмент по контролю и управлению доступом к сети.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.