11.1 Netfilter and iptables Behavior

11.1 Netfilter and iptables Behavior

Kali Linux inherits its firewalling stack from Debian, which means two layers you must keep straight for the KLCP exam: netfilter, the framework inside the Linux kernel that actually inspects and acts on packets, and iptables, the traditional userspace command you run to configure it. On current Kali releases there is a third name, nftables, which is the modern successor backend. Questions love to test whether you know which layer does what.

Netfilter: the Kernel Framework

Netfilter is a set of hooks inside the Linux kernel's networking stack. As a packet moves through the system it passes fixed hook points, and any registered module — such as the firewall ruleset — can inspect, modify, drop, or accept it at each hook. The five hook points map directly onto the five built-in chain names you see in iptables:

• PREROUTING — packets that just arrived, before any routing decision
• INPUT — packets destined for a local process on this machine
• FORWARD — packets being routed through this machine to another host
• OUTPUT — packets generated locally, heading out
• POSTROUTING — packets about to leave, after routing

Connection tracking (conntrack) also lives in netfilter. This is what lets the firewall treat packets as part of a flow (NEW, ESTABLISHED, RELATED) instead of isolated datagrams — the foundation of the stateful rules you will write in section 11.2.

The Four Tables

iptables organizes rules into tables, each grouping chains by purpose. A table is a category of processing; a chain is a list of rules attached to a hook point.

Exam traps to memorize: filter is the default table — if you run iptables without -t, you are editing filter. The nat table is where MASQUERADE, SNAT, and DNAT live. raw runs before connection tracking and exists almost solely to mark packets that should bypass conntrack. mangle is for modifying packets, not for filtering them, even though you technically can drop packets there (don't).

Notice the chain coverage: the filter table has no PREROUTING or POSTROUTING chain, because filtering decisions need the routing decision to have been made (INPUT/FORWARD) or the packet to be locally sourced (OUTPUT). The nat table's POSTROUTING chain is where source NAT happens; PREROUTING is where destination NAT happens.

First-Match Rule Processing and Default Policies

Each chain is an ordered list of rules. The kernel walks the list from top to bottom and applies the first rule that matches the packet. Processing then stops for terminating targets such as ACCEPT, DROP, and REJECT. The LOG target is the important exception: it is non-terminating, so after logging, evaluation continues to the next rule. Place a LOG rule immediately before the DROP you want visibility into.

If no rule matches, the chain's default policy decides the packet's fate. You set it with iptables -P INPUT DROP, for example. Only ACCEPT and DROP are valid policies — iptables -P INPUT REJECT fails, a classic exam distractor. Best practice for a hardened box is a default-DROP stance on INPUT and FORWARD with explicit allow rules above it:

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

Order matters because of first-match semantics: a broad ACCEPT placed before a specific DROP shadows the DROP entirely. Use iptables -L -v -n --line-numbers to inspect the live ruleset with packet/byte counters and rule numbers.

Kali's Out-of-the-Box Posture

A fresh Kali install ships with an empty ruleset and ACCEPT policies everywhere — there is effectively no firewall. This is deliberate: Kali's security model leans on the fact that network services (SSH, Apache, PostgreSQL) are disabled by default, so there is little to expose. If you enable services for an engagement, adding a firewall is on you. Don't assume Kali is protected by default; assume it is quiet by default.

iptables vs nftables in Modern Kali

nftables is the newer kernel packet-filtering framework meant to replace iptables, ip6tables, arptables, and ebtables with one tool (nft) and one ruleset. Debian switched to nftables as the default backend starting with Debian 10 (Buster), and Kali — being based on Debian Testing — followed. On a modern Kali system:

• The iptables binary is iptables-nft: it accepts classic iptables syntax but programs the nftables kernel subsystem through a compatibility layer.
• The old implementation remains available as iptables-legacy, switchable via update-alternatives --config iptables.
• You can view the actual active ruleset with nft list ruleset; rules added with iptables-nft appear there too.

Practical consequence: your classic iptables syntax still works on Kali, and the exam still tests it, but the underlying engine is nftables. Mixing native nft rules and iptables-legacy rules against the same hook points produces confusing interactions — pick one frontend per system.

A quick mental model for troubleshooting: when a rule 'isn't working,' check three things in order. First, confirm the rule landed in the table and chain you intended with iptables -t <table> -L -n -v — a rule added to filter when you meant nat silently does nothing. Second, check rule order, since an earlier broad match shadows everything below it. Third, remember that user-defined chains (created with iptables -N) do nothing until a built-in chain jumps into them with -j <chain-name>; the built-in chains are the only entry points wired to the kernel hooks.