И вот, совсем недавно, мне один товарищ рассказал, что он поднимает у себя в конторе кеширующий прокси с фильтрацией 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
Качаем
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
L-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 3.5.10 — последняя на данный момент стабильная версия, в которой исправлено множество багов и сделано множество оптимизаций, судя по чейнжлогу, в т.ч. исправлен баг, из-за которого пришлось в статье применять патч к bio.cc. ВНИМАНИЕ! НЕ ТЕСТИРОВАЛАСЬ на боевом сервере!)
Хочу сказать спасибо товарищу Дмитрию Рахматуллину, без него бы не получилось сделать то, что написано выше. Также, отдельное спасибо разработчикам Squid'а, которые оперативно ответили на мой баг-репорт об ошибке в libssl. И спасибо ребятам Nadz Goldman и gmax007 с Тостера, которые направили в нужное русло мои идеи по переносу Squid'а на физически отдельный от основного шлюза сервер.
Комментарии (79)
la0
28.09.2015 14:39> К сожалению, при блокировке HTTPS ресурсов, не появляется сообщение Squid'a «Доступ запрещен»
Вы попадаете вот сюда:
ssl_bump terminate blocked
Думаю, можно не делать terminate, а сделать
http_access deny blocked
Попробуйте, вдруг поможет.
nagibat0r
28.09.2015 14:41+1http_access действует только для HTTP, но никак не для HTTPS, в том то и дело
la0
28.09.2015 15:04Проверяли? интересно как реагирует сквид. Ошибка на этапе парсинга конфига или во время работы (запустите squid -N -d 99 -f /path/to/squid.conf и возможно это добавит больше подробностей)
Некоторое время назад я докапывался до некоторых особенностей работы сквида в т.ч. изучением исходников, и у меня сложилось мнение, что запрос «растуннеливается», а затем идёт по стандартной для HTTP схеме.
Я могу ошибаться, но есть версия, что если запросы попадающие в ACL «blocked» всё-таки растуннелить (bump), http_access сработает.
Надеюсь, чем мог, тем помог.nagibat0r
28.09.2015 17:17+1хм, я проверю завтра на работе, спасибо. Хотя судя по документации эта директива работает только для HTTP
nagibat0r
28.09.2015 20:13+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)."
nagibat0r
29.09.2015 10:46+1ради интереса все-таки проверил, нет, не работает
la0
29.09.2015 23:43Спасибо за эксперимент и ваше время!
Всё-таки получается, что сквид в такой конфигурации (splice) растуннеливает только до предъявленного сертификата с обоих сторон, а сам обмен как был зашифрован, так и остаётся.
Если это так, и я правильно понял доку wiki.squid-cache.org/Features/SslPeekAndSplice и то после
ssl_bump bump blocked
http_access может и сработать.
PS мне стало интересно и я это проверил: в настройке, которая без разбора делает «bump на всё» https_access deny сработал(как и ожидалась, произошла подмена сертификата о чем браузер выдал предупреждение).
grossws
30.09.2015 01:02Всё-таки получается, что сквид в такой конфигурации (splice) растуннеливает только до предъявленного сертификата с обоих сторон, а сам обмен как был зашифрован, так и остаётся.
Нет там «растуннелирования», как вы выразились. Просто squid парсит client hello и server hello.
nagibat0r
30.09.2015 06:05Не за что. Нет, Вы не совсем правильно все поняли. Все, что относится к SSl, не работает с правилами http_access. Имя сервера (ну или имя домена, если уж совсем грубо) из SSL можно извлечь только из ssl::server_name, и http_access не работает с этой директивой, на то он и HTTP_access
juffinhalli
28.09.2015 14:56Спасибо за ценный мануал! Добавил добра в карму.
Ещё прошу подсказать чем анализируете логи squid.
AcidVenom
28.09.2015 15:37А исходящие VPN-соединения для пользователей у вас зарезаны?
nagibat0r
28.09.2015 17:16VPN не зарезан, более того, площадки связаны в единую сеть по Openvpn. Блокировать незачем. VPN никто поднять не сможет, так как не смогут установить ПО для этих дел. Политиками GPO запрещен запуск любых программ с любых директорий, кроме Windows и Program files, а установить в них что-то не хватит прав
AcidVenom
28.09.2015 17:21Зарежьте PPTP и L2TP, их на дефолтной политике можно поднять и с пользовательскими правами. Ну и SSTP, и ним может быть сложнее.
nagibat0r
28.09.2015 18:31Странно. Но у нас обычный пользователь не может создать PPTP и L2TP без прав администратора, при дефолтных политиках GPO
AcidVenom
29.09.2015 08:45Смотрите ветку «Конфигурация пользователя» -> «Политики» -> «Административные шаблоны» -> «Сеть» -> «Сетевые подключения».
Примерный пункт «Запрет доступа к мастеру новых подключений».
amarao
28.09.2015 22:37+1На спор обеспечу себе приемлемый транспорт с помощью содержимого Windows и Program Files.
nagibat0r
29.09.2015 09:40Вы обеспечите. А вот наши пользователи вряд ли. Большинство пользователей мужчины и женщины за 40, которые в компьютерных познаниях не очень
amarao
29.09.2015 14:09-3Научу большинство ваших пользователей, и мужчин, и женщин за 40, которым хочется в одноклассники/вконтакте, как получить к нему доступ без особых затруднений и адского админского конфу.
Обращайтесь.
Zolushok
28.09.2015 16:07+1Простите за возможно дурацкий вопрос, ибо не всё понял…
Так вся эта конструкция понимает SNI или нет?nagibat0r
28.09.2015 17:14Да, понимает. Этапа step1 достаточно для понимания SNI-info, иначе бы не работал метод terminate для запрещенных хостов. Кстати, server_name берется как раз из SNI
lexore
28.09.2015 19:09NO_SSLv3
Вот тут все ещё немалую часть сайтов отрубите.nagibat0r
28.09.2015 19:21Может да, а может и нет. Какие сайты работают на SSLv3? Технология уже не поддерживается, насколько я знаю. Несколько дней тестирования, пока не жалуются)
lexore
28.09.2015 19:28+2Технология все ещё поддерживается, просто с неё стараются слезть и стащить других.
SSLv3 сейчас есть у трети популярных сайтов за бугром (https://www.trustworthyinternet.org/ssl-pulse/).
Какая-то часть этой трети серверов могут не иметь TLS1.х.
У себя смотрите сами, просто имейте в виду, что могут быть и такие грабли.
MaxxxZ
28.09.2015 20:26«Мы же с товарищем совместными усилиями добились сбособа фильтрации и отслеживания HTTPS без подмены сертификатов, без MITM и прочего, и все это в прозрачном режиме без настройки браузеров!»
К сожалению, принцип действия из статьи не понятен. Совсем.nagibat0r
28.09.2015 20:31В принципе, если посмотреть документацию Squid'a по peek-n-splice, то все станет понятно. Хорошо, я дополню статью, где подробно опишу все, что понял сам
grossws
28.09.2015 22:43+1Прэлэстно, прэлэстно. В одном месте собирается нормальный deb, а в другом —
./configure
make
make install
ldconfignagibat0r
29.09.2015 09:42собирается нормальный deb, потому что уже все подготовлено, так как скачаны исходники из репозитория Debian, где уже все прописано для создания пакетов, в случае с libressl ничего нет, и времени маловато, так что…
grossws
28.09.2015 23:23acl whitehttps ssl::server_name "/etc/squid/white_https.txt"
Не возьму в толк, что в этом случае происходит с хостами из whitelist'а? Просто splice? И как оно отрабатывает в строке
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 !whitehttpsssl_bump peek step1 !whitehttps, если peek для получения server_name ещё не должен был пройти?nagibat0r
29.09.2015 10:01+1Да, спасибо, это так сказать, «пережитки прошлого». Заработался, не заметил. whitehttps в строке sl_bump peek step1 !whitehttps вообще не нужны, как и в ssl_bump splice all !whitehttps
kbool
29.09.2015 11:33sslproxy_flags DONT_VERIFY_PEER
Вы не подвергаете своих пользователей опасности передать данные на левый ресурс?nagibat0r
29.09.2015 11:39браузер в любом случае выдаст ошибку с сертификатом, к тому же у нас есть корпоративные ресурсы (и не корпоративные), где используются самоподписанные сертификаты, так что нам без этой опции не обойтись
Sptsh
30.09.2015 04:57подскажите как в вашей организации организованна документационная часть вопроса просмотра шифрованных сессий, ведь это считается атакой man in the middle? И прорабатывали ли вопрос использования валидного сертификата (интересно, есть ли какие либо проблемы)?
Sptsh
30.09.2015 05:07простите не внимательно прочел :(
nagibat0r
30.09.2015 06:13хорошо, что заметили, что неправильно прочли) если интересно, то в прошлой конторе использовал MITM, но отказался от этой затеи спустя 2 дня. Для корректной работы нужен нормальный валидный сертификат, например от Comodo. Но организация бюджетная, там хаб купить было проблемой… А с самоподписанным сертификатом не открывались некоторые https ресурсы даже после подтверждения исключения безопасности
grossws
30.09.2015 13:32Обычно собственный root ca распространяется через политики gpo, тогда mitm будет виден только на тех сервисах, который используют certificate pinning.
nagibat0r
01.10.2015 06:11контроллера домена там не было, так что GPO сразу отпадало, а так да. Вроде бы Гугл ругается на MITM, даже при условии, что root ca импортирован в хранилище
Aclz
01.10.2015 11:06Ну вот пиннинг сертификатов Гугля и используется во всё большем количестве браузеров. И не только его, Фаерфокс точно ругается на аддонс.мозилла.ком и твиттер. И количество встроенных сертификатов в браузеров в дальнейшем будет только расти.
Aclz
Как-то не понятно. HTTPS не управляется лишь если мы хотим блокировать по контенту страниц или по параметрам URL. На уровне доменного имени HTTPS вполне себе прекрасно блокируется.
PS: На 3.5.х полгода назад сильно жаловались по производительности и стабильности. Счас как?
nagibat0r
Я с Вами согласен, Вы скорее всего клоните в сторону блокировки по DNS. Но первоочередная задача отслеживать посещение ресурсов, а не просто блокировать. Мне необходимо производить аудит посещаемых сайтов. Работаю я с серверами на Линуксе, а Squid — это единственный пригодный прокси-сервер с нужными мне возможностями.
З.Ы.: по производительности скажу следующее:
в конторе over 200 пользователей (одна площадка, планирую подключить еще 3 площадки, добавится еще около 100 клиентов), Squid 3.5.8 прекрасно себя чувствует на 2 ядрах с 2 Гигами
Aclz
То есть условно сам список сайтов пользователя недостаточен, а нужно знать конкретно какие профили вконтакта он посещал, какие ролики ютуба смотрел и т.д.?
nagibat0r
Верно, все идет к этому. Но и просто даже посмотреть список посещаемых HTTPS ресурсов, как его получить, если не бампить SSL соединение? Смотреть сторонними утилитами типа tcpdump — это муторно, а здесь удобные логи с вебмордой для просмотра. Поправьте, если я не прав. У нас браузеры статически не настроены на Proxy. Полностью прозрачный режим.
Aclz
Сам список посещенных 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 -nagibat0r
при статически настроенном в браузере адресе прокси?
Aclz
Увы да, про транспарентный не скажу.
nagibat0r
в том и дело! статически настроенный браузер — это не проблема, и в статье не освещается…
цель — прозрачный прокси с нужными функциями
chelaxe
Можно еще wpad как я сделал и закрыть 443 порт. Хочешь интернет — включай прокси.
nagibat0r
Firefox у нас везде установлен. Если бы все было так просто, я бы не мучился с компиляцией Кальмара
chelaxe
у Firefox есть проблемы? У нас работают. Сделал раздачу по DHCP и DNS и все.
nagibat0r
когда изначально стоит галка «Не использовать прокси», то да
chelaxe
nagibat0r
нет нет, идея-то хорошая) но я сомневаюсь, что наши бабули смогут включить прокси, даже если им объяснить, как это сделать.
chelaxe
Я делал сайтик с пошаговой инструкцией для разных браузеров. Еще для особых случаев использовал удаленное управление. Таким образом перевел парк в 100-150 пользователей. Заняло неделю. Если был бы AD было бы быстрее конечно.
Aclz
В AD это совершенно не проблема.
nagibat0r
Firefox изначально настроен на «не использовать прокси», политики AD Firefox не подхватывает.
Aclz
Есть плагин GPO для FF, есть различные способы его распространения, в общем проблема решаема, даже на хабре об этом писали.
nagibat0r
Статью нашел, прочитал. Если оно работает, это замечательно, надо будет проверить. Но опять же. Тема статьи — прозрачный прокси-сервер)
nagibat0r
Статью нашел, прочитал. Если оно работает, это замечательно, надо будет проверить. Но опять же. Тема статьи — прозрачный прокси-сервер)
ekungurov
То есть суть новшеств в том, что сейчас возможна работа HTTPS в прозрачном режиме прокси, что раньше было невозможно.
nagibat0r
мало того, что в прозрачном режиме! используется новая технология peek-and-splice, которая позволяет бампить ssl без подмены сертификатов, т.е. без MITM атаки
Sptsh
1000 пользователей — проблем никаких, только при использовании LDAP\Kerberos количество хелперов нужно увеличить.
nagibat0r
про хелперы все верно, когда в предыдущей конторе поднимал Кальмара, делал авторизацию, и тоже пришлось кол-во хелперов увеличить