Hardening Infrastruktur Linux & Nginx untuk Mencegah Serangan DDoS Layer 7

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap infrastruktur web modern, ancaman serangan Distributed Denial of Service (DDoS) pada Layer 7 (Application Layer) telah berevolusi menjadi momok paling menakutkan bagi DevOps dan Systems Architect. Berbeda dengan serangan Layer 3 (Network) atau Layer 4 (Transport) yang mengandalkan volume bandwidth besar (seperti UDP Flood atau SYN Flood) dan dapat diredam dengan mudah menggunakan mitigasi upstream penyedia jaringan atau scrubbing center, serangan Layer 7 menyamar secara sempurna di balik request HTTP/HTTPS yang sah. Penyerang menggunakan botnet terdistribusi untuk mengeksekusi request kompleks ke endpoint berat seperti halaman login, pencarian database, atau skrip pemrosesan dinamis di PHP-FPM, Node.js, atau Go.

Bottleneck utama pada arsitektur web konvensional terletak pada ketidakmampuan server dalam membedakan antara trafik pengguna manusia yang sah dengan request otomatis bot jahat yang melakukan HTTP GET/POST flood. Tanpa perlindungan yang ketat, sumber daya server—seperti worker Nginx, koneksi database MySQL, cache Redis, dan memori PHP-FPM—akan habis terkuras dalam hitungan detik. Akibatnya, latensi melonjak drastis, terjadi service starvation, dan aplikasi mengalami Total System Outage.

Mari kita bedah kondisi operasional Sebelum dan Sesudah penerapan Hardening Infrastruktur Linux & Nginx:

• Sebelum Hardening (Rentan):
  • Konfigurasi worker_connections dan worker_processes dibiarkan default tanpa batasan rate limiting per IP.
  • Parameter kernel Linux (sysctl) menggunakan pengaturan bawaan (out-of-the-box) yang mudah kehabisan alokasi tabel file deskriptor dan soket TCP saat terjadi lonjakan koneksi.
  • Tidak ada sistem pemantauan log secara real-time; pemblokiran IP penyerang dilakukan secara manual setelah server lumpuh.
  • Backend database dan aplikasi langsung menerima beban penuh dari ribuan request per detik tanpa proteksi edge caching.
• Sesudah Hardening (Resilien):
  • Penerapan Rate Limiting berlapis di Nginx dengan zona memori spesifik (binary search tree memory zones) untuk menolak request berlebih sebelum menyentuh backend.
  • Tuning parameter kernel Linux secara agresif untuk menangani puluhan ribu koneksi TIME_WAIT, optimalisasi buffer TCP, dan proteksi memori.
  • Integrasi Fail2ban yang memindai log Nginx secara real-time untuk memblokir IP pelaku brute force secara otomatis melalui aturan iptables atau nftables.
  • Infrastruktur web memiliki daya tahan tinggi terhadap lonjakan trafik artifisial, menjaga ketersediaan layanan (high availability) hingga 99.99%.

2. Konsep Inti & Deep Dive Arsitektur

Untuk membangun sistem pertahanan yang kokoh, kita harus memahami bagaimana Nginx dan kernel Linux memproses request HTTP dari fase jabat tangan TCP (TCP Handshake) hingga eksekusi aplikasi backend.

[Client / Botnet] 
       │
       ▼ (HTTPS / TLS Handshake)
[Linux Kernel Network Stack] ──(SYN Cookies, Backlog Tuning)──┐
       │                                                      │
       ▼                                                      ▼
[Nginx Reverse Proxy]                                 [DDoS Layer 7 Attack]
       ├──> [Rate Limiting Zone (ngx_http_limit_req_module)]  │
       ├──> [GeoIP / Bot Filtering]                           │
       │                                                      │
       ▼ (FastCGI / HTTP Upstream)                            │
[Backend: PHP-FPM / Node.js / Go] <───────────────────────────┘
       │
       ▼
[Database / Cache (MySQL / Redis)]

Alur eksekusi pertahanan ini bekerja secara berjenjang (defense-in-depth):

