Mengamankan Web Modern: Implementasi WAF dan Rate Limiting Tingkat Lanjut di Nginx dan Cloudflare

1. Titik Awal Masalah: Mengapa Arsitektur Lama Sering Ambruk di Produksi

Jam 2 pagi, pagerduty berdering nyaring. Notifikasi dari sistem pemantauan menunjukkan latensi lonjakan drastis, diikuti oleh error 504 Gateway Time-out yang merembet ke seluruh layanan. Begitu membuka terminal dan mengecek log Nginx, pemandangan horor langsung tersaji: ribuan baris IP acak menghantam endpoint login (/api/v1/auth/login) dan halaman pencarian secara bersamaan. Bukan serangan DDoS masif yang merobohkan pipa jaringan kita, melainkan serangan terdistribusi yang sangat rapi—sebuah serangan Layer 7 Application DoS dan Credential Stuffing yang menyamar sebagai trafik organik.

Di era web modern, di mana tumpukan aplikasi dibangun di atas kombinasi frontend SPA, backend microservices berbasis Go atau Node.js, serta database MySQL/PostgreSQL yang dibungkus Redis caching, infrastruktur seringkali rapuh pada titik transisi. Arsitektur lama yang hanya mengandalkan firewall jaringan (Layer 3/4) atau sekadar memasang rate limit naif berbasis IP tunggal sudah tidak lagi memadai. Botnet modern menggunakan ribuan residential proxies untuk mendistribusikan serangan, membuat pemblokiran IP mentah menjadi sia-sia belaka. Jika kita tidak segera mengalihkan pertahanan ke Edge menggunakan Cloudflare dan memperketat gerbang Nginx di hulu, server asal (origin server) kita hanya tinggal menunggu waktu untuk tumbang.

Dan di sinilah cerita ini bermula—bagaimana kita merombak total cara memandang keamanan perimeter, mengubah Nginx dari sekadar penerus HTTP pasif menjadi benteng pertahanan presisi tinggi, dan memadukannya dengan kecerdasan WAF Cloudflare untuk menyaring sampah internet sebelum menyentuh kode aplikasi kita.

2. Di Balik Layar: Bagaimana Sistem Ini Bekerja Tanpa Sihir

Sebelum kita menyentuh baris konfigurasi, mari kita bedah secara intuitif apa yang sebenarnya terjadi di balik layar saat sebuah request HTTP masuk ke infrastruktur kita. Bayangkan arsitektur kita sebagai sebuah gedung perkantoran eksklusif. Cloudflare bertindak sebagai pos pemeriksaan keamanan di gerbang utama kompleks (Edge CDN & WAF), sementara Nginx adalah resepsionis utama yang berdiri tepat di depan pintu lobi gedung aplikasi kita.

Ketika seorang pengguna atau bot mengetuk pintu, Cloudflare melakukan pemeriksaan awal berdasarkan reputasi IP global, sidik jari TLS (TLS fingerprinting), analisis tantangan JavaScript (JS Challenge), dan aturan WAF kustom yang kita tulis. Bot jahat atau skrip brute force biasanya langsung disaring di sini, menghemat bandwidth jaringan dan mencegah sumber daya CPU server asal terkuras. Namun, beberapa trafik licik yang berhasil lolos dari saringan edge ini masih harus melewati pos pemeriksaan kedua di Nginx.

Di Nginx, kita menggunakan mekanisme memori bersama (shared memory zone) melalui modul ngx_http_limit_req_module. Modul ini tidak sekadar menghitung jumlah klik, melainkan menggunakan algoritma Leaky Bucket. Bayangkan sebuah ember air dengan lubang kecil di bawahnya. Request masuk ibarat air yang dituangkan ke dalam ember. Jika air dituangkan terlalu cepat melebihi kapasitas lubang pembuangan, air akan meluber—inilah momen di mana Nginx mengembalikan respons HTTP 503 Service Temporarily Unavailable atau memicu sliding window rate limiting. Pendekatan ini memastikan lonjakan trafik sah yang mendadak masih bisa ditoleransi (berkat kapasitas tampung ember), sementara serangan beruntun langsung dipangkas tanpa ampun.

3. Pilihan Pendekatan & Kompromi yang Harus Diambil

Dalam merancang strategi pertahanan ini, kita dihadapkan pada persimpangan jalan arsitektural. Tidak ada solusi perak tunggal (silver bullet); setiap pilihan membawa konsekuensi performa dan kompleksitas operasional tersendiri.

Mari kita bandingkan dua pendekatan utama dalam menangani rate limiting dan proteksi:

Keputusan terbaik di lapangan? Selalu gunakan pendekatan Hibrida. Cloudflare menangkap serangan skala makro dan anomali global, sementara Nginx di origin bertindak sebagai penjaga gerbang mikro yang memastikan tidak ada satupun script kiddie yang lolos dari celah logika aplikasi internal kita.

4. Meracik Lingkungan: Persiapan & Prasyarat Lapangan

