Introduction to IPtables firewall

In this post i will explain the basic usage of IPtables firewall.

Note: Samples taken from other articles -> Check the references section 

Agenda

• Introduction
• Understanding firewall and packet filtering
• IPtables internals
• Getting started
• Conclusion
• References

Introduction

IPtables is the IP packet filtering system that is integrated with the latest 2.4.x versions of the Linux kernel. This system facilitates greater control over IP packet filtering and firewall configuration on Linux systems, be they systems connected to the Internet or a LAN, servers, or proxy servers interfacing between a LAN and the Internet.

There is a wealth of information available about iptables, but much of it is fairly complex, and if you want to do a few basic things, this How To is for you.  

Understanding firewall and packet filtering

For a Linux system connected to a network, a firewall is the essential defense mechanism that allows only legitimate network traffic in and out of the system and disallows everything else. To determine whether the network traffic is legitimate or not, a firewall relies on a set of rules it contains that are predefined by a network or system administrator. These rules tell the firewall whether to consider as legitimate and what to do with the network traffic coming from a certain source, going to a certain destination, or having a certain protocol type. The term "configuring the firewall" refers to adding, modifying, and removing these rules.

Network traffic is made up of IP packets or simply packets -- small chunks of data traveling in streams from a source system to a destination system. These packets have headers, i.e. bits of data prefixed to every packet that contain information about the packet's source, destination, and protocol types. Based on a set of rules, a firewall checks these headers to determine which packet to accept and which packet to reject. This process is known as packet filtering. 

IPtables internals

The IPtables IP packet filtering system is a powerful tool that is used to add, edit and remove the rules that a firewall follows and consists of while making packet filtering decisions. These rules are stored in special-purpose packet filtering tables integrated in the Linux kernel. Inside the packet filtering tables the rules are grouped together in what are known as chains.

The netfilter/iptables IP packet filtering system, although referred to as a single entity, is actually made up of two components: netfilter and iptables. 

The netfilter component, also known as kernelspace, is the part of the kernel that consists of packet filtering tables containing sets of rules that are used by the kernel to control the process of packet filtering. 

The iptables component is a tool, also known as userspace, which facilitates inserting, modifying and removing rules in the packet filtering tables.

By using userspace, you can build your own customized rules that are saved in packet filtering tables in kernelspace. These rules have targets that tell the kernel what to do with packets coming from certain sources, heading for certain destinations or have certain protocol types. If a packet matches a rule, the packet can be allowed to pass through using target ACCEPT. A packet can also be blocked and killed using target DROP or REJECT. There are many more targets available for other actions that can be performed on packets. 

The rules are grouped in chains, according to the types of packets they deal with. Rules dealing with incoming packets are added to the INPUT chain. Rules dealing with outgoing packets are added to the OUTPUT chain. And rules dealing with packets being forwarded are added to the FORWARD chain. These three chains are the main chains built-in by default inside basic packet-filtering tables. There are many other chain types available like PREROUTING and POSTROUTING and there is also provision for user-defined chains. Each chain can have a policy that defines "a default target", i.e. a default action to perform, if a packet doesn't match any rule in that chain. 

After the rules are built and chains are in place, the real work of packet filtering starts. Here is where the kernelspace takes over from userspace. When a packet reaches the firewall, the kernel first examines the header information of the packet, particularly the destination of the packet. This process is known as routing.

If the packet originated from outside and is destined for the system and the firewall is on, the kernel passes it on to the INPUT chain of the kernelspace packet filtering table. If the packet originated from inside the system or another source on an internal network the system is connected to and is destined for another outside system, the packet is passed on to the OUTPUT chain. Similarly, packets originating from outside systems and destined for outside systems are passed on to the FORWARD chain. 

Next the packet's header information is compared with each rule in the chain it is passed on to, unless it perfectly matches a rule. If a packet matches a rule, the kernel performs the action specified by the target of that rule on the packet. But if the packet doesn't match a rule, then it is compared to the next rule in the chain. Finally, if the packet doesn't match to any rule in the chain, then the kernel consults the policy of that chain to decide what to do with the packet. Ideally the policy should tell the kernel to DROP that packet. Figure 1 graphically illustrates this packet filtering process.

             Figure 1

Getting started

Almost all Linux distributions come with iptables installed and ready to use. Make sure you have the iptables command available in your preferred shell. 

Because we are going to make modifications at the kernel level, make sure you have root privileges.

Checking Currently applied rules

root@desktop:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination      

