11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

Stateful Packet Filtering Firewall with Iptables

Lecture Notes (c) 2006 Prof. Wayne Pollock, Tampa FL USA
iptables a.k.a. netfilter examines incoming and outgoing packets
at various points. It does this by matching each packet against a chain
of rules. Each rule contains matching criteria and a target which says
what to do with a packet that matched the criteria. A chain of rules is
a list. Packets are matched against each rule in a chain, in order, until
a match occurs. Then the target of that rule is used (generally) to
accept or to drop the packet. However the target may cause the
packet’s header fields to be changed, to log the packet, or do another
action. If no rule matches some packet then a default policy is used to
decide what to do.
Iptables is a stateful packet filter, in that it keeps track of connections,
statistics, and packet flows. Even UDP packets can be tracked (e.g., a
DNS query and the response). All that information may be used in the
criteria to match packets, or to produce reports. Note that connections
have a timeout value, so iptables may “forget” some long idle
connection and begin dropping packets.
Originally packet filters were stateless, and had to decide what to do
with a packet only by examining that packet’s layer 3 (IP, ICMP) and
4 (TCP, UDP) headers. Soon the black-hats were tweaking and faking
the various flags and fields in the headers to by-pass the packet filter.
The most common attacks were to turn off the SYN bit in a TCP
packet so the firewall would think the packet was part of an
established session and allow it through.
Non-Linux systems today often have similar packet filter firewalls,
which use similar concepts to iptables. (ipf a.k.a. ipfilter on
Solaris, the Solaris default location for the firewall rules file is
/etc/ipf/ipf.conf. For BSD the packet filter is called pf, and
the command to use it is pfctl. To enable add “pf=YES” to
/etc/rc.conf.local. The rules go in /etc/pf.conf.)
One problem today is that many applications use the same port
number (e.g., MS with SMB on ports 137 and 139). So you can’t
filter traffic just by examining packet headers, you need to examine
the application layer (layer 7) headers too. This is the only way for
example to see if some packet going to port 80 really contains an

https://wpollock.com/AUnixSec/IptablesOverview.htm 1/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

HTTP request, or is some stealth IM or file transfer packet. Some

commercial packet filter firewall devices can examine layer 7 data and
use that to decide to accept or drop the packet.
A more common solution is to use transparent application proxy
servers, which receive the supposed HTTP packet, and forwards it if it
really is an HTTP packet.
IP Accounting Besides packet filtering iptables collects statistics on byte
and packet counts for each rule. This is called accounting.
Iptables can also be used for NAT (including masquerading and port
forwarding), packet mangling (modifying bits of the headers), and
load balancing.
Chains
There are five built-in chains, one for each point in the kernel’s
processing path:

The chain determines when a packet is examined. An incoming

packet (from the outside to this host) arrive at a NIC and will be
processed only by the rules on the prerouting and input chains.
Outgoing packets (from this host to another) will use the output and
postrouting chains only.
When the host acts as a router it will forward some packets (from one
interface to another). These will traverse only the prerouting,
forward, and postrouting chains.
Some (or all) of these chains may be empty. You can set a default
policy for this standard chains.
You can also define new chains. Such chains may be the targets of
rules in other chains. Defining your own chains may be useful in a
couple of situations.

https://wpollock.com/AUnixSec/IptablesOverview.htm 2/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

If you have a set of rules that need to be part of several chains, it is

