«Прозрачный» Squid с фильтрацией HTTPS ресурсов без подмены сертификатов

Просмотров: 1691

Как отследить HTTPS без подмены сертификатов с помощью Squid'а, и как сам Squid для этого приспособить)
Article Image
Не секрет, что в больших конторах тема фильтрации Интернета довольно актуальная. С этой задачей справляется немало программных и аппаратных решений. Но в настоящее время все те сайты, которые мы резали ранее, работают по протоколу HTTPS, т.е. порт 443. Как известно, данный протокол проследить, прослушать и т. п., невозможно. А любой кеширующий фильтрующий прокси-сервер, редиректор и т. п. фильтрует только HTTP, т.е. порт 80. Как же резать Вконтакте, Одноклассники, iphide.info и многие другие подобные сайты? Как блокировать доступ к личной почте в организации, если использование оной запрещено порядками в организации? Да, можно фильтровать по IP адресам, но они частенько меняются, да и на многих ресурсах несколько IP адресов. Блокировать их на уровне файрвола как-то совсем не православное решение, и не совсем удобное.

И вот, совсем недавно, мне один товарищ рассказал, что он поднимает у себя в конторе кеширующий прокси с фильтрацией HTTPS, меня это заинтересовало. А поднимал он Squid 3.5.8. Как выяснилось, в нем переработана организация перехвата шифрованных HTTPS-сеансов (ssl_bump), вместо режимов перехвата («modes») введены в обиход действия («actions»), которые в том числе можно использовать в ACL. Режим «server-first», при котором вначале осуществляется соединение с целевым сервером, а потом создаётся защищённое соединение между клиентом и прокси, теперь доступен как действие «bump». Режим «none», при котором создаётся TCP-туннель без дешифровки трафика, теперь доступен как действие «splice».

Для обеспечения обратной совместимости добавлено действие «peek-and-splice», при котором решение о типе создаваемого вначале соединения (клиент-прокси или прокси-сервер) принимается на основе SSL hello-сообщений. Добавлены действия «peek» и «stare» для получения клиентского или серверного сертификата с сохранением возможности дальнейшего применения режимов «splice» и «bump» для соединений. Добавлено действие «terminate» для закрытия соединений к клиенту или серверу. Вот как раз SSL BUMP, PEEK-and-SPLICE и Terminate нам и нужны. Вообще, схема работы на самом деле довольно простая. Squid подключается к HTTPS ресурсу, получает его сертификат, и может «посмотреть» некоторые данные о ресурсе, в частности имя сервера, которое нам как раз и нужно для блокировки! Все мануалы, которые есть в Интернете, то и дело описывают Man in the middle (MITM) атаку с подменой сертификатов, при которой в принципе не работают некоторые сайты и банк-клиенты, да и юзеры явно видят, что за ними следят. Мы же с товарищем совместными усилиями добились сбособа фильтрации и отслеживания HTTPS без подмены сертификатов, без MITM и прочего, и все это в прозрачном режиме без настройки браузеров!

Впоследствии я столкнулся с некоторыми сложностями, в частности Squid начинал сегфолтиться на большой нагрузке. Но проблема была решена. Дело в том, что в Openssl имеются кое какие баги, которые исправлены в библиотеке Libressl. Поэтому необходимо сначала интегрировать в систему Libressl, потом уже после внесения патча в файл bio.cc в исходниках Squid приступать к компиляции последнего. Поехали! Оговорюсь, что у меня используется дистрибутив Debian Jessie x86, и Squid я в итоге собрал версии 3.5.9 (последняя на данный момент версия), и статья рассчитана на более-менее опытного пользователя Linux, так как некоторые моменты опускаются, а говорится лишь самое главное, так как мне лень все разжевывать. Итак, если вам интересно, идем под кат.

Для начала, подготовимся к сборке пакетов:
 
apt-get install git fakeroot build-essential devscripts
apt-cache policy squid3
apt-get build-dep squid3
apt-get build-dep libecap2
apt-get install libssl-dev libgnutls28-dev

Не забудьте перейти в ту папку, где вы будете собирать исходники, чтобы не засрать себе Хоум. Далее скачаем, скомпилируем и установим Libressl:
 
wget http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.1.6.tar.gz
tar -xzvf libressl-2.1.6.tar.gz
cd libressl-2.1.6

Собираем и устанавливаем, после чего перечитаем хеши библиотек:
 
./configure
make
checkinstall --pkgname libressl --pkgversion 2.1.6
dpkg -i libressl_2.1.6-1_i386.deb
ldconfig

Ну и надо настроить использование LibreSSL по-умолчанию:
 
mv /usr/bin/openssl /usr/bin/openssl-1
update-alternatives --install /usr/bin/openssl openssl /usr/bin/openssl-1 10
update-alternatives --install /usr/bin/openssl openssl /usr/local/bin/openssl 50
update-alternatives --config openssl

Проверим, получилось ли поставить Libressl:
 
openssl version
    LibreSSL 2.1.6

Получилось!

После выполнения этих действий, необходимо отредактировать sources.list, включив туда исходники из ветки testing (это необходимо, так как нам нужно компилировать новый libecap, который в свою очередь необходим для сборки Squid):
 
