Your SlideShare is downloading. ×
State Firewall
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

State Firewall


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. IPTables Lab 2: State Firewall Introduction 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 ‘state firewall’. 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 server. 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 examples. 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.
  • 2. 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. Lab Setup 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 specification: 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. Example: 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: #!/bin/sh # Remove any existing rules iptables --flush # 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
  • 3. 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 or • 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)
  • 4. • 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 case. 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. Problems 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 modify later. • 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 • What is the result?
  • 5. Questions/Problems 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 modification?) 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? Questions 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
  • 6. 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: #modprobe ip_conntrack_ftp i) Now, verify that the active mode FTP test works. Questions 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.