Hardening Nginx untuk Server Produksi

Hardening Nginx adalah proses mengubah konfigurasi bawaan menjadi konfigurasi yang hanya melayani apa yang perlu, memberi informasi sesedikit mungkin, dan tahan terhadap request yang aneh. Konfigurasi bawaan dirancang agar mudah jalan, bukan agar aman di internet terbuka.

Risikonya konkret. Satu file .env yang bisa diunduh membuka password database dan API key. Satu .git yang terbuka memungkinkan orang merekonstruksi kode sumbermu. Timeout yang terlalu longgar membuat server mudah kehabisan koneksi oleh klien yang sengaja lambat. Semua itu bisa dicegah dengan beberapa baris konfigurasi.

Lapisan yang perlu diperkuat

Sembunyikan informasi versi

Secara bawaan, Nginx menampilkan nomor versinya di header Server dan di halaman error. Informasi ini memudahkan penyerang mencocokkan server dengan celah yang diketahui. Matikan dengan server_tokens off; di blok http. Ini tidak menggantikan update rutin, tapi mengurangi informasi gratis.

TLS yang modern

Batasi protokol ke TLS 1.2 dan TLS 1.3. TLS 1.0 dan 1.1 sudah dinyatakan usang oleh IETF lewat RFC 8996 dan tidak dibutuhkan browser modern. Nginx versi baru sudah memakai TLSv1.2 TLSv1.3 sebagai nilai bawaan, tapi menuliskannya eksplisit tetap berguna di server yang versinya beragam. Untuk daftar cipher, ikuti generator konfigurasi Mozilla (profil intermediate cocok untuk kebanyakan website bisnis) daripada menyusun sendiri. Aktifkan juga HSTS setelah HTTPS stabil; header ini dan header keamanan lainnya dibahas di security headers.

Tolak host yang tidak dikenal

Bot sering mengakses server langsung lewat alamat IP atau nama domain acak. Buat blok default_server yang menolak request seperti itu, supaya hanya domain yang kamu daftarkan yang dilayani. Untuk HTTPS, direktif ssl_reject_handshake on; (tersedia sejak Nginx 1.19.4) menolak handshake tanpa perlu sertifikat palsu.

Batasi metode HTTP

Website biasa hanya butuh GET, HEAD, dan POST. Metode lain seperti TRACE, PUT, atau DELETE tidak perlu diterima di level web server kecuali aplikasimu memang memakainya, misalnya API REST.

Blokir file tersembunyi dan file sensitif

File dan folder yang diawali titik, seperti .env, .git, .htpasswd, dan .DS_Store, tidak boleh bisa diakses dari luar. Kecualikan .well-known, karena folder itu dipakai validasi sertifikat SSL. Blokir juga ekstensi cadangan seperti .bak, .sql, dan .old yang sering tertinggal setelah migrasi.

Timeout, buffer, dan batas ukuran

Timeout yang pendek untuk header dan body request membatasi dampak klien yang sengaja mengirim data sangat lambat. client_max_body_size membatasi ukuran unggahan; sesuaikan dengan kebutuhan nyata, misalnya ukuran file terbesar yang boleh diunggah pengguna. large_client_header_buffers membatasi header yang berlebihan.

Rate limit di titik rawan

Halaman login, reset password, dan endpoint API publik adalah sasaran brute force. Modul limit_req membatasi jumlah request per alamat IP dalam rentang waktu tertentu. Terapkan di lokasi rawan saja, bukan di seluruh website, agar pengunjung biasa tidak terganggu. Untuk serangan volume besar, rate limit di Nginx tidak cukup; perlindungannya dibahas di anti DDoS untuk VPS.

Log yang berguna

Simpan access log dan error log, pastikan rotasi log aktif agar disk tidak penuh, dan tinjau secara berkala. Log adalah bukti pertama saat terjadi insiden.

Contoh konfigurasi

Contoh berikut bisa kamu sesuaikan. Ganti nama domain, path sertifikat, dan alamat upstream aplikasi.

# di dalam blok http
server_tokens off;
client_header_timeout 10s;
client_body_timeout 10s;
send_timeout 10s;
keepalive_timeout 30s;
client_max_body_size 10m;
large_client_header_buffers 4 8k;
limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;

# tolak host tak dikenal
server {
    listen 80 default_server;
    listen 443 ssl default_server;
    ssl_reject_handshake on;
    return 444;
}

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

server {
    listen 443 ssl;
    http2 on;
    server_name domainmu.com;

    ssl_certificate     /etc/ssl/domainmu/fullchain.pem;
    ssl_certificate_key /etc/ssl/domainmu/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_tickets off;

    if ($request_method !~ ^(GET|HEAD|POST)$) {
        return 405;
    }

    location ~ /\.(?!well-known) {
        deny all;
    }

    location ~* \.(bak|old|sql|swp|log)$ {
        deny all;
    }

    location = /login {
        limit_req zone=login burst=5 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
    }

    access_log /var/log/nginx/domainmu.access.log;
    error_log  /var/log/nginx/domainmu.error.log warn;
}

Direktif http2 on; berlaku untuk Nginx 1.25.1 ke atas. Untuk versi lebih lama, tulis listen 443 ssl http2;. Selalu jalankan nginx -t sebelum systemctl reload nginx.

Perbandingan bawaan dan setelah hardening

Kapan cukup dengan Nginx, kapan perlu lapisan lain?

Hardening Nginx sudah cukup sebagai pondasi untuk website profil, blog, dan aplikasi internal dengan lalu lintas wajar. Kombinasikan dengan firewall server yang hanya membuka port 80, 443, dan SSH, serta update sistem rutin. Dasar pengamanan servernya ada di cara mengamankan VPS baru.

Lapisan tambahan seperti WAF atau CDN masuk akal ketika website memproses transaksi, sering menjadi sasaran bot, atau pernah diserang. WAF memeriksa isi request, misalnya pola SQL injection, yang tidak dilakukan konfigurasi Nginx biasa. Kalau kamu masih menimbang web server mana yang dipakai, perbandingannya ada di Nginx vs Apache vs LiteSpeed.

Konfigurasi ini juga butuh pemilik. Tentukan siapa yang memasang update Nginx, membaca error log, dan meninjau ulang direktif secara berkala, entah staf internal atau pihak luar yang kamu tunjuk.