deb-src http://ftp.de.debian.org/debian/ testing main contrib non-free

Обновим кеш пакетов:
 
apt-get update

А теперь скачаем из Testing нужные исходники:
 

apt-get source squid3/testing
apt-get source libecap3/testing

Далее соберем libecap:
 
cd libecap-1.0.1/
dpkg-buildpackage -us -uc -nc -d

Удалим старье, и установим новье:
 
apt-get purge libecap2
dpkg -i libecap3_1.0.1-2_i386.deb
dpkg -i libecap3-dev_1.0.1-2_i386.deb

Качаем последний самый свежий и работающий снэпшот Squid'a:
 
wget http://www.squid-cache.org/Versions/v3/3.5/squid-3.5.8.tar.gz

Обновим полученные ранее исходники Squid'a до новых, и далее будем работать уже в директории с новоиспеченными исходниками:
 
cd squid3-3.5.7/
uupdate -v 3.5.8 ../squid-3.5.8.tar.gz
cd ../squid3-3.5.8/

Чтобы все нужные нам плюшки заработали, надо компилировать Squid с нужными опциями, поэтому внесем в debian/rules следующие опции компиляции:
 
--enable-ssl
--enable-ssl-crtd
--with-openssl

Скачаем патч для bio.cc, который нужен для корректной работы с Libressl, отсюда bugs.squid-cache.org/attachment.cgi?id=3216 и применим его
 
patch -p0 -i bug-4330-put_cipher_by_char-t1.patch

Теперь можно приступать к компиляции и сборке Squid'а. Но не так быстро! Все скомпилируется без проблем, по крайней мере на х86 архитектуре, но в самом конце, на этапе сборки пакетов deb, вам любезно скажут в консоли: «ай ай ай, не могу понять, какие зависимости нужны для libssl.so.32» (это версия библиотеки из Libressl). Оно и понятно, откуда Debian'у знать о ней. Мы обманем систему, указав опцию «не проверять зависимости», вот так:
 
export DEB_DH_SHLIBDEPS_ARGS_ALL=--dpkg-shlibdeps-params=--ignore-missing-info

А вот теперь приступим к компиляции и сборке:
 
dpkg-buildpackage -us -uc -nc

После сборки установим пакет с языками для Squid'a:
 
apt-get install squid-langpack

Далее установим новоиспеченные пакеты:
 
dpkg -i squid-common_3.5.8-1_all.deb
dpkg -i squid_3.5.8-1_i386.deb
dpkg -i squid3_3.5.8-1_all.deb
dpkg -i squidclient_3.5.8-1_i386.deb

Если система заматерилась на неудовлетворенные зависимости, сделаем:
 
apt-get -f install

Почти готово. Перейдем в каталог /etc/squid, кое-что там изменим. Создадим pem файлик, необходимый для SSL-Bump'инга:
 
openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout squidCA.pem -out squidCA.pem

И приведем squid.conf к следующему виду:
 
acl localnet src 192.168.1.0/24	# 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 CONNECT method CONNECT

dns_nameservers 8.8.8.8
http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localhost manager
http_access deny manager

http_access allow localnet
http_access allow localhost
http_access deny all

#прозрачный порт указывается опцией intercept
http_port 192.168.1.254:3128 intercept options=NO_SSLv3:NO_SSLv2

#также нужно указать непрозрачный порт, ибо если захотите вручную указать адрес
#прокси в браузере, указав прозрачный порт, вы получите ошибку доступа, поэтому нужно
#указывать непрозрачный порт в браузере, если конечно такое желание будет, к тому же в логах 
#сыпятся ошибки о том, что непрохрачный порт не указан=) 
http_port 192.168.1.254:3130 options=NO_SSLv3:NO_SSLv2 

#и наконец, указываем HTTPS порт с нужными опциями
https_port 192.168.1.254: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

#укажем правило со списком блокируемых ресурсов (в файле домены вида .domain.com)
acl blocked ssl::server_name  "/etc/squid/blocked_https.txt"
acl step1 at_step SslBump1
ssl_bump peek step1

#терминируем соединение, если клиент заходит на запрещенный ресурс
ssl_bump terminate blocked 
ssl_bump splice all

sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB

coredump_dir /var/spool/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
cache_dir aufs /var/spool/squid 20000 49 256
maximum_object_size 61440 KB
minimum_object_size 3 KB

cache_swap_low 90
cache_swap_high 95
maximum_object_size_in_memory 512 KB
memory_replacement_policy lru
logfile_rotate 4

 
Немного расскажу про конфиг. Документация по ssl_bump, peek-n-splice довольно обширная, но для нашей задачи необходимо знать следующее. Есть несколько этапов «handshaking» (т.е. рукопожатие, взаимодействие с сервером). Описаны они в оф.документации. Нас интересует пример Peek at SNI and Bump. То есть, как следует из названия, мы смотрим SNI-информацию и бампим соединение. Перед этим, мы указываем опцией DONT_VERIFY_PEER, что необходимо принимать сертификаты даже, если они не прошли проверку и опцией sslproxy_cert_error указываем, что нужно отключить проверку сертификатов на сервере. Указанное правило «acl step1 at_step SslBump1» — это есть первый из трех возможных шагов ssl_bump'а. При выполнении этого шага мы получаем только SNI, и ничего более. Нам этого достаточно. Дальше мы используем этот ACL строкой ssl_bump peek step1, то есть непосредственно смотрим SNI, а уже после этого блокируем соединение, если в SNI найден server_name из списка blocked.


