IPTables

From WBITT's Cooker!

Revision as of 10:23, 6 March 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.

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). 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

Basic Principles for protection

When trying to achieve the goal of "Maximum Security" or "Maximum Protection" for your IT assets, remember; IPTables, or any firewall for that matter, is just one small component. In other words, any firewall (software, or hardware), is not a magic wand. Merely placing a firewall on your server, or between your users and the internet, does not guarantee that the assets you are trying to protect, are actually protected. There are other areas to pay attention, in parallel to setting up / placing a firewall. The following principles must always be a part of your IT Security Policy, to achieve the goal of "Maximum Security" or "Maximum Protection".

Note: Most people don't pay attention to the fact that it is not only the servers and corporate networks, which are to be protected from the Internet. It is equally important to protect the internet from your servers or the corporate networks. i.e. Make sure that your server, or any of the computers inside your LAN are not compromised, and do not become a slave of a BOTNET to perform any sort of DOS or DDOS attack on other computers, or on Internet in general. "You can be held liable for such damages".

Internet Servers:

• Install the least amount of packages/software on the servers. This principle is equally valid for the servers placed on the Internet, or the servers placed on your private LAN. The goal should be to only install software which is related to the service offered by this server. For example, in case of a web server serving web pages generated by PHP, on the data stored in a MySQL database, you should install the minimal OS, and Apache Web Server, PHP, and MySQL database software on top of it. It would also be totally useless to have printing software (CUPS), office suite, or multimedia related packages, or desktop/window managers on this server.
• Each service running on your server is a door to your server's inside. Thus, enable only those services on the servers, which are an absolute must to run. For example, on a web server, you should only enable the web service and the services related to it. Switch off any/all irrelevant services. As you do not expect anyone to print any documents from the web server placed half the world away, there is no sense in having CUPS (Common Unix Printing System) service running on it. This way, there are less doors to lock / less holes to plug.
• Lock down services which are not needed to be accessed from outside. On a stand alone web server, there might be a MySQL database server running. However, this DB service doesn't need to be accessed from outside. Therefore in this case, lock down the DB service to listen only from the server's local IP address, or the loop back address. Apply the same to other services.
• Strip down each service to a bare number of modules. For example, if you are authenticating the website visitors against a MySQL database, there is no use to load LDAP, or PostgreSQL modules in your Apache configuration files.
• Make sure to keep the OS and application software updated. This will ensure that you run your OS and the applications running on top of it with minimum bugs / vulnerabilities. The least the vulnerabilities, the least chance for them to be exploited.
• Avoid creating users on your server, with access to any sort of command shell.

LAN users/Corporate networks:

• If possible, avoid all Microsoft products on your network. It is not a grudge. Privacy is the major concern. Security wise, it is a fact that most of the time, Microsoft products have serious bugs, vulnerabilities, back doors, and Easter eggs inside them. And they are easily hit by viruses, trojans, malware, spyware, etc. If you take a look at any commercial network, the network administrator is always complaining of the amount of spam being generated from the "inside network". That may lead to an assumption that the network/system admin is not doing his job in the first place. Still, windows systems are always more at risk. If there is a need to use windows systems, make sure that each workstation is protected by a "working"/"good-quality" anti-virus and anti-spam software. Also make sure that each workstation is up to date with the latest updates released by Microsoft. Also, make sure, that the subscriptions of both the OS and the applications on top of it are current. Most of the time, the anti-viruses's subscription is expired, and they stop working. It is also a fact, that the users also choose to ignore the warnings sent by the software, resulting in exploitation of any vulnerabilities in their systems.
• Linux OS and related Open-Source applications are a better choice, compared to Microsoft. These products have lesser bugs, fixes are available almost immediately, and there is no subscription (most of the time), to get updates. Debian, Fedora, CENTOS, Ubuntu, etc, are all subscription free operating systems, with remarkable security architecture, performance, and ease of use.
• Make sure, that both Windows and Linux systems on your network, follow some defined security policy. Such as users should not have ability to install any piece of software, without the security administrator's approval. Similarly, the list of software to be run on the corporate network, must be a limited one, allowing only that software to be installed on a computer, which is aligned to the user's job role/job responsibilities.
• Lock down Floppies, CD/DVD writers and USB ports on the computers. By the way, this is very difficult to implement in today's computing environments.
• DNS, DHCP services running on the network must be protected against users adding dummy DNS records in the DNS zone. They (users) should also be restricted in acquiring IP addresses for their computers.
• Any Wireless access points in your network, must use authentication mechanisms, and allow only those computer systems to connect to them, which provide necessary credentials at connection time. You must also use strong (strongest available) encryption to encrypt your wireless traffic.

This is not a definitive list, but should give you a clear idea.

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.
• 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.

• 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.

• 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.

References

• http://en.wikipedia.org/wiki/Iptables
• http://en.wikipedia.org/wiki/Netfilter
• http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html
• http://people.netfilter.org/~rusty/unreliable-guides/