Установка и настройка прокси-сервера Squid 3 с доменной аутентификацией, разграничением доступа к ресурсам по группам фильтрацией и пр.
Предполагается, что Вы попали сюда из основной статьи блока и понимаете описываемый здесь контекст. За основу этой статьи взят в целом добротный материал отсюда, однако мне потребовалось адаптировать его к моей системе (несколько иному итоговому функционалу) - немного расширить функционал, немного оптимизировать и "вылизать" (не все опции исходных статей заработали в моей системе без доработок).
Устанавливаем SQUID
Приступим к установке Squid 3, если следовать инструкциям основной статьи - сейчас самое время:
apt-get install squid3 ldap-utils
После установки проверим с какими параметрами собран установленный Squid (это формальность если используете дистрибутив Ubuntu 14.04, но в другом репозитории может оказаться менее функциональный пакет), чтобы убедиться в том, что он сможет работать со всеми нужными нам хелперами (вспомогательными утилитами выполняющими аутентификацию и авторизацию пользователей).
squid3 -v
Squid Cache: Version 3.3.8
Ubuntu
configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info'
'--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules'
'--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--enable-inline' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock'
'--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' '--enable-follow-x-forwarded-for'
'--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper'
'--enable-auth-ntlm=fake,smb_lm' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group'
'--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' '--with-swapdir=/var/spool/squid3'
'--with-logdir=/var/log/squid3' '--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter'
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
'LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
'CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security'
Обратите внимание на выделенные опции и их значения - должно быть примерно так.
Далее, в рамках подготовки Ubuntu Server к работе с механизмами аутентификации Kerberos и NTLM из Squid, донастроим их.
Донастраиваем Kerberos
Встречается два основных варианта настройки Kerberos на Linux. Первый - использование утилиты MSKTUTIL для создания в домене отдельной учетной записи компьютера, которая будет использоваться для аутентификации пользователей домена, а также для периодического изменения пароля этой учетной записи и регенерации keytab файла. Второй - упрощенный вариант (несколько страдает безопасность системы, т.к. необходимо запретить смену пароля для учетки которой авторизуется в домене Kerberos нашего сервера, или проделывать все перечисленные ниже операции вручную с нужной периодичностью) получения и использования keytab-файла. Далее мы создадим в домене AD служебную учетную запись пользователя (для авторизации нашего Kerberos в домене), отключим в свойствах учетной записи устаревание пароля и необходимость смены пароля, сгенерируем на контроллере домена для этой учетной записи keytab-файл, который затем скопируем на наш прокси сервер и будем использовать его для аутентификации Kerberos на постоянной основе.
Создаем в домене учетную запись пользователя для службы SQUID. В нашем примере это будет учетная запись DOMAIN\smbsrv01-SQUIDkrb (она будет использована для двух целей, что не очень хорошо для безопасности, но оптимизирует систему, для аутентификации Kerberos и для выполнения запросов в LDAP).
Отключим для учетной записи требование периодической смены пароля (Password never expires):
Для созданной учетной записи нам нужно сгенерировать keytab-файл на контроллере домена AD (в нашем случае на базе Windows Server 2008) с помощью утилиты ktpass (кроме того, этой операцией мы заменим принципала учетной записи на специальную строку которой представляется Squid , WindowsNT имя записи останется прежним и его можно будет использовать для аутентификации):
ktpass -princ HTTP/smbsrv01.domain.lan@DOMAIN.LAN -mapuser DOMAIN\smbsrv01-SQUIDkrb -pass PasSw0rd -crypto All -ptype KRB5_NT_PRINCIPAL -out C:\Temp\smbsrv01-SQUIDkrb.keytab
Targeting domain controller: smbsrv01.domain.lan Successfully mapped HTTP/smbsrv01.domain.lan to smbsrv01-SQUIDkrb. Password successfully set! Key created. Key created. Key created. Key created. Key created. Output keytab to C:\Temp\smbsrv01-SQUIDkrb.keytab: Keytab version: 0x502 keysize 83 HTTP/smbsrv01.domain.lan@DOMAIN.LAN ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x1 (DES-CBC-CRC) keylength 8 (0x...) keysize 83 HTTP/smbsrv01.domain.lan@DOMAIN.LAN ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x3 (DES-CBC-MD5) keylength 8 (0x...) keysize 91 HTTP/smbsrv01.domain.lan@DOMAIN.LAN ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x17 (RC4-HMAC) keylength 16 (0x....) keysize 107 HTTP/smbsrv01.domain.lan@DOMAIN.LAN ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x12 (AES256-SHA1) keylength 32 (0x.......) keysize 91 HTTP/smbsrv01.domain.lan@DOMAIN.LAN ptype 1 (KRB5_NT_PRINCIPAL) vno 4 etype 0x11 (AES128-SHA1) keylength 16 (0x.....)
Обратите внимание на то, что в параметре –princ мы указали имя сервера (HOSTNAME), для которого мы собираемся настроить аутентификацию Kerberos (в нашем случае это smbsrv01.domain.lan) используя выше-обозначенную учетную запись пользователя. Однако вместо этого, можно использовать другое имя, если например в перспективе есть задача использовать служебную учетную запись пользователя сразу для нескольких серверов SQUID с единой точкой входа для пользователей. Разумеется для каждого измененного имени в DNS должна быть создана статическая A-запись (PTR-запись не нужна) и эта запись должна указывать на IP-адрес нашего Linux-сервера (192.168.0.2). Кроме этого в настройках Squid нужно указать новое имя сервера (которым будет представляться Squid в AD).
В процессе генерации keytab-файла в домене в свойствах учетной записи пользователя изменится имя для входа а также будет изменён атрибут servicePrincipalName (будет добавлено значение из параметра -princ)
Теперь нам нужно безопасным способом передать получившийся файл smbsrv01-SQUIDkrb.keytab с компьютера под управлением Windows на Linux-сервер smbsrv01 в каталог /etc/squid3/. Сделать это можно например по протоколу SSH (ранее мы уже запустили службу сервера OpenSSH на smbsrv01) с помощью утилиты WinSCP или PSCP.
Передадим файл сначала в каталог /home/user/ (или ~ для краткости):
C:\Tools\PuTTy>pscp -scp C:\Temp\smbsrv01-SQUIDkrb.keytab user@smbsrv01:~/smbsrv01-SQUIDkrb.keytab
Теперь из каталога /home/user/ нам нужно будет переместить файл в в каталог /etc/squid3/
sudo mv /home/user/smbsrv01-SQUIDkrb.keytab /etc/squid3/smbsrv01-SQUIDkrb.keytab
Далее выставляем разрешения на keytab-файл таким образом, чтобы в дальнейшем служба Squid могла получить к нему доступ:
sudo chgrp proxy /etc/squid3/smbsrv01-SQUIDkrb.keytab sudo chmod 640 /etc/squid3/smbsrv01-SQUIDkrb.keytab
ls -la /etc/squid3/smbsrv01-SQUIDkrb.keytab
-rw-r----- 1 user proxy 477 May 31 20:45 /etc/squid3/smbsrv01-SQUIDkrb.keytab
***
Проверяем возможность аутентификации в AD с помощью Kerberos. Сначала выполняем команду, которая должна отработать без ошибок:
kinit -k HTTP/smbsrv01.domain.lan
Затем проверим наличие полученного билета Kerberos командой klist
klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/smbsrv01.domain.lan@DOMAIN.LAN
Valid starting Expires Service principal
05/31/2014 21:22:14 06/01/2014 07:22:14 krbtgt/DOMAIN.LAN@DOMAIN.LAN
renew until 06/01/2014 21:22:14
Как видим, билет успешно получен. Теперь можем удалить его командой kdestroy
***
Для того чтобы SQUID однозначно знал где искать keytab-файл, создадим файл настроек по умолчанию и откроем его на редактирование:
sudo touch /etc/default/squid3 sudo nano /etc/default/squid3
Впишем в файл следующие сроки:
KRB5_KTNAME=/etc/squid3/smbsrv01-SQUIDkrb.keytab export KRB5_KTNAME
На этом базовую поддержку Kerberos в рамках нашей задачи можно считать законченной, переходим к NTLM.
Донастройка NTLM
Проверяем статус доверительных отношений с доменом:
sudo wbinfo -t checking the trust secret for domain KOM via RPC calls succeeded
Проверяем аутентификацию пользователя в домене:
sudo wbinfo -a DOMAIN\\user Enter DOMAIN\user's password: plaintext password authentication succeeded Enter DOMAIN\user's password: challenge/response password authentication succeeded
Включим пользователя от имени которого будет работать Squid (proxy) в группу доступа для чтения каталога /var/run/samba/winbindd_privileged
sudo gpasswd -a proxy winbindd_priv Adding user proxy to group winbindd_priv
Забегая вперёд могу сказать, что проделанной настройки Samba4 оказалось недостаточно. Когда дело дошло до тестирования хелперов Squid, хелпер NTLM аутентификации из состава Samba4 (/usr/bin/ntlm_auth) при вызове Squid-ом для любой попытки аутентификации пользователей приводил к одной и той же ошибке:
ERROR: NTLM Authentication validating user. Error returned 'BH NT_STATUS_UNSUCCESSFUL NT_STATUS_UNSUCCESSFUL'
Идея решения этой проблемы была найдена здесь [Bug 1304953] Re: ntlm_auth reports Broken Helper: BH NT_STATUS_UNSUCCESSFUL NT_STATUS_UNSUCCESSFUL. Как я понял, суть проблемы заключается в том, что Squid версии 3.3.8 при работе с хелпером NTLM аутентификации пытается использовать содержимое каталога /var/run/samba/winbindd_privileged, в то время как в Samba4 его месторасположение изменено на /var/lib/samba/winbindd_privileged. Оказалось, что в системе присутствуют оба каталога:
sudo ls -la /var/run/samba/winbindd_privileged total 0 drwxr-x--- 2 root winbindd_priv 40 Jun 6 18:38 . drwxr-xr-x 7 root root 460 Jun 6 18:38 ..
sudo ls -la /var/lib/samba/winbindd_privileged total 8 drwxr-x--- 2 root root 4096 Jun 6 18:38 . drwxr-xr-x 6 root root 4096 Jun 6 18:38 .. srwxrwxrwx 1 root root 0 Jun 6 18:38 pipe
Для решения проблемы неработающей NTLM аутентификации в Squid пришлось настроить разрешения на каталог /var/lib/samba/winbindd_privileged аналогично тому, как они настроены для каталога /var/run/samba/winbindd_privileged…
sudo chgrp winbindd_priv /var/lib/samba/winbindd_privileged sudo ls -la /var/lib/samba/winbindd_privileged total 8 drwxr-x--- 2 root winbindd_priv 4096 Jun 6 18:38 . drwxr-xr-x 6 root root 4096 Jun 6 18:38 .. srwxrwxrwx 1 root root 0 Jun 6 18:38 pipe
…а также слинковать подкаталог ../pipe из старого месторасположения в новое…
sudo ln -s /var/lib/samba/winbindd_privileged/pipe /var/run/samba/winbindd_privileged/pipe sudo ls -la /var/run/samba/winbindd_privileged total 0 drwxr-x--- 2 root winbindd_priv 60 Jun 6 18:41 . drwxr-xr-x 7 root root 460 Jun 6 18:38 .. lrwxrwxrwx 1 root root 39 Jun 6 18:41 pipe -> /var/lib/samba/winbindd_privileged/pipe
После этих изменений можно перезапустить Squid3 и Samba4 (или систему целиком).
***
Теперь относительно того, что для учетной записи компьютера (не путать с сервисной учетной записью пользователя для поддержки Kerberos) нашего Linux-сервера в домене AD рекомендуется выполнять периодическую смену пароля. Судя по документу Samba manpages — smb.conf.5 параметр machine password timeout отвечает за то, насколько часто процесс smbd будет пытаться выполнить смену пароля учетной записи компьютера в домене. По умолчанию это значение равно 604800 секунд, то есть 7 дней. Таким образом добавлять в планировщик заданий CRON отдельную задачу смены пароля командой “net rpc changetrustpw” мы не станем.
***
На этом минимальную настройку поддержки Kerberos и NTLM в Ubuntu Server 14.04 LTS для использования механизмов аутентификации пользователей домена Active Directory в Squid 3 будем считать законченной.
Настройка SQUID
Проделаем ряд подготовительных манипуляций по созданию доменных групп безопасности, которые будут использоваться для ограничения доступа к Интернет, а также созданию вспомогательных файлов, ссылки на которые будут включены в основной конфигурационный файл Squid 3.3.8. Затем отредактируем основной конфигурационный файл Squid и проверим работу нашего прокси-сервера с новыми настройками.
Создаём доменные группы доступа
Ранее по условиям нашей задачи было определено, что для разграничения доступа пользователей к Интернет мы будем использовать группы безопасности в домене Active Directory (AD). Создадим несколько таких групп:
- smbsrv01-Internet-Blocked — Пользователи которым запрещён любой доступ в Интернет. Проверка членства в этой группе в Squid будет осуществляться в первую очередь. Поэтому, даже если получиться так, что пользователь по ошибке включён в какие-то другие группы доступа, в доступе к Интернет ему всё равно будет отказано.
- smbsrv01-Internet-WhiteList — Пользователи Интернет с доступом к ограниченному списку сайтов. В большинстве случаев есть ряд пользователей, которым для выполнения служебных обязанностей требуется доступ к определённым Интернет-ресурсам, а к любым другим внешним ресурсам доступ нужно ограничить.
- smbsrv01-Internet-BlackList — Пользователи Интернет с доступом к любым сайтам за исключением списка блокированных сайтов (настройка такого списка будет выполнена в отдельном файле). В эту группу входит основная масса пользователей.
- smbsrv01-Internet-FullAccess — Пользователи Интернет с доступом ко всем сайтам без исключений. В такую группу может входить например руководство организации, которое хочет ограничить доступ к некоторым Интернет-ресурсам своим сотрудникам, а само при этом желает иметь полный доступ без ограничений.
- smbsrv01-Internet-FullAnonym — Пользователи Интернет с доступом ко всем сайтам без исключений. Отличие этой группы от предыдущей заключается в том, что доступ в Интернет для членов этой группы не будет записываться в лог и поэтому не будет фигурировать в отчетности использования ресурсов Интернет. То есть данная группа предназначена для возможных сценариев требования анонимности некоторых пользователей.
Как видим, группы перечислены в порядке расширения прав доступа. И именно в таком порядке мы будем обрабатывать эти группы в конфигурационном файле Squid.
smbsrv01-Internet-All – Это ещё одна служебная группа, которую мы создадим. Она будет включать в себя все вышеперечисленные группы. Эта группа потребуется нам в дальнейшем для настройки отчетности использования ресурсов Интернет.
Наполним созданные группы доменными пользователями. Помимо прямого членства пользователей в эти группы можно включать другие доменные группы доступа, так как членство в группах будет проверяться с учетом возможной вложенности.
Настраиваем вспомогательные файлы параметров
Настраиваемая нами в Squid система аутентификации пользователей будет иметь три типа: Negotiate, NTLM, Basic. Первый тип будет представлять собой согласование с клиентом, где Kerberos будет использоваться как приоритетный протокол аутентификации а NTLM как альтернативный. Второй тип будет аутентифицировать клиентов, которые имеют явное желание использовать протокол NTLM. Третий тип рассматривается как исключительный (в силу его небезопасности) и нужен лишь для поддержки приложений, которые умеют работать только с Basic аутентификацией. Минимальные подготовительные процедуры для обеспечения функциональности Kerberos и NTLM мы уже проделали. Если же говорить о Basic аутентификации, то здесь нам потребуется дополнительно создать в домене отдельную учетную запись пользователя, от имени которого будет выполняться подключение к AD, как к LDAP-каталогу для выполнения Basic-аутентификации а также авторизации (проверке членства в доменных группах). Лучше всего, чтобы это была отдельная учетная запись пользователя с минимальным набором прав в домене, однако в нашем примере для упрощения будет использоваться та же учетная запись, которая ранее нами была создана для поддержки Kerberos-аутентификации (smbsrv01-SQUIDkrb).
Создадим отдельный файл ldappass.conf в котором будет храниться пароль этой учетной записи для дальнейшего использования на него ссылок из конфигурационного файла Squid.
sudo sh -c "echo 'PasSw0rd' > /etc/squid3/ldappass.conf" sudo chmod o-r /etc/squid3/ldappass.conf sudo chgrp proxy /etc/squid3/ldappass.conf ls -la /etc/squid3/ldappass.conf -rw-r----- 1 root proxy 17 Jun 5 19:19 /etc/squid3/ldappass.conf
***
Далее создадим дополнительные конфигурационные файлы в которых будут записаны ранее созданные нами доменные группы безопасности. Разумеется этого можно и не делать и напрямую в дальнейшем включить названия групп в основной конфигурационный файл Squid, однако подход с модульностью параметров (когда данные параметров подключаются из дополнительных внешних файлов) в некоторых случаях может быть удобен и полезен.
sudo sh -c "echo 'smbsrv01-Internet-Blocked' > /etc/squid3/grps_blocked.conf" sudo sh -c "echo 'smbsrv01-Internet-WhiteList' > /etc/squid3/grps_whitelist.conf" sudo sh -c "echo 'smbsrv01-Internet-BlackList' > /etc/squid3/grps_blacklist.conf" sudo sh -c "echo 'smbsrv01-Internet-FullAccess' > /etc/squid3/grps_fullaccess.conf" sudo sh -c "echo 'smbsrv01-Internet-FullAnonym' > /etc/squid3/grps_fullanonym.conf"
***
Создаём дополнительные конфигурационные файлы для хранения разных списков сайтов (доменов).
sudo touch /etc/squid3/dom_whitelist.conf sudo touch /etc/squid3/dom_blacklist.conf sudo touch /etc/squid3/dom_allaccess.conf
Файл dom_allaccess.conf будет содержать перечень сайтов к которым нужно предоставить всем без исключения пользователям организации без аутентификации и авторизации на прокси. То есть доступ к этим Интернет-сайтам будет разрешён для пользователей, даже если они не включены ни в одну из доменных групп доступа. К таким сайтам может относиться например внешний Интернет-сайт организации. Или например есть на компьютерах пользователей такое приложение как Microsoft Office 2013, которое может вести себя неадекватно при использовании требующего аутентификацию прокси-сервера отличного от Microsoft ISA/TMG. В частности при открытии приложений типа Word 2013 или Excel 2013 пользователь может получать многократные запросы авторизации, так как эти приложения пытаются получить доступ к внешним веб-узлам Microsoft, при этом сами эти приложения ни в какую не хотят представлять прокси серверу данные для аутентификации пользователя (проверено на дампе сетевого трафика). Поэтому для того, чтобы не ущемлять функциональность Microsoft Office, было решено включить используемые им URL в файл dom_allaccess.conf. Пример такого файла:
### How to add domains to this file
#
# 1. Use only the domain name EXCLUDING the protocol prefix, i.e.
# don't put "http://" at the start.
#
# 2. Do not append a directory to the domain name, i.e. don't put
# /index.php/path/blah.html at the end of the name.
#
# 3. Prefix each entry with a single dot ".", this ensures a match of
# example.com and www.example.com.
#
# 4. If you need to match different top level domains like .com,
# .net, .com.au for sites that have multiple top level domains to
# the same website then add a seperate entry for each e.g.
# .example.com
# .example.com.au
#
###
#
# Corp.sites
#
.organization.ru
#
# Learning sites
#
.cdo.academlp.ru
.tests24.ru
#
# Microsoft Office sites
#
.officeimg.vo.msecnd.net
.office.microsoft.com
.office15client.microsoft.com
.officeapps.live.com
Файл dom_whitelist.conf будет содержать перечень сайтов, к которым нужно предоставить доступ ограниченной категории пользователей, прошедшим аутентификацию и авторизацию на прокси. Пользователи которым разрешается доступ только к этому списку сайтов должны быть включены в доменную группу доступа smbsrv01-Internet-WhiteList. Ко всем другим сайтам Интернет доступ для данной категории пользователей будет запрещён. Примером из жизни могут стать пользователи которым нужно дать доступ к определённым Интернет-сайтам компаний партнёров по бизнесу, а к Интернету в целом доступ должен быть заблокирован. Или учащиеся СОШ, которым законом запрещено посещение сайтов не образовательного характера (в рамках учебного процесса). Пример такого файла (без закомментированных строк в шапке файла по аналогии с предыдущим примером):
.app1.partner1.ru .arm.sub.partner2.ru
Файл dom_blacklist.conf будет содержать перечень сайтов, доступ к которым необходимо запретить всем пользователям Интернет (не относиться к пользователям включённым в группы smbsrv01-Internet-Full*). Примером таких сайтов могут быть сайты, содержимое которых по мнению руководства может отрицательно влиять на трудовую дисциплину сотрудников организации, типа социальных сетей, развлекательных сайтов и т.п.. Другим кандидатом в попадание в такой список могут стать сайты, доступ к которым необходимо ограничить согласно писем Роскомнадзора. Пример такого файла:
.fourthreich.com .nssukr.com
***
В дополнение к фильтру по доменным именам добавим фильтрацию по URL (в Squid3 за это отвечает отдельный механизм, поэтому и настройки будут отдельными). Добавим "черный" и "белый" списки URL:
sudo touch /etc/squid3/url_blacklist.conf sudo touch /etc/squid3/url_whitelist.conf
Содержимое этих файлов отличается по форме от файлов доменного фильтра. В "черный список логично добавить "запретные" URL, примерно так:
### How to add urls to this file
#
# 1. Из файла Squid читает регулярные выражения для фильтра URL построчно.
#
# 2. Начало строки (начало URL) обозначается символом ^.
#
# 3. Конец строки (конец URL) обозначается символом $.
#
# 4. Строка должна включать полный URL с кодом протокола (например http://) и конечным слэшем (если требуется).
#
# 5. Если требуется указать только вхождение подстроки в больший URL -
# используйте символ ^ (в начале строки) - для указания вхождения подстроки от начала URL;
# используйте символ $ (в конце строки) - для указания вхождения подстроки в конце URL;
# не используйте ограничивающие символы для указания вхождения подстроки в середине URL;
# дополнительные сведения смотрите в справке по SQUID и регулярным выражениям POSIX.
#
# Примеры:
# ^http://example.com$
# ^http://www.example.com.au/$
#
###
#
# Extremism
#
^http://0chan.hk/h/$
^http://0chan.hk/h/res/214.html$
^http://2013star.org/component/k2/itemlist/tag/%d0%98%d0%b6%d0%b5%d0%b2%d1%81%d0%ba.html$
А в "белый" список добавим разрешенные всем пользователям адреса:
###
#
# Educational
#
^http://www.n-t.org/nl/$
^http://sites.google.com/site/obsestvo02/$
^http://www.un.org/russian/$
***
Отдельно обозначим создание двух дополнительных конфигурационных файлов для обеспечения доступа определённых компьютеров сети к определённым сайтам со службой Windows Update
sudo touch /etc/squid3/dom_wsus.conf sudo touch /etc/squid3/computers_wsus.conf
Создание таких файлов может понадобиться тем, кто использует сервер System Center 2012 R2 Configuration Manager (SCCM) занимающийся автоматической загрузкой обновлений из Интернет-службы Microsoft Windows Update который не умеет аутентифицироваться на прокси и поэтому ему нужно организовать прямой доступ к соответствующим веб-ресурсам.
Файл dom_wsus.conf будет содержать список сайтов Microsoft к которым соответствующим компьютерам локальной сети нужно организовать прямой доступ. Пример такого файла:
# .download.windowsupdate.com #
Файл computers_wsus.conf соответственно будет содержать список IP-адресов серверов SCCM. Пример такого файла:
# # wsus.domain.lan 192.168.0.100 #
Настаиваем основной конфигурационный файл squid.conf
Перед тем как начать редактирование основного конфигурационного файла /etc/squid3/squid.conf хорошим тоном будет создать его резервную копию, чтобы на всякий случай иметь под рукой возможность восстановления конфигурации по умолчанию, после чего можно со спокойной душой открыть исходный файл на редактирование:
sudo cp /etc/squid3/squid.conf /etc/squid3/squid.conf.default
Открываем squid.conf на редактирование (в вашем любимом редакторе).
Далее мы рассмотрим пример конфигурационного файла, разбив его содержимое на основные логические секции и предварительно в трёх словах описав ту или иную часть настроек.
Аутентификация и авторизация пользователей в Squid выполняется вспомогательными программами, так называемыми хелперами. В первой части конфигурации выполняется описание вызовов этих хелперов с передачей им необходимых параметров и в порядке их приоритетности. Как ранее уже было отмечено, в нашем примере будет использоваться три схемы аутентификации. Сначала идёт описание приоритетного метода аутентификации – Согласование выбора Kerberos или NTLM. Затем если клиент по какой-то причине не может использовать аутентификацию Kerberos и при этом готов работать с NTLM – выполняется обработка настроек NTLM. Ну и в последнюю очередь описывается работа метода Basic.
Для процедур согласования будет использоваться специальный хелпер negotiate_wrapper_auth доступный в составе Squid3. Он отвечает за вызов аутентификации Kerberos с помощью хелпера negotiate_kerberos_auth (из состава Squid) либо аутентификации NTLM c помощью хелпера ntlm_auth (из состава Samba). При этом в качестве важных параметров Kerberos-хелпера указывается SPN служебной учетной записи, для которой ранее мы генерировали keytab-файл.
Для процедуры Basic-аутентификации будет использоваться хелпер basic_ldap_auth из состава Squid3.
Возможные значения параметров auth_param для разных методов аутентификации довольно подробно расписаны в комментариях конфигурационного файла squid.conf. Возможные значения ключей хелперов расположенных по умолчанию в каталоге /usr/lib/squid3/, как правило, можно узнать при самостоятельном вызове этих хелперов к ключами –h или –-help.
# SQUID 3.3.8 Configuration # ----------------------------------------------------------------------------- # # OPTIONS FOR AUTHENTICATION # ----------------------------------------------------------------------------- # # Negotiate Kerberos and NTLM authentication
auth_param negotiate program /usr/lib/squid3/negotiate_wrapper_auth --kerberos /usr/lib/squid3/negotiate_kerberos_auth -r -s "HTTP/smbsrv01.domain.lan@DOMAIN.LAN" --ntlm /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --domain=DOMAIN
auth_param negotiate children 200 startup=50 idle=10
auth_param negotiate keep_alive off
# Only NTLM authentication
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --domain=DOMAIN
auth_param ntlm children 100 startup=20 idle=5
auth_param ntlm keep_alive off
# Basic authentication via ldap for clients not authenticated via kerberos/ntlm
auth_param basic program /usr/lib/squid3/basic_ldap_auth -v 3 -P -R -b "dc=domain,dc=lan" -D "smbsrv01-SQUIDkrb@domain.lan" -W /etc/squid3/ldappass.conf -f "sAMAccountName=%s" -h dc.domain.lan
auth_param basic children 20
auth_param basic realm "smbsrv01 SQUID Proxy Server Basic authentication!"
auth_param basic credentialsttl 2 hours
Далее идёт секция описания списков контроля доступа (ACL). Сначала опишем основной ACL внешнего типа, который будет вызывать хелпер LDAP-авторизации ext_ldap_group_acl (из состава Squid3), который в свою очередь фактически будет выполнять проверку членства уже аутентифицированного на прокси пользователя в доменных группах безопасности, чтобы понять какой этому пользователю в дальнейшем нужно предоставить доступ. Обратите внимание на то, что в LDAP-фильтре используемом для поиска к атрибуту memberOf добавлен ключ :1.2.840.113556.1.4.1941:, который объясняет LDAP-серверу (контроллеру домена AD), что поиск членства в группах нужно выполнять с учётом вложенности групп. Обратите внимание, что я создавал группы доступа в контейнере Users в корне дерева LDAP домена, что и указано в строке поиска как параметр CN=Users .
# ACCESS CONTROLS # ----------------------------------------------------------------------------- # # LDAP authorization external_acl_type memberof ttl=3600 ipv4 %LOGIN /usr/lib/squid3/ext_ldap_group_acl -v 3 -P -R -K -S -b "dc=domain,dc=lan" -D "smbsrv01-SQUIDkrb@domain.lan" -W /etc/squid3/ldappass.conf -f "(&(objectclass=person)(sAMAccountName=%v)(memberOf:1.2.840.113556.1.4.1941:=cn=%g,CN=Users,DC=domain,DC=lan))" -h dc.domain.lan
Далее идёт секция описания всех основных ACL, которые по сути являются переменными содержащими некие значения, которыми в дальнейшем будут оперировать правила доступа.
Сначала идет объявление сетей которые смогут работать через наш шлюз (переменная localnet будет использована (где это возможно) для ограничения доступа по принадлежности к сегменту сети. Однако если в вашей локальной сети единственный сегмент и нужно дать работать только из него, то оптимальнее будет просто запускать демон Squid только на интерфейсе в эту сеть и не делать дополнительных обработок.
Следующий ACL нужен для объявления в дальнейшем в некоторых правилах обязательного требования аутентификации пользователя.
Следующие пять ACL нужны для вызова описанного ранее внешнего ACL для проверки членства в той или иной доменной группе описанной в подключаемых файлах.
Следующие три ACL описывают разные списки сайтов из соответствующих подключаемых файлов. Следующие два списка нужны чтобы задействовать дополнительную фильтрацию по URL. И еще два ACL потребуются нам в дальнейшем для описания правил для Windows Update.
Затем идёт ряд ALC используемых в конфигурации по умолчанию. ACL описывающие разрешённые для проксирования порты вполне можно принять в предлагаемом по умолчанию составе.
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl auth proxy_auth REQUIRED
acl BlockedUsers external memberof -i "/etc/squid3/grps_blocked.conf"
acl WhiteListUsers external memberof -i "/etc/squid3/grps_whitelist.conf"
acl BlackListUsers external memberof -i "/etc/squid3/grps_blacklist.conf"
acl FullAccessUsers external memberof -i "/etc/squid3/grps_fullaccess.conf"
acl AnonymousAccessUsers external memberof -i "/etc/squid3/grps_fullanonym.conf"
acl WhiteList dstdomain -i "/etc/squid3/dom_whitelist.conf"
acl BlackList dstdomain -i "/etc/squid3/dom_blacklist.conf"
acl AllAccess dstdomain -i "/etc/squid3/dom_allaccess.conf"
acl WhiteListURL url_regex -i "/etc/squid3/url_whitelist.conf"
acl BlackListURL url_regex -i "/etc/squid3/url_blacklist.conf"
acl WUServers src "/etc/squid3/computers_wsus.conf"
acl WUSites dstdomain -i "/etc/squid3/dom_wsus.conf"
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
Далее идёт одна из самых важных секций, описывающая сами правила доступа к ресурсам Интернет. Сначала идёт ряд правил из конфигурации по умолчанию, затем идут правила использующие описанные нами ранее ACL. Очередность расположения правил играет важную роль и поэтому правила расположены в такой последовательности, которая позволит задействовать все созданные нами ACL в соответствии с их предназначением. Самым последним правилом запрещается любой доступ в Интернет, то есть действует принцип, при котором всё, что явно не разрешено ранее идущими правилами – запрещено.
# Deny requests to certain unsafe ports
http_access deny !Safe_ports
# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports
# Only allow cachemgr access from localhost, localnet
http_access allow localhost manager
http_access allow localnet manager
http_access deny manager
# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
http_access deny to_localhost
# Allow direct access to Windows Update
http_access allow WUSites WUServers
# Allow unrestricted access to allaccessed sites
http_access allow AllAccess
# Enforce authentication, order of rules is important for authorization levels
http_access deny !auth
# Prevent access to basic auth prompt for BlockedAccess users
http_access deny BlockedUsers all
http_access allow WhiteList
http_access allow WhiteListURL
http_access deny WhiteListUsers all
http_access allow AnonymousAccessUsers all
http_access allow FullAccessUsers all
http_access deny BlackList
http_access deny BlackListURL
http_access allow BlackListUsers all
# And finally deny all other access to this proxy
http_access deny all
Далее идёт не менее важная секция описывающая то, на каких сетевых интерфейсах Squid будет принимать подключения. Ограничим возможность подключения рамками локальной сети, чтобы наш прокси сервер не отвечал на запросы из Интернет (именно эта секция имелась ввиду, когда шел разговор о списке localnet).
# NETWORK OPTIONS # ----------------------------------------------------------------------------- # http_port 192.168.0.10:3128
Увеличение значения параметра forward_max_tries может оказаться полезно в ситуациях, когда на запрос прокси на разрешение имени какого-либо Интернет-ресурса возвращено большое количество внешних IP адресов, часть из которых не отвечает на запросы.
# OPTIONS WHICH AFFECT THE NEIGHBOR SELECTION ALGORITHM # ----------------------------------------------------------------------------- # hierarchy_stoplist cgi-bin ? forward_max_tries 25 #
Далее идут параметры кэширования веб-контента. Кэш Squid делится на оперативный кэш в ОЗУ и дисковый кэш. Если нужна высокая скорость работы кэша при большом количестве ОЗУ на сервере, то можно отказаться от использования дискового кэша вообще. Если же объём ОЗУ не велик, то при необходимости можно значительно увеличить общий объем кэша перенеся его бОльшую массу да диск. В нашем случае именно так и сделано, то есть используется гибридная конфигурация кэширования с 4GB кэша в ОЗУ и 7GB кэша в указанной директории (у меня она расположена в ветке /var которая смонтирована отдельным быстрым разделом файловой системы).
# MEMORY CACHE OPTIONS # ----------------------------------------------------------------------------- # cache_mem 4096 MB maximum_object_size_in_memory 4048 KB memory_replacement_policy heap GDSF # DISK CACHE OPTIONS # --------------------------------------------------------------------------- # cache_replacement_policy heap LFUDA cache_dir ufs /var/spool/squid3 7000 16 256 maximum_object_size 32768 KB
Далее идут параметры логирования (напомню, что пользователи из ACL AnonymousAccess не логируются) и траблшутинга. Затем идёт конфигурация по умолчанию для тюнинга кэширования и ряд других параметров. Отдельное внимание стоит обратить на то, что весьма желательно с помощью параметра cachemgr_passwd ограничить паролем доступ к менеджеру кэша Squid, который доступен через URL http://smbsrv01.domain.lan:3128/squid-internal-mgr/menu из локальной сети согласно настроенного нами ранее правила “http_access allow localnet manager”. Если этого не сделать то все желающие из локальной сети как минимум смогут получить доступ к информации о паролях пользователей используемых в схемах Basic-аутентификации.
# LOGFILE OPTIONS # ----------------------------------------------------------------------------- # # don't log AnonymousAccess access_log daemon:/var/log/squid3/access.log squid !AnonymousAccess # OPTIONS FOR TROUBLESHOOTING # ----------------------------------------------------------------------------- # cache_log /var/log/squid3/cache.log coredump_dir /var/spool/squid3
# Этот параметр следует использовать только для отладки - очень большой объем логов
#debug_options ALL,1 33,5 28,5 29,5
# OPTIONS FOR TUNING THE CACHE # ----------------------------------------------------------------------------- # refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880 refresh_pattern . 0 20% 4320 # ADMINISTRATIVE PARAMETERS # ----------------------------------------------------------------------------- #
# Email of cache admin
cache_mgr admin@domain.lan httpd_suppress_version_string on visible_hostname KREVEDKO-01 # ERROR PAGE OPTIONS # ----------------------------------------------------------------------------- # error_directory /usr/share/squid3/errors/ru error_default_language ru # DNS OPTIONS # ----------------------------------------------------------------------------- # dns_v4_first on # MISCELLANEOUS # ----------------------------------------------------------------------------- # forwarded_for delete cachemgr_passwd StrOnG_PaZsZw0rD all
Разумеется приведённый пример конфигурационного файла squid.conf не отражает всего множества доступных параметров, позволяющих гибко тюнинговать функции Squid, а лишь является примером рабочей базовой конфигурации.
После того как мы закончили с редактированием конфигурационного файла, выполним его проверку на наличие синтаксических ошибок:
sudo squid3 -k parse
Если парсер не обнаружил никаких явных ошибок, то можем применить новую конфигурацию Squid:
sudo squid3 -k reconfigure
***
После этого можно приступать к проверке настроенных нами правил доступа на клиентских компьютерах локальной сети. Корректность работы схем аутентификации желательно проверить на разных браузерах.
В случае проблем в реальном режиме времени смотрим логи:
sudo tail -f /var/log/squid3/cache.log
sudo tail -f /var/log/squid3/access.log
***
На данном этапе можно считать, что наш прокси-сервер функционирует и способен обслуживать клиентов локальной сети. Далее рассмотрим пример авто-настройки браузеров на клиентских компьютерах сети с помощью механизмов Proxy Auto Configuration (WPAD) на базе веб-сервера Apache2.
Забыли пароль?