Pull to refresh

Comments 140

UFO just landed and posted this here
Я с Вами согласен, Вы скорее всего клоните в сторону блокировки по DNS. Но первоочередная задача отслеживать посещение ресурсов, а не просто блокировать. Мне необходимо производить аудит посещаемых сайтов. Работаю я с серверами на Линуксе, а Squid — это единственный пригодный прокси-сервер с нужными мне возможностями.

З.Ы.: по производительности скажу следующее:
в конторе over 200 пользователей (одна площадка, планирую подключить еще 3 площадки, добавится еще около 100 клиентов), Squid 3.5.8 прекрасно себя чувствует на 2 ядрах с 2 Гигами
UFO just landed and posted this here
Верно, все идет к этому. Но и просто даже посмотреть список посещаемых HTTPS ресурсов, как его получить, если не бампить SSL соединение? Смотреть сторонними утилитами типа tcpdump — это муторно, а здесь удобные логи с вебмордой для просмотра. Поправьте, если я не прав. У нас браузеры статически не настроены на Proxy. Полностью прозрачный режим.
UFO just landed and posted this here
при статически настроенном в браузере адресе прокси?
UFO just landed and posted this here
в том и дело! статически настроенный браузер — это не проблема, и в статье не освещается…
цель — прозрачный прокси с нужными функциями
статически настроенный браузер

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

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

Попробуйте, вдруг поможет.
http_access действует только для HTTP, но никак не для HTTPS, в том то и дело
Проверяли? интересно как реагирует сквид. Ошибка на этапе парсинга конфига или во время работы (запустите squid -N -d 99 -f /path/to/squid.conf и возможно это добавит больше подробностей)
Некоторое время назад я докапывался до некоторых особенностей работы сквида в т.ч. изучением исходников, и у меня сложилось мнение, что запрос «растуннеливается», а затем идёт по стандартной для HTTP схеме.
Я могу ошибаться, но есть версия, что если запросы попадающие в ACL «blocked» всё-таки растуннелить (bump), http_access сработает.
Надеюсь, чем мог, тем помог.
хм, я проверю завтра на работе, спасибо. Хотя судя по документации эта директива работает только для HTTP
И все же, вот кусочек из оф.документации по 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)."
ради интереса все-таки проверил, нет, не работает
Спасибо за эксперимент и ваше время!
Всё-таки получается, что сквид в такой конфигурации (splice) растуннеливает только до предъявленного сертификата с обоих сторон, а сам обмен как был зашифрован, так и остаётся.
Если это так, и я правильно понял доку wiki.squid-cache.org/Features/SslPeekAndSplice и то после
ssl_bump bump blocked
http_access может и сработать.

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

image
интересно… На Гитхабе случаем нет исходников?)
нет я на коленке собрал. Вам отправлю в личку, кому еще нужно пишите в личку.
благодарю! попробую сегодня
UFO just landed and posted this here
VPN не зарезан, более того, площадки связаны в единую сеть по Openvpn. Блокировать незачем. VPN никто поднять не сможет, так как не смогут установить ПО для этих дел. Политиками GPO запрещен запуск любых программ с любых директорий, кроме Windows и Program files, а установить в них что-то не хватит прав
UFO just landed and posted this here
Странно. Но у нас обычный пользователь не может создать PPTP и L2TP без прав администратора, при дефолтных политиках GPO
UFO just landed and posted this here
На спор обеспечу себе приемлемый транспорт с помощью содержимого Windows и Program Files.
Вы обеспечите. А вот наши пользователи вряд ли. Большинство пользователей мужчины и женщины за 40, которые в компьютерных познаниях не очень
Научу большинство ваших пользователей, и мужчин, и женщин за 40, которым хочется в одноклассники/вконтакте, как получить к нему доступ без особых затруднений и адского админского конфу.

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

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

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

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

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

Так что certificate pinning если и работает, то только в приложениях на том же Android где в само приложение встраивается валидный сертификат. В случае Windows не представляю где certificate pinning может работать, в каких программах и на каких сервисах.
UFO just landed and posted this here
Кто нибудь поборол проблему подключения ICQ с такими настройками Squid как в статье (в настройках icq указан именно порт 443 и сервер login.icq.com)? По порту 5190 все работает без проблем.
У меня в упор не хочет подключаться аська и нельзя зайти через браузер на https://e.mail.ru/messages/inbox/ в режиме прозрачного проксирования. При этом без проблем открываются все сайты по https и работает jabber, vk и прочее по https.
Проблем нет, работает несколько шлюзов с такими же настройками. ОС? Версия Squid? Ваш список блокировки HTTPS? И конфиг Squid=)
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 с такими настройками не подключается
ставьте версию 3.5.8, уже обсуждалось и в моем блоге, и тут. Даже в статье есть запись в конце. Причина в каком-то баге, который добавили в версиях >3.5.8. Версии >=4 не тестировались
плюс ко всему имейте в виду, что HTTPS блочится по server_name, и раз Вы заблокировали my.mail.ru, то заблокируется и ICQ, так как это одна контора с одними и теми же IP. Это Вам на будущее, когда поставите версию 3.5.8. С версией >3.5.8 у вас периодически будет падать Интернет, будет помогать перезапуск прокси, но ненадолго. К тому же, почему у Вас нет перенаправления на 80 порт Squid'а? Насколько мне известно, это будет негативно сказываться на работе
Попробую завтра 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 мысль понятна, спасибо.
без LibreSSL работать не будет, делайте все, как по статье. От libressl хуже не будет, оно совместимо с openssl. И читайте статью внимательно.
update-alternatives --install /usr/bin/openssl openssl /usr/local/bin/openssl 50
Ребята, читайте!
UPD 14.12.15: спешу поделиться с коллегами отличной новостью! Я нашел способ заставить работать новые версии Squid'а без особых танцев с бубном! Необходимо, чтобы у клиентов и в настройках Squid'а были одинаковые DNS! В моем случае, на шлюзе с Кальмаром крутится Bind. Назначил клиентам именно его, и Кальмару директивой:
dns_nameservers 127.0.0.1
. После чего все успешно заработало. Проверено на Squid 4.0.3, собрана БЕЗ Libressl!


