HTTPS Inspection — развертывание и использование

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).

 

Содержание статьи:

  1. Введение
    1. HTTPS Inspection – входящий/исходящий трафик
    2. Постепенное развёртывание
    3. Начальная настройка
  2. Передовой опыт
    1. Настройка сертификатов
    2. Создание базовых правил HTTPS Inspection
    3. Подключение к сети интернет
  3. Дополнительная инфомрация
    1. Perfect Forward Secrecy Cipher Suites (безопасность кодировки)
    2. Мобильные приложения
    3. Сервисы обновления
    4. Классификация HTTPS vs. HTTPS Inspection
  4. Производительность
  5. Устанение неполадок
    1. Примечания
    2. WSTLSD daemon (SSL handshake)
    3. HTTPS Inspection – связанные вопросы
    4. HTTPS Inspection – соответствие требованиям
  6. Дополнительная документация
  7. Связанные решения
  8. История изменений

(I) Введение

HTTPS InspectionИнтернет-трафик 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

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

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

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

 

Поток на Security Gateway:

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

HTTPS Inspection

 

 

 

 

 

 

 

 

 

 

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

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

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

Поток на Security Gateway:

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

HTTPS Inspection

 

 

 

 

 

 

 

 

 

(I-2) Введение: постепенное развертывание

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

(I-3) Введение: Первоначальная настройка

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

(II) Передовой опыт

(II-1) Передовой опыт: Настройка сертификатов

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

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

HTTPS Inspection

 

 

 

 

 

 

 

 

 

 

HTTPS Inspection

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

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

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

HTTPS Inspection

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

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

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

(II-2) Передовой опыт: Создание HTTPS Inspection Rule Base

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

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

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

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

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

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

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

HTTPS Inspection

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

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

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

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

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

HTTPS Inspection

 

 

 

 

 

 

 

 

 

 

 

 

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

( II- 3 ) ​​Передовой опыт: подключение к Интернету

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

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

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

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

HTTPS Inspection

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

(III ) Дополнительная информация

( III- 1 ) Дополнительная информация : Идеальная прямая безопасность шифров
  • Perfect Forward Secrecy (PFS) — введение

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

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.20 и ниже подключение к веб-серверам невозможно без регистрации. Примером такого веб-сервера служит tumblr.com.

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

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

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

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

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

( III- 2 ) Дополнительная информация: Мобильные приложения

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

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

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

(III -3 ) Дополнительная информация : Update Services  (сервисы обновлений)

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

(III-4) Дополнительная информация: Categorized HTTPS против HTTPS Inspection

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 включен·
  • Существует прокси между сайтом назначения и шлюзом безопасности (или функцией шлюза безопасности, подобной прокси-серверу).

(IV) Производительность

 

HTTPS InspectionHTTPS 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.

(V) Исправление ошибок

(V-1) Исправление ошибок: примечания

  • HTTPS InspectionВсегда запускайте окно поддержки перед внесением любых исправлений.
  • Свяжитесь со службой поддержки 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.40VSR76R77R77.10R77.20R77.30)

(V-2) Исправление ошибок: WSTLSD daemon

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

См sk105559 — How to debug WSTLSD daemon.

(V-3) Исправление ошибок: связанные с HTTPS Inspection вопросы

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

  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 kdebugTf > /var/log/debug.txt

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

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

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

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

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

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

  1. Соберите следующие файлы:
    • /var/log/debug.txt
    • /var/log/messages*
    • захват трафика (s)
    • CPinfo файл из Security Gateway(s) / Cluster members
    • CPinfo файл из Server Security Management Server / Domain Management Server

(V-4) Исправление ошибок: политики соответствия HTTPS Inspection

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

  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. Соберите следующие файлы:
    • /var/log/debug.txt
    • /var/log/messages*
    • захват трафика (s)
    • CPinfo файл из Security Gateway(s) / Cluster members
    • CPinfo файл из Server Security Management Server / Domain Management Server

(VI) Связанная документация

  • Руководство по управлению шлюзом безопасности (R20,R75.40R75.40VSR76R77— Глава «Defining an Internet Access Policy» — (Определение политики доступа в Интернет) — «HTTPS Inspection»
  • Руководство по управлению URL-фильтрацией и контролем приложений (R20,R75.40R75.40VSR76R77) — Глава «Managing Application Control and URL Filtering» — «HTTPS Inspection»
  • Руководство по управлению Data Loss Prevention (предотвращению потери данных) (R20R75.40R75.40VSR76R77) — Глава » Installation and Configuration » — «HTTPS Inspection»
  • Руководство по управлению IPS (R20,R75.40R75.40VSR76R77) — Глава » Monitoring Traffic» (Мониторинг трафика) — «HTTPS Inspection»
  • Руководство администратора по предотвращению угроз (Threat Prevention) Guide (R76,R77) — Глава » Using Threat Prevention with HTTPS Traffic» (Использование Threat Prevention с HTTPS трафиком)
  • Руководство по управлению Anti-Bot and Anti-Virus (40,R75.40VS) — Глава «Managing Anti-Bot and Anti-Virus»  — «HTTPS Inspection»

(VII) Связанные решения

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

  • Конфигурация
  • Исправление неполадок
  • Внесение правок

(VIII) История изменений

Дата Описание
10 декабря 2015
  • Раздел «Related solutions» — добавление связанных решений
18 ноября 2015
  • Раздел «Performance» (производительность) section — Раздел Производительность «, — добавил связанной решение (для Check Point Партнеры) (для партнёров Check Point)
13 ноября 2015
  • Раздел «Related solutions» — добавление связанных решений
12 ноября 2015
  • Первый выход этой статьи

 

ID решения sk108202
Продукт HTTPS Inspection
Версия Все
ОС Gaia, SecurePlatform 2.6
Платформа / Модель Все
Дата создания 12-ноября 2015
Последнее изменение 10-декабря 2015