Какие схемы аутентификации используются в squid

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

При работе с базовой схемой используются вспомогательные модули basic_ncsa, basic_pam, basic_ldap_auth. Они напрямую проверяют логин и пароль, принимая запросы от Squid и возвращая статус проверки. Такой подход подходит для небольших установок или изолированных сегментов, где требуется минимум сторонних сервисов.

В средах Windows чаще применяется NTLM или Kerberos. Эти методы позволяют Squid взаимодействовать с контроллерами домена, обеспечивая автоматическую передачу учетных данных пользователя при наличии корректной конфигурации браузера и сервера. Настройка требует точного указания параметров домена, ключей и корректных прав у сервисных аккаунтов.

При необходимости связать Squid с нестандартной системой контроля доступа используется внешний исполняемый файл или скрипт. Через external_acl_type можно подключить собственный обработчик, который будет отвечать за проверку данных, например, через API, внутреннюю систему учёта или токены.

Использование базовой аутентификации через helpers (basic_ncsa, basic_pam)

Базовая схема опирается на передачу логина и пароля в кодировке Base64, поэтому ключевую роль играет корректная настройка helpers. Модуль basic_ncsa считывает хеши из локального файла, созданного утилитой htpasswd. Для рабочих сред имеет значение выбор алгоритма: рекомендуется задавать bcrypt или SHA-512, поскольку они поддерживаются современными сборками Squid.

Вариант basic_pam подходит для серверов, где уже используется PAM-стек. Helper обращается к конфигурации в каталоге /etc/pam.d/, что позволяет применять системные правила: ограничение по времени, привязку к группе, двухфакторную проверку через подключённые модули. При такой конфигурации Squid не хранит парольные файлы и передаёт проверку службе pam_unix или расширенным модулям.

Для минимизации задержек стоит ограничить количество одновременных запросов к helper, задав параметры children и concurrency. Избыточное число процессов приводит к росту нагрузки на CPU, а слишком низкое – к увеличению времени ответа. В типовых установках оптимальным считается диапазон от 5 до 20 процессов в зависимости от потока запросов.

Доступ следует подтверждать через ACL, например:

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd

acl users proxy_auth REQUIRED

http_access allow users

Такая конфигурация обеспечивает проверку по заданному helper, фильтрацию через ACL и отказ в обработке запросов без корректных данных. Дополнительное преимущество базовой схемы – прозрачное журналирование: в access.log фиксируются успешные и отклонённые попытки, что упрощает аудит.

Настройка digest-метода и хранение хэшей паролей

Digest-аутентификация использует контрольные суммы, исключая передачу паролей в открытом виде. Squid обращается к helper digest_file_auth, который работает с файлом, содержащим строки в формате username:realm:HA1. Значение HA1 формируется утилитой htdigest и представляет собой MD5-хеш от связки «логин + область + пароль».

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

Пример параметров в конфигурации:

auth_param digest program /usr/lib/squid/digest_file_auth /etc/squid/digest.passwd

auth_param digest realm proxy-access

acl digest_users proxy_auth REQUIRED

http_access allow digest_users

Для снижения нагрузки на helper применяется параметр children. Значение подбирается с учётом количества одновременных соединений. В средних установках обычно достаточно 5–10 процессов. Недостаток digest-метода – зависимость от MD5, поэтому его рекомендуют использовать в контуре, ограниченном внутренними сетями, где важна защита от перехвата, но отсутствуют требования к современным алгоритмам.

Применение NTLM для интеграции со средой Windows

NTLM позволяет Squid принимать учетные данные пользователей без повторного запроса пароля, опираясь на механизм вызовов к контроллеру домена. Для работы требуется пакет Samba и корректная настройка winbind, обеспечивающего обмен запросами между Squid и инфраструктурой AD. Helper ntlm_auth действует как посредник, передавая данные для проверки через winbindd.

Перед конфигурацией Squid необходимо убедиться, что сервер успешно присоединён к домену и способен получать SID, UID и информацию о группах. Проверка выполняется командами wbinfo -u и wbinfo -g. Наличие ответа указывает на корректное взаимодействие с контроллером домена.

В конфигурации Squid задаётся вызов helper:

auth_param ntlm program /usr/bin/ntlm_auth —helper-protocol=squid-2.5-ntlmssp

auth_param ntlm children 15

Для разграничения доступа применяются ACL на основе групп AD. Они определяются через external_acl_type с использованием wbinfo_group.pl или встроенной команды wbinfo —group-info. Такой подход позволяет Squid выдавать доступ только членам определённых подразделений или ролей без создания дополнительных локальных списков.

Браузеры должны быть настроены на автоматическое использование учётных данных. В среде Windows это управляется через GPO: параметр Automatic logon only in Intranet zone и список доверенных сайтов. Без этого NTLM будет запрашиваться вручную или отклоняться.

Работа Kerberos/Negotiate для единого входа в домене AD

Kerberos обеспечивает Squid доступ к механизму тикетов, выданных контроллером домена. Для корректной работы требуется сервисная запись HTTP/hostname и ключевой табличный файл keytab. Его создают через ktpass на контроллере домена, задавая точное имя хоста, совпадающее с тем, что используют браузеры при обращении к прокси.

Squid взаимодействует с Kerberos через helper negotiate_kerberos_auth, который проверяет полученные тикеты и передает статус в основной процесс. В настройках важно указать путь к keytab и обеспечить доступ только пользователю, под которым запущен сервис. Неправильные права или несовпадение имени SPN приводят к ошибке «KRB5KRB_AP_ERR_MODIFIED».

Пример рабочего фрагмента конфигурации:

auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -k /etc/squid/HTTP.keytab

auth_param negotiate children 10

acl ad_users proxy_auth REQUIRED

http_access allow ad_users

Для корректной выдачи тикетов браузеры должны находиться в зоне, отмеченной как Intranet, а адрес прокси – в списке доверенных узлов. В корпоративных сетях параметры распространяются через GPO. Если используется балансировка или несколько экземпляров Squid, каждый сервер должен иметь собственный keytab с уникальным SPN либо использовать общий виртуальный адрес, указанный в записи SPN.

Дополнительная проверка выполняется через kinit и kvno. Если тикет можно получить и он проходит валидацию на стороне Squid, то механизм Negotiate будет использоваться без запроса пароля, опираясь на тикеты, выданные контроллером домена.

Аутентификация через внешние скрипты и собственные backends

Внешние скрипты позволяют связать Squid с любым хранилищем учётных данных: внутренней БД, REST-API, файловой системой или сервисом авторизации, отсутствующим в стандартных helpers. Для взаимодействия используется external_acl_type, который передаёт скрипту параметры запроса и получает ответ в формате «OK» или «ERR».

• Скрипт должен принимать данные через stdin и отвечать через stdout.
• Возврат «OK user=<имя>» позволяет передать Squid имя пользователя без стандартного механизма авторизации.
• Закрытие stdout или превышение таймаута приводит к блокировке доступа.
• Запускать скрипт рекомендуется от системного пользователя Squid, чтобы ограничить привилегии.

Пример определения внешнего источника и ACL:

1. external_acl_type custom_auth ttl=30 negative_ttl=15 %LOGIN /usr/local/bin/check_auth.sh
2. acl ext_users external custom_auth
3. http_access allow ext_users

Скрипт может обращаться к базе данных через psycopg2 или mysqlclient, проверять токены в Redis, сверять IP-адреса и параметры запроса. Такой подход позволяет внедрять нестандартные схемы: авторизацию по одноразовым ключам, доступ по временным ссылкам, ограничение по расписанию или интеграцию с внутренними системами учёта.

Настройка LDAP-проверки через helper basic_ldap_auth

Helper basic_ldap_auth используется для аутентификации пользователей через LDAP-серверы, включая Active Directory и OpenLDAP. Squid передает логин и пароль в helper, который выполняет bind к указанному LDAP-контроллеру и возвращает результат проверки.

Основные параметры конфигурации:

• auth_param basic program – путь к basic_ldap_auth с указанием LDAP URI, DN-шаблона и опций подключения.
• auth_param basic children – количество процессов helper для одновременной проверки, оптимально 5–20 в зависимости от нагрузки.
• auth_param basic realm – идентификатор зоны, отображаемый пользователю при запросе пароля.
• auth_param basic credentialsttl – время кеширования успешных проверок для снижения нагрузки на LDAP.

Пример конфигурации:

auth_param basic program /usr/lib/squid/basic_ldap_auth -b «dc=example,dc=com» -D «cn=proxyuser,dc=example,dc=com» -w «пароль» -f «uid=%s»

auth_param basic children 10

auth_param basic realm LDAP Proxy

acl ldap_users proxy_auth REQUIRED

http_access allow ldap_users

Для повышения надежности рекомендуется указывать несколько серверов через запятую в LDAP URI и использовать таймауты bind и search. В OpenLDAP важно правильно указать DN-шаблон, а в AD – фильтры с атрибутом sAMAccountName или userPrincipalName. Кеширование с помощью credentialsttl сокращает количество bind-запросов и улучшает отклик Squid при большом числе пользователей.

Контроль и обработка результатов аутентификации через acl auth

ACL (Access Control List) в Squid позволяет фильтровать запросы на основе результатов аутентификации. После проверки через helper или внешний скрипт создается объект proxy_auth, который содержит статус пользователя и его имя. На основе этого Squid принимает решение о доступе к ресурсам.

Основные принципы работы:

• ACL определяется через acl имя proxy_auth REQUIRED или acl имя proxy_auth пользователь, где можно указать конкретных пользователей или группы.
• HTTP-запросы, не прошедшие проверку, отклоняются http_access deny.
• Можно комбинировать несколько ACL для создания сложных правил доступа, учитывая IP, время суток, домен или URL.
• При использовании внешних скриптов ACL фиксирует результат «OK» или «ERR», что позволяет применять единые правила независимо от типа аутентификации.

Пример конфигурации:

1. acl users proxy_auth REQUIRED
2. acl admins proxy_auth john mary
3. http_access allow admins
4. http_access allow users
5. http_access deny all

Рекомендуется создавать отдельные ACL для административного доступа и для обычных пользователей. Такой подход облегчает аудит и диагностику: в журнале фиксируется, какая ACL сработала, и можно быстро выявить источник отклонённых запросов. Для крупных сетей оптимально использовать комбинирование с external_acl_type для проверки принадлежности к ролям или группам из LDAP/AD.

Вопрос-ответ:

Какие виды аутентификации поддерживает Squid для корпоративной сети?

Squid поддерживает базовую аутентификацию через helpers (basic_ncsa, basic_pam), digest-метод, NTLM для интеграции с Windows, Kerberos/Negotiate для единого входа в домене AD, проверку через LDAP с помощью basic_ldap_auth и внешние скрипты или собственные backends. Выбор метода зависит от инфраструктуры, объема пользователей и требований к безопасности передачи данных.

Как настроить базовую аутентификацию через basic_ncsa для локальных пользователей?

Необходимо создать файл с хешами паролей через утилиту htpasswd и указать его в конфигурации Squid с помощью параметра auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd. Дополнительно задаются ACL: acl users proxy_auth REQUIRED и http_access allow users. Рекомендуется ограничить количество процессов helper через параметр children, чтобы избежать перегрузки сервера при большом числе одновременных запросов.

В чем преимущества использования Kerberos/Negotiate в Squid для домена AD?

Kerberos позволяет пользователям входить в прокси без повторного ввода пароля, используя тикеты, выданные контроллером домена. Для этого требуется создать сервисную запись HTTP/hostname, keytab-файл и настроить helper negotiate_kerberos_auth. Такой подход упрощает управление учётными данными, обеспечивает проверку подлинности через AD и снижает риск передачи пароля по сети.

Как подключить Squid к LDAP-серверу для проверки пользователей?

Используется helper basic_ldap_auth, которому передаются параметры: URI LDAP, DN-шаблон для поиска пользователей, учетная запись для bind и пароль. В конфигурации Squid задается auth_param basic program /usr/lib/squid/basic_ldap_auth -b «dc=example,dc=com» -D «cn=proxyuser,dc=example,dc=com» -w «пароль» -f «uid=%s». Затем создается ACL через acl ldap_users proxy_auth REQUIRED и разрешается доступ через http_access allow ldap_users. Можно указать несколько серверов и включить кеширование успешных проверок через credentialsttl для уменьшения нагрузки.

Для чего используются внешние скрипты в аутентификации Squid и как их настроить?

Внешние скрипты позволяют интегрировать Squid с нестандартными системами авторизации, включая внутренние базы, API или временные токены. Скрипт принимает данные через stdin и возвращает «OK» или «ERR». В конфигурации Squid задается external_acl_type custom_auth ttl=30 negative_ttl=15 %LOGIN /usr/local/bin/check_auth.sh, затем ACL acl ext_users external custom_auth и http_access allow ext_users. Скрипт может проверять группы, IP-адреса или временные параметры, обеспечивая гибкий контроль доступа.

Как настроить NTLM-аутентификацию в Squid для интеграции с Active Directory?

Для NTLM требуется установить Samba и включить службу winbind. Squid использует helper ntlm_auth, который связывается с winbindd и проверяет учетные данные пользователей в домене. Необходимо убедиться, что сервер Squid присоединен к домену и имеет корректные права. В конфигурации задаются параметры: auth_param ntlm program /usr/bin/ntlm_auth —helper-protocol=squid-2.5-ntlmssp и auth_param ntlm children 15. Доступ управляется через ACL на основе групп AD, что позволяет ограничить доступ определенным подразделениям без создания локальных списков пользователей.

Можно ли использовать Squid для проверки пользователей через нестандартные системы авторизации?

Да, для этого применяются внешние скрипты или собственные backends через external_acl_type. Скрипт принимает данные от Squid через stdin и возвращает результат проверки «OK» или «ERR». В конфигурации создается ACL: acl ext_users external custom_auth, затем разрешается доступ http_access allow ext_users. Такой подход позволяет проверять учетные данные через базы данных, API, токены или временные ключи и настраивать правила доступа по группам, IP или расписанию.