Ведущий сисадмин, тыжпогромист
6,4
рейтинг
28 сентября 2015 в 13:32

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

Не секрет, что в больших конторах тема фильтрации Интернета довольно актуальная. С этой задачей справляется немало программных и аппаратных решений. Но в настоящее время все те сайты, которые мы резали ранее, работают по протоколу 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

UPD 10.12.15: Появилась следующая версия статьи, с немного другим подходом к компиляции Кальмара и сборке пакетов. Вот тут

UPD 14.12.15: спешу поделиться с коллегами отличной новостью! Я нашел способ заставить работать новые версии Squid'а без особых танцев с бубном! Необходимо, чтобы у клиентов и в настройках Squid'а были одинаковые DNS! В моем случае, на шлюзе с Кальмаром крутится Bind. Назначил клиентам именно его, и Кальмару директивой:

dns_nameservers 127.0.0.1
. После чего все успешно заработало. Проверено на Squid 4.0.3, собрана БЕЗ Libressl!


UPD 14.12.15: не знаю почему, но в данный момент на Debian 8.2 при сборке Squid'a описанным выше способом выдается сообщение о том, что файл mime.conf не найден. И действительно, ведь в исходниках Кальмара есть mime.conf.default. Я нашел решение. Необходимо отредактировать два файлика:
1) debian/squid-common.install, и привести строку

etc/squid/mime.conf

в такой вид:

etc/squid/mime.conf.default

2) Также необходимо сделать так, чтобы после установки пакета файл переименовался автоматом в «сквидочитаемый вид», т.е. в mime.conf. Для этого отредактируем файл debian/squid-common.postinst, приведя его в такой вид:


#! /bin/sh

set -e

case "$1" in
        configure)
mv /etc/squid/mime.conf.default /etc/squid/mime.conf
...........

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

