WAF: Gue Pikir Pasang Web Application Firewall Itu Cukup, Ternyata Baru Setengah Jalan

Gue masih inget banget malam itu. Client nelfon panik, website e-commerce mereka lemot parah, terus tiba-tiba down total. Pas gue cek, ternyata bukan masalah server. Bukan juga masalah database. Yang kena adalah WAF yang gue pasang dengan bangga tiga minggu sebelumnya. Bukan WAF-nya yang nyerang, tapi WAF-nya yang jadi korban. Bot traffic jutaan request masuk lewat celah yang gue kira udah ketutup, dan alih-alih ngeblokir, WAF malah kewalahan sampe mati. Malam itu gue duduk di depan laptop, minum kopi yang udah dingin, dan ngerasa WAF yang gue kira tameng kokoh itu ternyata cuma tembok dari kertas yang baru ketemu api pertama kali.

Banyak orang di dunia cybersecurity, termasuk gue dulu, mikir kalau WAF itu kayak magic shield. Pasang, aktifin mode blocking, terus lupa. Anggapannya: semua serangan web bakal keblokir otomatis, website aman, kerjaan beres. Realitanya jauh lebih kompleks dari itu. WAF itu bukan alat yang bisa lo set-and-forget. Dia butuh tuning, butuh pemahaman tentang traffic aplikasi lo sendiri, butuh monitoring, dan yang paling penting, dia harus diposisikan dengan benar di dalam arsitektur pertahanan lo. Artikel ini cerita tentang perjalanan gue dari nol nyemplung ke dunia WAF, semua kesalahan yang gue bikin, dan pelajaran yang gue bawa sampe sekarang.

Apa Sebenarnya WAF Itu, dan Apa yang Bukan

Sebelum masuk lebih dalam, gue mau lurusin dulu satu hal yang sering salah kaprah. WAF, atau Web Application Firewall, itu bukan pengganti secure coding. Dia juga bukan pengganti penetration testing. WAF itu lapisan pertahanan yang duduk di antara user dan aplikasi web, tugasnya nyaring traffic HTTP yang masuk dan ngeblokir request yang keliatan mencurigakan. Bayangin kayak satpam di pintu masuk gedung yang ngecek satu-satu orang yang mau masuk: lo bawa tas, tasnya diperiksa, lo keliatan gelisah, lo ditanya mau ngapain. Tapi satpam itu bukan pengganti desain gedung yang aman, bukan juga pengganti prosedur keamanan internal.

WAF bekerja dengan beberapa cara. Ada yang berbasis signature, dia punya database pola serangan yang dikenal, kayak pola SQL injection atau cross-site scripting, terus nyocokin request yang masuk sama pola-pola itu. Ada yang berbasis behavioral, dia belajar dari pola traffic normal dan ngasih tanda kalau ada yang aneh. Ada juga yang hybrid, gabungan dua-duanya. Mayoritas WAF modern, terutama yang open source kayak ModSecurity dengan OWASP Core Rule Set, itu kombinasi dari signature dan beberapa aturan heuristik.

Yang penting gue tekankan di sini: WAF itu cuma salah satu lapisan. Defense in depth itu konsep yang harus lo pegang. WAF di depan, aplikasi yang di-coding dengan aman di tengah, monitoring dan logging di belakang. Kalau lo cuma ngandelin WAF dan aplikasi lo bobrok, penyerang cuma perlu nyari satu celah yang nggak kepegang sama rules WAF lo. Dan percaya deh, mereka selalu nemu.

Kesalahan Pertama Gue: Langsung Mode Blocking Tanpa Belajar Traffic

Kesalahan paling klasik yang gue bikin, dan gue yakin banyak orang juga bikin, adalah langsung naruh WAF di mode blocking dari hari pertama. Logikanya waktu itu sederhana: makin cepet ngeblokir, makin aman. Ternyata itu justru bikin malapetaka. WAF yang baru dipasang itu belum kenal sama traffic normal aplikasi lo. Dia belum tau mana request yang bener dari user asli, mana yang bot, mana yang legit. Hasilnya? False positive di mana-mana.

