Mitigasi Serangan Distributed Denial of Service (DDoS) dan Web Application Firewall Tingkat Lanjut

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap infrastruktur web modern, ancaman terhadap ketersediaan layanan (availability) dan integritas data semakin kompleks. Serangan Distributed Denial of Service (DDoS) di Layer 7 (Application Layer) serta serangan brute-force otomatis pada titik masuk otentikasi bukan lagi sekadar gangguan kecil, melainkan ancaman eksistensial yang dapat melumpuhkan pendapatan perusahaan, merusak reputasi merek, dan memicu kerugian finansial yang masif.

Secara historis, banyak administrator sistem mengandalkan perangkat keras mitigasi DDoS tradisional yang beroperasi di Layer 3 dan Layer 4. Namun, pendekatan ini terbukti tidak memadai ketika menghadapi serangan Layer 7 yang dirancang untuk meniru perilaku pengguna sah secara sempurna—seperti HTTP Flood, Slowloris, serangan berbasis XML-RPC/WordPress pingback, atau credential stuffing terdistribusi yang memanfaatkan ribuan botnet dengan alamat IP yang terus berotasi.

Bottleneck performa dan keamanan yang paling sering ditemukan di dunia nyata meliputi:

• Ketiadaan Granularitas Rate Limiting: Konfigurasi server web standar sering kali hanya membatasi koneksi total per IP tanpa memperhitungkan konteks endpoint (misalnya, membatasi / sama ketatnya dengan /api/v1/auth/login).
• Buta terhadap Anomali Payload: Tanpa adanya Web Application Firewall (WAF) yang terkonfigurasi dengan aturan kustom, payload berbahaya yang mengandung injeksi SQL, Cross-Site Scripting (XSS), atau eksekusi jarak jauh (RCE) dapat lolos langsung ke backend (PHP-FPM, Node.js, atau Go) dan menghabiskan sumber daya CPU serta memori.
• Kurangnya Korelasi Log Real-Time: Log akses Nginx atau Apache yang menumpuk tanpa sistem analisis otomatis seperti Fail2ban atau Logstash menyebabkan respons mitigasi terlambat; penyerang sudah berhasil melakukan brute-force sebelum admin menyadari adanya anomali.

Perbandingan Kondisi: Sebelum vs Sesudah Penerapan

2. Konsep Inti & Deep Dive Arsitektur

Untuk membangun benteng pertahanan yang tangguh, kita harus memahami bagaimana lalu lintas data mengalir melalui infrastruktur web modern, mulai dari jaringan publik hingga penyimpanan persisten.

Alur Eksekusi & Arsitektur Jaringan (ASCII Flow Chart)

[ Internet / Botnet Traffic ]
          │
          ▼
┌────────────────────────────────────────┐
│      Cloudflare Edge / CDN & WAF       │
└────────────────────┬───────────────────┘
                     │ (Encrypted TLS 1.3 / Proxy Protocol)
                     ▼
┌────────────────────────────────────────┐
│      Nginx Reverse Proxy + ModSecurity │ <── [ Fail2ban (Kernel iptables/nftables) ]
│  - Advanced Rate Limiting Zones        │
│  - SSL Termination                     │
└────────────────────┬───────────────────┘
                     │ (FastCGI / HTTP Upstream)
          ┌──────────┴──────────┐
          ▼                     ▼
┌───────────────────┐ ┌───────────────────┐
│  Backend App 1    │ │  Backend App 2    │ (Go / Node.js / PHP-FPM)
└─────────┬─────────┘ └─────────┬─────────┘
          │                     │
          └──────────┬──────────┘
                     ▼
┌────────────────────────────────────────┐
│   Database (MySQL/MariaDB) & Redis     │
└────────────────────────────────────────┘

Penjelasan Alur Kerja di Balik Layar

