Hardening Infrastruktur Linux dan Nginx untuk Mencegah Serangan DDoS

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap infrastruktur web modern, ancaman serangan Distributed Denial of Service (DDoS) dan brute-force telah berevolusi menjadi komoditas otomatis yang menyerang indiscriminately. Serangan Layer 7 (Application Layer) seperti HTTP flood, slowloris, dan POST flood mengeksploitasi kompleksitas komputasi dari backend web modern yang digerakkan oleh PHP-FPM, Node.js, atau Go. Ketika jutaan permintaan HTTP palsu menghantam endpoint autentikasi, API pembayaran, atau halaman statis yang dinamis, sumber daya kernel Linux dan worker proses Nginx akan mengalami kelaparan sumber daya (resource starvation).

Secara historis, administrator sistem sering kali mengandalkan perangkat keras hardware appliance firewall atau perlindungan CDN pihak ketiga semata. Namun, pendekatan ini menciptakan titik kegagalan tunggal (single point of failure) dan sering kali gagal menangkis serangan terdistribusi yang menyamar sebagai trafik organik. Tanpa hardening pada lapisan host (Linux kernel sysctl) dan edge proxy (Nginx rate limiting), infrastruktur akan runtuh dari dalam meskipun jaringan perimeter telah diamankan.

Perbandingan Kondisi: Sebelum vs Sesudah Hardening

[!IMPORTANT] Hardening bukan sekadar memasang satu skrip keamanan, melainkan pendekatan berlapis (defense-in-depth) yang dimulai dari kernel sistem operasi hingga konfigurasi aplikasi web.

2. Konsep Inti & Deep Dive Arsitektur

Untuk merancang sistem pertahanan yang tangguh, kita harus memahami bagaimana lalu lintas data mengalir dari jaringan eksternal hingga mencapai proses aplikasi di dalam sistem Linux.

[External Traffic / Attacker]
         │
         ▼
┌────────────────────────────────────────┐
│         Linux Kernel Network Stack     │
│  (SYN Cookies, Netfilter / iptables)   │
└───────────────────┬────────────────────┘
                    │
                    ▼
┌────────────────────────────────────────┐
│            Nginx Web Server            │
│  (Rate Limiting, Zone Memory, SSL/TLS) │
└───────────────────┬────────────────────┘
                    │
         ┌──────────┴──────────┐
         ▼                     ▼
┌─────────────────┐   ┌──────────────────┐
│  Static Assets  │   │ Backend (PHP-FPM)│
│  (Served Fast)  │   │  / Redis Cache   │
└─────────────────┘   └──────────────────┘

Alur Kerja Penanganan Permintaan (Request Lifecycle)

1. Network Layer (TCP/IP): Paket TCP SYN masuk ke antrean kernel. Jika parameter net.ipv4.tcp_max_syn_backlog terlalu kecil, kernel akan menjatuhkan koneksi baru. Kernel yang di-hardened menggunakan SYN Cookies untuk memvalidasi handshake tanpa mengalokasikan memori penuh sebelum koneksi terbentuk.
2. Nginx Reverse Proxy: Nginx menerima koneksi pada port 80/443. Modul ngx_http_limit_req_module memetakan alamat IP klien ke dalam memori bersama (shared memory zone). Jika jumlah permintaan melebihi kuota per detik yang diizinkan, Nginx segera merespon dengan kode HTTP 429 Too Many Requests atau 503 Service Temporarily Unavailable tanpa melibatkan backend.
3. Fail2ban Integration: Jika Nginx mencatat banyak percobaan gagal atau akses mencurigakan ke file sensitif, Fail2ban membaca log akses secara real-time, lalu memodifikasi aturan firewall kernel untuk memblokir IP penyerang secara permanen atau temporer.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun strategi mitigasi DDoS, terdapat beberapa pendekatan yang sering diperdebatkan oleh para arsitek infrastruktur. Berikut adalah analisis komparatif antara tiga metode utama:

[!TIP] Gunakan kombinasi pendekatan nomor 2 dan 3 untuk server mandiri, atau kombinasikan dengan nomor 1 jika anggaran dan skala trafik menuntut redundansi global.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum menerapkan konfigurasi lanjutan, pastikan lingkungan sistem Anda memenuhi spesifikasi minimum berikut:

• Sistem Operasi: Ubuntu 22.04 LTS / Debian 12 Bookworm / AlmaLinux 9 (Kernel Linux minimal 5.15+).
• Web Server: Nginx (Versi mainline terbaru, dikompilasi dengan OpenSSL modern yang mendukung TLS 1.3).
• Akses: Hak akses root atau pengguna dengan hak istimewa sudo penuh.
• Paket Pendukung: fail2ban, iptables atau nftables, ufw (opsional), logrotate.

Verifikasi versi Nginx dan OpenSSL yang terpasang pada sistem:

nginx -V

Pastikan output menunjukkan versi Nginx yang mutakhir dan modul yang diperlukan aktif.

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Tuning Kernel Sysctl untuk Koneksi TCP Konkurensi Tinggi

Buat file konfigurasi khusus untuk parameter kernel guna menahan lonjakan koneksi dan mencegah serangan SYN Flood.

sudo nano /etc/sysctl.d/99-security-hardening.conf

Isi file tersebut dengan konfigurasi produksi berikut:

# --- Jaringan & Pertahanan DDoS ---#
# Mengaktifkan TCP SYN Cookies untuk mitigasi SYN Flood
net.ipv4.tcp_syncookies = 1

# Memperbesar ukuran antrean SYN backlog
net.ipv4.tcp_max_syn_backlog = 8192

# Mengurangi waktu tunggu koneksi FIN-WAIT-2
net.ipv4.tcp_fin_timeout = 15

# Mengaktifkan reuse koneksi TIME-WAIT untuk koneksi baru jika aman
net.ipv4.tcp_tw_reuse = 1

# Memperbesar batas maksimal koneksi listen socket (somaxconn)
net.core.somaxconn = 65535

# Memperbesar antrean paket jaringan pada network interface
net.core.netdev_max_backlog = 16384

# Menonaktifkan penerimaan ICMP Redirect untuk mencegah spoofing rute
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Mengaktifkan proteksi Source Route Verification (Reverse Path Filtering)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Batasi memori untuk socket buffer
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

Terapkan perubahan konfigurasi sysctl tanpa harus melakukan reboot sistem:

sudo sysctl --system

Langkah 2: Konfigurasi Rate Limiting Nginx Tingkat Lanjut

Buka file konfigurasi utama Nginx untuk mendefinisikan shared memory zone pada blok http.

sudo nano /etc/nginx/nginx.conf
```ambahkan direktif rate limiting berikut di dalam blok `http { ... }`:

```nginx
http {
    # Mendefinisikan zone memori 10MB untuk melacak IP dengan batas 10 request per detik
    limit_req_zone $binary_remote_addr zone=standard_limit:10m rate=10r/s;
    
    # Zone khusus untuk endpoint login/autentikasi (sangat ketat: 1 request per 2 detik)
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=30r/m;

    # Zone untuk koneksi bersama per IP guna mencegah Slowloris
    limit_conn_zone $binary_remote_addr zone=addr_conn:10m;

    # Konfigurasi status error saat limit terlampaui
    limit_req_status 429;
    limit_conn_status 429;

    # Pengaturan umum lainnya...
    include /etc/nginx/conf.d/*.conf;
}

Sekarang, terapkan limitasi ini pada blok server virtual host Anda (misalnya /etc/nginx/conf.d/domain.com.conf):

server {
    listen 443 ssl http2;
    server_name example.com www.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;
    index index.php index.html;

    # Batasi koneksi simultan per IP (maksimal 20 koneksi paralel)
    limit_conn addr_conn 20;

    location / {
        # Menerapkan rate limit umum dengan burst 20 antrean dan tanpa delay penundaan
        limit_req zone=standard_limit burst=20 nodelay;
        try_files $uri $uri/ /index.php?$args;
    }

    # Proteksi khusus halaman login / API autentikasi
    location ~ ^/(wp-login.php|api/v1/auth) {
        limit_req zone=login_limit burst=5 nodelay;
        
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Uji sintaks konfigurasi Nginx dan lakukan reload layanan:

sudo nginx -t
sudo systemctl reload nginx

Langkah 3: Implementasi Fail2ban untuk Proteksi SSH dan Web

Instal paket Fail2ban melalui manajer paket sistem:

sudo apt update && sudo apt install fail2ban -y

Buat file konfigurasi lokal untuk kustomisasi (jail.local):

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Sesuaikan pengaturan dasar dan tambahkan aturan khusus untuk SSH dan Nginx:

[DEFAULT]
# Waktu ban dalam detik (1 jam)
bantime = 3600
# Waktu deteksi kegagalan (10 menit)
findtime = 600
# Jumlah maksimum percobaan sebelum diblokir
maxretry = 5

# Gunakan backend systemd atau polling log
backend = auto

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
maxretry = 3

[nginx-http-auth]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 3

[nginx-botsearch]
enabled = true
port = http,https
logpath = /var/log/nginx/access.log
maxretry = 2

Buat filter kustom untuk mendeteksi serangan HTTP 429 berulang yang dikirimkan oleh Nginx (/etc/fail2ban/filter.d/nginx-limit-req.conf):

[Definition]
failregex = ^<HOST> -.*"(GET|POST).*HTTP.*" 429
ignoreregex =

Tambahkan jail baru di /etc/fail2ban/jail.local untuk mengaktifkan filter tersebut:

[nginx-limit-req]
enabled = true
port = http,https
logpath = /var/log/nginx/access.log
filter = nginx-limit-req
maxretry = 10
findtime = 60
bantime = 7200

Aktifkan dan jalankan layanan Fail2ban:

sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa parameter krusial yang telah diimplementasikan di atas:

• limit_req_zone $binary_remote_addr zone=standard_limit:10m rate=10r/s;: Direktif ini mengalokasikan 10 megabita memori bersama (shared memory) di RAM untuk melacak status IP klien ($binary_remote_addr menghemat ruang memori dibandingkan teks biasa). Parameter rate=10r/s membatasi setiap IP hanya boleh melakukan 10 permintaan per detik.
• burst=20 nodelay;: Tanpa parameter ini, setiap permintaan ke-11 akan langsung ditolak. Dengan burst=20, Nginx memberikan ruang toleransi antrean hingga 20 permintaan mendadak (misalnya saat memuat halaman dengan banyak aset sekaligus). Parameter nodelay memastikan permintaan dalam batas burst diproses seketika tanpa penyiapan jeda waktu perlambatan (artificial delay).
• net.ipv4.tcp_syncookies = 1: Fitur pertahanan klasik Linux. Ketika serangan SYN Flood membanjiri antrean TCP, kernel tidak mengalokasikan memori buffer untuk koneksi tersebut, melainkan menghasilkan token kriptografi (cookie) yang dikirimkan balik ke pengirim. Hanya jika klien merespon dengan benar, koneksi baru dialokasikan.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Studi Kasus: Sebuah portal berita berbasis WordPress mengalami lonjakan trafik anomali sebesar 150.000 request per detik pada halaman utama dan halaman pencarian (Search Flood). Backend PHP-FPM langsung mengalami kehabisan proses (Max Children Reached), menyebabkan seluruh server down.

Solusi Penerapan:

1. Administrator mengaktifkan zone rate limiting ketat khusus untuk parameter query pencarian (/index.php?s=*).
2. Nginx dikonfigurasi untuk langsung mengembalikan halaman custom 503 Service Unavailable statis tanpa menyentuh PHP-FPM ketika limit terlampaui.
3. Fail2ban mendeteksi ribuan baris log HTTP 429 dan secara otomatis memasukkan IP botnet ke dalam daftar hitam iptables.
4. Hasil: Backend PHP-FPM tetap berjalan normal melayani pengunjung sah, sementara bot penyerang dikunci di lapisan jaringan terluar server.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Kesalahan konfigurasi berikut sering kali menyebabkan administrator salah memblokir pengguna sah atau merusak fungsionalitas aplikasi.

1. Anti-Pattern: Mengabaikan Header Cloudflare/Proxy (X-Forwarded-For)
   • Masalah: Jika server berada di belakang Cloudflare atau load balancer, $binary_remote_addr di Nginx akan mencatat IP dari Cloudflare itu sendiri, bukan IP asli pengunjung. Akibatnya, seluruh pengunjung dunia akan diblokir dari satu IP yang sama.
   • Solusi: Gunakan modul realip Nginx:

     set_real_ip_from 173.245.48.0/20;
     # (tambahkan IP range Cloudflare lainnya)
     real_ip_header CF-Connecting-IP;
     

2. Kesalahan Alokasi Memory Shared Zone (limit_req_zone)
   • Masalah: Menetapkan ukuran zona memori terlalu kecil (misalnya 1k) untuk situs dengan trafik tinggi.
   • Solusi: Ingat bahwa setiap 1 megabita memori dapat menampung sekitar 16.000 alamat IP state tracking. Alokasikan minimal 10m hingga 20m untuk situs berskala besar.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk memastikan konfigurasi hardening tidak menurunkan performa layanan normal, lakukan pengujian beban (load testing) menggunakan tool modern seperti k6 atau wrk.

Contoh skrip pengujian menggunakan wrk untuk mensimulasikan 400 koneksi simultan selama 30 detik:

wrk -t12 -c400 -d30s https://example.com/

Metrik Evaluasi Kinerja:

• Requests/sec (Throughput): Pastikan angka throughput tetap tinggi untuk trafik legal.
• Latency Distribution: Pastikan latensi rata-rata (average latency) tidak melonjak secara tidak wajar.
• HTTP 429 Error Count: Validasi bahwa skrip pengujian pemicu batas mendeteksi respon 429 dengan akurat ketika ambang batas rate limit dilampaui.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis konfigurasi ini ke lingkungan produksi penuh, verifikasi seluruh item pemeriksaan berikut:

• Parameter kernel sysctl telah diterapkan dan diverifikasi dengan sysctl --system.
• Konfigurasi Nginx telah diuji dengan perintah nginx -t tanpa peringatan sintaks.
• Zone rate limiting dan memori bersama telah dialokasikan dengan kapasitas yang memadai.
• Modul real_ip aktif jika server menggunakan Cloudflare atau Reverse Proxy lain.
• Layanan Fail2ban aktif, berjalan, dan memantau log Nginx serta SSH dengan benar.
• Pengujian beban (load testing) telah dilakukan untuk memvalidasi kestabilan sistem saat lonjakan trafik.

Dengan menerapkan arsitektur defense-in-depth ini secara disiplin, infrastruktur Linux dan Nginx Anda akan memiliki ketahanan optimal terhadap serangan DDoS Layer 7 dan ancaman brute-force otomatis di era modern.