В предыдущем уроке мы затронули проблему человеческого фактора в Информационной безопасности. В итоге мы сделали вывод, что не важно на сколько качественное и дорогое оборудование вы используете, т.к. все “упрется” в настройку, которая должна быть выполнена грамотно. В этом уроке мы рассмотрим https-инспекцию. Довольно многие недооценивают важность этой функции без которой немыслима современная защита сети. Но обо всем по порядку.

Защита веб-трафика

Практически все современные NGFW или UTM решения имеют функционал проверки веб-трафика. Это и категоризация сайтов и проверка скачиваемого контента и определение веб-приложений. Причем последний пункт (веб-приложения) очень важен, т.к. через один и тот же порт могут работать огромное кол-во сервисов. И если с проверкой HTTP-трафика практически у всех вендоров нет проблем, то HTTPS — настоящий вызов для современных средств защиты.

HTTPS

Думаю, что нет особого смысла рассказывать что такое HTTPS и на сколько он важен для организации безопасного Интернета. Благодаря HTTPS можно быть уверенным, что между клиентом (браузер) и сервером (web-server) невозможно перехватить или изменить передаваемую информацию. Согласно статистике за 2017 год, доля HTTPS-трафика превысила 50%.



Более того, современные браузеры (например google chrome) будут помечать http-сайты с формой авторизации как недоверенные, а google будет понижать их в поисковой выдаче. Все это спровоцирует еще более стремительное увеличение доли HTTPS-трафика.

Как было сказано ранее, HTTPS используется для защищенного общения между двумя узлами в сети Интернет. При этом HTTPS не является каким-то новым протоколом, в целом это обычный HTTP, просто для защиты трафика в качестве транспортного протокола используется SSL или TLS. Именно эти протоколы и отвечают за аутентификацию, шифрование и целостность трафика. Мы не будем подробно рассматривать работу этих протоколов, но всем кто интересуется очень рекомендую вот эту статью. В грубом приближении работа HTTPS выглядит следующим образом:



Т.е. клиент инициирует TLS-запрос к Web-серверу и получает TLS-ответ, а также видит цифровой сертификат, который естественно должен быть доверенным. Пример сертификата при обращении на сайт vk.com изображен выше. В нем содержатся параметры защищенного соединения и открытый ключ. Кроме того, браузер может “подсказать” какая именно версия TLS используется. Повторюсь, что это очень упрощенное описание работы TLS.

После успешного TLS Handshake, начинается передача данных в шифрованном виде. Казалось бы, что это очень хорошо (так оно и есть). Однако для “безопасника” в компании это настоящая головная боль. Поскольку он не “видит” этот трафик и не может проверять его содержимое ни антивирусом, ни системой предотвращения вторжений (IPS), ни DLP-системой, ничем… А это в свою очередь представляет собой очень серьезную уязвимость. Т.к. большинство сайтов переходят на HTTPS, то без HTTPS инспекции ваш интернет-шлюз не может проверять большую часть Web-трафика (т.к. он зашифрован). Кроме того, злоумышленники все чаще используют облачные файловые хранилища для распространения вирусов, которые также работают по HTTPS. Таким образом, каким бы качественным и дорогим не был ваш межсетевой экран (будь то UTM или NGFW решение), он будет пропускать абсолютно все вирусы и зловреды без включенной HTTPS инспекции. Даже пресловутый тестовый вирус EICAR, который детектится любым антивирусом, будет успешно проходить вашу защиту через HTTPS. Мы это обязательно рассмотрим на примере.

HTTPS-инспекция

Решить проблему безопасников призвана технология HTTPS-инспекции. Ее суть до безобразия проста. Фактически, устройство, которое организует HTTPS-инспекцию, совершает атаку типа man-in-the-middle. Выглядит это примерно следующим образом:



Т.е. Check Point перехватывает запрос пользователя, поднимает с ним HTTPS-соединение и уже от себя поднимает HTTPS-сессию с ресурсом, к которому обратился пользователь. В данном случае клиенту предъявляется сертификат, который выпустил сам Check Point. Само собой, что данный сертификат должен быть доверенным. Для этого в Check Point-е есть возможность импортировать сертификат от доверенного CA (subordinate certificate). При импортировании убедитесь, что сертификат имеет алгоритм подписи не ниже sha256, т.к. если он будет например sha1, то современные браузеры будут “ругаться” на такие сертификаты. Либо же вы можете сгенерировать самоподписанный сертификат, который затем необходимо сделать доверенным для всех компьютеров. Именно этот способ мы рассмотрим на примере.