Хочу сказать спасибо товарищу Дмитрию Рахматуллину, без него бы не получилось сделать то, что написано выше. Также, отдельное спасибо разработчикам Squid'а, которые оперативно ответили на мой баг-репорт об ошибке в libssl. И спасибо ребятам Nadz Goldman и gmax007 с Тостера, которые направили в нужное русло мои идеи по переносу Squid'а на физически отдельный от основного шлюза сервер.
Никита Парфенович @nagibat0r
карма
21,0
рейтинг 6,4
Ведущий сисадмин, тыжпогромист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (130)

  • 0
    А любой кеширующий фильтрующий прокси-сервер, редиректор и т. п. Фильтрует только HTTPS. Как же резать Вконтакте, Одноклассники, iphide.info и многие другие подобные сайты? Как блокировать доступ к личной почте в организации, если использование оной запрещено порядками в организации? Да, можно фильтровать по IP адресам, но они частенько меняются, да и на многих ресурсах несколько IP адресов.

    Как-то не понятно. HTTPS не управляется лишь если мы хотим блокировать по контенту страниц или по параметрам URL. На уровне доменного имени HTTPS вполне себе прекрасно блокируется.

    PS: На 3.5.х полгода назад сильно жаловались по производительности и стабильности. Счас как?
    • 0
      Я с Вами согласен, Вы скорее всего клоните в сторону блокировки по DNS. Но первоочередная задача отслеживать посещение ресурсов, а не просто блокировать. Мне необходимо производить аудит посещаемых сайтов. Работаю я с серверами на Линуксе, а Squid — это единственный пригодный прокси-сервер с нужными мне возможностями.

      З.Ы.: по производительности скажу следующее:
      в конторе over 200 пользователей (одна площадка, планирую подключить еще 3 площадки, добавится еще около 100 клиентов), Squid 3.5.8 прекрасно себя чувствует на 2 ядрах с 2 Гигами
      • 0
        Мне необходимо производить аудит посещаемых сайтов.

        То есть условно сам список сайтов пользователя недостаточен, а нужно знать конкретно какие профили вконтакта он посещал, какие ролики ютуба смотрел и т.д.?
        • 0
          Верно, все идет к этому. Но и просто даже посмотреть список посещаемых HTTPS ресурсов, как его получить, если не бампить SSL соединение? Смотреть сторонними утилитами типа tcpdump — это муторно, а здесь удобные логи с вебмордой для просмотра. Поправьте, если я не прав. У нас браузеры статически не настроены на Proxy. Полностью прозрачный режим.
          • 0
            Но и просто даже посмотреть список посещаемых HTTPS ресурсов, как его получить, если не бампить SSL соединение?

            Сам список посещенных HTTPS-ресурсов вроде бы вполне нормально пишется в access.log сквида без бампа и спайса:

            1444440064.646 90163 192.168.10.70 TCP_MISS/200 4287 CONNECT e.mail.ru:443 DOMAIN\user DIRECT/94.100.180.215 -
            • +1
              при статически настроенном в браузере адресе прокси?
              • 0
                Увы да, про транспарентный не скажу.
                • 0
                  в том и дело! статически настроенный браузер — это не проблема, и в статье не освещается…
                  цель — прозрачный прокси с нужными функциями
                  • 0
                    статически настроенный браузер

                    Можно еще wpad как я сделал и закрыть 443 порт. Хочешь интернет — включай прокси.
                    • 0
                      Firefox у нас везде установлен. Если бы все было так просто, я бы не мучился с компиляцией Кальмара
                      • 0
                        у Firefox есть проблемы? У нас работают. Сделал раздачу по DHCP и DNS и все.
                        • 0
                          когда изначально стоит галка «Не использовать прокси», то да
                          • 0
                            Хочешь интернет — включай прокси.
                            • 0
                              нет нет, идея-то хорошая) но я сомневаюсь, что наши бабули смогут включить прокси, даже если им объяснить, как это сделать.
                              • 0
                                Я делал сайтик с пошаговой инструкцией для разных браузеров. Еще для особых случаев использовал удаленное управление. Таким образом перевел парк в 100-150 пользователей. Заняло неделю. Если был бы AD было бы быстрее конечно.
                      • +1
                        В AD это совершенно не проблема.
                        • 0
                          Firefox изначально настроен на «не использовать прокси», политики AD Firefox не подхватывает.
                          • +4
                            Есть плагин GPO для FF, есть различные способы его распространения, в общем проблема решаема, даже на хабре об этом писали.
                            • 0
                              Статью нашел, прочитал. Если оно работает, это замечательно, надо будет проверить. Но опять же. Тема статьи — прозрачный прокси-сервер)
                            • 0
                              Статью нашел, прочитал. Если оно работает, это замечательно, надо будет проверить. Но опять же. Тема статьи — прозрачный прокси-сервер)
                  • 0
                    То есть суть новшеств в том, что сейчас возможна работа HTTPS в прозрачном режиме прокси, что раньше было невозможно.
                    • 0
                      мало того, что в прозрачном режиме! используется новая технология peek-and-splice, которая позволяет бампить ssl без подмены сертификатов, т.е. без MITM атаки
    • +1
      1000 пользователей — проблем никаких, только при использовании LDAP\Kerberos количество хелперов нужно увеличить.
      • 0
        про хелперы все верно, когда в предыдущей конторе поднимал Кальмара, делал авторизацию, и тоже пришлось кол-во хелперов увеличить
  • 0
    А любой кеширующий фильтрующий прокси-сервер, редиректор и т. п. Фильтрует только HTTPS
    Опечатка?
    • 0
      Спасибо, поправил! Конечно же, HTTP
  • 0
    > К сожалению, при блокировке HTTPS ресурсов, не появляется сообщение Squid'a «Доступ запрещен»
    Вы попадаете вот сюда:
    ssl_bump terminate blocked

    Думаю, можно не делать terminate, а сделать
    http_access deny blocked

    Попробуйте, вдруг поможет.
    • +1
      http_access действует только для HTTP, но никак не для HTTPS, в том то и дело
      • 0
        Проверяли? интересно как реагирует сквид. Ошибка на этапе парсинга конфига или во время работы (запустите squid -N -d 99 -f /path/to/squid.conf и возможно это добавит больше подробностей)
        Некоторое время назад я докапывался до некоторых особенностей работы сквида в т.ч. изучением исходников, и у меня сложилось мнение, что запрос «растуннеливается», а затем идёт по стандартной для HTTP схеме.
        Я могу ошибаться, но есть версия, что если запросы попадающие в ACL «blocked» всё-таки растуннелить (bump), http_access сработает.
        Надеюсь, чем мог, тем помог.
        • +1
          хм, я проверю завтра на работе, спасибо. Хотя судя по документации эта директива работает только для HTTP
        • +1
          И все же, вот кусочек из оф.документации по peek-n-splice:
          " At no point during ssl_bump processing will dstdomain ACL work. That ACL relies on HTTP message details that are not yet decrypted. An ssl::server_name acl type is provided instead that uses CONNECT, SNI, or server certificate Subject name (whichever is available)."
        • +1
          ради интереса все-таки проверил, нет, не работает
          • 0
            Спасибо за эксперимент и ваше время!
            Всё-таки получается, что сквид в такой конфигурации (splice) растуннеливает только до предъявленного сертификата с обоих сторон, а сам обмен как был зашифрован, так и остаётся.
            Если это так, и я правильно понял доку wiki.squid-cache.org/Features/SslPeekAndSplice и то после
            ssl_bump bump blocked
            http_access может и сработать.

            PS мне стало интересно и я это проверил: в настройке, которая без разбора делает «bump на всё» https_access deny сработал(как и ожидалась, произошла подмена сертификата о чем браузер выдал предупреждение).
            • 0
              Всё-таки получается, что сквид в такой конфигурации (splice) растуннеливает только до предъявленного сертификата с обоих сторон, а сам обмен как был зашифрован, так и остаётся.
              Нет там «растуннелирования», как вы выразились. Просто squid парсит client hello и server hello.
            • 0
              Не за что. Нет, Вы не совсем правильно все поняли. Все, что относится к SSl, не работает с правилами http_access. Имя сервера (ну или имя домена, если уж совсем грубо) из SSL можно извлечь только из ssl::server_name, и http_access не работает с этой директивой, на то он и HTTP_access
      • 0
        у меня на данный момент http_access блокирует https сайты или я не правильно вас понял
        • 0
          Режим работы Вашего прокси? И покажите конфиг, очень интересно
        • 0
          Отвечу сам, раз Вы не хотите с нами поделиться) У Вас прокси настроен статически в браузере
  • 0
    Спасибо за ценный мануал! Добавил добра в карму.
    Ещё прошу подсказать чем анализируете логи squid.
    • +1
      Спасибо и Вам! Для анализа логов поставил LightSquid. Показался мне более производительным
      • +1
        Так же использую LightSquid. Еще дописал на php для просмотра индивидуального отчета.

        image
        • 0
          интересно… На Гитхабе случаем нет исходников?)
          • 0
            нет я на коленке собрал. Вам отправлю в личку, кому еще нужно пишите в личку.
            • 0
              благодарю! попробую сегодня
  • 0
    А исходящие VPN-соединения для пользователей у вас зарезаны?
    • 0
      VPN не зарезан, более того, площадки связаны в единую сеть по Openvpn. Блокировать незачем. VPN никто поднять не сможет, так как не смогут установить ПО для этих дел. Политиками GPO запрещен запуск любых программ с любых директорий, кроме Windows и Program files, а установить в них что-то не хватит прав
      • 0
        Зарежьте PPTP и L2TP, их на дефолтной политике можно поднять и с пользовательскими правами. Ну и SSTP, и ним может быть сложнее.
        • 0
          Странно. Но у нас обычный пользователь не может создать PPTP и L2TP без прав администратора, при дефолтных политиках GPO
          • 0
            Смотрите ветку «Конфигурация пользователя» -> «Политики» -> «Административные шаблоны» -> «Сеть» -> «Сетевые подключения».
            Примерный пункт «Запрет доступа к мастеру новых подключений».
      • +1
        На спор обеспечу себе приемлемый транспорт с помощью содержимого Windows и Program Files.
        • 0
          Вы обеспечите. А вот наши пользователи вряд ли. Большинство пользователей мужчины и женщины за 40, которые в компьютерных познаниях не очень
          • –3
            Научу большинство ваших пользователей, и мужчин, и женщин за 40, которым хочется в одноклассники/вконтакте, как получить к нему доступ без особых затруднений и адского админского конфу.

            Обращайтесь.
            • 0
              Я не сомневаюсь. Я тоже умею поднимать туннели. Но все же, как относятся Ваши комментарии к теме поста?
              • 0
                А я это и без туннелей сделаю. hint: noVNC — наше всё.

                А комментарии относятся к попыткам контроля интернетов.
                • –1
                  Зачем такая сложность?
                  www.google.com/search?q=https+web+proxy
                  И все. Совсем все.
                  • 0
                    Упс, моя вина. Не проверил. Своременные контактики так усложнились, что уже не работают через вебпрокси
                    • 0
                      а ничего, что данная статья про блокировку и отслеживание переходов по https?
                      • –2
                        Cтатья про то, что админу хочется блокировать некоторые сайты, что трудно реализуемо ввиду https. Веб прокси совершенно нормально обходит эту проблему, чем делает всю эту возню бесполезной. Единственное утешение админу- это то, что вконтактик и иже с ним сами себя блокируют (как я понимаю, защита авторизации от MITM, чем, по сути, веб прокси и является).
                        З.ы. Фейсбучек все-таки работает. Хоть и урезанный.
                        • 0
                          я все равно не понимаю, о чем Вы говорите. Squid нормально отлавливает ваши https веб прокси, и нормально их блокирует, к чему Вы ведете разговор? Статья о том, как такие сайты отслеживать и блокировать
                          • –2
                            Вы предлагаете заблокировать гугл?
                            Вы нажимали ссылку в моем комментарии?
                            • 0
                              Вы читали статью? Что мешает МНЕ, как системному администратору, отслеживать в реальном времени (да и не в реальном) и заблокировать https веб-прокси?
                              • –2
                                Ну успехов вам в этом деле.
                                Вы действительно админ или просто теоретически рассуждаете?
                                • 0
                                  Нет, я пекарь. Я, действительно, не понимаю ход Ваших мыслей.
                                  Мне ничто оне мешает пару раз в неделю открыть статистику и посмотреть https сайты, которые посещали сотрудники, и нажать напротив нужных «Добавить в блок-лист». Занимает 10-15 минут. Или Вы думаете, что https веб-прокси настолько много. что их нельзя добавить в блок-лист? Вы ОШИБАЕТЕСЬ, и Вы действительно теоретически рассуждаете. И Вы так и не ответили на вопрос: Вы читали статью?
                                • 0
                                  и минусовать в карму совсем не обязательно…
  • +1
    Простите за возможно дурацкий вопрос, ибо не всё понял…

    Так вся эта конструкция понимает SNI или нет?
    • 0
      Да, понимает. Этапа step1 достаточно для понимания SNI-info, иначе бы не работал метод terminate для запрещенных хостов. Кстати, server_name берется как раз из SNI
      • 0
        Тогда можно еще раз на пальцах и подробнее объяснить поэтапно что происходит в момент запроса урла по https и как происходит блокировка?
        • 0
          происходит все вот так, говоря простыми словами: клиент запрашивает https ресурс, Кальмар представляется браузером, подключается к ресурсу, вытаскивает SNI-info и далее на основании правил и данных SNI происходит блокировка. Если же блокировать ресурс не нужно, Кальмар передает соединение клиенту без подмены сертификата
          • 0
            А если я (как обладатель сайта) хочу чтобы он был совсем совсем секьюрным, и чтобы никто (такой как Вы (= ) даже не смог понять, что его юзеры ходят ко мне, я беру отдельный сервер с отдельным IP под свой сайт и хостю его на нём. Теперь никакой SNI мне не нужен.
            А клиенты всё так же и будут слать в SNI имя сервера в TLS Handshake Hello пакетах? Как мне заставить их не «палить» имя сервера в SNI?
            Или современные браузеры все поголовно делают это по дефолту?
            Спасибо!
            • 0
              Пообщался с автором статьи в личке
              да, насколько мне известно, будет всегда посылаться, sni обязательно должен содержать SN, иначе не будет работать SSL.
    • +2
      Я бы сказал, на SNI все и завязано.
  • 0
    NO_SSLv3
    Вот тут все ещё немалую часть сайтов отрубите.
    • 0
      Может да, а может и нет. Какие сайты работают на SSLv3? Технология уже не поддерживается, насколько я знаю. Несколько дней тестирования, пока не жалуются)
      • +2
        Технология все ещё поддерживается, просто с неё стараются слезть и стащить других.
        SSLv3 сейчас есть у трети популярных сайтов за бугром (https://www.trustworthyinternet.org/ssl-pulse/).
        Какая-то часть этой трети серверов могут не иметь TLS1.х.
        У себя смотрите сами, просто имейте в виду, что могут быть и такие грабли.
        • 0
          спасибо, буду иметь в виду
  • 0
    «Мы же с товарищем совместными усилиями добились сбособа фильтрации и отслеживания HTTPS без подмены сертификатов, без MITM и прочего, и все это в прозрачном режиме без настройки браузеров!»
    К сожалению, принцип действия из статьи не понятен. Совсем.
    • 0
      В принципе, если посмотреть документацию Squid'a по peek-n-splice, то все станет понятно. Хорошо, я дополню статью, где подробно опишу все, что понял сам
  • +1
    Прэлэстно, прэлэстно. В одном месте собирается нормальный deb, а в другом —
    ./configure
    make
    make install
    ldconfig
    • 0
      собирается нормальный deb, потому что уже все подготовлено, так как скачаны исходники из репозитория Debian, где уже все прописано для создания пакетов, в случае с libressl ничего нет, и времени маловато, так что…
      • +1
        checkinstall
        • 0
          попробую. Все же как обычно, сначала сделать, чтобы работало, а потом сделать красиво
  • 0
    acl whitehttps ssl::server_name "/etc/squid/white_https.txt"
    acl blocked ssl::server_name "/etc/squid/blocked_https.txt"
    acl step1 at_step SslBump1
    ssl_bump peek step1 !whitehttps
    ssl_bump terminate blocked
    ssl_bump splice all !whitehttps
    Не возьму в толк, что в этом случае происходит с хостами из whitelist'а? Просто splice? И как оно отрабатывает в строке ssl_bump peek step1 !whitehttps, если peek для получения server_name ещё не должен был пройти?
    • +1
      Да, спасибо, это так сказать, «пережитки прошлого». Заработался, не заметил. whitehttps в строке sl_bump peek step1 !whitehttps вообще не нужны, как и в ssl_bump splice all !whitehttps
  • 0
    sslproxy_flags DONT_VERIFY_PEER

    Вы не подвергаете своих пользователей опасности передать данные на левый ресурс?
    • 0
      браузер в любом случае выдаст ошибку с сертификатом, к тому же у нас есть корпоративные ресурсы (и не корпоративные), где используются самоподписанные сертификаты, так что нам без этой опции не обойтись
      • 0
        подскажите как в вашей организации организованна документационная часть вопроса просмотра шифрованных сессий, ведь это считается атакой man in the middle? И прорабатывали ли вопрос использования валидного сертификата (интересно, есть ли какие либо проблемы)?
        • 0
          простите не внимательно прочел :(
          • 0
            хорошо, что заметили, что неправильно прочли) если интересно, то в прошлой конторе использовал MITM, но отказался от этой затеи спустя 2 дня. Для корректной работы нужен нормальный валидный сертификат, например от Comodo. Но организация бюджетная, там хаб купить было проблемой… А с самоподписанным сертификатом не открывались некоторые https ресурсы даже после подтверждения исключения безопасности
            • 0
              Обычно собственный root ca распространяется через политики gpo, тогда mitm будет виден только на тех сервисах, который используют certificate pinning.
              • 0
                контроллера домена там не было, так что GPO сразу отпадало, а так да. Вроде бы Гугл ругается на MITM, даже при условии, что root ca импортирован в хранилище
                • 0
                  Ну вот пиннинг сертификатов Гугля и используется во всё большем количестве браузеров. И не только его, Фаерфокс точно ругается на аддонс.мозилла.ком и твиттер. И количество встроенных сертификатов в браузеров в дальнейшем будет только расти.
                  • 0
                    Можно добавить хосты, для которых используется cert pinning в whitelist/blacklist. Но придется контролировать список таких хостов, да.
                    • 0
                      можно, но ИМХО, очень неудобно
              • 0
                было бы интересно узнать хоть 1 сервис использующий certificate pinning

                Только не говорите, что всемогущий google это использует — я точно знаю что нет, не используют, покрайней мере для gmail.
                Откуда я знаю? Недавно лечил ПК с очень занимательным вирусом, который ставил локальную https проксю, засовывал свой корневой сертификат в список корневых доверенных и все сайты с https проксировал через себя. Дак вот человек сидел на таком компе неделю и вирус все проксировал через себя и ни гуглхром ни мозилла ни пикнули, что при попытке зайти на их сайты по https соединение проксируется по подставному секртификату.
                Человечек случайно понял, что беда какая-то с ПК, когда зашел на сайт банка и в строке сертификата не было написано BANK VTB24, а был самоподписной и валидный сертификат.

                Так что certificate pinning если и работает, то только в приложениях на том же Android где в само приложение встраивается валидный сертификат. В случае Windows не представляю где certificate pinning может работать, в каких программах и на каких сервисах.
                • 0
                  Про FF (https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning):
                  How to use pinning

                  Starting with FF 32, it's on by default, so you don't have to do anything. The pinning level is enforced by a pref, security.cert_pinning.enforcement_level

                  0. Pinning disabled
                  1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, default)
                  2. Strict. Pinning is always enforced.
                  3. Enforce test mode.

                  Т.е. в случае с трояном это не может служить панацеей, т.к. сам троян может сделать всё, что угодно: как отключить пиннинг в настройках вообще, так и подменить CA, действуя от имени пользователя. Т.о. pinning в FF по-умолчанию защищает от подмены сертификатов, выпущенных «внешними» корневыми CA (идущими в поставке с FF, т.к. он не использует сертификаты ОС), но не добавленных пользователем вручную самостоятельно (таким сертификатам по-умолчанию FF доверяет безусловно, пока юзер сам не выберет режим Strict).
  • 0
    Кто нибудь поборол проблему подключения ICQ с такими настройками Squid как в статье (в настройках icq указан именно порт 443 и сервер login.icq.com)? По порту 5190 все работает без проблем.
    У меня в упор не хочет подключаться аська и нельзя зайти через браузер на https://e.mail.ru/messages/inbox/ в режиме прозрачного проксирования. При этом без проблем открываются все сайты по https и работает jabber, vk и прочее по https.
    • 0
      Проблем нет, работает несколько шлюзов с такими же настройками. ОС? Версия Squid? Ваш список блокировки HTTPS? И конфиг Squid=)
      • 0
        Debian 8.2 Jessie

        squid -v
        Squid Cache: Version 3.5.10
        Service Name: squid
        Debian linux
        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' 'BUILDCXXFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -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' '--enable-ssl' '--enable-ssl-crtd' '--with-openssl' '--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=Debian linux' '--enable-linux-netfilter' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security'


        Правило для iptables для 443 порта
        iptables -t nat -A PREROUTING -i brlan -p tcp -s 192.168.0.0/16 --dport 443 -j REDIRECT --to-port 3129


        squid.conf
        acl localnet src 192.168.0.0/16
        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 allow manager localhost
        http_access deny manager
        http_access deny !Safe_ports
        http_access deny CONNECT !SSL_ports
        http_access allow localnet
        http_access allow localhost
        http_access deny all

        http_port 3128 intercept options=NO_SSLv3:NO_SSLv2
        https_port 3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/ssl/squid.pem
        http_port 3130 options=NO_SSLv3:NO_SSLv2

        always_direct allow all
        sslproxy_cert_error allow all
        sslproxy_flags DONT_VERIFY_PEER

        acl blocked ssl::server_name "/etc/squid/block_social.acl"
        acl url_social_filtred src 192.168.0.10 192.168.0.11
        acl step1 at_step SslBump1

        ssl_bump peek step1
        ssl_bump terminate blocked url_social_filtred
        ssl_bump splice all

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

        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

        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


        Содержимое /etc/squid/block_social.acl
        odnoklassniki\.ru
        vkontakte\.ru
        vk\.com
        facebook\.com
        fishki\.net
        my\.mail\.ru


        В таком виде зайти на почту mail.ru просто не реально, пол сайта просто не загружается.
        Так же криво работает https://calendar.google.com и https://maps.google.com
        Что интересно https://maps.google.com в хроме открывается, а если используется виджет карты на каком нить сайте с gmaps то он не загружается.
        И выборочно другие сайты, причем в разных браузерах все по разному, самое большое количество непоняток у Opera, в Google Chrome получше, но то что почту mail.ru не открывается из-зо всех браузеров это точно.
        И ICQ на login.icq.com порт 443 с такими настройками не подключается
        • 0
          ставьте версию 3.5.8, уже обсуждалось и в моем блоге, и тут. Даже в статье есть запись в конце. Причина в каком-то баге, который добавили в версиях >3.5.8. Версии >=4 не тестировались
        • 0
          плюс ко всему имейте в виду, что HTTPS блочится по server_name, и раз Вы заблокировали my.mail.ru, то заблокируется и ICQ, так как это одна контора с одними и теми же IP. Это Вам на будущее, когда поставите версию 3.5.8. С версией >3.5.8 у вас периодически будет падать Интернет, будет помогать перезапуск прокси, но ненадолго. К тому же, почему у Вас нет перенаправления на 80 порт Squid'а? Насколько мне известно, это будет негативно сказываться на работе
          • 0
            Попробую завтра 3.5.8
            Я так понимаю, что патч для bio.cc не нужен если я использую openssl? Или интегрировать libressl, но как быть с кучей другого софта на сервере который использует openssl, например openvpn или nginx?

            Перенаправление на 80 порт есть, просто не написал его, такое же как и для 443 только --to-port 3128
            iptables -t nat -A PREROUTING -i brlan -p tcp -s 192.168.0.0/16 --dport 80 -j REDIRECT --to-port 3128

            С server_name мысль понятна, спасибо.
            • 0
              без LibreSSL работать не будет, делайте все, как по статье. От libressl хуже не будет, оно совместимо с openssl. И читайте статью внимательно.
              update-alternatives --install /usr/bin/openssl openssl /usr/local/bin/openssl 50
              
  • 0
    Обновил статью!
  • 0
    Ребята, читайте!
    UPD 14.12.15: спешу поделиться с коллегами отличной новостью! Я нашел способ заставить работать новые версии Squid'а без особых танцев с бубном! Необходимо, чтобы у клиентов и в настройках Squid'а были одинаковые DNS! В моем случае, на шлюзе с Кальмаром крутится Bind. Назначил клиентам именно его, и Кальмару директивой:
    dns_nameservers 127.0.0.1
    
    . После чего все успешно заработало. Проверено на Squid 4.0.3, собрана БЕЗ Libressl!


    Прошу протестировать
    • 0
      Как убрать теперь из debian установленную Libressl?
      • 0
        с помощью dpkg
        • +1
          dpkg не убирает то что было добавлено в alternatives
          скорее всего так
          # update-alternatives --remove openssl /usr/local/bin/openssl
          # update-alternatives --remove openssl /usr/bin/openssl-1
          # mv /usr/bin/openssl-1 /usr/bin/openssl
          и проверка
          # openssl version
          OpenSSL 1.0.1k 8 Jan 2015
          и только потом
          # apt-get remove libressl --purge
          • 0
            да, я совершенно забыл про update-alternatives. Нужно сделать в обратном порядке, нежели чем в статье
  • 0
    Рано Вы написали, что на 4.0.3 все работает. Мои тесты показали что на debian 8.2 x64 даже на 3 пользователях процесс squid через минут 20-30 просто аварийно завершается и все. Сомневаюсь, что это специфика моей системы, скорее недоработки squid 4.0.3
    • 0
      хм… У меня пока работает. Странно. Хорошо, если еще человек напишет один, новость убираю
    • 0
      да, Ваши тесты подтверждаются, судя по всему. Создал 5 виртуальных машин с идентичной конфигурацией через Puppet. Только один сервер работает нормально, но если vlan переключать на другие, то там кальмар крашится. В чем дело, я не понимаю.
  • 0
    Скажите, пожалуйста, а как заблокировать доступ ко всему и разрешить только на указанные сайты.
  • 0
    Вах, какой статья хороший. А вы не проверяли, с 15 года указанные проблемы не исправили? Хочется попробовать, но как-то лениво libressl ставить, да ещё и версию сквида понижать...
  • 0
    Хе-хе) главное, не забыть взять отпуск на 364-й день:

    openssl req -new -newkey rsa:1024 -days 365
  • 0
    А под CentOS7 никто не пробовал запускать?
    • 0
      Пробовал! Вот тут: https://habrahabr.ru/sandbox/99037/

      Более того, мне кажется, ценность этой заметки сравнима со статьёй nagibat0r -а, и её определённо надо вытаскивать из песочницы!

      UPD 14.12.15: Необходимо, чтобы у клиентов и в настройках Squid'а были одинаковые DNS

      Ага. И теперь становится очевидно, зачем :)
  • 0
    А наличие wpad не решает проблему? По крайней мере для пользователей с мобильными устройствами?
    • 0
      Быть может… Но судя по 41К просмотров, очень многие предпочитают именно прозрачный вариант :-)

      Кстати, у меня получилось (убунта). squid-3.5.13 + openssl-1.0.2f + патч на hostHeaderIpVerify + pdnsd — ошибки исчезли, логи красивые. Рекомендую.

      Правда, не могу разобраться, почему в первый день работы кешировались все картинки с рамблера, а сейчас одна, редко две из десяти — что это за своенравие такое? Кто в курсе? И если настроить правила для фильтрации рекламы, тот же рамблер бесконечно крутит колёсико загрузки, хотя firebug показывает, что все запросы завершены.
      • 0
        Но судя по 41К просмотров, очень многие предпочитают именно прозрачный вариант :-)
        Странный вывод. С чего вы взяли, что количество просмотров коррелирует с реализацией того, о чём говорится в статье?
        • 0
          Это тот случай, когда за минусом к комменту следует пояснение этого минуса? Если так, то лучше бы по-старинке, втихую, потому что я ну правда не знаю, что ответить, так, чтобы без флейма. Хотя бы с того, что определённый процент пришёл из поиска, вбив слова "squid", "https" и "прозрачный". С того, что прямо сейчас, именно эта статья увеличивает количество успешных реализаций описанного алгоритма, как когда-то журнал Хакер увеличил число приводов по 272-й. Если и этому требуются доказательства, то отсылаю к самому автору, он об этом пишет в первом абзаце.

          Коррелирует или нет, их всё равно много, по разным причинам. Много — означает не процентное соотношение, а просто количество, "по головам".

          — Сколько в Америке заправок?
          — Очень много!
          — Странный вывод. С чего вы взяли?
  • 0
    Ну в принципе 41к просмотров говорит только о том, что на статью часто натыкаются. Сколько человек ее применило — неизвестно.
    То что она все еще в песочнице тоже о чем-то говорит.
    А вот чем не прозрачен wpad? Если браузеры и так ищут запись указывающую на расположении этого файла?
    • 0
      Не, я про эту. А которая в песочнице — отличное дополнение. Их вообще можно вместе слить, освежить — будет классный tutorial.

      С wpad не работал, поэтому не могу ничего сказать. Совершенно не в курсе, будет ли он подхватываться, если в браузере стоит "прокси: нет" вместо "авто", если выключены скрипты/NoScript (wpad это же скрипт), умеют ли с ним работать все телефоны (вот тут чел считает, что нет). В этом плане он непрозрачен, придётся обходить с поклоном всех и каждого, чтобы объяснить, где поставить галочку, и почему им придётся купить новый телефон для интернета)
  • 0
  • 0
    У меня работает сквид на centos7, в прозрачном режиме, на домашнем роутере. Каких либо проблем не замечено. Подскажите, что имеет в виду автор статьи, когда говорит что пользователей банит googlе?

    Linux router.local 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

     squid -v
    Squid Cache: Version 3.5.8
    Service Name: squid
    configure options:  '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--exec_prefix=/usr' '--libexecdir=/usr/lib64/squid' '--localstatedir=/var' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--with-logdir=$(localstatedir)/log/squid' '--with-pidfile=$(localstatedir)/run/squid.pid' '--disable-dependency-tracking' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-auth-basic=DB,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,getpwnam' '--enable-auth-ntlm=smb_lm,fake' '--enable-auth-digest=file,LDAP,eDirectory' '--enable-auth-negotiate=kerberos,wrapper' '--enable-external-acl-helpers=wbinfo_group,kerberos_ldap_group' '--enable-cache-digests' '--enable-cachemgr-hostname=localhost' '--enable-delay-pools' '--enable-epoll' '--enable-icap-client' '--enable-ident-lookups' '--enable-linux-netfilter' '--enable-removal-policies=heap,lru' '--enable-snmp' '--enable-storeio=aufs,diskd,ufs,rock' '--enable-wccpv2' '--enable-esi' '--enable-ssl-crtd' '--enable-icmp' '--with-aio' '--with-default-user=squid' '--with-filedescriptors=16384' '--with-dl' '--with-openssl' '--with-pthreads' '--with-included-ltdl' '--disable-arch-native' '--enable-ecap' '--without-nettle' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -fPIC' 'PKG_CONFIG_PATH=%{_PKG_CONFIG_PATH}:/usr/lib64/pkgconfig:/usr/share/pkgconfig' --enable-ltdl-convenience

    OpenSSL 1.0.1e-fips 11 Feb 2013
  • 0
    В том что оно работает не сомневаюсь. Но сам пробую squid 4.0.7 и openssl 1.0.2g.

    А вот что автор имеет ввиду под баном в гугле — без понятия. Страничку с просьбой ввести капчу и доказать что ты не бот? Плюс я в принципе не понимаю причем тут Round-Robin DNS.
    • 0
      я думаю, автор имеет в виду вот это: гугл перестает открываться, по причине того, что прокси "затыкается" на нем.
  • +1
    Как оказалось, проблема известная и все варианты решения сводятся к прописыванию адреса прокси у пользователя.

    А вместо этого автор открывает потенциальную уязвимость. Плюс в той статье нету подробного и понятного описания причин возникновения такой проблемы.
    • 0
      Действительно, про уязвимость написано слишком мало. Даже по CVE-2009-0801 гуглится только, что flash и java на нехороших страничках смогут подменой заголовков через сквид получать доступ к интранету. Но ни слова, как именно. Исправили? Да, мы исправили. А что вы исправили… Тихушники, блин.

      У меня в конфиге указан tcp_outgoing_address, и по логике обращаться к интранету squid не может (надо бы проверить). В этом случае уязвимость сводится к возможности экстремально-продвинутым-пользователям обойти чёрный список сайтов, и не более того. Учитывая, что в чёрном списке (у меня) только сервера обновлений windows, антивирусов и прочей дребедени, которая последнее время забила 80% канала, оставив на котиков с ютуба только 20, уязвимости как таковой и нет...
    • 0
      Проверил только что, можно запретить сквиду обращаться в локальную сеть, назначив outgoing address (внешний, скажем, 11.11.11.11) плюс два правила в iptables:

      /sbin/iptables -A OUTPUT --source 11.11.11.11/32 --dst 127.0.0.0/24 -j REJECT
      /sbin/iptables -A OUTPUT --source 11.11.11.11/32 --dst 192.168.1.1/24 -j REJECT
      • +1
        Плюсанул бы, да срок кончился… Полезная информация! Необходимо взять на заметку!

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