Bagi seorang sysadmin atau engineer infrastruktur, memahami cara kerja firewall bukan sekadar teori—ini adalah garis pertahanan pertama server dari lalu lintas jaringan yang tidak diinginkan. Salah satu tool yang paling sering digunakan untuk keperluan ini di Linux adalah iptables.
Banyak orang menghafal perintah iptables -A INPUT -p tcp --dport 22 -j ACCEPT tanpa benar-benar memahami apa yang terjadi di baliknya: kenapa harus INPUT, bukan OUTPUT? Kenapa urutan rule penting? Apa bedanya DROP dengan REJECT secara nyata di jaringan?
Artikel ini akan membedah mekanisme iptables secara menyeluruh—mulai dari perjalanan paket di dalam kernel, proses evaluasi rule, hingga perbedaan fungsional dari setiap target. Tujuannya sederhana: setelah membaca ini, Anda tidak hanya bisa menulis rule iptables, tapi juga memahami mengapa rule tersebut bekerja seperti itu.
Catatan penting sebelum mulai: pada distribusi modern (Ubuntu 20.10 ke atas, Debian 11+, RHEL 9+), perintah iptables yang Anda jalankan sebenarnya diterjemahkan oleh backend nftables melalui lapisan kompatibilitas iptables-nft. Netfilter Project sendiri sudah menempatkan iptables versi legacy dalam status legacy maintenance—tetap didukung untuk perbaikan keamanan, tapi tidak ada lagi fitur baru. Kabar baiknya, sintaks dan konsep yang dibahas di artikel ini tetap 100% relevan, karena semua distro tersebut tetap menyediakan perintah iptables sebagai antarmuka utamanya.
Apa Itu Iptables dan Netfilter?
Iptables adalah utilitas userspace yang digunakan untuk mengonfigurasi aturan pada Netfilter, yaitu framework packet filtering yang tertanam di dalam kernel Linux. Netfilter menyediakan serangkaian hook point—titik-titik di mana kernel memeriksa setiap paket yang lewat—dan iptables adalah cara kita “menitipkan” aturan pada titik-titik tersebut.
Iptables bekerja dengan konsep tiga lapisan:
- Table — mengelompokkan aturan berdasarkan tujuan (misalnya
filteruntuk penyaringan paket,natuntuk translasi alamat,mangleuntuk modifikasi paket). - Chain — kumpulan rule di dalam sebuah table, dieksekusi sesuai posisi paket dalam alurnya (INPUT, OUTPUT, FORWARD, dan lainnya).
- Rule — kondisi pencocokan (source IP, port, protokol, dsb.) beserta target atau tindakan yang dijalankan jika paket cocok.
Fokus artikel ini adalah table filter, yaitu table default yang berisi tiga chain utama: INPUT, OUTPUT, dan FORWARD.
Perjalanan Sebuah Paket: Memahami Chain INPUT, OUTPUT, dan FORWARD
Bayangkan setiap paket jaringan sebagai surat yang masuk ke kantor pos (server Anda). Sebelum surat itu sampai ke penerima, ia harus melewati beberapa pos pemeriksaan. Berikut alurnya:
1. Chain INPUT
Chain ini dilalui oleh paket yang tujuannya adalah server itu sendiri. Misalnya, seseorang mencoba SSH ke server Anda di port 22, atau browser mengakses web server di port 80. Sebelum paket ini diteruskan ke aplikasi (sshd, nginx, dsb.), kernel akan mengevaluasinya lewat chain INPUT terlebih dahulu.
Analoginya: INPUT adalah satpam di pintu masuk gedung kantor Anda sendiri—memeriksa siapa saja yang mau masuk ke ruangan Anda.
2. Chain OUTPUT
Chain ini dilalui oleh paket yang berasal dari server itu sendiri menuju keluar. Contohnya ketika server Anda melakukan curl ke API eksternal, atau mengirim balasan DNS query. Paket ini dievaluasi oleh chain OUTPUT sebelum meninggalkan mesin.
Analoginya: OUTPUT adalah satpam yang memeriksa barang yang Anda bawa keluar dari kantor.
3. Chain FORWARD
Chain ini dilalui oleh paket yang bukan untuk server ini, melainkan hanya “numpang lewat”—server bertindak sebagai router atau gateway yang meneruskan trafik dari satu jaringan ke jaringan lain. Ini relevan misalnya pada server yang difungsikan sebagai router, VPN gateway, atau load balancer transparan.
Analoginya: FORWARD adalah jalur transit di bandara—penumpang tidak keluar ke kota, hanya lewat menuju penerbangan lain.
Penting: Sebelum paket sampai ke INPUT atau FORWARD, kernel sebenarnya sudah melewati proses routing decision terlebih dahulu untuk menentukan apakah paket ini ditujukan untuk sistem lokal (masuk ke INPUT) atau perlu diteruskan (masuk ke FORWARD). Untuk kebutuhan sehari-hari, memahami tiga chain filter ini sudah cukup untuk mengelola firewall server.
Bagaimana Rule Diproses: Dari Atas ke Bawah
Ini adalah konsep paling krusial yang sering disalahpahami: iptables mengevaluasi rule dalam sebuah chain secara berurutan, dari atas ke bawah, dan berhenti begitu menemukan rule yang cocok dengan target final (ACCEPT/DROP/REJECT).
Contoh kasus:
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP
Pada contoh ini:
- Paket SSH dari jaringan
192.168.1.0/24akan dicek rule pertama—cocok, target ACCEPT dijalankan, evaluasi berhenti di sini. - Paket SSH dari IP lain akan gagal di rule pertama, lanjut ke rule kedua—cocok, di-DROP.
Kalau urutan kedua rule ini dibalik, seluruh trafik SSH (termasuk dari jaringan lokal) akan langsung di-DROP oleh rule pertama, dan rule ACCEPT di bawahnya tidak akan pernah tereksekusi. Inilah kenapa urutan rule sama pentingnya dengan isi rule itu sendiri.
Jika tidak ada satu pun rule yang cocok sampai akhir chain, iptables akan menjalankan default policy dari chain tersebut (biasanya diset dengan iptables -P INPUT DROP, misalnya).
Memahami Target: ACCEPT, DROP, REJECT, dan LOG
ACCEPT
Mengizinkan paket untuk melanjutkan perjalanannya. Untuk chain INPUT, ini berarti paket diteruskan ke aplikasi/proses yang dituju. Target ini bersifat final—begitu ACCEPT dijalankan, evaluasi rule pada chain tersebut berhenti.
DROP
Membuang paket secara diam-diam, tanpa memberi respons apa pun ke pengirim. Dari sisi klien, ini terasa seperti koneksi yang menggantung (timeout), bukan ditolak secara eksplisit.
Kelebihan DROP: menyembunyikan keberadaan server dari port scanner sederhana, karena penyerang tidak mendapat konfirmasi bahwa port tersebut “ada” tapi ditutup.
REJECT
Mirip dengan DROP dalam hal menolak paket, tapi mengirimkan respons penolakan ke pengirim—misalnya paket ICMP “port unreachable” untuk UDP, atau TCP RST untuk koneksi TCP. Target ini secara teknis merupakan modul ekstensi (bukan verdict inti netfilter seperti ACCEPT/DROP), sehingga penulisannya butuh menyebutkan tipe reject secara eksplisit jika ingin dikustomisasi, misalnya:
iptables -A INPUT -p tcp --dport 8080 -j REJECT --reject-with tcp-reset
Kelebihan REJECT: klien mendapat kepastian instan bahwa koneksi ditolak, bukan menunggu timeout—ini lebih ramah untuk servis yang memang sengaja ditutup untuk publik tapi ingin memberi tahu klien secara jelas (misalnya di jaringan internal).
LOG
Berbeda dari tiga target sebelumnya, LOG tidak bersifat final—paket tetap diteruskan ke rule berikutnya setelah dicatat. LOG hanya menulis informasi paket (source IP, port, flag TCP, dsb.) ke log kernel yang bisa dilihat lewat dmesg atau journalctl -k.
Karena sifatnya non-terminating, LOG biasa dipasang sebelum rule DROP/REJECT, supaya percobaan akses yang ditolak tetap tercatat untuk keperluan audit:
iptables -A INPUT -p tcp --dport 23 -j LOG --log-prefix "TELNET-BLOCKED: "
iptables -A INPUT -p tcp --dport 23 -j DROP
Materi Praktis: Studi Kasus Sederhana
Misalkan Anda mengelola sebuah web server dengan kebutuhan berikut:
- Mengizinkan SSH hanya dari IP kantor
- Mengizinkan HTTP dan HTTPS untuk publik
- Menolak semua trafik lain secara default
- Mencatat percobaan akses yang gagal
Berikut implementasinya:
# Kebijakan default: tolak semua dulu
iptables -P INPUT DROP
# Izinkan loopback (penting agar service lokal tidak rusak)
iptables -A INPUT -i lo -j ACCEPT
# Izinkan koneksi yang sudah established/related
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH hanya dari IP kantor
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.10 -j ACCEPT
# HTTP dan HTTPS untuk publik
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Log dan tolak sisanya
iptables -A INPUT -j LOG --log-prefix "DROPPED: "
iptables -A INPUT -j DROP
Perhatikan bagaimana urutan rule di atas mengikuti prinsip most specific first: aturan yang lebih spesifik (SSH dari IP tertentu) diletakkan sebelum aturan yang lebih umum.
Tutorial Step-by-Step: Membangun Firewall Dasar
Langkah 1 — Cek status iptables saat ini
iptables -L -n -v --line-numbers
Selalu cek dulu rule yang sudah ada sebelum menambah rule baru, agar tidak terjadi konflik urutan.
Langkah 2 — Backup rule yang ada
iptables-save > /root/iptables-backup-$(date +%F).rules
Langkah ini sering dilupakan, padahal krusial—salah konfigurasi firewall bisa mengunci Anda sendiri dari server (terutama jika akses hanya lewat SSH).
Langkah 3 — Tambahkan rule ESTABLISHED/RELATED di awal
Rule ini memastikan paket balasan dari koneksi yang sudah Anda buat sendiri (misalnya apt update) tidak ikut terblokir.
Langkah 4 — Tambahkan rule spesifik untuk servis yang dibutuhkan
Urutkan dari yang paling spesifik ke paling umum.
Langkah 5 — Set default policy menjadi DROP
Lakukan ini paling akhir, setelah semua rule ACCEPT terpasang dan diuji, supaya tidak memutus akses SSH Anda sendiri di tengah proses konfigurasi.
Langkah 6 — Simpan konfigurasi secara permanen
Rule iptables bersifat sementara (hilang saat reboot) kecuali disimpan lewat tool seperti iptables-persistent (Debian/Ubuntu) atau iptables.service (RHEL-based).
Kesalahan yang Sering Terjadi
1. Meletakkan default policy DROP sebelum rule ACCEPT selesai dikonfigurasi Penyebab: tergesa-gesa mengetes keamanan. Dampak: akses SSH terputus, admin terkunci dari server sendiri. Solusi: selalu konfigurasi rule ACCEPT dahulu, uji koneksi paralel (misalnya sesi SSH kedua), baru ubah default policy.
2. Lupa mengizinkan interface loopback (lo) Penyebab: menganggap loopback otomatis diizinkan. Dampak: aplikasi yang saling berkomunikasi lewat localhost (misalnya database dan web app di server yang sama) gagal terhubung. Solusi: selalu tambahkan iptables -A INPUT -i lo -j ACCEPT di awal rule.
3. Tidak mempertimbangkan urutan rule Penyebab: menambah rule baru tanpa memeriksa posisi. Dampak: rule baru tidak pernah tereksekusi karena “ketutup” rule di atasnya. Solusi: gunakan --line-numbers saat memeriksa rule, dan sisipkan rule baru di posisi yang tepat dengan -I bukan selalu -A.
4. Menggunakan DROP untuk semua kasus tanpa mempertimbangkan REJECT Penyebab: menganggap DROP selalu lebih aman. Dampak: klien legit mengalami timeout lama pada servis internal yang seharusnya bisa langsung diberi tahu ditolak. Solusi: gunakan REJECT untuk jaringan internal/servis yang memang perlu memberi kepastian, DROP untuk exposure ke internet publik.
Tips dan Rekomendasi
- Gunakan rule ESTABLISHED,RELATED di posisi paling atas (setelah loopback) untuk efisiensi—paket balasan tidak perlu dicek ulang dari nol.
- Kelompokkan rule berdasarkan servis dan beri komentar dengan opsi
-m comment --comment "..."agar mudah diaudit tim lain. - Selalu backup rule sebelum perubahan besar, dan uji lewat sesi terpisah agar tidak terkunci sendiri.
- Untuk server produksi baru, pertimbangkan menggunakan
nftlangsung (sintaks native nftables) karena ini adalah arah pengembangan jangka panjang, sementaraiptableskini berjalan lewat lapisan kompatibilitasiptables-nftdi banyak distro modern. - Manfaatkan
iptables -L -vuntuk melihat packet count per rule—rule dengan counter nol dalam waktu lama bisa jadi kandidat untuk dihapus atau ditinjau ulang.

