«Прозрачный» Squid с разграничением доступа / Хабр

Как готовить кальмара, думаю что не я один сталкивался с задачей настройки Squid’а для разграничения доступа сотрудникам предприятия, но при этом он должен быть «прозрачным». Другими словами конфигурация показанная далее удовлетворяет трём условиям:

Хотелось бы уточнить по последнему пункту, так как шлюз «прозрачный», то использовать доменную авторизацию пользователей мы не можем, по данной причине выбрано разграничение именно по ip-адресам.

В качестве базовой конфигурации использовались материалы из статьи «Прозрачный» Squid с фильтрацией HTTPS ресурсов без подмены сертификатов (x86). Так как установка и настройка компонентов в данной статье описаны достаточно подробно, я пропущу данную информацию.

Программное обеспечение использованное мной для тестирование конфигурации:

Итак, файл

/etc/squid/squid.conf:

acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

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 Safe_ports port 901         # SWAT

acl CONNECT method CONNECT

#Добавление в acl трёх списков: запрещенные, разрешенные и группа расширенного доступа
acl denied_urls url_regex "/etc/squid/denied_urls"
acl allowed_urls url_regex "/etc/squid/allowed_urls"
acl extended_access_group src "/etc/squid/extended_access_group"

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager

#Ключевая строчка из-за которой долго ломали голову, так как без нее запрос сертификатов к сайтам 
# на https не осуществляется.
#Разрешаем осуществлять коннект к ресурсу, если https
http_access allow localnet CONNECT
#Запрещаем всем доступ на запрещенные сайты
http_access deny denied_urls
#Этим правилом разрешаем всем кто не в группе расширенного доступа ходить только на 
#разрешенные сайты
http_access deny !extended_access_group !allowed_urls

http_access allow localnet
http_access allow localhost
http_access deny all

#Обязательно один из портов должен быть в таком виде и являться заглушкой
http_port 3130
http_port 3128 intercept
https_port 3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squidCA.pem

always_direct allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

#Правила доступа для ssl
acl allowed_urls_ssl ssl::server_name_regex "/etc/squid/allowed_urls"
acl denied_urls_ssl ssl::server_name_regex "/etc/squid/denied_urls"
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump terminate denied_urls_ssl
ssl_bump splice extended_access_group
ssl_bump terminate !allowed_urls_ssl
ssl_bump splice all
sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB

#cache_dir ufs /var/cache/squid 100 16 256

coredump_dir /var/cache/squid

refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|?) 0     0%      0
refresh_pattern .               0       20%     4320

Перед запуском Squid’а не забываем создать три файла в

/etc/squid/

.

denied_urls

и

allowed_urls

вида:

geektimes.ru
habrahabr.ru
toster.ru
windowsupdate.microsoft.com

И

extended_access_group

вида:

192.168.1.5     #Иванов И.И.
192.168.1.87    #Петров П.П.
192.168.1.108   #Сидоров С.С.

При обращении по http на запрещенный сайт выдаст стандартную заглушку Squid’а, а по https — «ERR_SSL_PROTOCOL_ERROR».

Спасибо за прочтение статьи.

Всем привет!

Часто в организациях используем разного рода прокси, прокси как составляющая программного шлюза или самостоятельный классический вариант squid анализатор логов и т.п.

Мы пытались внедрить решение от Ideco и ИКС, в итоге остановились на squid. Под катом история пути и техническая информация по настройке старого доброго кальмара.

Начну пожалуй с того, что конечно странно на habr в 2021 году видеть статью про настройку squid, но тем не менее, даже в нынешние время платные продукты могут уступать по некоторым пунктам open source софту который так или иначе лежат в основе платного продукта с красивым интерфейсом.

Всё началось с того, что руководство дало ясно понять что мы можем позволить себе купить интернет биллинг.

Требования следующие: интеграция в Windows AD, полное управление пользователями из AD, шейпер скорости, фильтрация по типу контента, по спискам сайтов, возможность дать доступ всей сети к локальным ресурсам компании.

В сети компании насчитывается свыше 550 компьютеров. Большинству из них нужен доступ к внутренним ресурсам.

Все разворачивалось в виртуальной среде, сервер виртуализации Hyper-v core — Неверный выбор, о причинах изложу в конце статьи.

Немного о выборе конкурсантов, UserGate помню его из времен начала работы в IT, по старой памяти приложение windows — по умолчанию не подходит.

