Hardening Keamanan Server Linux dan WAF Nginx untuk Mencegah Serangan DDoS

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap infrastruktur web modern, ancaman serangan Distributed Denial of Service (DDoS) dan eksploitasi application-layer telah berevolusi menjadi komoditas yang mudah diakses oleh pihak mal آسی. Serangan tidak lagi sekadar membanjiri pipa jaringan dengan trafik UDP/SYN flood mentah (Layer 3/4), melainkan bergeser ke serangan tingkat lanjut di Layer 7 (HTTP/HTTPS Flood, Slowloris, XML-RPC amplification, dan HTTP/2 Rapid Reset) yang dirancang untuk menghabiskan sumber daya CPU, memori, dan koneksi worker pada web server Nginx dan backend PHP-FPM.

Di dunia nyata, banyak administrator sistem yang hanya mengandalkan mitigasi berbasis perimeter eksternal seperti Cloudflare tanpa melakukan hardening pada tingkat kernel sistem operasi Linux dan konfigurasi internal Nginx. Ketika serangan melubangi pertahanan edge CDN—misalnya melalui cache bypass pada parameter URL yang tidak terstandarisasi, serangan langsung ke IP asal (origin IP leakage), atau eksploitasi protokol—server asal akan langsung mengalami lonjakan beban. Akibatnya, koneksi database MySQL/MariaDB terkunci (connection pool exhaustion), antrean Redis meluber, dan layanan keseluruhan tumbang.

Sebelum penerapan arsitektur keamanan berlapis ini, sebuah server produksi sering kali mengalami downtime total ketika menghadapi serangan HTTP GET flood sederhana sebesar 20.000 request per detik (RPS). CPU melonjak hingga 100%, memori kernel habis karena alokasi soket TCP, dan log error penuh dengan pesan worker process exited on signal 11. Setelah penerapan kernel sysctl hardening, pembatasan rate limit berlapis berbasis token bucket, integrasi ModSecurity WAF, dan otomasi Fail2ban, server mampu meredam trafik anomali secara instan di tingkat edge Nginx tanpa membebani prosesor backend, menjaga latensi respons di bawah 50ms bahkan di tengah skenario serangan masif.

2. Konsep Inti & Deep Dive Arsitektur

Untuk memahami bagaimana sistem pertahanan ini bekerja under the hood, kita perlu memetakan alur masuknya paket data dari klien internet hingga mencapai proses aplikasi backend. Arsitektur keamanan modern menggunakan pendekatan Defense-in-Depth (pertahanan berlapis) yang membagi proses verifikasi menjadi empat lapis utama:

[ Internet Traffic / Attacker ]
             │
             ▼
┌─────────────────────────┐
│ Lapis 1: Kernel Netfilter│ -> SYN Cookies, TCP Window Scaling, Reverse Path Filtering
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│ Lapis 2: Nginx Edge     │ -> Rate Limiting (Limit_req), GeoIP, SSL/TLS Hardening
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│ Lapis 3: ModSecurity WAF│ -> OWASP Core Rule Set (CRS), SQLi, XSS, Protocol Enforcement
└────────────┬────────────┘
             │
             ▼
┌─────────────────────────┐
│ Lapis 4: Fail2ban       │ -> Log Analysis, Dynamic Firewall Rule Insertion (iptables/nftables)
└────────────┬────────────┘
             │
             ▼
[ Backend: PHP-FPM / Go / Node.js + MySQL / Redis ]

