Продолжая тему нюансов SSL, в данной статье я расскажу как автоматически исключать сервера, запрещающие вклинивание в SSL сессию, из политики расшифрования. Чтобы автоматически добавлять новые исключения SSL, я использовал механизм auto-tagging.
Что нужно сделать
1. Создать динамическую группу адресов, этот функционал называется Dynamic Address Group (DAG).
1. Создать динамическую группу адресов, этот функционал называется Dynamic Address Group (DAG).
2. Стартовать процесс тегирования каждого IP адреса сервера: этот функционал автоматизации находится в Log Forwarding Profile. И эти IP станут автоматически попадать в этот DAG.
3. Создать правило исключения из расшифрования всех адресов из этого DAG.
Как правильно говорить SSL или TLS?
Название протокола SSL придумала фирма Netscape для описания шифрования данных идущих из внешних серверов. Термин SSL был изменен на TLS для того, чтобы подчеркнуть открытый характер стандарта, благодаря чему кто угодно мог использовать его в своих проектах, и тем самым отделить его от фирменного продукта компании. Кроме того, протокол TLS разрабатывался как протокол, независимый от приложений, тогда как SSL изначально планировалось использовать только для подключений HTTP. Оба термина правильные. SSL термин прижился и используется чаще всего, хотя технологически уже давно в сетях это протокол TLS. Также как слово ксерокс прижилось и используется до сих пор, хотя копировать документы научилась не только компания Xerox. Буду использовать далее SSL, понимая, что это все семейство протоколов всех версий SSL и TLS.
Какие приложения используют SSL?
Внутри SSL может быть не только HTTP трафик, а SMTP, POP3 или FTP, и другие, там передаются любые данные, нужные приложениям: мессенджерам, обновлениям, базам данных, видеоконференциям. Браузеры используют две версии HTTP/1 и HTTP/2 - они серьезно отличаются друг от друга и их нужно по-разному обрабатывать в средствах защиты. Если мы говорим про вскрытие SSL, то важно наличие движка определения и разбора приложений. Если кто-то говорит, что L4 firewall может вскрывать SSL и что-то там видеть, то это от незнания, что SSL используется разными приложениями. Сейчас уже несколько тысяч различных приложений используют SSL на 443 порту и их надо уметь различать, чтобы защищать компанию от угроз. Если ваше устройство вскрывает SSL на 443 порту и ожидает там HTTP/1, а там HTTP/2 или FTP, то оно просто разрушит работу приложения или не сможет его проанализировать.
Постановка задачи и в чем проблема с расшифрованием SSL
Реализация SSL Decrypt выглядит как хакерская атака категории Man In The Middle (MITM), то есть производится подмену настоящих ключей шифрования и сертификата сервера. Когда вы включаете расшифрование трафика SSL в своей сети, то вы обнаружите, что далеко не все серверы согласны на такое жесткое вмешательство в SSL сессию. Приложения перестают работать, когда вы пытаетесь делать для них атаку "человек посередине" (MITM). И это единственный способ "вскрыть" SSL трафик между клиентом и сервером и получить открытый трафик и отправить на анализ в application control, антивирус, IPS, URL фильтр, Threat Intelligence, DLP и песочницу и другие движки анализа угроз.
Поэтому в каждом устройстве нужно вести список серверов, которые против и отключать функции расшифрования SSL для всех таких сервисов. Что это за сервера: почти все мессенджеры, например, whatsapp, все обновления, например, Microsoft Update, все вебинары, например, gotomeeting и почти все обновления у программ и так далее.
Список сервисов, которые нужно исключать из расшифрования SSL, чтобы они не ломались, уже заложен в NGFW Palo Alto Networks, и выглядит так:
Однако, ведение этого списка - это очень непростое занятие: сотрудников много, сервисов, которые защищают себя от расшифрования все больше. Да, часть сервисов уже добавлены в исключения, но, их больше и постоянно появляются новые.
Как автоматически исключать сервера SSL, с которыми не работает расшифрование? Нужно вести свой список таких серверов. Этими списками URL, IP и DNS можно обмениваться используя механизм внешних список EDL.
Подробнее мы рассказывали в этом видео:
Dynamic Address Group (DAG)
В наших сетях постоянно возникают и исчезают различные новые объекты и одновременно меняются свойства старых объектов: система виртуализации может сама запускать новые веб сервера, старые сервисы могут начать работать ошибочно, сотрудники могут вдруг заразиться и нам нужно вовремя их поместить в карантин. Изменения среды происходит круглосуточно и менять правила доступа межсетевого экрана нужно круглосуточно. Если у вас есть круглосуточная дежурная смена или даже Security Operation Center, то это выполнимо. Но сейчас век автоматизации. Чтобы межсетевой экран сам автоматически менял правила в зависимости от каких-то событий в сети, используйте объект Dynamic Address Group или Dynamic User Groups. Его плюсом является то, что он пополняется объектами без необходимости сохранения конфигурации (не нужно делать commit). Это отличает DGA от обычных статических групп объектов.
В данный объект попадают IP адреса, которые обладают каким-то свойством. Это свойство может пропадать или появляться у IP адреса и соответственно IP адрес то попадает, то исчезает из этого динамического объекта. Чтобы описать новое свойство, мы приписываем IP адресу специальный тег. У каждого IP адреса может быть до 32 тегов (свойств).
Например, у вас стартовал новый WEB сервер, система виртуализации, оповещает межсетевой экран, что еще один IP адрес в сети стал веб-сервером и правило для доступа к веб-серверам начинает работать для этого нового IP адреса. Что удобно, администраторы не участвуют, все происходит само. Новый доступ прописывается сам. Такая возможность интеграции с тегами VMWare есть у Palo Alto Networks https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/policy/monitor-changes-in-the-virtual-environment/enable-vm-monitoring-to-track-changes-on-the-virtual-network.html
Второй пример. Если мы обнаруживаем, что в сети появился компьютер, который начал подключаться к бот-сети, то очевидно, что он заражен. Чтобы остановить распространение вредоносного кода, мы блокируем доступ этому сотруднику к сети, оповещаем его, что ему требуется вылечить свой компьютер для дальнейшей работы в сети компании. Это также может быть и домашний компьютер сотрудника, который подключился в сети по VPN.
Пример с помещением сотрудника в карантин после его заражения хорошо описан в видеоролике https://www.youtube.com/watch?v=SaknKHwdnCI&t=619s
Кстати, в этом примере показано не только как IP адресу назначается новый тег, но и как тег убирать после того как сотрудник вылечил компьютер, используя реакцию override в профиле URL.
Я использовал на межсетевом экране политику для выключения расшифрования SSL, используя объект DAG и сейчас про это расскажу.
Попытка расшифровывать трафик с Яндекс.Станции
В моем случае испытуемым объектом является Яндекс.Станция (Алиса). По сути это яркий представитель Интернета Вещей (IoT). Я попробовал включить расшифрование SSL для соединений, которые делает Яндекс.Станция. И обнаружил, что она просто перестает работать. Поскольку Алиса делает очень много подключений по SSL, и против расшифрования, то мне надо было добавить ее в исключения. И мне было интересно, все ли SSL соединения мне надо исключать или часть из них я смогу расшифровать.
Как работает расшифрование.
Когда Алиса подключается к своему серверу, то NGFW перехватывает соединение и начинает работать как прокси-сервер для SSL. И этот режим таки называется: forward proxy.
NGFW подключается к серверу Яндекса, получает от него сертификат и проверяет его подпись, то есть проверяет можно ли ему доверять.
Для самой Алисы NGFW отдает свой сертификат (я его сгенерировал и сделал самоподписанным), говоря что он Яндекс и подписывает это встроенным своим сертификатом. Поскольку Алиса тоже проверяет сертификат, а доверия самоподписанному сертификату от NGFW нет, то она отказывается работать. Так работает много приложений и это справедливо.
Поскольку загрузить свой сертификат в Алису у меня нет возможности, то доверять сертификату она не будет никогда. Нужно добавлять в исключения. Как это добавить вручную показано в видеролике ниже:
Как автоматизировать добавление исключений для SSL
1. Сначала нужно создать тег, который мы будем привязывать к IP адресу.
Заходим в Objects->Tags-Add
Name: SSL-Bypass (любой текст несущий какой-то смысл для вас)
Color: Lime (любой цвет, который вам нравится)
Comments: (любой текст, который вы хотите написать, чтобы потом вспомнить зачем вы завели этот тег)
2. Создадим сам объект. Зайдем в Objects->Address Groups и создадим динамический объект.
Name: Tagged2Bypass (любое имя удобное для вас)
Description: Любой понятный текст
Type: Dynamic
Match: ‘SSL-Bypas’ - можно вбить руками, можно использовать кнопку Add Match Criteria.
Слева появился список всех доступных тегов. В это поле можно вписать логические операции «И» или «ИЛИ», чтобы добавлять только IP адреса, которые соответствую сразу всем перечисленным тегам одновременно (операция И) или хотя бы одному из них (операция ИЛИ)
Мы создали объект Tagged2Bypass, и теперь все IP адреса с тегом SSL-Bypass будут автоматически в этом объекте.
Нам осталось разобраться как же добавлять теги автоматически, в случае ошибки расшифрования SSL. И тут мы будем использовать еще одну функцию межсетевого экрана: автоматическое тегирование.
Log Forwarding Profile и auto-tagging
И это самое сложное и одновременно самое интересное место повествования.
Посмотрите на журнал трафика на скриншоте ниже. Посмотрите в колонку Session End Reason. В журнале трафика каждая запись содержит причину, по которой L4 сессия или сессия приложения L7 была завершена. Если в журнале событий появляется событие связанное с ошибкой SSL, то это значит, что клиент не смог подключиться к своему SSL серверу. Посмотрите на скриншоте: это ошибки decrypt-error, decrypt-cert-validation, decrypt-unsupport-param.
По-хорошему, в любой компании надо заводить кейс под каждую таку строчку, разбираться с ошибкой, но у меня не стоит такой задачи. Пусть эти ошибки будут критерием для добавления в исключение SSL.
Чтобы сервис доступа по SSL заработал, мне нужно автоматически выключить расшифрование SSL для данного Destination IP. И это адрес тоже указан в этой же записи журнала.
На межсетевом экране Palo Alto Networks есть сервис автоматического реагирования на события. Правила реагирования находятся в разделе Objects->Log Forwarding и называются Log Forwarding Profile. Суть каждого профиля в том, что NGFW просматривает каждую новую запись журнала и реагирует на нее: отправляет SNMP, отправляет email, отправляет Syslog в SIEM, ставит тег Source или Destination IP адресу.
Я сделал профиль CheckDecryptErrors.
И в нем сделал одно правило SetTag - на что реагировать и как.
Log Type: traffic (тот журнал в котором есть запись об ошибках SSL)
Filter: (session_end_reason eq decrypt-error) or (session_end_reason eq decrypt-unsupport-param) or (session_end_reason eq decrypt-cert-validation) - это ошибки SSL которые мне нужны, чтобы сделать реакцию
Built-in Action: Tag2Bypass
Я воспользовался кнопкой Filter Builder из интерфейса Log Forwarding Match List, поскольку там была подсказка какие варианты поля Sesson End Reason я могу выбрать. Получилось так: (session_end_reason eq decrypt-error) or (session_end_reason eq decrypt-unsupport-param) or (session_end_reason eq decrypt-cert-validation)
И сразу же можно было посмотреть какие в результате будут выбраны журналы - на что я буду реагировать
Когда NGFW видит ошибку SSL, то он ставит тег SSL-Bypass для Destination IP. В поле Built-in Actions я вписал одно действие для этого.
Name: Tag2Bypass (любое имя с нужным нам смыслом)
Target: Destination Address (мы хотим тег ставить адресу сервера, который отказался работать в режиме SSL Decrypt)
Registration: Local User-ID (за теги отвечает либо NGFW, либо Panorama, в данном случае я хочу чтобы все было локально для этого NGFW)
TimeOut (min): 0 (я хочу чтобы IP адрес был с этим тегом вечно, чтобы я больше не пытался никогда делать расшифрование для этого IP. Лучше ставить время на сутки, потому что таблица тегов не бесконечно и нам не нужно, чтобы она переполнялась.)
Tags: SSL-Bypass (те теги, которые нам нужны для попадания IP адреса в DAG. В данном случае этот тег позволит нам исключить данный IP из расшифрования SSL)
Таким образом данный IP попадает в мой DAG, если случается любая ошибка в SSL.
Не забудьте, что этот Log Forwarding Profile должен быть связан с тем правилом, которое пропускает ваш трафик и соответственно, журналирует его. Имя правила, которое вызывает ошибки мы видели в журнале трафика и мы знаем куда подставлять профиль CheckDecryptErrors. Нам нужно привязать реакцию на ошибку в это правило.
Далее находим это правило в политике безопасности Policies->Security
Кликаем на само это правило и во вкладке Actions добавляем в поле Log Forwarding название нашего профиля CheckDecryptErrors. Теперь, если трафик SSL, который пропущен по этому правилу будет в журнал писать ошибки, то мы автоматически добавим IP адрес сервера в исключения.
Прошу обратить внимание, что само правило написано по порту 443. Я специально написал его как в L4 firewall - без указания приложения L7, поскольку я готовлю другую статью про сравнение L4 и L7 правил. И это правило мне нужно, чтобы показать сколько разных L7 приложений ходит по 443 порту. Как вы видите - за несколько часов, что я потратил на статью в поле Apps Seen есть уже 77 разных приложений.
Видно, что я сделал проверки ошибок SSL не только для Яндекс.Cтанции, но и для всех своих источников трафика в квартире.
Мне останется написать само правило- исключение, которое выключает расшифрование для всех адресов из этого DAG с именем.
Переходим в Policies->Decryption
Перед правилом для соединений Алисы я пишу правило Tagged2Bypass - не делать расшифрование для IP адресов из моего DAG.
Source Address: any
Destination Address: Tagged2Bypass (наш DAG, в который мы добавляем наши IP адреса в случае ошибок SSL)
Service: any (любой порт)
Action: no-decrypt (не надо расшифровывать)
Type: ssl-forward-proxy (режим MITM)
Добавляем правило и делаем Commit.
Итог
Что мы сделали
- Создали тег SSL-Bypass
- Создали DAG (динамическую группу адресов) Tagged2Bypass
- Создали Log Forwarding Profile CheckDecryptErrors
- Добавили профиль CheckDecryptErrors в правило по которому идут SSL соединения в разделе Policies - Security
- Добавили новое правило BypassDecrypt в Policies - Decryption для выключения расшифрования соединений в сторону адресов из Tagged2Bypass
- Сохранили конфигурацию.
Теперь я могу посмотреть сам объект Tagged2Bypass - сколько там IP адресов.
В объекте Tagged2Bypass уже 170 адресов.
В корпоративной сети это сильно помогает, потому что вы автоматически разрешаете ситуацию с блокировкой SSL сессии. Если это не делать автоматически, то вы будете делать это вручную: сервис не будет работать, сотрудник будет создавать кейс, вы будете изучать почему SSL не работает, делать исключения вручную. В данном примере я решил автоматически все 170 кейсов, хотя на самом деле я потратил это время более полезно: написал эту статью.