HTTPS Inspection — передовой опыт

В этой статье представлены некоторые рекомендации по развертыванию и использованию HTTPS Inspection для предотвращения распространенных проблем в конфигурации.

Обратите внимание: для извлечения пользы из последних обновлений в области безопасности, производительности и стабильности, Check Point всегда рекомендует обновить систему до самой последней версии (upgrade Security Gateway / upgrade Cluster / upgrade VSX / upgrade 600 appliance / upgrade 1100 appliance / upgrade Security Management Server / upgrade Multi-Domain Security Management Server / upgrade SmartConsole).

Интернет-трафик HTTPS зашифрован и использует SSL протокол (Secure Sockets Layer ) для сохранения данных в безопасности и полной сохранности. Тем не менее, HTTPS трафик имеет возможную угрозу безопасности и может скрывать незаконную деятельность пользователя и вредоносный трафик. С помощью HTTPS Inspection шлюз безопасности может осуществлять проверку трафика , который зашифрован через HTTPS.

Благодаря использованию сертификатов, шлюз безопасности становится посредником между устройством пользователя и безопасным веб-сайтом. Все данные хранятся в личных журналах HTTPS Inspection. Только администраторы с доступом к HTTPS Inspection смогут увидеть все поля журнала.

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

HTTPS Inspection Rule Base представляет собой набор правил, определяющих, какого рода HTTPS трафик будет проверяться с помощью шлюза безопасности. Проверка осуществляется посредством всех программных блейдов (Software Blades), поддерживающих HTTPS Inspection, а именно:

• Application Control
• URL Filtering
• IPS
• DLP
• Anti-Virus
• Anti-Bot

• Inbound HTTPS Inspection (проверка входящего трафика) защищает внутренние серверы (например, центры обработки данных и веб-серверы) от вредоносных атак, поступающих из Интернета.

Входящие соединения представляют собой HTTPS соединения, которые начинаются от внешнего клиента и соединяются с внутренним сервером в DMZ или в сети. Шлюз безопасности сравнивает запрос HTTPS с базовыми политиками безопасности — HTTPS Inspection Rule Base. Если запрос не соответствует им, пакет не расшифровывается.

Если запрос соответствует политикам безопасности, шлюз безопасности использует сертификат для внутреннего сервера, чтобы создать соединение HTTPS с внешним клиентом. Шлюз безопасности создает новое соединение HTTPS с внутренним сервером. Поскольку шлюз безопасности имеет защищенное соединение с внешним клиентом, он способен расшифровать HTTPS трафик. Расшифрованный трафик проверяется в соответствии с политиками.

Поток на Security Gateway:

1. Перехват запроса.
2. Использование оригинального сертификата сервера и ключа безопасности для инициирования SSL соединения с клиентом.
3. Создание и установка нового SSL соединения с веб-сервером.
4. Использование двух SSL соединений:

• Расшифровка данных, спрятанных от клиента.
• Осмотр контента всех блейдов, допущенных политиками безопасности.
• Последующее шифрование данных для сохранения конфиденциальности клиента, так как после шлюза безопасности данные перемещаются на указанный сервер.

• Outbound HTTPS Inspection (проверка исходящего трафика) защищает внутренних пользователей и серверы от вредоносных интернет-атак, возникающих в соединениях внутри организации.

Исходящие соединения представляют собой HTTPS соединения, которые начинаются с внутреннего клиента и имеют доступ к Интернету. Шлюз безопасности проверяет запрос HTTPS с помощью HTTPS Inspection Rule Base. Если запрос не соответствует правилу, пакет не расшифровывается.

Если запрос соответствует политикам безопасности, шлюз гарантирует, что сертификат на сервере (в интернете ) действителен. Шлюз безопасности создает новый сертификат и использует его для нового соединения HTTPS с сервером. Существуют два HTTPS соединения, первое — к внутреннему клиенту, второе – к серверу. Это позволяет расшифровывать и проверять пакеты в соответствии с политиками шлюза безопасности и другими базовыми правилами. Далее пакеты снова шифруются и перемещаются в место назначения.

Поток на Security Gateway:

