Main Content

Setting up your Linux system as a firewall using iptables

Archive - Originally posted on "The Horse's Mouth" - 2012-04-02 07:49:21 - Graham Ellis

During last week's Linux course (a private one) we took a look at firewalls using iptables.

iptables can be run on an individual Linux machine, controlling the traffic that's allowed in and out, and turning that machine into its own firewall:


* INPUT rules control the outside agents that can contact (or attempt to contact) services running on the firewalled systsm

* OUTPUT rules control the services (and locations of services) that users of the machine can contact, or attempt to contact

iptables can also (usually more commonly and usefully) be run on a gateway machine - a Linux machine with multiple interfaces, where additionally you can specify:

* FORWARD rules control the service and ports that can be passed through the machine from one network to another, without being subjected to both the input and the output rules.

The three routes that you can control on a firewall. Rules are specified based on each interface, so in addition to my set of three shown on the diagram, there will be another set of three controlling traffic from the world into your network, and don't forget the local loopback adapter too. There's a sample configuration file [here] which demonstrates some first principles, using a machine with a single external connection.


Let's set up our machine so that we:
* Allow the user of the machine to make use of any external services (s)he may want to contact
* Restrict incoming requests to a limited number of carefully selected services on a potentially dirty and dangerous network

Step 1 - set up the basic rules:

  iptables -P INPUT DROP
  iptables -P OUTPUT ACCEPT
  iptables -P FORWARD DROP

We're starting from a default in our machine where nothing is allowed in, anything is allowed out, and nothing is forwarded. DROP means that our system pretends that there isn't a system there at all, rather than sending back any sort of response to say "go away".

Step 2 - once traffic has been allowed, allow it to continue

  iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

We're now modifying the input rule. If we get an input as a result of an outgoing question we've asked, we need to get that answer back, which wouldn't happen if we left the input rule unmodified.

Step 3 - allow additional incoming services

This is optional and only needed if your machine's to be a server. The sample file (link above) allows ssh, DNS, Ldap and FTP traffic on their default ports. It also allows port 80 (web server / http) traffic. Here are some of the extra iptables ommands (the ssh and http ones):

  iptables -A INPUT -p tcp --dport ssh -i eth0 -j ACCEPT
  iptables -A INPUT -p tcp --dport 80 -i eth0 -j ACCEPT

For some of these services, you'll need multiple ports, and perhaps to allow udp traffic as well as tcp.

Step 4 - allow local loopback

Every Linux box will have multiple services running, and these may want to contact each other within the system. For example, your local web server (which can be contacted using the rule above from outside) may want to contact a MySQL daemon that can't be accessed directly from outside:

  iptables -A INPUT -i lo -j ACCEPT

Potentially, this is a vital rule - all sorts of standard bits of software contact each other via the loopback adaptor, and failure to specify this additional rule can result in quite a few things not working.

Step 5 - allow pings

Optional, again. Do you want your machine to respond to pings? The sample file contains the lines you need to do this, while looking to configure ping in such a way that you don't get flooded when handling aggressive external (flood) pinging.

Please note - setting up a firewall is NOT your total answer to "security"!. Although we have restricted traffic in our example to services of our choice, we have not considered the security of each of the individual services we have allowed through. We need to consider the security of each of those allowed services individually, including the possibility of security breaches which use those services as their means of transport - for example, an injection attack to a database which uses a flaw