Belajar UFW - UFW di Server Produksi & VPS

#Pendahuluan

Setelah 15 episode teori dan praktik, episode 16 membawa kalian ke medan yang sesungguhnya: server produksi dan VPS. Ini bukan lagi lab — kesalahan di sini berarti downtime, kebocoran data, atau server yang terkunci di tengah malam.

Mengapa episode ini penting? Karena server produksi punya tiga lapis realitas yang jarang dibahas: (1) firewall cloud provider yang sering kalian lupakan, (2) firewall OS (UFW) yang kita pelajari, dan (3) kebiasaan operasional seperti verifikasi sebelum enable. Ketiganya harus bekerja sama — dan kesalahpahaman tentang pembagian tugasnya adalah sumber bug yang klasik.

#Dua Lapis Firewall di VPS

Sebagian besar VPS modern (DigitalOcean, AWS, Hetzner) menawarkan firewall terkelola di level provider. Kalian kini punya dua lapis:

100%

Lapis	Contoh	Dikelola Di	Karakter
Cloud provider	Security Group, Cloud Firewall	Panel/API provider	Berjalan sebelum traffic sampai ke OS
OS firewall	UFW	Server	Berjalan di dalam OS

Praktik yang sehat: aktifkan keduanya dengan aturan yang sama. Cloud firewall melindungi sebelum traffic masuk (murah, terpusat), UFW melindungi di dalam OS (berlaku juga untuk traffic yang datang lewat jalur lain, seperti VPN internal atau jaringan privat).

Note

Kesalahan klasik: mengaktifkan firewall provider lalu lupa firewall OS — dan sebaliknya. Server yang hanya dilindungi firewall provider terbuka terhadap traffic dari jaringan internal provider (misalnya sesama VPS di akun yang sama). Server yang hanya dilindungi UFW terbuka lebar sebelum traffic mencapai OS. Keduanya harus menyala.

#Baseline Rules untuk VPS

Prinsip baseline: buka hanya SSH + port layanan, tutup sisanya. Contoh VPS yang menjalankan web server:

Baseline rules VPS

# SSH — amankan dulu, batasi ke IP yang memang perlu
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
 
# Layanan publik
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
 
# Aktifkan
sudo ufw enable

Jika kalian mengelola server dari banyak lokasi dan subnet kantor tidak tetap, opsi yang lebih fleksibel — tetap dengan limit:

Alternatif SSH dengan rate limit

sudo ufw limit 22/tcp

Ingat aturan emas episode 3: SSH dulu, baru enable — atau pakai prosedur aman di bawah.

#Prosedur Verifikasi Aman Sebelum Enable

Enable UFW di VPS jarak jauh selalu berisiko. Prosedur standar yang menyelamatkan banyak admin:

#Langkah 1: Simpan Sesi SSH Cadangan

Buka dua sesi SSH sebelum enable — satu sebagai "jaring pengaman". Jika satu sesi putus, sesi lain masih bisa menyelamatkan.

#Langkah 2: Verifikasi Aturan SSH Ada

Pastikan SSH ada di ruleset

sudo ufw status verbose

Pastikan port SSH kalian muncul dengan action ALLOW atau LIMIT. Jika tidak muncul — berhenti. Perbaiki dulu.

#Langkah 3: Enable dengan Batas Waktu

Jalankan enable dengan timer darurat. Jika terjadi kesalahan, timer akan mematikan firewall kembali:

Enable dengan jaring pengaman waktu

sudo ufw enable
sleep 60
sudo ufw status | grep -q "Status: active" && echo "OK aktif" || echo "Tidak aktif!"

Ide lengkapnya: jalankan ufw enable, lalu dalam 60 detik uji koneksi dari sesi lain. Jika koneksi putus, segera sudo ufw disable dari sesi cadangan sebelum benar-benar terkunci.

#Langkah 4: Buktikan dari Luar

Dari mesin testing, verifikasi layanan:

Verifikasi dari mesin lain

ssh user@203.0.113.5
curl -I http://203.0.113.5

Warning

Jika kalian benar-benar terkunci dan sesi cadangan pun putus, jalan keluar terakhir adalah console VPS provider (misalnya DigitalOcean Console, AWS EC2 Serial Console) atau recovery mode. Dari sana jalankan sudo ufw disable atau sudo iptables -P INPUT ACCEPT. Ini sebabnya membuka panel provider sebelum bermain firewall jarak jauh adalah kebiasaan yang bijak.

#UFW di Ubuntu 24.04 dan 26.04 LTS

Kedua rilis LTS terbaru memakai backend nftables (iptables-nft). Perbedaan praktis dengan sistem lama:

Perintah UFW sama persis — kompatibilitas tetap terjaga.
Backend nft bisa dilihat di ufw status verbose (baris Status: ... (nft) atau via ufw show raw).
Service ufw.service menangani load saat boot; pastikan enabled:

Pastikan service aktif di LTS baru

sudo systemctl enable --now ufw
systemctl is-enabled ufw

Output enabled memastikan firewall menyala ulang setelah reboot — kegagalan di sini adalah sumber masalah "server kembali terbuka setelah restart".

#Konfigurasi Khusus Ubuntu 26.04

Pada Ubuntu 26.04, pastikan memakai kebiasaan episode 3-4 yang konsisten: verifikasi backend, izinkan SSH, lalu enable. Tidak ada perintah khusus UFW baru di 26.04 — perubahannya sebagian besar di layer netfilter di belakang layar.

#Checklist Sebelum Produksi

SSH (atau port admin) diizinkan dan bisa diakses dari lokasi kalian.
Semua port layanan yang diperlukan sudah allow, sisanya default DROP.
Firewall provider dan UFW aktif dengan aturan yang sama.
Logging aktif (ufw logging on) untuk observabilitas episode 12.
Service ufw enabled saat boot.
Ruleset didokumentasikan di ~/ufw-lab/NOTES.md (atau repo, episode 20-21).
Sesi SSH cadangan siap sebelum enable.

#Common Pitfalls

Hanya mengandalkan firewall provider: traffic jaringan internal provider menembus. UFW harus aktif juga.
Enable tanpa verifikasi SSH ada di ruleset: resep terkunci yang paling klasik.
Service ufw tidak enabled: firewall mati setelah reboot.
Ruleset tidak terdokumentasi: sulit audit dan sulit mereplikasi ke server lain (episode 20-21).

#Penutup

Pada episode 16 ini, kalian telah menempatkan UFW dalam konteks produksi.

Inti yang harus dibawa pulang:

VPS punya dua lapis firewall (provider + OS); keduanya harus aktif dengan aturan konsisten.
Baseline produksi: SSH + port layanan saja; sisanya DROP.
Gunakan prosedur enable aman: sesi cadangan, verifikasi aturan, timer darurat, uji dari luar.
Backend modern nftables dipakai di Ubuntu 24.04/26.04 LTS; perintah UFW tetap sama.
Pastikan ufw.service enabled dan logging aktif.

Di episode 17 selanjutnya, kita menyelami detail yang menentukan perilaku firewall: Rule Ordering & Best Practice — urutan evaluasi before-user-after, audit dengan ufw status numbered, prinsip least privilege, dan kebiasaan dokumentasi perubahan ruleset. Sampai jumpa di episode 17!