Защита от кибератак: расшифровка SSL

Еще одной проблемой является отсутствие единой точки анализа зашифрованного трафика. В средних и крупных компаниях обычно используются различные средства защиты информации (FW, IDS, WAF, DLP, sandbox), которые могут расшифровать трафик самостоятельно различными способами. Каждое перечисленное решение должно поддерживать анализ трафика, зашифрованного протоколом SSL/TLS, для выявления угроз, которые распространяются через защищенные каналы.

Рис. 1.

Так, например, устройства класса Next Generation Firewall (NGFW) или Unified Threat Management (UTM) поддерживают анализ передаваемых данных с помощью различных механизмов защиты: потоковое антивирусное сканирование, контроль приложений, web-фильтрация, контентный анализ и пр.

Но как быть с пассивными устройствами сканирования? Например, есть решение IDS, установленное «сбоку» (в режиме приема копии трафика – SPAN), на которое подается трафик, зашифрованный протоколом SSL/TLS. В большинстве случаев мы не сможем проанализировать передаваемые пакеты из-за особенностей работы криптографического протокола.

На сегодняшний день при использовании SSL/TLS возникают два противоречивых требования:

• с одной стороны, требуется шифровать данные на глобальном уровне с помощью протокола SSL/TLS, который помогает решить задачу по безопасной передаче данных;
• с другой – требуется прозрачная расшифровка данных внутри сети компании, чтобы защититься от атак, использующих протокол SSL/TLS, для передачи вредоносного содержимого, а также для анализа передаваемых данных системами IDS, DLP, Sandbox и др.

Если по первому пункту все более-менее понятно, то второй – это головная боль специалистов в области информационной безопасности. И это прежде всего связано с расшифровкой SSL/TLS-трафика и его доставкой на устройства анализа, например, IDS, Sandbox или DLP.

Общие принципы и проблемы расшифровки SSL

Когда требуется расшифровать трафик, между приложением пользователя (как правило, браузером) и сервером ставится промежуточное устройство, которое терминирует SSL-соединения на себе. Устройство, реализующее данный процесс SSL, мы будем называть SSL-прокси.

Рис. 2.

В таком случае пользовательское приложение устанавливает сессию с SSL-прокси для расшифровки трафика и отправки его в открытом виде до сервера. Дополнительным плюсом использования схемы с SSL-прокси является возможность передачи копии расшифрованного трафика на сторонние средства анализа.

На сегодняшний день при открытии SSL-сессии используются два наиболее известных метода обмена ключами – по алгоритмам RSA и Диффи–Хеллмана (DH).

При использовании RSA закрытый ключ сервера обеспечивает защиту сеансовых ключей. У данного алгоритма есть огромный риск: в случае компрометации закрытого ключа сервера злоумышленник сможет расшифровать данные не только в процессе их передачи, но и ранее перехваченный трафик. С точки зрения расшифровки SSL с использованием алгоритма RSA проблем практически не возникает. На устройство расшифровки трафика (балансировщик, NGWF, IDS, WAF) загружается закрытый ключ сервера, после чего появляется возможность расшифровать весь трафик: и терминированный на устройстве, и зеркалированный (по SPAN).

Алгоритм Диффи–Хеллмана в процессе работы использует эфемерные ключи. Злоумышленник не сможет дешифровать ранее перехваченные данные, но, получив закрытый ключ сервера, он сможет реализовать MITM-атаку во время сеанса связи. Это связано с тем, что ключи при обмене генерируются так, что только клиент и сервер могут получить доступ к ним. После закрытия сеанса связи обе стороны уничтожают сеансовые ключи, и единственный способ расшифровать данные в рамках SSL-сессии – взломать сеансовые ключи. Поэтому при использовании алгоритма Диффи–Хеллмана невозможно расшифровать зеркалированный трафик, переданный с другого устройства в зашифрованном виде. И только использование устройства, реализующего функцию SSL-прокси, может решить эту задачу.

Проверено на практике

Одним из рабочих примеров расшифровки SSL является применение устройства F5 BIG-IP Local Traffic Manager.

В типовом случае внутренний пользователь компании устанавливает защищенное соединение с устройством F5 BIG-IP. В свою очередь, F5 BIG-IP выступает в роли клиента по отношению к внешнему web-ресурсу и устанавливает с ним защищенное соединение. После установки защищенных сессий с двух сторон (такая архитектура получила название Full Proxy) начинается процесс передачи данных по зашифрованному каналу.

Рис. 3.

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

Для того чтобы в браузере пользователя при обращении к внешним web-ресурсам не возникало сообщения об ошибке проверки сертификата, требуется:

1. Сгенерировать запрос на сертификат (Certificate Signing Request – CSR) на устройстве F5 BIG-IP.
2. В центре сертификации (Certification authority – CA) выпустить сертификат по CSR (при этом требуется указать шаблон сертификата как промежуточный центр сертификации (Subordinate CA).
3. Загрузить полученный сертификат на F5 BIG-IP.

После окончания процедуры мы получаем один элемент в списке сертификатов, а это означает, что ключ и сертификат успешно связаны друг с другом. На примере скриншота видно, что добавлен один элемент, содержащий пару: сертификат и закрытый ключ сервера.

Рис. 4.

В F5 BIG-IP есть два понятия – Client SSL и Profile SSL. Client означает движение трафика между клиентом и устройством F5 BIG-IP, Server – трафик между устройством F5 BIG-IP и серверами.

Настройка Client SSL осуществляется в меню Local Traffic–Profiles–SSL–Client, где указываются ранее загруженный сертификат, закрытый ключ сервера и название профиля (в нашем случае wan_ssl).

Рис. 5.

Настройка Server SSL осуществляется в меню Local Traffic–Profiles–SSL–Server. В качестве примера мы использовали предустановленный сертификат по умолчанию. Для продукционных систем его применять не рекомендуется – после обновления программного обеспечения F5 BIG-IP производится апдейт предустановленных сертификатов и закрытых ключей.

Рис. 6.

Для SSL-терминации F5 BIG-IP использует концепцию виртуального сервера, чтобы принимать соединения из внешней сети. Если кратко, это виртуальный интерфейс (может иметь IP-адрес и порт), который осуществляет обработку соединений. Виртуальные серверы могут быть различных типов: например, Stateless (для работы с UDP трафиком), Forwarding Layer 4 (для работы с пакетами на уровне 4 OSI), Standart (для реализации функции балансировки, SSL-терминации). В нашем случае нам потребуются серверы двух типов: Standart и Perfomance (Layer 4).

SSL-терминирование заключается в том, что пользовательский HTTPShttps-трафик в зашифрованном виде доходит только до виртуального сервера системы F5 BIG-IP, где транслируется в HTTPhttp, и дальше перемещается по внутренним сетям сервиса в открытом виде. При необходимости HTTPShttps-трафик расшифровывается и отправляется на конечный хост.

Для упрощения настройки расшифровки трафика и отправки его копии на сторонние устройства анализа используется технология F5 BIG-IP iApps – настраиваемый пользователем фреймворк для развертывания приложений. Технология предоставляет наборы шаблонов для автоматизации процесса добавления виртуальных серверов, пулов серверов и другого оборудования.

Мы используем шаблон iApps – f5.ssl_intercept, который автоматизирует процесс расшифровки SSL и отправки копии расшифрованного трафика на дополнительные устройства анализа: IPS, Sandbox, DLP.

Рис. 7.

Как видно на скриншоте, были созданы четыре виртуальных сервера для приема соединений (в том числе зашифрованных) и отправки расшифрованного трафика на дополнительное устройство анализа. Профили www_inet_ingress_vs_any_tcp и www_inet_ingress_vs_any_udp используются для приема соединений по TCP и UDP соответственно. В профиле www_inet_ingress_vs_any_tcp указан раннее созданный профиль Client SSL – wan_ssl, для реализации функции по расшифровки SSL-трафика. Важно отметить, что виртуальный сервер в процессе расшифровки может осуществить замену порта с 443 на 80 в заголовках. Данная подмена портов нужна в тех случаях, когда трафик направляется на сторонние устройства, которые при виде порта 443 в заголовке определяют трафик как зашифрованный и не анализируют его.

Рис. 8.

Виртуальный сервер www_inet_egress_vs_80_tcp используется для приема соединений от дополнительного устройства анализа, шифрования и передачи трафика до внешнего сервера. А www_inet_egress_vs_any отвечает за передачу всего остального трафика (UDP, ICMP и прочее). В процессе шифрования виртуальный сервер осуществляет обратную замену номеров портов в заголовках (80 снова меняется на 443).

Рис. 9.

После проведенных настроек F5 BIG-IP принимает соединения на свой IP-адрес (Self IP). Данный адрес для пользователей будет выступать в качестве шлюза по умолчанию.

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

Рис. 10.

Применение такой схемы, предполагающей расшифровку и отправку трафика на дополнительный анализ, практически не ограниченно. Мы можем отправлять трафик на IPS, DLP, Web Gateway, WAF, Sandbox и пр. На практике мы проверяли работу F5 BIG-IP в связке с «песочницей»/IPS FireEye NX.

FireEye NX анализирует трафик в соответствии с настроенными политиками безопасности и возвращает его на F5 BIG-IP, который, в свою очередь, отправляет трафик на сервер по протоколу HTTPhttp или с использованием SSL.

Рис. 11.

***

Хотим отметить, системы расшифровки трафика, т.е. устройства, реализующие функции SSL–прокси SSL Offloading, в дальнейшем будут все более и более востребованы, учитывая рост использования протокола шифрования SSL/TLS. Они позволяют не только расшифровать трафик для снижения нагрузки на конечные серверы, но и отправить его на дополнительный анализ с привлечением сторонних средств защиты информации.