Memecahkan masalah Cloud Armor

Gunakan petunjuk ini untuk memecahkan masalah terkait kebijakan keamanan Google Cloud Armor.

Masalah umum

Men-debug kebijakan keamanan

Jika Anda memerlukan informasi tambahan tentang peristiwa tertentu yang memicu aturan yang telah dikonfigurasi sebelumnya, baca bagian Penggunaan logging permintaan, lalu aktifkan logging panjang. Cloud Logging mencatat tingkat detail yang lebih tinggi dalam log Anda, yang dapat Anda gunakan untuk menganalisis dan men-debug kebijakan serta aturan.

Meskipun aturan penolakan dikonfigurasi dalam kebijakan keamanan Cloud Armor, traffic tetap diizinkan.

Untuk mengatasi masalah tersebut, ikuti langkah-langkah berikut:

Pastikan kebijakan keamanan Cloud Armor telah diterapkan pada layanan backend target. Misalnya, perintah berikut menggambarkan semua data yang terkait dengan layanan backend BACKEND. Hasil yang ditampilkan harus mencakup nama kebijakan keamanan Cloud Armor yang terkait dengan layanan backend ini.
```
gcloud compute backend-services describe BACKEND
```

Tinjau log HTTP(S) untuk menentukan kebijakan dan aturan mana yang cocok untuk traffic Anda beserta tindakan yang terkait. Untuk melihat log, gunakan Cloud Logging.

Berikut adalah contoh log permintaan yang diizinkan dengan kolom menarik yang ditandai. Periksa kolom berikut dan pastikan seluruh kolom cocok dengan aturan yang Anda konfigurasi untuk menolak traffic:

configuredAction harus cocok dengan tindakan yang dikonfigurasi dalam aturan.
name harus cocok dengan nama kebijakan keamanan Cloud Armor yang dilampirkan ke layanan backend ini.
outcome harus cocok dengan configuredAction.
priority harus cocok dengan nomor prioritas aturan.

  httpRequest:
   remoteIp: 104.133.0.95
   requestMethod: GET
   requestSize: '801'
   requestUrl: http://74.125.67.38/
   responseSize: '246'
   serverIp: 10.132.0.4
   status: 200
   userAgent: curl/7.35.0
     insertId: ajvis5ev4i60
     internalId:
       projectNumber: '895280006100'
     jsonPayload:
       '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry
       enforcedSecurityPolicy:
         configuredAction: ACCEPT
         name: mydev-policy-log-test1
         outcome: ACCEPT
         priority: 2147483647
       statusDetails: response_sent_by_backend
     logName: projects/mydev-staging/logs/requests
     resource:
       labels:
         backend_service_name: BACKEND_SERVICE_NAME
         forwarding_rule_name: FORWARDING_RULE_NAME
         project_id: PROJECT_ID
         target_proxy_name: TARGET_HTTP_PROXY_NAME
         url_map_name: URL_MAP_NAME
         zone: global
       type: http_load_balancer
     severity: INFO
     timestamp: '2017-04-18T18:57:05.845960288Z'

Tinjau hierarki aturan untuk memastikan aturan yang benar telah cocok. Mungkin ada aturan prioritas yang lebih tinggi dengan tindakan izinkan yang cocok dengan traffic Anda. Gunakan perintah describe pada security-policies di Google Cloud CLI untuk melihat isi kebijakan keamanan Cloud Armor.

Misalnya, contoh berikut menunjukkan bagaimana aturan izin dengan prioritas lebih tinggi (pada prioritas 100) cocok dengan traffic yang berasal dari alamat IP 1.2.3.4, sehingga mencegah aturan penolakan dengan prioritas lebih rendah (pada prioritas 200) untuk aktif dan memblokir traffic.

gcloud compute security-policies describe POLICY_NAME

