iptables is a firewall that is a replacement of the IPChains firewall for the Linux 2.4 kernel and later versions. It requires elevated privileges to operate, and it must be executed by user root, otherwise it fails to function. iptables allows a system administrator to configure the tables provided by Xtables (which in turn uses Netfilter) and the chains and rules it stores. iptables has the following features:

* It supports stateful packet inspections.
* It filters the packets according to the MAC address and TCP header flag values.
* It is helpful for preventing attacks using malformed packets.
* It reduces DoS attacks.
* It provides better network address translation.
* It supports the transparent integration of the operating system with Web proxy servers.

iptables command

The iptables command is used to create and configure IP-tables that contains rules for packet filtering. The default filter table contains Input, Output, or Forward chains. Various command parameters are used with the iptables command to perform a specific action on the specified chains. The command syntax of the iptables command is as follows:

iptables [-t table] command [match] [target/jump]

Some of the important parameters are listed below:

Parameter Description
-A Appends the specified IP-table rule.
-D n Deletes the n(th) rule in the specified chain.
-F Deletes (or flushes) every rule in the specified chain. If no chain is specified, it deletes the rules from all chains.
-h Provides help by listing the command structures and summary of command parameters and options.

Note: All the parameters should be provided in uppercase except the -h parameter.

How iptables firewall works?

The Xtables framework, used by ip_tables, ip6_tables and arp_tables, allows the system administrator to define tables containing chains of rules for the treatment of packets. Each table is associated with a different kind of packet processing. Packets are processed by traversing the chains. A rule in a chain can send a packet to another chain, and this can be repeated to whatever level of nesting is desired. Every network packet arriving at or leaving from the computer traverses at least one chain.

The source of the packet determines which chain it traverses initially. There are three predefined chains (INPUT, OUTPUT, and FORWARD) in the “filter” table. Predefined chains have a policy, for example DROP, which is applied to the packet if it reaches the end of the chain. The system administrator can create as many other chains as desired. These chains have no policy; if a packet reaches the end of the chain, it is returned to the chain which called it. A chain may be empty.

Each rule in a chain contains the specification of which packets it matches. It may also contain a target. As a packet traverses a chain, each rule in turn examines it. If a rule does not match the packet, the packet is passed to the next rule. If a rule does match the packet, the rule takes the action indicated by the target, which may result in the packet being allowed to continue along the chain or it may not.

The packet continues to traverse the chain until either (1) a rule matches the packet and decides the ultimate fate of the packet (for example by calling one of the ACCEPT or DROP targets); or (2) a rule calls the RETURN target, in which case processing returns to the calling chain; or (3) the end of the chain is reached.

Example

The command “iptables -L” is executed by user root to display an abridged view of the firewall configuration.

# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all — localhost.localdomain localhost.localdomain
ACCEPT all — anywhere anywhere state RELATED,ESTABLISHED
REJECT all — anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Redirection Example

This simple example of its use illustrates how to redirect all traffic on the default HTTP port, port 80, to port 8080, allowing the HTTP daemon to run as a non-privileged user, unable to listen on port numbers below 1024.

iptables -t nat -A PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8080

Note: If you launch this command on your computer, it will only work for external IP addresses connecting to your machine. Connections from localhost do not traverse the PREROUTING chain in the “nat” table. If you also want this feature to work, use the following rule:

iptables -t nat -A OUTPUT -o lo -p tcp –dport 80 -j REDIRECT –to-port 8080

It reroutes packets on the loopback (lo) interface from port 80 to port 8080.

Netfilter

Netfilter is a framework that provides a set of hooks within the Linux kernel for intercepting and manipulating network packets.

The best-known component on top of Netfilter is the firewall which filters packets, but the hooks are also used by other components which perform network address translation, stateful tracking and packet enqueueing to user space.

Connection Tracking by Netfilter

One of the important features built on top of the Netfilter framework is connection tracking. Connection tracking allows the kernel to keep track of all logical network connections or sessions, and thereby relate all of the packets which may make up that connection. NAT relies on this information to translate all related packets in the same way, and iptables can use this information to act as a stateful firewall.

Connection tracking classifies each packet as being in a number of different states: new (trying to create a new connection), established (part of an already-existing connection), related (packet initiating a new connection that is related to, but not actually part of an existing connection), invalid (not part of an existing connection) and untracked. A normal example would be that the first packet the conntrack subsystem sees will be classified new, the reply would be classified established and an ICMP error would be related. An ICMP error packet which did not match any known connection would be invalid. untracked is a special state that can be assigned by the administrator to bypass connection tracking for a particular packet.

The connection state is completely independent of any TCP state. If the host answers with a SYN ACK packet to acknowledge a new incoming TCP connection, the TCP connection itself is not yet established but the tracked connection is this packet will match the “established” state.

A tracked connection of a stateless protocol like UDP nevertheless has a connection state.

Furthermore, through the use of plugin modules, connection tracking can be given knowledge of application layer protocols and thus understand that two or more distinct connections are “related”. For example, consider the FTP protocol. A control connection is established, but whenever data is transferred, a separate connection is established to transfer it. When the nf_conntrack_ftp module is loaded, the first packet of an FTP data connection will be classified as “related” instead of “new”, as it is logically part of an existing connection.

iptables can use the connection tracking information to make packet filtering rules more powerful and easier to manage. The “conntrack” match extension allows iptables rules to examine the connection tracking classification for a packet. For example, one rule might allow NEW packets only from inside the firewall to outside, but allow RELATED and ESTABLISHED in either direction. This allows normal reply packets from the outside (ESTABLISHED), but does not allow new connections to come from the outside to the inside. However, if an FTP data connection needs to come from outside the firewall to the inside, it will be allowed, because the packet will be correctly classified as RELATED to the FTP control connection, rather than a NEW connection.