Назад | Перейти на главную страницу

Content Aware Firewall и зашифрованный контент

Существуют межсетевые экраны, которые анализируют проходящий трафик и блокируют его, если он не нужен. Насколько хорошо эти межсетевые экраны работают с зашифрованным трафиком, например HTTPS или IMAP через SSL?

Пример: может ли брандмауэр различать HTTPS-трафик на порту 443 и, скажем, защищенный трафик удаленного рабочего стола через 443?

В вашем конкретном примере да, это возможно.

HTTPS запускает сеанс TLS с удаленным устройством.

TLSv1  Client Hello

Безопасный RDP запускает сеанс RDP, который согласовывает безопасное соединение TLS между двумя сторонами сеанса.

X.224  Connection Request (0xe0)

Поскольку протоколы запуска сеанса различаются, межсетевой экран с отслеживанием состояния должен иметь возможность различать запуск HTTPS-соединения и что-то еще.

В общем случае брандмауэр не сможет обнаружить что-то вроде SSH-over-HTTPS, поскольку трафик SSH скрыт внутри трафика HTTPS. Единственный способ обнаружить это - эвристический анализ шаблонов трафика, но я не знаю ничего, что могло бы это сделать.

Для IMAP есть два режима защиты. Один через SSL, другой через TLS. Метод SSL выглядит так же, как HTTPS-соединение, только на другом порту, и если удаленный порт такой же, то он мало что может с этим поделать. TLS, с другой стороны, согласовывается между обоими сторонами диалога, поэтому запуск сеанса заметно отличается и легко обнаруживается.

Важно помнить, что SSL создает оболочку TCP, через которую проходит трафик. Многие протоколы включают метод согласованной безопасности внутри самого протокола, который использует те же технологии, что и оболочка, но использует другой метод запуска сеанса, который делает его дифференцируемым.

Некоторые брандмауэры / прокси-серверы могут выполнять «атаку авторизованного посредника» на TLS-соединения; например, Squid называет эту функцию «SSL Bump». Прокси-сервер, который делает это, будет иметь полный доступ к открытым текстовым данным, передаваемым внутри сеанса TLS. Однако клиент за таким прокси-сервером получит другой сертификат сервера (предоставленный самим прокси, а не реальным сервером), что вызовет ошибки или предупреждения TLS, если клиент не настроен на ожидание таких сертификатов (путем добавления сертификата прокси CA в список доверенных корневых сертификатов).