Belajar Iptables - Ruleset Production & Best Practice

#Pendahuluan

Hingga episode 16, kalian sudah punya semua bahan baku: aturan yang benar, proteksi anti-scan, logging yang sehat. Episode 17 mengubah fokus dari apa yang benar menjadi bagaimana menyusunnya dengan benar — karena ruleset produksi yang baik bukan sekadar kumpulan aturan yang berfungsi, tapi sistem yang mudah dipahami, mudah diaudit, dan mudah diubah bertahun-tahun kemudian.

Ruleset produksi yang baik punya tiga sifat: default-deny, terorganisasi, dan terversi. Tiga sifat ini yang membedakan firewall profesional dari tumpukan -A yang menumpuk asal-asalan.

#Prinsip 1: Default-Deny dengan Allowlist

Filosofi inti: segala sesuatu ditutup kecuali yang eksplisit dibuka. Policy default DROP adalah dasarnya:

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

Allowlist layanan dibangun dengan menulis aturan ACCEPT yang eksplisit dan spesifik — semakin sedikit alasan menerima, semakin kecil permukaan serangan:

# Hanya dari subnet office untuk SSH
sudo iptables -A INPUT -p tcp --dport 22 -s 10.20.0.0/16 -j ACCEPT
# Web untuk semua, tapi via chain khusus
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Aturan praktis: jika sebuah layanan bisa dibatasi sumbernya, batasi. SSH dari subnet office saja jauh lebih aman daripada SSH untuk semua orang.

#Prinsip 2: Chain User-Defined yang Rapi

Tumpukan 50 aturan di satu chain INPUT adalah mimpi buruk audit. Pecah menjadi chain tematik:

sudo iptables -N SSH_PROTECT
sudo iptables -N WEB_PORTS
sudo iptables -N GUEST_LAN

Isi setiap chain dengan aturan spesifik:

sudo iptables -A SSH_PROTECT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name SSH
sudo iptables -A SSH_PROTECT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --name SSH --seconds 60 --hitcount 4 -j REJECT
sudo iptables -A SSH_PROTECT -p tcp --dport 22 -s 10.20.0.0/16 -j ACCEPT
sudo iptables -A SSH_PROTECT -p tcp --dport 22 -j DROP

Lalu panggil dari chain utama — satu baris, tujuan jelas:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j SSH_PROTECT
sudo iptables -A INPUT -p tcp --dport 80 -j WEB_PORTS

Sekarang membaca iptables -L INPUT langsung menunjukkan "apa yang terjadi" tanpa harus mencerna puluhan baris teknis. Aturan yang tidak cocok di chain SSH_PROTECT akan RETURN — jadi pastikan tiap chain berakhir dengan -j DROP atau -j RETURN yang eksplisit.

#Prinsip 3: Dokumentasi dengan Modul Comment

Aturan yang tidak terdokumentasi adalah teka-teki bagi orang yang menanganinya di tahun berikutnya — termasuk kalian sendiri. Modul comment menempelkan catatan ke aturan:

sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT -m comment --comment "HTTPS publik"
sudo iptables -A INPUT -p tcp --dport 22 -s 10.20.0.0/16 -j ACCEPT -m comment --comment "SSH hanya dari subnet office"

#Prinsip 4: Version Control (Git/IaC)

Ruleset produksi adalah aset — dan aset layak di-version. Simpan representasinya di git sebagai bagian dari IaC:

sudo iptables-save > iptables/rules.v4
sudo ip6tables-save > iptables/rules.v6

iptables/
├── rules.v4        # ruleset IPv4 produksi
├── rules.v6        # ruleset IPv6 produksi
└── README.md       # dokumentasi & SOP perubahan

Kebiasaan yang direkomendasikan: setiap perubahan dipromosikan lewat alur yang sama dengan kode — uji di staging, review diff, baru apply di produksi. Restore dari git adalah satu perintah:

sudo iptables-restore < iptables/rules.v4
sudo ip6tables-restore < iptables/rules.v6

Dengan iptables-restore yang atomik (episode 8), rollback berarti git checkout <commit lama> + satu restore.

#Audit Berkala

Firewall membusuk diam-diam: aturan yang sudah tidak relevan, port yang lupa ditutup, komentar yang menyesatkan. Jadikan audit rutin:

sudo iptables -L -n -v --line-numbers
sudo iptables -S
sudo iptables-save | grep -v "^#" | grep -- "-A"

Pertanyaan kunci saat audit:

• Adakah aturan yang counter-nya nol sejak lama? — mungkin tidak dibutuhkan.
• Adakah layanan yang diizinkan tapi aplikasinya sudah dicabut?
• Adakah komentar yang menunjuk orang/pemilik yang sudah pindah?
• Apakah rules.v4 di disk sama dengan ruleset yang aktif di kernel?

diff <(sudo iptables-save) /etc/iptables/rules.v4 && echo "Identik"

#Checklist Ruleset Produksi

Sebelum menyebut ruleset "production-ready", periksa:

• Policy INPUT/FORWARD = DROP; OUTPUT = ACCEPT (atau allowlist).
• ESTABLISHED,RELATED di paling atas; INVALID di-DROP.
• Loopback diizinkan; ICMP dibatasi bukan diblokir.
• SSH di-rate-limit dan dibatasi sumbernya bila memungkinkan.
• Chain user-defined untuk kelompok layanan; komentar untuk tiap aturan.
• Ruleset tersimpan di git; rules.v4/rules.v6 sejalan dengan kernel.
• Versi IPv6 paralel tidak dilupakan.
• Audit counter terjadwal (bulanan / per-perubahan besar).

#Penutup

Inti yang harus dibawa pulang:

• Default-deny + allowlist eksplisit = permukaan serangan minimal.
• Chain user-defined membuat ruleset terbaca seperti dokumen, bukan tumpukan teks.
• Modul comment mendokumentasikan mengapa — aset terbesar untuk audit.
• Simpan ruleset di git sebagai IaC; restore atomik adalah rollback instan.
• Audit berkala: hapus aturan mati, tutup port yang tak terpakai.

Di episode 18 selanjutnya kita akan membahas troubleshooting firewall & koneksi — mendiagnosis lewat counter, iptables-save | grep, tcpdump, conntrack -L, dan ss -tlnp; menangani koneksi yang drop tanpa log, aturan yang menutupi aturan lain, NAT yang tidak bekerja, serta konflik Docker/UFW. Sampai jumpa di episode 18!