Output:

  creationTimestamp: '2017-04-18T14:47:58.045-07:00
  description: ''
  fingerprint: Yu5spBjdoC0=
  id: '2560355463394441057'
  kind: compute#securityPolicy
  name: POLICY_NAME
  rules:
  -action: allow
   description: allow high priority rule
   kind: compute#securityPolicyRule
   match:
     srcIpRanges:
     -'1.2.3.4/32'
   preview: false
   priority: 100
  -action: deny
   description: deny lower priority rule
   kind: compute#securityPolicyRule
   match:
     srcIpRanges:
     -'1.2.3.0/24
   preview: false
   priority: 200
  -action: deny
   description: default rule
   kind: compute#securityPolicyRule
   match:
     srcIpRanges:
     -'*'
   preview: false
   priority: 2147483647
   selfLink: http://www.googleapis.com/compute/v1/projects/bigclustertestdev0-devconsole/global/securityPolicies/sp

Aturan yang telah dikonfigurasi sebelumnya menampilkan positif palsu

Deteksi XSS dan SQLi didasarkan pada pencocokan signature statis pada header permintaan HTTP dan parameter L7 lainnya. Pola ekspresi reguler ini rentan terhadap positif palsu. Anda dapat menggunakan aturan yang telah dikonfigurasi sebelumnya untuk deteksi XSS dan SQLi dalam mode pratinjau, lalu memeriksa log untuk mengetahui apakah ada positif palsu.

Jika menemukan positif palsu, Anda dapat membandingkan konten traffic dengan aturan OWASP CRS. Jika aturan tidak valid atau tidak relevan, nonaktifkan menggunakan ekspresi evaluatePreconfiguredWaf, dan tentukan ID aturan dalam argumen exclude ID list.

Setelah meninjau log dan menghapus semua positif palsu, nonaktifkan mode pratinjau.

Untuk menambahkan aturan yang telah dikonfigurasi sebelumnya dalam mode pratinjau:

Buat kebijakan keamanan dengan serangkaian ekspresi yang telah dikonfigurasi sebelumnya dalam mode pratinjau:

gcloud compute security-policies rules create 1000
   --security-policy POLICY_NAME
   --expression "evaluatePreconfiguredWaf('xss-stable')"
   --action deny-403
   --preview

Tinjau log HTTP(S) untuk kolom permintaan HTTP seperti url dan cookie. Misalnya, requestUrl membandingkan secara positif dengan aturan OWASP CRS ID 941180:

httpRequest:
  remoteIp: 104.133.0.95
  requestMethod: GET
  requestSize: '801'
  requestUrl: http://74.125.67.38/foo?document.cookie=1010"
  responseSize: '246'
  serverIp: 10.132.0.4
  status: 200
  userAgent: curl/7.35.0
insertId: ajvis5ev4i60
internalId:
  projectNumber: '895280006100'
jsonPayload:
  '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry
  enforcedSecurityPolicy:
    configuredAction: ACCEPT
    name: POLICY_NAME
    outcome: ACCEPT
    priority: 2147483647
    preconfiguredExprIds: [ 'owasp-crs-v030001-id941180-xss' ]
  statusDetails: response_sent_by_backend
logName: projects/mydev-staging/logs/requests
resource:
  labels:
    backend_service_name: BACKEND_SERVICE
    forwarding_rule_name: mydev-forwarding-rule
    project_id: mydev-staging
    target_proxy_name: mydev-target-http-proxy
    url_map_name: mydev-url-map
    zone: global
  type: http_load_balancer
severity: INFO
timestamp: '2017-04-18T18:57:05.845960288Z'

Kecualikan aturan OWASP CRS ID 941180 dengan memperbarui aturan tersebut dalam kebijakan keamanan Cloud Armor:

gcloud compute security-policies rules update 1000 \
    --security-policy POLICY_NAME \
    --expression "evaluatePreconfiguredWaf('xss-stable', ['owasp-crs-v030001-id941180-xss'])" \
    --action deny-403 \
    --preview