Sebelum menyelam ke dalam skrip konfigurasi, pastikan fondasi infrastruktur kita sudah siap dan selaras. Kita berasumsi bahwa Anda menggunakan sistem operasi berbasis Linux (Ubuntu 22.04 LTS atau AlmaLinux 9), dengan stack standar web modern:

• Web Server: Nginx (versi mainline terbaru)
• Backend: PHP-FPM / Node.js / Go
• DNS & CDN: Cloudflare (dengan mode proxy oranye / Proxied aktif)

Langkah pertama yang sering dilupakan oleh engineer pemula adalah memastikan Nginx mengenali alamat IP asli pengunjung alih-alih alamat IP dari server edge Cloudflare. Tanpa langkah ini, seluruh rate limiting di Nginx akan menganggap Cloudflare sebagai satu-satunya pelaku yang mengakses server, mengakibatkan seluruh pengguna internet Anda terblokir secara massal hanya karena satu IP edge mencapai batas limit!

Mari kita pastikan modul realip aktif di Nginx dengan memeriksa konfigurasi dasar pada blok http di file /etc/nginx/nginx.conf:

http {
    # Percaya pada header yang dikirim oleh Cloudflare
    set_real_ip_from 173.245.48.0/20;
    set_real_ip_from 103.21.244.0/22;
    set_real_ip_from 103.22.200.0/22;
    set_real_ip_from 103.31.4.0/22;
    set_real_ip_from 141.101.64.0/18;
    set_real_ip_from 108.162.192.0/18;
    set_real_ip_from 190.93.240.0/20;
    set_real_ip_from 188.114.96.0/20;
    set_real_ip_from 197.234.240.0/22;
    set_real_ip_from 198.41.128.0/17;
    set_real_ip_from 162.158.0.0/15;
    set_real_ip_from 104.16.0.0/13;
    set_real_ip_from 104.24.0.0/14;
    set_real_ip_from 172.64.0.0/13;
    set_real_ip_from 131.0.72.0/22;
    
    # Untuk IPv6 Cloudflare
    set_real_ip_from 2400:cb00::/32;
    set_real_ip_from 2606:4700::/32;
    set_real_ip_from 2803:f800::/32;
    set_real_ip_from 2405:b500::/32;
    set_real_ip_from 2405:8100::/32;
    set_real_ip_from 2406:b400::/32;
    set_real_ip_from 2407:7080::/32;
    
    real_ip_header CF-Connecting-IP;
}

[!IMPORTANT] Daftar blok IP CIDR Cloudflare di atas sewaktu-waktu dapat diperbarui oleh mereka. Selalu sinkronkan daftar ini secara berkala melalui dokumentasi resmi Cloudflare atau gunakan skrip otomasi cron untuk memperbarui file konfigurasi Nginx secara dinamis.

5. Langkah Implementasi: Membangun Solusi yang Tangguh

Sekarang fondasi jaringan sudah bersih, mari kita bangun sistem rate limiting tingkat lanjut di Nginx. Kita akan membuat dua zona pembatasan yang berbeda: satu untuk halaman umum (membatasi lonjakan agresif) dan satu lagi khusus untuk endpoint sensitif seperti /api/v1/auth/login yang rentan terhadap serangan brute force.

Buka file konfigurasi server virtual Nginx Anda (misalnya /etc/nginx/sites-available/production.conf) dan terapkan struktur berikut:

# Mendefinisikan zona memori bersama untuk rate limiting
# zone=standard_limit:10m berarti mengalokasikan 10MB RAM (cukup untuk ~160.000 IP address)
# rate=10r/s berarti membatasi maksimal 10 request per detik per IP
limit_req_zone $binary_remote_addr zone=standard_limit:10m rate=10r/s;

# Zona khusus login yang jauh lebih ketat: 1 request per detik per IP
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/html/public;
    index index.php index.html;

    # Proteksi umum untuk seluruh situs
    location / {
        limit_req zone=standard_limit burst=20 nodelay;
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Proteksi ketat khusus endpoint otentikasi
    location = /api/v1/auth/login {
        # Burst=5 memberikan toleransi lonjakan kecil, nodelay menolak langsung jika lewat
        limit_req zone=login_limit burst=5 nodelay;
        
        # Mengarahkan ke backend PHP-FPM atau Node.js
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    }
}

[!TIP] Parameter burst dan nodelay adalah penentu utama pengalaman pengguna (UX). Tanpa nodelay, Nginx akan menahan (delay) request yang melebihi batas rate, yang justru bisa menyebabkan antrean koneksi menumpuk di memori. Dengan nodelay, request berlebih langsung dipangkas dengan error 503, menjaga server tetap responsif bagi trafik sah.

6. Membedah Baris Kode Krusial yang Kerap Menjebak

Mari kita bedah secara mendalam mengapa beberapa baris kode dalam konfigurasi di atas sering menjadi jebakan bagi para engineer pemula di lapangan:

1. Penggunaan Variabel $binary_remote_addr vs $remote_addr: Banyak artikel lama menyarankan penggunaan $remote_addr. Ini adalah jebakan maut! $remote_addr menyimpan alamat IP dalam format teks string (panjang variabel hingga 15 karakter untuk IPv4 atau 39 karakter untuk IPv6). Sebaliknya, $binary_remote_addr menyimpan IP dalam bentuk representasi biner yang ringkas (hanya 4 byte untuk IPv4 dan 16 byte untuk IPv6). Menggunakan bentuk biner menghemat memori zona bersama secara masif, memungkinkan Nginx melacak jutaan IP unik tanpa menghabiskan RAM server.

2. Logika burst dan Penanganan Status HTTP 503: Ketika sebuah request melanggar aturan limit, Nginx secara default mengembalikan kode status 503. Namun, bot pintar terkadang mengabaikan status ini dan terus menembak server. Kita bisa mengubah kode status respons rate limit agar sistem pemantauan atau WAF edge mendeteksinya lebih cepat dengan menambahkan baris berikut di dalam blok server atau location:

   limit_req_status 429;
   

   Mengubahnya menjadi 429 Too Many Requests jauh lebih sesuai dengan standar RFC 6585 untuk kasus pembatasan rate.

7. Bertahan di Bawah Tekanan: Skenario Traffic Nyata

Bayangkan insiden kampanye flash sale tengah malam atau serangan credential stuffing terkoordinasi yang menghantam aplikasi Anda dengan 50.000 request per detik. Di tingkat edge, Cloudflare WAF berperan sebagai garis depan yang menepis sebagian besar serangan menggunakan Custom Rules berbasis ekspresi reguler dan verifikasi Managed Rulesets.

Untuk melengkapi perlindungan Nginx di origin, kita masuk ke dasbor Cloudflare, navigasikan ke Security > WAF > Custom Rules, dan buat aturan proteksi untuk endpoint sensitif:

• Rule Name: Block Aggressive Bot Login
• Field: URI Path
• Operator: equals
• Value: /api/v1/auth/login
• And / Or: And
• Field: Request Method
• Operator: equals
• Value: POST
• And / Or: And
• Field: Bot Score
• Operator: less than
• Value: 30 (Cloudflare memberikan skor bot dari 1-99, di mana angka kecil menandakan bot otomatis)
• Choose Action: Managed Challenge atau Block

Dengan aturan ini, setiap skrip otomatis atau bot dengan reputasi buruk yang mencoba melakukan POST ke endpoint login akan langsung dicegat oleh Cloudflare di server edge terdekat di Tokyo, Frankfurt, atau New York, bahkan sebelum paket data menyentuh kartu jaringan server fisik kita.

8. Jebakan Klasik & Cara Menghindarinya Sebelum Meledak

Selama bertahun-tahun merawat infrastruktur skala besar, saya telah melihat berbagai kesalahan fatal yang dilakukan tim engineering saat menerapkan WAF dan Rate Limiting:

• Jebakan 1: Memblokir Alamat IP Internal Load Balancer / Proxy. Jika Anda berada di belakang AWS ALB, Cloudflare, atau Cloudflare Tunnel, lupa mendefinisikan set_real_ip_from akan membuat Nginx memblokir IP load balancer itu sendiri. Akibatnya, seluruh situs mendadak down total.
• Jebakan 2: Alokasi Memori Zona Limit Terlalu Kecil. Menulis limit_req_zone $binary_remote_addr zone=one:1k; adalah resep disaster. Jika memori penuh, Nginx akan membuang catatan IP lama secara acak (lru), melemahkan efektivitas rate limiting. Selalu hitung kebutuhan memori: 1 MB RAM dapat menampung sekitar 16.000 alamat IP. Alokasikan minimal 10MB hingga 32MB untuk situs berlalu lintas tinggi.
• Jebakan 3: Mengabaikan Aset Statis. Jangan pernah menerapkan rate limiting yang terlalu ketat pada direktori aset statis seperti CSS, JavaScript, atau gambar. Bot atau pengguna yang memuat halaman dengan puluhan aset gambar akan langsung terkena banned oleh Nginx sendiri!

9. Uji Nyali: Mengukur Performa di Titik Batas

Jangan pernah mempercayai konfigurasi keamanan sebelum Anda mengujinya sendiri di lingkungan staging atau produksi yang terkontrol. Kita bisa menggunakan tool open-source seperti Apache Bench (ab), Wrk, atau Locust untuk mensimulasikan serangan beban.

Jalankan perintah pengujian berikut menggunakan wrk untuk menguji endpoint login kita:

# Mensimulasikan 100 koneksi paralel dengan 10 thread selama 30 detik
wrk -t10 -c100 -d30s -s post_login.lua https://example.com/api/v1/auth/login

Di mana file post_login.lua berisi payload POST sederhana:

wrk.headers["Content-Type"] = "application/json"
wrk.body = '{"username":"test_user","password":"secret_password\