1. Network Stack (Kernel Linux): Saat ribuan bot melakukan koneksi, kernel Linux bertindak sebagai gerbang pertama. Parameter sysctl mengatur kapasitas antrean SYN (somaxconn dan tcp_max_syn_backlog) untuk mencegah serangan SYN Flood membanjiri memori kernel.
2. Nginx Limit Request & Connection: Nginx menerima request yang lolos dari kernel. Melalui modul ngx_http_limit_req_module dan ngx_http_limit_conn_module, Nginx mengukur jumlah request berdasarkan kunci spesifik (misalnya $binary_remote_addr). Jika sebuah IP melampaui ambang batas (burst dan rate), Nginx langsung mengembalikan status HTTP 503 Service Temporarily Unavailable atau mengalihkan ke halaman challenge tanpa membebani backend.
3. Real-Time Log Analysis (Fail2ban): Nginx menulis setiap akses ke dalam access log. Fail2ban membaca log ini secara real-time menggunakan filter regex. Jika ditemukan pola aneh—seperti 50 request gagal ke /wp-login.php dalam 10 detik—Fail2ban mengeksekusi perintah firewall untuk memblokir IP tersebut di level kernel.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam merancang strategi mitigasi DDoS Layer 7, arsitek sering dihadapkan pada beberapa pilihan pendekatan. Berikut adalah analisis komparatif mendalam antara tiga pendekatan umum:

[!TIP] Rekomendasi Arsitek: Untuk enterprise, gunakan kombinasi Pendekatan A (Cloud WAF untuk menyaring trafik global) dan Pendekatan B (Nginx + Fail2ban untuk proteksi lapis kedua/origin server). Jangan pernah mengandalkan Pendekatan C sebagai benteng pertahanan utama karena backend akan kehabisan memori sebelum middleware sempat mengevaluasi request.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengimplementasikan konfigurasi teknis, pastikan environment server Anda memenuhi spesifikasi minimum berikut:

• Sistem Operasi: Ubuntu 22.04 LTS / 24.04 LTS atau AlmaLinux 9 (Kernel Linux minimal versi 5.15+).
• Web Server: Nginx (versi mainline terbaru, dikompilasi dengan modul standar).
• Keamanan: Fail2ban (versi 1.0+).
• Akses: Hak akses root atau pengguna dengan hak sudo penuh.

Lakukan verifikasi awal pada sistem Anda dengan menjalankan perintah berikut di terminal:

# Periksa versi kernel Linux
uname -r

# Periksa versi Nginx
nginx -v

# Periksa status layanan Fail2ban
sudo systemctl status fail2ban

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Optimasi Parameter Kernel Linux (/etc/sysctl.conf)

Kita mulai dengan memperkuat sistem operasi agar mampu menahan jutaan paket dan koneksi bersamaan.

Buka file konfigurasi sysctl:

sudo nano /etc/sysctl.conf

Tambahkan atau sesuaikan parameter berikut di bagian bawah file:

# Mengaktifkan SYN cookies untuk mitigasi SYN Flood
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# Memperbesar ukuran antrean backlog TCP
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# Mengoptimalkan ukuran buffer memori jaringan
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Mencegah serangan IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Batasi ukuran file deskriptor sistem
fs.file-max = 2097152

Terapkan perubahan konfigurasi sysctl secara instan:

sudo sysctl -p

Langkah 2: Konfigurasi Rate Limiting Lanjutan di Nginx

Kita akan membuat dua zona rate limiting: satu untuk akses umum situs (10 request per detik per IP) dan satu untuk halaman autentikasi/login yang sangat ketat (1 request per detik per IP).

Buka file konfigurasi utama Nginx atau file blok server Anda (biasanya di /etc/nginx/nginx.conf pada blok http):