Интернет Контроль Сервер (ИКС)- дело дошло до тестов. Удалось корректно загрузить из 10 только 2 раза, отмечая его отличную нестабильность пошли дальше. К стати, не могу не отметить юмор разработчиков, кто в курсе тот поймет! Продукт развивается, может быть уже проблем нет, но и задача решена.

Ideco — мне понравилось, отличное решение, но в функционал включен не только интернет биллинг, это полноценный шлюз со всеми плюшками, для нас лишнее. Но тем не менее он прошел полный тест, возникло 2 непреодолимых препятствия:

1. Невозможно дать доступ к определенным ресурсам всей сети или всем пользователям домена — по умолчанию не считая таких пользователей за пользователя которого нужно лицензировать.

1.1 — Из пункта 1 вытекает немалая цена, т.к. у нас в компании довольно много компьютеров которым необходимо подключение к внутренним web сервисам и не нужен доступ в интернет, покупать лицензии для использования внутренних ресурсов мы не планировали, также не планировали разводить зоопарк серверов раздающих интернет.

2. IP адрес компьютера жестко привязывается к имени пользователя который первый прошел аутентификацию на прокси, так при смене сотрудника нужно было в админ. панели удалять привязку в ручном режиме, что конечно не отвечает требованию управлять всем через AD.

Кстати, шлюз ideco доступен в бесплатной версии до 40 пользователей и без привязки к AD. Также появился IDECO SELECTA, или я не заметил его выпуска или он был выпущен уже после всех тестов.

После всех пройденных этапов было решено своими силами сделать все на squid но с поправкой на наши технические требования, что из этого получилось читайте далее.

Начнем с того, что корректных и полных мануалов в сети нет, есть некоторые части, но все инструкции сводились на нет новыми релизами сквида.

Мы используем ubuntu server, следовательно следующая информация актуальна для этой ОС и с другими ОС может серьёзно различаться.

Все в командной строке нужно делать из под sudo, далее дописывать перед каждой командой sudo не буду.

Настройка OS ubuntu server 16.04:

apt-get update
apt-get upgrade
apt-get install mc g   libecap3-dev libdb-dev libldap2-dev libpam0g-dev libldb-dev libsasl2-dev libkrb5-dev gcc libssl-dev krb5-user libpam-krb5 libkrb5-3 libsasl2-modules-gssapi-mit linux-virtual-lts-xenial linux-tools-virtual-lts-xenial linux-cloud-tools-virtual-lts-xenial linux-image-virtual linux-tools-virtual linux-cloud-tools-virtual squid3

Т.к. мы используем Hyper-v виртуализацию то мы установили необходимые пакеты.

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

wget http://www.squid-cache.org/Versions/v3/3.5/squid-3.5.26.tar.gz

Распаковываем в home или любой другой каталог.

tar xzf squid-3.5.26.tar.gz
cd /home/squid-3.5.26/

chmod  x configure 

Указываем какие пакеты нам нужны, можете ненужное удалить или что-то добавить. Кому-то покажется что тут куча лишнего. Список взять из установленной версии сквида и добавлены дополнительные пакеты.

./configure '--enable-ssl' '--with-openssl=/usr/lib/ssl/' '--disable-ipv6' '--enable-ssl-crtd' '--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' 'BUILDCXXFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--libexecdir=/usr/lib/squid' '--mandir=/usr/share/man' '--enable-inline' '--disable-arch-native' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,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/squid' '--with-logdir=/var/log/squid' '--with-pidfile=/var/run/squid.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-build-info=Ubuntu linux' '--enable-linux-netfilter' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security'

make
make install

–with-openssl=/usr/lib/ssl/ — указываем путь до openssl, указан дефолтный путь в ubuntu server.

–disable-ipv6 — выключаем ipv6 — о причинах читайте ниже.

–enable-ssl-crtd — это для связки генерации ssl сертификатов для bump.

Возможно будут зависимости, нужно их установить.

По умолчанию все устанавливается в /etc/squid/

Создаем папку внутри /etc/squid для ssl сертификатов:

mkdir /etc/squid/ssl/private

Создаем сертификат:

Переходим в каталог

cd mkdir /etc/squid/ssl/private

Создаем ключ

openssl genrsa -aes256 -out private.pem 2048

Создаем сертификат

openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout private.pem -out public.pem

Конвертируем сертификат в понятный для браузера формат

openssl x509 -outform der -in public.pem -out squid3domainlocal.der

Создаем базу сертификатов:

/usr/lib/squid/ssl_crtd -c -s /etc/squid/ssl/ssl_db/

Назначаем доступ:

chown root:proxy -R /etc/squid/ssl
chmod 640 -R /etc/squid/ssl/private
chmod 660 -R /etc/squid/ssl/ssl_db

Обращаю Ваше внимание на то, что имя прокси сервера и имя указанное при создании сертификата должно быть одинаковое. Формат squid3.domain.local.

Полученный squid3domainlocal.der через групповые политики или вручную вносим в доверенные центры сертификации. Прокси сервер в браузере указываем не ip а полное имя компьютера, к примеру squid3.domain.local.

Создаем обычного пользователя в домене, пусть будет squid3.

Для прохождения аутентификации через kerberos нам нужен keytab пользователя squid3 для principal HTTP/squid3.DOMAIN.LOCAL@DOMAIN.LOCAL, при стандартном входе в домен через net ads создается keytab /etc/krb5.keytab, но в нем указаны principal не http а host. Что делает невозможным проходить аутентификацию пользователей через web браузер. Если Вы расположили keytab в /etc/krb5.keytab и после вводите в домен саму машину, то keytab просто будет дополнен новыми principal.Но обращаю Ваше внимание на то, что устанавливать пакет samba и вводить машину в домен не нужно, достаточно сгенерированного keytab для пользователя.

Далее идем на домен контроллер и выполняем нехитрую команду:

ktpass -princ HTTP/squid3.DOMAIN.LOCAL@DOMAIN.LOCAL mapuser squid3@DOMAIN.LOCAL -crypto AES128-SHA1 -pass XXXXXXXXXXXXXX -ptype KRB5_NT_PRINCIPAL -out c:krb5.keytab

Переносим полученный файл на прокси сервер и далее помещаем в удобное расположение, я выбираю /etc/krb5.keytab.

Если Вы хотите сделать авторизацию еще и для web сайта, статистика или внутренний портал компании то нужно создать группу и включить туда пользователей proxy и www-data.

Создаем группу:

groupadd allowreadkeytab

Добавляем необходимых пользователей в группу:

adduser proxy allowreadkeytab
adduser www-data allowreadkeytab

Назначаем владельцев на krb5.keytab

chown root:allowreadkeytab /etc/krb5.keytab

Если нет необходимости дополнительным сервисам давать доступ, то группу не создаем, просто выставляем владельцев и права:

chown root:proxy /etc/krb5.keytab

Назначаем доступ:

chmod 640 /etc/krb5.keytab

Получаем:

-rw-r----- 1 root allowreadkeytab /etc/krb5.keytab

Или

-rw-r----- 1 root proxy /etc/krb5.keytab

Чтение и запись для root, только чтение для allowreadkeytab и без доступа для остальных.

Настраиваем krb5.conf

mcedit /etc/krb5.conf

Сохраняем.

Обращаю Ваше внимание, что ниже squid.conf не будет содержать все acl и все правила, будут лишь по 1 примеру настройки, полная настройка acl и листами доступа к сайтам и т.п. будет слишком объемной. Ниже приведенный конфиг можно рассматривать как требующий доработки под свои нужды.

Переходим к настройке squid:

mcedit /etc/squid/squid.conf


acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 21

acl purge method PURGE
acl CONNECT method CONNECT

http_access allow purge localhost
http_access deny purge
http_access deny CONNECT !SSL_ports

Тут важный момент, есть сайты которые поднимают соединение непосредственно с «компьютером», и аутентификация пользователя не производится. Как следствие происходит блокировка соединения. Для обхода этой проблемы дается доступ конкретному ip к конкретному сайту.

!!! Важное примечание !!! Правило должно быть расположено выше правил с аутентификацией basic, ntlm, kerberos и др.

acl authip src "/etc/squid/pools/ip.txt"
acl domainautip dstdomain "/etc/squid/exceptions/domain.txt"
http_access allow authip domainautip 
http_reply_access allow authip  domainautip

Определяем aclы:

→ Документация

Acl для определения типа контента:

acl application_mime rep_mime_type application/octet-stream
acl video_mime rep_mime_type “/etc/squid/ban/mime_type_video.txt”

Также фильтровать некоторый контент можно по url, для этого создаем acl:

acl blockextention urlpath_regex -i “/etc/squid/ban/blockextention.txt”

Есть еще любопытный acl allowerrorsert, т.к. мы не разрешаем по умолчанию доступ к сайтам с кривыми сертификатами, я использую allowerrorsert для определения перечня разрешенных сайтов с «кривыми» ssl. Об этом не много ниже.

