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

e61c1f8142ec4bd8b8da14971f14bc2a.png

Нет, а вы вообще когда-либо видели веселый текст про 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, которая будет блокировать доступ к соц. сетям.

4af895140251478ab0309af2db6f086b.png

Пробуем доступ по-обычному http. Из соц. сетей нам подойдёт старая www.hi5.com.

800e69c4775c44f9adcc77a61c1c4c3a.png

Access Denied, политика работает. Смотрим на FMC в Analysis → Connections → Events. Вот наши заблокированные запросы:

803b05295c9946b290944ee880d5c6a6.png

Сдвигаем таблицу вправо, чтобы посмотреть URL:

544248a98a9e47e58fa7ce76c8df0ffa.png

Смотрим в Wireshark с фильтром по IP-адресу 67.221.174.31:

740e311be4164147bf6fec2861c081bf.png

Видим: проходит TCP handshake, после клиент отправляет HTTP Get с URI «http://hi5.com». На HTTP Get он сразу получает ответ 403 Forbidden. Вот содержание:

e59bbe27a7a94fa0bcb480e85b1fb21a.png

Видно, что это как раз тот самый End User Notification (далее EUN), который мы видим в браузере. EUN отправляет vFTD в ответ на попытку пойти на запрещённый ресурс. Причём EUN отправляется с IP-адреса 67.221.174.31. То есть, фактически, vFTD вклинивается в TCP-сессию между клиентом и сервером и подкладывает свой ответ.

Ок, с чистым http всё понятно. Теперь пробуем зайти на https-сайт, например, vk.com. Дешифрация на vFTD не включена. Сможем ли заблокировать?

bf3ce6d8c8b34ee198b75ebe3c8f184c.png

Оп, опять Access Denied. на FMC в Analysis → Connections → Events. Вот наши заблокированные запросы:

683fc31db98c4d0196262d2e2124db6b.png

Сдвигаемся вправо:

3c04db7046234e6abac3992ba5641ccc.png

Видим, что vk.com оказался не удачным примером. Оказывается, изначально сессия устанавливается по http (tcp порт 80, видно во втором столбце последней страницы). Поэтому блокировка происходит по тому же сценарию, что и в первом случае.

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

552cba4ceeec4e7db4735cf0e13b879b.png
Перенаправление

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

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

d06ec0e8422643f5ba1f3eb099998fee.png
HTTP Get

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

375f0789f33147a0bedba9c83a5d7012.png
Wireshark для вконтактика 2


Если вы еще не заснули — пробуем facebook.com:

da3227178ecc454baa85e165c76e36d4.png

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

3d0e428685554a2b8196888a001d1d84.png

9e34b3a3e5454d70ad8f127e7f0e4f77.png

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

6900a3955793496785a0316cc8c3d39c.png

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

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

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


По дампу трафика в Wireshark видим, что vFTD блокирует сессию к facebook после каждого сообщения SSL Client hello. Соответственно, в Client hello содержится достаточно информации для распознания URL и принятия решения о блокировке. Рассмотрим Client hello внимательнее:

4e810de92a05487cb22d59e8b6c6b52d.png

Действительно, в поле Server Name Indication extension содержится информация, по которой можно определить запрашиваемый ресурс.

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

Это логично, потому что FirePOWER подкладывает страничку EUN в установленную сессию (если она не расшифрована, сделать это нельзя).

Блокировка по интернет-приложениям:

Возможно стоит снова налить себе кофе. Осталось немного, но лучше перестраховаться.
Последнее, что решил проверить — будет ли работать фильтрация интернет-приложений внутри https. В частности, покомпонентная.

Создаем политику, которая будет блокировать Google Drive, Google Maps и Google Play:

f45f70919d7b4fd080f2f18df48c8b75.png

Проверяем — выбранные приложения успешно заблокированы. Смотрим на FMC:

25782330e8c7441e9f10cf7d099f1eea.png

d9c575ffc7b647d6953c3bb14214f0cf.png

В Wireshark видно, что приложения блокируются по тому же сценарию, что и Facebook, то есть после каждого SSL Client Hello:

8091019a6b544aa9b5924e30d20285f5.png

f0e0a822d4874843b8093caa1ae01086.png

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

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

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

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


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

Для шифрованного трафика не работают сигнатуры 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.

Комментарии (0)

© Habrahabr.ru