User yang baru daftar akun diblokir karena format email-nya dianggap aneh. Request pencarian produk yang sah diblokir karena mengandung karakter tertentu yang kebaca sebagai SQL injection. Bahkan admin yang lagi login dari kantor tiba-tiba ke-lock out karena IP-nya kena aturan rate limiting. Bayangin gue harus nerima puluhan tiket dari user yang nanya "kenapa website-nya error terus" padahal yang error itu WAF yang gue pasang sendiri.

Pelajaran pertama yang gue serap: WAF itu harus lo perkenalin dulu sama aplikasi lo. Mulai dari mode detection atau monitoring, biarin dia jalan beberapa minggu, kumpulin log, pelajari apa yang dia flag dan apa yang dia lewatin. Baru setelah lo paham pola traffic-nya, lo bisa pelan-pelan naikin level ke mode blocking. Ini kayak lo pindah ke lingkungan baru: lo nggak langsung percaya sama semua orang, tapi lo juga nggak langsung curiga sama semua orang. Lo belajar dulu, baru mutusin.

Mempelajari Log: Di Situ Sebenarnya Keahlian WAF Diuji

Waktu gue mulai serius, gue sadar kalau bagian paling penting dari WAF itu bukan rules-nya, tapi log-nya. WAF yang bagus itu sumber intelijen yang luar biasa. Setiap request yang diblokir, setiap request yang di-flag, setiap pola aneh yang ke-deteksi, semua itu data berharga. Tapi data itu nggak ada gunanya kalau lo nggak baca.

Gue mulai rutinitas baru: tiap pagi, sebelum ngapa-ngapain, gue buka dashboard WAF dan baca log semalam. Request apa aja yang ke-block, dari IP mana, pola apa yang kena, apakah itu serangan beneran atau cuma false positive. Dari situ gue mulai ngeliat pola-pola yang menarik. Misalnya, gue nemu satu IP yang secara rutin nyoba akses endpoint admin tapi selalu ke-block karena IP-nya ada di daftar hitam. Itu bukan serangan besar, tapi itu sinyal. Beberapa minggu kemudian, IP yang sama nyoba lagi dengan pola yang lebih canggih. Kalau gue nggak baca log, gue nggak akan nyadar kalau ada yang lagi ngintip-ngintip.

Log WAF juga ngajarin gue tentang aplikasi lo sendiri. Gue mulai ngeliat request-request yang jujur aja aneh. Ada endpoint yang nggak pernah gue tau ternyata diakses ratusan kali sehari. Ada parameter yang nggak pernah gue definisikan ternyata dikirim sama client. Ini bukan cuma soal security, ini soal memahami aplikasi lo lebih dalam.

Bypass WAF: Kenyataan Pahit yang Harus Lo Hadapi

Sekarang kita masuk ke bagian yang paling seru dan paling pahit: bypass. WAF itu bukan tembok yang nggak bisa ditembus. Setiap WAF punya celah, dan penyerang yang pinter selalu nyari celah itu. Ada banyak teknik bypass yang umum dipakai, dan gue mau cerita beberapa yang gue alami langsung.

Teknik pertama yang gue temui adalah encoding. WAF ngecek request berdasarkan pola tertentu, tapi kalau lo encode payload-nya, misalnya pake URL encoding ganda atau Unicode, WAF yang nggak normalisasi input dengan bener bakal kelewat. Contoh klasiknya SQL injection: payload asli ' OR 1=1-- gampang ke-deteksi, tapi kalau di-encode jadi %27%20OR%201%3D1--, beberapa WAF yang kurang pinter bakal bingung. Ini kenapa WAF modern harus punya kemampuan decoding yang agresif, dan kenapa lo harus ngetes WAF lo sendiri dengan payload yang di-encode.

Teknik kedua adalah HTTP parameter pollution. WAF biasanya ngecek parameter tertentu, tapi kalau lo kirim parameter yang sama dua kali dengan nilai yang beda, beberapa server bakal nerima yang terakhir sementara WAF cuma ngecek yang pertama. Ini celah klasik yang sering dipake buat ngelewatin filtering.

Teknik ketiga, dan ini yang paling bikin gue ngerasa hopeless waktu itu, adalah JSON dan content-type yang beda. Banyak WAF yang fokus ngecek query string dan form data biasa, tapi pas request datang dalam format JSON dengan content type application/json, beberapa WAF nggak parse isinya dengan bener. Padahal sekarang ini mayoritas aplikasi modern pake API yang komunikasinya lewat JSON. Kalau WAF lo nggak bisa parse JSON dengan bener, berarti setengah dari permukaan serangan lo nggak ke-cover.

