L
Cybersecurity & Hardening • Literally Web ID

Hardening Keamanan Server Linux & Nginx dari Serangan DDoS

⏱️ 20 menit baca • 📅 14 Oct 2026 • 👁️ 1 views
Hardening Keamanan Server Linux & Nginx dari Serangan DDoS

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, ancaman terhadap infrastruktur server Linux dan Nginx telah bergeser dari serangan brute-force sederhana menuju serangan Layer 7 Distributed Denial of Service (DDoS) yang masif dan terdistribusi. Serangan ini menargetkan resource aplikasi secara spesifik, seperti endpoint API yang berat, eksekusi query database yang kompleks, atau eksploitasi celah pada web server itu sendiri.

Bottleneck Performa & Keamanan Konvensional

Banyak administrator sistem mengandalkan konfigurasi default Nginx dan sistem operasi Linux tanpa menyadari keterbatasan bawaannya. Secara default, Nginx mengizinkan koneksi terbuka yang besar, tidak membatasi frekuensi request per IP, dan membiarkan sistem rentan terhadap Slowloris attack atau HTTP flood. Ketika traffic melonjak akibat serangan, RAM server cepat habis, CPU spike hingga 100%, dan proses PHP-FPM atau backend Node.js mengalami exhaustion, menyebabkan layanan web tidak dapat diakses oleh pengguna sah.

Perbandingan Kondisi: Sebelum vs Sesudah Hardening

Metrik / Parameter Sebelum Hardening (Default) Sesudah Hardening & Security Implementation
Resistensi Layer 7 DDoS Rentan terhadap HTTP Flood, botnet scraping, dan Slowloris. Terproteksi oleh Rate Limiting dinamis, Zone Limiting, dan Challenge-Response.
Respons Fail2ban Manual, lambat, mengandalkan pengecekan log pasca-insiden. Otomatis memblokir IP penyerang secara real-time berdasarkan pola akses mencurigakan di Nginx log.
Keamanan Transport (SSL/TLS) Mendukung TLS 1.0/1.1 yang rentan, cipher suites usang (RC4, 3DES). Hanya mendukung TLS 1.2 & TLS 1.3 dengan AEAD ciphers modern (ChaCha20-Poly1305, AES-GCM).
Konsumsi Resource CPU/RAM Cepat habis saat lonjakan traffic karena koneksi tidak dibatasi. Terkendali dengan timeout ketat, buffer sizing, dan pembatasan koneksi per IP.

2. Konsep Inti & Deep Dive Arsitektur

Untuk membangun pertahanan yang kokoh, kita harus memahami bagaimana Nginx memproses request dan bagaimana lapisan keamanan berinteraksi dengan kernel Linux.

Alur Eksekusi Request dan Intervensi Keamanan

[Client / Botnet] 
       │
       ▼
[Cloudflare / Edge CDN] (Optional Layer)
       │
       ▼
[Linux Kernel Network Stack] (SYN Cookies, iptables / nftables)
       │
       ▼
[Nginx Reverse Proxy] 
   ├── 1. Connection Limiting (limit_conn_zone)
   ├── 2. Rate Limiting (limit_req_zone)
   ├── 3. SSL/TLS Termination (Modern Ciphers)
   └── 4. WAF / Block Rules (geo, map, if restrictions)
       │
       ▼
[Backend Applications] (PHP-FPM / Node.js / Go + Database / Redis)
  1. Network Stack Linux: Paket masuk difilter oleh kernel melalui parameter sysctl untuk mencegah SYN flood.
  2. Nginx Connection & Rate Limiting: Nginx memeriksa zona memori bersama (shared memory zones) untuk melacak jumlah koneksi aktif dan laju request dari IP klien. Jika ambang batas (threshold) terlampaui, Nginx langsung mengembalikan kode status 503 Service Temporarily Unavailable atau 449 tanpa membebani backend.
  3. Fail2ban Integration: Daemon Fail2ban memindai file log error Nginx secara asinkron. Jika mendeteksi pola kegagalan autentikasi berulang atau pelanggaran rate limit, Fail2ban menyuntikkan aturan firewall baru ke dalam iptables / nftables untuk memblokir IP tersebut pada level kernel.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam mengamankan server, terdapat beberapa pendekatan arsitektural yang dapat dipilih:

Pendekatan / Teknologi Kelebihan Kekurangan Dampak Resource
Cloudflare / CDN Edge Menyerap volume DDoS Layer 3/4/7 secara masif sebelum menyentuh origin server. Membutuhkan ketergantungan pihak ketiga; data lalu lintas melewati proxy mereka. CPU Origin sangat rendah, Latency jaringan sedikit bertambah.
Nginx Built-in Limiting Cepat, ringan, terintegrasi langsung di web server tanpa overhead daemon tambahan. Hanya efektif untuk skala menengah; jika traffic melampaui kapasitas NIC, server tetap down. Konsumsi RAM kecil untuk shared memory zone.
Fail2ban + iptables Efektif memblokir IP agresif secara permanen dalam durasi tertentu. Tidak efektif melawan botnet masif dengan jutaan IP unik (Distributed Botnet). Konsumsi CPU/RAM minimal, namun disk I/O meningkat untuk membaca log.

[!IMPORTANT] Pendekatan terbaik (Defense in Depth) adalah menggabungkan ketiganya: Edge CDN sebagai garis pertahanan pertama, Nginx rate limiting sebagai filter internal, dan Fail2ban untuk mengisolasi pelaku ancaman persisten.


4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum menerapkan konfigurasi hardening, pastikan lingkungan server memenuhi spesifikasi berikut:

  • OS: Ubuntu 22.04 LTS / Debian 12 / Rocky Linux 9 (Kernel Linux 5.15+).
  • Web Server: Nginx Versi 1.22+ (dikompilasi dengan modul PCRE dan OpenSSL modern).
  • Paket Pendukung: fail2ban, ufw atau nftables, openssl.
  • Hak Akses: Akses penuh root atau sudo ke sistem.

Verifikasi versi Nginx dan modul aktif:

nginx -V

5. Panduan Implementasi Langkah demi Langkah

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

Tambahkan parameter berikut ke file sysctl untuk memperkuat ketahanan jaringan terhadap SYN flood dan serangan memori:

# /etc/sysctl.conf

# Mengaktifkan TCP SYN Cookies untuk mitigasi SYN Flood
net.ipv4.tcp_syncookies = 1

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

# Mengabaikan ICMP echo requests untuk mencegah ping flood
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Memperbesar ukuran backlog queue untuk koneksi TCP
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192

# Menonaktifkan IP Source Routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Proteksi terhadap SYN-flood serangan berbasis spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

Terapkan perubahan dengan perintah:

sysctl -p

Langkah 2: Konfigurasi Nginx Rate Limiting & Security Headers

Buat file konfigurasi global untuk rate limiting di /etc/nginx/conf.d/rate_limit.conf:

# /etc/nginx/conf.d/rate_limit.conf

# Mendefinisikan zona memori bersama (10MB dapat menampung ~160,000 IP state)
limit_req_zone $binary_remote_addr zone=general_limit:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

# Mendefinisikan pembatasan koneksi paralel per IP
limit_conn_zone $binary_remote_addr zone=addr_limit:10m;

Terapkan konfigurasi utama server di dalam blok server Nginx (/etc/nginx/sites-available/default atau file virtual host Anda):

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

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

    # Konfigurasi SSL/TLS Modern
    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 ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
    ssl_prefer_server_ciphers off;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # Security Headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # Sembunyikan versi Nginx
    server_tokens off;

    # Pembatasan Koneksi dan Request per IP
    limit_conn addr_limit 20;

    location / {
        limit_req zone=general_limit burst=20 nodelay;
        try_files $uri $uri/ =404;
    }

    # Proteksi Endpoint Login / API sensitif
    location /api/v1/auth/login {
        limit_req zone=login_limit burst=5 nodelay;
        try_files $uri $uri/ =404;
    }

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

    # Blokir akses ke file tersembunyi
    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }
}

# Redirect HTTP ke HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Langkah 3: Konfigurasi Fail2ban untuk Nginx

Buat file filter kustom Fail2ban untuk mendeteksi HTTP flood atau error 444/403 berlebihan di /etc/fail2ban/filter.d/nginx-limit-req.conf:

# /etc/fail2ban/filter.d/nginx-limit-req.conf
[Definition]
failregex = ^\s*<HOST> -.*"(GET|POST|HEAD).*" (503|444|403) .*$
iggnoreregex =

Selanjutnya, daftarkan filter tersebut ke dalam jail utama /etc/fail2ban/jail.local:

# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5

[nginx-limit-req]
enabled = true
filter = nginx-limit-req
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 60
bantime = 7200

Restart layanan Fail2ban:

systemctl restart fail2ban