1. Перехват запроса.
2. Установление безопасного соединения с запрашиваемым веб-сайтом и проерка сертификата сервера сайта.
3. Создание нового SSL сертификата для установления связи между шлюзом безопасности и клиентом, отправление клиенту нового сертификата и сопоставление SSL с сертификатом.
4. Использование двух подключений SSL :

• Расшифровка данных клиента .
• Инспектирование содержимого всех блейдов, установленных политиками.
• Инспектирование веб-трафика, попадающего в сеть организации.
• Обратное шифрование данных для сохранения конфиденциальности клиента, пока данные перемещаются в назначенный ресурс веб-сервера.

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

Обратитесь в Руководству администратора Application Control and URL Filtering Administration Guide (R75.20, R75.40, R75.40VS, R76, R77) — глава «Managing Application Control and URL Filtering» — «HTTPS Inspection».

• Использование всей цепочки сертификатов для настройки проверки входящего трафика.

При импорте сертификата внутреннего сервера, для контроля входящего трафика необходимо включить все промежуточные центры сертификации (CAs) цепочки в * .p12 file. Включение только сертификата сервера может вызвать предупреждения некоторых браузеров о ненадежности сайтов, поскольку некоторые браузеры не способны выбирать и проверять всю цепочку сертификатов.

• CA создание / импорт — Использование CA сертификата для проверки HTTPS Inspection исходящего трафика.

При импорте внешнего сертификата в SmartDashboard на вкладку блейда «Advanced» — «HTTPS Inspection» — «Gateways» — «Import Certificate from file…», необходимо использовать CA сертификат, так как этот сертификат может быть использован для подписи сертификатов, генерируемых шлюзом безопасности для проверки исходящего трафика.

Импорт другого сертификата (не CA) приведет к отказу соединения в браузере клиента.

Примечание: Использование сертификата по умолчанию, сгенерированного из свойств шлюза безопасности – панель «HTTPS Inspection» — не вызовет никаких проблем, так как сертификат шлюза безопасности является CA сертификатом и может быть использован для подписи сертификатов, генерируемых шлюзом безопасности.

• Убедитесь, что все промежуточные сертификаты в цепочке имеют подпись SHA -256 , чтобы избежать предупреждений браузера.

Для проверки входящего и исходящего трафика, убедитесь, что все промежуточные сертификаты в цепочке имеют подпись SHA -256 (или выше).

В противном случае, браузеры могут предупредить (например, появится значок рядом с «URL») о том, что соединение является недостаточно безопасным.

Это ограничение относится только к промежуточным сертификатам в цепочке, но не к корневым центрам сертификации CAs.

А. Что проверять?

Настоятельно рекомендуется инспектировать HTTPS трафик с браузеров (исходящий HTTPS Inspection).

Пользователи могут выбрать обход некоторых категорий в целях сохранения конфиденциальности.HTTPS-приложения, запускаемые вне браузера, склонны доверять собственной корневой CA-системе сертификации, не доверяя при этом сертификату, сгенерированному шлюзом безопасности (примеры: Google Drive, Dropbox).

Кроме того, HTTPS-приложения, запускаемые вне браузера, могут использовать нестандартный SSL сертификат, поэтому не могут быть проверены шлюзом безопасности. Эти ограничения не являются специфическими для Check Point.

Обойти эти соединения можно с помощью IP-адреса сервера (когда есть доступ к нему), IP-адреса клиента (при наличии нескольких клиентов, использующих эти приложения), или идентификатора пользователя.В тех случаях, когда сервер использует стандартный SSL сертификат, обход соответствует категории / URL также может быть использован.

В. Проверка сайтов с сертификатом мульти-категории

Решения по обходу HTTPS Inspection основаны на сертификате сервера. Важно отметить, что существуют серверы, которые выпускают единый сертификат для нескольких доменов из разных категорий (поисковики / порталы, обмен мультимедийными данными и т.д.).Например, ниже представлен сертификат Google:

Без расшифровки SSL сертификата, для Gateway Security становится невозможным знание основного URL и простая классификация соединений.

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

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

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

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

Рассмотрим следующие базы правил:

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

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