Tinjau kembali log, lalu nonaktifkan mode pratinjau untuk menerapkan aturan.

Klien dengan signature yang ditolak tidak diblokir atau ditolak

Jika Anda menggunakan Cloud Armor bersama Cloud CDN, kebijakan keamanan hanya diterapkan untuk permintaan konten dinamis, cache yang tidak ditemukan, atau permintaan lain yang ditujukan ke server asal CDN. Cache ditemukan akan ditampilkan meskipun kebijakan keamanan Cloud Armor downstream mencegah permintaan tersebut untuk menjangkau server asal CDN.

Masalah terkait daftar alamat IP bernama

Bagian ini menyediakan informasi untuk menyelesaikan masalah terkait daftar alamat IP bernama.

Alamat IP dalam daftar alamat IP bernama

Alamat IP dalam daftar selalu cocok dengan alamat IP di situs penyedia yang tercantum dalam panduan daftar alamat IP bernama Cloud Armor. Jika ada pertanyaan mengenai hal ini, hubungi tim Dukungan Cloud.

Alamat IP dalam daftar alamat IP bernama sudah tidak berlaku di Cloud Armor

Cloud Armor menyinkronkan daftar alamat IP-nya dengan penyedia daftar alamat IP setiap hari. Mungkin terdapat data lama yang tertunda beberapa jam atau sehari dari data di penyedia. Namun, jika Anda yakin bahwa data lama mengalami keterlambatan lebih dari yang diperkirakan, misalnya lebih dari seminggu, hubungi tim Dukungan Cloud.

Kesulitan dalam membuat kebijakan keamanan yang merujuk pada daftar alamat IP bernama.

Anda mungkin mencoba membuat kebijakan keamanan yang merujuk pada daftar alamat IP bernama, menggunakan perintah seperti berikut:

gcloud compute security-policies rules create 750 \
    --security-policy my \
    --expression "evaluatePreconfiguredExpr('sourceiplist-example')" \
    --action "allow"

Jika perintah gagal, pesan error yang Anda lihat akan terlihat seperti berikut:

ERROR: (gcloud.compute.security-policies.rules.create) Could not fetch resource:
 - Invalid value for field 'resource.match.expr': '{  "expression": "evaluatePreconfiguredExpr(\u0027sourceiplist-example\u0027)"}'.
Error parsing Cloud Armor rule matcher expression: sourceiplist-example
is not a valid preconfigured expression set.

Pastikan bahwa penyedia tertentu didukung, dan bahwa nama daftar alamat IP diberikan dengan benar. Anda dapat memeriksanya menggunakan perintah gcloud berikut untuk menampilkan daftar rangkaian ekspresi yang telah dikonfigurasi sebelumnya:

gcloud compute security-policies list-preconfigured-expression-sets

Traffic terblokir meskipun ada aturan yang telah dikonfigurasi sebelumnya untuk daftar alamat IP bernama yang diizinkan.

Anda mungkin menemukan bahwa traffic diblokir dari alamat IP yang ada dalam daftar alamat IP bernama:

Pastikan traffic berasal dari alamat IP yang terdaftar dalam daftar alamat IP bernama yang diizinkan.
Periksa apakah ada aturan keamanan lain dengan prioritas yang lebih tinggi yang dapat memblokir traffic. Jika Anda masih menemukan masalah ini, hubungi tim Dukungan Cloud.
Pastikan kebijakan keamanan terhubung ke layanan backend yang benar:
```
gcloud compute backend-services describe BACKEND_SERVICE
```

Periksa aturan yang ada dalam kebijakan keamanan. Contoh:

 gcloud compute security-policies describe POLICY_NAME

Perintah menampilkan informasi yang serupa dengan berikut ini:

---
…
name: POLICY_NAME
rules:
-action: allow
 description: allow fastly ip addresses
 kind: compute#securityPolicyRule
 match:
    expr:
      expression: evaluatePreconfiguredExpr('sourceiplist-fastly')
 preview: false
 priority: 100