Прошу протестировать
Как убрать теперь из debian установленную Libressl?
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
да, я совершенно забыл про update-alternatives. Нужно сделать в обратном порядке, нежели чем в статье
Рано Вы написали, что на 4.0.3 все работает. Мои тесты показали что на debian 8.2 x64 даже на 3 пользователях процесс squid через минут 20-30 просто аварийно завершается и все. Сомневаюсь, что это специфика моей системы, скорее недоработки squid 4.0.3
хм… У меня пока работает. Странно. Хорошо, если еще человек напишет один, новость убираю
да, Ваши тесты подтверждаются, судя по всему. Создал 5 виртуальных машин с идентичной конфигурацией через Puppet. Только один сервер работает нормально, но если vlan переключать на другие, то там кальмар крашится. В чем дело, я не понимаю.
Скажите, пожалуйста, а как заблокировать доступ ко всему и разрешить только на указанные сайты.
Вах, какой статья хороший. А вы не проверяли, с 15 года указанные проблемы не исправили? Хочется попробовать, но как-то лениво libressl ставить, да ещё и версию сквида понижать...
Хе-хе) главное, не забыть взять отпуск на 364-й день:

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

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

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

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

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

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

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

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

С wpad не работал, поэтому не могу ничего сказать. Совершенно не в курсе, будет ли он подхватываться, если в браузере стоит "прокси: нет" вместо "авто", если выключены скрипты/NoScript (wpad это же скрипт), умеют ли с ним работать все телефоны (вот тут чел считает, что нет). В этом плане он непрозрачен, придётся обходить с поклоном всех и каждого, чтобы объяснить, где поставить галочку, и почему им придётся купить новый телефон для интернета)
У меня работает сквид на 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
В том что оно работает не сомневаюсь. Но сам пробую squid 4.0.7 и openssl 1.0.2g.

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

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

У меня в конфиге указан tcp_outgoing_address, и по логике обращаться к интранету squid не может (надо бы проверить). В этом случае уязвимость сводится к возможности экстремально-продвинутым-пользователям обойти чёрный список сайтов, и не более того. Учитывая, что в чёрном списке (у меня) только сервера обновлений windows, антивирусов и прочей дребедени, которая последнее время забила 80% канала, оставив на котиков с ютуба только 20, уязвимости как таковой и нет...
Проверил только что, можно запретить сквиду обращаться в локальную сеть, назначив 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
Плюсанул бы, да срок кончился… Полезная информация! Необходимо взять на заметку!
Есть ли решение с tproxy?
Проблемка простая: в логах только ip адрес, а нужно dns имя.
Судя по тому, что пишут в списках рассылки (имя только в MitM режиме), штатно не решается.
К сожалению нет, существует масса хостингов, которые не прописывают обратную зону. Была мысль, бить в лог успешное или неуспешное срабатывание acl (оно же срабатывает!), но кроме debug режима пока решение не нашел.
а мне вот блокировать не надо, надо только считать и тоже проблема…
В логе размер — 0 =(
Уже на этапе сборки прочитал что блокировки поддается только hostname :( обидно. Я думал кто то победил проблему с урлами. Придется пользоваться по старинке подменой. В пятницу от РКН получил вот такую текстовочку:
В связи с распоряжением Роскомнадзора Прошу Вас при оказании услуги по предоставлению доступа к информационно-телекоммуникационной сети «Интернет», осуществить запрет блокировки следующих сетевых адресов: 95.213.11.180, 87.240.165.82 и 5.255.255.88, отсутствующих в Перечне записей, содержащих информацию о доменных именах, указателях страниц сайтов в сети «Интернет» и сетевых адресах, позволяющих идентифицировать сайты в сети «Интернет» и (или) информационные ресурсы, содержащие информацию, доступ к которой должен быть ограничен операторами связи в порядке, установленным Федеральным законом от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (Выгрузка), предоставляемом операторам связи.

А потом еще и звонком предупредили, что делайте чего хотите, но IP целиком закрывать нельзя только URL. Я правда с самого начала так не делаю. Так что теперь без вариантов только подмена. К сожалению способ автора мне бесполезен.

(некропостинг)
А разве наши дорогие провайдеры блокируют URL'ы?) Такое было только во времена http, без s.

Так и пост от 2015 года. Тогда еще инет состоял не весь из https. Сейчас это конечно не актуально. Сейчас блокируют целиком по домену, вытаскивая его из хэндшейка.

Подскажите пожалуйста, в данной реализации возможно прикрутить Screen Squid или Sarg?

Но только ScreenSquid. SARG лучше не используйте и забудьте его, как страшный сон сисадмина

Sign up to leave a comment.

Articles

Change theme settings