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

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

Несмотря на большие возможности базовой конфигурации, некоторые функции, необходимые для комфортной работы прокси-сервера, возложены на дополнительные программы, называемые “хелперами”. Одна из самых важных задач, для решения которой создано множество хелперов, это аутентификация пользователей. Сам прокси-сервер Squid не осуществляет аутентификацию, он лишь способен декодировать HTTP-заголовок Authorization и передать расшифрованную информацию хелперу. Хелпер проверяет корректность переданных данных и в зависимости от того, верна ли связка логин-пароль отвечает прокси-серверу. После этого Squid проверяет права доступа и предоставляет пользователю доступ, или же возвращает 407 ошибку HTTP, если аутентификация не пройдена.

Хелперы, способные производить аутентификацию клиентов сети некоторыми основными способами входят в состав пакета Squid. Любой хелпер работает согласно своей схеме аутентификации и возвращает прокси-серверу положительный или отрицательный результат. Одновременно могут быть сконфигурированы несколько схем аутентификации, прокси-сервер будет пытаться использовать разные схемы аутентификации в зависимости от порядка их указания в squid.conf.

Очень важно помнить, что аутентификация невозможна в прозрачном режиме работы прокси-сервера (transparent proxy). Это ограничение вызвано исключительно особенностями работы протокола TCP/IP, а не недостатками функционала Squid.

Включение и настройка сторонних модулей аутентификации выполняется с помощью директивы auth_param главного конфигурационного файла:

auth_param scheme parameter [setting]

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

После настройки аутентификации и выбранного хелпера обязательно создать acl (access control list - список контроля доступа), который задействует настроенный модуль аутентификации и позволит получить доступ к сети авторизованным пользователям.

Изначально строка задания acl имеет следующий формат:

acl acl_name acl_type argument

Для создания списка контроля доступа, который включает в себя пользователей, прошедших аутентификацию, параметр acl_type должен иметь значение proxy_auth. Не стоит забывать, что данный acl должен иметь разрешение на доступ, которое выдаётся с помощью директивы http_access.

Настройка Basic-аутентификации

Basic метод аутентификации - это простейший метод проверки подлинности, который существовал ещё в протоколе HTTP/1.0. Он основан на предоставлении прокси-серверу учетных данных веб-браузером клиента. Логин и пароль объединяются через двоеточие, кодируются в base64 и передаются в поле Authorization HTTP-запроса. Следует обратить внимание, что кодирование учетных данных в base64 не является защитой и фактически происходит открытая передача пароля. Единственное преимущество basic схемы это то, что её поддерживает любой браузер или другой клиент работы с сетью.

Атентификация с использованием NCSA

Хранение паролей осуществляется с помощью обычного текстового файла, который содержит учетные данные, закодированные в base64. По умолчанию в Squid basic-аутентификация реализуется с помощью хелпера, расположенного в /usr/lib/squid3/ncsa_auth. Он проверяет соответствие переданной комбинации "логин:пароль" с хранящимися в файле данными и возвращает прокси-серверу “OK” или “ERR” в качестве результата.

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

auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/squidusers 
# здесь /usr/lib/squid3/ncsa_auth это путь к самому хелперу, а /etc/squid3/squidusers - путь к файлу, содержащему комбинации логинов и паролей.
acl lan proxy_auth REQUIRED # создание списка доступа, в который включены все прошедшие аутентификацию пользователи
http_access allow lan # теперь пользователям списка lan разрешен доступ к интернету

Файл паролей для реализации Basic аутентификации можно создать с помощью утилиты htpasswd, которая входит в состав пакета apache2-utils для Debian/Ubuntu. Синтаксис команды для htpasswd следующий:

htpasswd [-c] /создаваемый/файл/паролей имя_пользователя

Параметр -с используется для создания нового файла, изменение существующего файла производится без этого параметра.

Ниже приведен пример создания нового файла учетных записей squidusers и добавления пользователей user1 и user2 с паролями 12345:

htpasswd -c /etc/squid3/squidusers user1

New password:
Re-type new password:
Adding password for user user1

cat /etc/squid3/squidusers
user1:12345

htpasswd /etc/squid3/squidusers user2

New password:
Re-type new password:
Adding password for user user2

cat /etc/squid3/squidusers
user1:12345
user2:12345

Для созданного файла желательно установить права на чтение только пользователю и группе, от имени которой работает Squid:

chmod 440 /etc/squid3/squidusers
chown proxy:proxy /etc/squid3/squidusers

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

squid3 -k reconfigure или /etc/init.d/squid3 reload

Аутентификация с использованием базы данных MySQL

Помимо хранения учетных данных в файле можно воспользоваться basic-аутентификацией через базу данных. В этом случае связки "логин:пароль" будут храниться в базе данных MySQL.

В первую очередь создадим базу данных и таблицу для хранения паролей. Для этого следует выполнить несколько запросов к серверу MySQL:

create database squid; # создана база данных
CREATE TABLE 'passwd' (
'user' varchar(32) NOT NULL default '',
'password' varchar(35) NOT NULL default '',
'enabled' tinyint(1) NOT NULL default '1',
'fullname' varchar(60) default NULL,
'comment' varchar(60) default NULL,
PRIMARY KEY ('id')); # создана таблица passwd с полями user,password,enabled,fullname и comment

Так же можно сразу внести в таблицу тестовую запись, выполнив следующий запрос:

insert into passwd values('test','pass',1,'Test User','for test');

Настройка на стороне MySQL завершена, теперь необходимо подключить DB-аутентификацию в файле настроек squid.conf аналогичным обычной basic-аутентификации способом:

auth_param basic program /usr/local/squid/libexec/squid_db_auth --user user --password password --md5 --persist
acl db-auth proxy_auth REQUIRED
http_access allow db-auth

Отдельное внимание стоит уделить основным параметрам хелпера:

• --user - имя пользователя БД;
• --password - пароль доступа к БД;
• --table - таблица в БД, по умолчанию "passwd";
• --usercol - столбец с именами пользователей, по умолчанию "user";
• --passwdcol - столбец с паролями, по умолчанию"password";
• --plaintext - означает, что пароли в базе хранятся в открытом виде;
• --md5 - означает, что пароли зашифрованы в md5 без добавления “соли”;
• --salt - “соль”, используемая для шифрования пароля;
• --persist - оставляет соединение с БД открытым в промежутке между запросами.

По завершении настройки необходимо обновить конфигурацию прокси-сервера командой

squid3 -k reconfigure

Помимо хелперов NCSA и MySQL, в состав Squid также входит множество других хелперов для работы с такими источниками данных, как LDAP, RADIUS, PAM и другие.

Digest-аутентификация

Данный метод является более предпочтительным, чем basic-аутентификация благодаря использованию шифрования пароля перед отправкой через сеть. Общая схема работы примерно та же, что и в basic методе, за исключением того, что при обмене между клиентом и сервером учетные данные шифруются с использованием MD5-шифрования. В ответы клиента и сервера добавляются случайные значения, после этого пароль передаётся в виде хэша. Шифровку и дешифровку пароля может производить утилита htdigest, которая устанавливается вместе с пакетом apache2-utils. Хелпер, позволяющий реализовать Digest-аутентификацию с помощью файла с паролями, можно найти по адресу /usr/lib/squid3/digest_pw_auth.

Также как и для Basic-аутентификации, для Digest-аутенфикации существуют и другие хелперы, позволяющие использовать разные источники данных о пользователях.

Помимо Basic- и Digest-аутентификации, Squid также поддерживает NTLM- и Negotiate-аутентификацию. Данные схемы применяются достаточно редко, как правило, в рамках корпоративной инфраструктуры и их настройка заслуживает отдельной статьи.

Общие настройки аутентификации пользователей

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

children

auth_param basic children 5

Количество подпроцессов программы аутентификации, работающих одновременно. Базовое значение 5 означает, что одновременно может происходить аутентификация не более чем пяти пользователей. Если шестой клиент захочет получить доступ, ему придется ждать появления свободного процесса аутентификации. Увеличение числа процессов может ускорить работу прокси-сервера. С другой стороны, слишком большое значение этой настройки может привести к увеличению нагрузки на сервер, особенно в случае неисправности.

realm

auth_param basic realm Corporate proxy server Squid

Данный параметр позволяет указать строку, которая будет отправлена клиенту через окно авторизации. Как правило, это название прокси-сервера или какой-то комментарий, позволяющий пользователю понять, что он авторизуется в Squid.

credentialsttl

auth_param basic credentialsttl 2 hours

Параметр, отвечающий за срок хранения в кэше связки "username:password". Когда заданный промежуток времени истечет, прокси-сервер вновь запросит у пользователя аутентификацию.

casesensitive

auth_param basic casesensitive off

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

blankpassword

auth_param basic blankpassword off

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

Дополнительные директивы

Кроме директивы auth_param есть так же несколько других директив, влияющих на аутентификацию:

authenticate_cache_garbage_interval 1 hour

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

authenticate_ttl 1 hour

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

authenticate_ip_ttl 0 seconds

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

Заключение

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

Введение любого из механизмов аутентификации связано с определенным уровнем дискомфорта для пользователей сети и возрастающей сложностью её обслуживания. Не стоит забывать, что аутентификация в режиме “прозрачного” Squid невозможна - каждый компьютер придется настраивать для работы через прокси-сервер. С точки зрения информационной безопасности, куда большее внимание стоит обратить на права пользователей и на принципиальную доступность некоторых файлов в сети. Поэтому перед тем, как реализовывать любой из механизмов аутентификации пользователей, стоит как следует продумать схему работы сети и ответить на вопрос “Можно ли достичь того же уровня безопасности без использования аутентификации всех клиентов?”