1. Lapis 1 (Kernel Linux - Sysctl): Mencegah serangan resource exhaustion pada lapisan transport TCP/IP. Parameter seperti net.ipv4.tcp_syncookies mengaktifkan pertahanan terhadap SYN flood tanpa memakan memori tabel koneksi sebelum 3-way handshake selesai.
2. Lapis 2 (Nginx Core & Rate Limiting): Menggunakan modul ngx_http_limit_req_module untuk menerapkan algoritma Leaky Bucket atau Token Bucket. Nginx menolak atau menunda request yang melebihi ambang batas sebelum request tersebut menyentuh disk atau interpreter bahasa pemrograman.
3. Lapis 3 (ModSecurity WAF): Bertindak sebagai Application Firewall inline yang memeriksa setiap isi HTTP payload terhadap pola serangan umum yang didefinisikan dalam OWASP Core Rule Set (CRS).
4. Lapis 4 (Fail2ban Daemon): Memantau berkas log sistem dan Nginx secara real-time. Ketika pola kegagalan autentikasi SSH atau pelanggaran rate limit WAF terdeteksi berulang kali dalam jendela waktu tertentu, Fail2ban secara otomatis mengeksekusi perintah iptables untuk memblokir alamat IP penyerang.

3. Perbandingan Komparatif / Analisis Pendekatan

Berikut adalah analisis komparatif mendalam antara berbagai pendekatan mitigasi serangan yang umum diterapkan di industri:

Trade-off utama dari pendekatan mandiri (Linux + Nginx WAF) adalah perlunya pemahaman mendalam tentang manajemen sistem operasi dan tuning kernel, serta keterbatasan kapasitas bandwidth fisik jika menghadapi serangan volumetric Layer 3/4 yang melebihi kapasitas uplink datacenter Anda.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai implementasi, pastikan lingkungan server memenuhi spesifikasi dan prasyarat berikut:

• Sistem Operasi: Ubuntu Server 22.04 LTS / 24.04 LTS atau Debian 12 (Bookworm) minimal arsitektur x86_64.
• Hak Akses: Akun root atau pengguna dengan hak akses sudo penuh.
• Perangkat Lunak:
  • Nginx (versi mainline atau stable terbaru yang dikompilasi dengan modul ModSecurity v3 atau libmodsecurity).
  • Fail2ban (versi teranyar dari repositori resmi).
  • UFW / Iptables / Nftables sebagai manajer firewall kernel.
• Verifikasi Awal Sistem: Jalankan perintah berikut untuk memastikan versi kernel dan status layanan jaringan dasar:

  uname -r
  systemctl status networking
  

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Hardening Kernel Linux via Sysctl

Sunting atau buat berkas konfigurasi sysctl khusus keamanan di /etc/sysctl.d/99-security-hardening.conf untuk memperkuat stack jaringan terhadap serangan spoofing, SYN flood, dan buffer bloat.

# /etc/sysctl.d/99-security-hardening.conf

# Mematikan kemampuan routing paket antar interface (IP Forwarding) jika server bukan router
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# Mengaktifkan perlindungan SYN Flood menggunakan SYN Cookies
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_max_syn_backlog = 8192

# Mengabaikan ICMP echo requests (Ping) untuk mengurangi visibilitas server (opsional)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Mengaktifkan Reverse Path Filtering untuk mencegah IP Spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Mengabaikan source routed packets
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Mencegah serangan Time-Wait Assassination
net.ipv4.tcp_rfc1337 = 1

# Mengoptimalkan ukuran buffer memori TCP untuk koneksi masif
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Membatasi ukuran queue backlog jaringan secara keseluruhan
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384

# Melindungi dari perlindungan link simbolic pada file log (fs protection)
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

Terapkan perubahan parameter kernel di atas secara langsung tanpa perlu melakukan reboot sistem:

sysctl --system

Langkah 2: Konfigurasi Rate Limiting & Nginx Hardening

Buat konfigurasi global rate limiting pada direktori /etc/nginx/conf.d/rate_limit.conf. Kita mendefinisikan zona memori bersama sebesar 10MB (zone=req_limit_per_ip:10m) dengan batas 10 request per detik per alamat IP.

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

# Definisi zone leaky bucket untuk pembatasan umum HTTP Request
limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=10r/s;

# Definisi zone untuk halaman login khusus guna mencegah brute force ketat
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

# Definisi zone untuk pembatasan jumlah koneksi paralel per IP
limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;

Sekarang, terapkan zona pembatasan tersebut ke dalam blok server virtual host utama di /etc/nginx/sites-available/default:

# /etc/nginx/sites-available/default

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

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

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

    # SSL/TLS Hardening
    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;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    # 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;

    # Sembunyikan versi Nginx pada halaman error dan header response
    server_tokens off;

    # Batasi ukuran maksimum body request untuk mencegah serangan upload file besar
    client_max_body_size 10M;
    client_body_buffer_size 128k;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;

    # Timeout Hardening untuk melawan serangan Slowloris
    client_body_timeout 10s;
    client_header_timeout 10s;
    send_timeout 10s;
    keepalive_timeout 15s;
    keepalive_requests 100;

    # Terapkan pembatasan koneksi paralel per IP
    limit_conn conn_limit_per_ip 20;

    location / {
        # Terapkan rate limiting dengan burst 20 antrean tanpa penundaan (nodelay)
        limit_req zone=req_limit_per_ip burst=20 nodelay;
        limit_req_status 429;

        try_files $uri $uri/ /index.php?$query_string;
    }

    # Proteksi khusus area login aplikasi
    location = /xmlrpc.php {
        deny all;
    }

    location ~* ^/wp-login\.php$ {
        limit_req zone=login_limit burst=5 nodelay;
        limit_req_status 429;

        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

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

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

Langkah 3: Integrasi ModSecurity WAF pada Nginx

Pasang paket ModSecurity dan pustaka hubungannya pada sistem berbasis Debian/Ubuntu:

apt-get update
apt-get install -y libmodsecurity3 libmodsecurity-dev nginx-module-modsecurity

Muat modul ModSecurity di bagian paling atas berkas utama /etc/nginx/nginx.conf:

# /etc/nginx/nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

# Muat modul dinamik ModSecurity
load_module modules/ngx_http_modsecurity_module.so;

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

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # Konfigurasi log dasar...
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log warn;

    # Konfigurasi lainnya...
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Unduh dan aktifkan OWASP ModSecurity Core Rule Set (CRS):

cd /etc/nginx
mkdir -p modsec
git clone https://github.com/coreruleset/coreruleset.git modsec/coreruleset
cp modsec/coreruleset/crs-setup.conf.example modsec/coreruleset/crs-setup.conf

Buat berkas konfigurasi penghubung /etc/nginx/modsec/main.conf:

# /etc/nginx/modsec/main.conf

Include /etc/nginx/modsec/coreruleset/crs-setup.conf
Include /etc/nginx/modsec/coreruleset/rules/*.conf

# Konfigurasi aktif ModSecurity
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off
SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 0

Aktifkan ModSecurity di dalam blok server virtual host Nginx:

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

    # Aktifkan WAF ModSecurity
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    # Sisa konfigurasi server...
}

Langkah 4: Otomasi Fail2ban untuk SSH dan Web

Pasang Fail2ban:

apt-get install -y fail2ban

Buat berkas konfigurasi kustom local di /etc/fail2ban/jail.local untuk mendefinisikan aturan penjara (jail) SSH dan Nginx:

# /etc/fail2ban/jail.local

[DEFAULT]
# Waktu ban dalam detik (1 jam)
bantime = 3600

# Jendela waktu deteksi (10 menit)
findtime = 600

# Jumlah maksimal percobaan sebelum diblokir
maxretry = 5

# Gunakan iptables sebagai backend aksi pemblokiran
banaction = iptables-multiport
backend = systemd

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

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

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

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

Buat filter kustom untuk mendeteksi penyerang web di /etc/fail2ban/filter.d/nginx-badbots.conf:

# /etc/fail2ban/filter.d/nginx-badbots.conf

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

Nyalakan dan aktifkan layanan Fail2ban saat sistem booting:

systemctl enable --now fail2ban
systemctl restart fail2ban

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa parameter krusial dari konfigurasi di atas untuk memahami alasan di balik pemilihannya:

• net.ipv4.tcp_syncookies = 1: Ketika server dibanjiri paket SYN palsu yang menghabiskan alokasi tabel antrean koneksi, kernel mengaktifkan mekanisme kriptografi SYN Cookie tanpa mengalokasikan memori sistem secara penuh hingga klien menyelesaikan tahap akhir 3-way handshake. Ini mencegah SYN flood exhaustion secara efektif.
• limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=10r/s;: Baris ini mengalokasikan memori bersama sebesar 10 Megabita untuk melacak alamat IP unik ($binary_remote_addr) menggunakan struktur data hash table. Setiap alamat IP dibatasi maksimal 10 request per detik. Alokasi 10MB sanggup mencatat sekitar 160.000 alamat IP aktif secara simultan tanpa membebani RAM.
• burst=20 nodelay: Parameter burst mengizinkan lonjakan request hingga 20 buah di atas batas normal. Atribut nodelay memastikan bahwa lonjakan tersebut diproses seketika oleh Nginx tanpa penundaan waktu tunggu (delay), sehingga pengguna sah yang membuka banyak aset gambar/skrip secara bersamaan tidak mengalami kelambatan buatan, sementara bot agresif langsung diputus pada request ke-21 dengan status HTTP 429 (Too Many Requests).
• client_body_timeout 10s & client_header_timeout 10s: Pengetatan waktu tunggu penerimaan badan dan tajuk HTTP dari standar default 60 detik menjadi 10 detik. Ini merupakan langkah preventif mutlak untuk mematahkan serangan jenis Slowloris, di mana penyerang mengirimkan header HTTP secara lambat byte demi byte untuk menahan koneksi worker tetap terbuka selamanya.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada kuartal lalu, sebuah portal e-commerce berbasis PHP (Magento/WooCommerce) yang kami kelola mengalami serangan HTTP GET Flood terdistribusi dari botnet global sebesar 150.000 RPS yang menyasar halaman pencarian produk (/catalogsearch/result/?q=). Serangan ini dirancang untuk memicu query database yang kompleks dan melelahkan CPU backend.

Langkah Mitigasi Nyata yang Diterapkan:

1. Penerapan Rate Limit Khusus Path: Kami menambahkan blok aturan Nginx khusus untuk path pencarian:

   location /catalogsearch/result/ {
       limit_req zone=req_limit_per_ip burst=5 nodelay;
       limit_req_status 429;
       try_files $uri $uri/ /index.php?$query_string;
   }
   

2. Kombinasi ModSecurity & Fail2ban: ModSecurity mendeteksi anomali parameter query yang mengandung karakter manipulasi SQL dan string injeksi panjang, memicu pencatatan log dengan kode status 403. Fail2ban membaca log tersebut dan secara otomatis memasukkan IP penyerang ke dalam rantai iptables DROP dalam kurun waktu kurang dari 3 detik.
3. Hasil Akhir: Penggunaan CPU pada server asal yang sebelumnya mencapai 98% langsung turun stabil di kisaran 12%. Layanan e-commerce tetap dapat diakses secara normal oleh pelanggan sah tanpa mengalami gangguan latensi maupun downtime.

8. Common Pitfalls, Anti-Patterns & Solusi

Dalam mengimplementasikan keamanan tingkat lanjut ini, banyak administrator terjebak dalam beberapa kesalahan fatal berikut:

• Anti-Pattern 1: Mengaktifkan ModSecurity Rule Set Tingkat Maksimal Tanpa Tahap Audit Mode
  • Dampak: Ribuan aturan ketat akan memblokir request sah dari pengguna (false positive), seperti pengiriman formulir admin atau pembaruan API yang mengandung tag HTML yang sah.
  • Solusi: Selalu jalankan ModSecurity dalam mode deteksi saja (SecRuleEngine DetectionOnly) selama minimal 3 hingga 5 hari di lingkungan produksi. Analisis log audit (/var/log/modsec_audit.log) untuk menyesuaikan pengecualian (exclusion rules) sebelum mengaktifkannya secara penuh (SecRuleEngine On).
• Anti-Pattern 2: Mengabaikan Header X-Forwarded-For di Belakang Reverse Proxy / Cloudflare
  • Dampak: Semua request yang masuk ke Nginx akan terbaca berasal dari alamat IP internal CDN Cloudflare, bukan alamat IP asli pengguna. Akibatnya, aturan rate limiting dan Fail2ban akan memblokir IP Cloudflare dan melumpuhkan seluruh website.
  • Solusi: Gunakan modul resmi Nginx ngx_http_realip_module dan konfigurasikan rentang IP Cloudflare dengan benar:

    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;
    

• Anti-Pattern 3: Mengatur nofile (File Descriptor Limit) Terlalu Rendah di Tingkat Sistem Operasi
  • Dampak: Ketika ribuan koneksi masuk secara bersamaan, Nginx akan gagal membuka soket baru dan memunculkan error too many open files meskipun parameter sysctl jaringan sudah disetel tinggi.
  • Solusi: Tingkatkan batas maksimal file descriptor pada layanan systemd Nginx (/etc/systemd/system/nginx.service.d/override.conf):

    [Service]
    LimitNOFILE=65535
    

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian performa dan ketahanan server harus dilakukan secara berkala menggunakan perangkat uji beban modern seperti wrk atau k6. Jangan pernah melakukan uji beban menggunakan tool yang tidak memiliki izin tertulis dari pemilik infrastruktur.

Contoh perintah pengujian beban menggunakan wrk untuk mensimulasikan 500 koneksi paralel selama 30 detik pada server:

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

Interpretasi Metrik Keberhasilan Tuning:

• Requests/sec (RPS): Setelah hardening kernel dan Nginx, throughput RPS harus meningkat setidaknya 20-30% karena efisiensi pengelolaan memori buffer TCP dan penolakan dini (early drop) terhadap request tidak sah.
• Latency Distribution: Pastikan latensi persentil ke-99 (p99 latency) tetap berada di bawah 100ms di bawah beban puncak. Jika p99 melonjak drastis, periksa apakah antrean Worker Processes Nginx mengalami kekurangan proses atau bottleneck pada akses disk I/O.
• Error Rate: Proporsi status HTTP 429 dan 403 harus sesuai dengan rasio trafik anomali yang masuk, sementara status HTTP 2xx untuk pengguna sah harus tetap terjaga pada angka 99.9%.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum menyatakan infrastruktur web server Anda siap menghadapi ancaman serangan siber tingkat lanjut di lingkungan produksi, pastikan seluruh item dalam checklist berikut telah diverifikasi secara tuntas:

• Parameter kernel sysctl jaringan telah disunting dan diterapkan secara permanen via berkas /etc/sysctl.d/.
• Blokir SYN flood aktif dan mekanisme SYN Cookies berfungsi normal.
• Nginx dikonfigurasi dengan pembatasan rate limit (limit_req dan limit_conn) serta parameter timeout yang ketat untuk mencegah Slowloris.
• ModSecurity WAF telah dipasang, diuji dengan mode audit, dan diaktifkan dengan OWASP Core Rule Set terbaru.
• Layanan Fail2ban aktif dan memantau log sistem otentikasi SSH serta log akses Nginx secara real-time.
• Modul realip dikonfigurasi dengan benar apabila berada di belakang CDN pihak ketiga (Cloudflare/AWS CloudFront).
• Batas sistem File Descriptor (LimitNOFILE) pada layanan systemd Nginx telah ditingkatkan minimal ke angka 65535.
• Pengujian beban (load testing) dan simulasi serangan skala kecil berhasil diredam tanpa menyebabkan gangguan pada layanan backend aplikasi.

Dengan menerapkan seluruh kerangka arsitektur keamanan berlapis ini secara disiplin, infrastruktur server Linux dan Nginx Anda akan bertransformasi menjadi benteng pertahanan yang tangguh, resilien, dan siap menghadapi dinamika serangan siber modern yang kian destruktif.