Panduan Lengkap Firewall Ubuntu: UFW, Fail2Ban

VPS tanpa firewall itu kayak rumah tanpa pintu — siapapun bisa masuk kapan aja. Banyak admin pernah melihat VPS klien yang baru 3 hari online sudah terkena brute force SSH lebih dari 10.000 kali. Logs-nya penuh dengan failed login attempts dari IP China dan Russia. Untungnya mereka sudah memakai key-based auth, tapi tetap saja mengkhawatirkan. Artikel ini menjadi panduan lengkap untuk setup firewall di Ubuntu VPS production menggunakan UFW, Fail2Ban, dan rate limiting — semua yang dibutuhkan supaya server aman dan admin bisa tidur nyenyak.

Artikel ini membahas tiga layer pertahanan: UFW sebagai firewall utama, Fail2Ban sebagai brute force protection, dan nginx rate limiting sebagai application layer protection. Kombinasi ketiganya adalah pola standar yang dipakai di banyak server production dan didokumentasikan oleh berbagai penyedia cloud serta komunitas sysadmin.

Layer 1: UFW (Uncomplicated Firewall)

UFW adalah wrapper simpel untuk iptables yang membuat setup firewall jauh lebih mudah. Tidak perlu memahami syntax iptables yang rumit — UFW menangani semuanya dengan command yang intuitif.

Install UFW terlebih dahulu:

sudo apt update && sudo apt install ufw -y

Setup default policies — deny all incoming, allow all outgoing:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Sekarang allow ports yang dibutuhkan. Untuk web server, dibutuhkan SSH (22), HTTP (80), dan HTTPS (443):

sudo ufw allow 22/tcp comment "SSH"
sudo ufw allow 80/tcp comment "HTTP"
sudo ufw allow 443/tcp comment "HTTPS"

PENTING: Pastikan SSH di-allow SEBELUM enable UFW. Kalau tidak, server bisa terkunci dari VPS sendiri — kejadian yang pernah dialami banyak admin, dan biasanya baru bisa pulih lewat console access dari provider.

Enable UFW:

sudo ufw enable
sudo ufw status verbose

Output-nya seharusnya seperti ini:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere       # SSH
80/tcp                     ALLOW IN    Anywhere       # HTTP
443/tcp                    ALLOW IN    Anywhere       # HTTPS

Advanced UFW Rules untuk Production

Beyond basic ports, dibutuhkan rules yang lebih spesifik. Misalnya, restrict SSH hanya dari IP tertentu:

sudo ufw allow from 103.xxx.xxx.xxx to any port 22 proto tcp comment "Office SSH"

Allow PostgreSQL hanya dari localhost (untuk aplikasi yang jalan di server yang sama):

sudo ufw allow from 127.0.0.1 to any port 5432 proto tcp comment "Local PostgreSQL"

Untuk admin yang bekerja dari banyak lokasi, cara yang lebih elegan adalah masuk lewat VPN dan membatasi SSH hanya dari IP VPN — pola yang dibahas lebih detail di panduan WireGuard site-to-site VPN multi-region. Dengan begitu, port 22 bahkan tidak terlihat dari internet publik.

Dan block semua traffic dari suspicious countries. Banyak admin memblokir ranges dari negara yang tidak relevan dengan bisnis klien:

# Block specific ranges (contoh)
sudo ufw deny from 185.220.0.0/16 comment "Known bad range"

Rate limiting di level UFW juga bisa dilakukan untuk SSH protection tambahan:

sudo ufw limit 22/tcp comment "SSH rate limit"

Command limit akan block IP yang melakukan lebih dari 6 connection attempts dalam 30 detik. Ini defense layer pertama sebelum Fail2Ban.

Layer 2: Fail2Ban — Brute Force Protection

Fail2Ban memonitor log files dan mem-ban IP yang melakukan repeated failed login attempts. Ini sangat powerful karena bisa auto-block attacker tanpa intervensi manual.

Install Fail2Ban:

sudo apt install fail2ban -y

Buat custom configuration (jangan edit jail.conf langsung — itu akan ke-overwrite saat update):

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

Edit section [DEFAULT]:

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
banaction = ufw

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 86400

Penjelasan parameter: - bantime: Durasi ban dalam detik (86400 = 24 jam untuk SSH) - findtime: Window waktu untuk menghitung failed attempts - maxretry: Jumlah maksimal failed attempts sebelum ban - banaction: UFW integration — langsung block via firewall

Restart Fail2Ban dan cek statusnya:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Output yang diharapkan:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     47
|  +- File list:        /var/log/auth.log
+- Actions
   |- Currently banned: 5
   |- Total banned:     12
   +- Banned IP list:   103.21.124.13 45.33.44.100 185.220.101.4

