Introducing iptables part 3

This article provides an overview of how to configure the Linux kernel firewall for ipv4 using iptables and the Filter table. It is intended for beginners to intermediate linux users and provides launch at startup configurations and also useful examples.


In the Introducing iptables part 1 and Introducing iptables part 2 articles we briefly discussed the Filter table and chains, backing up and restoring configurations as well as inserting, appending and deleting rules. This article will cover launch at startup configurations and some useful examples.

Launch at Startup

Let's take a look at our current rules. If you've been following along, your current rules should look something like:

sudo /sbin/iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  0.0.0.0/0            127.0.0.0/8         reject-with icmp-port-unreachable 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:30000 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
LOG        all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables denied: ' 
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0  

Let's make sure the configuration is saved to a file.

sudo sh -c '/sbin/iptables-save > /etc/iptables.save'

Now skip to your distribution subsection to continue setting up iptables for startup.

Ubuntu and Debian

sudo nano /etc/network/if-pre-up.d/iptables

If the file has contents, update it to match this or add the following contents:

#!/bin/sh
sudo sh -c '/sbin/iptables-restore < /etc/iptables.save'

Now make sure the script is executable with the following:

sudo /bin/chmod +x /etc/network/if-pre-up.d/iptables

This will run the iptables-restore command on your saved config file every time the network interface comes up.

RHEL, CentOS and Fedora

sudo /sbin/service iptables save

This will restore your ruleset on reboot.

Gentoo

sudo /etc/init.d/iptables save

This will save your current config to:

/var/lib/iptables/rules-save

Then to have it start at boot, add it to the default runtime with:

sudo /sbin/rc-update add iptables default

Arch

sudo /etc/init.d/iptables save

This will save your current configuration to:

/etc/iptables/iptables.rules

Then add iptables to your DAEMONS section of your rc.conf file

sudo nano /etc/rc.conf

Should look something similar to:

DAEMONS=(syslog-ng iptables network netfs crond sshd)

Examples

Here is our example iptables rules file. You can restore this for the above configuration with:

sudo sh -c '/sbin/iptables-restore < iptables.txt'

This one will block TCP traffic on port 21(ftp). You can replace the 21 with the desired port.

sudo /sbin/iptables -I INPUT -p tcp -m tcp --dport 21 -j DROP

This one will block TCP traffic originating from a specific ip address or range.

sudo /sbin/iptables -I INPUT -s 123.123.123.123 -p tcp -j DROP

If you don't specify a protocol, it will block all traffic from the ip.

sudo /sbin/iptables -I INPUT -s 123.123.123.123 -j DROP

And if you wanted to combine the two, you could block TCP traffic from both source ip and destination port with something like:

sudo /sbin/iptables -I INPUT -s 123.123.123.123 -p tcp -m tcp --dport 21 -j DROP

These rules will limit the number of connections allowed over a time period. The example uses the alternate ssh port 30000. It can help prevent brute force attacks etcetera by adding the ip to a sshbrute list, as well as verify that the ip's on the list are not exceeding the 60 second limit. Change the ssh port 30000 if needed.

sudo /sbin/iptables -I INPUT -p tcp --dport 30000 -i eth0 -m state --state NEW -m sshbrute --set
sudo /sbin/iptables -I INPUT -p tcp --dport 30000 -i eth0 -m state --state NEW -m sshbrute --update --seconds 60 --hitcount 4 -j DROP

Further Info

There are loads of information regarding iptables and the linux firewall. These articles just touch on the basics. Fail2ban is a good example of a program that uses iptables quite a bit. And check out the official iptables site for more info as well.

  • -- Natorious

Article Comments:

Felipe commented Thu Mar 03 17:19:54 UTC 2011:

Thank you for this great article. I was able to use the information gathered from following the fail2ban article to block IP addresses that were attempting to access my site.

Sean commented Sun Mar 27 07:55:44 UTC 2011:

While the earlier rules use REJECT, the additional examples at the bottom of part-3 use DROP instead. I understand that DROP is more "stealthy" in that no response is sent to the source, possibly obscuring existence of a server at the destination IP. I also understand that DROP may lead to some user apps simply assuming the packet got lost leading to more packets as they try again.

Given these factors, are there any generally accepted best practices for DROP use vs REJECT? Is there a reason DROP wasn't used previously?

Thank you!

Nate commented Tue Mar 29 08:09:52 UTC 2011:

Hi Sean. The big differences between DROP vs REJECT is that with DROP, there is not reply back to the original sender. In most situations, you would want to block an ip address using DROP if the traffic from that ip is malicious as there is no sense in replying to it. Either approach should work though.

Peter Drake commented Fri Apr 08 21:33:25 UTC 2011:

Very nicely written with easily readable instruction that are clearly explained. Congratulation on doing well what a lot of other tutorials don't.

P.S I am a teacher and would permission to use this in my class

Adebayo commented Tue Oct 18 14:30:13 UTC 2011:

I would like to know the effect of having this line in the FORWARD chain in iptables.

ACCEPT all anywhere anywhere state NEW

Does it accept all traffic and makes the iptables useless.

reggie commented Mon Feb 06 20:02:08 UTC 2012:

How do you limit ssh access to a single ip?

install how to enable telnet on redhat linux commented Thu Aug 28 15:49:52 UTC 2014:

I leave a response whenever I appreciate a post on a website or I have something to valuable to contribute to the conversation. Usually it is triggered by the passion displayed in the post I read.

And after this article Slicehost Articles: Introducing iptables part 3. I was actually moved enough to leave a thought :-P I do have 2 questions for you if you usually do not mind. Could it be just me or does it look as if like a few of these remarks appear like left by brain dead people? :-P And, if you are posting on other sites, I'd like to follow everything fresh you have to post. Could you list the complete urls of all your public pages like your Facebook page, twitter feed, or linkedin profile?

Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)