1. What is Netfilter?
Netfilter is the Linux kernel's network packet-processing subsystem.
iptables is the user-space command/tool used to configure Netfilter.
So:
User space
|
| iptables commands
v
+----------------------+
| Linux Kernel |
| |
| Netfilter |
| |
| Packet processing |
+----------------------+
|
v
Network interfaces
Purdy explicitly states:
"The Linux kernel's network packet processing subsystem is called Netfilter, and iptables is the command used to configure it."
Exact source:
Gregor N. Purdy, Linux iptables Pocket Reference, O'Reilly Media, 2004, Introduction, p. 1.
2. Netfilter vs iptables
These two terms are closely related but are not exactly the same thing.
Netfilter
Netfilter is the kernel framework/subsystem responsible for packet processing.
iptables
iptables is the user-space configuration mechanism used to specify rules for that framework.
USER SPACE
|
|
iptables
|
| configure rules
v
+-------------+
| Netfilter |
| (kernel) |
+-------------+
|
v
packets
Purdy notes that Netfilter and iptables are tightly coupled and uses the term "iptables" in places to refer to either or both.
Source: Purdy, Introduction, p. 1.
3. Where does Netfilter operate?
Purdy states that:
iptables operates at OSI Layer 3 (Network).
For Layer 2 packet processing, other technologies such as ebtables are used.
Therefore:
OSI Layer 7 Application
|
OSI Layer 4 TCP / UDP
|
OSI Layer 3 IP
|
↓
Netfilter
↓
OSI Layer 2 Ethernet
The Netfilter/iptables architecture described in Purdy is therefore centered on IPv4/network-layer packet processing.
Exact source: Purdy, Introduction, p. 1.
4. The basic Netfilter architecture
The most important architectural idea is:
Packets
|
v
Hook points
|
v
Chains
|
v
Rules
|
+------ Match
|
+------ Target
Purdy describes the architecture as grouping packet-processing rules into tables, with tables containing chains, and chains containing processing rules.
A rule consists of:
Match criteria
+
Target
Match
Determines whether a particular packet is affected by the rule.
Target
Determines what happens to a packet when the rule matches.
Examples of possible targets include:
ACCEPT
DROP
REJECT
DNAT
SNAT
LOG
Source: Purdy, Introduction and the sections Tables, Chains, Rules, Matches, and Targets, pp. 2–7.
5. Hook Points
Netfilter defines five hook points in the kernel's packet-processing path.
The five are:
PREROUTING
INPUT
FORWARD
OUTPUT
POSTROUTING
Purdy emphasizes that these hook points represent locations in the packet-processing path where chains of rules can be attached.
PREROUTING
|
+------+------+
| |
INPUT FORWARD
| |
v v
Local process Routing
|
v
POSTROUTING
Local-generated packets
|
v
OUTPUT
|
v
POSTROUTING
Exact source: Purdy, Concepts, pp. 2–3, "hook points" and "Chains."
6. The Five Hook Points
6.1 PREROUTING
Packets arriving from a network interface encounter the PREROUTING hook before the kernel makes the final routing decision.
Conceptually:
Network interface
|
v
PREROUTING
|
v
Routing decision
This is important because operations such as destination NAT can occur before the routing decision.
Purdy's example uses:
iptables -t nat -A PREROUTING ...
to perform destination NAT.
Source: Purdy, "Example Command", "Packet flow", and NAT sections.
6.2 INPUT
The INPUT hook is used for packets whose final destination is the local machine.
Conceptually:
Network
|
v
PREROUTING
|
v
Routing decision
|
| local destination
v
INPUT
|
v
Local process
The packet is therefore entering the local host, not being forwarded through it.
Source: Purdy, "Packet flow", pp. 5–7.
6.3 FORWARD
The FORWARD hook is used when the Linux machine is routing a packet from one network interface to another.
Interface A
|
v
PREROUTING
|
v
Routing decision
|
v
FORWARD
|
v
POSTROUTING
|
v
Interface B
This is the key hook when Linux is behaving as a router/firewall forwarding traffic.
Source: Purdy, "Packet flow", Table 4 — Packet flows from one network interface to another (forwarding), p. 6.
6.4 OUTPUT
The OUTPUT hook handles packets generated by processes on the local machine.
Conceptually:
Local process
|
v
OUTPUT
|
v
Routing
|
v
POSTROUTING
|
v
Network interface
Therefore:
INPUT → traffic coming to the local machine
OUTPUT → traffic generated by the local machine
Source: Purdy, "Packet flow", pp. 6–7.
6.5 POSTROUTING
The POSTROUTING hook is encountered after the routing decision and before the packet leaves through the outgoing interface.
Routing
|
v
POSTROUTING
|
v
Outgoing interface
This is particularly important for source NAT / masquerading.
Source: Purdy, "Packet flow" and NAT sections.
7. Tables
A table represents a category/type of packet processing.
Purdy explains that iptables organizes packet-processing rules into tables according to function.
Major tables discussed in the book include:
filter
nat
mangle
The table determines what kind of processing the rules in it perform.
7.1 filter table
The filter table is used for ordinary packet filtering.
Typical actions include:
ACCEPT
DROP
REJECT
The filter table is the default table when no table is explicitly specified in an iptables command.
Source: Purdy, Tables and command reference.
7.2 nat table
The nat table is used for Network Address Translation.
It is associated with:
-
Source NAT
-
Destination NAT
-
Masquerading
-
Connection tracking
Example from Purdy:
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
-j DNAT --to-destination 192.168.1.3:8080
Here:
-t nat
selects the NAT table.
-A PREROUTING
adds the rule to the PREROUTING chain.
-j DNAT
specifies the destination-NAT target.
Source: Purdy, "An Example Command", p. 1; Network Address Translation, pp. 17–20.
7.3 mangle table
The mangle table is used for packet modification/mangling.
Purdy's index and tables/packet-flow discussion show that the mangle table participates at multiple hook points.
Examples of processing associated with it include:
-
MARK
-
TTL modification
-
Other packet alterations
Source: Purdy, Tables, Packet flow, and MARK/TTL targets.
8. Tables vs Chains
This distinction is very important.
It is common to say:
"PREROUTING chain of the nat table"
but Purdy explicitly points out that tables and chains are only partially correlated.
The conceptual distinction is:
CHAIN
=
Where in the packet-processing path?
TABLE
=
What type of processing?
So:
Hook point → chain
Processing function → table
Purdy explicitly warns that chains represent hook points in packet flow, while tables represent types of processing.
Source: Purdy, Concepts — Chains, p. 3.
9. Chains
A chain is a sequence of rules processed in order.
Chain
|
+-- Rule 1
|
+-- Rule 2
|
+-- Rule 3
|
+-- Rule 4
|
v
Policy / target
Each packet is presented to the rules one at a time.
If the packet does not match a rule:
Rule 1
|
| no match
v
Rule 2
|
| no match
v
Rule 3
This continues until:
-
a matching target determines an outcome, or
-
the end of the chain is reached.
Source: Purdy, Chains and Packet flow, pp. 3–6.
10. Built-in Chains
The built-in chains correspond to Netfilter's hook points.
The important ones are:
PREROUTING
INPUT
FORWARD
OUTPUT
POSTROUTING
They are associated with the packet path through the kernel.
Purdy also distinguishes built-in chains from user-defined chains.
11. User-defined Chains
Users can create their own chains to organize rules.
Example concept:
INPUT
|
+----> WEB_RULES
|
+----> SSH_RULES
|
+----> OTHER_RULES
This allows a large firewall policy to be divided into logical groups.
Purdy notes that user-defined chains have an implicit RETURN behavior rather than the configurable policy of built-in chains.
Source: Purdy, Chains, p. 4.
12. Chain Policy
A chain has a policy that determines what happens when a packet reaches the end of a built-in chain without matching a rule that determines its fate.
Purdy explains:
Built-in chain
|
+-- Rule 1
+-- Rule 2
+-- Rule 3
|
+-- no match
|
v
Chain policy
The built-in targets that can be used as a chain policy are:
ACCEPT
DROP
The default policy is:
ACCEPT
for a newly created built-in chain unless changed.
User-defined chains implicitly return control to the calling chain.
Source: Purdy, Chains, p. 4.
13. Rules
A rule consists of two conceptual parts:
Rule
|
+---- Match criteria
|
+---- Target
Match
Determines which packets the rule applies to.
Examples from Purdy's command reference include matches based on:
IP addresses
TCP
UDP
ICMP
Interface
Port
State
Packet length
Time
MAC address
Target
Determines what action is taken when the rule matches.
Examples:
ACCEPT
DROP
REJECT
LOG
DNAT
SNAT
MARK
REDIRECT
Source: Purdy, Rules, Matches, Targets, pp. 6–7 and command reference.
14. How Rule Matching Works
Suppose a chain contains:
Rule 1: TCP destination port 22 → ACCEPT
Rule 2: TCP destination port 80 → ACCEPT
Rule 3: everything else → DROP
A packet passes through the rules in sequence.
Packet
|
v
Rule 1
|
| no match
v
Rule 2
|
| match
v
ACCEPT
Purdy states that all match criteria specified for a rule must be satisfied for that rule to match a packet.
Source: Purdy, Rules, p. 7.
15. Targets
A target specifies what happens to a packet after a rule matches.
Important targets include:
ACCEPT
Allow the packet to continue.
packet
↓
ACCEPT
↓
continue processing
DROP
Discard the packet.
packet
↓
DROP
↓
discarded
REJECT
Reject the packet rather than silently dropping it.
LOG
Generate logging information while allowing packet processing to continue according to the subsequent processing.
NAT-related targets
DNAT
SNAT
MASQUERADE
REDIRECT
Purdy covers these in the command reference and NAT sections.
Source: Purdy, Targets, pp. 6–7 and command reference.
16. Packet Flow
This is the most important part of Netfilter architecture.
A packet does not simply pass through every chain.
Its path depends on:
-
Where the packet came from
-
Whether it is destined for the local machine
-
Whether it is being forwarded
-
Whether it was generated locally
17. Forwarded Packet
Consider a Linux machine acting as a router.
Interface A
|
v
PREROUTING
|
v
Routing decision
|
v
FORWARD
|
v
POSTROUTING
|
v
Interface B
Purdy gives the exact table/chain sequence for forwarding traffic:
mangle PREROUTING
nat PREROUTING
mangle FORWARD
filter FORWARD
mangle POSTROUTING
nat POSTROUTING
Exact source: Purdy, Packet flow — Table 4, "Packet flows from one network interface to another (forwarding)", p. 6.
18. Packet Destined for Local Process
For traffic coming from a network interface and destined for a local process, Purdy gives:
mangle PREROUTING
nat PREROUTING
mangle INPUT
filter INPUT
Conceptually:
Incoming interface
|
v
PREROUTING
|
v
Routing decision
|
| local
v
INPUT
|
v
Local process
Source: Purdy, Packet flow — Table 5, p. 6–7.
19. Locally Generated Packet
A packet generated by a local process follows a different path.
Conceptually:
Local process
|
v
OUTPUT
|
v
Routing
|
v
POSTROUTING
|
v
Network interface
The corresponding tables/chains are shown in Purdy's packet-flow tables.
Source: Purdy, Packet flow, pp. 6–7.
20. Complete Packet-Flow Model
A useful combined model is:
INCOMING PACKET
|
v
+--------------+
| PREROUTING |
+--------------+
|
v
Routing Decision
/ \
/ \
local forwarded
| |
v v
+---------+ +-----------+
| INPUT | | FORWARD |
+---------+ +-----------+
| |
v v
Local Process +-----------+
|POSTROUTING|
+-----------+
|
v
Outgoing Interface
LOCALLY GENERATED PACKET
|
v
+---------+
| OUTPUT |
+---------+
|
v
Routing / next step
|
v
POSTROUTING
|
v
Outgoing Interface
This is a conceptual representation of the packet paths and hook points described by Purdy.
21. Exact Forwarding Path from Purdy
For a packet forwarded from one network interface to another:
mangle PREROUTING
↓
nat PREROUTING
↓
Routing decision
↓
mangle FORWARD
↓
filter FORWARD
↓
mangle POSTROUTING
↓
nat POSTROUTING
↓
Outgoing interface
Source: Purdy, Packet flow, Table 4, p. 6.
Notice that:
filter FORWARD
appears after the routing decision.
This is because the kernel needs to know whether the packet is being forwarded before it can process it through the FORWARD hook.
22. Why PREROUTING Comes Before Routing
This is especially important for NAT.
Suppose a packet arrives with:
Destination = Public_IP
and a DNAT rule changes it to:
Destination = 192.168.1.3
That destination change must happen before the kernel decides where to route the packet.
Hence:
Packet arrives
|
v
PREROUTING
|
| DNAT
v
Destination changed
|
v
Routing decision
This is why DNAT is associated with PREROUTING in the packet-flow architecture.
Purdy's example command demonstrates this directly:
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
-j DNAT --to-destination 192.168.1.3:8080
Source: Purdy, "An Example Command" and NAT sections.
23. Why POSTROUTING Comes After Routing
Source NAT modifies the source address of a packet that is leaving the system.
Conceptually:
Packet
|
v
Routing decision
|
v
POSTROUTING
|
| SNAT / MASQUERADE
v
Outgoing interface
Therefore the packet has already gone through the routing decision before the final source-address modification.
Source: Purdy, Packet flow, Source NAT and Masquerading, pp. 6 and 18.
24. Connection Between Tables and Hooks
Not every table appears at every hook.
For example, in the forwarding path described by Purdy:
mangle PREROUTING
nat PREROUTING
mangle FORWARD
filter FORWARD
mangle POSTROUTING
nat POSTROUTING
So the architecture is better thought of as:
HOOK
|
+---------+---------+
| | |
table table table
| | |
rules rules rules
rather than:
table
|
+-- all hooks
Purdy explicitly notes the partial relationship between tables and chains.
25. Netfilter as a Packet Decision System
The complete decision process can be viewed as:
Incoming packet
|
v
Which hook?
|
v
Which relevant table?
|
v
Which chain?
|
v
Rule 1
|
| no match
v
Rule 2
|
| no match
v
Rule 3
|
| match
v
Target
|
+---- ACCEPT
+---- DROP
+---- REJECT
+---- DNAT
+---- SNAT
+---- LOG
+---- ...
This is the basic architecture described throughout Purdy's Concepts, Tables, Chains, Packet flow, Rules, Matches, and Targets sections.
26. Stateful Firewalling
Netfilter can also be used with connection tracking.
Purdy has a dedicated section:
Connection Tracking
and discusses connection states such as:
ESTABLISHED
EXPECTED
This allows firewall rules to take connection state into account.
For example, conceptually:
New connection
|
v
connection
tracking
|
v
ESTABLISHED
|
v
subsequent packets
This is different from treating every packet as completely independent.
Source: Purdy, Connection Tracking, p. 14 and state/conntrack match material.
27. Stateless vs Stateful Firewall
Purdy explicitly discusses:
Stateless Firewalls
Stateful Firewalls
Stateless
Each packet is evaluated primarily using the information contained in that packet.
Packet
↓
Rules
↓
Decision
Stateful
The firewall additionally keeps track of connection state.
Packet
↓
Connection tracking
↓
State
↓
Rules
↓
Decision
This is especially useful for TCP because packets can be interpreted in the context of an existing connection.
Source: Purdy, Stateless and Stateful Firewalls, p. 20; Connection Tracking, p. 14.
28. Netfilter and NAT
Netfilter is not only for filtering.
Purdy's architecture also supports:
Packet filtering
NAT
Packet mangling
Accounting
Connection tracking
The major NAT operations include:
DNAT
SNAT
MASQUERADE
REDIRECT
Conceptually:
Netfilter
|
+------------+-------------+
| | |
filtering NAT mangling
| | |
ACCEPT DNAT/SNAT MARK
DROP MASQUERADE TTL
Source: Purdy, Concepts, Applications, Connection Tracking, and Network Address Translation, pp. 2–20.
29. Netfilter and Firewalling
A basic packet-filtering firewall can be represented as:
Incoming Packet
|
v
Netfilter
|
v
filter table
|
v
INPUT /
FORWARD
|
+-----+-----+
| |
ACCEPT DROP
| |
v X
continue discard
For a Linux machine acting as a router, the important chain is:
FORWARD
For traffic destined for the local machine:
INPUT
For locally generated traffic:
OUTPUT
30. Netfilter in a Linux Router
Suppose Linux has two interfaces:
Network A
|
eth0
|
+---------------+
| Linux Router |
| |
| Netfilter |
+---------------+
|
eth1
|
Network B
A packet from Network A to Network B follows:
eth0
|
v
PREROUTING
|
v
Routing
|
v
FORWARD
|
v
POSTROUTING
|
v
eth1
This is the fundamental architecture to understand when using Linux as a router/firewall.
Source: Purdy, Packet flow, Table 4.
31. Netfilter and Kurose & Ross
Kurose & Ross does not describe Linux Netfilter's internal architecture in the same detail as Purdy.
What it contributes is the general concept of a middlebox.
In Kurose & Ross, Chapter 4, §4.5, a middlebox is a device placed along a network path that performs functions beyond simple IP forwarding.
Firewalls are examples of such functionality.
The conceptual relationship is:
Normal IP router
↓
Forward packets based on destination
Firewall / middlebox
↓
Inspect / filter / modify traffic
Kurose & Ross therefore provides the network architecture context, while Purdy provides the actual Linux/iptables architecture.
Source: Kurose & Ross, Computer Networking: A Top-Down Approach, 8th ed., Chapter 4, §4.5 — Middleboxes.
32. Netfilter and Wenliang Du
Wenliang Du's security material approaches Linux firewalling from the security perspective.
The associated firewall material covers:
-
Firewall concepts
-
Netfilter
-
iptables
-
Firewall rules
-
Linux packet filtering
The important relationship is:
Network traffic
|
v
Linux kernel
|
v
Netfilter
|
v
iptables rules
|
v
Security decision
This complements Purdy:
Purdy
→ How iptables / Netfilter is structured
Du
→ How firewalling and packet filtering are used
for security
33. Important Terminology
| Term | Meaning |
|---|---|
| Netfilter | Linux kernel packet-processing subsystem |
| iptables | User-space tool used to configure Netfilter |
| Hook point | Point in the kernel packet path where processing can occur |
| Chain | Ordered sequence of rules associated with processing at a hook |
| Table | Groups rules according to processing function |
| Rule | Match criteria + target |
| Match | Determines whether a rule applies to a packet |
| Target | Determines what happens to a matching packet |
| Policy | Default action for a built-in chain when no rule determines the packet's fate |
| Connection tracking | Maintains information about connection state |
| DNAT | Destination Network Address Translation |
| SNAT | Source Network Address Translation |
| MASQUERADE | Source NAT mechanism described by iptables |
| PREROUTING | Processing point before routing decision |
| INPUT | Processing point for packets destined for local host |
| FORWARD | Processing point for packets routed through the host |
| OUTPUT | Processing point for packets generated locally |
| POSTROUTING | Processing point after routing decision, before transmission |
34. The Most Important Diagram
Memorize this:
INCOMING PACKET
|
v
+-------------+
| PREROUTING |
+-------------+
|
v
ROUTING DECISION
/ \
/ \
/ \
LOCAL FORWARD
| |
v v
+---------+ +-----------+
| INPUT | | FORWARD |
+---------+ +-----------+
| |
v v
Local Process +-------------+
|POSTROUTING |
+-------------+
|
v
OUTGOING INTERFACE
LOCALLY GENERATED PACKET
|
v
+---------+
| OUTPUT |
+---------+
|
v
ROUTING DECISION
|
v
POSTROUTING
|
v
OUTGOING INTERFACE
35. Forwarding Path to Memorize
For a packet entering one interface and leaving another:
PREROUTING
↓
Routing
↓
FORWARD
↓
POSTROUTING
The actual table/chain sequence from Purdy is:
mangle PREROUTING
nat PREROUTING
mangle FORWARD
filter FORWARD
mangle POSTROUTING
nat POSTROUTING
Source: Purdy, Packet flow, Table 4, p. 6.
36. Local-Delivery Path to Memorize
For an incoming packet destined for the local machine:
PREROUTING
↓
Routing
↓
INPUT
↓
Local process
Purdy's table gives:
mangle PREROUTING
nat PREROUTING
mangle INPUT
filter INPUT
Source: Purdy, Packet flow, Table 5, p. 6.
37. Locally Generated Packet Path
For a packet generated by the local host:
Local process
↓
OUTPUT
↓
Routing
↓
POSTROUTING
↓
Network interface
This path is important when filtering traffic generated by the Linux machine itself.
Source: Purdy, Packet flow, pp. 6–7.
38. One Rule to Remember
The easiest way to remember Netfilter is:
PREROUTING
↓
"Where is this packet going?"
Routing decision
↓
+------------------+
| |
v v
INPUT FORWARD
(local host) (through host)
| |
v v
local process POSTROUTING
|
v
network
And for packets generated locally:
Local process
↓
OUTPUT
↓
Routing
↓
POSTROUTING
39. Relation to NAT
The hook ordering explains the basic NAT architecture:
Incoming packet
|
v
PREROUTING
|
| DNAT
v
Routing decision
|
v
FORWARD
|
v
POSTROUTING
|
| SNAT / MASQUERADE
v
Outgoing interface
Therefore:
DNAT → commonly associated with PREROUTING
SNAT → commonly associated with POSTROUTING
This relationship is directly reflected in Purdy's packet-flow and NAT sections.
40. Relation to Stateful Firewalling
Connection tracking adds another component:
Packet
|
v
Netfilter
|
v
Connection tracking
|
v
Connection state
|
v
Firewall rule
|
v
ACCEPT / DROP / ...
For example:
NEW
↓
connection established
↓
ESTABLISHED
↓
additional packets
This allows rules to distinguish packets based on connection state.
Source: Purdy, Connection Tracking, p. 14 and state match.
41. Final Mental Model
Think of Netfilter as a packet-processing framework inside the Linux kernel.
NETFILTER
|
+---------------+---------------+
| | |
HOOKS TABLES STATE
| | |
| | |
PREROUTING filter conntrack
INPUT nat
FORWARD mangle
OUTPUT
POSTROUTING
|
v
CHAINS
|
v
RULES
|
+--+--+
| |
MATCH TARGET
|
+--> ACCEPT
+--> DROP
+--> REJECT
+--> DNAT
+--> SNAT
+--> LOG
+--> ...
The fundamental separation is:
HOOK
=
where packet processing occurs
TABLE
=
what kind of processing is being performed
CHAIN
=
ordered rules associated with a hook
RULE
=
match + target
MATCH
=
does this rule apply?
TARGET
=
what should happen?
42. Sources — Only From the Specified Textbooks
Gregor N. Purdy
Gregor N. Purdy, Linux iptables Pocket Reference, O'Reilly Media, 2004
Primary source for this entire note
-
Introduction, p. 1
-
Netfilter definition
-
iptables definition
-
Layer 3 operation
-
-
Concepts, pp. 2–3
-
tables
-
chains
-
hook points
-
-
Tables, pp. 2–3
-
filter
-
nat
-
mangle
-
-
Chains, pp. 3–4
-
built-in chains
-
user-defined chains
-
chain policy
-
-
Packet flow, pp. 5–7
-
exact hook/table traversal
-
forwarding
-
input
-
output
-
-
Rules, p. 7
-
match criteria
-
targets
-
-
Connection Tracking, p. 14
-
Network Address Translation, pp. 17–20
-
Stateless and Stateful Firewalls, p. 20
The O'Reilly text explicitly describes Netfilter as the Linux kernel's network packet-processing subsystem and iptables as its configuration tool.
The accessible book text gives the exact forwarding packet-flow table:
mangle PREROUTING
nat PREROUTING
mangle FORWARD
filter FORWARD
mangle POSTROUTING
nat POSTROUTING
and explains sequential rule processing within chains.
J. F. Kurose & K. W. Ross
James F. Kurose and Keith W. Ross, Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2020
Relevant supporting source:
- Chapter 4, §4.5 — Middleboxes
This provides the broader networking architecture of firewalls/middleboxes but does not provide the Linux Netfilter hook/table implementation.
The authors' chapter structure identifies §4.5 as Middleboxes.
Wenliang Du
Wenliang Du, Computer & Internet Security: A Hands-on Approach, 2nd ed.
Relevant material:
-
Firewall
-
Netfilter
-
iptables
-
Linux packet filtering
Du's material provides the security/firewall context, while Purdy provides the detailed architecture.
Gordon Lyon — Nmap
Nmap is not used as a source for the Netfilter architecture in these notes, because its relevant material focuses on network discovery, TCP/UDP/ICMP behavior, and packet scanning rather than the Linux Netfilter framework.
James Forshaw
Forshaw is likewise not used as a source for the Netfilter architecture, because Attacking Network Protocols focuses on network protocol analysis and vulnerabilities rather than giving the Linux Netfilter/iptables architecture described by Purdy.
43. Quick Revision
NETFILTER
=========
Linux kernel packet-processing subsystem.
iptables
========
User-space tool used to configure Netfilter.
HOOKS
=====
PREROUTING
INPUT
FORWARD
OUTPUT
POSTROUTING
TABLES
======
filter → packet filtering
nat → network address translation
mangle → packet modification
CHAIN
=====
Ordered sequence of rules.
RULE
====
Match + Target
MATCH
=====
Determines whether rule applies.
TARGET
======
Determines what happens.
PACKET PATH
===========
Incoming
↓
PREROUTING
↓
Routing
├──→ INPUT → Local process
|
└──→ FORWARD → POSTROUTING → Outgoing interface
Local packet
↓
OUTPUT
↓
Routing
↓
POSTROUTING
↓
Outgoing interface
FORWARDING TABLE SEQUENCE
=========================
mangle PREROUTING
nat PREROUTING
mangle FORWARD
filter FORWARD
mangle POSTROUTING
nat POSTROUTING