Belajar UFW - Firewall untuk Docker, KVM & Tools Lain

#Pendahuluan

Episode 13 mengajarkan kalian meneruskan lalu lintas ke mesin di belakang host. Episode 14 menghadapi kenyataan yang lebih rumit: aplikasi yang menulis aturan netfilter sendiri, terutama Docker dan KVM/libvirt. Inilah sumber kebingungan terbesar bagi admin UFW — kalian menulis ufw deny 8080, tapi port itu tetap kebuka.

Mengapa ini penting? Karena Docker dan KVM adalah staples infrastruktur modern. Tanpa memahami bagaimana mereka berinteraksi dengan UFW, kalian akan percaya firewall aktif padahal ada jalur terbuka yang kalian tidak sadari — atau sebaliknya, memblokir layanan yang seharusnya berjalan.

#Konflik Dasar: Docker Mengelola iptables Sendiri

Docker (mode default) menulis aturan iptables secara langsung saat container dijalankan — tanpa lewat UFW. Konsekuensinya:

• Port yang dipublish (docker run -p 8080:80) terbuka di semua interface.
• Aturan UFW tidak memblokirnya — karena aturan Docker masuk ke chain DOCKER yang dievaluasi sebelum chain UFW.
• ufw status bahkan tidak menampilkan port-container itu.

Contoh: kalian menjalankan container dengan -p 8080:80, lalu menulis ufw deny 8080/tcp. Hasilnya? Port 8080 tetap terbuka dari luar.

Karena evaluasi netfilter berurutan, chain DOCKER menang sebelum aturan UFW sempat menolak.

#Solusi 1: Menghentikan Manipulasi iptables oleh Docker

Matikan pengelolaan iptables Docker agar semua port fallback ke aturan UFW:

{
  "iptables": false
}

Restart Docker:

sudo systemctl restart docker

Setelah ini, port yang dipublish tidak lagi otomatis terbuka di host — kalian harus membukanya secara eksplisit dengan UFW, dan memastikan IP forwarding (episode 13) tetap berfungsi untuk container. Trade-off-nya: networking Docker default (bridge) akan lebih terbatas dan butuh penyesuaian (misalnya aturan UFW untuk interface docker0).

#Solusi 2: Chain DOCKER-USER

Cara yang lebih modern dan direkomendasikan: Docker menyediakan chain DOCKER-USER yang dievaluasi sebelum chain DOCKER. Aturan deny yang kalian taruh di sana akan menang atas -p Docker:

sudo iptables -I DOCKER-USER -s 203.0.113.66 -j DROP
sudo iptables -I DOCKER-USER -s 203.0.113.0/24 -j DROP

Verifikasi:

sudo iptables -L DOCKER-USER -n -v

Chain DOCKER-USER (1 references)
target     prot opt source               destination
DROP       all  --  203.0.113.66         0.0.0.0/0
DROP       all  --  203.0.113.0/24       0.0.0.0/0
RETURN     all  --  0.0.0.0/0             0.0.0.0/0

Aturan RETURN di akhir adalah bawaan Docker — jangan dihapus. Karena DOCKER-USER dievaluasi lebih awal, semua sumber yang kalian blokir tidak akan pernah mencapai container, apa pun -p yang dipublish.

#UFW + KVM/libvirt

KVM/libvirt menciptakan bridge virbr0 — jaringan virtual yang menghubungkan VM. Aturannya berbeda dari Docker:

• Mode NAT default: VM di belakang virbr0 sudah terisolasi dari internet masuk; port tidak otomatis diekspos.
• Mode bridged: VM berbagi interface fisik dengan host — aturan UFW berlaku langsung untuk VM.

#Praktik untuk Mode Bridged

Aturan UFW yang kalian buat pada interface fisik otomatis melindungi VM bridged. Yang perlu diperhatikan: jangan blokir traffic internal bridge:

sudo ufw allow in on virbr0
sudo ufw allow out on virbr0

Sementara itu, untuk port forwarding ke VM (mode NAT), pakai teknik episode 13 — DNAT ke IP VM di jaringan virbr0:

-A PREROUTING -i eth0 -p tcp --dport 9443 -j DNAT --to-destination 192.168.122.50:443

#sslh dan Fail2ban dalam Tumpukan

#sslh: Satu Port untuk Banyak Protokol

sslh adalah protocol demultiplexer: ia mendengarkan satu port (misalnya 443) dan meneruskan koneksi ke layanan yang tepat berdasarkan protokol — SSH ke port 22, HTTPS ke nginx, OpenVPN ke port 1194. Manfaatnya: kalian hanya membuka satu port di firewall, menyamarkan layanan lain.

Integrasi dengan UFW sederhana — buka hanya port yang dipakai sslh:

sudo ufw allow 443/tcp

Layanan di belakangnya (SSH 22, HTTPS internal) tidak perlu dibuka karena hanya sslh yang terpapar.

#Fail2ban + DOCKER-USER

fail2ban (episode 10) memban IP dengan menambahkan aturan UFW. Sayangnya, aturan UFW tidak memengaruhi chain DOCKER. Solusinya: gunakan action ban khusus yang menulis ke DOCKER-USER:

[Definition]
actionban = iptables -I DOCKER-USER -s <ip> -j DROP
actionunban = iptables -D DOCKER-USER -s <ip> -j DROP

Dengan action ini, fail2ban bisa memban IP penyerang bahkan ketika targetnya container Docker.

#Common Pitfalls

1. Percaya ufw status saat memakai Docker: aturan Docker tidak tampil di sana. Audit dengan iptables -L -n untuk gambaran penuh.
2. "iptables": false tanpa memahami networking: bisa memutus networking antar container. Pahami dulu, atau pakai DOCKER-USER.
3. Menghapus baris RETURN di DOCKER-USER: RETURN wajib ada — tanpanya, aturan di bawahnya (termasuk chain DOCKER) tidak akan pernah dieksekusi.
4. Memblokir traffic virbr0: bisa memutus komunikasi VM-ke-host. Izinkan bridge internal secara eksplisit.

#Penutup

Pada episode 14 ini, kalian telah menguasai integrasi UFW dengan tool lain.

Inti yang harus dibawa pulang:

• Docker menulis aturan iptables sendiri; aturan UFW tidak memblokirnya secara otomatis.
• Dua solusi: "iptables": false di daemon.json (kontrol penuh UFW) atau blokir di chain DOCKER-USER (direkomendasikan).
• KVM/libvirt: mode NAT butuh DNAT (episode 13); mode bridged langsung dilindungi aturan UFW; izinkan virbr0.
• sslh memusatkan banyak protokol ke satu port — buka hanya port itu di UFW.
• fail2ban butuh action khusus DOCKER-USER agar ban-nya menjangkau container.

Di episode 15 selanjutnya, kita terapkan semua pengetahuan ke dua workload paling umum: Skenario Keamanan Umum (Web & Mail Server) — membuka 80/443 dengan benar, hardening port mail 25/587/993/465, dan hardening port scan untuk mencegah eksploitasi origin. Sampai jumpa di episode 15!