© 1995-2021 Компания «Инфосистемы Джет»
Защита от кибератак: расшифровка SSL
Информационная безопасность

Материал посвящен расшифровке SSL/TLS-трафика и его доставке на устройства анализа с примерами от вендоров

Информационная безопасность Тренд

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

03.11.2016

Посетителей: 792

Просмотров: 783

Время просмотра: 0

В настоящее время наметился тренд массового перехода с HTTP на HTTPS, и хотя доступ к web-сайтам без шифрования пока осуществляется более чем в трети случаев, ситуация радикально меняется. Все более активное применение протокола SSL/TLS (HTTPS) связано не только с желанием защищать передаваемые данные, есть и другие причины: например, поисковая система Google в факторах ранжирования стала учитывать применение протокола SSL/TLS, что позволяет выводить web-сайт на более высокие позиции по результатам поиска.

 

 

Если не так давно получить SSL-сертификат для web-сайта было проблематично, то сейчас существуют центры сертификации, где сертификат можно сгенерировать бесплатно, например, обратившись к сервису Let's Encrypt.

 

Преимущества использования протокола SSL/TLS очевидны, так как при передаче данных обеспечивается их конфиденциальность, целостность и достоверность. Тем не менее к существенным рискам можно отнести то, что он может использоваться для того, чтобы обойти традиционные сетевые средства защиты информации. Типичный случай обхода выглядит так: пользователь устанавливает соединение с веб-сайтом и скачивает файл-загрузчик (Trojan-downloader) или получает его по электронной почте. После его запуска создается зашифрованный сеанс связи с сервером управления (например, с ботнет-сервером C&C) и вредоносное ПО (например, zero-day) закачивается на рабочую станцию пользователя. Поскольку трафик при такой атаке зашифрован, он невидим для традиционных сетевых средств защиты.

Еще одной проблемой является отсутствие единой точки анализа зашифрованного трафика. В средних и крупных компаниях обычно используются различные средства защиты информации (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. Они позволяют не только расшифровать трафик для снижения нагрузки на конечные серверы, но и отправить его на дополнительный анализ с привлечением сторонних средств защиты информации.

Уведомления об обновлении тем – в вашей почте

Новый подход к защите информации — системы обнаружения компьютерных угроз

Системы обнаружения сетевых вторжений и выявления признаков компьютерных атак на информационные системы уже давно применяются как один из необходимых рубежей обороны информационных систем.

Активный аудит

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

The Standoff: топ-10 самых ярких ИБ-фактов

С 12 по 17 ноября компания Positive Technologies провела киберполигон The Standoff — мероприятие, где на виртуальной платформе проводили киберучения и стримы с ИБ-экспертами со всего мира.

Задание: шпионаж

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

«Наша задача — сделать атаку максимально дорогой и сложной для злоумышленника»

О векторах угроз ИБ, подходах к защите и других вопросах ИБ мы беседуем с Сергеем Невструевым, руководителем направления защиты от угроз «нулевого дня» компании Check Point SoftwareTechnologies в Восточной Европе.

72

Философия защиты

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

Основные классы угроз в компьютерном сообществе 2003 года, их причины и способы устранения

Компьютерные вирусы, сетевые черви, троянские программы и хакерские атаки давно перестали ассоциироваться с фантастическими боевиками голливудского производства. Компьютерная "фауна", хулиганство и преступления — сейчас это обыденные явления, с ...

Кибератаки на критическую инфраструктуру — миф или реальность?

Число кибератак на промышленные системы растет. Если недавно эта проблема носила умозрительный характер, сейчас она приобрела реальные очертания. Причем нарушение промышленной безопасности чревато последствиями, далеко выходящими за рамки финансового ущерба и потери деловой репутации.

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня