Дешифрация

  • 26.12.2016
  • 1999

Автор
Борис Усков, CCNP

Системный инженер


Скучно о дешифрации

Оглавление

Нет, а вы вообще когда-либо видели веселый текст про SSL?

Я – нет. Но нам все равно придется страдать. Вы могли бы пролистать этот материал и почитать что-нибудь более интересное и интригующее. Но если вам надо разобраться, как и зачем это работает, то советую запастись чем-нибудь бодрящим. Ибо далее неподготовленный человек рискует заснуть.

Я, конечно, возьму на себя ответственность и буду периодически вас будить. Однако, советую все же налить себе чашечку крепкого кофе и устроиться поудобнее. Поговорить нам надо о многом:
дешифрация NGFW – дело тонкое.

В комментариях к материалу о ISE+FirePOWER разгорелся спор на тему дешифрации. Я решил разобраться подробнее в этой УВЛЕКАТЕЛЬНОЙ теме.

Все известные мне решения NGFW, UTM и Web proxy для дешифрации https используют подмену сертификата. Оперировать буду на примере Cisco virtual FirePOWER Thread Defense (далее vFTD) под управлением Cisco FirePOWER Management Center virtual (далее FMC).

Мой коллега когда-то уже подробно описывал это решение здесь. Упомянутые принципы применимы к большинству подобных решений.

Фильтрация URL

Фильтрация по категориям 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, видно во втором столбце последней страницы). Поэтому блокировка происходит по тому же сценарию, что и в первом случае.

Перенаправление http на https

Конечно, для vk.com мы могли бы просто написать в браузере «https://vk.com». Тогда сразу же попадаем на защищённую версию сайта. Но обычно никто так не делает - сайт самостоятельно перенаправляет на https.

Скучно о дешифрации

Перенаправление

Скучно о дешифрации

Wireshark для вконтактика 1

Видим, что сначала клиент устанавливает tcp-сессию на порт 80. В ответ на HTTP Get сервер отвечает HTTP 302 Found.

Скучно о дешифрации

HTTP Get

Википедия подсказывает, что код HTTP 302 означает: «запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location». Видим, что в Location указано https://vk.com. Поэтому клиент сразу же устанавливает новую tcp-сессиию, но уже на порт 443.

Скучно о дешифрации

Wireshark для вконтактика 2

Доступ заблокирован, но EUN не отобразился. Посмотрим на FMC:

Скучно о дешифрации

Скучно о дешифрации

Посмотрим в Wireshark:

Скучно о дешифрации

Видим, что в отличие от vk, сайт сразу устанавливает сессию на порт 443.

hsts

Сайт использует механизм hsts. Если вкратце: сайты, поддерживающие hsts, после установления соединения с клиентом по https, говорят браузеру всегда использовать для последующих подключений https. То есть они для всех последующих сессий локально подставляют https:// вместо http:// в адресную строку.

Например, в google chrome можно посмотреть, для каких сайтов включён hsts. Для этого надо ввести в адресной строке chrome://net-internals/#hsts:

Скучно о дешифрации

Проверка hsts в Chrome

По дампу трафика в Wireshark видим, что vFTD блокирует сессию к сайт после каждого сообщения 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 видно, что приложения блокируются по тому же сценарию, что и сайт, то есть после каждого SSL Client Hello:

Скучно о дешифрации

Скучно о дешифрации

Блокировка Интернет-приложений

На практике нужно проверять возможность блокировки для конкретных приложений. Нет гарантии, что настроенная политика будет срабатывать вне зависимости от дешифрации (включена она или выключена). Версии приложений постоянно меняются, а патчи для FirePOWER могут не успевать за ними.

Для распознавания некоторых приложений всё же требуется дешифрация. Их немного, они отмечены в настройках политик специальной иконкой с замком.

Скучно о дешифрации

Приложения, требующие дешифрацию

Большинство из них связано с передачей файлов.

Таким образом, дешифрация нужна, чтобы срабатывало уведомление пользователей о блокировке. Хотя только для этого я бы весь этот компот не варил.

Для шифрованного трафика не работают сигнатуры IPS и файловые политики, включая Advanced Malware Protection (AMP). И это логично: чтобы искать вредоносов, трафик должен быть расшифрован. Тут стоит понимать, что глубокая инспекция не отработает именно для payload. Для той информации, которая передаётся в открытом виде (заголовки IP, TCP, сообщения SSL Handshake) сигнатуры работать будут.

С точки зрения IPS более интересна защита входящего трафика. Если, мы публикуем Web-сервер в Интернет и хотим защитить его с помощью IPS, то SSL-сессии будут инициироваться снаружи. Дешифровать их с подменой сертификата не имеет смысла: зачем менять один собственный сертификат на другой?

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

Мониторинг трафика

Последнее применение дешифрации – мониторинг трафика.

В итоге, для чего может потребоваться дешифрация трафика на FirePOWER:

  1. Отображение EUN для заблокированных сайтов и Web-приложений;
  2. Анализ трафика сигнатурами IPS;
  3. Контроль передачи файлов, в том числе анализ файлов системой AMP;
  4. Распознавание некоторых приложений;
  5. Мониторинг.

Думаю, теперь понятно, зачем дешифровать SSL на NGFW (а также UTM, Web proxy) в принципе. В данном случае я разобрал сабж на примере FirePOWER. Однако, уверен - на других решениях ситуация будет аналогичной. Если это не совсем так - пишите.

В следующем материале расскажу, КАК ИМЕННО работает дешифрация с подменой сертификата на NGFW. Stay tuned.

Список литературы
  1. Cisco Next Generation Security Solutions
  2. Cisco Firepower Threat Defense (FTD) Configuration and Troubleshooting Best Practices
Возможно, вас заинтересует
  1. Настройка и просмотр статистики о вызовах и их качестве в Cisco Unified Communications Manager (CUCM)
  2. Интеграция сервисов FirePOWER на Cisco ASA
  3. Ограничение скорости передачи трафика. Policer или shaper, что использовать в сети?
  4. Сетевые оверлейные технологии для ЦОД. Часть 2
  5. Интерфейсы контроллеров HPE Aruba и Cisco