Bagian Banned IP list adalah IP yang sedang diblokir aktif. Fail2Ban menulis entri ban ke UFW, sehingga IP tersebut ditolak di level firewall sebelum sempat menyentuh aplikasi. Untuk lapisan keamanan SSH yang lebih dalam — seperti menonaktifkan password login dan mengatur key-based auth — panduan hardening SSH server Ubuntu membahasnya secara lengkap.

Layer 3: Nginx Rate Limiting (Application Layer)

UFW dan Fail2Ban bekerja di level jaringan, tapi tidak bisa membedakan request yang sah dari bot yang menyamar sebagai user. Di sinilah nginx rate limiting masuk — membatasi jumlah request per klien di level aplikasi, sehingga endpoint login dan API tidak bisa dibanjiri.

Nginx menyediakan modul ngx_http_limit_req_module. Konsep dasarnya dua langkah: definisikan limit_req_zone di level http, lalu terapkan limit_req di location yang ingin dilindungi.

Definisikan zone di file konfigurasi nginx (misalnya /etc/nginx/nginx.conf di dalam blok http):

http {
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/s;

    server {
        ...
    }
}

Zone login_limit menyimpan state per IP (10 MB), dan membatasi rata-rata 5 request per detik. Selanjutnya terapkan di location login:

location /login {
    limit_req zone=login_limit burst=10 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

Parameter burst=10 mengizinkan lonjakan 10 request tambahan di atas rata-rata, dan nodelay membuat request burst diproses langsung tanpa antrian (queueing). Tanpa nodelay, request yang melewati burst akan ditunda — yang kadang terasa lambat bagi user sah. Request yang melampaui burst akan mendapat respons 503 Service Unavailable secara default.

Untuk endpoint yang lebih sensitif — seperti form login — banyak setup menggunakan rate yang lebih ketat (misal 1r/s atau 2r/s) dan memisahkan zone khusus. Kombinasi rate, burst, dan nodelay adalah tiga parameter inti yang wajib dipahami sebelum tuning.

Verifikasi dan Monitoring

Setelah ketiga layer aktif, verifikasi berkala sangat penting. Beberapa command yang berguna:

sudo ufw status numbered
sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo tail -f /var/log/fail2ban.log
sudo nginx -t && sudo systemctl reload nginx

Kebiasaan yang disarankan: cek fail2ban-client status sshd seminggu sekali untuk melihat pola serangan, dan pastikan tidak ada IP sendiri yang ke-ban secara tidak sengaja (false positive). Untuk visibilitas menyeluruh — termasuk metrik jaringan, CPU, dan disk pada server production — panduan monitoring server self-hosted dengan Netdata, Grafana, dan Prometheus bisa menjadi langkah lanjutan.

Sumber & Validasi

Artikel ini disusun berdasarkan dokumentasi resmi dan panduan yang diterbitkan penyedia cloud serta komunitas sysadmin:

• DigitalOcean — Hardening SSH: Fail2Ban, Nftables & Cloud Firewalls
• Hetzner Community — Securing SSH on Ubuntu with UFW and Fail2ban (diperbarui 2026-06-17)
• ComputingForGeeks — Harden Ubuntu 26.04 LTS Server (Security Guide)
• NGINX Docs — Module ngx_http_limit_req_module (dokumentasi resmi)
• getpagespeed — NGINX Rate Limiting: The Complete Guide (2026, direvisi Juli 2026)

Catatan validasi: nilai default ufw limit (6 koneksi per 30 detik) dan parameter rate/burst/nodelay mengikuti dokumentasi resmi UFW dan NGINX. Angka ban di contoh output Fail2Ban bersifat ilustratif. Angka serangan brute force (misal "10.000 attempts dalam 3 hari") adalah contoh ilustratif dari observasi umum admin, bukan statistik resmi — besaran aktual sangat bervariasi tergantung eksposur IP dan lokasi server. Disarankan menguji konfigurasi di staging sebelum diterapkan ke production, dan selalu memastikan akses console/out-of-band tersedia sebelum mengaktifkan firewall.

Rekomendasi VPS: RackNerd (Disclosure Afiliasi)

Kalau lo butuh VPS murah untuk production atau side-project, RackNerd (link affiliate) adalah salah satu penyedia VPS murah yang banyak dipakai developer untuk side-project. Harga mulai $10.31/tahun (~Rp 155.000) untuk 1GB RAM, NVMe SSD, 1TB bandwidth — promo RackNerd fluktuatif, cek halaman order untuk harga terkini.

Disclosure: Link di atas afiliasi — kalau lo order lewat situ, gue dapet komisi kecil tanpa nambah harga lo. Gak ada perubahan ranking atau rekomendasi berdasarkan afiliasi; perbandingan head-to-head sama IDCloudHost, VPS lokal, dan Hostinger ada di artikel dedicated dengan data terverifikasi.