Kesimpulan
Iptables bekerja dengan prinsip yang sebenarnya cukup logis begitu dipahami: setiap paket punya “arah perjalanan” yang menentukan chain mana yang dilaluinya (INPUT untuk tujuan lokal, OUTPUT untuk asal lokal, FORWARD untuk transit), rule dievaluasi berurutan dari atas ke bawah dan berhenti pada target final pertama yang cocok, serta setiap target—ACCEPT, DROP, REJECT, LOG—punya efek dan konsekuensi jaringan yang berbeda.
Poin penting yang perlu diingat:
- Urutan rule menentukan hasil, bukan hanya isi rule.
- DROP bersifat diam, REJECT memberi kepastian ke klien.
- LOG tidak menghentikan evaluasi—selalu pasangkan dengan target final.
- Selalu uji dan backup sebelum mengubah default policy menjadi DROP.
Memahami mekanisme ini adalah fondasi sebelum melangkah ke topik lanjutan seperti nftables, firewalld, atau integrasi firewall dengan container (Docker/Kubernetes) yang punya lapisan aturan tersendiri.
Frequently Asked Questions (FAQ)
Pertanyaan: Apa perbedaan utama antara chain INPUT dan FORWARD? Jawaban: INPUT menangani paket yang tujuannya adalah server itu sendiri, sedangkan FORWARD menangani paket yang hanya melewati server sebagai perantara (misalnya saat server berfungsi sebagai router).
Pertanyaan: Kenapa DROP dianggap lebih “aman” daripada REJECT untuk server publik? Jawaban: Karena DROP tidak memberi respons apa pun, sehingga penyerang atau port scanner tidak mendapat konfirmasi bahwa port tersebut benar-benar ada di server.
Pertanyaan: Apakah urutan rule iptables benar-benar memengaruhi hasil? Jawaban: Ya. Iptables mengevaluasi rule dari atas ke bawah dan berhenti pada rule pertama yang cocok dengan target final, sehingga rule yang sama bisa menghasilkan efek berbeda tergantung posisinya.
Pertanyaan: Apakah rule iptables otomatis tersimpan setelah server reboot? Jawaban: Tidak. Rule iptables bersifat sementara di memori kernel dan harus disimpan secara eksplisit menggunakan tool seperti iptables-persistent atau iptables.service.
Pertanyaan: Apakah iptables masih relevan dipelajari di tahun 2026 mengingat adanya nftables? Jawaban: Ya, karena banyak distribusi modern tetap menyediakan perintah iptables sebagai antarmuka (dijalankan lewat backend nftables), dan konsep chain serta target yang dibahas tetap menjadi dasar pemahaman firewall Linux secara umum.
Sudah lebih paham cara kerja iptables di balik layar? Yuk tulis di kolom komentar: apakah kamu masih pakai iptables legacy atau sudah migrasi ke nftables di server produksimu?
Jangan lupa bagikan artikel ini ke rekan sysadmin/DevOps lain yang mungkin masih bingung soal urutan chain dan target firewall, dan pantau terus artikel-artikel seputar Linux, networking, dan cybersecurity berikutnya di blog ini.