iptables
From Wikipedia, the free encyclopedia
| Original author(s) | Rusty Russell |
|---|---|
| Developer(s) | Netfilter Core Team |
| Initial release | 1998 |
| Stable release | 1.4.4 / June 16, 2009 |
| Written in | C |
| Operating system | Linux |
| Type | Packet filtering |
| License | GNU General Public License |
| Website | www.netfilter.org |
iptables is a user space application program that allows a system administrator to configure the tables provided by the Linux kernel firewall (which consists of Netfilter modules) and the chains and rules it stores. Different programs are currently used for different protocols; iptables applies to IPv4, ip6tables to IPv6, arptables to ARP, and ebtables as a special for Ethernet frames.
Because iptables requires elevated privileges to operate, it must be executed by user root, otherwise it fails to function. On most Linux systems, iptables is installed as /usr/sbin/iptables and documented in its man page [1][2], which can be opened using "man iptables" when installed.
iptables is also commonly used to inclusively refer to the kernel-level components. x_tables is the name of the kernel module carrying the shared code portion used by all four modules that also provides the API used for extensions; subsequently, Xtables is more or less used to refer to the entire firewall (v4,v6,arp,eb) architecture.
Contents |
[edit] History
Netfilter and iptables were initially designed together, so there is some overlap in early history. See Netfilter's article.
Prior to iptables, the predominant software packages for creating Linux firewalls were ipchains in Linux 2.2; and ipfwadm in Linux 2.0 which in turn was based on BSD's ipfw.
iptables preserves the basic ideas introduced into Linux with ipfwadm: lists of rules which each specified what to match within a packet, and what to do with such a packet. ipchains added the concept of chains of rules, and iptables extended this further into tables: one table was consulted when deciding whether to NAT a packet, and another consulted when deciding how to filter a packet. In addition, the three points at which filtering is done in a packet's journey were altered, so any packet only passes through one filtering point.
This split allowed iptables, in turn, to use the information which the connection tracking layer had determined about a packet: this information was previously tied to NAT. This makes iptables superior to ipchains because it has the ability to monitor the state of a connection and redirect, modify or stop data packets based on the state of the connection, not just on the source, destination or data content of the packet. A firewall using iptables this way is said to be a stateful firewall versus ipchains, which can only create a stateless firewall (except in very limited cases). It can be said that ipchains is not aware of the full context from which a data packet arises, whereas iptables is, and therefore iptables can make better decisions on the fate of packets and connections.
The netfilter maintainer intends to replace iptables with nftables in the future. The project is currently in the alpha stage of development.
[edit] Operational summary
Xtables 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 sequentially traversing the rules in chains. A rule in a chain can cause a goto or jump to another chain, and this can be repeated to whatever level of nesting is desired. (A jump is like a “call”, i.e. the point that was jumped from is remembered.) 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 five predefined chains (mapping to the five available Netfilter hooks), though a table may not have all chains. 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.
- “PREROUTING”: Packets will enter this chain before a routing decision is made.
- “INPUT”: Packet is going to be locally delivered. (N.B.: It does not have anything to do with processes having a socket open. Local delivery is controlled by the “local-delivery” routing table: `
ip route show table local`.) - “FORWARD”: All packets that have been routed and were not for local delivery will traverse this chain.
- “OUTPUT”: Packets sent from the machine itself will be visiting this chain.
- “POSTROUTING”: Routing decision has been made. Packets enter this chain just before handing them off to the hardware.
Each rule in a chain contains the specification of which packets it matches. It may also contain a target (used for extensions) or verdict (one of the built-in decisions). As a packet traverses a chain, each rule in turn is examined. 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/verdict, which may result in the packet being allowed to continue along the chain or it may not. Matches make up the large part of rulesets, as they contain the conditions packets are tested for. These can happen for about any layer in the OSI model, as with e.g. the --mac-source and -p tcp --dport parameteres, and there are also protocol-independent matches, such as -m time.
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 verdicts); or (2) a rule calls the RETURN verdict, in which case processing returns to the calling chain; or (3) the end of the chain is reached. Targets also return a verdict like ACCEPT (NAT modules will do this) or DROP (e.g. the “REJECT” module), but may also imply CONTINUE (internal name) to continue with the next rule as if no target/verdict was specified at all.
[edit] Example
This example shows an already-configured workstation firewall. The command "iptables -L" is executed by user root to display an abridged view of the firewall configuration. (The complete state can be obtained with iptables-save -c, and should be used when reporting problems.)
# 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
The RELATED,ESTABLISHED rule uses statefulness so that most client programs (web browser, ssh...) “just work”.
$ w3m http://en.wikipedia.org/wiki/Main_Page
(The main Wikipedia web page opens)
Computer does not respond to ping and no services are offered. Connections are rejected (REJECT) or timeout (with DROP) when ports are being scanned.
$ ping -c 1 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. --- 62.78.243.6 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms
Trying to connect to HTTP port (TCP 80)
$ telnet 10.0.0.1 80 Trying 10.0.0.1... telnet: connect to address 10.0.0.1: Connection refused
[edit] 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
which reroutes packets on the loopback (lo) interface from port 80 to port 8080.
[edit] Front-ends and scripts
There are numerous third-party software for iptables that tries to facilitate setting up rules. Front-ends in textual or graphical fashion allow users to click-generate simple rulesets; scripts usually refer to shell scripts (but other scripting languages are possible too) that call iptables or (the faster) iptables-restore with a set of predefined rules, or rules expanded from a template with the help of a simple configuration file. Linux distributions commonly employ the latter scheme of using templates. Such a template-based approach is practically a limited form of a rule generator, and such generators also exist in standalone fashion, for example, as PHP web pages.
Such front-ends, generators and scripts are often limited by their built-in template systems and where the templates offer substitution spots for user-defined rules. Also, the generated rules are generally not optimized for the particular firewalling effect the user wishes, as doing so will likely increase the maintenance cost for the developer. Users who reasonably understand iptables and want their ruleset optimized are advised to construct their own ruleset.
[edit] External links
- The netfilter/iptables project Web page
- iptables at Freshmeat
- The netfilter/iptables documentation page (outdated)
[edit] Other tools
- NuFW, an authenticating firewall extension to Netfilter
- FWSnort, Translates a Snort IDS ruleset into an IPTables ruleset.
- psad, Automated iptables log analysis to detect suspicious activity (port scans and probes for backdoors), and passively fingerprint remote TCP stacks.
- Programming Netfilter/iptables modules in "Rope"
[edit] Diagrams
To better understand how a packet traverses the kernel Xtables tables/chains you may find the following diagrams useful:
