Скучно о дешифрации
Нет, а вы вообще когда-либо видели веселый текст про SSL?
Я — нет. Но нам все равно придется страдать. Вы могли бы пролистать этот материал и почитать что-нибудь более интересное и интригующее. Но если вам надо разобраться, как и зачем это работает, то советую запастись чем-нибудь бодрящим. Ибо далее неподготовленный человек рискует заснуть.
Я, конечно, возьму на себя ответственность и буду периодически вас будить. Однако, советую все же налить себе чашечку крепкого кофе и устроиться поудобнее. Поговорить нам надо о многом:
дешифрация NGFW — дело тонкое.
В комментариях к материалу о ISE+FirePOWER разгорелся спор на тему дешифрации. Я решил разобраться подробнее в этой УВЛЕКАТЕЛЬНОЙ теме.
Все известные мне решения NGFW, UTM и Web proxy для дешифрации https используют подмену сертификата. Оперировать буду на примере Cisco virtual FirePOWER Thread Defense (далее vFTD) под управлением Cisco FirePOWER Management Center virtual (далее FMC).
Мой коллега когда-то уже подробно описывал это решение здесь. Упомянутые принципы применимы к большинству подобных решений.
Дешифрация — нужна или нет?
Фильтрация по категориям URL, репутациям сайтов и Интернет-приложениям — это классическая функциональность NGFW.
Чтобы понять к какому сайту обращается клиент не обязательно расшифровывать весь трафик. Функциональность дешифрации, как таковая, необходима только для определенных действий: анализа трафика, контроля передачи файлов и мониторинга. В случае же фильтрации интернет-доступа по https, дешифрация не нужна, пусть это и не очевидно.
Вот как работает блокировка по URL-категории:
Создаем политику доступа на FMC, которая будет блокировать доступ к соц. сетям.
Пробуем доступ по-обычному http. Из соц. сетей нам подойдёт старая www.hi5.com.
Access Denied, политика работает. Смотрим на FMC в Analysis → Connections → Events. Вот наши заблокированные запросы:
Сдвигаем таблицу вправо, чтобы посмотреть URL:
Смотрим в Wireshark с фильтром по IP-адресу 67.221.174.31:
Видим: проходит TCP handshake, после клиент отправляет HTTP Get с URI «http://hi5.com». На HTTP Get он сразу получает ответ 403 Forbidden. Вот содержание:
Видно, что это как раз тот самый End User Notification (далее EUN), который мы видим в браузере. EUN отправляет vFTD в ответ на попытку пойти на запрещённый ресурс. Причём EUN отправляется с IP-адреса 67.221.174.31. То есть, фактически, vFTD вклинивается в TCP-сессию между клиентом и сервером и подкладывает свой ответ.
Ок, с чистым http всё понятно. Теперь пробуем зайти на https-сайт, например, vk.com. Дешифрация на vFTD не включена. Сможем ли заблокировать?
Оп, опять Access Denied. на FMC в Analysis → Connections → Events. Вот наши заблокированные запросы:
Сдвигаемся вправо:
Видим, что vk.com оказался не удачным примером. Оказывается, изначально сессия устанавливается по http (tcp порт 80, видно во втором столбце последней страницы). Поэтому блокировка происходит по тому же сценарию, что и в первом случае.
Перенаправление
Wireshark для вконтактика 1
Видим, что сначала клиент устанавливает tcp-сессию на порт 80. В ответ на HTTP Get сервер отвечает HTTP 302 Found.
HTTP Get
Википедия подсказывает, что код HTTP 302 означает: «запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location». Видим, что в Location указано vk.com. Поэтому клиент сразу же устанавливает новую tcp-сессиию, но уже на порт 443.
Wireshark для вконтактика 2
Если вы еще не заснули — пробуем facebook.com:
Доступ заблокирован, но EUN не отобразился. Посмотрим на FMC:
Посмотрим в Wireshark:
Видим, что в отличие от vk, facebook сразу устанавливает сессию на порт 443.
Например, в google chrome можно посмотреть, для каких сайтов включён hsts. Для этого надо ввести в адресной строке chrome://net-internals/#hsts: 
Проверка hsts в Chrome
По дампу трафика в Wireshark видим, что vFTD блокирует сессию к facebook после каждого сообщения SSL Client hello. Соответственно, в Client hello содержится достаточно информации для распознания URL и принятия решения о блокировке. Рассмотрим Client hello внимательнее:
Действительно, в поле Server Name Indication extension содержится информация, по которой можно определить запрашиваемый ресурс.
Что касается EUN, у FirePOWER есть некоторые ограничения при отображении уведомлений о блокировке для пользователей. Для не расшифрованного трафика EUN отображаться не будет.
Это логично, потому что FirePOWER подкладывает страничку EUN в установленную сессию (если она не расшифрована, сделать это нельзя).
Блокировка по интернет-приложениям:
Возможно стоит снова налить себе кофе. Осталось немного, но лучше перестраховаться.
Последнее, что решил проверить — будет ли работать фильтрация интернет-приложений внутри https. В частности, покомпонентная.
Создаем политику, которая будет блокировать Google Drive, Google Maps и Google Play:
Проверяем — выбранные приложения успешно заблокированы. Смотрим на FMC:
В Wireshark видно, что приложения блокируются по тому же сценарию, что и Facebook, то есть после каждого SSL Client Hello:
Для распознавания некоторых приложений всё же требуется дешифрация. Их немного, они отмечены в настройках политик специальной иконкой с замком.
Приложения, требующие дешифрацию
Большинство из них связано с передачей файлов.
Таким образом, дешифрация нужна, чтобы срабатывало уведомление пользователей о блокировке. Хотя только для этого я бы весь этот компот не варил.
Для шифрованного трафика не работают сигнатуры IPS и файловые политики, включая Advanced Malware Protection (AMP). И это логично: чтобы искать вредоносов, трафик должен быть расшифрован. Тут стоит понимать, что глубокая инспекция не отработает именно для payload. Для той информации, которая передаётся в открытом виде (заголовки IP, TCP, сообщения SSL Handshake) сигнатуры работать будут.
С точки зрения IPS более интересна защита входящего трафика. Если, мы публикуем Web-сервер в Интернет и хотим защитить его с помощью IPS, то SSL-сессии будут инициироваться снаружи. Дешифровать их с подменой сертификата не имеет смысла: зачем менять один собственный сертификат на другой?
Для такой задачи на FirePOWER предусмотрена дешифрация с private key. То есть на FirePOWER заранее загружается сертификат публикуемого сервера и соответствующий private key. С помощью него будет осуществляться дешифрация сессии, запущенной снаружи. Данный вариант в рамках этого материала рассматривать не будем.
Последнее применение дешифрации — мониторинг трафика.
В итоге, для чего может потребоваться дешифрация трафика на FirePOWER:
- Отображение EUN для заблокированных сайтов и Web-приложений;
- Анализ трафика сигнатурами IPS;
- Контроль передачи файлов, в том числе анализ файлов системой AMP;
- Распознавание некоторых приложений;
- Мониторинг.
Думаю, теперь понятно, зачем дешифровать SSL на NGFW (а также UTM, Web proxy) в принципе. В данном случае я разобрал сабж на примере FirePOWER. Однако, уверен — на других решениях ситуация будет аналогичной. Если это не совсем так — пишите.
В следующем материале расскажу, КАК ИМЕННО работает дешифрация с подменой сертификата на NGFW. Stay tuned.