Если подключение к интернету отсутствует, то выбрать CRL и промежуточный CA не удастся. Проверка начнётся, но обход на основе URL или на основе категории не будет работать.

Ненадежные сертификаты и отсутствие CRL могут стать причинами разрыва соединения.

Примечание: проверка ящика «Log connections of clients that have not installed the CA certificate» будет осуществлять регистрацию соединений клиентов, которые не установил CA сертификат, или соединений, разорванных по другим причинам. Рекомендуется очистить эту коробку.

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

• Perfect Forward Secrecy (PFS) — введение

Perfect Forward Secrecy (PFS) — основной способ избавления от необходимости передачи конфиденциальных данных по проводу, гарантирующий секретность в будущем даже во время регистрации трафика.

PFS широко используется в TLS и IKE / IPsec.

• Perfect Forward Secrecy (PFS) — ECDHE

Diffie-Hellman (DH) является традиционным PFS алгоритмом.

Elliptic curve Diffie-Hellman (ECDH) — современный PFS алгоритм на основе эллиптических вычислений кривой. Тот же уровень безопасности Диффи-Хеллмана достигается с помощью более коротких ключей в ECDH, что повышает производительность.

ECDHE это протокол, который использует Ephemeral ECDH ключи.

Некоторые веб-серверы принимают только PFS шифры (DHE, ECDHE).

ECDHE полностью поддерживается в следующих версиях шлюза безопасности (ID 01418393):

• R77.30 (ID 01467522) и выше
• R77.20 с Jumbo Hotfix Accumulator Take_143 и выше (ID 01546352).

Для версий шлюзов безопасности R77.20 и ниже подключение к веб-серверам невозможно без регистрации. Примером такого веб-сервера служит tumblr.com.

Если вы столкнулись с такой проблемой, то свяжитесь поддержкой — Contact Check Point Support – для получения обновлений sk104717 (Issue ID 01418393).

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

Для ускорения процесса вы можете получить файлы CPinfo files с сервера управления безопасностью и шлюза безопасности.

Обратитесь к следующим ссылкам:

• Поддерживаемые шифры — sk104562 — Supported cipher suites for HTTPS Inspection
• Обновления — sk104717 — HTTPS Inspection Enhancements in R77.30

Примечание: Некоторые веб-серверы не принимают любые предложения шлюза безопасности . Подключение к таким веб-серверам не осуществляться без регистрации. Если вы столкнулись с такой проблемой, обратитесь за помощью: contact Check Point Support.

Мобильные приложения и мобильные браузеры плохо работают с HTTPS Inspection. Эти клиенты не могут вынужденно доверять Security Gateway's Certificate Authority (CA).

Некоторые приложения выдают предупреждения, а другие просто блокируют трафик.

Рекомендуется либо ограничить трафик мобильных приложений для большей безопасности, либо создать правила обхода для трафика, исходящего из мобильных устройств (например, в соответствии с IP-адресом точки доступа Wi-Fi).

Сервисы обновлений (например, обновлений Microsoft) косвенно обходят базы правил HTTPS Inspection.

Начиная с R76, функция категоризации веб-сайтов «Categorize HTTPS sites» (в сочетании с URL Filtering) позволяет классифицировать HTTPS сайты без активации HTTPS inspection для определения содержания трафика, основанного на FQDN сертификата сервера (SmartDashboard — перейдите к «Application & URL Filtering» на вкладке — на левой панели, перейдите в раздел «Advanced «- выберите «Engine Settings» – в разделе «URL Filtering», далее — «Categorize HTTPS sites»).

Функция «Categorize HTTPS sites» не выполняет проверку трафика. Политики, основанные на категоризированной проверке, должны принимать во внимание более низкий уровень конфиденциальности по сравнению с HTTPS Inspection.

Если опция «Categorize HTTPS sites» включена:

• Сертификат сервера доступен для обнаружения и утвержден.
• Если сервер является достоверным, то DN извлекается из сертификата.
• DN используется для категоризации сайта

Опция «The Categorize HTTPS sites» не работает, если:

• HTTPS Inspection включен·
• Существует прокси между сайтом назначения и шлюзом безопасности (или функцией шлюза безопасности, подобной прокси-серверу).