The output also mentions Chain. Think of iptable chains as sections in the firewall allowing a certain type of traffic. For example, to block all traffic from the private network to the internet, that rule would be set in the OUTPUT section. Similarly, any rule affecting incoming traffic would be listed in the INPUT chain.
The three chains are each applied to one type of activity in the firewall. At this point, there is nothing set yet. This means there are no restrictions and all network traffic is allowed to come and go.

• Chain INPUT
• Chain FORWARD, and
• Chain OUTPUT

Saving rules to a file

root@desktop:~# iptables-save > /etc/iptables.rules

root@desktop:~# cat /etc/iptables.rules 
# Generated by iptables-save v1.4.4 on Thu Dec 22 15:10:42 2011

*filter
:INPUT ACCEPT [732:83443]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [656:51642]
COMMIT
# Completed on Thu Dec 22 15:10:42 2011

 

Use the iptables-save command and redirected the output to a text file in the "/etc" directory. 

One of the first requirements is to allow established connections to receive traffic. You need this when you want anything behind the firewall (in a private network) to be able to send and receive network data without restrictions.

Establish sessions rule
 

root@desktop:~# iptables -A INPUT -m conntrack --ctstate \

ESTABLISHED,RELATED -j ACCEPT
root@desktop:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere    ctstate RELATED,ESTABLISHED 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

To have a better idea of what was issued, let's break the command apart and explain each one:

-A INPUT: Append this rule to the INPUT chain.

-m conntrack: Match the following connection tracking for the current packet/connection. 

-ctstate ESTABLISHED, RELATED: Connection states that the rule should apply to. In this case, an ESTABLISHED connection means a connection that has seen packets in both directions and a RELATED type means that the packet is starting a new connection but it is associated with an existing connection.

-j ACCEPT: tells the firewall to accept the connections described before. Another valid setting for the -j flag would be DROP




Accepting inbound SSH connections




root@desktop:~# iptables -A INPUT -p tcp --dport ssh -j ACCEPT
root@desktop:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere     ctstate RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere     tcp dpt:ssh 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination         

Blocking all incoming traffic

root@desktop:~#  iptables -A INPUT -j DROP
root@desktop:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere     ctstate RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere     tcp dpt:ssh 
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination       
 

Verifying firewall configuration

root@desktop:~# iptables-save > /etc/iptables.rules 
root@desktop:~# cat /etc/iptables.rules 
# Generated by iptables-save v1.4.4 on Thu Dec 22 15:10:42 2011
*filter
:INPUT ACCEPT [1234:120406]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1522:124750]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -j DROP 
COMMIT
# Completed on Thu Dec 22 15:10:42 2011

Network scan with locked down server

~ $ nmap 10.0.0.120    

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-11-21 20:56 EST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds

~ $ nmap -Pn 10.0.0.120

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-11-21 20:56 EST
Nmap scan report for 10.0.0.120
Host is up (0.017s latency).
Not shown: 999 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 12.19 seconds

Note that a scan was attempted against the IP where the server is located, but nmap failed to list the open ports. This happens because the firewall is set in such a way that it is blocking everything except for the SSH port we have open. Since nmap uses a specific network  protocol to verify if the host is up, it returned empty handed. The second try was successful and is telling us that only SSH is open and nothing else. With just three rules, we managed to get an effective lock down of  our server.
Saving rules

Now you've learned how to build basic rules and chains and how to add or remove them from the packet filtering tables. But you should remember that rules built the way described above are saved into the kernel and are lost when the system is rebooted. So if you have an error-free and efficient set of rules added to the packet filtering tables, to use the rules again after a reboot, you have to save the rule set in a file.

$ iptables-save > iptables-script
 
Whenever you boot your system again, you can restore the rule set into the packet filtering tables from this script file using the iptables-restore command as shown below:

$ iptables-restore iptables-script
 
And if you prefer to restore the rule set automatically every time you boot your system, then you can put the command specified above into any of your initialization shell-scripts.
 

 Conclusion

We have gone through some simple steps to get iptables to run properly and to safely lock down a Linux server. The rules applied should provide a good sense of what is going on in a server using iptables as a firewall. I encourage you to give iptables a try, especially if you depend on an appliance and want more control and easily replicated human-readable configurations.

While the rules used we've used here are simple, the full flexibility and complexity of iptables is beyond the scope of this article. There are many complex rules that you can combine to create a safe and controllable firewall environment.

 References

• Introduction to netfilter/iptables
• Firewall uptime and security with iptables
• IPtables HowTo