UFW diciptakan agar firewall bisa disetel dalam tiga perintah, dan dalam hal itu ia berhasil. Masalahnya di tempat lain: ufw status menampilkan niat, bukan hasil. Sebuah aturan bisa ada dalam daftar dan sama sekali tidak menutup apa pun — karena tiga sebab yang berbeda, dan ketiganya rutin dijumpai pada server sungguhan.

Permulaan yang tidak mengunci Anda di luar

Urutan perintahnya penting. Izinkan SSH lebih dulu, baru nyalakan:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

ufw enable sebelum mengizinkan SSH akan memutus sesi Anda sendiri, dan sesudah itu tinggal konsol penyedia. Kalau server sudah tersetel dan Anda tidak yakin, biarkan koneksi kedua terbuka — ia bertahan melewati suntingan yang gagal.

Lihatlah status yang rinci; yang ringkas menyembunyikan kebijakan bawaan:

sudo ufw status verbose

Kesalahan pertama: aturannya ada dan portnya terbuka untuk dunia

Baris paling umum di konfigurasi orang lain:

sudo ufw allow 3306

Begitulah MySQL dibuka «supaya bisa terhubung dari rumah» — dan terbuka untuk seluruh internet. Ada dua varian yang benar, dan keduanya lebih baik:

sudo ufw allow from 203.0.113.25 to any port 3306

atau, yang lebih andal, jangan biarkan layanannya keluar sama sekali: bind-address = 127.0.0.1 di konfigurasi MySQL, dan akses dari luar lewat terowongan SSH. Firewall adalah garis kedua; garis pertama adalah layanan yang tidak mendengarkan di alamat publik. Aturan di UFW bisa terhapus tanpa sengaja, sementara bind-address tidak berubah dengan sendirinya.

Kesalahan kedua: IPv6

Aturan semacam ufw allow from 203.0.113.25 hanya berlaku untuk IPv4. Kalau server punya alamat IPv6 — dan kebanyakan VPS punya dan aktif — layanannya tetap terjangkau melaluinya. Penyedia memberikan alamat, Anda tidak mengingatnya, tetapi pemindai mengingatnya.

Periksa apakah penyaringan v6 aktif sama sekali (IPV6=yes di /etc/default/ufw) dan apakah layanan mendengarkan di :: tanpa perlu:

ss -tulpn | grep ':::'

Aturan yang menyebut alamat secara eksplisit harus ditulis terpisah untuk tiap versi protokol.

Kesalahan ketiga: Docker

Yang paling menjengkelkan. Docker menerbitkan port dengan menambahkan aturannya sendiri ke rantai iptables sebelum aturan yang ditulis UFW. Akibatnya sebuah kontainer yang dijalankan dengan -p 5432:5432 terjangkau dari internet meski UFW melaporkan Status: active dan kebijakan deny incoming. Firewall tidak rusak — ia sekadar tidak pernah mendapat giliran.

Obatnya bukan di UFW melainkan pada cara port diterbitkan:

ports:
  - "127.0.0.1:5432:5432"

Mengikat ke alamat lokal adalah solusi paling sederhana dan paling andal. Yang menghadap ke luar hanyalah yang benar-benar melayani pengunjung: biasanya port 80 dan 443 dari sebuah reverse proxy.

Urutan aturan

UFW menerapkan aturan pertama yang cocok lalu berhenti di situ. Jadi larangan yang ditambahkan setelah izin tidak akan bekerja: gilirannya tidak pernah tiba. Lihat penomorannya dan sisipkan di tempat yang perlu:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 7

Aturan dihapus menurut nomor, tetapi nomornya bergeser setelah setiap penghapusan — hapus satu per satu dan baca ulang daftarnya.

Pemeriksaan dari luar

Perintah lokal menunjukkan apa yang disetel. Hasil sebenarnya hanya terlihat dari mesin lain:

nmap -Pn -p- 203.0.113.25
nc -zv 203.0.113.25 3306

Server lain mana pun atau komputer rumah Anda bisa dipakai. Inilah satu-satunya pemeriksaan yang tidak berbohong, dan layak dijalankan setelah setiap penyetelan ulang yang berarti — terutama setelah memasang sesuatu yang «menyetel jaringannya sendiri»: Docker, panel kendali, VPN.

Log

Secara bawaan UFW hampir tidak menulis apa-apa. Nyalakan dengan:

sudo ufw logging low

Catatannya masuk ke /var/log/ufw.log — tetapi hanya kalau di sistem ada rsyslog. Di Debian 12 dan Ubuntu 24.04 mungkin tidak ada, dan saat itu semuanya masuk ke jurnal systemd:

sudo journalctl -k | grep -i '\[UFW'

/var/log/ufw.log yang kosong dengan sendirinya tidak berarti apa-apa — lihatlah dulu di jurnal.

Apa yang boleh diharapkan dari firewall

UFW menutup apa yang seharusnya tidak terjangkau. Ia tidak memeriksa isi permintaan menuju apa yang terbuka: port 443 terbuka untuk semua orang, dan apa pun yang tiba di situs tiba tanpa halangan. Itu pekerjaan perkakas lain — WAF di tingkat aplikasi, IDS di tingkat lalu lintas. Tugas firewall lebih sederhana dan lebih penting: agar daftar port terbuka cocok dengan apa yang Anda yakini tentangnya. Bagaimana daftar itu bersama aturan aktif tampak pada satu halaman — lihat di demo bawah.