HTTPS Inspection создает дополнительную нагрузку на процессор шлюза безопасности по следующим причинам:

• Истечение срока SSL сертификата, шифрования / дешифрования и прекращение действия TCP, которые потребляют ресурсы процессора (Примечание: скорость SSL handshake была значительно улучшена в R77.30 — см sk103081 and to sk104717).
• Дополнительный трафик проверяется с помощью блейдов безопасности.

Существует возможность приблизиться к эффекту активации HTTPS Inspection в следующих ситуациях:

• Представляя типичный, конфигурацию исходящего (низкий или отсутствует входящий трафик по протоколу HTTPS Inspection) с 36% HTTPS.
• Использование R77.30 либо с NGTP (Firewall, IPS, контроль приложений, фильтрации URL-адресов, Антивирус, и Анти-бот), или NGFW (брандмауэр, IPS и контроль приложений) программного обеспечения лезвия для осмотра.
• Сценарий ЦОД требует специального моделирования.

Рациональное, что под отказы написано выше, влияние на требуемую мощность безопасности (СПУ) 60% до 100% выше, в зависимости от включенных лопастей программного обеспечения (чем больше лопасти уже включен, тем меньше дополнительное воздействие на HTTPS инспекции будет ).

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

• на коэффициент 1,6 для конфигурации NGTP;
• на коэффициент 2 для конфигурации NGFW.

Для партнёров Check Point: см sk108757 — How to estimate the performance impact of HTTPS Inspection using the Appliance Sizing Tool.

• Всегда запускайте окно поддержки перед внесением любых исправлений.
• Свяжитесь со службой поддержки Check Point для получения точных инструкций по внесению исправлений.
• В кластерной среде, исправления должны быть собраны для всех членов кластера.
• Для уменьшения нагрузки на процессор шлюза безопасности, исправления в ядре могут быть запущены только для определённых CoreXL Instances FW.

Самый безопасный способ сделать это — запустить исправления в ядре на Instances:

• # fw ctl debug 0
  # fw ctl debug -buf 32000
  # fw ctl debug -m MODULE + FLAGS
  # fw -i 0 ctl kdebug -T -f > /var/log/debug.txt
• См Kernel Debug flags (R75.40VS, R76, R77, R77.10, R77.20, R77.30)

WSTLSD daemon настраивает SSL handshake для HTTPS Inspected.

См sk105559 — How to debug WSTLSD daemon.

Обратите внимание: Данные исправления в ядре могут привести к высокой нагрузке на процессор шлюза безопасности. Обратитесь к окну поддержки.

1. Подготовка исправлений:

[Expert@HostName:0]# fw ctl debug 0
[Expert@HostName:0]# fw ctl debug -buf 32000
[Expert@HostName:0]# fw ctl debug -m fw + conn drop cptls

1. Проверка исправлений:

[Expert@HostName:0]# fw ctl debug -m fw

На выходе размер исправлений должен составить 32000KB, а все опции должны быть запущены в предыдущем шаге.

1. Начало исправлений:

[Expert@HostName:0]# fw ctl kdebug —T —f > /var/log/debug.txt

1. Захват трафика:

См sk30583 — What is FW Monitor?.
Он также может потребоваться для захвата трафика с TCPdump.

1. Повторное внесение исправлений :

Убедитесь, что проблема повторилась и соберите все соответствующие скриншоты / журналы.

1. Прекращение внесения исправлений:

Нажмите CTRL+C и запускайте
[Expert@HostName:0]# fw ctl debug 0

1. Соберите следующие файлы:

1. /var/log/debug.txt
2. /var/log/messages*
3. захват трафика (s)
4. CPinfo файл из Security Gateway(s) / Cluster members
5. CPinfo файл из Server Security Management Server / Domain Management Server

Обратите внимание: Данные исправления в ядре могут привести к высокой нагрузке на процессор шлюза безопасности. Обратитесь к окну поддержки.

1. Подготовка исправлений:

[Expert@HostName:0]# fw ctl debug 0
[Expert@HostName:0]# fw ctl debug -buf 32000
[Expert@HostName:0]# fw ctl debug -m fw + conn drop
[Expert@HostName:0]# fw ctl debug -m NRB all
[Expert@HostName:0]# fw ctl debug -m WS + connection info module pkt_dump policy session spii ssl_insp vs

1. Проверка исправлений:

[Expert@HostName:0]# fw ctl debug -m fw
[Expert@HostName:0]# fw ctl debug -m NRB
[Expert@HostName:0]# fw ctl debug -m WS

На выходе размер исправлений должен составить 32000KB, а все опции должны быть запущены в предыдущем шаге.

1. Начало исправлений:

[Expert@HostName:0]# fw ctl kdebug -T -f > /var/log/debug.txt

1. Захват трафика:

См sk30583 — What is FW Monitor?.
Он также может потребоваться для захвата трафика с TCPdump.

1. Повторное внесение исправлений:

Убедитесь, что проблема повторилась и соберите все соответствующие скриншоты / журналы.

1. Прекращение внесения исправлений:

Нажмите CTRL+C и запускайте
[Expert@HostName:0]# fw ctl debug 0

1. Соберите следующие файлы:

1. /var/log/debug.txt
2. /var/log/messages*
3. захват трафика (s)
4. CPinfo файл из Security Gateway(s) / Cluster members
5. CPinfo файл из Server Security Management Server / Domain Management Server

Обратите внимание: эта часть статьи предполагает наличие уровня доступа «Advanced» или выше.

• Конфигурация

• sk65123 — HTTPS Inspection FAQ
• sk104717 — HTTPS Inspection Enhancements in R77.30
• sk101223 — MultiCore Support for SSL in R77.20 and above
• sk104562 — Supported cipher suites for HTTPS Inspection
• sk108654 — How to control support for SSLv2 handshake in HTTPS Inspection
• sk108641 — How to Renew or Import a new HTTPS Inspection certificate
• sk90840 — HTTPS Inspection is not supported for IPv6 traffic in R76 / R77 and above
• sk106996 — «HTTP Strict Transport Security» (HSTS) header handling in HTTPS Inspection
• sk74000 — Disabling TLS 1.1 and 1.2 in Portals and HTTPS Inspection
• sk108757 — How to estimate the performance impact of HTTPS Inspection using the Appliance Sizing Tool
• sk97638 — Check Point Processes and Daemons

• Исправление неполадок

• sk98348 — Best Practices — Security Gateway Performance
• sk108653 — Security Gateway with enabled HTTPS Inspection crashes repeatedly
• sk92888 — Enabling HTTPS Inspection causes some applications to stop working
• sk108894 — Difficulties in connecting to untrusted sites when both HTTPS Inspection and CoreXL Dynamic Dispatcher are enabled
• sk64166 — HTTPS Inspection logs are misleading
• sk108187 — There are no logs for HTTPS Inspection, although it is enabled and configured for inbound inspection.html
• sk101166 — HTTPS Inspection ignores HTTPS traffic via proxy with authentication
• sk92839 — HTTPS Inspection and 'X-Forward-For' (XFF) HTTP header when inspecting proxy traffic
• sk96125 — Windows Update fails when HTTPS Inspection is enabled on Check Point Security Gateway
• sk92870 — Cannot delete the current HTTPS Inspection certificate
• sk98025 — HTTPS inspection with 3rd party certificate shows browser error
• sk92654 — HTTPS traffic is not inspected although HTTPS Inspection is enabled and Identity Awareness is used
• sk101791 — HTTPS Inspection «Bypass» rule that contains Dynamic Object does not work
• sk93184 — Users do not receive UserCheck page for blocked HTTPS content
• sk107325 — No access to HTTPS sites from Firefox when HTTPS Inspection is enabled
• sk102721 — UserCheck page is displayed twice when Application Control and HTTPS Inspection are enabled, and user is redirected from HTTP to HTTPS web site
• sk104095 — RC4 cipher is allowed for Inbound HTTPS inspection
• sk106296 — Not able to connect to HTTPS web sites that use ECDHE cipher suites after upgrading to R77.30
• sk105538 — Security Gateway with enabled HTTPS Inspection might crash during high traffic load

• Внесение правок

• sk105559 — How to debug WSTLSD daemon