handy to be able to define it once. Then you add a rule to each of the
built-in chains with no criteria, with a target of the new chain.
Commonly, both the input and forward chains (of the filter table)
have similar rules for dropping packets. So you create a new chain
“rulz” or some other name, add the rules to that, and use it from both
the input and forward chains.
Matching packets against a lot of rules can take time, thus increasing
the latency of the packets and lowering throughput. Using a user-
defined chain can help with this. Suppose it takes six (or more!) rules
to determine what to do with incoming packets going to some
particular server. Rather than add all the rules to the input chain, and
thus force all incoming packets to be matched against them, you can
put them in a new chain, and add a single rule to the input chain that
only matches the destination IP address of the server in question, and
uses the new chain as the target. (Illustrate!)
Note that ordering the rules in a chain carefully can also affect
performance.
Tables
iptables also organizes rules into four tables. A rule’s table
determines what targets are valid for that rule, as well as to which
built-in chains the rule can be added. Note some targets (e.g.,
ACCEPT, DROP) can be used in all tables.
There is a table for filtering the packets (the “filter” table) which
can have only rules in the INPUT, OUTPUT, and FORWARD chains.
Rules in this table don’t alter the packet in any way.
There is a table for NAT (the “nat” table) which uses the chains
PREROUTING (for altering packets as soon as they come in),
OUTPUT (for altering locally-generated packets before routing), and
POSTROUTING (for altering packets as they are about to go out).
Rules in this table are used to alter the source/destination IP address
(and possibly port numbers) in a consistent way.
There is also a mangle table and a raw table that allow rules with
targets that do other things to packets, such as re-routing them or
changing header values (such as the QoS field).
The rules in a chain are processed in an order determined by the table.
You can think of each table as having its own set of built-in chains.

https://wpollock.com/AUnixSec/IptablesOverview.htm 3/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

The following table shows the order of processing for each of the four
possible packet flows. For example consider what happens to an
incoming packet. First the mangle then the nat table rules in the
PREROUTING chain are used, then the mangle table rules in the
INPUT chain, and finally the filter table rules in the INPUT
chain.

Flow Type Table Chain

mangle PREROUTING
nat PREROUTING
incoming mangle INPUT
filter INPUT
mangle OUTPUT
nat OUTPUT
outgoing filter OUTPUT
mangle POSTROUTING
nat POSTROUTING
mangle PREROUTING
nat PREROUTING
mangle FORWARD
forwarding
filter FORWARD
mangle POSTROUTING
nat POSTROUTING
mangle OUTPUT
nat OUTPUT
socket
filter OUTPUT
(process-to-process)
filter INPUT
mangle INPUT

https://wpollock.com/AUnixSec/IptablesOverview.htm 4/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

Use the “-t table” option to specify which table to use when
adding/removing a rule. If this option is omitted then the filter
table is used by default.
Rules and match criteria
A rule is zero or more matching criteria and one (optional) target. A
rule is added to a specific table and chain. A rule with no criteria
matches all packets.
A rule with no target does nothing; processing will continue with the
next rule on the chain. Such a rule may be useful for accounting
purposes. Iptables keeps a byte and a packet count for each rule, that
is updated whenever a packet matches the rule’s criteria. So, to count
all incoming packets on interface eth0:
iptables -A INPUT -i eth0
By default iptables can use criteria that match IPv4 layers 3 and 4
headers:
-d [!] destination address[/mask] -s [!] source
address[/mask]
-i [!] input interface -o [!] output
interface
-p [!] protocol [!] -f
Here’s an example: iptables -t filter -A INPUT -i lo -
j ACCEPT
A “!” means “not”. For most values either numbers or names can be
given: port numbers or service names, IP addresses or DNS name,
protocol number or name, and even interfaces can be given names.
Most criteria have other names: ‑s = ‑‑source = ‑‑src. When
omitted the default is to match on all (i.e., no “-p” is the same as “-
p all”). Note it is a bad idea to use a DNS name that would cause a
remote DNS query!
The “-f” matches fragments (all but the first frame of a fragmented
IP packet).
For interfaces you can follow the name with a “+” to indicate all
interfaces that start with that name (e.g., “ppp+”, “eth+”).
To use additional criteria a match extension must be used. Each match
extension provides a set of extra criteria you can add to the rule. You

https://wpollock.com/AUnixSec/IptablesOverview.htm 5/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

