Memecahkan masalah Google 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 Menggunakan logging permintaan, lalu aktifkan logging panjang. Cloud Logging mencatat tingkat detail yang lebih tinggi dalam log yang dapat Anda gunakan untuk menganalisis dan men-debug kebijakan dan aturan.

Traffic diizinkan meskipun aturan tolak dikonfigurasi dalam kebijakan keamanan Google Cloud Armor

Untuk memperbaikinya, ikuti langkah-langkah berikut:

  1. Pastikan kebijakan keamanan Google Cloud Armor dilampirkan ke layanan backend target. Misalnya, perintah berikut menjelaskan semua data yang terkait dengan layanan backend BACKEND. Hasil yang ditampilkan harus menyertakan nama kebijakan keamanan Google Cloud Armor yang terkait dengan layanan backend ini.

    gcloud compute backend-services describe BACKEND

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

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

    • configuredAction harus cocok dengan tindakan yang dikonfigurasi dalam aturan.
    • name harus cocok dengan nama kebijakan keamanan Google 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'

  3. Tinjau hierarki aturan untuk memastikan bahwa aturan yang benar dicocokkan. Mungkin saja ada aturan prioritas yang lebih tinggi dengan tindakan izin yang cocok dengan traffic Anda. Gunakan perintah describe di security-policies di Google Cloud CLI untuk melihat konten kebijakan keamanan Google Cloud Armor.

    Misalnya, contoh berikut menunjukkan cara aturan izin dengan prioritas lebih tinggi (dengan prioritas 100) mencocokkan traffic yang berasal dari alamat IP 1.2.3.4, sehingga mencegah aturan tolak dengan prioritas lebih rendah (dengan prioritas 200) memicu 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 tanda tangan statis pada header permintaan HTTP dan parameter L7 lainnya. Pola ekspresi reguler ini rawan terhadap positif palsu. Anda dapat menggunakan aturan yang telah dikonfigurasi sebelumnya untuk deteksi XSS dan SQLi dalam mode pratinjau, lalu memeriksa log untuk menemukan positif palsu.

Jika menemukan positif palsu, Anda dapat membandingkan konten traffic dengan aturan CRS ModSecurity. Jika aturan tidak valid atau tidak relevan, nonaktifkan dengan menggunakan ekspresi evaluatePreconfiguredExpr, 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:

  1. Buat kebijakan keamanan dengan ekspresi yang telah dikonfigurasi sebelumnya yang ditetapkan dalam mode pratinjau:

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

  2. Tinjau log HTTP(S) untuk kolom permintaan HTTP seperti url dan cookie. Misalnya, requestUrl dibandingkan secara positif dengan ID aturan CRS ModSecurity 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'

  3. Kecualikan ID aturan CRS ModSecurity 941180 dengan memperbarui aturan di kebijakan keamanan Google Cloud Armor:

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

  4. Tinjau log lagi, lalu nonaktifkan mode pratinjau untuk menerapkan aturan.

Klien dengan tanda tangan yang ditolak tidak diblokir atau ditolak

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

Mitigasi risiko pada isi POST yang melebihi 8 KB saat menggunakan aturan WAF yang telah dikonfigurasi sebelumnya

Saat aturan WAF yang telah dikonfigurasi sebelumnya dievaluasi dalam kebijakan keamanan Google Cloud Armor, hingga 8 KB isi POST akan diperiksa untuk mencocokkan tanda tangan dengan aturan WAF. Pendekatan ini memberi Anda inspeksi dan perlindungan lapisan 7 latensi rendah, sekaligus mempertahankan ketersediaan untuk pelanggan Google lainnya.

Anda dapat mengurangi risiko dari permintaan POST yang lebih besar dengan membuat aturan dalam kebijakan keamanan untuk memastikan tidak ada konten yang tidak diperiksa yang menjangkau backend Anda. Buat aturan untuk menolak traffic yang melebihi 8 KB (8192 byte) dalam ukuran isi POST. Contoh kode berikut menunjukkan cara membuat aturan ini:

gcloud compute security-policies rules create 10 \
    --security-policy my-policy \
    --expression "int(request.headers['content-length']) > 8192" \
    --action deny-403 \
    --description "Block requests great than 8KB"

Masalah terkait daftar alamat IP yang telah diberi nama

Bagian ini memberikan informasi untuk menyelesaikan masalah terkait daftar alamat IP yang dinamai.

Alamat IP dalam daftar alamat IP yang telah diberi nama

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

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

Google Cloud Armor menyinkronkan daftarnya dengan penyedia daftar alamat IP setiap hari. Data yang sudah tidak berlaku mungkin tertinggal beberapa jam atau sehari dari data di penyedia. Namun, jika Anda yakin bahwa data yang sudah tidak berlaku tertinggal lebih lama dari yang diharapkan, misalnya, lebih dari seminggu, hubungi tim Dukungan Cloud.

Kesulitan membuat kebijakan keamanan yang mereferensikan daftar alamat IP bernama

Anda dapat mencoba membuat kebijakan keamanan yang mereferensikan daftar alamat IP yang telah diberi nama, menggunakan perintah seperti ini:

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

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

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 Google Cloud Armor rule matcher expression: sourceiplist-example
is not a valid preconfigured expression set.

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

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

Traffic diblokir meskipun ada aturan yang telah dikonfigurasi sebelumnya untuk daftar yang diizinkan alamat IP yang dinamai

Anda mungkin mendapati bahwa traffic diblokir dari alamat IP yang ada dalam daftar alamat IP yang telah diberi nama:

  1. Pastikan traffic berasal dari alamat IP yang ada dalam daftar yang diizinkan alamat IP bernama.

  2. Periksa apakah ada aturan keamanan lain dengan prioritas lebih tinggi yang dapat memblokir traffic. Jika Anda masih melihat masalah ini, hubungi tim Dukungan Cloud.

  3. Pastikan kebijakan keamanan dilampirkan ke layanan backend yang benar:

    gcloud compute backend-services describe BACKEND_SERVICE

  4. Periksa aturan yang ada dalam kebijakan keamanan. Contoh:

     gcloud compute security-policies describe POLICY_NAME

    Perintah ini menampilkan informasi yang mirip 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. Prioritasnya masing-masing juga dicantumkan.

  5. 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 tercakup dalam daftar alamat IP publik Fastly. Namun, permintaan dicocokkan dengan aturan penolakan dengan prioritas yang lebih tinggi, yaitu 50. Jika dibandingkan dengan yang ada dalam kebijakan keamanan, aturan ini 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 tentang masalah terkait temuan Security Command Center.

Kartu Google Cloud Armor tidak muncul di Security Command Center

Aktifkan temuan Google Cloud Armor di antarmuka Security Command Center.

Temuan dari Google Cloud Armor tidak muncul di Security Command Center

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

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

Temuan terlalu berisik

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

Masalah dengan Google Cloud Armor Adaptive Protection

Gunakan petunjuk ini untuk membantu Anda menyelesaikan masalah terkait Perlindungan Adaptif.

Perlindungan Adaptif diaktifkan untuk kebijakan keamanan, tetapi tidak ada log di Cloud Logging

Log Adaptive Protection dibuat secara terpisah dari log permintaan Google Cloud Armor dan muncul di resource yang berbeda di Cloud Logging. Log dan peristiwa Adaptive Protection berada di bagian resource Kebijakan Keamanan Jaringan di Cloud Logging. Ada periode pelatihan minimal satu jam setelah Perlindungan Adaptif diaktifkan dalam kebijakan keamanan sebelum Perlindungan Adaptif mulai menghasilkan pemberitahuan untuk serangan yang dicurigai. 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. Perlindungan Adaptif kemudian dapat mengidentifikasi aktivitas yang mencurigakan.

