Belajar UFW - Rule Ordering & Best Practice

#Pendahuluan

Sepanjang series ini kita menyebut "urutan aturan itu penting" berkali-kali. Episode 17 menuntaskan janji itu: rule ordering — bagaimana netfilter mengevaluasi aturan, bagaimana UFW membangun urutannya, dan bagaimana kalian memanfaatkannya. Setelah itu, kita rangkum best practice yang menjadikan kalian admin yang bukan sekadar bisa, tapi andal.

Mengapa episode ini penting? Karena sebagian besar bug firewall — port kebuka padahal sudah deny, deny yang tidak pernah bekerja, konflik aturan yang membingungkan — berakar pada kesalahpahaman tentang urutan. Best practice, di sisi lain, adalah apa yang membedakan konfigurasi yang bisa dirawat dari konfigurasi yang menunggu waktu untuk meledak.

#Bagaimana Netfilter Mengevaluasi Aturan

Netfilter mengevaluasi paket secara berurutan, aturan pertama yang cocok menang. Kalian sudah melihatnya di episode 2 dan 13. Konsekuensi praktisnya:

• Aturan yang lebih spesifik (deny IP tertentu) harus diletakkan lebih awal daripada aturan yang lebih umum (allow port) jika ingin menang.
• Aturan yang tidak pernah "dijangkau" adalah aturan mati — ia ada tapi tidak berpengaruh.

Contoh aturan mati:

sudo ufw allow from 10.0.0.0/8 to any port 22 proto tcp
sudo ufw deny from 10.0.0.5 to any port 22 proto tcp

Karena allow 10.0.0.0/8 dievaluasi lebih dulu (ditambahkan lebih awal), IP 10.0.0.5 — yang ada di dalam subnet — tetap lolos; aturan deny tidak pernah dipertimbangkan. Ini contoh nyata mengapa urutan adalah logika, bukan detail.

#Urutan Lengkap yang Dikenal UFW

Urutan evaluasi global dari episode 2 dan 11:

1. before.rules (system)      — loopback, invalid, established, ICMP
2. user.rules (rules kalian)  — dari ufw allow/deny/limit, diurutkan
   sesuai posisinya
3. after.rules (penutup)      — logging deny, aturan terakhir
4. default policies           — jaring pengaman terakhir

Di dalam blok user.rules, urutan mengikuti posisi — yang ditambahkan lebih awal di baris lebih atas. ufw insert (episode 6) mengubah posisi ini.

#Audit Ruleset dengan ufw status numbered

Audit adalah pemeriksaan berkala atas kesehatan ruleset. Alat utamanya ufw status numbered:

sudo ufw status numbered

Status: active
 
     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 10.0.0.5 22/tcp            DENY IN     10.0.0.5
[ 3] 80/tcp                     ALLOW IN    Anywhere
[ 4] 443/tcp                    ALLOW IN    Anywhere
[ 5] 8080/tcp                   ALLOW IN    Anywhere
[ 6] 22/tcp (v6)                ALLOW IN    Anywhere (v6)

Saat audit, tanyakan:

1. Apakah urutannya logis? — deny yang seharusnya menang harus di atas allow yang menaunginya. Pada contoh di atas, aturan [2] deny 10.0.0.5 mati karena [1] allow 22/tcp Anywhere lebih dulu cocok.
2. Apakah semua port masih dibutuhkan? — [5] 8080 harusnya tidak terbuka (episode 15). Bandingkan dengan ss -tlnp.
3. Apakah ada aturan ganda/tumpang tindih? — dua aturan yang menutupi hal yang sama membingungkan.

Perbaiki urutan dengan ufw delete + ufw insert (episode 6 dan 8):

sudo ufw delete 2
sudo ufw insert 1 deny from 10.0.0.5 to any port 22 proto tcp

Sekarang deny dievaluasi pertama — 10.0.0.5 benar-benar ditolak.

#Best Practice UFW di Produksi

#1. Least Privilege

Buka seminimal mungkin, se-spesifik mungkin:

• Publik → 80/tcp, 443/tcp saja.
• Internal → subnet/IP spesifik.
• Default → DROP (episode 9).

Setiap aturan harus bisa dijawab: "siapa yang butuh ini, dan kenapa?" Jika tidak ada jawabannya, hapus aturannya.

#2. Logging Aktif dengan Level yang Tepat

ufw logging on (level low) untuk produksi — catat yang ditolak, tanpa membanjiri disk (episode 12). Log adalah bahan bakar monitoring dan forensik.

#3. Dokumentasi Setiap Perubahan

Setiap perubahan ruleset harus terdokumentasi. Kebiasaan sederhana yang luar biasa efeknya:

date >> ~/ufw-lab/CHANGELOG.md
echo "- Buka 8080/tcp untuk staging (tiket #123)" >> ~/ufw-lab/CHANGELOG.md

Saat audit, CHANGELOG.md ini menjelaskan mengapa sebuah aturan ada — sesuatu yang tidak bisa dijawab oleh ufw status mana pun.

#4. Audit Berkala

Jadwalkan audit ruleset secara rutin (mingguan/bulanan):

sudo ufw status numbered
sudo ufw show added
sudo ss -tlnp

Bandingkan tiga output: aturan aktif vs perintah asli vs layanan yang benar-benar berjalan. Ketidakcocokan = pekerjaan menunggu.

#5. Perubahan Bertahap + Verifikasi

Ubah aturan satu per satu, verifikasi dampaknya (episode 16), baru lanjut. Jangan menulis 10 aturan sekaligus lalu "berharap" semuanya benar.

#Common Pitfalls

1. Aturan mati karena urutan: deny di bawah allow yang lebih luas = deny tidak berfungsi. Audit dengan status numbered.
2. Aturan redundant menumpuk: beberapa allow untuk layanan yang sama. Sederhanakan.
3. Dokumentasi diabaikan: aturan misterius yang "sudah ada sejak dulu" tidak bisa diaudit. Catat setiap perubahan.
4. Audit tanpa aksi: audit yang tidak menghasilkan keputusan (bersihkan / pertahankan) hanya buang waktu. Buat catatan aksi di CHANGELOG.

#Penutup

Pada episode 17 ini, kalian telah menguasai rule ordering dan best practice.

Inti yang harus dibawa pulang:

• Aturan pertama yang cocok menang — spesifik dulu, umum belakangan; deny yang ingin menang diletakkan paling atas.
• Urutan global: before → user → after → default policy.
• ufw status numbered adalah alat audit utama; bandingkan dengan ss -tlnp dan ufw show added.
• Best practice: least privilege, logging aktif, dokumentasi perubahan, audit berkala, perubahan bertahap.

Di episode 18 selanjutnya, kita memasuki mode dokter: Troubleshooting Koneksi & Rules — mendiagnosis dengan ufw status verbose, iptables -L -n -v, ss -tlnp, dan tcpdump, plus memecahkan kasus klasik: terkunci SSH, port tidak kebuka, dan konflik IPv6. Sampai jumpa di episode 18!