Какие схемы аутентификации используются в squid
Инструкция используется, если программа Kaspersky Web Traffic Security установлена из rpm- или deb-пакета на готовую операционную систему.
Если вы настраиваете аутентификацию с доменом, в названии которого содержится корневой домен .local , то для корректной работы Kerberos-аутентификации требуется выполнить предварительные действия в операционной системе.
- Проверьте состояние службы avahi-daemon. Для этого выполните команду: systemctl status avahi-daemon
- Если служба запущена, остановите ее. Для этого выполните команду: systemctl stop avahi-daemon
- Отключите автоматический запуск службы. Для этого выполните команду: systemctl disable avahi-daemon
Чтобы настроить сервис Squid для Kerberos-аутентификации, выполните следующие действия:
- Если вы используете операционные системы CentOS версии 8.x или Red Hat Enterprise Linux версии 8.x, настройте политику использования криптографичеких алгоритмов. Для этого выполните команду: update-crypto-policies —set LEGACY
- Скопируйте файл squid.keytab в директорию /etc/squid/.
- Настройте доступ к keytab-файлу. Для этого выполните следующие команды в зависимости от используемой операционной системы:
- CentOS, Red Hat Enterprise Linux или SUSE Linux Enterprise Server: chown squid:squid /etc/squid/squid.keytab chmod 400 /etc/squid/squid.keytab
- Ubuntu, Debian или Альт Сервер: chown proxy:proxy /etc/squid/squid.keytab chmod 400 /etc/squid/squid.keytab
По умолчанию владельцем файла krb5.keytab является суперпользователь.
- CentOS или Red Hat Enterprise Linux: auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/squid/squid.keytab -s HTTP/@ auth_param negotiate children 100 startup=0 idle=10 auth_param negotiate keep_alive on acl authenticated_user proxy_auth REQUIRED http_access deny !authenticated_user
- SUSE Linux Enterprise Server: auth_param negotiate program /usr/sbin/negotiate_kerberos_auth -k /etc/squid/squid.keytab -s HTTP/@ auth_param negotiate children 100 startup=0 idle=10 auth_param negotiate keep_alive on acl authenticated_user proxy_auth REQUIRED http_access deny !authenticated_user
- Ubuntu, Debian или Альт Сервер: auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -k /etc/squid/squid.keytab -s HTTP/@ auth_param negotiate children 100 startup=0 idle=10 auth_param negotiate keep_alive on acl authenticated_user proxy_auth REQUIRED http_access deny !authenticated_user
- CentOS или Red Hat Enterprise Linux: auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -d -k /etc/squid/squid.keytab -s HTTP/@
- SUSE Linux Enterprise Server: auth_param negotiate program /usr/sbin/negotiate_kerberos_auth -d -k /etc/squid/squid.keytab -s HTTP/@
- Ubuntu, Debian или Альт Сервер: auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -d -k /etc/squid/squid.keytab -s HTTP/@
Отладочные события будут записаны в файл /var/log/squid/cache.log.
- Для CentOS или Red Hat Enterprise Linux добавьте в файл /etc/sysconfig/squid строку: KRB5RCACHETYPE=none
- Для Ubuntu версии 18.04.х, Debian версии 9.х или Альт Сервер добавьте в файл /etc/default/squid строку: KRB5RCACHETYPE=none
- Для SUSE Linux Enterprise Server версии 15.х или Debian версии 10.х:
- Создайте файл /etc/systemd/system/squid.service.d/override.conf следующего содержания: [Service] Environment=KRB5RCACHETYPE=none
- Выполните команду: systemctl daemon-reload
По умолчанию Replay cache включен.
Replay cache обеспечивает более надежную защиту, но может снижать производительность программы.
Кеш, используемый в технологии Kerberos для хранения записей о запросах пользователей на аутентификацию. Этот механизм помогает защитить инфраструктуру от атак повторного воспроизведения. Во время таких атак злоумышленники записывают трафик пользователя, чтобы воспроизвести ранее отправленные им сообщения и успешно пройти аутентификацию на прокси-сервере. При использовании replay cache сервер аутентификации обнаруживает дубликат запроса и отправляет в ответ сообщение об ошибке.
Сервис Squid будет настроен для использования Kerberos-аутентификации.
Схемы авторизации в squid
Здравствуйте, имею следующий вопрос о том, как лучше организовать авторизацию пользователей в squid. Сейчас авторизация идет через basic хелпер ncsa. Возникла необходимость разбить пользователей на группы и раздавать инет согласно группам. Если сделать примерно так:
#Autentification
auth_param basic program /usr/squid/libexec/ncsa_auth /usr/squid/etc/passwd
auth_param basic children 15
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
acl user_url dstdomain .domain1.com
acl sec_url dstdomain .domain2.com
acl group_admins proxy_auth user1 user4 REQUIRED
acl group_users proxy_auth user2 REQUIRED
acl group_sec proxy_auth user3 REQUIRED
#HTTP Access
http_access allow manager localhost
http_access deny manager
http_access allow group_admins
http_access allow group_users user_url
http_access allow group_sec sec_url
Имхо тут плохо то, что proxy_auth здесь больше одного раза и squid будет терзать хелпер до появления первого OK — хотелось бы узнать, а вообше можно ли так делать, когда proxy_auth упоминается больше 1-го раза — не повлияет ли это на стабильность и т.д. Еще при использовании такой схемы был замечен глюк в IE7 -при попытке зайти куда либо спрашивает пароль 3 раза, потом пускает, возможно тоже из-за 3 proxy_auth, хотя в FF такого не замечено.
Или же есть еще 1 схема:
acl mydomain_site dstdomain .mydomain.ru
external_acl_type unix_group %LOGIN /usr/squid/libexec/check_group
acl auth proxy_auth REQUIRED
acl inet_full external unix_group inet-full
acl inet external unix_group inet
http_access allow auth mydomain_site
http_access allow inet_full
http_access allow inet user_url
Тут уже proxy_auth один раз, но неудобство в том, что приходись заводить пользователей дважды — в /etc/passwd и в passwd squid’а. И с этой схемой глюков с IE не замечено. В общем, хотелось бы выяснить, какая схема лучше. Сам склоняюсь к первой, т.к. проще пользователей заводить.
Squid, Kerberos и LDAP
Прокси-сервер Squid для предоставления доступа клиентов к ресурсам сети может осуществлять аутентификацию и авторизацию пользователей. Возможно построение взаимодействия с серверами Microsoft Active Directory путем аутентификации клиентов — членов домена, используя протокол Kerberos, и последующей авторизации членов групп домена.
[править] Принцип работы протокола Kerberos (схематически)
- Client (Пользователь) – пользователь, участник домена, запрашивающий доступ к ресурсам;
- AS (Authentication Server) — сервер аутентификации (например, Microsoft Active Directory);
- TGS (Ticket Granting Server) – сервер предоставления билетов (например, Microsoft Active Directory);
- SS (Service Server) – сервер предоставляющий доступ к ресурсам (например, прокси-сервер Squid);
- TGT (Ticket Granting Ticket) – билет для получения билета.
Определение протокола Kerberos а также более подробные пояснения его принципов работы можно почерпнуть из следующих источников:
- http://en.wikipedia.org/wiki/Kerberos_(protocol)
- http://ru.wikipedia.org/wiki/Kerberos
[править] Конфигурация пользователя для работы с Kerberos
Конфигурации клиентской машины
Пользователь должен быть членом домена и находится в базе данных домен контролера Microsoft Active Directory. Клиентская машина должна находиться в базе домен контроллера.
ОС пользователей: Windows 2000 или новее, Mac OS X и Linux. Поддерживаемые веб-обозреватели (browser): Internet Explorer 7.0 или новее (версия IE < версии 7.0 не работает с Kerberos), Mozilla Firefox версии 3,6 или новее и Safari (тесты проведены с версией 5.0.3).
В настройках прокси веб-обозревателя установить полное доменное имя (FQDN) прокси-сервера (например, proxy_squid@domain.loc) и номер порта (например, 3180).
Конфигурация сервера Microsoft Active Directory
- Необходимо настроить сервер Active Directory.
- Настроить DNS сервер. Обязательно внести записи доменного имени прокси-сервера proxy_squid.domain.loc.
Необходимо создать пользователя в домене: proxy_squid. Пароль пользователя должен не иметь срока годности (password never expires). Для оптимального уровня безопасности, пароль должен состоять из восьми символов — это минимум (буквы, цифры, а также специальные символы). Для аутентификации прокси-сервера на контроллере домена и последующей идентификации пользователей прокси-сервером Squid, необходимо создать файл keytab. Keytab – это файл который содержит Kerberos Principal (хост, пользователь и домен) и ключи шифрования (определяются из пароля Kerberos). Это файл применяется для аутентификации в инфраструктуре Kerberos (при этом не нужно вручную вводить логин и пароль). Squid будет использовать keytab для аутентификации пользователей через протокол Kerberos.
После создания, файл keytab необходимо скопировать на прокси-сервер (например, в каталог /etc/).
Создание файла keytab в командной строке домен контролера Microsoft Active Directory:
ktpass -princ HTTP/proxy_squid.domain.loc@DOMAIN.LOC -mapuser nbtname\proxy_squid -pass "password*" -ptype KRB5_NT_SRV_HST -out HTTP7.keytab
- nbtname — netbios имя домена
- password – указать пароль.
realm для Kerberos (то, что пишется после @) обязательно писать ЗАГЛАВНЫМИ буквами!
Конфигурация сетевого доступа к прокси-серверу
- Разрешить доступ прокси-серверов в сеть Интернет и обратно по протоколам: HTTP, HTTPS, SSH, FTP, DNS;
- Разрешить доступ прокси-серверов в локальную сеть (ЛВС) и обратно используя порты:
- Kerberos, TCP/UDP: 88, 464, 749, 750; TCP: 4444;
- Ldap, TCP/UDP: 389;
- Squid, TCP: 3180;
- SSH, TCP: 22, 10010, 10011;
- Msft-gc, TCP: 3268;
- Klogin, TCP: 543;
- Kshell, TCP: 544;
- Tell, TCP: 754;
- Eklogin, minipay, TCP: 2105;
- DNS, TCP/UDP: 53;
- HTTPS, TCP: 443;
- HTTP, TCP: 80;
- NTP, UDP: 123;
- ICMP.
[править] Конфигурация прокси-сервера Squid на базе ОС Linux
Пример для ОС CentOS
Прокси-серверу необходимо присвоить имя (hostname): proxy_squid.domain.loc.
Необходимо проверить доступность DNS сервера с помощью программ dig и nslookup. Если DNS сервер не настроен, настроить DNS. Имя прокси-сервера, должно быть занесено в базу DNS сервера.
Необходимо проверить синхронизацию времени на прокси-сервере, домен контролере и клиенте. Для правильной работы протокола Kerberos, разница во времени должна быть не больше 5 минут. Синхронизировать прокси-сервер с NTP сервером можно с помощью ntpdate.
Установка с FTP репозитория пакетов для Kerberos аутентификации, пакета Squid 3.0 и библиотеки SASL (Simple Authentication and Security Layer):
yum install cyrus-sasl-gssapi krb5-workstation krb5-devel squid3
Изменение прав доступа для keytab файла (это файла, который ранее был сформирован на домен контролере с помощью команды ktpass).
chown squid:squid /etc/HTTP7.keytab chmod u+rwx,g+rx /etc/HTTP7.keytab
Проверка правильности созданного файла keytab:
kinit –V –k –t /etc/HTTP7.keytab HTTP/proxy_squid.domain.loc@DOMAIN.LOC
Если файл создан верно, выполнится аутентификация в домене: Authenticated to Kerberos v5.
Посмотреть полученный билет Kerberos можно с помощью команды klist.
Изменение конфигурации аутентификации Kerberos. В файл /etc/krb5.conf необходимо внести следующие изменения:
[logging] default = FILE:/var/log/kerberos/krb5libs.log kdc = FILE:/var/log/kerberos/krb5kdc.log admin_server = FILE:/var/log/kerberos/kadmind.log [libdefaults] default_realm = DOMAIN.LOC dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h
forwardable = true proxiable = true default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
[realms] DOMAIN.LOC = < #Перечень домен контроллеров kdc = 192.168.1.5 kdc = 192.168.1.6 kdc = 192.168.1.7 admin_server = 192.168.1.5 default_domain = domain.loc >[domain_realm] .domain.loc = DOMAIN.LOC domain.loc = DOMAIN.LOC
[appdefaults] pam =
[login] krb4_convert = true krb4_get_tickets = false
Для автоматической аутентификации через Squid, необходимо внести следующие изменения в исполняемый файл /etc/init.d/squid
KRB5_KTNAME=/etc/HTTP7.keytab export KRB5_KTNAME
Если необходимо использовать для работы прокси-сервера Squid не стандартный порт (например, 3180), открыть этот порт в SELinux.
semanage port -a -t http_cache_port_t -p tcp 3180 service squid start
[править] Аутентификация пользователей Active Directory
Настройка аутентификации в конфигурационном файле /etc/squid/squid.conf. Для аутентификации используется встроенная в Squid программа squid_kerb_auth.
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d -s HTTP/proxy_squid.domain.loc@DOMAIN.LOC auth_param negotiate children 20 auth_param negotiate keep_alive on
[править] Авторизация пользователей Active Directory
Авторизация пользователей через Kerberos
external_acl_type (тут задаем произвольное имя для squid) Internet_User ttl=300 negative_ttl=60 %LOGIN /usr/libexec/squid/ext_kerberos_ldap_group_acl -a -g (а тут указываем имя группы из AD) Group_Internet_User -D DOMAIN.LOCAL
И так для всех необходимых групп. Всё, никаких паролей и страшных строчек LDAP авторизации.
Авторизация пользователей через LDAP
Необходимо авторизовать аутентифицированного пользователя с помощью squid_ldap_group.
Проверка авторизации пользователя в командной строке:
/usr/lib/squid/squid_ldap_group -R -b "dc=domain,dc=loc" -f "(&(objectclass=user)(sAMAccountName=%v)(memberof=cn=%a,OU=ProxyServer,OU=Services,OU=KYIV,DC=domain,DC=loc))" -D "proxy_squid@domain.loc" -W "/etc/squid/pass*" -K -d 192.168.1.5 192.168.1.6 192.168.1.7
Опция –W указывает на путь к файлу, который содержит пароль. Пользователем файла должен быть squid. Пароль должен совпадать с паролем в Kerberos keytab файле, сформированном ранее при помощи ktpass.
Если при вводе данных в формате пользователь группа получаем вывод OK, значит — авторизация работает. Если авторизация не работает, необходимо проверить путь хранения группы на контроллере домена (для этого можно использовать команду ldapsearch).
Если проверка работает, добавить конфигурацию для squid_ldap_group в /etc/squid/squid.conf:
Параметр %LOGIN в описании внешней группы указывает на то, перед проверкой на вхождение в эту группу, пользователя необходимо аутентифицировать
external_acl_type ldap_check ttl=1200 %LOGIN /usr/lib/squid/squid_ldap_group -R -b "dc=domain,dc=loc" -f "(&(objectclass=user)(sAMAccountName=%v)(memberof=cn=%a,OU=ProxyServer,OU=Services,OU=KYIV,DC=domain,DC=loc))" -D "proxy_squid@domain.loc" -W "/etc/squid/pass*" -K -d 192.168.1.5 192.168.1.6 192.168.1.7
[править] Определение правил доступа для пользователей
Проверка через Kerberos
acl Internet_User external Internet_User http_access allow Internet_User
Проверка через LDAP
Группе GG-KV-GOUP0 и GG-KV-GROUP1 предоставлен доступ в Интернет через Squid. Группа GG-KV-GROUP0 не получает доступа к файлам в Интернете, тип которых указан в файле /etc/squid/blocked (для определения типов файлов можно использовать регулярные выражения). Группа GG-KV-GROUP0 получает доступ ко всем файлам тип которых не указан в файле /etc/squid/blocked. Группа GG-KV-GROUP1 получает полный доступ ко всем файлам.
acl inet_access0 external ldap_check GG-KV-GROUP0 acl inet_access1 external ldap_check GG-KV-GROUP1 acl block_this_for_ggkvgroup0 url_regex -i "/etc/squid/blocked" http_access deny inet_access0 block_this_for_ggkvgroup0 http_access allow inet_access0 http_access allow inet_access1 .
[править] Определение политик QoS (delay pools)
acl ad128 external ldap_check GG-KV-GROUP0 acl ad256 external ldap_check GG-KV-GROUP1 .
Объявить delay pools
delay_pools 3 delay_class 1 1 delay_class 2 1 .
Определить принадлежность пользователей к delay pools
delay_access 1 allow ad128 delay_access 1 deny all delay_access 2 allow ad256 delay_access 2 deny all .
Ограничить пропускную способность
delay_parameters 1 16000/16000 #128Kb на всех delay_parameters 2 32000/32000 #256Kb на всех
timp87
Не так давно появилась задача разграничения доступа пользователей в интернет. Причем, всем в инет можно, кроме небольшой (относительно всей компании) группы людей.
В конторе у нас в качестве пользовательской ОС используется Windows (7+). Конечно, есть AD (2008+). Есть еще домены филиалов, с которыми установлены доверительные отношения (не помню, вроде только в одну сторону).
Надо поднимать web proxy. Требования в такой ситуации напрашиваются сами собой: нужно аутентификацию и авторизацию для прокси брать из AD (не путай эти понятия!).
В качестве инструментов хотелось использовать FreeBSD и squid.
Пошел я гуглить и искать инфу. В сети огромное количество howto’шек разной степени бестолковости. Кто в лес, кто по дрова, не понимая, нужны ли эти дрова вообще и куда их пихать. По кусочкам кое-что получилось понять, а дальше ваял сам. Тут результат понимания и описание процесса, чтобы сам потом мог легко вспомнить.
В итоге доступ в инет был организован для пользователей домена, а также, некоторых сетей (устройств), где не нужна аутентификация/авторизация.Все по понятиям
Потенциально аутентификация в моем случае возможна несколькими способами:
— NTLM
— LDAP
— Kerberos
Первый — этакая попытка Microsoft’а сделать свой Kerberos. Но сейчас его уже закапывает сам Microsoft, отказываясь от него в пользу третьего. Да и сам по себе протокол плохой (да, да, хэш от пароля ходит по сети). Второй неплох, но требует от пользователя ручного ввода пароля при аутентификации, т.е. браузер будет просить ввести логин/пасс выводя окошко. А вот Kerberos — то, что нужно. Он безопасный и все будет выглядеть прозрачно: никаких предложений ввести пароль и т.д. Правда, он чуть сложнее в настройке, чем предыдущие варианты, и старые версии Windows его не умеют.
Авторизация — через LDAP. Других способов я не знаю. Т,е. в AD есть security группа, в которую добавлены учетные записи (или другие группы, см. ниже) неугодных пользователей.
Разворачивал все это дело я на FreeBSD 10.0-RELEASE amd64. В качестве прокси — squid. Весь софт ставился из свежих портов. На Linux’е весь смысл тот же, только софт называется немного иначе.
Все это хозяйство настраивал и проверял по частям, сначала сделал аутентификацию, проверил ее, потом сверху примостил авторизацию, проверил, а потом сделал некоторые корректировки.База
Первым делом я разбирался с тем, как работает Kerberos. Это очень помогло в понимании того, что нужно делать. Как пример http://itband.ru/2010/12/kerberos1/ или http://www.oszone.net/4188/Kerberos. Из описания следует требование: время на серверах и клиентах должно быть синхронизировано. Проверил время, автозапуск ntpd и т.д. Конечно, нужен еще работающий DNS.
Далее осмыслив работу Kerberos я понял, что сервер, предоставляющий сервис, на котором аутентифицируется доменный клиент тоже должен аутентифицироваться. С пользователем все просто: у него есть учетка в AD, в которой записаны логин и хэш от его пароля. Хэш от пароля и есть закрытый ключ пользователя, которым он шифрует некоторые части пакетов при аутентификации на KDC. Пользователь знает свой пароль и клиентский софт извлекает из него хэш. KDC тоже знает хэш пользователя. И тот и другой может зашифровать и расшифровать пакет этим ключом. Но что с серверами? Сервер же тоже должен иметь какой-то закрытый ключ, который должен знать как KDC, так и сам сервер.Создание учетки для прокси в AD
Вообще, когда виндовые серверы заводятся в домен, у них появляется «учетка» в AD типа computer, для которой, скорей всего (честно, не знаю), формируется на каком-то шаге (может при развертывании какого-либо сервиса/роли) закрытый ключ. Потом этот ключ как-то попадает на этот новый сервер, я предполагаю. В моем случае сервер не виндовый, и мне нужно сделать это вручную.
В сети можно найти много статей где прокси *nix-сервер добавляют в домен, перед этим долго и мучительно настраивая samba. Это совсем необязательно. Это делается только для того, чтобы получить из AD файл keytab для «учетки» типа computer, от которой будет аутентифицироваться прокси сервер. Keytab, насколько я понял — это что-то вроде контейнера с закрытыми ключами, которыми будет пользоваться демон/сервис (squid) при аутентификации по Kerberos’у.
Есть 2 пути создания «учетки» в AD для сервера: добавление сервера в домен c помощью samba с самого *nix сервера (так создается «учетка» типа computer), или можно создать обычного пользователя (тип user) в AD любыми средствами, например, оснасткой «AD users and computers». Понятно, что второй способ проще.
Затем есть 3 способа извлечения файла keytab для созданной «учетки»: с помощью samba на *nix сервере (сервер должен быть в домене), утилитой mskutil на *nix сервере, или утилитой ktpass на контроллере домена. Опять же, последний мне показался проще.
Я создал пользовательскую учетку с именем «squid», задал ей пароль «passWD». По нашим правилам я создал ее в контейнере «Special accounts», который находится на вершине дерева AD. После чего экспортировал keytab с помощью ktpass так (описание опций читай в хелпе):> ktpass -princ HTTP/proxy.example.org@EXAMPLE.ORG -mapuser SAMPLE\squid -pass passWD -crypto all -ptype KRB5_NT_SRV_HST -out squid.keytab
Предположим, что мой домен назван «example.org», а NetBios-имя моего домена «sample». Контроллеры домена называются dc1.example.org и dc2.example.org. Сам сервер, который я настраивал зовется proxy.example.org.
На выходе ktpass получился файл squid.keytab. Его нужно скопировать на *nix сервер.Настройка Kerberos на FreeBSD
Во FreeBSD уже есть в базовой системе реализация Kerberos’а, так что ничего дополнительного устанавливать для его работы не надо, только настроить. Вообще в мире opensource *nix реализаций этого протокола 2 штуки: Heimdal и MIT. Первая чаще используется в BSD, вторая в Linux.
Все настройки Kerberos’а хранятся в файле /etc/krb5.conf (надо создать его). Туда для моего домена нужно записать:[libdefaults]
default_realm = EXAMPLE.ORG
default_keytab_name = /usr/local/etc/squid/squid.keytab [realms]
EXAMPLE.ORG = kdc = dc1.example.org
kdc = dc2.example.org
admin_server = dc1.example.org
default_domain = example.org
>
[domain_realm]
.example.org = EXAMPLE.ORG
example.org = EXAMPLE.ORGТут все более-менее понятно, если что, можно глянуть в ман krb5.conf(5). Строка default_keytab_name указывает на файл keytab, который будет использоваться по-умолчанию всеми службами, которым нужен Kerberos, если ничего другого не указано. Другой способ задания файла keytab — в переменных окружения конкретного демона, например, в скрипте запуска этого демона(как тут http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos). Т. е. там можно для каждого демона задать свой keytab. Замечу, что под FreeBSD можно просто добавить строку squid_krb5_ktname=»path/to/keytab» в /etc/rc.conf. У меня прокси не будет выполнять других функций, для которых нужен Kerberos, так что я задал keytab в /etc/krb5.conf.
Теперь, когда все настроено и на месте можно посмотреть в keytab на предмет поддерживаемого шифрования:# ktutil -k /usr/local/etc/squid/squid.keytab list
/usr/local/etc/squid/squid-v.keytab:
Vno Type Principal Aliases
4 des-cbc-crc HTTP/proxy.example.org@EXAMPLE.ORG
4 des-cbc-md5 HTTP/proxy.example.org@EXAMPLE.ORG
4 arcfour-hmac-md5 HTTP/proxy.example.org@EXAMPLE.ORG
4 aes256-cts-hmac-sha1-96 HTTP/proxy.example.org@EXAMPLE.ORG
4 aes128-cts-hmac-sha1-96 HTTP/proxy.example.org@EXAMPLE.ORGА потом проверить возможность аутентификации в AD через Kerberos:
# kinit -k HTTP/proxy.example.org
# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: HTTP/proxy.example.org@EXAMPLE.ORG
Issued Expires Principal
Feb 7 14:37:49 2014 Feb 8 00:37:44 2014 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
# kdestroyПолучил тикет, посмотрел на него, удалил.
Установка squid
Squid я ставил из портов, конкретно www/squid33. Был он версии 3.3.11. Я уверен, что когда кто-то будет читать эти строки, версия будет новей и порт будет называться www/squid. Тут было несколько нюансов. Сильно забегая вперед:
изначально, для настройки аутентификации и авторизации я ставил squid, добавив к стандартным только опции AUTH_LDAP иAUTH_KERB(ныне опция называется GSSAPI_* в зависимости от выбираемой реализации). Как оказалось потом, с аутентификацией все было хорошо, но с авторизацией пришлось повозиться. Вышло так, что хелпер ext_ldap_group_acl (опция AUTH_LDAP) не умеет работать с вложенными группами. Т.е. он просто проверяет наличие пользователя в конкретной группе. Если в группе запрета интернета есть вложенная группа, а уже во вложенной наш пользователь, то ext_ldap_group_acl этого не узнает. Не удобно, ведь не хочется добавлять в группу запрета интернета пользователей по одной учетке, хочется же целыми отделами =) или группами из филиальских доменов. Пришлось еще погуглить и нашелся другой хелпер ext_kerberos_ldap_group_acl. (стандартно он называется squid_kerb_ldap), который умеет такую штуку, только наоборот, выполняет рекурсивный поиск нужной группы на основе списка членства в группах (MemberOf) самого пользователя. Только он не был у меня установлен. И как его доустановить штатными средствами я не сразу понял. Нужно было только заглянуть в Makefile порта www/squid33 и все стало понятно. Для установки этого хелпера нужна комбинация опций AUTH_LDAP и AUTH_SASL. После переустановки порта, хелпер появился, но не работал. В логе squid’а были сообщения вроде таких:ERROR: ldap_sasl_interactive_bind_s error: Can’t contact LDAP server
ERROR: Error while binding to ldap server with SASL/GSSAPI: Can’t contact LDAP serverТут всплыли еще подробности нужно было установить openldap-client с поддержкой sasl. Для этого вместо net/openldap24-client нужно поставить net/openldap24-sasl-client. Можно еще добавить WANT_OPENLDAP_SASL=yes в /etc/make.conf чтобы потом проблем не было.
Потом опять ничего не заработало:ERROR: ldap_sasl_interactive_bind_s error: Unknown authentication method
ERROR: Error while binding to ldap server with SASL/GSSAPI: Unknown authentication methodВ /usr/ports/UPDATING нашел, что плагин gssapi был отделен от основного порта cyrus-sasl2. Доустановил плагин security/cyrus-sasl2-gssapi. Наступило счастье =).
Настройка браузера.
Тут ест одно важное замечание: в качестве адреса прокси у пользователей в браузере должно быть указано полное dns имя сервера, например, proxy.example.org. Также будет работать если dns запись является CNAME.
А вот с забитым в браузере IP прокси сервера ничего работать не будет!Настройка squid
Действовал я пошагово, поэтому первым делом настроил и проверил аутентификацию:
auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth -s HTTP/proxy.example.org@EXAMPLE.ORG
auth_param negotiate children 50 startup=10 idle=5
auth_param negotiate keep_alive onВсе очевидно. Для справки можно смотреть в доку squid’а или вывод «negotiate_kerberos_auth -h». Скажу лишь, что на этапе отладки лучше всего перед опцией -s добавить -i, так в логе cache.log появится много интересной инфы. Ссылка, где в конце есть схема работы squid с Kerberos http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos.
Есть вариант проверки работоспособности хелпера, который я подсмотрел у Markus Moeller, выводящий огромное количество информации. Нужно в командной строке от рута запустить:# kinit username@EXAMPLE.ORG
# /usr/local/libexec/squid/negotiate_kerberos_auth_test proxy.example.org 1 | awk ‘Надо не забыть потом запустить kdestroy.
Затем я разобрался с авторизацией. Это конфиг:external_acl_type NoInet ttl=3600 negative_ttl=3600 children-max=50 children-startup=10 children-idle=5 grace=15 %LOGIN /usr/local/libexec/squid/ext_kerberos_ldap_group_acl -a -i -g DenyInternet -m 64 -D EXAMPLE.ORG -u squid -p passWD
Опять же, все есть в хелпе и доке. На время дебага можно еще перед -i добавить -d. Замечу опцию -m, указывает уровень рекурсии при поиске группы, и еще опцию grace, которая хорошо ускоряет авторизацию (читай в доке). DenyInternet — это группа из AD, в которой томятся неугодные юзеры. NoInet — это имя данного внешнего acl.
Проверить работоспособность этой части можно просто запустив хелпер с нужными опциями, т.е. копируем в командную строку все, что после %LOGIN. Затем вводим имя пользователя и получаем в ответ OK или ERR. Например, из командной строки:# /usr/local/libexec/squid/ext_kerberos_ldap_group_acl -a -i -g DenyInternet -m 64 -D EXAMPLE.ORG -u squid -p passWD
username@EXAMPLE.ORG
OKПользователь входит в группу, иначе получили бы ERR.
Остальная часть конфига:cache_dir diskd /var/squid/cache 25600 16 256acl NoAuthNet src 192.168.8.0/24
acl NoAuthDevice src 192.168.8.184/32
acl NoInetAD external NoInethttp_access allow NoAuthDevice
http_access allow NoAuthNet
http_access deny NoInetAD all
http_access allow allhttp_port 3128
cache_mgr helpdesk@example.orgПервая строчка описывает механизм работы squid’а с кэшем. В данном случае используется отдельный демон для дисковых операций с кэшем. Для его корректной работы нужно изменить некоторые sysctl’ки. Тут пример каких, и откуда они взялись https://forums.freebsd.org/viewtopic.php?f=43&t=44638. Однако, есть мнение, что все, кроме ufs «сломано» и нестабильно.
Затем описание acl’ей. Тут есть девайс и сеть, для которых аутентификация и авторизация не нужны. Потом привязываем внешний acl из настройки авторизации к другому acl NoInetAD.
Теперь собственно описание доступа (принцип работы как в ipfw). Проверка условий идет по порядку сверху вниз, слева направо, поэтому первым делом выпускаем в интернет сеть NoAuthNet и устройство NoAuthDevice.
Затем для тех кто не совпал с предыдущими правилами вызываем авторизацию, которая в свою очередь вызовет аутентификацию, т.е. не пускаем неугодных юзеров, которые состоят в группе в AD. Здесь нужно заметить, что не случайно написано слово deny, а не allow. Дело в том, что allow работает только для уже аутентифицированных пользователей и не вызывает повторный запрос на аутентификацию, если она до этого момента не состоялась. Отправку ответа «407 — Proxy authentification required» выполняет только deny. Еще можно заметить, что в конце стоит all. Это не просто так, т.к. если в описании http_access последним стоит acl с авторизацией/аутентификацией, то она будет запрашиваться снова и снова, вместо одного раза. Поэтому, если ее не будет, то неугодным пользователям будет показываться окно авторизации раз 5. Некрасиво. А так они сразу получают Access denied . Все эти особенности были вычитаны тут http://wiki.squid-cache.org/Features/Authentication. Там описано еще несколько полезных трюков по аутентификации.И последней строчкой разрешаем выход в инет.
Вот полезная ссылка про правила работы squid’а с списками доступа http://wiki.squid-cache.org/SquidFaq/SquidAclНа всякий случай
Не относится к всему посту, просто мало ли когда-нибудь пригодится портянка с аутентификацией и авторизацией простым LDAP:
# Authentification using LDAP
##Delete the comments to enable another one auth procedure if previous wasn’t passed.
##auth_param basic program /usr/local/libexec/squid/basic_ldap_auth -R -D squid@example.org -W /usr/local/etc/squid/ldap.txt -b «dc=example,dc=org» -f «sAMAccountName=%s» 192.168.1.2
#
# Authorization using LDAP
# -K — remove realm from username
# -d — turn on the debug
#external_acl_type InetGroup ttl=600 %LOGIN /usr/local/libexec/squid/ext_ldap_group_acl -R -b «dc=example,dc=org» -f «(&(objectclass=person)(sAMAccountName=%v)(memberOf=cn=%a,ou=Security Groups,dc=example,dc=org))» -D
squid@example.org -W /usr/local/etc/squid/ldap.txt -K -d 192.168.1.2 192.168.1.3Тут нужно помнить и указывать путь к контейнеру, где лежит служебная учетка squid.