French | Spanish | Portuguese | Italian | German | Japanese | Chinese | Korean | Russian | Arabic

The two things needed to build firewalls and Quality of Service (QoS) with Linux are two packages named netfilter and iproute. While netfilter is a packet filtering framework included in the Linux kernels 2.4 and 2.6, iproute is a package containing a few utilities that allow Linux users to do advanced routing and traffic shaping.
This article is intended to introduce the tools we will use throughout this article. However, netfilter and iproute are very large subjects; so what I'll try to do in this article is to introduce readers who are not familiar with the subject, along with building a nice overview for readers who already know the subject. There are two websites with a lot of documentation on both projects for netfilter, http://www.netfilter.org, and for iproute, http://www.lartc.org.

netfilter/iptables

netfilter is a very important part of the Linux kernel in terms of security, packet mangling, and manipulation. The front end for netfilter is iptables, which "tells" the kernel what the user wants to do with the IP packets arriving into, passing through, or leaving the Linux box.
The most used features of netfilter are packet filtering and network address translation, but there are a lot of other things that we can do with netfilter, such as packet mangling Layer 7 filtering.
A rough explanation on how netfilter works is like this:

• The user instructs the kernel about what it needs to do with the IP packets that flow through the Linux box using the iptables tool.
• The Linux box then analyzes the IP headers on all packets flowing through it.
• If, when looking at the IP headers, the kernel finds matching rules, then the packet is manipulated according to the matching rule.

It might look very simple at the beginning, but actually is a lot more complicated process. netfilter has a few tables, each containing a default set of rules, which are called chains. The default table loaded into the kernel is the filter table, which contains three chains:

• INPUT: Contains rules for packets destined to the Linux machine itself.
• FORWARD: Contains rules for packets that the Linux machine routes to another IP address.
• OUTPUT: Contains rules for packets generated by the Linux machine.

Next, the packets flow through the pre-routing chain of the nat table, where we can do DNAT, port redirection, etc.
It is only logical to be able to perform destination network address translation before the routing process occurs. As you will see in Article 4, where we discuss DNAT in more detail, DNAT is the process of translating one (usually public) IP address into another (usually private). This is done by modifying the destination IP address in the IP packet's header. netfilter must do that before the kernel makes a routing decision so that the kernel will look for the new destination IP address in the IP packet.
After passing through the two chains, the Linux kernel makes a routing decision. This is not the netfilter's job. By analyzing the destination IP address from the IP packet header, the Linux box knows if the packet needs to be routed elsewhere or it was destined for it.
If the Linux box is the destination for the IP packet, the packet goes through the mangle table's INPUT chain for packet mangling. Afterwards, the packet is passed to the filter table INPUT chain, where it can be accepted, rejected, or dropped. If the packet is accepted (e.g. a request to a web server running on our Linux box), the Linux box generates a response to that packet, which goes through the mangle table OUPUT chain first.
Next, the packet is passed through the nat table OUTPUT chain and the filter table OUTPUT chain. At this point, the mangle table POSTROUTING chain and the nat table POSTROUTING chain are analyzed and the packet is ready to be sent out on the corresponding interface.
The chains presented here are the predefined chains of each table (filter, nat, and mangle). However, users can set up custom chains with custom names, and pass packets to those chains from the corresponding predefined chain. For example, if we want to create some rules for SSH access into the Linux box, we can create a custom chain named SSH, and insert one rule in the INPUT chain that instructs the kernel to analyze the SSH chain for incoming packets on port 22/TCP.
The predefined chains cannot be deleted or renamed.

Iptables — Operations

iptables has a syntax somewhat similar to the old ipchains (netfilter for 2.2 kernels). However, the concepts of netfilter for 2.4+ kernels are totally different from netfilters' concepts for 2.2 kernels.
The operations iptables can do with chains are:

• List the rules in a chain (iptables –L CHAIN).
• Change the policy of a chain (iptables –P CHAIN ACCEPT).
• Create a new chain (iptables –N CHAIN).
• Flush a chain; delete all rules (iptables –F CHAIN).
• Delete a chain (iptables –D CHAIN), only if the chain is empty.
• Zero counters in a chain (iptables –Z CHAIN). Every rule in every chain keeps a counter of the number of packets and bytes it matched. This command resets those counters.