Таким образом, оказавшись посередине между двумя шифрованными соединениям, Check Point получает возможность проверять трафик и все файлы, как с помощью антивируса, так и с помощью остальных блейдов (IPS, Threat Emulation и т.д.). Более подробно о HTTPS-инспекции Check Point вы можете почитать здесь.

Ограничения HTTPS-инспекции

Однако, не все так просто. Метод man-in-the-middle работает далеко не всегда. Есть случаи когда расшифровать https-трафик просто невозможно. Вот несколько примеров:

1) Используются отечественные криптоалгоритмы (ГОСТ) вместо стандартных SSL/TLS.
На данный момент ни одно иностранное решение не может обеспечивать корректную расшифровку подобного HTTPS-трафика (хотя и отечественных решений умеющих делать подобную https-инспекцию лично я не знаю). В качестве решения можно настроить исключения в HTTPS-инспекции для сайтов данной категории.

2) Используется Certificate Pinnig.
Т.е. приложение клиента заранее знает сертификат сервера, к которому он обращается. Обычно проверяется серийный номер сертификата. В этом случае приложение просто не будет смотреть в локальное хранилище доверенных сертификатов и при попытке подмены естественно будет возникать ошибка. Чаще всего данная проблема относится к толстым клиентам (такие как Skype, Telegram), которые используют SSL/TLS в качестве транспорта. Кроме того, буквально на днях обнаружил, что обновленная версия google chrome также начала использовать технологию certificate pinning для своих сервисов (youtube, google drive, gmail и так далее). Это делает невозможным использование https-инспекции. Компания Google активно заботится о безопасности пользователей, но значительно усложняет жизнь безопасникам. В этом случае есть два выхода:

• Настроить исключения в https-инспекции для сервисов Google. Уверен, что для компаний это крайне нежелательно.
• Использовать другой браузер… Например Firefox.

Уверен, что многих интересует проблема таких приложений как telegram и т.д. К сожалению (или к счастью) на данный момент расшифровывать этот трафик не предоставляется возможным. Либо вы блокируете эти приложения, т.к. на сетевом уровне невозможно “видеть” этот трафик, либо используете дополнительный уровень защиты в виде каких-то агентов на компьютерах пользователей, например CheckPoint SandBlast Agent, который сможет проверять на зловредность уже расшифрованный трафик (например полученные файлы через мессенджер).

3) Используется аутентификация не только сервера, но и клиента.
Это характерно для сайтов из категории финансовых услуг, когда для доступа к какому-нибудь банк-порталу клиент использует специальный ключ или токен. Естественно, что в данном случае устройство, которое осуществляет HTTPS-инспекцию просто не сможет организовать https-соединение с сервером, т.к. не обладает нужным ключем. Проблема решается только настройкой исключений в HTTPS-инспекции.

4) Используется отличный от SSL/TLS протокол.
В данном случае речь уже не о ГОСТ-шифровании, а об относительно новом протоколе от google — quic. Компания гугл начинает активно переводить свои сервисы именно на этот протокол. При этом на текущий момент невозможно обеспечить его расшифровку. Единственным решением в данном случае является блокировка протокола quic, после чего сервисы google начинают использовать стандартный SSL/TLS.

Настройка

Описать настройку в формате текста довольно трудоемко, поэтому мы сделали небольшое видео. В первой части рассказывается вышеописанная теория, а во второй части мы пробуем скачать вирус по HTTPS, а затем настроим HTTPS-инспекцию и сравниваем результат.

Вывод

Самое главное, что нужно вынести из этого урока — HTTPS-инспекция это ОБЯЗАТЕЛЬНЫЙ компонент современной защиты. Без этой функции в вашей сети огромная черная дыра с точки зрения безопасности. И это относится не только к Check Point-у, но и ко всем другим решениям. Обязательно протестируйте свою сеть подобным образом. Все что нужно, это какой-нибудь тестовый вирус и клиентская машина, желательно без антивируса, чтобы тот не смог заблокировать скачивание файла (для чистоты эксперимента).
На этом мы заканчиваем второй урок, спасибо за внимание!

P.S. Хотелось бы поблагодарить Алексея Белоглазова за помощь в подготовке урока.