Gue nggak akan lupa waktu pertama kali gue ngejalanin serangan test terhadap WAF yang gue kelola sendiri dan berhasil bypass dengan teknik encoding yang simpel. Rasanya campur aduk: kaget, malu, tapi juga excited. Kaget karena ternyata tameng yang gue banggakan gampang ditembus. Malu karena gue udah ngomong ke client kalau WAF ini bakal ngeblokir semua serangan. Tapi excited karena sekarang gue tau apa yang harus gue perbaiki. Dari situ gue mulai serius belajar tentang cara kerja bypass, dan cara ngetes WAF sebelum nyerahin ke production.

OWASP CRS dan Seni Tuning Rules

Salah satu hal yang paling ngebantu perjalanan gue adalah nemu OWASP Core Rule Set, atau CRS. Ini kumpulan rules open source yang dirancang buat ngedeteksi berbagai macam serangan web, dari SQL injection sampe remote code execution. CRS ini kayak buku resep yang udah diuji sama ribuan orang, dan gue tinggal nyocokin resepnya sama kebutuhan aplikasi lo. Tapi penting buat dipahami: CRS itu bukan sesuatu yang bisa lo pasang langsung dan lupa. CRS itu butuh tuning yang serius.

Tuning di sini maksudnya ngatur threshold dan exception. Setiap rule di CRS punya severity dan paranoia level. Paranoia level itu ukuran seberapa agresif WAF lo. Level satu itu cukup santai, cuma ngeblokir yang jelas-jelas serangan. Level empat itu paranoid banget, hampir semua yang aneh-aneh dianggap serangan. Masalahnya, makin tinggi paranoia level, makin banyak false positive. Gue belajar kalau nggak ada pengaturan yang cocok buat semua aplikasi. Aplikasi yang isinya cuma blog statis beda banget sama aplikasi e-commerce yang banyak form dan upload.

Gue juga belajar tentang whitelist dan exception. Ada beberapa hal yang secara teknis keliatan kayak serangan tapi sebenernya legit. Misalnya, kalau aplikasi lo punya fitur search yang ngebolehin user masukin karakter khusus, rule yang ngeblock SQL injection bakal sering ke-trigger. Solusinya bukan langsung nge-disable rule-nya, tapi bikin exception yang spesifik, misalnya cuma buat endpoint tertentu atau parameter tertentu. Ini seni yang butuh keseimbangan: terlalu ketat, user jadi korban; terlalu longgar, penyerang masuk.

WAF Bukan Satu-satunya Jawaban: Integrasi dengan Lapisan Lain

Salah satu pelajaran terbesar yang gue bawa sampe sekarang adalah WAF itu nggak bisa jalan sendirian. WAF yang paling canggih sekalipun bakal ngebuktiin batasnya kalau aplikasi di belakangnya bobrok. Gue pernah nanganin kasus di mana WAF udah dipasang dengan benar, tuning udah oke, tapi aplikasi masih kena kompromi. Pas dianalisa, ternyata celahnya bukan di layer web, tapi di API internal yang dipanggil dari server ke server, yang nggak lewat WAF sama sekali.

Ini ngebawa gue ke konsep yang gue pegang sampe sekarang: WAF itu satu lapisan dari banyak lapisan. Lo butuh secure coding practice di tim developer lo. Lo butuh input validation di level aplikasi, bukan cuma di level WAF. Lo butuh penetration testing yang rutin buat nemu celah yang nggak ke-cover WAF. Lo butuh monitoring di level server dan aplikasi, bukan cuma di level network. Lo butuh incident response plan yang jelas kalau suatu hari WAF lo gagal. Semua ini harus jalan bareng.

Gue sering liat tim yang kebangetan ngandelin satu alat. Pasang WAF, anggap beres. Pasang SIEM, anggap beres. Padahal keamanan itu kayak sistem imun: kalau cuma satu organ yang sehat tapi yang lain sakit, tubuh tetep bisa tumbang. WAF yang bagus itu bukan yang bisa ngeblokir semua serangan, tapi yang bisa ngeblokir sebagian besar, ngasih tau lo soal sisanya, dan ngebuktiin ke tim buat fokus ke tempat lain.

Belajar dari Serangan Sungguhan: Kasus yang Ngebentuk Cara Pandang Gue

Gue mau cerita satu kasus yang ngebentuk cara pandang gue tentang WAF secara permanen. Waktu itu ada satu aplikasi web yang dipasangin WAF dengan config yang menurut gue udah bagus. Rules CRS level dua, mode blocking, logging aktif. Terus suatu hari, SIEM gue nangkap sesuatu yang aneh: ada request yang masuk ke endpoint login dengan payload yang ke-encode, dan WAF nggak ngeblock karena payload-nya lolos normalisasi.

Untungnya, aplikasi di belakangnya punya input validation yang lumayan, jadi serangan itu gagal. Tapi momen itu ngebuka mata gue: kalau aplikasinya nggak punya lapisan pertahanan kedua, ceritanya bakal beda. Sejak itu, gue nggak pernah liat WAF sebagai garis pertahanan pertama dan terakhir. Gue liat dia sebagai bagian dari sistem yang lebih besar, dan gue selalu mastiin ada backup plan.

Kasus itu juga ngajarin gue pentingnya ngetes WAF secara rutin. Bukan cuma pas awal pasang, tapi terus-menerus. Ancaman berubah, teknik bypass berkembang, dan WAF yang oke bulan lalu bisa jadi usang bulan ini. Gue mulai bikin rutinitas: tiap bulan, gue jalanin serangkaian test payload buat mastiin WAF masih nangkep serangan yang harusnya dia tangkap. Ini kayak latihan fisik: kalau lo nggak latihan rutin, badan lo bakal lemes pas butuh.

Praktik yang Gue Terapin Sekarang

Setelah bertahun-tahun bergulat sama WAF, gue punya beberapa praktik yang selalu gue terapin. Pertama, selalu mulai dari mode detection. Biarin WAF belajar dari traffic asli sebelum lo nyalain blocking. Kedua, baca log secara rutin, bukan cuma pas ada insiden. Log WAF itu sumber intelijen yang nggak ternilai, dan lo harus baca dia kayak lo baca berita tiap pagi. Ketiga, tuning rules secara berkala berdasarkan data, bukan berdasarkan feeling. Kalau ada false positive, perbaiki dengan exception yang spesifik, bukan dengan nge-disable rule secara membabi buta.

Keempat, dan ini yang paling penting, jangan pernah berhenti ngetes. WAF yang nggak pernah diuji itu WAF yang nggak bisa dipercaya. Lo harus tau kekuatan dan kelemahan WAF lo sebelum penyerang yang nemuin duluan. Kelima, integrasikan WAF dengan lapisan pertahanan lain. Pastiin log WAF masuk ke SIEM, pastiin alert WAF nyambung ke tim response, pastiin ada prosedur yang jelas kalau WAF ke-bypass. Keenam, jangan lupa update. Rules WAF dan engine-nya harus selalu up to date, karena ancaman baru muncul tiap hari.

Kesimpulan: WAF Itu Alat, Bukan Jawaban

Kalau gue disuruh rangkum semua pelajaran gue soal WAF dalam satu kalimat, gue bakal bilang: WAF itu alat yang powerful, tapi dia bukan jawaban final buat keamanan web. Dia adalah salah satu komponen dari arsitektur pertahanan yang lebih besar, dan dia cuma efektif kalau diposisikan, dikonfigurasi, dan dipelihara dengan bener.

Gue nggak akan pernah lupa malam WAF pertama gue tumbang karena bot traffic. Malam itu ngerasa kayak kegagalan besar, tapi ternyata itu justru awal dari pemahaman gue yang sebenarnya tentang keamanan web. Sekarang, setiap kali gue pasang WAF buat client atau buat proyek gue sendiri, gue selalu inget: WAF itu bukan tameng ajaib, dia cuma salah satu prajurit di barisan pertahanan yang harus jalan bareng.

Buat lo yang baru mulai belajar soal WAF, gue saranin jangan takut buat nyemplung dan bikin kesalahan. Pasang WAF di lab lo, coba bypass dia, pelajari log-nya, tuning rules-nya. Semakin dalem lo masuk, semakin lo paham bahwa keamanan itu bukan soal punya alat yang paling canggih, tapi soal gimana lo ngombinasiin alat, proses, dan orang dengan bener. WAF cuma alat. Yang bikin beda adalah cara lo pake dia.