IPTables Lab 2: State Firewall
This lab will attempt to help illustrate some of the differences between packet
filtering and state filtering. Let’s consider a simple example:
A firewall would like to prevent users on the outside (Internet side) of the
firewall from establishing connections to users on the inside. On the other hand, we
cant just indiscriminately block all packets from any outside source to the inside. This
would imply that inside users could not use the Internet. (If that’s what we want,
why bother to have an Internet connection at all?) Ideally, the firewall will disallow
inbound packets that are not part of an ongoing connection that was established by
an inside machine. A firewall with this type of capability is often referred to as a
There are some simple ways to perform ‘state-like’ filtering. For example, if a
firewall examines the TCP flags, it can determine which packets are part of an
ongoing connection. The SYN flag is set by itself only for the first packet of a TCP
handshake to open a new connection. Therefore, the packet filter can block any
packet that has the TCP SYN flag set (and no others). This will work for web
browsing (allowing the inside user to browse the Internet). However, there are many
other situations that cannot be covered this simply. Let’s take a look at a few:
1) UDP. As you well know, UDP does not have flags. One very necessary UDP
protocol is DNS. Without DNS, the inside user cannot resolve domain names.
The local DNS server must have free communications with the Internet
(allowing incoming requests), so it will be located outside the firewall. The
inside user must be able to send requests and receive replies from this DNS
2) ICMP. This protocol does not use layer 4 at all. Certainly no TCP flags are
associated with it. The inside user needs to be able to receive ICMP error
messages and replies. For example, he should be able to PING Internet IP’s,
and receive ICMP error messages, such as ‘request timed out’.
3) More complex TCP conversations, which involve multiple connections -
some of which must be originated by the remote server. An example of this is
FTP. The user sets up the control connection, but the data connection is most
often set up by the FTP server. This would imply an incoming SYN packet
from the server. More and more applications that require incoming
connections are appearing everyday - applications like chat and voice are
A ‘state’ firewall can easily handle these types of cases, whereas a packet firewall
has more difficulty, and in some cases cannot handle them at all. If you think about
each of these three cases, the question becomes this: “What information in the
packet establishes that packet’s connection to a previous packet?” The key point in
this question is the “… previous packet..” portion. If a firewall is to relate a packet
that it receives to a ‘previous packet’ we are implying that the firewall is keeping a
record of past packets, and can search that record for a particular pattern. When a
firewall maintains this type of information, we say it is maintaining ‘state information’
- information about the state of a connection. This characteristic marks the primary
difference between a packet filtering firewall and a state firewall. A packet filtering
firewall makes decisions based solely on the contents of the packet just received. A
state firewall makes decisions based on a packet’s contents as well as information
contained in a ‘state table’. Obviously, the packet filter takes less resources (memory
and CPU time) than the state firewall. Most routers can also serve as a packet filter.
Another thing that most state firewalls are capable of is looking ‘deeper’ into
the packet. Most packet filters look at layers 3 and 4. State firewalls are typically
capable of looking into the application (or upper) layers. In many cases it is the only
way to determine if an incoming packet is part of an ongoing conversation.
In this lab we will take at look at an example of each of these cases and
restrict ourselves to packet filtering. Then we will take a look at the built-in state
capabilities of iptables.
For this lab, each student should continue to work independently on their own
iptables. Use Inside1 and Inside2 machines for your iptables, and use your Outside
machine as you testing machine. You will need Outside to be booted with Windows.
All of your machines will need to be set up with real addresses, and able to
access the Internet. Use the real IP’s that are assigned to your Island. Before turning
on your uplink, be sure to apply the necessary Service Pack and Worm fixes to the
windows2k machine. (Mark your drive to indicate it has been patched.)
1. The SYN Flag
In this exercise we will see how iptables allows you to filter based on specific flags in
the TCP header. We will use this capability to allow outgoing connections, allow the
return of associated packets, but prohibit incoming connection requests.
The format for matching particular flags assumes (of course) that you have specified
the TCP protocol. The flag match option is an extension of the TCP protocol
iptables -A INPUT -p tcp --tcp-flags <mask> <comp>
Where <mask> is a comma-separated list of the flags to be checked, and <comp> is
a comma-separated list of the ones that should be set.
iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN SYN
In this example, the SYN, ACK, and FIN flags are to be checked, and only the SYN
flag should be set; ACK and FIN should not be set.
Note: Be sure that the comma-delimited list does not contain any spaces.
You can also use the exclamation point (!) to indicate NOT for any flag. For example,
you might refer to !SYN, to mean that the SYN flag should NOT be set (ie: cleared).
a) Check to make sure your current iptables script listing looks like this:
# Remove any existing rules
# Set up the default policy for each of the chains
iptables --policy INPUT DROP
iptables --policy OUTPUT ACCEPT
iptables --policy FORWARD ACCEPT
# Allow loopback communications
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
b) Copy this script to a new file called lab2. We will edit the new file during this lab
so you can retain a copy of lab 1’s script.
c) At this point, we are blocking all incoming packets, no matter if they are part of an
ongoing connection or not.
• Which rule(s) in the list above will block all incoming packets?
d) Let’s now write a rule to accept incoming packets where are part of an existing
connection. If the connection is ongoing, the ACK flag must be set:
iptables -A INPUT -p tcp --tcp-flags ACK ACK -j ACCEPT
Add this line to the end of your new script file. Save it and run the script.
e) Now, open the browser on the machine. Enter the IP address for google. (You will
need to use your third machine to resolve it, since the iptables machine will not be
able to access the DNS server.)
• Did it work?
f) Try entering the url www.google.com or www.yahoo.com.
• Does that work?
• Why not?
g) Try to telnet to your windows machine QoD service (port 17)
• What is the result?
h) Try to connect to the windows ftp server (you may need to start it). Also, put a
file in the default FTP directory. Log on as anonymous.
• Did it work?
i) Do a directory listing. (dir).
• Did it work?
j) Exit the PASSIVE mode and enter the ACTIVE mode. (type ‘passive’).
Do a directory listing again.
• Did it work?
• Explain why?
k) Try pinging the windows machine.
• What is the result?
• Explain why?
Let’s take a look at each of these issues one at a time….
2. Getting PING Responses Back
a) In order to allow the PING responses to get through the firewall, we must set up a
rule that allows them. For any rule, consider the following minimum:
• Which chain? (INPUT, OUTPUT, FORWARD)
• Which protocol? (TCP, UDP, ICMP, IP)
• Protocol details - such as flags, sub-types, etc.
• Source and/or Destination IP/hostname
• Source and/or Destination Port (when applicable)
• Whether to ACCEPT or DROP.
So, lets return to our problem of allowing ping replies back in.
• Which chain? INPUT of course - these are incoming packets
• WHICH protocol? ICMP
• Protocol sub-type? echo-reply
• Source and/or Destination IP? we want to let any IP respond.
• Ports? no ports with icmp
• Accept or Drop? Our default INPUT rule is to drop.. we need to accept in this
b) Now let’s write the rule:
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
(To see a list of the icmp types, from the command line, type ‘iptables -p icmp -h’)
c) Next question is, “where do we put the rule?” Rule placement is very important.
For example, if we had a rule that DROPped all icmp packets, like the following:
iptables -A INPUT -p icmp -j DROP
then it would do no good to place the new rule we just wrote after that rule, because
it would never be ‘seen’. In our case right now, we just need to place the rule
somewhere after the policy settings. So add it to the end of your rule set.
d) Try to ping your windows machine again.
• Does it work now?
• Can the windows machine ping you? Explain why.
1. Write a rule and place it in your list that would enable the windows box to ping
your firewall. First, make the rule general, so that any machine can ping you. Then
modify the rule to allow only the windows machine to ping you.
3. Getting DNS Replies Back
a) Let’s see if we can take care of name resolution. Follow the same technique for
designing the rule:
• Which chain? INPUT again, of course
• WHICH protocol? UDP
• Protocol sub-type? DNS - will be covered by the port number
• Source and/or Destination IP? We will start with any DNS server respond and
• Ports? Source port is 53 (DNS Server). Destination port will vary (ephemeral)
• Accept or Drop? ACCEPT, obviously.
b) Write the rule:
iptables -A INPUT -p udp --sport 53 -j ACCEPT
c) What position in our list? Doesn’t really matter, since we have no other rules that
apply to UDP. Add it to the end of our list and re-run the script.
d) Now, try to ping a machine using its domain name (like ping www.yahoo.com).
• What is the result?
2. Write the modified rule to allow only your DNS server to respond to you.
Why would this matter? (ie: what could a potential hacker do if you didn’t make this
4. Getting the ACTIVE FTP to Work
This problem takes a little more thought. This rule will have to be an exception to our
ACK ACK rule that we wrote to disallow incoming connections. Remember, in ACTIVE
FTP the server will be attempting to set up the data connection, so it will first send a
packet with just the SYN flag set (no ACK flag).
a) Design the rule
• Which chain? INPUT
• WHICH protocol? TCP
• Flags? SYN only. After that, our other rule will take care of the packets, since
they will all have ACK flag set after the first one.
• Source and/or Destination IP? For now, lets allow any
• Ports? Port 20 for source. Destination port will vary.
• Accept or Drop? Accept
b) Write the rule
iptables -A INPUT -p tcp --tcp-flags SYN SYN --sport 20 -j ACCEPT
c) The position of this rule is very critical. Since it is an exception to the ACK ACK
rule, it must appear in the list before that rule. Enter the rule in the appropriate
place, save script and re-run.
d) Now, from your firewall machine, ftp to the windows box and turn off passive
mode. Then perform a directory listing.
• Did it work this time?
3. What all is ‘allowed’ to pass through the firewall beyond exactly what we want? Ie:
if we include this FTP rule, how could a potential hacker use it?
5. State Firewall with iptables
One of the big improvements iptables offered over ipchains was the addition of ‘state
firewall’ capabilities. The rules we have been adding in this lab all relate to the kind
of operation that can take place automatically when a firewall maintains state. In this
exercise we will look the state capabilities of iptables.
a) First, comment out the new lines you have added so far this lab. Also, change
your OUTPUT chain policy to DROP. Rerun you script and insure that you cannot ping
out, or do name resolution, etc.
b) Now, list the iptables modules.
• What modules are currently installed that pertain to iptables?
c) Next, add the following line two lines:
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
d) Save and re-run your script.
g) You should have found that one of the tests did not work - active mode FTP. Load
the ftp connection-tracking module:
i) Now, verify that the active mode FTP test works.
4. What is the response from a machine that receives an unsolicited SYN ACK
packet? In other words, can we start a connection by slipping a SYN packet through
if we also set the ACK flag?
5. How and where does iptables maintain its connection table? Run some tests
showing the contents of the ip_conntrack table and explain what the entries mean.
Show a half-open tcp connection and then a fully-opened connection.