specify which match extensions you want to use using the “-m
extension_name”, followed by the criteria that extension enables.
A few match extensions are loaded automatically if you use the
corresponding protocol in the rule: tcp, udp, and icmp. The first
two allow “--dport num” and “--sport num” to specify source
and destination port numbers (and ranges). The icmp match
extension allows “--icmp-type type”. (And others too.)
To see which criteria an extension provides, use:
iptables -m extension_name --help
Some match extensions will cause the kernel to load additional
loadable kernel modules.
The iptables man page lists all the match extensions available. One
special match extension is “arp”, which enables layer 2 match
criteria. A very useful match extension is “state”, which can be
used to see if a packet is part of an existing session (or flow):
iptables -A INPUT -m state --state ESTABLISHED -
j ACCEPT
Targets
The target of a rule determines what to do with a packet that matched
the criteria. You specify the target with the “-j target” option.
For example:
iptables -A INPUT -i eth0 -p tcp --dport 23 -
j DROP
says to DROP (discard and ignore) any packets that match the criteria:
incoming, from network interface eth0, to TCP port 23 (telnet).
There are only four built-in targets, however additional target
extensions can be used. The standard distribution includes many
target extensions. Some targets are only valid in chains in a particular
table. (For example the NAT targets are only valid in the nat table.)
Target extensions (especially those that modify the packet) allow
additional commands. For example:
iptables -t mangle -A PREROUTING -p tcp --
dport 80 \
-j MARK --set-mark 3

https://wpollock.com/AUnixSec/IptablesOverview.htm 6/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

To see what additional commands a target extension allows, use:

iptables -j target --help
As with match extensions, some target extensions will cause the
kernel to load additional modules.
Some of the more commonly used targets are (the first 3 are built-in
targets):
ACCEPT obvious
DROP obvious
RETURN This is the default target at the end of a user-
defined chain. It means to return to the next rule in
the parent chain.
REJECT Discard the packet, but send an ICMP message
back to the source. Useful when the source in in
your AS but don’t use when source is the Internet!
Use DROP instead.
LOG Use to log the packet to the kernel logger (dmesg,
syslog). This target is special in that it doesn’t
terminate the packet processing.
MARK Used with the iproute2 and the tc command for
advanced routing and traffic shaping.
DNAT Used to configure transparent proxy.
SNAT Used for IP Masquerade when the source has a
static IP address. It specifies that the source
address of the packet should be modified (and all
future packets in this connection will also be
mangled).
MASQUERADE Used for IP Masquerade when the source has a
dynamic IP address.
chain Send the packet to another chain for further
processing. If that chain’s rules fail to match the
packet, then processing will continue with the next
rule in the current chain. (See also RETURN
target.)

https://wpollock.com/AUnixSec/IptablesOverview.htm 7/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

Using iptables
To add or remove rules from chains you specify the table (default is
filter) and the chain. For example, to append a new rule to the
end of the OUTPUT chain of the nat table:
iptables -t nat -A OUTPUT criteria -j
action
You can insert rules in any position in the chain by using “-I” instead
of “-A”.
To delete a rule use: iptables -D chain {rule|rule-
num}
To delete all rules use: iptables ‑F [chain]
Create a new chain with: iptables [-t table] -N name.
Delete all user-defined chains: iptables -X [chain]
List [all] rules [no DNS]: iptables [-v] [-n] -L.
Reset per-rule packet and byte counters: iptables -Z
[chain]
You can set the default policy for a built-in chain with:
iptable -P chain {ACCEPT|DROP}
User-defined chains don’t have default policies but you can just put a
reject/drop everything rule at the end for the same effect.
The best way to work with complex sets of rules is to edit the file
where your OS stores the rules (in the “iptables-save” format),
then simply restart iptables. On Red Hat systems this is
/etc/sysconfig/iptables. If there is no such file (on other
systems) then save the rules as a shell script that you can run at boot
time.
When building a firewall you can use the iptables command to modify
the currently loaded (in RAM) rules. These take effect immediately.
Once you’ve added and tweaked the rules to the point that they work,
you can save the current rules to a file with iptables-save. The
result can be used as input to iptables-restore. You can see
this in the file /etc/sysconfig/iptables, which is where RH
stores the firewall rules.