1. Edge Filtering (Cloudflare): Trafik mentah dari internet mendarat pertama kali di CDN/Edge. Serangan DDoS volumetrik besar diserap di sini melalui Anycast Network dan mitigasi Layer 3/4.
2. Reverse Proxy & WAF (Nginx + ModSecurity): Trafik yang lolos diteruskan ke server origin. Nginx bertindak sebagai reverse proxy yang mengevaluasi parameter zona rate limiting (limit_req dan limit_conn). ModSecurity menganalisis setiap HTTP request terhadap sekumpulan aturan (ruleset) untuk mendeteksi pola serangan.
3. Kernel-Level Blocking (Fail2ban): Jika ModSecurity atau log error Nginx mendeteksi pola serangan berulang dari IP tertentu (misalnya, 5 kali gagal login dalam 1 menit), Fail2ban secara otomatis menyuntikkan aturan ke iptables atau nftables untuk memblokir IP tersebut di tingkat kernel sebelum membebani Nginx.
4. Aplikasi & Penyimpanan: Permintaan yang sah diteruskan ke runtime backend (PHP-FPM/Go/Node), yang kemudian berinteraksi dengan Redis untuk caching dan MariaDB untuk persistensi data.

3. Perbandingan Komparatif / Analisis Pendekatan

Memilih strategi mitigasi memerlukan pemahaman tentang trade-off sumber daya (CPU, RAM, Latency) dari setiap pendekatan.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengimplementasikan konfigurasi tingkat lanjut, pastikan lingkungan sistem Anda memenuhi spesifikasi berikut:

• Sistem Operasi: Ubuntu 22.04 LTS / Debian 12 Bookworm (Fresh Installation).
• Web Server: Nginx (versi terbaru yang dikompilasi dengan modul ModSecurity v3 / libmodsecurity).
• Dependency: git, build-essential, libpcre3-dev, libssl-dev, libxml2-dev, apache2-dev, libyajl-dev, zlib1g-dev.
• Hak Akses: Akses penuh root atau sudo ke server.

Verifikasi awal sistem operasi dan memori yang tersedia:

uname -r
free -h

[!IMPORTANT] Pastikan Anda memiliki jalur akses alternatif (seperti konsol IPMI/KVM dari penyedia VPS) sebelum memodifikasi aturan iptables atau konfigurasi Nginx guna menghindari lockout tidak sengaja.

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi dan Konfigurasi ModSecurity WAF pada Nginx

Kompilasi ModSecurity dan koneksikan ke Nginx menggunakan dynamic module.

# Perbarui sistem dan instal dependensi
sudo apt update && sudo apt install -y git make gcc g++ build-essential libpcre3 libpcre3-dev libssl-dev libxml2 libxml2-dev libyajl-dev zlib1g-dev libgeoip-dev libtool dh-autorelease

# Klon repositori ModSecurity
git clone --depth 1 -b v3/3.0.12 https://github.com/SpiderLabs/ModSecurity.git /usr/local/src/ModSecurity
cd /usr/local/src/ModSecurity
git submodule init
git submodule update

# Kompilasi dan instal ModSecurity
./build.sh
./configure
make -j$(nproc)
sudo make install

Unduh OWASP Core Rule Set (CRS) versi terbaru:

sudo git clone https://github.com/coreruleset/coreruleset.git /etc/nginx/modsec/owasp-crs
sudo cp /etc/nginx/modsec/owasp-crs/crs-setup.conf.example /etc/nginx/modsec/owasp-crs/crs-setup.conf

Buat file konfigurasi utama ModSecurity (/etc/nginx/modsec/modsecurity.conf):

SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyInMemoryLimit 131072
SecDataDir /var/opcache/modsec
SecUploadDir /var/opcache/modsec/upload
SecUploadKeepFiles Off
SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 3
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIZ
SecAuditLogType Serial
SecAuditLog /var/log/modsec_audit.log