-action: deny(403)
 description: Default rule, higher priority overrides it
 kind: compute#securityPolicyRule
 match:
    config:
      srcIpRanges:
      -'*'
    versionedExpr: SRC_IPS_V1
 preview: false
 priority: 2147483647
-action: deny(404)
 description: deny altostrat referer
 kind: compute#securityPolicyRule
 match:
    expr:
      expression: request.headers['Referer'].contains('altostrat')
 preview: false
 priority: 50
…

Kebijakan keamanan sebelumnya berisi tiga aturan: aturan penolakan default, aturan izin untuk alamat IP Fastly, dan aturan penolakan untuk perujuk yang berisi altostrat. Prioritas masing-masing juga tercantum.

Tinjau log untuk menentukan aturan mana yang cocok dengan traffic Anda dan tindakan terkait. Untuk mengetahui informasi tentang logging, lihat Menggunakan Logs Explorer.

Berikut adalah contoh log:
```
 httpRequest: {
    referer: "http://www.altostrat.com/"
    remoteIp: "23.230.32.10"
    requestMethod: "HEAD"
    requestSize: "79"
    requestUrl: "http://www.example.com/"
    responseSize: "258"
    status: 404
    userAgent: "Mozilla/5.0"
  }
  …
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
    enforcedSecurityPolicy: {
      configuredAction: "DENY"
      name: "POLICY_NAME"
      outcome: "DENY"
      priority: 50
    }
    statusDetails: "denied_by_security_policy"
  }
  …
```
Dari log sebelumnya, permintaan berasal dari 23.230.32.10, yang terdaftar dalam daftar alamat IP publik Fastly. Namun, permintaan tersebut dicocokkan dengan aturan penolakan yang memiliki prioritas lebih tinggi, yaitu 50. Jika dibandingkan dengan yang tercantum dalam kebijakan keamanan, aturan tersebut sesuai dengan aturan penolakan untuk perujuk yang berisi altostrat. Karena permintaan memiliki perujuk http://www.altostrat.com/, penerapan aturan keamanan berfungsi dengan benar.

Masalah terkait temuan Security Command Center

Bagian ini berisi informasi mengenai masalah yang terkait dengan temuan Security Command Center.

Kartu Cloud Armor tidak muncul di Security Command Center

Aktifkan temuan Cloud Armor di antarmuka Security Command Center.

Temuan dari Cloud Armor tidak muncul di Security Command Center

Jika temuan dari Cloud Armor tidak muncul di Security Command Center, traffic ke layanan backend mungkin tidak memenuhi kriteria untuk memunculkan temuan.

Untuk pertanyaan tentang volume traffic ke backend Anda, periksa statistik permintaan di dasbor Cloud Monitoring pada bagian Kebijakan Keamanan Jaringan.

Temuan tidak relevan

Untuk mendapatkan bantuan terkait masalah ini, hubungi tim Dukungan Cloud.

Masalah terkait Google Cloud Armor Adaptive Protection

Gunakan petunjuk berikut untuk membantu Anda menyelesaikan masalah terkait Adaptive Protection.

Adaptive Protection diaktifkan untuk kebijakan keamanan, tetapi tidak ada log di Cloud Logging

Log Adaptive Protection dihasilkan secara terpisah dari log permintaan Cloud Armor dan muncul di bagian resource yang berbeda di Cloud Logging. Log dan peristiwa Adaptive Protection berada di bagian resource Kebijakan Keamanan Jaringan di Cloud Logging. Sebelum Adaptive Protection mulai membuat pemberitahuan untuk serangan yang dicurigai, terdapat periode pelatihan minimal satu jam setelah Adaptive Protection diaktifkan dalam kebijakan keamanan. Selama periode pelatihan, Adaptive Protection mempelajari traffic permintaan yang masuk dan mengembangkan dasar pengukuran yang berbeda untuk setiap layanan backend yang dilindungi oleh kebijakan keamanan tersebut. Kemudian, Adaptive Protection dapat mengidentifikasi aktivitas mencurigakan.

Jika Anda mengaktifkan Adaptive Protection untuk kebijakan keamanan dan tidak melihat adanya peringatan setelah periode pelatihan selama satu jam, hal ini menunjukkan bahwa tidak ada aktivitas yang dapat diidentifikasi sebagai serangan berbahaya yang menargetkan salah satu layanan backend yang terkait dengan kebijakan keamanan.

Jika potensi serangan atau traffic yang tidak normal berlangsung dalam jangka waktu yang lebih lama, lebih dari beberapa jam, maka Adaptive Protection mulai menganggap perilaku tersebut sebagai perilaku yang normal dan tidak lagi memberikan peringatan atas pola traffic yang serupa. Setelah potensi serangan mereda dan pola traffic kembali normal, baik karena serangan telah berakhir atau Anda memblokirnya dengan aturan Cloud Armor yang sesuai, Adaptive Protection akan memberikan peringatan terhadap perilaku traffic selanjutnya yang dianggap menyimpang dari pola normal.

Adaptive Protection menganalisis traffic yang seharusnya diizinkan melalui kebijakan keamanan Cloud Armor. Jika Anda menetapkan aturan default untuk menolak akses dengan daftar traffic yang diizinkan dan dibatasi, maka Adaptive Protection hanya mendeteksi aktivitas berbahaya pada traffic yang lolos evaluasi berdasarkan daftar yang diizinkan tersebut.

Ada terlalu banyak peringatan atau terlalu banyak log di Cloud Logging dari Adaptive Protection.

Peringatan Adaptive Protection memberikan skor kepercayaan, yang menunjukkan seberapa kuat model Adaptive Protection mengidentifikasi aktivitas yang terdeteksi tidak normal dan berpotensi sebagai serangan. Anda dapat memfilter entri log tertentu melalui Cloud Logging hanya untuk menampilkan (atau meneruskan ke downstream) peringatan yang memiliki skor kepercayaan di atas ambang batas tertentu.

Adaptive Protection menyediakan mekanisme untuk melaporkan pemberitahuan sebagai positif palsu, yang dijelaskan di bagian Monitoring, memberikan masukan, dan melaporkan peristiwa yang error. Perlu diperhatikan bahwa pelaporan positif palsu mungkin tidak langsung menyebabkan perubahan pada apa yang diindikasikan oleh Adaptive Protection. Seiring waktu, model Adaptive Protection belajar bahwa pola traffic tersebut normal dan dapat diterima, dan Adaptive Protection berhenti memberikan peringatan untuk pola tersebut.

Jika peringatan Adaptive Protection terlalu sering muncul pada subset layanan backend dalam kebijakan keamanan, hal ini mungkin menunjukkan bahwa traffic normal dari layanan backend tersebut mengalami fluktuasi yang signifikan dan secara terus-menerus diidentifikasi oleh Adaptive Protection sebagai perilaku yang tidak normal. Anda dapat membuat kebijakan keamanan terpisah tanpa mengaktifkan Adaptive Protection dan menghubungkan layanan backend ini dengan kebijakan keamanan baru.

Insiden tertentu yang dilaporkan oleh Adaptive Protection dianggap sebagai positif palsu atau tidak relevan

Adaptive Protection menyediakan mekanisme untuk melaporkan pemberitahuan positif palsu. Ikuti prosedur yang dijelaskan di bagian Monitoring, memberikan masukan, dan melaporkan peristiwa yang error. Perlu diingat bahwa pelaporan positif palsu mungkin tidak langsung menyebabkan perubahan pada apa yang diindikasikan oleh Adaptive Protection. Seiring waktu, model Adaptive Protection belajar bahwa pola traffic tersebut normal dan dapat diterima, dan Adaptive Protection berhenti memberikan peringatan untuk pola tersebut.

Bagaimana cara saya mengetahui bahwa kebijakan keamanan edge sedang diterapkan?

Anda dapat memeriksa tindakan yang diambil pada kebijakan keamanan edge Anda dengan memeriksa dasbor pemantauan, metrik pemantauan, atau pencatatan setiap permintaan.

Dasbor Monitoring

Cloud Monitoring tersedia di halaman Network Security Policies di bagian Monitoring. Anda dapat menggunakan rincian berdasarkan kebijakan keamanan di halaman untuk mengukur jumlah permintaan yang diizinkan dan ditolak oleh kebijakan keamanan edge yang telah dikonfigurasi. Anda juga dapat memeriksa perincian menurut layanan backend untuk men-debug layanan backend tertentu. Untuk mengetahui detail tentang dasbor Cloud Monitoring, lihat Memantau kebijakan keamanan Cloud Armor.

Metrik pemantauan

Metrik mentah yang mengukur permintaan yang diizinkan dan ditolak tersedia untuk kebijakan keamanan edge. Untuk mengetahui informasi selengkapnya, lihat Metrik pemantauan untuk kebijakan keamanan.

Logging setiap permintaan

Keputusan kebijakan keamanan edge dicatat ke log permintaan load balancing di bagian enforcedEdgeSecurityPolicy. Ini terpisah dari enforcedSecurityPolicy, yang mencatat keputusan kebijakan keamanan backend.

Pengelolaan bot

Bagian ini berisi informasi mengenai pemecahan masalah terkait pengelolaan bot.

Pengguna tidak dikecualikan seperti yang diharapkan

Anda mungkin telah mengonfigurasi aturan kebijakan keamanan dengan tindakan pengalihan untuk penilaian reCAPTCHA, dan menemukan beberapa pengguna yang Anda anggap sah tidak dikecualikan seperti yang diharapkan. Ikuti langkah-langkah di bawah untuk memecahkan masalah.

Pertama, periksa log setiap permintaan untuk melihat apakah ada aturan kebijakan keamanan dengan prioritas lebih tinggi yang cocok dengan traffic, dimana tindakan yang diambil berbeda. Secara khusus, cari kolom configured_action dan outcome. Perhatikan bahwa agar pengguna dikecualikan, setidaknya ada dua permintaan yang terlibat. Permintaan awal dikirim tanpa cookie pengecualian, dan permintaan selanjutnya dikirim dengan cookie pengecualian apabila pengguna lulus penilaian reCAPTCHA. Oleh karena itu, diharapkan setidaknya ada dua entri log.

Jika Anda melihat GOOGLE_RECAPTCHA sebagai tindakan yang dikonfigurasi, dan REDIRECT sebagai hasilnya, permintaan dialihkan untuk penilaian reCAPTCHA;
Jika Anda melihat GOOGLE_RECAPTCHA sebagai tindakan yang dikonfigurasi, dan ACCEPT sebagai hasilnya, permintaan tersebut dikecualikan dari pengalihan untuk penilaian reCAPTCHA.
Jika Anda melihat nilai yang berbeda di kolom pada atas, aturan dengan tindakan yang berbeda telah cocok. Dalam hal ini, pengguna tidak diharapkan untuk dialihkan atau dikecualikan.

Kedua, ada beberapa persyaratan yang harus dipenuhi pengguna agar mereka dikecualikan dari pengalihan untuk penilaian reCAPTCHA.

Pengguna harus menggunakan browser.
Browser harus mengaktifkan JavaScript agar halaman pengalihan dengan JavaScript reCAPTCHA yang disematkan dapat dimuat dengan benar.
Browser harus mengaktifkan cookie agar pengaturan dan pemasangan otomatis cookie pengecualian dapat dilakukan.
Pengguna harus lulus penilaian reCAPTCHA; misalnya, mereka harus menyelesaikan tantangan pop-up jika ada.

Harap diketahui bahwa pengguna yang tidak dapat memenuhi salah satu persyaratan di atas tidak akan menerima pengecualian, meskipun aturan dengan tindakan pengalihan untuk penilaian reCAPTCHA sesuai.

Ketiga, penilaian reCAPTCHA hanya dijalankan saat halaman pengalihan yang menyematkan JavaScript reCAPTCHA dirender. Oleh karena itu, pengalihan untuk penilaian reCAPTCHA hanya berlaku untuk permintaan yang mengharapkan respons yang mengarah ke rendering halaman penuh. Permintaan lainnya, seperti pemuatan aset dalam halaman, atau permintaan yang berasal dari skrip tersemat yang tidak mengharapkan respons dirender, tidak diharapkan untuk mendapatkan penilaian reCAPTCHA. Oleh karena itu, sebaiknya Anda menerapkan tindakan ini dengan kondisi kecocokan untuk jalur URL yang memenuhi kondisi ini.

Misalnya, Anda memiliki halaman web yang berisi elemen tersemat seperti gambar, link ke halaman web lain, dan skrip. Anda tidak ingin menerapkan tindakan pengalihan untuk penilaian reCAPTCHA untuk jalur URL yang menghosting gambar, atau yang seharusnya diakses oleh skrip yang tidak memerlukan render halaman penuh. Sebagai gantinya, Anda dapat menerapkan tindakan pengalihan untuk penilaian reCAPTCHA untuk jalur URL yang menghosting halaman web, seperti halaman web utama atau halaman web tertaut lainnya.

Terakhir, jika halaman pengalihan berhasil dirender, periksa pada Alat Developer yang disediakan oleh browser untuk melihat apakah cookie pengecualian ditetapkan dan apakah cookie tersebut dilampirkan dalam permintaan lanjutan untuk situs yang sama. Untuk mendapatkan bantuan lebih lanjut, Anda dapat menghubungi tim Dukungan Cloud.

Masalah terkait pembatasan kapasitas

Traffic tidak di-throttle seperti yang diharapkan

Anda mungkin menemukan bahwa alamat IP klien mengirimkan traffic tingkat tinggi ke aplikasi dengan kecepatan yang melebihi nilai minimum yang Anda tetapkan, tetapi traffic tidak dibatasi seperti yang Anda harapkan. Ikuti langkah-langkah berikut untuk menyelidiki masalah ini.

Pertama, pastikan apakah aturan dengan prioritas lebih tinggi mengizinkan traffic dari alamat IP tersebut. Periksa log untuk melihat apakah aturan ALLOW diaktifkan untuk alamat IP. Ini bisa berupa aturan ALLOW itu sendiri, atau dalam aturan THROTTLE atau RATE_BASED_BAN lainnya.

Jika Anda menemukan aturan dengan prioritas lebih tinggi, lakukan salah satu tindakan berikut:

Ubah prioritas untuk memastikan aturan pembatasan kecepatan memiliki prioritas yang lebih tinggi, dengan menetapkan nilai numerik yang lebih rendah.
Kecualikan alamat IP dari ekspresi yang cocok dalam aturan yang memiliki prioritas lebih tinggi.

Masalahnya juga mungkin karena nilai minimum ditetapkan dengan tidak tepat. Jika demikian, permintaan diproses dengan akurat, namun tindakan untuk permintaan yang sesuai batas tetap dijalankan. Periksa log untuk mengonfirmasi bahwa hal ini terjadi, lalu kurangi nilai minimum dalam aturan Anda.

Terakhir, alamat IP mungkin tidak cocok dengan aturan throttle atau pemblokiran berbasis kapasitas. Untuk mengatasinya, periksa kesalahan dalam kondisi kecocokan, lalu ubah kondisi kecocokan aturan ke nilai yang tepat.

Langkah berikutnya

Mendapatkan dukungan

Memecahkan masalah Cloud Armor Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.