Squid ssl bump: Squid3 в режиме SSLBump с динамической генерацией сертификатов / Хабр
Squid3 в режиме SSLBump с динамической генерацией сертификатов / Хабр
Приветствую.
Шифрованный веб-трафик вещь хорошая, но порой совершенно не ясно что пользователь там, внутри, делает. При заходе на любой https ресурс через squid, в логи записывается достаточно строк подобного вида:
1330231066.104 10 172.26.27.8 TCP_MISS/200 390 CONNECT mail.google.com:443 — HIER_DIRECT/173.194.32.54 —
1330241192.883 9 172.26.27.97 TCP_MISS/200 390 CONNECT mc.yandex.ru:443 — HIER_DIRECT/213.180.193.119 —
Видно, что в определённое время пользователи зашли на gmail и яндекс. В принципе вот и всё что мы видим из логов. Но не понятно выполнялся ли GET или POST запрос, не видно полных урлов, ни размеров файлов. Так же нет возможности проверить ssl трафик антивирусной программой либо какими content inspection программами.
В этой статье я хочу описать возможность squid’а «разламывать» ssl соединение и иметь хоть какой-то обзор происходящего в https трафике.
Так как на CentOS стоит «усиленный» openssl, то сборка squid’а c необходимыми нам ключам не получается.
Есть два варианта решения данной проблемы.
Первый — это лезть в инклюд файлы установленного openssl, потом в исходники сквида и менять некоторые строки. И второй — это собирать сквид с кастомным openssl.
Первый вариант слишком хардкорный и оставим его в стороне.
1. openssl
Итак, для начала нам надо собрать свой openssl. Тут всё довольно просто и никакой магии:
wget www.openssl.org/source/openssl-1.0.0k.tar.gztar -zxf openssl-1.0.0k.tar.gzcd openssl-1.0.0k
Что бы не было конфликтов с уже установленной версией openssl, указываем новый путь:
./config shared --prefix=/opt/squid/openssl --openssldir=/opt/squid/opensslmakemake install
Всё, openssl собран и готов к использованию.
2. squid
Сборка прокси сервера аналогична сборке любой программы (configure && make && make install), единственное это указание определённых ключей при компиляции:
wget www.squid-cache.org/Versions/v3/3.2/squid-3.2.7.tar.gztar -zxf squid-3.2.7.tar.gzcd squid-3.2.7./configure --prefix=/opt/squid --enable-ssl --enable-ssl-crtd --with-openssl=/opt/squid/openssl
—enable-ssl — включает поддержку ssl режима
—enable-ssl-crtd — генерацией сертификатов занимается отдельный процесс, а не сам прокси сервер.
—with-openssl — путь куда был установлен кастомный openssl
make allmake install
Так, squid прокси сервер собран.
3. Генерируем self-signed сертификат
Сертификат будет использоваться прокси сервером для создания динамических сертификатов веб сайтов.
cd /opt/squid/etc/openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout squidCA.pem -out squidCA.pem
Так как файл squidCA.pem содержит приватный ключ, делаем его читаемым только для пользователя root:chmod 400 squidCA.pem
4.Настраиваем squid
Добавим следующие строки в squid.conf файл
http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/opt/squid/etc/squidCA.pem
always_direct allow all
ssl_bump allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
данную настройку нежелательно использовать в продукционной системе, так как доступ разрешён на все https сайты с любыми сертификатами.
Подготавливаем кэширование сертификатов:mkdir /opt/squid/var/lib/opt/squid/libexec/ssl_crtd -c -s /opt/squid/var/lib/ssl_dbchown -R nobody /opt/squid/var/lib/ssl_db
Если у вас в настройке cache_effective_user стоит другое UID, то вместо nobody следует использовать его.
Стоит заметить, что если по какой-то причине вы поменяли ваш сертификат для squid’а, то надо полностью очистить каталог /opt/squid/var/lib/ssl_db и заново инициализировать сертификатную базу данных.
Выставляем необходимые права, инициализируем и запускаем прокси сервер:chown -R nobody /opt/squid/var/logs/opt/squid/sbin/squid -z /opt/squid/sbin/squid
проверяем файл /opt/squid/var/logs/cache.log на наличие ошибок, если ошибок нет и имеется строка «Accepting SSL bumped HTTP Socket connections at local=[::]:3128 remote=[::] FD 21 flags=9«, то прокси сервер в режиме SSLBump запущен.
5. пользовательские проблемы
Так как в данном случае мы используем self-signed сертификат, любые посещения https сайтов через прокси будут показывать пользователям ошибку сертификата. Причина ошибки — Issuer нашего сертификата не находится в списке Trusted CA в браузере.
Что бы ошибок не было, выполняем следующее действие.
openssl x509 -in squidCA.pem -outform DER -out squid.der
Теперь полученный файл squid.der надо импортировать в клиентский браузер.
Для Internet Explorer:
Tools->Internet Options->Content->Certificates
Выбираем закладку «Trusted Root Certificate Authorities»
Жмём Import, выбираем файл squid.der и завершаем импорт.
Для Firefox:
Tools->Options->Advanced->Encryption->View Certificates
Выбираем закладку «Authorities»
Жмём Import, выбираем файл squid.der и завершаем импорт.
Ну вот в общем то всё. В зависимости от ваших фантазий, теперь у вас есть возможность в https трафике запретить делать POST запросы, скачивать большие файлы, закрыть доступ к определённым файлам/папкам. Так же можно запретить доступ на сайты, сертификаты которых выданы не доверенными CA. Ну и возможность проверять на вирусы.
Спасибо за внимание,
Использование squid ssl_bump для просмотра содержимого https-трафика
Эта заметка является пошаговой инструкцией для осуществления расшифровки https-трафика и повторного шифрования с целью просмотра (и, при необходимости, фильтрации или изменения) его содержания при условии установки дополнительно корневого(CA) сертификата на конечное устройство. Перехват https-трафика может быть применён в следующих целях:
- анализ действий и высокоуровневая отладка приложений, взаимодействующих с другими хостами(серверами) по https
- реверс-инжиниринг протоколов, работающих поверх https
- фильтрация контента (например, рекламы) на сетевом шлюзе
- отслеживание и ограничение действий пользователей в корпоративных сетях (предотвращение утечек конфиденциальных данных)
- различная незаконная деятельность (кража конфиденциальная данных и т.п.) в условиях, когда конечному пользователю неизвестно об установке дополнительного корневого сертификата на его устройство
В первых трёх случаях мы сами устанавливаем CA-сертификат на своё устройство и делаем это целенаправленно. В четвёртом случае, это делается администраторами корпоративной сети. В последнем же случае CA-сертификат попадает в устройство либо в результате действий вредоносного ПО или путём обмана пользователя, либо производителем самого устройства предустановлено на заводе.
Схема подключения устройств для этой статьи выполнена следующим образом:
Базовая настройка роутера выглядит следующим образом:
– включена маршрутизация (net.ipv4.ip_forward=1)
– на порту eth0 (в сторону LAN-свитча) работает isc-dhcp-server, раздаёт адреса 192.168.1.1-192.168.1.127, ip интерфейса eth0 192.168.1.128, маска сети /24
– через порт eth2 (в сторону Internet) настроено WAN-подключение к интернет-провайдеру, включен iptables SNAT (в случае, если IP-адрес, выдаваемый провайдером динамический, вместо SNAT используется MASQUERADE)
Т.е. роутер в своей базовой конфигурации делает тоже самое, что делают обычные домашние CPE, на просторах интернета есть тысячи инструкций как это настроить.
Для того, чтобы заняться расшифровкой https и повторным шифрованием нужно установить PROXY-сервер SQUID 3.4 (на текущий момент актуальная версия 3.4.10), который умеет работать в прозрачном режиме (в самом деле, в двух прозрачных режимах, но мы будем использовать более простой – intercept). Прописывать прокси-сервер в настройках сетевого подключения на конечных устройствах не придётся.
Чаще всего, в репозиториях популярных дистрибутивов Linux, Squid поставляется без ssl_bump, поэтому его придётся собирать из исходных кодов:
user@router ~ $ wget http://www.squid-cache.org/Versions/v3/3.4/squid-3.4.10.tar.xz user@router ~ $ tar -xf squid-3.4.10.tar.xz user@router ~ $ cd squid-3.4.10/ user@router ~ $ ./configure --prefix=/opt/squid --enable-ssl --enable-ssl-crtd user@router ~ $ make user@router ~ $ sudo make install user@router ~ $ sudo chown nobody /opt/squid/var/logs/ user@router ~ $ sudo mkdir /opt/squid/var/lib user@router ~ $ sudo /opt/squid/libexec/ssl_crtd -c -s /opt/squid/var/lib/ssl_db user@router ~ $ sudo chown -R nobody /opt/squid/var/lib/ssl_db
Генерация CA-сертификата:
user@router ~ $ openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout squidCA.pem -out squidCA.pem Generating a 2048 bit RSA private key ... writing new private key to 'squidCA.pem' ----- ... ----- Country Name (2 letter code) [AU]: State or Province Name (full name) [Some-State]: Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]: Organizational Unit Name (eg, section) []:HOME Common Name (e.g. server FQDN or YOUR name) []:SQUID Email Address []: user@router ~ $ openssl x509 -in squidCA.pem -outform DER -out squidCA.der user@router ~ $ sudo cp squidCA.pem /opt/squid/etc/squidCA.pem
Файл squidCA.pem содержит CA-сертификат и приватный ключ в BASE64-кодировке, файл squidCA.der содержить только CA-сертификат в DER(бинарной) кодировке, этот файл предназначен для импорта конечными устройствами.
Конфигурация /opt/squid/etc/squid.conf:
cache deny all http_access allow all http_reply_access allow all https_port 192.168.1.128:3166 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/opt/squid/etc/squidCA.pem ssl_bump none localhost ssl_bump server-first all sslproxy_cert_error allow all sslproxy_flags DONT_VERIFY_PEER sslproxy_options ALL sslproxy_cipher ALL httpd_suppress_version_string on via off forwarded_for transparent reply_header_access X-Cache deny all reply_header_access X-Cache-Lookup deny all request_header_access Cache-Control deny all
Запуск Squid осуществляется командой “/opt/squid/sbin/squid”, выключение “killall squid” (3 раза). Проверить, что Squid запущен нужно следующим образом:
user@router ~ $ sudo netstat -ntplu | grep squid tcp 0 0 192.168.1.128:3166 0.0.0.0:* LISTEN 7215/(squid-1) udp 0 0 0.0.0.0:50048 0.0.0.0:* 7215/(squid-1) udp6 0 0 :::41916 :::* 7215/(squid-1)
Логи squid хранятся в файлах /opt/squid/var/log/cache.log и /opt/squid/var/log/access.log
На роутере остаётся дело за малым, завернуть https-трафик на локальный SQUID:
user@router ~ $ sudo iptables -t nat -I PREROUTING -p TCP -s 192.168.1.19 --dport 443 -j REDIRECT --to-port 3166 user@router ~ $ sudo iptables -t nat -I PREROUTING -p TCP -s 192.168.1.29 --dport 443 -j REDIRECT --to-port 3166
Для удаления вместо опции -I нужно использовать -D. IP-адреса 192.168.1.19 и .29 принадлежат устройствам PC и Mobile Phone.
Однако, прежде чем перенаправлять трафик на Squid, нужно установить дополнительный корневой сертификат на конечные устройства (файл squidCA.der). Например, для Mac OS X 10.9 это делается с помощью утилиты Keychain Access(File->Import Items, Destination Keychain=login, Always Trust), результат выглядит следующим образом:
Для Android(начиная с 4.0) тоже есть встроенный механизм импорта корневых сертификатов (в версии 4.4 Настройки->Безопасность->Хранилище учётных данных->Установить из памяти(установить сертификаты с носителя)). Результат установки:
В более старых версиях Android возможно добавить свой CA-сертификат в общее хранилище при условии наличия root-привилегий на устройство. Добавление в общее хранилище является более удобным способом, т.к. это не требует установки PIN-кода/пароля на телефон, не появляется предупреждение безопасности при включении устройства.
Теперь запустим браузер(Chrome 39.0.2171.95) на PC и проверим, что осуществляется перехват https-трафика с подменой сертификата:
В некоторых случаях, браузер может отображать устаревшую информацию о сертификате, если вы ранее посещали запрашиваемый сайт (в этом случае можно очистить кеш(не всегда помогает) или запустить браузер с чистым профилем).
Содержимое https-запросов (в зависимости от уровня логирования) можно увидеть в лог-файле access.log Squid-а, но куда более удобный способ анализа – использование Wireshark(запущенный на router). Для того, чтобы расшифровывать трафик, передаваемый в сторону конечных устройств, нужно указать Wireshark-у где находится приватный ключ. Для версии 1.99.2 (development version) настройка осуществляется так: Edit->Preferences->Protocols->SSL->RSA Key List->Edit, далее как на скриншоте:
После чего запустим wireshark на интерфейсе eth0 с capture filter “port 443 and host 192.168.1.29” и посмотрим какие https-запросы отправляются с мобильного телефона на Android-е:
На скриншоте изображено взаимодействие приложения Яндекса.Почта с их сервером посредством https. Кроме этого взаимодействия, был обнаружен ещё такой запрос к одному из серверов Яндекс (IP 213.180.204.58, в поле Host analytics.mobile.yandex.net):
POST /report?deviceid=<удалено>&uuid=<удалено>& analytics_sdk_version=160&client_analytics_sdk_version=160& app_version_name=2.06&app_build_number=9118&os_version=4.4.2& locale=ru-RU& is_rooted=1& api_key=<удалено>&app_id=ru.yandex.mail&app_platform=android&protocol_version=2& model=SM-G900FD&manufacturer=Samsung& screen_width=1920&screen_height=1080&screen_dpi=480&scalefactor=3.0& device_type=phone&android_id=<удалено>&adv_id=
А в самом теле POST-запроса содержится текущий список видимых Wifi-сетей (хотя в системных настройках геолокации разрешено использование только GPS).
Я понимаю зачем им нужны эти данные и даже передача списка wifi-сетей не удивляет, но интересно, зачем Яндекс хочет знать, что мой телефон рутирован? (is_rooted=1)
Like this:
Like Loading…
Related
Дамп SSL траффика средствами Squid
Рылся в интернете и нашел очень интересную статью, посвященную сабжу. Описание, данное там, более чем полное и понятное, а потому не буду ничего менять, а просто приведу всю статью.
Ссылка внизу страницы.
Новые предложения для шифрования и обеспечения безопасности личной информации в социальных сетях могут помочь защитить пользователей, но они также являются головной болью для ИТ и менеджеров по безопасности.
На прошлой неделе Twitter присоединился к Facebook и другим социальным сетям в использовании по умолчанию HTTPS-протокола, чтобы помочь обеспечить неприкосновенность частной жизни пользователей сайта. Многие считают, что нужно благодарить автор FireSheep о включении поддержки HTTPS в список приоритетов социальными сетями.
С новыми настройками HTTPS, миллионы людей теперь могут защитить свои личные — и не очень — публикации от любопытных глаз в самолетах, в кафе или в каких-либо иных местах, где они могут заходить на свои любимые сайты социальных сетей. Сообщество безопасности одобрил действия Facebook по совершению важного шага защите сессий и информации пользователей.
ИТ-организации, с другой стороны, не настолько уверены в новых мерах безопасности. Их первый вопрос: как контролировать входящую и исходящую информацию корпорации, если весь механизм передачи данных зашифрован?
Опасности социальных сетей исследовались и освещались много раз. Действительная ситуация заключается в том, что любой способ перемещения информации из организации в социальную сеть — будь то посредством физической среды, либо личного сообщения, является потенциальной возможностью для утечки информации. Когда эти «возможности» становятся зашифрованными, сотрудники, отвечающие за безопасность, теряют возможность контролировать данные сессии и понимать, что же происходит «за дверью». По существу, повышенная безопасность клиентов на данных веб-сайтах снижает возможности предприятия защитить корпоративную информацию.
Итак, что же делать одинокой фирме, если она хочет защитить корпоративную информацию, но HTTPS-сессии препятствуют ее видимости? Время применить некоторые программы, обеспечивающие видимость.
Если в организации имеется модный коммерческий продукт предотвращающий утечку информации DLP), тогда проверьте его способность обеспечивать защиту конечных точек или интеграцию с веб-прокси. Некоторые DLP продукты дают возможность перехватывать все вызовы браузера в конечной точке и изучать каждую транзакцию. Любая операция будет регулироваться в соответствии с набором правил DLP. К сожалению, все, что хранится в конечной точке, может быть подделано конечным пользователем, злоумышленником или вредоносной программой.
Интеграция с веб-прокси обеспечивает менее навязчивую альтернативу и не полагается на конечную машину, но здесь могут возникнуть проблемы с совместимостью и охватом. Если конечная точка находится за пределами организации, тогда она может не охватываться прокси до тех пор, пока организация не подключит весь удаленный трафик через систему.
Если твоя организация не имеет коммерческого DLP решения, которое может исследовать HTTPS трафик, или какого-то иного способа, все равн существует дополнительная возможность. Применение открытого прокси, такого как Squid, может обеспечить изучение HTTPS трафика – даже если ты не блокируешь запросы в стандартной системе фильтров.
Squid является популярным открытым прокси. Он может быть использован как обратный прокси для входящих соединений или в более традиционной конфигурации для проксирования исходящих соединений. Реализация варьирует в зависимости от сетевой среды, но Squid может находиться в сетевом потоке в целях контроля всего трафика и его захвата через ICAP, или же может быть использован как сетевой анализатор. Не имеет значения, каким образом он реализован, прокси может быть использована для контроля HTTPS-трафика при помощи sslbump.
Использовать sslbump внутри Squid довольно просто, для этого необходимо лишь несколько опций в конфигурации. Для начала http_port должен быть сконфигурирован для использования sslBump, как в следующем примере:
http_port 3128 sslBump cert=/usr/local/squid3/etc/CA-priv+pub.pem
Затем, так как Squid требует обратного прокси, мы должны активировать директиву always_direct.
always_direct allow all
Так как существуют некоторые запросы, которые мы не хотим декодировать при помощи Squid-а – когда пользователи, например, заходят в свои банковские аккаунты, совершают коммерческие операции, заходят на сайты с важной информацией или на те, что не обрабатываются sslbump надлежащим образом – мы можем использовать команды ssl_bump и acl в целях предотвращения распространения подобного процесса на другие сайты.
acl broken_sites dstdomain .example.com ssl_bump deny broken_sites ssl_bump allow all
В самом простом виде эти команды помогают системе создать список broken_sites, который не обрабатывается надлежащим образом sslbump. Если сайт не входит в список broken_sites, тогда система разрешит обработку ssl_bump.
Теперь у тебя должен быть полностью готовый к использованию Squid, который сможет обрабатывать HTTPS-запросы. Используй открытые плагины — такие как SquidGuard и ClamAV — для контроля трафика.
HTTPS представляет огромный шаг вперед для пользователей веб-сайтов, а также их безопасности, но это также может быть огромной проблемой для команд, отвечающих за безопасность, предпринимающих попытки по предотвращению утечки информации через социальные сети. Существует множество путей для решения этой проблемы. Оцени инфраструктуру, определи потребности и выбери то, что в наибольшее степени подходит твоей сети.
Ссылка на статью: http://www.xakep.ru/post/55161/
Как увидеть полный URL при HTTPS через ssl_bump? — Хабр Q&A
Занялся тут настройкой ssl_bump на конторском прокси. Прочитал множество документации в тырнете. Что-то даже настроил. Но нет понимания.
Вопросов два:
Первый и самый главный — ssl_bump позволит мне видеть URL так, как он виден по HTTP?
Второй — почему собственно bump не работает? 🙂
Конфиг такой:
http_port 10.87.1.39:8080 ssl-bump cert=/etc/pki/tls/certs/logsrv_subca.crt key=/etc/pki/tls/private/logsrv_subca.key cipher=kEECDH+AES:kEDH+AES:kRSA+AES:!aNULL:!DSS:!SSLv2 options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE,SINGLE_ECDH_USE cafile=/etc/pki/tls/certs/ca-bundle.trust.crt dhparams=/etc/pki/tls/private/dhparams.pem tls-dh=prime256v1:/etc/pki/tls/private/dhparams.pem
sslproxy_client_certificate /etc/pki/tls/certs/logsrv_client.crt
sslproxy_client_key /etc/pki/tls/private/logsrv_client.key
sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
sslproxy_cipher kEECDH+AES:kEDH+AES:kRSA+AES:!aNULL:!DSS:!SSLv2
sslproxy_cafile /etc/pki/tls/certs/ca-bundle.trust.crt
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all
#ssl_bump splice all
sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MBОн вполне возможно крив, потому что вот в таком виде не работает нифига — при обращении на банальный гугл все виснет. Работать начинает только когда вместо bump all ставишь splice all.
UPD: Тестирование браузеров на «вшивость». Тестирование проводилось заходом на vk.com через прокси с bump.
FF — Не замечает ваще нифига. Спокойно рисует «зеленый замочек». Можно просмотреть сертификат.
Хром — Значок незащищенного соединения. Сертификат просмотреть нельзя.
Опера — Значок незащищенного соединения. Можно посмотреть сертификат.
ЯБ — Предупреждение во весь экран! Единственный браузер, который углядел, что его дурют и сертификат на vk.com выдан каким-то там logsrv 😀 Если предупреждение проигнорировать, то сообщает, что это не особо защищенное соединение, так как используется сертификат подписанный SHA-1
Squid фильтрация https без подмены сертификатов. Как решить проблему с ssl3? — Хабр Q&A
OS: Debian 8.2 jessie
squid: 3.5.8 — с поддержкой ssl
openssl: 1.0.1k
Squid собирал следующим образом:
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
vim /etc/apt/sources.list
# deb-src http://ftp.de.debian.org/debian/ testing main contrib non-free
apt-get update
apt-get source squid3/testing
apt-get source libecap3/testing
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
links squid-cache.org
cd squid3-3.5.7/
uupdate -v 3.5.8 ../squid-3.5.8.tar.gz
cd ../squid3-3.5.8/
vim debian/rules
# --enable-ssl
# --enable-ssl-crtd
# --with-openssl
dpkg-buildpackage -us -uc -nc
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.debiptables.sh
iptables -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -A FORWARD -i eth0 -o eth2 -j ACCEPT
iptables -A FORWARD -i eth2 -o eth0 -j ACCEPT
iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 443 -j REDIRECT --to-port 3129Пользуюсь методом Peek and Splice.
Info: SSL Peek and Splice
squid.conf
acl localnet src 192.168.15.0/24
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
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_port 192.168.15.237:3128 transparent
acl blacklist url_regex -i "/etc/squid/blacklist"
http_access deny blacklist localnet
http_access allow localnet
https_port 192.168.15.237:3129 intercept ssl-bump connection-auth=off options=ALL cert=/etc/squid/squidCA.pem
always_direct allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
ssl_bump peek all
acl blocked ssl::server_name .vk.com .google.ru .google.com
ssl_bump terminate blocked
ssl_bump splice all
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 .Squid прекрасно работает и блокирует vk и google.
Однако, если выполнить curl --sslv3 https://ya.ru, то клиент curl зависает, а squid выдаёт ошибку.
cache.log
root@gate:~# tail -f /var/log/squid/cache.log
2015/09/19 10:02:08 kid1| HTCP Disabled.
2015/09/19 10:02:08 kid1| Pinger socket opened on FD 16
2015/09/19 10:02:08 kid1| Squid plugin modules loaded: 0
2015/09/19 10:02:08 kid1| Adaptation support is off.
2015/09/19 10:02:08 kid1| Accepting NAT intercepted HTTP Socket connections at local=192.168.15.237:3128 remote=[::] FD 13 flags=41
2015/09/19 10:02:08 kid1| Accepting NAT intercepted SSL bumped HTTPS Socket connections at local=192.168.15.237:3129 remote=[::] FD 14 flags=41
2015/09/19 10:02:08| pinger: Initialising ICMP pinger ...
2015/09/19 10:02:08| pinger: ICMP socket opened.
2015/09/19 10:02:08| pinger: ICMPv6 socket opened
2015/09/19 10:02:09 kid1| storeLateRelease: released 0 objects
2015/09/19 10:02:27 kid1| Error negotiating SSL on FD 15: error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol (1/-1/0)Вопрос: Как подружить squid и ssl3 ?
UPDATE_1: Проблема решена, рабочая версия конфига:
acl localnet src 192.168.15.0/24
acl trustedman src 192.168.15.1
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
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_port 192.168.15.237:3128 transparent
acl blacklist url_regex -i "/etc/squid/blacklist"
http_access deny blacklist localnet
http_access allow localnet
https_port 192.168.15.237: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
acl blocked ssl::server_name .vk.com .google.ru .google.com
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump terminate blocked !trustedman
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% 4320Squid3 в режиме SSLBump с динамической генерацией сертификатов / Хабр
Приветствую.
Шифрованный веб-трафик вещь хорошая, но порой совершенно не ясно, что пользователь там, внутри, делает. При заходе на любой https-ресурс через squid, в логи записывается достаточно строк подобного вида:
1330231066.104 10 172.26.27.8 TCP_MISS / 200 390 CONNECT mail.google.com:443 — HIER_DIRECT / 173.194.32.54 —
133024 TCP1192.883 9 177.26.26.2 / 200 390 ПОДКЛЮЧИТЬся к mc.yandex.ru:443 — HIER_DIRECT / 213.180.193.119 —
Видно, что в определенное время пользователи зашли на Gmail и яндекс. В принципе вот и всё что мы видим из логов. Но не понятно выполнялся ли ПОЛУЧИТЬ или ОПУБЛИКОВАТЬ запрос, не видно полных урлов, ни размеров файлов. Так же нет возможности проверить ssl трафик антивирусной программой другими программами проверки содержимого.
В этой статье я хочу описать возможность squid’а «разламывать» ssl-соединение и иметь хоть какой-то обзор происходящего в https трафике.
Так как на CentOS стоит «усиленный» openssl, то сборка squid’а c необходимыми нам ключам не получается.
Есть два варианта решения данной проблемы.
Первый — это установлен лезть в инклюд файлы openssl, потом в исходники сквида и менять некоторые строки. И второй — это собирать сквид с кастомным openssl.
Первый вариант слишком хардкорный и оставим его в стороне.
1. openssl
Итак, для начала нам надо собрать свой openssl. Тут всё довольно просто и никакой магии:
wget www.openssl.org/source/openssl-1.0.0k.tar.gz
tar -zxf openssl-1.0.0k.tar.gz
cd openssl-1.0.0k
Что бы не было конфликтов с уже установленной версией openssl, указываем новый путь:
./config shared --prefix = / opt / squid / openssl --openssldir = / opt / squid / openssl
сделать
сделать установить
Всё, openssl собран и готов к использованию.
2. кальмар
Сборка прокси сервера аналогична сборке любой программы (configure && make && make install), единственное указание определенных ключей при компиляции:
wget www.squid-cache.org/Versions/v3/3.2/squid-3.2.7.tar.gz
tar -zxf squid-3.2.7.tar.gz
cd squid-3.2.7
./ configure --prefix = / opt / squid --enable-ssl --enable-ssl-crtd --with-openssl = / opt / squid / openssl
—enable-ssl — включает поддержку ssl режима
—enable-ssl-crtd — генерации сертификатов отдельный процесс, а не сам прокси-сервер.
—with-openssl — путь куда был установлен кастомный openssl
сделать все
сделать установить
Так, squid прокси сервер собран.
3. Генерируем самоподписанный сертификат
Сертификат будет работать прокси сервером для создания динамических сертификатов веб сайтов.
cd / opt / squid / etc /
openssl req -new -newkey rsa: 1024 -days 365 -nodes -x509 -keyout squidCA.pem -out squidCA.pem
Так как файл squidCA.pem содержит приватный ключ, делаем его читаемым только для пользователя root:
chmod 400 squidCA.pem
4.Настраиваем squid
Добавим следующие строки в кальмар.conf файл
http_port 3128 ssl-bump generate-host-Certific = on dynamic_cert_mem_cache_size = 4MB cert = / opt / squid / etc / squidCA.pem
always_direct разрешить все
ssl_bump разрешить все
sslproxy_cert_error разрешить все
sslproxy_flags DONT_VERIFY_PEER
нет настроек нежелательно использовать в продукционной системе, как доступ разрешен на все https сайты с любыми сертификатами.
Подготавливаем кэширование сертификатов:
mkdir / opt / squid / var / lib
/ opt / squid / libexec / ssl_crtd -c -s / opt / squid / var / lib / ssl_db
chown -R nobody / opt / сквид / вар / библиотека / ssl_db
Если у вас в настройке cache_effective_user стоит другой UID, то вместо никто не следует использовать его.
Стоит заметить, что если по какой-то причине вы поменяли ваш сертификат для squid’а, то надо полностью очистить каталог / opt / squid / var / lib / ssl_db и заново инициализировать сертификатную базу данных.
Выставляем необходимые права, инициализируем и запускаем прокси-сервер:
chown -R nobody / opt / squid / var / logs
/ opt / squid / sbin / squid -z
/ opt / squid / sbin / кальмар
проверяем файл / opt / squid / var / logs / cache.log на наличие ошибок, если ошибок нет и имеется строка « Принятие SSL bumped HTTP Socket-соединений на local = [::]: 3128 remote = [::] FD 21 flags = 9 «, то запущен прокси-сервер в режиме SSLBump.
5. пользовательские проблемы
Так как в данном случае мы используем самоподписанный сертификат, любые посещения https сайтов через прокси будут показывать пользователям ошибку сертификата. Причина ошибки — Издатель нашего сертификата не находится в списке доверенных центров сертификации в браузере.
Что бы ошибок не было, выполняем следующее действие.
openssl x509 -in squidCA.pem -outform DER -out squid.der
Теперь полученный файл squid.der надо импортировать в клиентский браузер.
Для Internet Explorer:
Инструменты-> Свойства обозревателя-> Содержимое-> Сертификаты
Выбираем закладку «Доверенные корневые центры сертификации»
Жмём Import, выбираем файл squid.der и завершаем импорт.
Для Firefox:
Инструменты-> Параметры-> Дополнительно-> Шифрование-> Просмотр сертификатов
Выбираем закладку «Власти»
Жмём Import, выбираем файл squid.der и завершаем импорт.
Ну вот в общем то всё. В зависимости от ваших фантазий, теперь у вас есть возможность в https трафике запретить выполнять запросы POST, скачивать большие файлы, закрыть доступ к определенным файлам / папкам. Так же можно запретить доступ на сайты, сертификаты выданы не доверенными CA. Ну и возможность проверять на вирусы.
Спасибо за внимание,
.
Использование squid ssl_bump для просмотра содержимого https-traffic
Этака является пошаговой инструкцией для осуществления расшифровки https-трафика и повторного шифрования с целью просмотра (и, при необходимости, фильтрации или изменения) его содержания при установке корневого (CA) сертификата на конечное устройство. Перехват https-трафика может быть применён в следующих целях:
- анализ действий и высокоуровневая отладка приложений, взаимодействующих с другими хостами (серверами) по https
- реверс-инжиниринг протоколов, работающих поверх https
- фильтрация контента (например, рекламы) на сетевом шлюзе
- отслеживание и ограничение действий пользователей в корпоративных сетях (предотвращение утечек конфиденциальных данных)
- конфиденциальная незаконная деятельность (кража конфиденциальная данных и т.п.) в условиях, когда конечному пользователю неизвестно об установке дополнительного корневого сертификата на его устройство
В первых трёх случаях мы сами устанавливаем CA-сертификат на своё устройство и делаем это целенаправленно. В четвёртом случае, это протоколми корпоративной сети. В результате вредоносного ПО или путём обмана пользователя, либо самого устройства, предустановленного на заводе, произойдет самое заражение CA-сертификат.
Схема подключения устройств для этой статьи выполнена следующим образом:
Базовая настройка роутера следующим образом:
— включена маршрутизация (net.ipv4.ip_forward = 1)
— на порту eth0 (в сторону LAN-свитча) работает isc-dhcp-server, раздаёт адрес 192.168.1.1-192.168.1.127, ip интерфейса eth0 192.168.1.128, маска сети / 24
— через порт eth2 (в сторону Интернет) настроено WAN-подключение к адресу интернет-провайдеру, включен iptables SNAT (в случае, если IP-адрес, выдаваемый провайдером динамический, вместо SNAT используется MASQUERADE )
Т.е. роутер в своей конфигурации делает тоже самое, что делают обычные домашние CPE, на просторах интернета есть тысячи как это настроить.
Для того, чтобы заняться расшифровкой https и повторным шифрованием нужно установить PROXY-сервер SQUID 3.4 (на текущий момент актуальная версия 3.4.10), который умеет работать в прозрачном режиме (в самом деле, в двух прозрачных режимах, но мы будем использовать более простой — перехват). Прописывать прокси-сервер в настройках сетевого подключения на конечных устройствах не придётся.
Чаще всего, в репозиториях популярных дистрибутивов Linux, Squid поставляется без ssl_bump, поэтому его придётся собирать из исходных кодов:
пользователь @ маршрутизатор ~ $ wget http://www.squid-cache.org/Versions/v3/3.4/squid-3.4.10.tar.xz пользователь @ маршрутизатор ~ $ tar -xf squid-3.4.10.tar.xz пользователь @ маршрутизатор ~ $ cd squid-3.4.10 / пользователь @ маршрутизатор ~ $ ./configure --prefix = / opt / squid --enable-ssl --enable-ssl-crtd пользователь @ маршрутизатор ~ $ make пользователь @ маршрутизатор ~ $ sudo make install пользователь @ маршрутизатор ~ $ sudo chown никто / opt / squid / var / logs / пользователь @ маршрутизатор ~ $ sudo mkdir / opt / squid / var / lib пользователь @ маршрутизатор ~ $ sudo / opt / squid / libexec / ssl_crtd -c -s / opt / squid / var / lib / ssl_db пользователь @ маршрутизатор ~ $ sudo chown -R никто / opt / squid / var / lib / ssl_db
Генерация CA-сертификата:
user @ router ~ $ openssl req -new -newkey rsa: 2048 -days 3650 -nodes -x509 -keyout squidCA.pem -out squidCA.pem Создание 2048-битного закрытого ключа RSA ... запись нового закрытого ключа в "squidCA.pem" ----- ... ----- Название страны (двухбуквенный код) [AU]: Название штата или провинции (полное название) [Some-State]: Название населенного пункта (например, город) []: Название организации (например, компания) [Internet Widgits Pty Ltd]: Название организационной единицы (например, раздел) []: HOME Общее имя (например, полное доменное имя сервера или ВАШЕ имя) []: SQUID Адрес электронной почты []: user @ router ~ $ openssl x509 -в squidCA.pem -outform DER -out squidCA.der пользователь @ маршрутизатор ~ $ sudo cp squidCA.pem /opt/squid/etc/squidCA.pem
Файл squidCA.pem содержит CA-сертификат и приватный ключ в BASE64-кодировке, файл squidCA.der содержит только CA-сертификат в DER (бинарной) кодировке, этот файл предназначен для импорта конечными устройствами.
Конфигурация /opt/squid/etc/squid.conf:
кеш запретить все http_access разрешить все http_reply_access разрешить все https_port 192.168.1.128: 3166 перехват ssl-bump generate-host-Certific = on dynamic_cert_mem_cache_size = 4MB cert = / opt / squid / etc / squidCA.pem ssl_bump нет localhost ssl_bump server-first all sslproxy_cert_error разрешить все sslproxy_flags DONT_VERIFY_PEER sslproxy_options ВСЕ sslproxy_cipher ВСЕ httpd_suppress_version_string на через выкл forwarded_for прозрачный reply_header_access X-Cache запретить все reply_header_access X-Cache-Lookup запретить все request_header_access Cache-Control запретить все
Запуск Squid осуществляется командой «/ opt / squid / sbin / squid», выключение «killall squid» (в 3 раза).Проверить, что Squid запущен следующим образом:
пользователь @ маршрутизатор ~ $ sudo netstat -ntplu | grep squid tcp 0 0 192.168.1.128:3166 0.0.0.0:* СЛУШАТЬ 7215 / (squid-1) UDP 0 0 0.0.0.0:50048 0.0.0.0:* 7215 / (кальмар-1) udp6 0 0 ::: 41916 ::: * 7215 / (кальмар-1)
Логи squid хранятся в файлах / opt / squid / var / log / cache.журнал и /opt/squid/var/log/access.log
На роутере остаётся дело за малым, завернуть https-трафик на локальный SQUID:
пользователь @ маршрутизатор ~ $ sudo iptables -t nat -I PREROUTING -p TCP -s 192.168.1.19 --dport 443 -j REDIRECT --to-port 3166 пользователь @ маршрутизатор ~ $ sudo iptables -t nat -I PREROUTING -p TCP -s 192.168.1.29 --dport 443 -j REDIRECT --to-port 3166
Для удаления вместо опции -I нужно использовать -D. IP-адреса 192.168.1.19 и .29 принадлежащих устройствам PC и Mobile Phone.
Прежде чем перенаправлять трафик на Squid, нужно установить дополнительный сертификат на конечное устройство (файл squidCA.der). Например, для Mac OS X 10.9 это делается с помощью утилиты Keychain Access (File-> Import Items, Destination Keychain = login, Always Trust), результат выглядит следующим образом:
Для Android (начиная с 4.0) тоже есть встроенный механизм импорта корневых сертификатов (в версии 4.4 Настройки-> Безопасность-> Хранилище учётных данных-> Установить из памяти (установить сертификаты с носителя)).Результат установки:
В более старых версиях Android можно добавить свой CA-сертификат в общее хранилище при условии наличия корневых привилегий на устройстве. Добавление в хранилище сообщений более активно, т.к. это не требует установки PIN-кода / пароля на телефон, не предупреждает безопасность при включении устройства.
Теперь запустим браузер (Chrome 39.0.2171.95) на ПК и проверим, что выполняется перехват https-трафика с подменой сертификата:
В некоторых случаях браузер может отображать устаревшую информацию о сертификате, если вы ранее посещали запрашиваемый сайт (в этом случае можно очистить кеш (не всегда помогает) или запустить браузер с чистым профилем).
Содержимое https-запросов (в зависимости от уровня логирования) можно увидеть в лог-файле access.log Squid-а, но куда более удобный способ анализа — Wireshark (запущенный на маршрутизаторе). Для того, чтобы расшифровывать трафик, передаваемый в сторону конечных устройств, нужно указать Wireshark-у где находится приватный ключ. Для версии 1.99.2 (разрабатываемая версия) настройка осуществляется так: Edit-> Preferences-> Protocols-> SSL-> RSA Key List-> Edit, далее как на скриншоте:
После чего запустим wirehark в интерфейсе eth0 с фильтром захвата «порт 443 и хост 192.168.1.29 ”и посмотрим какие https-запросы отправляются с мобильного телефона на Android-е:
На скриншоте изображено взаимодействие приложения Яндекса.Почта с их сервером посредством https. Кроме этого взаимодействия, был обнаружен ещё такой запрос к одному из серверов Яндекс (IP 213.180.204.58, в поле Host analytics.mobile.yandex.net):
POST / report? Deviceid = <удалено> & uuid = <удалено> & analytics_sdk_version = 160 & client_analytics_sdk_version = 160 & app_version_name = 2.06 & app_build_number = 9118 & os_version = 4.4.2 & locale = ru-RU & is_rooted = 1 & api_key = <удалено> & app_id = ru.yandex.mail & app_platform = android & protocol_version = 2 & модель = SM-G900FD & производитель = Samsung & screen_width = 1920 & screen_height = 1080 & screen_dpi = 480 & scalefactor = 3.0 & device_type = phone & android_id = <удалено> & adv_id =
А в самом теле POST-запрос находится текущий список Wifi-сетей (хотя в настройках геолокации разрешено использование только GPS).
Я понимаю зачем им нужны эти данные и даже передача списка wifi-сетей не удивляет, но интересно, зачем Яндекс хочет знать, что мой телефон рутирован? (is_rooted = 1)
Нравится:
Нравится Загрузка …
Связанные
.
Дамп SSL траффика средств Squid
Рылся в интернете и нашел очень интересную статью, посвященную сабжу. Описание, данное там, более чем полное и понятное, а потому не буду ничего менять, а просто приведу всю статью.
Ссылка внизу страницы.
Новые предложения для шифрования и обеспечения безопасности личной информации в системе безопасности пользователей, но они также являются головной болью для ИТ и менеджеров по безопасности.
На прошлой неделе Twitter присоединился к Facebook и другим социальным сетям в использовании по умолчанию HTTPS-протокол, чтобы помочь обеспечить безопасность частной жизни пользователей сайта.Многие считают, что нужно благодарить автор FireSheep о включении поддержки HTTPS в список приоритетов социальными сетями.
С новыми настройками HTTPS, миллионы людей теперь могут защитить свои личные — и не очень — публикации от любопытных глаз в самолетах, в кафе или в каких-либо других местах, где они могут заходить на свои любимые сайты социальных сетей. Сообщество безопасности одобрил действия Facebook по совершению важного шага защиты сессий и информации.
ИТ-организации, с другой стороны, не уверены в новых мерах безопасности.Их первый вопрос: как контролировать входящую и исходящую информацию корпорации, если весь механизм передачи данных зашифрован?
Опасности социальных сетей исследовались и освещались много раз. Действующая информация заключается в том, что любым способом передачи информации из организации в социальной сети — будь то посредством физической среды, либо личным сообщением, потенциальной возможностью для утечки информации. Когда эти «возможности» становятся зашифрованными, сотрудники, отвечающие за безопасность, теряют возможность контролировать данные и понимать, что же происходит «за дверью».По существу, повышенная безопасность клиентов на веб-сайтах снижает возможности защиты корпоративной информации.
Итак, что же делать одинокой фирме, если она хочет защитить корпоративную информацию, но HTTPS-препятствия ее видимости? Время применить некоторые программы, обеспечивающие видимость.
Если имеется модный коммерческий продукт, предотвращающий утечку информации DLP), тогда проверьте его способность защиты конечных точек или интеграцию с веб-прокси.Некоторые DLP продукты дают возможность перехватывать все вызовы в конечной точке и изучать каждую транзакцию. Любая операция будет регулироваться в соответствии с набором правил DLP. К сожалению, все, что хранится в конечной точке, может быть подделано конечным пользователем, злоумышленником или программной программой.
Интеграция с веб-прокси обеспечивает менее навязчивую альтернативу и не полагается на конечную машину, но здесь возникают проблемы с совместимостью и охватом.Если конечная точка находится за пределами, тогда она может не охватываться прокси до тех пор, пока организация не подключит весь удаленный трафик через систему.
Если твоя организация не имеет коммерческих решений DLP, которое может использовать HTTPS-трафик, или какого-то исследователя, все равн дополнительная возможность. Применение открытого прокси, такого как Squid, может обеспечить изучение HTTPS-трафика — даже если ты не блокируешь запросы в стандартной системе фильтров.
Squid является популярным открытым прокси. Он может быть использован как обратный прокси для входящих соединений или в более традиционной конфигурации для проксирования исходящих соединений. Реализация алгоритмов в зависимости от сетевой среды, но Squid может находиться в сетевом потоке в целях контроля всего трафика и его захвата через ICAP, или же может быть использован как сетевой анализатор. Не значения, каким образом он реализован, прокси может быть использован для контроля HTTPS-трафика при помощи sslbump.
Использовать sslbump внутри Squid довольно просто, для этого необходимо лишь несколько опций в конфигурации. Для начала http_port должен быть сконфигурирован для использования sslBump, как в следующем примере:
http_port 3128 sslBump cert = / usr / local / squid3 / etc / CA-priv + pub.pem
Затем, так как Squid требует обратного прокси. , мы должны активировать директиву always_direct.
always_direct разрешить все
Так как существуют некоторые запросы, которые мы не хотим декодировать при помощи Squid-а — когда пользователи, например, заходят в свои банковские аккаунты, совершают коммерческие операции, заходят на сайты с использованием информации или на те , что не обрабатываются sslbump надлежащим образом — мы можем использовать команды ssl_bump и acl в целях распространения подобного процесса на другие сайты.
acl broken_sites dstdomain .example.com ssl_bump deny broken_sites ssl_bump разрешить все
В самом простом виде эти команды помогают создать список broken_sites, который не обрабатывается надлежащим образом sslbump. Если сайт не входит в список broken_sites, тогда система разрешит обработку ssl_bump.
Теперь у тебя должен быть полностью готовый к использованию Squid, который сможет обрабатывать HTTPS-запросы. Используй открытые плагины — такие как SquidGuard и ClamAV — для контроля трафика.
HTTPS представляет огромный шаг вперед для пользователей веб-сайтов, а также их безопасности, но это также может быть огромной проблемой для команд, отвечающих за безопасность, предпринимающих попытки по предотвращению утечки информации через социальные сети. Существует множество путей для решения этой проблемы. Оцените инфраструктуру, определи потребности и выбери то, что в наивысшей степени подходит твоей сети.
Ссылка на статью: http://www.xakep.ru/post/55161/
.