https://wpollock.com/AUnixSec/IptablesOverview.htm 8/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

Filtering Basics [Adapted from “Linux firewalls” 3rd Ed., by Suehring and
Ziegler,
(C)2006 by Peason Ed.]
Start by deleting all user defined chains, and clearing all rules from
the five built in chains. Next add a default policy of DROP to the
INPUT, OUTPUT, and FORWARD chains. (The other two chains
don’t need to drop packets, so you can leave the default-default policy
of ACCEPT for them.)
If you stop here you are safe! But it will pay to add some holes in this
firewall. At this point is is a good idea to check that all kernel level
network protections have been enabled.
A very common situation to to allow the same packets into this host as
you will allow your host to forward, when acting as a router. If not
routing you can just add filter table rules to the INPUT and OUTPUT
chains. If routing, you will usually want the same rules for the INPUT
and FORWARD chains. The way to deal with this is to create a new
user-defined chain, say “MYRULZ”, and all the common rules to this
chain. Then you only have this for INPUT and FORWARD:
-A INPUT -j MYRULZ
-A FORWARD -j MYRULZ
It is usually safe and useful to accept packets from your loopback
interface. These can only have been sent from programs on your host,
to other programs on your host. So add this (if using routing, add to
MYRULZ instead):
-A INPUT -i lo -j ACCEPT
Next we want to allow some outside packets to get through. To start
with we want to allow return packets from our outgoing connections.
This generally means to allow incoming packes that are part of some
established conversation. (TCP or UDP). However you may also
want to allow related packets, if using FTP (FTP establishes an
outgoing connection, then the remote server initiates another using a
different port. This is related to but not part of the established
conversation.)
-A INPUT -m state --state ESTABLISHED,RELATED -
j ACCEPT
Some packets are obviously fake and should never be allowed, no
matter what holes you decide to add. You should drop any incoming

https://wpollock.com/AUnixSec/IptablesOverview.htm 9/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

packets from a NIC with the following source addresses (See RFC-
3330 list of special IPv4 addresses):
You host’s IP address assigned to that NIC.
Any address from one of your internal LANs (that is attached to a
different NIC)
Class A, B, C private addresses: 10.0.0.0 - 10.255.255.255, 172.16.0.0
- 172.31.255.255, 192.168.0.0 - 192.168.255.255.
Class D (multicast) addresses (these are legal destinations only, never
sources): 224.0.0.0 - 239.255.255.255
Class E (reserved) addresses: 240.0.0.0 - 247.255.255.255
Higher addresses are not used legally: 248.0.0.0 - 255.255.255.255
Looback addresses: 127.0.0.0 - 127.255.255.255
Illegal source broadcast addresses. While some broadcase source
addresses are legal on a single LAN (e.g., 0.0.0.0 for a DHCP
requests) you will never see any broadcast address from the Internet,
or as a regular non-broadcast packet. So in many cases you can filter
out any source of 0.0.0.0 - 0.255.255.255, and also 255.255.255.255.
Link-local addresses are reserved for zeroconf addressing and are
private on a given lan, if used at all. So these addresses are not vald
sources from other networks: 169.254.0.0 - 169.254.255.255
192.0.2.0/24 block is reserved for TEST-NET, to be used in examples
and documentation.
192.88.99.0/24 - This block is allocated for use as 6to4 relay anycast
addresses, according to [RFC3068]. So if you don’t use IPv6 then
you shouldn’t see these.
198.18.0.0/15 - This block has been allocated for use in benchmark
tests of network interconnect devices. Its use is documented in
[RFC2544].
Any unallocation addresses. You can check IANA and the various
RARs (e.g., ARIN) to see which blocks are currently unassigned. No
legal packet should have such a source address. But be careful! New
allocations are made all the time so you would have to carefully
monitor those and frequently update your firewall. (I don’t know of
any site that provides you will alerts on this, but it would be a good
idea!)

https://wpollock.com/AUnixSec/IptablesOverview.htm 10/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

Any known problem networks/hosts. You can simply drop all packes
that come from problem sites, provided those sites aren’t also used for
legitimate purposes. A business must balance the extra security
against lost of customers. (An alterniative is to rate limit packets from
those sites.)
Limiting Sources and Services
In many cases you can limit some types of traffic to only be legal
from a small number of source IPs.. For example SSH (port 22)
access to a production server should only be allowed from a few
places: inside the company LAN, and perhaps a few remote sites that
have administrative access.
You can also drop traffic based on source port. Legitimate packets for
services such as mail or web will have a source port in the
unregistered (dynamic or private) range of 49152 through 65535.
While there may be exceptions you will need to allow (e.g., SMB) in
general source ports in the range 0 to 49151 (and especially the well-
known ports of 0 to 1023.
At this point is is just a matter of adding rules for the holes you with
to allow. For example to allow access to a web service (port 80):
-A INPUT -m state --state NEW -p tcp --dport 80 -
j ACCEPT
Don’t forget to allow related ports, such as DNS, IPP, MTA, POP,
HTTPS, etc.
In the end you may wish to add a rule to drop the packets. The
purpose is to be able to see the accounting statistics on packets
dropped. To troubleshoot your system you may also add LOG rules.
(Show log from yborstudent.)
Egress Filtering
Many sites assume no local evil users or security problems and simply
allow any outgoing packet (set the policy on the OUTPUT chain to
ACCEPT and add no rules).
A better approach it to limit outgoing packets to ones with a correct
source IP address (and source port), and that are part of an established
session. A production server will rarely if ever initiate out-going
connections, it should just respond to incoming ones. (There are
exceptions, e.g. a mail server using a real-time black list or an FTP

https://wpollock.com/AUnixSec/IptablesOverview.htm 11/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

server.) If you do allow out-going sessions then limit where they go by

destination port (i.e., only allow the MTA to connect to the RTBL-DNS
at sbl‑xbl.spamhaus.org, or SSH to specific servers.)
Filtering examples and gotchas
When you have multiple NICs the system may not detect them in the
same order every time. So “eth0” and “eth1” may be different. Try to
give your NICs better (stable) names (like INTERNET or DMZ or
PRIVATE-LAN, and use those names in iptables rules.
To allow remote X window GUI access can be dangerous. ssh can
be used to provide a more secure tunnel for X, POP/ IMAP, etc. To
allow remote X for the local LAN only is still dangerous (because a
black hat may spoof the IP address of some server on your LAN and
open windows on your server or do other more nasty things). X
sessions start at port 6000 (for session 0), 6001, (for IP:1), etc.
Blocking all ports from 6000 – 6009 is often done to stop X but
unfortunately this range overlaps other registered services, so you
must be careful. You might allow access to ports 6000 – 6004 to
localhost (or the local LAN) only.
There was a posting about preventing SSH dictionary attacks on
SlashDot, and several people posted iptables methods of dealing
with this, using the “recent” rule.
“Rundown on SSH Brute Force Attacks” at
http://it.slashdot.org/article.pl?sid=05/07/16/1615233 This is what
was posted (there was a more complicated one that allowed for ssh IP
white-listing too):
-A PREROUTING -p tcp -d $EXTERNAL --dport 22 -m recent --
rcheck \
--hitcount 3 --seconds 600 -j LOG --log-prefix "SSH attack: "
-A PREROUTING -p tcp -d $EXTERNAL --dport 22 -m recent --
rcheck \
--hitcount 3 --seconds 600 -j DROP
-A PREROUTING -p tcp -d $EXTERNAL --dport 22 -m recent --set \
-j DNAT --to-destination $INTERNAL:22 # ???
-A OUTPUT -p tcp -d $EXTERNAL --dport 22 -j DNAT \
--to-destination $INTERNAL:22 # ???
A simpler approach is to use the limit match extension. The
following lines block SSH connections from the beginning:

https://wpollock.com/AUnixSec/IptablesOverview.htm 12/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state \

--state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m
limit \
--limit 5/min -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j DROP
With these three rules, incoming SSH connections are limited to five,
established connections are unaffected and otherwise the packets are
dropped.
The hashlimit match extension (run "iptables -m hashlimit
--help" for more information on it) allows you to rate-limit traffic
with unique limits based on source IP address (among other things).
For example:
# iptables -A INPUT -m hashlimit -p tcp --dport 22 --hashlimit 1/min \
--hashlimit-mode srcip --hashlimit-name ssh -m state --state NEW -j
ACCEPT
# iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP
# cat /proc/net/ipt_hashlimit/ssh
9 64.12.26.80:0->0.0.0.0:0 9600000 9600000 1920000
9 127.0.0.1:0->0.0.0.0:0 259392 9600000 1920000
Transparent HTTP Proxy Example
This last example comes from the Transparent Proxy with Linux and
Squid How‑to, from the Linux Documentation Project. Here we have
a Linux box used as a router, with eth0 connected to the “outside-
net” (Parameter) network (i.e., the connection to your ISP and the
Internet), eth1 connected to the “inside-net” network. (Aside:
networks can be assigned names in /etc/networks.) The IP
address of eth1 is “router-inside”.
In the inside-net is the squid proxy server, with IP address of “squid-
server”. It listens for traffic on port 3128.
On the router you need these commands:
iptables -t mangle -A PREROUTING -p tcp --dport 80 -s squid-server -
j ACCEPT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-
mark 3

https://wpollock.com/AUnixSec/IptablesOverview.htm 13/14
11/8/23, 12:11 AM Stateful Packet Filtering Firewall with Iptables

ip rule add fwmark 3 table 2

ip route add default via squid-box dev eth1 table 2
Note that the choice of firewall mark (3) and routing table (2) was
arbitrary. If you are already using policy routing or firewall marking
for some other purpose, make sure you choose different numbers here.
The first rule tells the router to accept TCP packets going to port 80 of
the squid server. The second rule marks all incoming TCP packets to
port 80 except those going to the squid server. The order of these two
rules is significant and a common source of error and confusion.
The last two commands set up a routing policy for marked packets.
The first thing we do is to select the packets we want. Thus, all
packets to port 80, except those coming from squid-server itself, are
MARKed. Then, when the kernel goes to make a routing decision the
MARKed packets aren’t routing using the normal routing table that
you access with the “route” command, but with a special table.
Together these commands route all marked packets to the squid server.
Next the squid-server needs one rule:
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 \
-j REDIRECT --to-port 3128
This rule uses DNAT (destination NAT) to change the destination port
number of TCP packets arriving in from eth0 (on the squid server,
not the router) to port 3128.
An HTTP proxy such as squid works as follows: A user on a
workstation uses a web browser to visit www.example.com (which
uses port 80 by default). The browser determines the IP address of
www.example.com, creates an HTTP request packet, and sends it
there.
For non-transparent proxying, the browser is configured with the IP
address and port number of the proxy server (in our example squid-
server:3128). Squid reads the HTTP headers to determine the real
destination IP. It then sends the HTTP request, caches the reply, and
finally returns the HTTP reply to the original workstation.
For transparent proxy, no workstations need any special
configuration. Instead you have the router do all the work.

https://wpollock.com/AUnixSec/IptablesOverview.htm 14/14