Jika situs web Anda memerlukan kebijakan kontrol akses khusus, Anda dapat membuat aturan kustom. Aturan kustom memungkinkan Anda menentukan kondisi pencocokan untuk permintaan masuk dan menetapkan aksi—seperti Block atau Monitor—untuk permintaan yang sesuai, sehingga memberikan kendali fleksibel atas konten yang dapat diakses pengguna.
Akurasi geolokasi IP klien
Saat menggunakan aturan kustom WAF dengan rules engine untuk memblokir permintaan, perhatikan bahwa data geolokasi IP (seperti benua, negara/wilayah, provinsi, dan ISP) mungkin tidak 100% akurat. Kesalahan identifikasi dapat terjadi, jadi gunakan fitur ini dengan hati-hati.
Jika Anda mengalami ketidakakuratan pada geolokasi IP klien, Anda dapat membuat whitelist rule untuk mengizinkan alamat IP tertentu. Hal ini mencegah WAF salah memblokir alamat IP klien yang sah.
Konfigurasikan aturan kustom
Di Konsol ESA, pilih Websites. Di kolom Website, klik website target.
Di panel navigasi sebelah kiri, pilih .
Klik tab Custom Rules, lalu pada tab Custom Rules, klik Create Rule.
Masukkan Rule Name.
Di area If requests match..., konfigurasikan kondisi pencocokan. Untuk informasi lebih lanjut, lihat Rule expression syntax.
Di area Then execute..., tentukan aksi untuk permintaan yang sesuai. Untuk informasi lebih lanjut, lihat Actions.
Klik OK.
Saat mengonfigurasi aturan, perhatikan hal berikut:
Pencocokan User-Agent dan sensitivitas huruf besar/kecil: Saat Anda mengonfigurasi aturan untuk mencocokkan berdasarkan User-Agent, jika memilih mode pencocokan Case-insensitive, nilai pencocokan harus seluruhnya dalam huruf kecil. Pastikan juga memilih presisi pencocokan yang tepat—Equals untuk pencocokan eksak atau Contains untuk pencocokan parsial—sesuai kebutuhan Anda. Mode yang salah dapat menyebabkan aturan tidak berlaku, misalnya dengan mengizinkan permintaan yang seharusnya diblokir (mengembalikan status code 200).
Batasan rules engine: Rules engine WAF saat ini hanya mendukung pencocokan boolean, seperti memeriksa apakah bidang permintaan berisi string tertentu. Fitur ini tidak mendukung logika yang lebih kompleks seperti menghitung jumlah kemunculan atau panjang array. Oleh karena itu, Anda tidak dapat membuat aturan untuk "memblokir permintaan jika URL berisi kata kunci lebih dari N kali." Kebijakan perlindungan WAF harus didasarkan pada atribut permintaan seperti client IP, User-Agent, Referer, atau URI. Anda tidak dapat memblokir traffic hanya berdasarkan identifier tingkat bisnis, seperti visitor ID.
Actions
Block: Memblokir permintaan yang sesuai dan mengembalikan halaman blokir ke klien.
CatatanSesuaikan halaman blokir melalui Configure custom pages.
Monitor: Mengizinkan permintaan yang sesuai untuk lewat, tetapi mencatat event tersebut. Gunakan mode pemantauan untuk menguji aturan baru dan memeriksa log WAF terhadap false positive. Setelah memastikan tidak ada false positive, ubah aksi menjadi Block.
CatatanAnda harus mengaktifkan Log Service untuk menggunakan fitur log kueri.
JavaScript Challenge: ESA mengembalikan cuplikan JavaScript ke klien. Jika browser berhasil menjalankan skrip tersebut, ESA mengizinkan semua permintaan berikutnya dari klien tersebut selama periode default 30 menit tanpa tantangan tambahan. Jika tidak, permintaan tersebut diblokir.
Slider CAPTCHA: ESA mengembalikan halaman Slider CAPTCHA. Jika klien berhasil menyelesaikan CAPTCHA tersebut, ESA mengizinkan semua permintaan berikutnya dari klien tersebut selama periode default 30 menit. Jika tidak, permintaan tersebut diblokir.
CatatanPermintaan yang lolos Slider CAPTCHA dikenai tagihan; permintaan yang diblokir tidak.
JavaScript Challenge dan Slider CAPTCHA untuk aturan kustom WAF serta aturan rate limiting hanya berlaku untuk halaman statis. Untuk API asinkron (
XMLHttpRequestdanFetch), aktifkan tantangan ini di bagian Bots. Saat permintaan yang sesuai lolos tantangan, ESA menambahkanCookie acw_sc__v2atauacw_sc__v3ke Header HTTP untuk menandai klien sebagai telah diverifikasi.
Strict Slider CAPTCHA: Dalam mode CAPTCHA ketat, setiap permintaan klien harus melewati verifikasi (berbeda dengan Slider CAPTCHA yang memberikan transmisi langsung selama 30 menit untuk klien yang sebelumnya telah diverifikasi). Aktifkan dengan hati-hati. Strict Slider CAPTCHA hanya tersedia untuk paket Enterprise berdasarkan permintaan.
Aturan kustom mendukung dua aksi verifikasi manusia:
JS Challenge: Verifikasi pasif. Sistem mengirim kode JavaScript ke klien untuk verifikasi otomatis tanpa memerlukan interaksi pengguna.
Slider Challenge: Verifikasi interaktif. Pengguna harus menyelesaikan aksi geser untuk lolos verifikasi.
Saat menggunakan JS Challenge dan Slider Challenge, perhatikan batasan berikut:
JavaScript Challenge dan Slider CAPTCHA hanya cocok untuk permintaan halaman statis. Kami tidak merekomendasikan penggunaannya dalam skenario dinamis, seperti pengiriman form POST atau panggilan API, karena dapat menyebabkan kehilangan data atau verifikasi berulang.
Jika Anda menerapkan JavaScript Challenge atau Slider CAPTCHA pada file resource seperti gambar, mekanisme browser dapat mencegah penyelesaian verifikasi, sehingga resource gagal ditampilkan. Untuk domain atau path yang hanya menyajikan gambar, kami merekomendasikan menggunakan aksi block atau mengonfigurasi whitelist rule daripada verifikasi manusia.
Setelah JavaScript Challenge berhasil dilalui, durasi izin adalah 30 menit secara default dan tidak dapat diubah.
Untuk jenis CAPTCHA lainnya, seperti verifikasi satu klik, gunakan fitur AI Captcha. Fitur ini mendukung berbagai jenis tantangan, termasuk satu klik, slider, dan teka-teki rotasi, serta dapat dikonfigurasi secara terpisah di Konsol ESA.
Contoh konfigurasi
Skenario: Di Security Analytics atau Event Analysis, Anda menemukan bahwa IP klien 192.168.0.1 mengirim permintaan mencurigakan ke hostname dns.example.com.
Konfigurasi:
Parameter | Nilai contoh |
If requests match... | Kedua kondisi berikut terpenuhi:
Anda juga dapat langsung menggunakan ekspresi berikut: |
Then execute... | Block permintaan dan beri respons menggunakan Default Error Page. |
Hasil: Aturan kustom memblokir semua permintaan yang sesuai.
Contoh konfigurasi umum
Gunakan contoh berikut untuk skenario perlindungan umum sebagai titik awal, lalu sesuaikan dengan kebutuhan Anda.
Skenario 1: Blokir crawler tertentu (misalnya, Bytespider)
Di area If requests match..., atur bidang pencocokan ke User-Agent, operator ke Contains, dan nilai ke Bytespider. Untuk aksi, pilih Block.
Skenario 2: Batasi metode permintaan (izinkan hanya GET dan POST)
Konfigurasikan aturan: Jika Request Method tidak sama dengan GET DAN tidak sama dengan POST, maka jalankan aksi Block. Skenario ini memerlukan paket Advanced atau lebih tinggi.
Skenario 3: Izinkan hanya IP tertentu untuk mengakses subdomain
Gabungkan dua kondisi pencocokan: Hostname sama dengan subdomain target DAN Client IP tidak sama dengan IP yang ditentukan. Untuk aksi, pilih Block.
Skenario 4: Blokir permintaan dengan Referer kosong sambil mengizinkan akses langsung ke path tertentu
Anda perlu mengonfigurasi dua aturan dan mengatur prioritasnya:
Aturan whitelist (prioritas tinggi): Jika URI permintaan sama dengan path yang dapat diakses langsung (seperti halaman utama
/atau halaman artikel), jalankan aksi Skip All Rules.Aturan blokir (prioritas rendah): Jika Referer kosong, jalankan aksi Block.
Aturan whitelist harus memiliki prioritas lebih tinggi daripada aturan blokir agar path akses langsung tidak terpengaruh.
Skenario 5: Blokir permintaan anomali untuk path URL tertentu
Konfigurasikan kondisi gabungan: URI berisi string tertentu DAN Referer kosong. Untuk aksi, pilih Block atau JS Challenge.
Ketersediaan fitur berdasarkan paket
Fitur | Entrance | Pro | Premium | Enterprise |
Jumlah aturan kustom | 5 | 20 | 100 | 100 |
Paket Free tidak mendukung kondisi pencocokan berdasarkan bidang seperti Ip.Geoip.Country. Jika Anda menggunakan bidang ini dalam aturan kustom, sistem akan mengembalikan error Ip.Geoip.Country.NotSupport. Untuk menggunakan kondisi pencocokan berbasis geolokasi, Anda harus melakukan upgrade ke paket Basic atau lebih tinggi.
FAQ
Mengapa aturan blokir berbasis negara/wilayah menyebabkan false positive atau gagal mengidentifikasi wilayah 'Unknown'?
Data geolokasi IP (benua, negara/wilayah, provinsi, ISP) tidak dapat 100% akurat. Selain itu, layanan VPN atau proxy dapat mengubah geolokasi IP klien yang tampak, sehingga menyebabkan aturan terpicu secara salah.
Rentang IP privat (seperti 100.64.0.0/10) dan IP proxy mungkin diidentifikasi sebagai wilayah Unknown. ESA tidak mendukung pemblokiran langsung terhadap wilayah Unknown.
Rekomendasi:
Gabungkan kondisi geolokasi dengan atribut lain seperti User-Agent atau Referer. Contohnya: negara/wilayah tidak termasuk dalam daftar target DAN User-Agent tidak sesuai dengan nilai tertentu. Hal ini mengurangi false positive yang disebabkan oleh ketergantungan semata pada geolokasi.
Jika terjadi false positive, konfigurasikan aturan whitelist untuk mengizinkan alamat IP yang sah.
Bagaimana menangani callback pihak ketiga (seperti notifikasi Alipay) yang diblokir oleh WAF?
Analisis karakteristik umum permintaan callback tersebut (misalnya, path URI berisi /pay/notify/, User-Agent tertentu, dan metode permintaan adalah POST). Lalu, buat aturan kustom sebagai whitelist: jika permintaan sesuai dengan semua karakteristik tersebut, terapkan aksi Skip All Rules.
Jika Anda tidak dapat menentukan semua karakteristiknya, mulailah dengan mengonfigurasi aturan blokir untuk pola serangan yang diketahui, lalu uji secara bertahap untuk memastikan callback yang sah tidak diblokir.
Dokumentasi terkait
Fitur terkait aturan memiliki variasi dalam prioritas efektif, reentrancy, dan granularitas efektif. Untuk detailnya, lihat Properties of Rule-Related Features.