acl banksites dstdomain "/etc/squid/allow/bank.txt"
acl allofficesites dstdomain "/etc/squid/allow/alloffice.txt"

acl manual dstdomain "/etc/squid/ban/manual.txt"
acl allowerrorsert dstdomain "/etc/squid/exceptions/allowerrorsert.txt"

Также есть возможность управлять доступом к сайтам на основе ssl правил, но на мой взгляд эффективнее управлять через http_access. Вот пример acl для использования в правилах ssl:

acl sslproxy ssl::server_name "/etc/squid/ban/proxy.txt"

Ниже мы еще вернемся к этому типу acl и их применению.

Позволяет видеть в расширенном режиме запросы POST и mime.

strip_query_terms off
log_mime_hdrs on

Аутентификация и авторизация пользователя в группе active direcory через kerberos:

auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -s HTTP/squid3.domain.local@DOMAIN.LOCAL
auth_param negotiate children 20 startup=10 idle=10
auth_param negotiate keep_alive on

Тут следует остановиться и разобрать подробнее, children — максимальное количество процессов доступные для запуска, startup количество процессов которые запущены всегда, idle максимальная очередь к помощнику при превышении указанного числа будет запускаться новый процесс помощника.

Небольшое отступление по работе авторизации:

Тут есть особенность, дело в том, что некоторые сайты пытаются подключить вагон разных ресурсов и картинок с других сайтов, собрать кучу статистики и прочее, каждый запрос проходит авторизацию это может вызвать большую очередь к процессу помощника авторизации, можно просто увеличить children, увеличить idle… но это только на первый взгляд, запросов от 1 пользователя может быть несколько десятков тысяч, что за собой несет большую очередь. При появлении большой очереди нагрузка на CPU зашкаливает. В условиях большого количества пк и малой доли пользователей с полноценным доступом в интернет, установленный на пк chrome создавал прям удивительное количество соединений — 500 тыс. запросов на clients1.google.com в сутки. Как следствие были пики очередей.

Подробности решения в конце статьи, где будут описаны некоторые технические моменты решение возникших проблем в процессе отладки.

Поиск пользователя в группе:

external_acl_type domainusers ttl=300 negative_ttl=60 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -T d09fd0bed0bbd18cd0b7d0bed0b2d0b0d182d0b5d0bbd0b820d0b4d0bed0bcd0b5d0bdd0b0 -D DOMAIN.LOCAL

external_acl_type allow-all ttl=300 negative_ttl=60 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g internet-allow-all -D DOMAIN.LOCAL

Две строки выше выполняю 1 функцию, загружают помощника для поиска пользователя в группе, можете сами выполнить в командной строке /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g internet-allow-all -D DOMAIN.LOCAL жмем enter и набираем имя пользователя, если пользователь будет найден в указанной группе, то ответ будет OK если нет то ERR. Обращаю внимание на то, что указанная группа internet-allow-all создана в AD.

Если Вы обратили внимание, то две строки отличаются, в 1 непонятный набор букв и цифр во второй все ясно… В первой строке указана группа «Пользователи домена», не желая разбираться с кириллицей в конфиге сквида и работе хелпера, я решил сделать так, это единственная группа в AD которая связана с этим сервисом имя которой написано кириллицей. Синтаксис тоже изменен, с g что означает группу на T.

Обещал рассказать почему отключил ipv6, это была длинная история, не шла авторизация у пользователя потому что я не указал в строке external_acl_type…….ipv4 т.к. мы не используем ipv6 да и мало кто использует в локальных сетях решено было вообще отключить чтобы избежать подобных проблем. На сёрфинге интернета это тоже никак не отражается.

Группы для ограничения скорости:

external_acl_type disable-speed ttl=300 negative_ttl=60 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g internet-deny-speed -D DOMAIN.LOCAL

external_acl_type allow-speed ttl=300 negative_ttl=60 ipv4 %LOGIN /usr/lib/squid3/ext_kerberos_ldap_group_acl -a -g internet-allow-speed -D DOMAIN.LOCAL

internet-allow-speed — Группа созданная в AD.

Так как группы и пользователей мы получаем из внешнего хелпера, нам нужно определить acl в синтаксисе squid для работы http_access и т.д.

acl domainusers external domainusers
acl allow-all external allow-all
acl allow-speed external allow-speed
acl disable-speed external disable-speed

Далее следуют разрешающие и блокирующие правила. Правила работают как обычно по цепочке, все что cверху имеет большее значение.

http_access allow localhost
http_access deny manual
http_reply_access deny application_mime
http_access allow allow-all
http_reply_access allow allow-all