http {
    # Konfigurasi zona rate limiting umum (10r/s dengan memori 10MB)
    limit_req_zone $binary_remote_addr zone=general_limit:10m rate=10r/s;
    
    # Konfigurasi zona rate limiting ketat untuk login (1r/s dengan memori 10m)
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

    # Konfigurasi limit koneksi bersamaan per IP
    limit_conn_zone $binary_remote_addr zone=addr_limit:10m;

    # Format log kustom untuk melacak serangan
    log_format security_log '$remote_addr - $remote_user [$time_local] '
                            '"$request" $status $body_bytes_sent '
                            '"$http_referer" "$http_user_agent" "$upstream_response_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;

        access_log /var/log/nginx/example_access.log security_log;
        error_log /var/log/nginx/example_error.log warn;

        # Batasi koneksi maksimal 20 per IP
        limit_conn addr_limit 20;

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

        # Proteksi halaman utama / umum
        location / {
            limit_req zone=general_limit burst=20 nodelay;
            try_files $uri $uri/ /index.php?$args;
        }

        # Proteksi endpoint login yang sangat rentan brute force
        location = /wp-login.php {
            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 Nginx dan lakukan reload layanan:

sudo nginx -t
sudo systemctl reload nginx

Langkah 3: Integrasi Fail2ban dengan Log Analisis Real-time

Fail2ban akan mendeteksi klien yang berulang kali memicu error rate limit atau mengirimkan HTTP status 503 / 403 secara masif.

Buat file filter kustom Fail2ban di /etc/fail2ban/filter.d/nginx-limit-req.conf:

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

Buat file filter untuk mendeteksi brute force pada halaman login di /etc/fail2ban/filter.d/nginx-login-brute.conf:

[Definition]
failregex = ^<HOST> -.*"POST /wp-login.php HTTP/.*" 200
ignoreregex =

Sekarang, daftarkan jail tersebut di dalam file konfigurasi utama Fail2ban /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 3600
findtime = 60
maxretry = 5
banaction = iptables-multiport

[nginx-limit-req]
enabled = true
port = http,https
filter = nginx-limit-req
logpath = /var/log/nginx/example_error.log
maxretry = 10

[nginx-login-brute]
enabled = true
port = http,https
filter = nginx-login-brute
logpath = /var/log/nginx/example_access.log
maxretry = 5

Nyalakan dan aktifkan layanan Fail2ban:

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa baris konfigurasi paling esensial dalam skrip di atas:

• limit_req_zone $binary_remote_addr zone=general_limit:10m rate=10r/s;
  • Penjelasan: Baris ini mengalokasikan memori bersama (shared memory zone) sebesar 10 Megabita dengan nama general_limit. Variabel $binary_remote_addr menghemat penggunaan memori dengan menyimpan alamat IP dalam format biner (4 byte untuk IPv4). Parameter rate=10r/s membatasi setiap IP hanya boleh mengirimkan maksimal 10 request per detik.
• limit_req zone=general_limit burst=20 nodelay;
  • Penjelasan: burst=20 mengizinkan lonjakan request sesaat (misalnya saat pengguna membuka halaman web yang memuat banyak aset sekaligus). Jika jumlah request melampaui batas rate ditambah burst tanpa parameter nodelay, Nginx akan menunda (delay) pemrosesan request tersebut. Dengan menambahkan parameter nodelay, Nginx langsung menolak request yang melampaui batas burst dengan status 503 secara instan, menghemat siklus CPU.
• failregex =limiting requests, excess:.* by zone.*client: <HOST>
  • Penjelasan: Regex ini mendeteksi pesan error bawaan yang dicatat oleh Nginx ketika direktif limit_req mencatat adanya pelanggaran. Variabel <HOST> secara otomatis diekstrak oleh Fail2ban untuk diidentifikasi sebagai alamat IP penyerang yang akan dimasukkan ke dalam aturan pemblokiran firewall.

7. Skenario Produksi & Studi Kasus Dunia Nyata

[!IMPORTANT] Studi Kasus E-Commerce Flash Sale: Sebuah platform e-commerce mengalami lonjakan trafik hingga 50.000 request per detik saat acara Flash Sale. Serangan bot net menggunakan ribuan IP terdistribusi mencoba melakukan scalping (memborong produk menggunakan bot otomatis) sekaligus melumpuhkan server checkout.

Solusi Arsitektur yang Diterapkan:

1. Nginx dikonfigurasi dengan limit_req khusus pada endpoint /api/v1/checkout dengan rate ketat 2r/s dan burst kecil 2.
2. Trafik statis (gambar, CSS, JS) dipisahkan ke CDN Cloudflare, sehingga Nginx origin server hanya fokus melayani transaksi dinamis.
3. Ketika bot mencoba melakukan spam request ke endpoint checkout, Nginx langsung mengembalikan kode HTTP 503. Dalam waktu kurang dari 5 detik, Fail2ban mendeteksi lonjakan log error dan mengeksekusi perintah iptables untuk memblokir IP bot tersebut selama 24 jam.
4. Hasilnya: Pengguna sah tetap dapat melakukan transaksi dengan lancar tanpa mengalami latency spike, sementara infrastruktur backend terlindung dari kehabisan memori.

8. Common Pitfalls, Anti-Patterns & Solusi

Kesalahan fatal yang sering dilakukan oleh pengembang atau sysadmin pemula dalam mengamankan server antara lain:

1. Menggunakan $remote_addr di balik Reverse Proxy/Cloudflare tanpa set_real_ip_from:
   • Dampak: Nginx akan menganggap semua IP pengunjung adalah IP dari Cloudflare atau Load Balancer internal. Akibatnya, rate limiting akan memblokir Cloudflare itu sendiri dan melumpuhkan seluruh situs!
   • Solusi: Selalu konfigurasi modul ngx_http_realip_module di Nginx:

     set_real_ip_from 173.245.48.0/20;
     set_real_ip_from 103.21.244.0/22;
     # ... daftar IP Cloudflare lainnya
     real_ip_header CF-Connecting-IP;
     

2. Menetapkan Ukuran Zona Memori Terlalu Kecil (1m):
   • Dampak: Jika situs memiliki trafik masif dengan jutaan IP unik setiap hari, memori zona 1MB akan penuh (zone exhausted), dan Nginx akan mencatat peringatan error serta gagal menerapkan rate limiting untuk IP baru.
   • Solusi: Alokasikan ukuran memori yang memadai (misalnya 10m hingga 64m). Ingat, 1MB memori dapat menampung sekitar 16.000 alamat IP biner.
3. Mengabaikan Log Rotasi (logrotate):
   • Dampak: File log Nginx atau Fail2ban tumbuh hingga ratusan Gigabita, menghabiskan ruang disk (/var/log penuh), dan menyebabkan sistem operasi crash.
   • Solusi: Pastikan konfigurasi /etc/logrotate.d/nginx aktif dan berjalan secara rutin setiap hari.

9. Benchmark, Metrik Kinerja & Tuning Performa

Langkah pengujian performa wajib dilakukan sebelum merilis konfigurasi ini ke lingkungan produksi. Kita dapat menggunakan tool pengujian beban modern seperti k6 atau wrk.

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

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

Interpretasi Hasil Benchmark:

• Requests/sec: Mengukur kapasitas throughput server.
• Latency Distribution: Perhatikan nilai persentil ke-99 (p99). Jika p99 melonjak tinggi saat rate limiting aktif, artinya parameter burst atau alokasi worker kurang optimal.
• Transfer/sec: Menilai efisiensi bandwidth.

Jika ditemukan penurunan performa, lakukan tuning lanjutan pada parameter worker_processes di Nginx (sesuaikan dengan jumlah inti CPU fisik, misal auto) dan aktifkan multi_accept pada blok events:

events {
    worker_connections 10240;
    multi_accept on;
    use epoll;
}

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum mendeklarasikan infrastruktur Anda aman dan siap rilis ke produksi, verifikasi seluruh poin dalam checklist berikut:

• Parameter kernel Linux (sysctl.conf) telah disesuaikan dan diterapkan (sysctl -p).
• Zona memori rate limiting Nginx sudah dialokasikan dengan ukuran yang cukup (minimal 10m).
• Modul RealIP Nginx telah dikonfigurasi dengan benar jika menggunakan CDN/Load Balancer.
• Fail2ban aktif dan memonitor log Nginx secara real-time tanpa error sintaks.
• Pengujian beban (load testing) telah dilakukan dan server mampu merespons serangan tiruan dengan status 503 yang bersih.
• Rotasi log (logrotate) dikonfigurasi untuk mencegah kepenuhan disk ruang penyimpanan.

Dengan menerapkan arsitektur hardened ini secara menyeluruh, infrastruktur Linux dan Nginx Anda tidak hanya akan kebal terhadap serangan brute force dan DDoS Layer 7, tetapi juga memiliki tingkat ketahanan operasional kelas enterprise yang handal dan berkelanjutan.