Тематические термины: Squid , AD , CentOS .
Инструкция подразумевает, что у нас уже есть рабочий Squid-сервер. В противном случае, настраиваем, используя инструкцию Установка и настройка Squid на CentOS .
Наш сервер будет принимать как наиболее безопасную Kerberos-авторизацию, так и NTLM. Для компьютеров в домене будет поддерживаться прозрачная LDAP-аутентификация. Все команды выполняются на примере системы Linux CentOS 7.
Подготовка
Настройка времени
Имя сервера
Настройка на контроллере домена
Создание учетной записи
Создание keytab-файла
Настройка CentOS
Kerberos
NTLM
Настройка SQUID
Проверка
Авторизация на основе групп AD
Блокировка сайтов
Возможные ошибки
Читайте также
Подготовка
Настройка времени
Интеграция с Active Directory требует минимального расхождения времени с контроллером домена. Устанавливаем утилиту chrony:
yum install chrony
Запускаем службу для синхронизации времени:
systemctl enable chronyd —now
Имя сервера
Задаем имя сервера следующей командой:
hostnamectl set-hostname proxy.domain.local
* где proxy — имя сервера; domain.local — доменное имя, используемое в сети.
Настройка на контроллере домена
Создание учетной записи
Открываем консоль управления пользователями и добавляем нового со стандартными правами. От этой учетной записи будут выполняться запросы к AD DS.
В своем примере мы создаем пользователя squid.
Учетная запись должна быть размещена по пути, в котором присутствуют названия только на латинице. Подразделения и контейнеры не должны быть на русском.
Создание keytab-файла
В двух словах, данный файл позволяет установить легитимность нашего Linux-сервера. Создается он на контроллере домена и копируется на последний.
Для создания файла переходим на контроллер домена и от имени администратора запускаем Powershell или обычную командную строку. Вводим:
ktpass /princ HTTP/proxy.domain.local@DOMAIN.LOCAL /mapuser squid@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass «password» /out C:proxy.keytab
* где proxy.domain.local — полное имя нашего squid-сервера; DOMAIN.LOCAL — наш домен; squid@DOMAIN.LOCAL — учетная запись в AD для выполнения запросов (создана на шаге выше); password — пароль, который будет задан пользователю (должен соответствовать требованию AD).
* регистр важен.
В нашем примере, после выполнения команды на контроллере домена в корне диска С появится файл proxy.keytab. Его копируем на Linux-сервер, например, при помощи WinSCP .
Настройка CentOS
Kerberos
Устанавливаем следующие пакеты:
yum install cyrus-sasl-gssapi krb5-workstation krb5-devel
Открываем конфигурационный файл Kerberos:
vi /etc/krb5.conf
Редактируем следующие строки:
[libdefaults]
…
default_realm = DOMAIN.LOCAL
..
[realms]
DOMAIN.LOCAL = {
kdc = 192.168.0.15
kdc = 192.168.0.16
kdc = 192.168.0.17
admin_server = domain.local
}
* DOMAIN.LOCAL — наш домен; kdc — перечень контроллеров домена; admin_server — первичный контроллер (в данном примере будет использоваться случайный).
Проверяем настройки krb, запросив тикет:
kinit domainuser
klist
При правильных настройках мы увидим на подобие:
Ticket cache: KEYRING:persistent:0:0
Default principal: domainuser@DOMAIN.LOCAL
Valid starting Expires Service principal
15.05.2018 10:08:33 15.05.2018 20:08:33 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 22.05.2018 10:08:30
Проверяем keytab-файл, который мы перенесли на сервер с контроллера домена:
kinit -V -k -t /etc/squid/proxy.keytab HTTP/proxy.domain.local@DOMAIN.LOCAL
* где /etc/squid/proxy.keytab — путь до keytab-файла; HTTP/proxy.domain.local@DOMAIN.LOCAL — принципал, который был задан при создании файла.
И снова:
klist
Картина, примерно, следующая:
Ticket cache: KEYRING:persistent:0:krb_ccache_9MN6pt8
Default principal: HTTP/proxy.domain.local@DOMAIN.LOCAL
Valid starting Expires Service principal
16.05.2018 09:35:20 16.05.2018 19:35:20 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 23.05.2018 09:35:20
Зададим файлу следующие права:
chown squid:squid /etc/squid/proxy.keytab
chmod u+rwx,g+rx /etc/squid/proxy.keytab
NTLM
Устанавливаем следующие пакеты:
yum install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation
Конфигурируем
authconfig —enablekrb5 —krb5kdc=domain.local —krb5adminserver=domain.local —krb5realm=domain.LOCAL —enablewinbind —enablewinbindauth —smbsecurity=ads —smbrealm=domain.LOCAL —smbservers=domain.local —smbworkgroup=domain —winbindtemplatehomedir=/home/%U —winbindtemplateshell=/bin/bash —enablemkhomedir —enablewinbindusedefaultdomain —update
* где domain.local — это наш домен, domain — домен в сокращенной нотации. Регистр важен.
* если после ввода команды мы увидим ошибку Job for winbind.service failed because the control process exited with error code. See «systemctl status winbind.service» and «journalctl -xe» for details — игнорируем ее. Она возникает из-за того, что наш сервер еще не в домене.
Добавляем сервер в домен:
net ads join -U administrator
* где administrator — учетная запись в AD с правами на ввод компьютеров в домен.
Разрешаем автозапуск winbind и запускаем его:
systemctl enable winbind
systemctl start winbind
Проверяем, что наш сервер умеет обращаться к службе каталогов:
wbinfo -t
wbinfo -g
* первая команда проверяет возможность отправлять запросы на контроллер домена; вторая — выводит список групп, находящихся в каталоге.
Настройка SQUID
Для скрипта запуска squid добавим следующее:
vi /etc/default/squid
KRB5_KTNAME=/etc/squid/proxy.keytab
export KRB5_KTNAME
* в данном случае, мы задаем переменную KRB5_KTNAME , в которой указан путь до кейтаб файла.
Открываем конфигурационный файл squid:
vi /etc/squid/squid.conf
И добавляем:
auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -d -s HTTP/proxy.domain.local@DOMAIN.LOCAL
auth_param negotiate children 20
auth_param negotiate keep_alive on
auth_param ntlm program /usr/bin/ntlm_auth —diagnostics —helper-protocol=squid-2.5-ntlmssp —domain=DOMAIN
auth_param ntlm children 10
auth_param ntlm keep_alive off
* где /usr/lib64/squid/negotiate_kerberos_auth — путь до библиотеки аутентификации по kerberos, ее путь может отличаться — это зависит от версии системы; HTTP/proxy.domain.local@DOMAIN.LOCAL — учетная запись в keytab.
Также настраиваем, чтобы squid требовал аутентификацию. Для этого в секции acl добавим:
acl auth proxy_auth REQUIRED
Далее это:
http_access allow localnet
Меняем на:
http_access allow auth
* в нашем случае acl localnet использовалась для предоставления доступа.
Проверяем настройки конфигурационного файла:
squid -k parse
И если ошибок нет:
squid -k reconfigure
Проверка
Для проверки на сервере открываем лог:
tail -f /var/log/squid/access.log | grep remontka
* remontka — учетная запись в AD, от которой будем проверять работу squid.
Теперь на клиентском компьютере заходим в систему под нашей учетной записью (в данном примере, remontka) и грузим любой сайт.
На сервер в логах должны появиться записи, примерно, такого вида:
1526474100.078 240 192.168.1.16 TCP_TUNNEL/200 934 CONNECT syndication.twitter.com:443 remontka HIER_DIRECT/134.144.40.72 —
1526474100.743 45 192.168.1.16 TCP_TUNNEL/200 559 CONNECT login.vk.com:443 remontka HIER_DIRECT/187.244.139.145 —
Авторизация на основе групп AD
Ранее, мы предоставили доступ к сети Интернет любому пользователю Active Directory. Теперь ограничим доступ с помощью групп AD DS.
Для начала, создаем 2 группы пользователей, например:
- squidusers. Пользователи squid, которым будет предоставлен доступ к сети Интернет с ограничениями.
- squidsuperusers. Этим пользователям будет предоставлен неограниченный доступ.
Теперь на прокси-сервере открываем конфигурационный файл squid:
vi /etc/squid/squid.conf
Добавляем после настройки аутентификации:
external_acl_type squid_users_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g squidusers@DOMAIN.LOCAL
external_acl_type squid_superusers_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g squidsuperusers@DOMAIN.LOCAL
external_acl_type squid_users_from_ad_ntlm %LOGIN /usr/lib64/squid/ext_wbinfo_group_acl -d
* где
- squid_users_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе squidusers в домене DOMAIN.LOCAL .
- squid_superusers_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе squidsuperusers в домене DOMAIN.LOCAL .
- squid_users_from_ad_ntlm — произвольное название acl, авторизованных пользователей в AD через NTLM.
В секции acl:
#acl auth proxy_auth REQUIRED
acl squid_users_acl_krb external squid_users_from_ad_krb
acl squid_superusers_acl_krb external squid_superusers_from_ad_krb
acl squid_users_acl_ntlm external squid_users_from_ad_ntlm squidusers
acl squid_superusers_acl_ntlm external squid_superusers_from_ad_ntlm squidsuperusers
* где
- squid_users_acl_krb — произвольное название acl для всех, кто входит в squid_users_from_ad_krb ;
- squid_superusers_acl_krb — произвольное название acl для всех, кто входит в squid_superusers_from_ad_krb ;
- squid_users_acl_ntlm — произвольное название acl для всех, кто входит в squid_users_from_ad_ntlm ;
- squid_superusers_acl_ntlm — произвольное название acl для всех, кто входит в squid_superusers_from_ad_ntlm ;
* предыдущую acl для общей аутентификации комментируем.
В секции allow:
#http_access allow auth
http_access allow squid_superusers_acl_krb
http_access allow squid_superusers_acl_ntlm
http_access allow squid_users_acl_krb
http_access allow squid_users_acl_ntlm
* разрешаем доступ для созданных ранее acl; предыдущее разрешение для всех пользователей AD запрещаем. На данном этапе разницы между пользователями групп squidusers и squidsuperusers нет — позже мы настроим ограничение доступа к сайтам, где будем применять разные группы для предоставления различных прав.
Перечитываем конфигурацию прокси-сервера:
squid -k reconfigure
Ограничение доступа к сайтам
Мы рассмотрим простой пример блокировки двух сайтов. Доступ к ним будет ограничен в рабочее и ночное время для пользователей группы squidusers. Пользователи группы squidsuperusers будут иметь полный доступ ко всем сайтам.
Открываем конфигурационный файл squid:
vi /etc/squid/squid.conf
В разделе с ACL добавим 2 строки:
acl BLOCKED url_regex -i «/etc/squid/denysite»
acl BLOCKED_ACCESS time 18:00-23:59
* в данном примере мы создаем acl BLOCKED для сайтов, доступ к которым будем блокировать; список сайтов будем хранить в файле /etc/squid/denysite . Второй acl BLOCKED_ACCESS будем использовать для предоставления доступа к заблокированным сайтам, но с промежуток с 18:00 до 23:59 .
Теперь преобразовываем к следующему виду, ранее созданные правила для доступа:
http_access allow squid_superusers_acl_krb
http_access allow squid_superusers_acl_ntlm
http_access allow BLOCKED BLOCKED_ACCESS
http_access deny BLOCKED
http_access allow squid_users_acl_krb
http_access allow squid_users_acl_ntlm
* как видим, мы добавили правила блокировки после пользователей группы squidsuperusers — таким образом, на последних они не будут распространяться. Данные правила разрешают заблокированные сайты в указанный ранее промежуток времени и блокируют доступ к сайтам, перечисленным в файле /etc/squid/denysite .
Создаем файл /etc/squid/denysite:
vi /etc/squid/denysite
facebook.com
vk.com
* в данном примере мы блокируем доступ к социальным сетям facebook и ВКонтакте.
Перечитываем конфигурацию squid:
squid -k reconfigure
Возможные ошибки
1. Password set failed! 0x00000020
Возникает при попытке создать keytab на контроллере домена.
Причина: учетная запись, которая используется в ключе /mapuser находится в одном из подразделений, названных с применением кириллицы.
Решение: перенесите учетную запись для связывания в подразделение, названное на латинице, например, CN=Users,dc=domain,dc=local.
Читайте также
Другие инструкции по SQUID, которые могут показаться интересными:
1. Установка и настройка SAMS2 на CentOS
2. Установка и настройка SARG для анализа логов SQUID на CentOS