For the –L, –F, –D, and –Z operations, if the chain name is not specified, the operation is applied to the entire table, which if not specified is by default the filter table.
To specify the table on which we do operations, we must use the –t switch like so iptables –t filter …

Operations that iptables can execute on rules are:

• Append rules to a chain (iptables –A)
• Insert rules in a chain (iptables –I)
• Replace a rule from a chain (iptables –R)
• Delete a rule from a chain (iptables –D)

The most used switches are –A and –D (append and delete rules). Usually, when designing firewalls, the rules are appended to chains.
During run time, users use –I more than –A because often they need to insert temporary rules in the chain.
iptables –A places the rule at the end of the chain, while iptables –I places the rule on the top of the other rules in the chain. However, you can insert a rule anywhere in the chain by specifying the position where you want the rule to be in the chain with the –I switch: iptables –I CHAIN 4 will insert a rule at the fourth position of the specified chain.

The syntax for adding a rule to a chain is:

Filtering specifications is a part of an iptables rule that is used by the kernel to identify IP packets for which the kernel does the action specified by TARGET.

Filtering Specifications

IP packets can be identified in a large number of ways by specifying interfaces, protocols, ports, etc., to iptables rules. The beauty of it is that we can mix any of those specifications, having a high flexibility and a wide range of selectors. I'm not planning to cover all those selectors in depth, but keep in mind that if you think about something logical about IP packets, you have every chance to identify those packets using iptables rules.
Filtering specifications for Layer2: Interfaces can be specified as selectors with –i and –o switches.
-i stands for "--in-interface", and -o for "--out-interface". + can be used to specify only the beginning string of the interface—for example -i eth+ will match all interfaces beginning with the string eth; so we've specified all Ethernet interfaces as input interfaces for one rule.
Short version switches (e.g -i) and long version switches (e.g. "--in-interface") have absolutely the same effect. Some people prefer using short switches for command lines and long switches for scripts as they can offer better readability, but we will use only short switches in this article even in the scripts to get used to the command lines better.
The exclamation mark "!" represents a negation and can be used to specify on which interface(s) not to apply this filter (e.g. -i ! eth1 will not match packets coming in on eth1).

Layer 3: Source IP address(es) can be specified using -s, --src, or --source, and destination IP address(es) with -d,--dst, or --destination. Sources or destinations can be IP addresses, subnets, or canonical names (e.g, "-s 217.207.125.58", "-s www.packtpub.com", or "-s 217.207.125.58/32" have the same effect). Specifying canonical names for hosts that have multiple IP addresses will result in adding the same number of rules as the number of IP addresses the DNS server resolves for that host at the time the rules are added.

Layer 4: Protocol can be specified using the -p switch, which stands for "--protocol". Protocols can be specified by their corresponding numbers or by their names—tcp, udp, or icmp (case insensitive).
For the ICMP protocol, you can specify ICMP message types using "--icmp-type". The list of ICMP messages can be found by using the command "iptables -p icmp --help".
For the UDP protocol, you can specify source or destination ports with "--source-port" or "--sport" and "--destination-port" and "--dport".
TCP, being the most complete Layer 4 protocol, has more options. You can specify, besides source or destination ports as for the UDP protocol, "--tcp-flags", "--syn" and "--tcp-option". TCP flags can be "SYN ACK FIN RST URG PSH ALL NONE". "--syn" is used to identify the initiating connections and is equivalent to "--tcp-flags SYN,RST,ACK SYN". "--tcp-option" followed by a number matches TCP packets with the option set to that number.

Another beautiful thing about netfilter/iptables is that matching extensions can be developed separately and added later. On the netfilter site, there is a large repository of matching extensions called "patch-o-matic", at http://www.netfilter.org/projects/patch-o-matic/index.html.

A new and "daring" extension to iptables plans to extend its capabilities from the lower layers to the upper layer of the OSI model, Layer 7—application.