Jika Anda mengaktifkan Perlindungan Adaptif untuk kebijakan keamanan dan tidak melihat pemberitahuan apa pun setelah periode pelatihan satu jam, hal ini menunjukkan bahwa tidak ada aktivitas yang dapat diidentifikasi sebagai penargetan yang berpotensi berbahaya terhadap salah satu layanan backend yang terkait dengan kebijakan keamanan tersebut.

Jika potensi serangan atau traffic anomali berlanjut dalam jangka waktu yang lebih lama, melebihi beberapa jam, Adaptive Protection akan mulai menganggap perilaku tersebut sebagai perilaku dasar pengukuran dan tidak akan terus memberikan peringatan pada pola traffic serupa. Setelah potensi serangan mereda dan pola traffic kembali ke dasar pengukuran awal, baik karena serangan berakhir atau Anda memblokirnya dengan aturan Google Cloud Armor yang sesuai, Adaptive Protection akan memberi tahu tentang perilaku traffic mendatang yang dianggap menyimpang dari dasar pengukuran.

Adaptive Protection menganalisis traffic yang akan diizinkan melalui kebijakan keamanan Google Cloud Armor. Jika Anda menetapkan aturan default untuk menolak akses dengan daftar yang diizinkan untuk traffic yang dibatasi, Perlindungan Adaptif hanya mendeteksi aktivitas berbahaya pada traffic yang lulus evaluasi sehubungan dengan daftar yang diizinkan.

Ada terlalu banyak pemberitahuan atau terlalu banyak log di Cloud Logging dari Adaptive Protection

Notifikasi Perlindungan Adaptif memberikan skor keyakinan, yang menunjukkan seberapa kuat model Perlindungan Adaptif mengidentifikasi aktivitas yang terdeteksi sebagai anomali dan berpotensi merupakan serangan. Anda dapat memfilter entri log tertentu melalui Cloud Logging agar hanya menampilkan (atau meneruskan ke downstream) pemberitahuan yang memiliki skor keyakinan di atas nilai minimum tertentu.

Adaptive Protection menyediakan mekanisme untuk melaporkan pemberitahuan sebagai positif palsu, yang dijelaskan di bagian Pemantauan, masukan, dan pelaporan error peristiwa. Perhatikan bahwa pelaporan positif palsu mungkin tidak menyebabkan perubahan langsung pada hal yang diinformasikan oleh Perlindungan Adaptif. Seiring waktu, model Perlindungan Adaptif akan mempelajari bahwa pola traffic tersebut normal dan dapat diterima, dan Perlindungan Adaptif akan berhenti memberikan pemberitahuan tentang pola ini.

Jika pemberitahuan Perlindungan Adaptif terlalu sering muncul pada sebagian layanan backend dalam kebijakan keamanan, hal ini mungkin menunjukkan bahwa traffic normal layanan backend ini memiliki fluktuasi yang signifikan yang terus-menerus diidentifikasi oleh Perlindungan Adaptif sebagai perilaku anomali. Anda dapat membuat kebijakan keamanan terpisah tanpa mengaktifkan Adaptive Protection dan mengaitkan layanan backend ini dengan kebijakan keamanan baru.

Insiden tertentu yang dilaporkan oleh Perlindungan Adaptif dianggap sebagai positif palsu atau tidak relevan

Perlindungan Adaptif menyediakan mekanisme untuk melaporkan pemberitahuan positif palsu. Ikuti prosedur yang dijelaskan di bagian Memantau, memberikan masukan, dan melaporkan error peristiwa. Perhatikan bahwa pelaporan positif palsu mungkin tidak langsung menghasilkan perubahan pada hal yang diaktifkan oleh Perlindungan Adaptif. Seiring waktu, model Perlindungan Adaptif akan mempelajari bahwa pola traffic tersebut normal dan dapat diterima, dan Perlindungan Adaptif akan berhenti memberikan pemberitahuan tentang pola ini.

Bagaimana cara mengetahui bahwa kebijakan keamanan edge saya diterapkan?

Anda dapat memeriksa tindakan yang dilakukan pada kebijakan keamanan edge dengan memeriksa dasbor pemantauan, metrik pemantauan, atau logging per permintaan.

Dasbor monitoring

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

Metrik pemantauan

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

Logging per permintaan

Keputusan kebijakan keamanan edge dicatat ke dalam log permintaan load balancing di bagian enforcedEdgeSecurityPolicy. Hal ini terpisah dari enforcedSecurityPolicy, yang merekam keputusan kebijakan keamanan backend.

Pengelolaan bot

Bagian ini berisi informasi tentang 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 mendapati bahwa beberapa pengguna yang menurut Anda sah tidak dikecualikan seperti yang diharapkan. Ikuti langkah-langkah di bawah untuk memecahkan masalah.

Pertama, periksa log per permintaan untuk melihat apakah ada aturan kebijakan keamanan dengan prioritas lebih tinggi yang cocok dengan traffic, dengan tindakan yang berbeda. Secara khusus, cari kolom configured_action dan outcome. Perhatikan bahwa agar pengguna dikecualikan, setidaknya ada dua permintaan yang terlibat. Permintaan awal tidak memiliki cookie pengecualian, dan permintaan berikutnya memiliki cookie pengecualian jika pengguna lulus penilaian reCAPTCHA. Oleh karena itu, setidaknya ada dua entri log.

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

Kedua, ada beberapa persyaratan di sisi pengguna agar mereka dikecualikan dari pengalihan untuk penilaian reCAPTCHA.

  1. Pengguna harus menggunakan browser.
  2. Browser harus mengaktifkan JavaScript untuk memungkinkan pemuatan halaman pengalihan yang tepat dengan JavaScript reCAPTCHA yang disematkan.
  3. Browser harus mengaktifkan cookie untuk mengizinkan setelan dan lampiran otomatis cookie pengecualian.
  4. Pengguna harus lulus penilaian reCAPTCHA; misalnya, mereka harus menyelesaikan tantangan pop-up jika ada.

Pengguna yang tidak dapat memenuhi salah satu persyaratan di atas tidak akan menerima pengecualian, meskipun aturan dengan tindakan pengalihan untuk penilaian reCAPTCHA cocok.

Ketiga, penilaian reCAPTCHA hanya dieksekusi 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 terapkan 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 jika rendering halaman penuh tidak diharapkan. 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 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 bantuan lebih lanjut, Anda dapat menghubungi tim Dukungan Cloud.

Masalah terkait pembatasan kapasitas

Traffic tidak di-throttle seperti yang diharapkan

Anda mungkin mendapati bahwa alamat IP klien mengirim traffic tingkat tinggi ke aplikasi dengan kecepatan yang melebihi nilai minimum yang Anda tetapkan, tetapi traffic tersebut tidak dibatasi seperti yang Anda harapkan. Ikuti langkah-langkah berikut untuk menyelidiki masalahnya.

Pertama, pastikan apakah aturan dengan prioritas lebih tinggi mengizinkan traffic dari alamat IP tersebut. Periksa log untuk melihat apakah aturan ALLOW dipicu untuk alamat IP. Ini dapat 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 hal berikut:

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

Masalahnya mungkin juga karena nilai minimum ditetapkan dengan tidak benar. Jika demikian, permintaan akan dicocokkan secara akurat, tetapi tindakan sesuai akan dipicu. Periksa log untuk mengonfirmasi bahwa hal ini terjadi, lalu kurangi nilai minimum dalam aturan Anda.

Terakhir, alamat IP mungkin tidak cocok dengan aturan pembatasan atau larangan berbasis kapasitas. Untuk memperbaikinya, periksa kesalahan dalam kondisi kecocokan, lalu ubah kondisi kecocokan aturan ke nilai yang benar.

Langkah selanjutnya