Далее завернем файрволом нужные порты на Squid:
 
iptables -t nat -A PREROUTING -p tcp -m tcp -s 192.168.1.0/24 --dport 443 -j REDIRECT --to-ports 3129
iptables -t nat -A PREROUTING -p tcp -m tcp -s 192.168.1.0/24 --dport 80 -j REDIRECT --to-ports 3128

Все готово! Можно торжественно запускать Squid:
 
systemctl start squid

Посмотрим, все ли со Squid'ом нормально:
 
systemctl status squid
● squid.service - LSB: Squid HTTP Proxy version 3.x
   Loaded: loaded (/etc/init.d/squid)
   Active: active (running) since Сб 2015-09-26 21:09:44 YEKT; 2h 6min ago
  Process: 1798 ExecStop=/etc/init.d/squid stop (code=exited, status=0/SUCCESS)
  Process: 1818 ExecStart=/etc/init.d/squid start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/squid.service
           ├─1850 /usr/sbin/squid -YC -f /etc/squid/squid.conf
           ├─1852 (squid-1) -YC -f /etc/squid/squid.conf
           ├─1853 (logfile-daemon) /var/log/squid/access.log
           └─1854 (pinger)

сен 26 21:09:44 squid squid[1850]: Squid Parent: will start 1 kids
сен 26 21:09:44 squid squid[1850]: Squid Parent: (squid-1) process 1852 started
сен 26 21:09:44 squid squid[1818]: Starting Squid HTTP Proxy: squid.


Если ошибок нет, можно работать. К сожалению, при блокировке HTTPS ресурсов, не появляется сообщение Squid'a «Доступ запрещен», а вместо этого браузер выдает ошибку о невозможности создания соединения. Если кто-то подскажет, как это сделать, буду очень рад.

UPD: в версии Кальмара, которую компилировал я изначально, т.е. 3.5.9, найден досадный баг (или фича), из-за которого спустя время перестают открываться некоторые HTTPS сайты. Решение: компилировать версию 3.5.8.

UPD2: создал очередной багрепорт по проблеме в 3.5.9, тему буду обновлять, если что-то прояснится.
UPD3: вышла версия 3.5.10 с исправленными багами, по крайней мере, патч на файл bio.cc там уже применен. Не тестировал пока-что
UPD4: подредактировал статью немного.

UPD5: прямая ссылка для скачивания архива со всеми нужными пакетами (SQUID 3.5.8), пока-что это единственная рабочая версия! Остальные, которые версиями выше, имеют баг, из-за которого Squid перестает работать при прозрачном проксировании HTTPS. ВЕРСИЯ ДЛЯ Х86!!!


ВНИМАНИЕ!!! Во избежание недоразумений, ставьте версию 3.5.8! На ней нет никаких проблем, и если сделано все точно по статье, то все будет работать! Если ставите версию выше, то я не гарантирую правильной работы прозрачной фильтрации!

Очередное Update!!! в src-репозитарии Debian Testing теперь 3.5.10!!! добавляйте в sources.list src-репозитарий squeeze. Там версия 3.1, но ничего страшного, все обновится до версии 3.5.8 как надо, только пути к каталогам измените в соответствии с версией скачанных исходников!

 UPD 02.12.15:  Я прошу прощения, если заставил кого-то костылить. Перезалил архив squid 3.5.8, там не хватало одного deb пакета! squid 3.5.8_all. 

UPD 02.12.15: Внимание! Если у вас проблема с установкой libressl, то нужно сделать так: сначала поставить openssl, а затем уже ставить libressl (если ставите версию из архива с пакетами, то не забывайте сделать замену openssl на libressl, как в статье!). Это решит проблему "невидения" библиотеки libssl.so.32

Хочу сказать спасибо товарищу Дмитрию Рахматуллину, без него бы не получилось сделать то, что написано выше. Также, отдельное спасибо разработчикам Squid'а, которые оперативно ответили на мой баг-репорт об ошибке в libssl. И спасибо ребятам Nadz Goldman и gmax007 с Тостера, которые направили в нужное русло мои идеи по переносу Squid'а на физически отдельный от основного шлюза сервер.
 
Также обсуждение статьи на Хабрахабре
 
И еще раз, ВНИМАНИЕ!!!!!!!! АХТУНГ!!!! 
Если у вас что-то не работает, убедитесь, что используете версию Squid 3.5.8, потому как во всех версиях выше\ниже есть непонятные баги, из-за которых использование ПРОЗРАЧНОГО проксирования HTTPS становится настоящим кошмаром!

Опубликовано 25 Февраля 2016 в категории Squid

comments powered by HyperComments
Поиск по сайту:

Теги:

Популярные статьи:

Новости IT:

^ Наверх