Linux proxy active directory

Авторизация на SQUID через Active Directory

Инструкция подразумевает, что у нас уже есть рабочий Squid-сервер. В противном случае, настраиваем, используя инструкцию Установка и настройка Squid на CentOS.

Наш сервер будет принимать как наиболее безопасную Kerberos-авторизацию, так и NTLM. Для компьютеров в домене будет поддерживаться прозрачная LDAP-аутентификация. Все команды выполняются на примере системы Linux CentOS 7.

Подготовка

Настройка времени

Интеграция с 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:

Редактируем следующие строки:

[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, запросив тикет:

При правильных настройках мы увидим на подобие:

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 — принципал, который был задан при создании файла.

Картина, примерно, следующая:

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

Устанавливаем следующие пакеты:

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

Проверяем, что наш сервер умеет обращаться к службе каталогов:

* первая команда проверяет возможность отправлять запросы на контроллер домена; вторая — выводит список групп, находящихся в каталоге.

Настройка SQUID

Для скрипта запуска squid добавим следующее:

KRB5_KTNAME=/etc/squid/proxy.keytab
export KRB5_KTNAME

* в данном случае, мы задаем переменную KRB5_KTNAME, в которой указан путь до кейтаб файла.

Открываем конфигурационный файл squid:

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 reconfigure

Проверка

Для проверки на сервере открываем лог:

tail -f /var/log/squid/access.log | grep dmosk

* dmosk — учетная запись в AD, от которой будем проверять работу squid.

Теперь на клиентском компьютере заходим в систему под нашей учетной записью (в данном примере, dmosk) и грузим любой сайт.

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

1526474100.078 240 192.168.1.16 TCP_TUNNEL/200 934 CONNECT syndication.twitter.com:443 dmosk HIER_DIRECT/134.144.40.72 —
1526474100.743 45 192.168.1.16 TCP_TUNNEL/200 559 CONNECT login.vk.com:443 dmosk HIER_DIRECT/187.244.139.145 —

Авторизация на основе групп AD

Ранее, мы предоставили доступ к сети Интернет любому пользователю Active Directory. Теперь ограничим доступ с помощью групп AD DS.

Для начала, создаем 2 группы пользователей, например:

1. squidusers. Пользователи squid, которым будет предоставлен доступ к сети Интернет с ограничениями.
2. squidsuperusers. Этим пользователям будет предоставлен неограниченный доступ.

Теперь на прокси-сервере открываем конфигурационный файл squid:

Добавляем после настройки аутентификации:

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 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 для общей аутентификации комментируем.

#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:

В разделе с 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:

* в данном примере мы блокируем доступ к социальным сетям facebook и ВКонтакте.

Перечитываем конфигурацию squid:

squid -k reconfigure

Возможные ошибки

1. Password set failed! 0x00000020

Возникает при попытке создать keytab на контроллере домена.

Причина: учетная запись, которая используется в ключе /mapuser находится в одном из подразделений, названных с применением кириллицы.

Решение: перенесите учетную запись для связывания в подразделение, названное на латинице, например, CN=Users,dc=domain,dc=local.

Читайте также

Другие инструкции по SQUID, которые могут показаться интересными:

Источник

Прокси Squid с авторизацией в домене Active Directory

Как то раз мы рассматривали настройку прокси squid для начинающих в среде Windows. Потом мы настраивали squid в «роутере из коробки» — pfSense. А сегодня мы покажем как создать мощный прокси сервер в Linux Debian. Зачем? Дело в том, что даже в pfSense мы не можем раскрыть всю мощь squid без бубна. Поэтому, если перед вами стоит задача сделать бескомпромиссный прокси сервер — Linux единственный вариант.

Что мы будем делать? Ну… например заставим работать Squid сразу в двух режимах: прозрачном (transparent) и обычном. Это нужно на тот случай, если в вашей организации есть отдельная гостевая сеть для приходящих людей и вы хотите фильтровать трафик, но при этом лишние логины и пароли для каждого гостя создавать/вести/выдавать нет никакого желания. При этом все сотрудники будут правильно учитываться, потому что мы настроим взаимодействие прокcи сервера с Active Directory. В заключении еще прикрутим анализатор логов, чтобы всегда знать кто и как использует интернет.

Первое что нам понадобится — это установленный Debian с настроенной сетью. Для будущего прокси-сервера на роутере должен быть открыт доступ в интернет. Как вариант, можно совместить роутер и прокси-сервер в одной машине, но это уже другая история, которую мы тоже как нибудь затронем. А пока на всех этих мелочах мы останавливаться не будем, просто приведем ссылки на нужные обзоры:
1. Установка Linux Debian
2. Настройка сети в Linux Debian

Присоединение к Active Directory

Нам нужно присоединить нашу Linux машину к домену Active Directory. Для этого нужно выполнить ряд подготовительных действий.
Сначала нам нужно научить наш будущий прокси сервер синхронизировать время с домен-контроллером. Устанавливаем NTP командой apt-get install ntp

После этого вносим некоторые коррективы в файл /etc/ntp.conf добавляем строку server IP_адрес_домен-контроллера. Остальные строки, начинающиеся со слова server лучше закоментировать, поставив символ # перед ними. В итоге должно получиться вот так:

Затем правим файл /etc/resolv.conf — здесь указываются адреса DNS-серверов. Для примера мой домен Active Directory будет называться mydomain.local, а домен-контроллер просто dc. По философии MS домен-контроллер является DNSом. Поэтому в первой строке указываем сам домен, во второй строке IP домен-контроллера:

После этих манипуляций лучше всего перезагрузиться.
Для проверки правильности наших действий даем команду ping dc. dc в данном случае это именно имя домен-контроллера, а не его адрес. Если все сделали правильно, то имя должно автоматически преобразоваться в адрес и пинги побегут…
Теперь нужно установить несколько пакетов для корректного взаимодействия с Active Directory. Выполняем команду apt-get install samba winbind krb5-admin-server krb5-clients krb5-config krb5-doc krb5-kdc krb5-user

После установки опять правим конфиг-файлы. Начнем с самбы.
Открываем файл /etc/samba/smb.conf, стираем из него все нафиг и пишем заново следующие строки:

[global]
workgroup = MYDOMAIN
netbios name = PROXY
realm = MYDOMAIN.LOCAL
server string =
security = ads
encrypt passwords = true
password server = dc.mydomain.local
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yse
winbind uid = 10000-20000
winbind gid = 10000-20000
Если вы внимательно посмотрели этот листинг, то заметили, что в строке server string после знака равенства стоит пробел — это не случайно. Добавляйте там пробел, иначе самба сама будет заполнять этот параметр на свое усмотрение, что не всегда хорошо.
Перезагружаемся.
Правим следующий файл /etc/krb5.conf В конечном итоге он должен выглядеть как показано на скриншоте ниже. Вместо mydomain.local и dc подставляете свои названия. Обратите внимание, что в разных частях файла эти названия написаны в разном регистре — это очень важно!

Перезагружаемся.

Выполняем команду kinit admin где вместо admin указываем логин администратора домена. Нас должны будут спросить пароль этого админа.

Теперь выполняем команду net ads join -U admin где вместо admin пишем логин администратора домена. После выполнения этой команды может появиться ошибка DNS сервера. Смело можно проигнорировать.
Еще выполним команды wbinfo -p и wbinfo -t
Обе команды должны завершиться успешно. Если так оно и получилось, то не поленитесь перезагрузить комп прокси-сервера.

Важное замечание: с описанными выше командами просто так лучше не играться. При подготовке этого обзора я от нефига делать выполнил эти команды на своем боевом прокси сервере. Сами команды выполнились успешно, но прокси после этого перестал воспринимать доменных пользователей. Помогла только перезагрузка машины.
Устанавливаем squid командой apt-get install squid

Настройка squid

Открываем файл /etc/squid/squid.conf
Можно стереть там все, мы напишем заново только нужные нам вещи.
Затем добавляем вот такие строки (собственно благодаря им squid обращается к Active Directory):
auth_param ntlm program /usr/bin/ntlm_auth —helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5

Теперь укажем, что наш прокси будет работать в двух режимах (192.168.17.6 — IP-адрес прокси):
http_port 192.168.17.6:3128
http_port 192.168.17.6:3127 transparent
В Active Directory можно сделать несколько уровней доступа к интернету для разных сотрудников. Для этого на домен-контроллере создайте к примеру 3 группы. Одну назовем Internet_Full, другую Internet_Medium, третью Internet_Low. Первая группа будет иметь доступ куда угодно без всяких ограничений, во вторую группу можно добавить всех пользователей, они будут иметь доступ куда угодно за исключением черного списка сайтов. Третья группа для всяких неувязков, им будет доступ только на сайты из белого списка.
Сначала сделаем ссылки на списки белых и черных ресурсов (это будут отдельные файлы, которые мы создадим сами)
acl white_list url_regex -i «/etc/squid/white_list»
acl black_list url_regex -i «/etc/squid/black_list»

в конфиге пропишем ссылки на эти группы:
acl Full external nt_group Internet_Full
acl Medium external nt_group Internet_Medium
acl Low external nt_group Internet_Low

Далее пропишем сети и гостей (в моем примере сегмент гостевой сети имеет адресацию 192.168.18.0/24):

acl all src 0.0.0.0/0.0.0.0
acl guests src 192.168.18.0/255.255.255.0

Делаем проверку сотркдников через домен обязательной:
acl nt_group proxy_auth REQUIRED

Чтобы наши гости не съели всю пропускную способность интернет-канала надо «зарезать» их по скорости. Для этого создается «пул задержек» в терминологии прокси-сервера. Этому пулу назначается ограничение скорости и к кому это дело применяется. В итоге мы напишем такие строки:
delay_pools 1
delay_class 1 1
delay_parameters 1 128000/128000
delay_access 1 allow guests

В delay_parameters указывается номер нашего пула и ограничение скорости на хводящий и исходящий траффик через дробь в байтах/сек. В моем примере для гостей получится скорость 1 Мбит/с.

Теперь пишем сами правила доступа.
Для гостевой сети доступ без ограничений:
http_access allow guests

для доменных групп:
http_access allow Low white_list
http_access deny Low deny
http_access deny Medium black_list
http_access allow Medium
http_access allow Full

Теперь добавим несколько строк по логированию доступа в интернет (это нам понадобится чуть позже):
access_log /var/log/squid/access.log
logfile_rotate 100

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

Создайте файлы /etc/squid/white_list и /etc/squid/black_list
В этих файлах в столбик можно просто писать названия сайтов. В файл черного списка — плохие сайты, в белый — хорошие 🙂

Для того чтобы все гости ходили тоже через прокси-сервер, на роутере необходимо «завернуть» гостевой трафик. В случае, если у вас роутер на базе linux, то это делается простой командой iptables -t nat -A PREROUTING -s 192.168.18.0/24 -p tcp —dport 80 -j DNAT —to 192.168.17.6:3127

Если вы сквид устанавливали прямо на роутер, то еще проще:
iptables -t nat -A PREROUTING -s 192.168.18.0/24 -p tcp —dport 80 -j REDIRECT —to-port 3127

С вероятностью 99% ваш итоговый конфигурационный файл будет отличаться от нашего примера, вам захочется что-то изменить, добавить или удалить. Так вот, есть одна замечательная консольная команда, которая пишется так: squid -k reconfigure Работает она как кнопка «Применить» после того как вы внесли изменения в конфиг.

Анализ логов

Для анализа доступа в интернет нам нужно установить apache и lightsquid. Делается это простой командой apt-get install apache2 lightsquid
Для просмотра статистики нужно просто через браузер зайти на адрес прокси-сервера. В нашем примере вот так:
http://192.168.17.6/lightsquid

Картина будет следующая:

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

Источник