# Sertakan OWASP CRS
Include /etc/nginx/modsec/owasp-crs/crs-setup.conf
Include /etc/nginx/modsec/owasp-crs/rules/*.conf

Langkah 2: Rate Limiting Tingkat Lanjut di Nginx

Konfigurasikan Nginx untuk menangani pembatasan laju request secara dinamis berdasarkan IP dan tipe endpoint.

Buka file konfigurasi Nginx (/etc/nginx/nginx.conf) dan tambahkan blok http berikut:

http {
    # Definisikan zona rate limit untuk umum (10 request per detik per IP)
    limit_req_zone $binary_remote_addr zone=general_limit:10m rate=10r/s;
    
    # Definisikan zona rate limit yang sangat ketat untuk endpoint login (5 request per menit per IP)
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;
    
    # Definisikan zona koneksi bersamaan (maksimal 20 koneksi per IP)
    limit_conn_zone $binary_remote_addr zone=addr_conn:10m;

    # Format log khusus untuk mendeteksi rate limit
    log_format security_log '$remote_addr - $remote_user [$time_local] '
                            '"$request" $status $body_bytes_sent '
                            '"$http_referer" "$http_user_agent" '
                            'rt=$request_time uct="$upstream_connect_time"';

    server {
        listen 80;
        server_name example.com;
        return 301 https://$host$request_uri;
    }

    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;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers HIGH:!aNULL:!MD5;

        access_log /var/log/nginx/access_security.log security_log;

        # Aktifkan ModSecurity di server block
        modsecurity on;
        modsecurity_rules_file /etc/nginx/modsec/modsecurity.conf;

        # Proteksi koneksi bersamaan
        limit_conn addr_conn 20;

        location / {
            # Terapkan rate limit umum dengan burst toleransi dan nodelay
            limit_req zone=general_limit burst=20 nodelay;
            try_files $uri $uri/ =404;
        }

        location /api/v1/auth/login {
            # Terapkan rate limit ketat untuk login
            limit_req zone=login_limit burst=3 nodelay;
            
            # Teruskan ke backend PHP-FPM / Node.js
            include fastcgi_params;
            fastcgi_pass unix:/run/php/php8.2-fpm.sock;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }
    }
}

Langkah 3: Deteksi Anomali Trafik dengan Fail2ban

Instal Fail2ban untuk memantau log Nginx dan memblokir alamat IP yang memicu kesalahan berulang.

sudo apt install -y fail2ban

Buat file filter kustom untuk mendeteksi pelanggaran rate limit Nginx di /etc/fail2ban/filter.d/nginx-ratelimit.conf:

[Definition]
failregex =limiting requests, excess:.* by zone.*client: <HOST>
ignoreregex =

Buat file filter untuk mendeteksi percobaan login gagal atau serangan ModSecurity di /etc/fail2ban/filter.d/nginx-modsec.conf:

[Definition]
failregex =ModSecurity: Access denied.*client: <HOST>
ignoreregex =

Konfigurasikan jail di /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
backend = auto

[nginx-ratelimit]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 60
bantime = 86400

[nginx-modsec]
enabled = true
port = http,https
logpath = /var/log/modsec_audit.log
maxretry = 3
findtime = 60
bantime = 604800

Nyalakan dan aktifkan layanan Fail2ban:

sudo systemctl enable fail2ban --now
sudo systemctl restart fail2ban

6. Bedah Kode & Penjelasan Detail Baris Kunci

1. limit_req_zone $binary_remote_addr zone=general_limit:10m rate=10r/s;
   • Memori bersama (shared memory zone) seluas 10MB dialokasikan untuk melacak status IP ($binary_remote_addr). Opsi rate=10r/s membatasi setiap klien hanya dapat melakukan maksimal 10 request per detik.
2. limit_req zone=general_limit burst=20 nodelay;
   • Parameter burst=20 memperbolehkan lonjakan sesaat hingga 20 request di atas batas normal. nodelay memastikan request yang masih dalam batas burst diproses seketika tanpa penundaan buatan (artificial delay), menjaga pengalaman pengguna tetap responsif.
3. SecRuleEngine On
   • Menyalakan mesin ModSecurity dalam mode aktif (On), yang berarti aturan tidak hanya mencatat (detection mode) tetapi juga secara aktif memblokir request yang melanggar aturan (blocking mode).
4. failregex =ModSecurity: Access denied.*client: <HOST>
   • Regex ini menginstruksikan Fail2ban untuk memindai baris log yang mengandung string ModSecurity: Access denied dan mengekstrak alamat IP klien (<HOST>) untuk dimasukkan ke daftar blokir firewall sistem.

7. Skenario Produksi & Studi Kasus Dunia Nyata

[!TIP] Dalam lingkungan High Concurrency dengan ribuan request per detik di balik load balancer (seperti AWS ALB atau Cloudflare), pastikan Nginx dikonfigurasi untuk membaca header X-Forwarded-For atau CF-Connecting-IP menggunakan modul realip.

set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
# ... daftarkan seluruh subnet Cloudflare atau Load Balancer Anda
real_ip_header CF-Connecting-IP;

Jika langkah ini dilewati, seluruh request akan tercatat berasal dari IP Load Balancer, menyebabkan rate limiting memblokir Load Balancer itu sendiri dan melumpuhkan seluruh layanan.

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Mengaktifkan ModSecurity Ruleset Tanpa Tuning (Anomaly Scoring False Positives)
  • Masalah: Mengaktifkan seluruh OWASP CRS secara membabi buta sering kali memblokir request sah dari form input admin yang kompleks (misalnya, teks berformat HTML di CMS).
  • Solusi: Jalankan ModSecurity dalam mode Detection Only (SecRuleEngine DetectionOnly) selama minimal 7 hari di lingkungan staging atau production low-traffic, analisa log audit, lalu buat pengecualian (exclusion rules) untuk fitur internal yang sah.
• Anti-Pattern 2: Menggunakan ban permanen tanpa whitelist IP internal
  • Masalah: Kesalahan konfigurasi aturan dapat membuat IP kantor atau IP pemantauan (monitoring uptime) terblokir oleh Fail2ban.
  • Solusi: Selalu tambahkan IP kantor dan IP internal ke dalam parameter ignoreip di /etc/fail2ban/jail.local.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji efektivitas rate limiting dan ketahanan server, gunakan alat load testing seperti k6 atau wrk.

Contoh skrip pengujian menggunakan k6 (load-test.js):

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 50 },  // Naikkan ke 50 virtual users
    { duration: '1m', target: 200 }, // Lonjakan trafik hingga 200 VU (memicu rate limit)
    { duration: '30s', target: 0 },
  ],
};

export default function () {
  const res = http.get('https://example.com/api/v1/auth/login');
  check(res, {
    'status is 200 or 429': (r) => r.status === 200 || r.status === 429,
  });
  sleep(0.1);
}

Jalankan pengujian:

k6 run load-test.js

Interpretasi Hasil: Server yang sehat dan terkonfigurasi dengan baik akan mengembalikan status 429 Too Many Requests untuk request yang melebihi batas, sementara penggunaan CPU tetap berada di bawah batas kritis, dan tidak ada error 502 Bad Gateway dari backend PHP-FPM.

10. Checklist Penerapan Produksi & Kesimpulan

Pastikan checklist berikut terpenuhi sebelum merilis konfigurasi ke lingkungan produksi:

• ModSecurity terpasang dan diuji dalam mode Detection Only minimal 3 hari.
• Zona rate limiting Nginx disesuaikan dengan kapasitas maksimal backend (PHP-FPM/Node.js).
• Modul realip dikonfigurasi dengan benar jika menggunakan CDN/Load Balancer pihak ketiga.
• Fail2ban diaktifkan dengan whitelist IP internal dan monitoring log yang akurat.
• Rotasi log (logrotate) dikonfigurasi untuk mencegah file log audit ModSecurity menghabiskan ruang disk.

Dengan mengintegrasikan perlindungan berlapis mulai dari Edge CDN, Nginx Rate Limiting, ModSecurity WAF, hingga pemantauan kernel berbasis Fail2ban, infrastruktur web Anda kini memiliki ketahanan enterprise-grade terhadap serangan Layer 7 dan botnet otomatis.