IPTables
From WBITT's Cooker!
(→Diagram) |
|||
| (43 intermediate revisions not shown) | |||
| Line 16: | Line 16: | ||
==Purpose of this document== | ==Purpose of this document== | ||
| - | Although, several extremely good articles already exist on the topic of IPTables | + | Although, several extremely good articles already exist on the topic of IPTables, there was a popular demand for a CBT on this topic. The CBT definitely needed a text to follow, and thus this article was born. It should be noted that this document is for a beginner, for whom too much of information is confusing. Therefore, this document addresses basic concepts and mechanisms. If you are looking for a detailed discussion/explanation of TCP/IP protocol stack, TCP/IP headers, in relation to various moving parts of the entire iptables/netfilter mechanism, etc; you should read the latest version of [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html "Iptables Tutorial by Oskar Andreasson"], which is one of the finest documents on IPTables till date. You should also check [http://people.netfilter.org/~rusty/unreliable-guides/ "Rusty's Remarkably Unreliable Guides"]. Rusty Russell, was the person, who actually wrote (most of the) IPChains and IPTables code. |
==Introduction== | ==Introduction== | ||
| - | IPTables is the mechanism for packet "Filter"-ing, in modern Linux distributions. In addition to packet filtering, it also does other interesting things such as "NAT"-ing and "Mangle"-ing. To be more specific, IPTables (originally from the NetFileter project), is the user-land application, which is used to manage/configure various packet handling "tables" provided in the Linux kernel (Linux Kernel Firewall). Each table has certain "chains" in it, and each chain has certain "rules", against which each packet is evaluated. IPTables is the default packet handling application in 2.4 and 2.6 series kernels. In 2.2 series kernels the application was "IPChains"; and in 2.0 series kernel, it was "IPFWAdm". | + | IPTables is the mechanism for packet "Filter"-ing, in modern Linux distributions. In addition to packet filtering, it also does other interesting things such as "NAT"-ing and "Mangle"-ing. To be more specific, IPTables (originally from the NetFileter project), is the user-land application, which is used to manage/configure various packet handling "tables" provided in the Linux kernel (Linux Kernel Firewall). Check http://www.linfo.org/kernel_space.html for a definition of Kernel Space and User Space. |
| + | |||
| + | [[File:Kerner-user-space.png]] | ||
| + | |||
| + | Each table has certain "chains" in it, and each chain has certain "rules", against which each packet is evaluated. IPTables is the default packet handling application in 2.4 and 2.6 series kernels. In 2.2 series kernels the application was "IPChains"; and in 2.0 series kernel, it was "IPFWAdm". | ||
| + | |||
| + | <b>Note:</b> IPTables deal with IPV4 traffic. IP6Tables are used to control IPV6 traffic. ARPTables are used to control ARP traffic. And ebtables are used to control traffic crossing bridges. | ||
In addition to looking at the source and destination IP addresses and ports, IPTables also has the ability to monitor the "state" of the packet. This makes iptables also work as a "stateful" firewall. In other words, it also does connection tracking. A stateful firewall can check context of the packet, to evaluate if it is a NEW packet, a packet related to a previous communication, or a packet from an already ESTABLISHED communication, etc. It can also inspect, and take action on, various TCP flags in a packet header, such as SYN, ACK, FIN, etc. | In addition to looking at the source and destination IP addresses and ports, IPTables also has the ability to monitor the "state" of the packet. This makes iptables also work as a "stateful" firewall. In other words, it also does connection tracking. A stateful firewall can check context of the packet, to evaluate if it is a NEW packet, a packet related to a previous communication, or a packet from an already ESTABLISHED communication, etc. It can also inspect, and take action on, various TCP flags in a packet header, such as SYN, ACK, FIN, etc. | ||
| - | <b>Note:</b> We would be using the word "iptables" in lower case. It is same as IPTables. | + | <b>Note:</b> We would be using the word "iptables" in lower case. It is same as "IPTables", or "IP Tables". |
You may be encountering the term/word "NetFilter", whenever you are reading any text related to IPTables. Netfilter and iptables were initially designed together, in 1998, so there is some overlap in early history. It might also be interesting to note, that the Netfilter maintainer Patrick McHardy has proposed to replace iptables with nftables in the future. The project is currently in the alpha stage of development. | You may be encountering the term/word "NetFilter", whenever you are reading any text related to IPTables. Netfilter and iptables were initially designed together, in 1998, so there is some overlap in early history. It might also be interesting to note, that the Netfilter maintainer Patrick McHardy has proposed to replace iptables with nftables in the future. The project is currently in the alpha stage of development. | ||
| + | ==What we would cover in this document?== | ||
| + | We would explain, to a suitable depth, <i>How IPTables work?</i> And, <i>How to comprehend, write and manage IPTables rules?</i> To support our explanation, we would cover two common scenarios: | ||
| + | * Protecting Internet servers | ||
| + | * Protecting LANs connected to the internet | ||
| + | |||
| + | ==The moving parts of IPTables== | ||
| + | The Linux Kernel Firewall provides several "tables" to manage traffic. And IPTables application is used to manage these tables. From here onwards, we would use terms "Linux Kernel Firewall" and "IPTables" interchangeably. Though we fully understand that the two operate in totally different areas; still, this way it is easier to understand the concepts. | ||
| + | |||
| + | Commonly used tables are: filter, nat, mangle. Each table has specific role in handling the traffic passing through it, briefly described below. | ||
| + | * Filter table: Consists of INPUT, FORWARD and OUTPUT chains. Any filtering decisions to ACCEPT, REJECT, or DROP packets are made here. | ||
| + | * NAT table: Consists of PREROUTING, POSTROUTING and OUTPUT chains. The chains in the NAT table cannot be used for filtering. Possible targets are: DNAT, SNAT, MASQUERADE, REDIRECT. | ||
| + | * Mangle table: Consists of PREROUTING, INPUT, FORWARD, OUTPUT and POSTROUTING chains. Packets are marked with special "markers", which are later used to identify / differentiate different traffic. Mangle is also used to manipulate various parts of the packet, such as modifying the TTL value, etc. | ||
| + | |||
| + | Any IP packet, from the moment it enters a Linux machine, to the moment it leaves the machine, passes through different chains. Below are few possible routes a packet may take: | ||
| + | |||
| + | * Consider a web server, for example. A packet arrives requesting a web page. This packet is destined to reach a web service (Apache) running on the web server. In this case, the packet will traverse PREROUTING and INPUT chains, on it's way in. Once this packet reaches the web service on port 80, of this server, the server generates a web page and sends back the packet. This packet, (since it originated from a local service on this machine), comes out of the OUTPUT chain, and exits the machine from the POSTROUTING chain. In this scenario, FORWARD chain was not used at all. Simple text representation of this particular traffic is as follows: | ||
| + | <pre> | ||
| + | Wire-->--NetworkInterfaceCard-->--[PREROUTING]-->--[INPUT]-->--LocalService/Port | ||
| + | </pre> | ||
| + | |||
| + | * Consider a Linux Router/Firewall/Gateway, placed between a private LAN of your SOHO, and Internet. Assume a user on the LAN tries to access a web page from a website, somewhere on the internet. The packet originate from this user's PC, reach the physical interface of the Linux firewall, and enters the PREROUTING chain. After PREROUTING, a routing decision is made: "Does the packet wishes to go out towards the internet?", or, "Does the packet wishes to reach a service running on the this firewall/gateway?". In our case, the kernel on this gateway machine would notice, that this packet is not destined for any local service on the gateway, and wishes to go out. The packet will thus be sent out on the FORWARD chain, (assuming packet forwarding is enabled). The packet then traverses the POSTROUTING chain, where its source IP address listed in the packet headers are replaced with the public IP of the outgoing interface, using SNAT or MASQUERADE. (SNAT and MASQUERADE will be discussed shortly). The packet then leaves POSTROUTING chain, and essentially exits the physical machine (the gateway/firewall). In this scenario, the packet did not traverse the INPUT and OUTPUT chains of the gateway/firewall. Simple text representation of this particular traffic is as follows: | ||
| + | <pre> | ||
| + | Wire-->--NetworkInterfaceCard-->--[PREROUTING]-->--[FORWARD]-->--[POSTROUTING]-->--NetworkInterfaceCard-->--Wire | ||
| + | </pre> | ||
| + | |||
| + | * Consider a Linux PC, or a web server for example. This time, the machine in question needs to get some package from the internet. Perhaps, it needs to update its kernel. A web request will originate from this machine. This request, in the shape of IP packets, will directly start traversing the OUTPUT chain. Afterwards, the packet will traverse the POSTROUTING chain and will exit the machine. In this scenario, the packet which origination from this machine, did not pass through PREROUTING, FORWARD, or INPUT chains. Simple text representation of this particular traffic is as follows: | ||
| + | <pre> | ||
| + | LocalService/Port-->--[Output]-->--[POSTROUTING]-->--NetworkInterfaceCard-->--Wire | ||
| + | </pre> | ||
| + | |||
| + | ===Packet Traversal between various chains=== | ||
| + | [[File:IPTables-Chains-1.png]] | ||
| + | |||
| + | ==CBTs== | ||
| + | A series of CBTs is also released on WBITT, covering the same topic, in Urdu. English version will soon be released. | ||
| + | |||
| + | [[http://techsnail.com/cbts-training-videos/urdu-cbt-understanding-iptables/ Understanding IPTables, Urdu CBT]] | ||
==References== | ==References== | ||
| Line 32: | Line 75: | ||
* http://en.wikipedia.org/wiki/Netfilter | * http://en.wikipedia.org/wiki/Netfilter | ||
* http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html | * http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html | ||
| + | * http://people.netfilter.org/~rusty/unreliable-guides/ | ||
| + | * http://www.linfo.org/kernel_space.html | ||
Current revision as of 18:20, 3 April 2011
Alternate Title: "Understanding IPTables"
Author: Muhammad Kamran Azeem [CISSP, RHCE, OCP (DBA), CCNA] (http://wbitt.com , http://techsnail.com)
E-mail: kamran at wbitt dot com
Created: 27 Feb 2011
Updated: (Please see the footer area of this document for this information.)
Category: Firewall, Security
License: Copyright (c) 2011 by Muhammad Kamran Azeem. Permission to copy, distribute (sell or give-away) and translate, provided you retain the name of the original author.
Synopsis: This paper, explains the Linux default firewall, the IPTables.
Contents |
Purpose of this document
Although, several extremely good articles already exist on the topic of IPTables, there was a popular demand for a CBT on this topic. The CBT definitely needed a text to follow, and thus this article was born. It should be noted that this document is for a beginner, for whom too much of information is confusing. Therefore, this document addresses basic concepts and mechanisms. If you are looking for a detailed discussion/explanation of TCP/IP protocol stack, TCP/IP headers, in relation to various moving parts of the entire iptables/netfilter mechanism, etc; you should read the latest version of "Iptables Tutorial by Oskar Andreasson", which is one of the finest documents on IPTables till date. You should also check "Rusty's Remarkably Unreliable Guides". Rusty Russell, was the person, who actually wrote (most of the) IPChains and IPTables code.
Introduction
IPTables is the mechanism for packet "Filter"-ing, in modern Linux distributions. In addition to packet filtering, it also does other interesting things such as "NAT"-ing and "Mangle"-ing. To be more specific, IPTables (originally from the NetFileter project), is the user-land application, which is used to manage/configure various packet handling "tables" provided in the Linux kernel (Linux Kernel Firewall). Check http://www.linfo.org/kernel_space.html for a definition of Kernel Space and User Space.
Each table has certain "chains" in it, and each chain has certain "rules", against which each packet is evaluated. IPTables is the default packet handling application in 2.4 and 2.6 series kernels. In 2.2 series kernels the application was "IPChains"; and in 2.0 series kernel, it was "IPFWAdm".
Note: IPTables deal with IPV4 traffic. IP6Tables are used to control IPV6 traffic. ARPTables are used to control ARP traffic. And ebtables are used to control traffic crossing bridges.
In addition to looking at the source and destination IP addresses and ports, IPTables also has the ability to monitor the "state" of the packet. This makes iptables also work as a "stateful" firewall. In other words, it also does connection tracking. A stateful firewall can check context of the packet, to evaluate if it is a NEW packet, a packet related to a previous communication, or a packet from an already ESTABLISHED communication, etc. It can also inspect, and take action on, various TCP flags in a packet header, such as SYN, ACK, FIN, etc.
Note: We would be using the word "iptables" in lower case. It is same as "IPTables", or "IP Tables".
You may be encountering the term/word "NetFilter", whenever you are reading any text related to IPTables. Netfilter and iptables were initially designed together, in 1998, so there is some overlap in early history. It might also be interesting to note, that the Netfilter maintainer Patrick McHardy has proposed to replace iptables with nftables in the future. The project is currently in the alpha stage of development.
What we would cover in this document?
We would explain, to a suitable depth, How IPTables work? And, How to comprehend, write and manage IPTables rules? To support our explanation, we would cover two common scenarios:
- Protecting Internet servers
- Protecting LANs connected to the internet
The moving parts of IPTables
The Linux Kernel Firewall provides several "tables" to manage traffic. And IPTables application is used to manage these tables. From here onwards, we would use terms "Linux Kernel Firewall" and "IPTables" interchangeably. Though we fully understand that the two operate in totally different areas; still, this way it is easier to understand the concepts.
Commonly used tables are: filter, nat, mangle. Each table has specific role in handling the traffic passing through it, briefly described below.
- Filter table: Consists of INPUT, FORWARD and OUTPUT chains. Any filtering decisions to ACCEPT, REJECT, or DROP packets are made here.
- NAT table: Consists of PREROUTING, POSTROUTING and OUTPUT chains. The chains in the NAT table cannot be used for filtering. Possible targets are: DNAT, SNAT, MASQUERADE, REDIRECT.
- Mangle table: Consists of PREROUTING, INPUT, FORWARD, OUTPUT and POSTROUTING chains. Packets are marked with special "markers", which are later used to identify / differentiate different traffic. Mangle is also used to manipulate various parts of the packet, such as modifying the TTL value, etc.
Any IP packet, from the moment it enters a Linux machine, to the moment it leaves the machine, passes through different chains. Below are few possible routes a packet may take:
- Consider a web server, for example. A packet arrives requesting a web page. This packet is destined to reach a web service (Apache) running on the web server. In this case, the packet will traverse PREROUTING and INPUT chains, on it's way in. Once this packet reaches the web service on port 80, of this server, the server generates a web page and sends back the packet. This packet, (since it originated from a local service on this machine), comes out of the OUTPUT chain, and exits the machine from the POSTROUTING chain. In this scenario, FORWARD chain was not used at all. Simple text representation of this particular traffic is as follows:
Wire-->--NetworkInterfaceCard-->--[PREROUTING]-->--[INPUT]-->--LocalService/Port
- Consider a Linux Router/Firewall/Gateway, placed between a private LAN of your SOHO, and Internet. Assume a user on the LAN tries to access a web page from a website, somewhere on the internet. The packet originate from this user's PC, reach the physical interface of the Linux firewall, and enters the PREROUTING chain. After PREROUTING, a routing decision is made: "Does the packet wishes to go out towards the internet?", or, "Does the packet wishes to reach a service running on the this firewall/gateway?". In our case, the kernel on this gateway machine would notice, that this packet is not destined for any local service on the gateway, and wishes to go out. The packet will thus be sent out on the FORWARD chain, (assuming packet forwarding is enabled). The packet then traverses the POSTROUTING chain, where its source IP address listed in the packet headers are replaced with the public IP of the outgoing interface, using SNAT or MASQUERADE. (SNAT and MASQUERADE will be discussed shortly). The packet then leaves POSTROUTING chain, and essentially exits the physical machine (the gateway/firewall). In this scenario, the packet did not traverse the INPUT and OUTPUT chains of the gateway/firewall. Simple text representation of this particular traffic is as follows:
Wire-->--NetworkInterfaceCard-->--[PREROUTING]-->--[FORWARD]-->--[POSTROUTING]-->--NetworkInterfaceCard-->--Wire
- Consider a Linux PC, or a web server for example. This time, the machine in question needs to get some package from the internet. Perhaps, it needs to update its kernel. A web request will originate from this machine. This request, in the shape of IP packets, will directly start traversing the OUTPUT chain. Afterwards, the packet will traverse the POSTROUTING chain and will exit the machine. In this scenario, the packet which origination from this machine, did not pass through PREROUTING, FORWARD, or INPUT chains. Simple text representation of this particular traffic is as follows:
LocalService/Port-->--[Output]-->--[POSTROUTING]-->--NetworkInterfaceCard-->--Wire
Packet Traversal between various chains
CBTs
A series of CBTs is also released on WBITT, covering the same topic, in Urdu. English version will soon be released.
[Understanding IPTables, Urdu CBT]