http_access allow domainusers banksites
http_access deny domainusers

Тут начинается bump, в строке http_port указываем порт и указываем функцию ssl-bump далее включаем генерацию сертификатов, далее размер кеша, далее указываем сам сертификат к слову который добавлен в качестве доверенного центра сертификации на компьютерах домена, далее ключ.

Схема работы следующая, клиент заходит на сайт google.com, клиент устанавливает соеденение ssl с прокси, а прокси в свою очередь с сайтом, прокси поднимает ssl с сайтом и отдельно ssl с клиентом выступая при этом посредником.

эта схема при полном бампе соединения, можно разбирать не полностью, а только для 1 из сторон, я не нашел этому применения, поэтому мы это не используем. К тому же чтобы видеть весь трафик открыто, как http, подходит только эта схема.

http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=16MB  cert=/etc/squid/ssl/private/public.pem key=/etc/squid/ssl/private/private.pem

настройки помощника который генерирует ssl сертификаты для сайтов:

sslcrtd_program /usr/lib/squid/ssl_crtd -s /etc/squid/ssl/ssl_db -M 16MB
sslcrtd_children 20 startup=10 idle=10

visible_hostname = squid3.domain.local

Cоздаем acl с шагами bump, существует всего 3 шага, sslbump1 смотрит на открытую информацию в сертификате, та которая доступна всем.

sslbump2 создает соединение с сайтом sslbump3 создает соединение с клиентом.

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

Указываем acl которые будут внесены в исключения при работе с sslbump

acl sslbanksites ssl::server_name "/etc/squid/exceptions/bank.txt"
acl allowsplice ssl::server_name "/etc/squid/exceptions/allowsplice.txt"

В bank.txt и allowsplice.txt находятся имена доменов.

Это правило разрешает принимать сертификаты с ошибкой, т.e. просроченный, самоподписанный, выданных на другой хост и т.п. Мы создавали acl для этого правила выше.

sslproxy_cert_error allow allowerrorsert

splice — пропустить все последующие действия т.е. не делать bump пропустить как есть.

peek — подсмотреть доступную инфу без полного бампа

terminate — закрыть соединение, не используем, фильтруем через http_access

bump — «влезает» в соединение, делает https видимым как http

ssl_bump splice allowsplice
ssl_bump splice sslbanksites
ssl_bump peek step1 all
ssl_bump bump step2 all 
ssl_bump bump step3 all

Закрываем доступ всем.

http_access deny all
icp_access deny all
htcp_access deny all

Прочие настройки

cache deny all
error_directory /etc/squid/errors/
forwarded_for off

Режем скорость, указываем сколько пулов задержки мы используем:

delay_pools 3

VIP-пользователи, избранные сайты без ограничений по скорости

delay_class 1 1
delay_access 1 allow allow-speed
delay_access 1 allow banksites
delay_parameters 1 -1/-1
delay_access 1 deny all

В нерабочее время — Интернет отключается (до 100КБ/сек.)

delay_class 2 2
delay_access 2 allow !workhours
delay_parameters 2 -1/-1 10000/10000
delay_access 2 deny all

Ограничение на закачку — до 10MB загружают весь канал без ограничений, свыше только 100 КБ/С

delay_class 3 2
delay_access 3 allow disable-speed
delay_parameters 3 -1/-1 32000/10485760
delay_access 3 deny all

В синтаксисе лога изменена буква a на большую A, вот тут: %6tr %>A. Это дает возможность в логах видеть имя компьютера вместо его IP адреса, что конечно удобней.

logformat squid %ts.tu %6tr %>A %Ss/>Hs %<st %rm %ru %[un  %Sh/%<a %mt

Не много о проблемах и об особенностях которые возникали.

Прокси сервер выведен в отдельную dmz, файрволом жестко ограничен доступ в dmz и из нее. Т.к. сквид постоянно опрашивает dns и kerberos по udp преимущественно, то он незамедлительно превышал допустимое количество подключений с 1 ip, на сервер AD который находится в другой dmz, соединения сбрасывались. Проблема была неочевидная, хелпер авторизации падал, клиент получал окно аутентификации.

Ошибка выглядит так:

support_krb5.cc(64): pid=36139 :2021/10/24 08:53:51| kerberos_ldap_group: ERROR: Error while initializing credentials from keytab: Cannot contact any KDC for realm ‘DOMAIN.LOCAL’

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

Была еще 1 ошибка:

support_sasl.cc(276): pid=8872 :2021/10/24 06:26:31| kerberos_ldap_group: ERROR: ldap_sasl_interactive_bind_s error: Local error
support_ldap.cc(957): pid=8872 :2021/10/24 06:26:31| kerberos_ldap_group: ERROR: Error while binding to ldap server with SASL/GSSAPI: Local error

В bind нужно скопировать обратную зону.

UPD — Самое интересное

Возникла проблема с высокой нагрузкой на cpu и io, проц грузил в основном negotiate_kerberos io грузил ext_kerberos_ldap_group_acl, понятное дело что negotiate_kerberos запускал ext_kerberos_ldap_group_acl, нагрузка была не постоянная, два раза в день по 30 минут.

Изменение соотношения количества children и idle нужного результата не дало. В процессе отладки была ясная картина, при любой конфигурации в период пиков запускалось максимальное количество процессов аутентификации. Был проанализирован access.log, как результат анализа было выделено то, что в момент пиковой нагрузки было очень много ssl соединений, это натолкнуло на мысль что проблема кроется не в авторизации а в ssl_bump, для эксперимента был отключен ssl_bump, как результат было полное отсутствие нагрузки на протяжении всего дня. В целом в течении дня работа кальмара и его помощников не вызывала нарекании, но в определенные моменты приходило огромное количество соединений, сухие цифры: от 1 компьютера в единицу времени (5-15 мин) пришло 10000 запросов на ssl соединение которое попадает под правило bump. В другой день тоже самое с другого компьютера на .*whatsapp.net.

В конечном итоге ssl_bump включен, работает без нареканий. Если идет куча запросов на хост который недоступен по таймауту, вот тут возникают пики. На уменьшение очереди в основном повлияло исключение clients1.google.com и clients2.google.com из прокси.

Решать дать доступ к clients1.google.com и clients2.google.com, отключить задание на обновление или исключить эти хосты из прокси решать Вам.

Относительно hyper-v, в целом всё работает стабильно, uptime обычно превышает два месяца, но наступает тот день когда абсолютно на ровном месте без ошибок в логах и какой-либо нагрузки зависают виртуальные машины или выполняется их перезагрузка, но при этом последующая загрузка не приводит загрузке рабочего состояния. Приходится делать сброс и последующая загрузка производится нормально, прошу прощения за тавтологию. При всех равных на указанном сервере крутится две виртуалки ubuntu server 16.04 и у обоих происходит ода и та же проблема с разницей между ними в несколько дней, потом опять uptime не менее 2 месяцев. Для решения этой проблемы переносим сквид в докер, следующую статью оформлю про настройку сквида в докере, в целом мало чем отличается кроме целой кучи зависимостей.

Настройка bind:

 nano /etc/bind/named.conf.options 

Редактируем и вставляем:

zone "domain.local" {
    type slave;
    masters { 192.168.XX.XX; 192.168.XX.XX;};
    file "bak.domain.local";
    forwarders {};
	
	zone  "XX.168.192.in-addr.arpa" {
    type slave;
    masters { 192.168.XX.XX; 192.168.XX.XX;};
    file  "XX.168.192.in-addr.arpa.zone";
};

Анализатор логов:

Squidanalyzer

→ Сайт
→ Инструкции: раз и два

Для его работы нужно установить apache2:

apt-get install apache2

Рассказывать о том, как настаивать его не буду, по ссылкам довольно понятно и доступно. Обращу внимание лишь на одно, пока не будет сгенерирован первый отчет — по web адресу ничего не появится, будет ошибка.

Как только будет сформирован первый отчет, Вы получите заветную страничку с отчетами.
Стоит отметить что страницу с отчетами можно стилизовать под Вашу компанию, сменить логотипы, подписи, фон и т.п. Часть следует менять в основном конфиге:

/etc/squidanalyzer/squidanalyzer.conf

И в скрипте который является шаблоном для /usr/bin/squid-analyzer:

/usr/local/share/perl/5.22.1/SquidAnalyzer.pm

Статья писалась с перерывами, периодически дополнялась и корректировалась, надеюсь она будет полезна.

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

В процессе отладки очень помог awk, команда которая выводит и группирует столбцы:

 cat /var/log/squid/access.log  | awk '{print $номерстолбца}' | cut -d: -f1 | sort | uniq -c | sort -n

Можно добавлять grep.

Для конвертации формата даты и времени в логе кальмара можно использовать:
%tl %6tr %>A %Ss/>Hs %<st %rm %ru %[un %Sh/%<a %mt