Web Application Firewall:FAQ tentang konfigurasi perlindungan

Mengapa saya tidak dapat menemukan ID aturan perlindungan tertentu di konsol WAF?

Jika Anda tidak dapat menemukan ID aturan tertentu di konsol WAF, periksa hal-hal berikut berdasarkan jenis aturan:

Cari aturan perlindungan inti web bawaan

1. Masuk ke konsol Web Application Firewall 3.0. Dari bilah menu atas, pilih kelompok sumber daya dan wilayah (Chinese Mainland atau Outside Chinese Mainland) untuk instans WAF.

2. Di panel navigasi sebelah kiri, pilih Protection Config > Core Web Protection > Core Protection Rule.

3. Temukan dan buka template perlindungan target, lalu klik Configure Engine pada kolom Actions.

4. Di halaman Configure Engine yang muncul, cari aturan tersebut.

Cari aturan kustom

Untuk modul perlindungan lainnya (seperti Custom Rule, HTTP Flood Protection, dan Scanning Protection) di bawah Core Web Protection, ikuti langkah-langkah berikut untuk mencari aturan kustom:

1. Di panel navigasi sebelah kiri, pilih Protection Config > Core Web Protection.

2. Cari di lokasi yang ditunjukkan pada gambar berikut.

Cari aturan daftar putih

1. Di panel navigasi sebelah kiri, pilih Protection Config > Whitelist.

2. Cari di lokasi yang ditunjukkan pada gambar berikut.

Cari aturan Bot Management

Aturan perlindungan telah dihapus

Jika aturan tidak ditemukan di lokasi mana pun di atas, kemungkinan aturan tersebut telah dihapus. Anda dapat menggunakan Operation Audit untuk memeriksa apakah terdapat event bernama DeleteDefenseRule atau DeleteDefenseTemplate. Untuk informasi selengkapnya, lihat Kueri event di Konsol ActionTrail.

Apakah acl_action:block dalam log WAF menunjukkan bahwa permintaan benar-benar diblokir?

acl_action:block tidak selalu berarti permintaan tersebut diblokir. Jika acl_test diatur ke true, itu menunjukkan mode observasi. Dalam mode ini, hanya log yang direkam dan tidak ada aksi perlindungan seperti pemblokiran yang dipicu. Untuk menentukan apakah permintaan benar-benar diblokir, periksa bidang final_action. final_action:block menunjukkan bahwa permintaan tersebut diblokir.

Mengapa aturan kustom tidak berlaku setelah saya mengatur bidang pencocokan ke Body Parameter?

Hal ini mungkin disebabkan oleh konten pencocokan yang Anda masukkan terlalu pendek. Saat menggunakan bidang Body Parameter, pastikan konten pencocokan lebih dari empat karakter. Jika tidak, trafik tidak dapat dideteksi.

Mengapa aturan kebijakan perlindungan kustom tidak berlaku ketika bidang pencocokan URL berisi double slash (//)?

Engine aturan WAF secara default menormalisasi URL dengan mengompresi slash (/) berurutan. Oleh karena itu, aturan kebijakan perlindungan kustom yang berisi double slash (//) dalam bidang pencocokan URL tidak dapat dicocokkan dengan benar.

Untuk mengonfigurasi aturan ACL untuk URL yang berisi double slash (//), Anda dapat menggunakan path single-slash yang sesuai sebagai kondisi pencocokan. Misalnya, jika Anda ingin menggunakan //api/sms/request sebagai nilai kondisi untuk bidang pencocokan URL, masukkan /api/sms/request di bidang konten pencocokan. WAF kemudian dapat menerapkan kontrol akses ke permintaan yang berisi path tersebut.

Bagaimana cara memecahkan masalah mengapa permintaan diblokir oleh WAF menggunakan ID permintaan?

Saat permintaan diblokir oleh WAF, sistem mengembalikan ID permintaan unik dalam respons. Anda dapat menggunakan ID ini untuk mencari informasi detail di laporan keamanan atau log guna mengidentifikasi alasan pemblokiran.

1. Dapatkan ID permintaan: Setelah permintaan diblokir, ID permintaan ditampilkan secara default di halaman pemblokiran. Salin ID ini untuk pencarian selanjutnya.

2. Cari di konsol WAF: Masuk ke konsol WAF 3.0. Di panel navigasi sebelah kiri, pilih Detection and Response > Security Reports. Tetapkan rentang waktu pencarian, lalu tempel ID permintaan di kotak pencarian Enter Trace ID.

   Catatan

   Jika pengiriman log diaktifkan untuk objek perlindungan, Anda juga dapat mencari di halaman Detection and Response > Log Service.

3. Analisis alasan pemblokiran: Di halaman Security Reports, lihat Protection Module dan Rules Matched yang dicocokkan oleh permintaan di bagian bawah halaman. Jika Anda memastikan bahwa permintaan tersebut merupakan trafik bisnis normal, klik Suppress False Positive di kolom Actions pada Logs untuk menambahkan permintaan ke daftar putih. Untuk informasi selengkapnya, lihat Daftar Putih.

Bagaimana cara menonaktifkan fitur API Security untuk instans WAF pay-as-you-go?

Jika Anda tidak lagi memerlukan fitur API Security untuk instans WAF pay-as-you-go, ikuti langkah-langkah berikut untuk menonaktifkannya.

1. Masuk ke konsol Web Application Firewall 3.0. Dari bilah menu atas, pilih kelompok sumber daya dan wilayah (Chinese Mainland atau Outside Chinese Mainland) untuk instans WAF.

2. Di panel navigasi sebelah kiri, pilih Protection Config > API Security.

3. Buka tab Policy Configurations > Applicable Object Configurations.

4. Matikan sakelar Basic Detection untuk semua objek yang dilindungi dan kelompok objek yang dilindungi. Setelah operasi ini, data historis untuk API Security akan di-purge dan tidak dapat dilihat lagi.

Apakah Alibaba Cloud WAF menyisipkan header respons CORS atau secara dinamis menggemakan header permintaan Origin secara default?

WAF tidak memodifikasi header CORS permintaan dan tidak menyediakan opsi konfigurasi untuk secara otomatis menyisipkan header respons CORS atau menggemakan header Origin secara dinamis. Kebijakan CORS harus dikonfigurasi dan dikelola oleh server origin atau aplikasi Anda.

Apa penyebab WAF mengembalikan error 413 Request Entity Too Large?

Penyebab: File yang diunggah melebihi batas ukuran permintaan maksimum yang ditetapkan oleh WAF (saat ini 2 GB).

Solusi:

• Kurangi ukuran file agar setiap permintaan berada di bawah 2 GB.

• Upgrade WAF ke edisi Ultimate, yang mendukung file hingga 10 GB. Untuk informasi selengkapnya, lihat Ukuran file unggahan.

Apakah menerima peringatan intersepsi WAF berarti bisnis terganggu?

Menerima peringatan intersepsi WAF menunjukkan bahwa mekanisme perlindungan keamanan berfungsi dengan baik dan tidak secara langsung berarti bisnis Anda terdampak. Namun, dalam skenario tertentu, Anda mungkin perlu menyelidiki potensi false positive atau kegagalan perlindungan.

Makna peringatan

Peringatan intersepsi WAF menunjukkan bahwa sistem berhasil mengidentifikasi dan memblokir permintaan berbahaya yang sesuai dengan aturan keamanan. Permintaan tersebut dibersihkan sebelum mencapai server origin dan tidak mengonsumsi sumber daya server origin atau menyebabkan kerusakan akibat serangan. Ini merupakan tanda bahwa mekanisme perlindungan berfungsi secara normal.

Skenario yang Memerlukan Investigasi

1. False positive: Jika akses pengguna sah (seperti login backend atau panggilan API) diblokir, konfigurasi aturan mungkin terlalu ketat sehingga menyebabkan pemblokiran palsu. Dalam kasus ini, ketersediaan bisnis terganggu, dan Anda perlu menyesuaikan aturan perlindungan atau menambahkan fitur terkait ke daftar putih.

2. Serangan CC skala besar: Saat mengalami serangan CC frekuensi tinggi, meskipun WAF melakukan intersepsi, beberapa permintaan mungkin tetap lolos. Selain itu, trafik serangan yang berlebihan dapat memicu mekanisme blackhole, sehingga layanan WAF menjadi tidak tersedia. Untuk strategi pertahanan spesifik, lihat Mengonfigurasi perlindungan serangan flood HTTP.

Mengapa strategi perlindungan WAF default tidak mengintersepsi unggahan file skrip seperti .py/.sh?

Strategi perlindungan WAF default terutama menargetkan serangan web frekuensi tinggi (seperti injeksi SQL dan XSS) serta webshell umum (JSP, PHP, ASP).

Ekstensi file skrip seperti .py, .sh, .cmd, dan .bat umum digunakan dalam skenario bisnis sah untuk tugas latar belakang atau pemrosesan batch. Untuk menghindari pemblokiran permintaan bisnis normal, strategi default tidak menyertakan ekstensi ini dalam cakupan intersepsi global.

Jika Anda perlu mengintersepsi unggahan semacam itu, kami merekomendasikan menggunakan Aturan kustom untuk mengontrol unggahan secara tepat dengan mencocokkan path antarmuka unggahan dan ekstensi nama file.

Bagaimana cara memblokir IP luar negeri sekaligus mengizinkan crawler mesin pencari tertentu?

Anda dapat mencapai hal ini melalui konfigurasi gabungan:

1. Aktifkan fitur Konfigurasi aturan pemblokiran wilayah dan pilih opsi untuk memblokir semua wilayah Outside China.

2. Buat Daftar Putih. Atur Match Condition ke User-Agent yang berisi identifikasi crawler tertentu (seperti Googlebot atau bingbot), dan atur Bypassed Modules ke Geo-blocking.

Apa perbedaan antara pencocokan awalan dan pencocokan regex? Bagaimana memilihnya?

1. Kemampuan pencocokan: Pencocokan awalan adalah mode sederhana yang hanya mendukung pencocokan string tetap. Pencocokan regex adalah aturan lanjutan yang mendukung pencocokan pola kompleks.

2. Kinerja: Pencocokan awalan memiliki efisiensi eksekusi tinggi. Pencocokan regex mengonsumsi sumber daya sedikit lebih banyak karena kompleksitas engine-nya, dan biayanya sedikit lebih tinggi saat menggunakan edisi pay-as-you-go.

3. Saran penyetelan aturan: Jika aturan saat ini tidak memblokir seperti yang diharapkan, periksa apakah metode pencocokan tidak sesuai. Misalnya, untuk path URI, Anda dapat mencoba menggunakan Contains One of Multiple Values atau Regex Match alih-alih pencocokan awalan/akhiran tunggal untuk meningkatkan tingkat hit. Saat menggunakan pencocokan regex, perhatikan sintaks regex dan hindari nesting yang kompleks.

Apakah daftar putih berlaku segera setelah dikonfigurasi, atau apakah saya perlu menunggu periode larangan berakhir?

Setelah Anda menambahkan aturan daftar putih, aturan tersebut berlaku segera. Anda tidak perlu menunggu periode larangan asli berakhir.

Jika Anda masih diblokir setelah konfigurasi, periksa hal berikut:

• Periksa apakah sakelar templat dan aturan diaktifkan.

• Pastikan pengaturan Apply To sudah benar.

• Verifikasi kondisi pencocokan akurat.

• Konfirmasi apakah terdapat proxy lapisan 7 seperti CDN atau Anti-DDoS sebelum WAF. Jika ya, Anda harus mengonfigurasi dengan benar opsi Is a Layer 7 proxy such as Anti-DDoS Proxy or CDN deployed in front of WAF saat menambahkan aset. Jika tidak, WAF tidak dapat memperoleh IP klien sebenarnya.

Apa prinsip pencocokan aturan sidik jari WAF (JA3/JA4/HTTP2)? Mengapa aturan tersebut dapat terpicu dari dimensi non-IP?

Aturan sidik jari melakukan pencocokan berdasarkan nilai hash yang dihasilkan dari karakteristik browser atau tool klien, bukan berdasarkan alamat IP. Secara spesifik:

1. Sidik jari JA3: Dihasilkan dengan menerapkan penghashan MD5 pada parameter utama proses jabat tangan TLS (versi, paket sandi, dll.).

2. Sidik jari JA4: Memperkenalkan algoritma tambahan (versi browser, OS, dll.) untuk mengurangi duplikasi.

3. Sidik jari HTTP/2: Dihasilkan menggunakan algoritma MD5 berdasarkan sidik jari asli klien HTTP/2.

Selama permintaan membawa tanda tangan sidik jari yang cocok, aturan akan dipicu terlepas dari asal geografis IP tersebut.