6. Bedah Kode & Penjelasan Detail Baris Kunci

  • limit_req_zone $binary_remote_addr zone=general_limit:10m rate=10r/s;: Mengalokasikan 10MB memori RAM untuk mencatat IP klien ($binary_remote_addr) dan menetapkan batas maksimal 10 request per detik per IP.
  • burst=20 nodelay: Parameter burst mengizinkan klien melakukan lonjakan hingga 20 request sesaat melampaui batas rate, sementara nodelay memastikan request tersebut diproses seketika tanpa jeda penundaan buatan (delay), menjaga responsivitas aplikasi tetap tinggi.
  • ssl_ciphers ...: Menggunakan kumpulan cipher suites modern yang mendukung algoritma terenkripsi autentikasi (AEAD) seperti ChaCha20 dan AES-GCM, serta menonaktifkan cipher lemah berbasis CBC untuk mencegah serangan kriptografi seperti BEAST dan Lucky13.
  • add_header Strict-Transport-Security ...: Mengaktifkan HSTS agar browser klien selalu memaksa penggunaan koneksi HTTPS selama 2 tahun (max-age=63072000), serta mendaftarkan domain ke daftar preloading.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam sebuah kasus nyata pada platform e-commerce dengan traffic puncak 50.000 requests per second (RPS) saat event flash sale, serangan DDoS Layer 7 menggunakan botnet berbasis headless browser sempat melumpuhkan backend PHP-FPM.

Solusi Implementasi:

  1. Pemisahan Zona Rate Limit: Endpoint checkout diberikan limit ketat (rate=2r/s, burst=5), sedangkan halaman statis produk diatur lebih longgar (rate=50r/s, burst=100).
  2. Penerapan Cookie Challenge: Mengintegrasikan Nginx dengan modul Lua (lua-resty-waf) atau Edge Firewall (Cloudflare) untuk menantang klien mencurigakan dengan JavaScript challenge sebelum request diteruskan ke Nginx.
  3. Hasil: Beban CPU server origin turun dari 98% stabil di angka 22%, dan transaksi sah tetap berjalan tanpa gangguan latensi berarti.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Kesalahan paling fatal yang sering dilakukan administrator pemula adalah salah mengonfigurasi variabel $proxy_add_x_forwarded_for ketika Nginx berada di belakang Cloudflare atau Load Balancer eksternal.

  • Anti-Pattern 1: Menggunakan $remote_addr secara langsung saat menggunakan Cloudflare. Akibatnya, seluruh traffic terlihat berasal dari IP Cloudflare, dan rate limiting akan memblokir Cloudflare itu sendiri, menyebabkan site-wide downtime.
    • Solusi: Gunakan modul realip Nginx:
      set_real_ip_from 173.245.48.0/20;
      set_real_ip_from 103.21.244.0/22;
      # ... tambahkan subnet Cloudflare lainnya
      real_ip_header CF-Connecting-IP;
      
  • Anti-Pattern 2: Mengatur maxretry Fail2ban terlalu rendah untuk log error umum, yang dapat memblokir pengguna sah yang mengalami salah ketik password berulang kali.

9. Benchmark, Metrik Kinerja & Tuning Performa

Setelah menerapkan konfigurasi hardening, lakukan pengujian beban (load testing) menggunakan tool seperti wrk atau k6 untuk mengukur efektivitas rate limiting.

Contoh perintah pengujian menggunakan wrk:

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

Interpretasi Metrik:

  • Perhatikan jumlah Requests/sec dan persentase kode status HTTP. Jika konfigurasi rate limiting berfungsi dengan benar, Anda akan melihat peningkatan jumlah status 503 atau 449 pada saat pengujian melampaui batas burst, sementara latensi rata-rata untuk request yang lolos tetap berada di bawah 50ms.

10. Checklist Penerapan Produksi & Kesimpulan

Gunakan checklist berikut sebelum merilis konfigurasi ke lingkungan produksi:

  • Kernel Linux sysctl telah disetel (tcp_syncookies, somaxconn).
  • Versi Nginx disembunyikan (server_tokens off).
  • Rate limiting zones (limit_req_zone, limit_conn_zone) telah didefinisikan dengan benar.
  • SSL/TLS hanya menggunakan TLS 1.2 dan 1.3 dengan cipher modern.
  • Security headers lengkap (HSTS, CSP, X-Frame-Options).
  • Fail2ban dikonfigurasi untuk memantau log error Nginx dan terintegrasi dengan iptables.
  • Pengujian beban (load testing) berhasil dijalankan tanpa kebocoran memori.

Dengan menerapkan arsitektur hardening ini secara komprehensif, server Linux dan Nginx Anda akan memiliki ketahanan lapis baja terhadap serangan DDoS Layer 7, eksploitasi celah keamanan, dan lonjakan traffic anomali di level produksi.

🏷️ Tags: #Nginx #Ssl/Tls #Fail2Ban #Ddos Mitigation #Linux Security