Akses telemetri visibilitas serangan DDoS

Google Cloud Armor Enterprise memungkinkan Anda menggunakan Cloud Logging dan Cloud Monitoring untuk menganalisis serangan DDoS dan sumbernya.

Google Cloud Armor secara otomatis mendeteksi dan memitigasi serangan lapisan jaringan (Lapisan 3) dan lapisan transportasi (Lapisan 4), melakukan mitigasi sebelum menerapkan kebijakan keamanan dan mengevaluasi hanya permintaan yang dibentuk dengan baik terhadap aturan kebijakan keamanan Anda. Oleh karena itu, traffic yang menurun akibat perlindungan DDoS yang selalu aktif tidak muncul dalam telemetri untuk kebijakan keamanan atau backend.

Sebagai gantinya, metrik Cloud Logging dan Cloud Monitoring untuk peristiwa mitigasi DDoS adalah bagian dari visibilitas serangan DDoS, sebuah fitur yang tersedia secara eksklusif untuk pelanggan Google Cloud Armor Enterprise. Bagian berikut menjelaskan cara menggunakan Logging dan Monitoring untuk menganalisis serangan DDoS dan sumbernya. Visibilitas serangan DDoS tersedia untuk jenis load balancer berikut:

  • Load Balancer Aplikasi eksternal global
  • Load Balancer Aplikasi Klasik

Jika Anda menggunakan referensi layanan lintas project, Anda hanya dapat melihat telemetri dan logging yang terkait dengan visibilitas serangan DDoS di project host atau layanan yang mencakup frontend dan peta URL load balancer Anda. Anda tidak dapat melihat telemetri dan logging di project layanan yang mencakup layanan backend.

Untuk memastikan pelaporan dan pencatatan log yang tepat, Cloud Armor memerlukan akses ke log berikut. Log ini harus disimpan di Cloud Logging, atau dirutekan ke bucket logging yang dapat diakses Cloud Armor.

  • networksecurity.googleapis.com/dos_attack
  • networksecurity.googleapis.com/network_dos_attack
  • networksecurity.googleapis.com/network_dos_attack_mitigations

Log peristiwa mitigasi serangan Cloud Logging

Cloud Armor membuat tiga jenis entri log peristiwa saat memitigasi serangan DDoS. Format log mencakup analisis alamat IP sumber dan geografi jika memungkinkan. Bagian berikut memberikan contoh format log untuk setiap jenis log peristiwa:

Mitigasi dimulai

   {
      "id": "20220101_1235_mitigiation_1.2.3.4",
      "mitigationType": "MITIGATION_STARTED",
      "targetVip": "1.2.3.4",
      "totalVolume": {
         "pps": "1234000",
         "bps": "9876000000"
      },
      "started": {
         "totalAttackVolume": {
            "pps": "1000000",
            "bps": "9000000000"
      },
      "topSourceIp": [
         {
            "ipAddress": "1.2.3.4",
            "volume": {
            "pps": "10000",
            "bps": "2000000"
            }
         },
         {
            "ipAddress": "2.3.4.5",
            "volume": {
            "pps": "5000",
            "bps": "1000000"
            }
         }
      ],
      "topSourceGeo": [
         {
            "geo": "US",
            "volume": {
            "pps": "100000",
            "bps": "20000000"
            }
         }
      ]
      }
   }
   

Mitigasi sedang berlangsung

   {
      "id": "20220101_1235_mitigiation_1.2.3.4",
      "mitigationType": "MITIGATION_ONGOING",
      "targetVip": "1.2.3.4",
      "totalVolume": {
         "pps": "1234000",
         "bps": "9876000000"
      },
      "ongoing": {
         "totalAttackVolume": {
            "pps": "1000000",
            "bps": "9000000000"
         },
         "topSourceIp": [
         {
            "ipAddress": "1.2.3.4",
            "volume": {
               "pps": "10000",
               "bps": "2000000"
            }
         },
         {
            "ipAddress": "2.3.4.5",
            "volume": {
               "pps": "5000",
               "bps": "1000000"
            }
         }
      ],
      "topSourceGeo": [
         {
            "geo": "US",
            "volume": {
               "pps": "100000",
               "bps": "20000000"
            }
         }
      ]
      }
   }
   

Mitigasi berakhir

   {
      "id": "20220101_1235_mitigiation_1.2.3.4",
      "mitigationType": "MITIGATION_ENDED",
      "targetVip": "1.2.3.4",
      "totalVolume": {
         "pps": "2314000",
         "bps": "9768000000"
      },
      "ended": {
         "attackDurationSeconds": 345
      }
   }
   

Di konsol Google Cloud , buka halaman Logs Explorer dan lihat resource ProtectedEndpoint.

Buka Logs Explorer

Atau, Anda dapat melihat nama log network_dos_attack_mitigations.

Metrik Cloud Monitoring

Metrik telemetri mitigasi DDoS terlihat di bagian resource Protected Network Endpoint (ProtectedEndpoint), yang eksklusif untuk alamat IP virtual lapisan aplikasi (Lapisan 7) yang terdaftar di Google Cloud Armor Enterprise. Metrik yang tersedia adalah sebagai berikut:

  • Byte masuk (/dos/ingress_bytes)
  • Paket masuk (/dos/ingress_packets)

Anda dapat mengelompokkan dan memfilter metrik sebelumnya berdasarkan label berikut:

Label Nilai
project_id ID project Anda yang terdaftar di Cloud Armor Enterprise.
location Lokasi endpoint yang dilindungi.
vip Alamat IP virtual endpoint yang dilindungi.
drop_status Nilai yang mungkin:
  • processed: Traffic tidak ditolak oleh perlindungan DDoS yang selalu aktif di Cloud Armor, yang berarti traffic tersebut dievaluasi berdasarkan kebijakan keamanan Anda.
  • blocked: Traffic ditolak oleh perlindungan DDoS yang selalu aktif dari Cloud Armor dan dihentikan sebelum dievaluasi berdasarkan kebijakan keamanan Anda.

Di Google Cloud konsol, buka halaman Metrics Explorer.

Buka Metrics Explorer

Menafsirkan metrik telemetri untuk alamat IP virtual dengan volume traffic rendah

Untuk alamat IP virtual (VIP) yang menerima kurang dari 100.000 paket per detik, sebaiknya gunakan jangka waktu yang lebih panjang untuk melihat metrik di Cloud Monitoring. Misalnya, jika VIP dengan traffic lebih tinggi dapat menggunakan ALIGN_RATE satu menit, sebaiknya gunakan ALIGN_RATE 10 menit. Menggunakan jangka waktu yang lebih panjang akan membantu mengurangi volume artefak yang dihasilkan dari rasio sinyal terhadap derau yang buruk.

Selain itu, beberapa komponen kecepatan Cloud Armor membatalkan traffic (kecepatan pembatalan) disimpulkan dengan cara statistik, dan mungkin kurang akurat untuk VIP dengan traffic rendah. Artinya, selama serangan DDoS, rasio pelepasan paket yang dilaporkan Cloud Monitoring mungkin sedikit lebih rendah daripada rasio pelepasan paket yang sebenarnya. Hal ini mengurangi artefak statistik yang dapat menyebabkan perkiraan berlebih volume traffic yang dibatalkan, terutama untuk VIP yang menerima volume traffic rendah dan tidak diserang.