IPTables configuration 1.1 2005/08/12 02:02:33 GMT-5 2005/08/12 03:19:27 GMT-5 Pat Shuff pshuff@rice.edu Pat Shuff pshuff@rice.edu firewall IP filtering IP tables security There are a variety of ways to configure a Linux computer to either accept or deny connections from other computers. The IPTables program operates inside the kernel to filter data at the IP protocol layer as well as the UDP and TCP layers. We will look at the configuration files used as well as the different options available to block or allow requests. The iptables binary is integrated with the Linux kernel to do packet filtering and blocking. The code that comes with the 2.4 and greater kernel supports the packet filtering software such that the undesired data never gets to the user level applications. There is a command line component that takes user parameters and routes them into the kernel to configure how the operating system deals with data packets arriving from the network interface. Source code for this filtering software can be found at http://netfilter.org Let's follow a packet into our computer and see how the iptable program interacts with the packet. When an IP datagram comes into the computer the destination header is inspected and the packet is either dropped, accepted by the kernel since we are the destination, or routed to another computer. Typically , routing is not done these days by a Linux computer but done by dedicated hardware designed specifically to do routing. When the packet is accepted by the kernel it is made available to applications running on the operating system as data streams from another computer. If the packet destination is our computer, we then take the packet and pass it through the iptable device driver. If the iptable driver is configured to accept data from the source computer on the receiving port, the data packet is dropped into kernel buffers. If the iptable program is configured to block data either from the source computer or on the port that it was received, it drops the data as if were never sent. We configure the iptable driver through the iptable command line. The iptable command requires root privileges to execute because it reconfigures the rule sets that are stored in the device driver. Let's look at a very simple example. We want to allow someone to ping our computer. The ping protocol is neither TCP nor UDP, it is ICMP. If we define a filter to accept any inputs from any computer for ping actions, we can see the ping operate. We would need to type iptables -A INPUT -s 127.0.0.1 -p icmp -j ACCEPT The basic actions of this command are to define an input rule that looks at traffic coming from 127.0.0.1 using the ICMP protocol and accepts the request. Let's break the command down. The -A option appends rules for the chain of rules that will be used for filtering. In this example, the INPUT chain is the one that we are appending to. The -s option defines the IP address that we are looking at. In this instance it is 127.0.0.1. The -p option defines the protocol that will be filtered. In this case it is the ICMP protocol since we want ping to work. The -j option defines the routing action. By following this with ACCEPT we tell the iptable kernel module to pass these requests to any user level application that is listening for ICMP requests. We should be able to perform the ping command and see the ping answered. To turn off the ping, we use the following command iptables -D INPUT -s 127.0.0.1 -p icmp -j DROP The -D option says drop the command, not append. The -j DROP command tells the kernel to drop the packet and not let anyone see the data. Note that we could have used the -A option to append this rule to the previous rule that we had defined. This might lead to some confusion to someone looking at the rule sets. Fortunately, the device driver is programmed to take the last rule and treat it as the arbitrator. If rule one says to accept the packet and rule two says to drop the packet, we will drop the packet. If the rules were reversed we would accept the packet. It is much easier to delete the rules when we want to override something previously configured. To list all of the rules defined we simply use the -L option for iptables and it generates an output of all rules defined. The -s and -d options define source and destination addresses. The address that follows the options can be dns names, ip addresses, or netmasks. If, for example, we type -s 10.5.5.10, this says that we will define a rule for data coming from this and only this machine. If we type -s 10.5.5.0/255.255.255.0, this says that we will define a rule for data coming from IP addresses 10.5.5.0 through 10.5.5.255 inclusive. We can specify the same by typing 10.5.5.0/24. The /24 at the end says that we will only look at the first 24 bits of the address and treat the remaining 8 bits as a wildcard. This will address the same range as the previous example. It is important to note that the /24 option will restrict us to 256 computers that are configured on the same subnet as our computer. If we wanted to restrict the source to something that was on our campus we would need to use the /16 option. This says that the first two digits in the ip address uniquely identify all computers at our university. Smaller schools or organizations will need to use something between 16 and 24 as the masking bits to restrict access based on source address. The protocols that we typically deal with are the TCP, UDP, and ICMP protocols. We define this with the -p or --protocol flag. We can put an exclimation point (!) in front of the protocol that says that the rule applies to everything but this protocol. For example, if we use -p !TCP, this says that we apply the rule to all protocols except TCP. # iptables -D INPUT -s 127.0.0.1 -p icmp -j ACCEPT # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.2 ms # iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes --- 127.0.0.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss