Understanding how Netfilter (iptables) works

As I've read a lot of articles about Netfilter, aka iptables, and most of them are confusing and hard to read, I better explain in this article the basics of this powerful wide available firewall.

Before you continue reading, be sure you understand how communications work in TCP/IP networks such as Internet or, probably, your own Intranet.

I'm not going to bore you with the history of Netfilter and where it comes from. However, it's important to notice that this firewall is integrated in the Linux kernel, so it's available broadway with no need of extra packages to be installed. In addition, it's quick and strong enough to be used in a wide variety of scenarios.

Network packets can come from, go to or pass through your firewall. Depending on the path it follows, different rules can be applied. Rulesets are named tables and tables are associated to chains. You can create your own chains, but that's not the goal of this article.

In a packet's lifetime, it passes through different chains containing rules, which may change, accept or deny the packet somehow. A policy determines what happens to a packet. There is a default policy for each chain.

The following image shows some of the basic chains and flows:

For a full description of filtering tables, please refer to this page.

Here are some examples of paths a packet could follow:

• Packets from another system to the firewall: PREROUTING and INPUT.
• Packets from the firewall to another system: OUTPUT and POSTROUTING.
• Packets from one system to another through the firewall: PREROUTING, FORWARD and POSTROUTING.

The order of the chains is always the same. For instance, PREROUTING comes always before INPUT and not the other way round.

To interact with Netfilter you can use the command line tool iptables, though it's not the only way.

Please keep in mind that any changes made will be losed after reboot. To avoid that, you can:

1. Save the tables state to a file with the command iptables-save and restore the rules from the file at startup with iptables-restore, or
2. Create a shell script with direct iptables commands to be executed at startup.

I prefer the later, for it allows you to use shell variables and to add comments to make the it more readable.

Anyway, the file created one way or the other should have reading permissions for the root only and placed in a secure directory.

When reading or executing the file at startup, it has to be done before the network interfaces are configured, for security reasons. To do so, you can place the rules or a shell script that reads them in the directory /etc/init.d/if-pre-up.d if you're working with Debian.

DHCP forwarding with a relay server

What if you have several local networks and you don't want a DHCP server on each? Don't worry about that! You only need a single DHCP server and many DHCP relay servers forwarding the requests to it.

I'll explain how to configure both servers using an example of two networks 192.168.56.0/24, on which is the main DHCP server, and 10.0.0.0/24, on which is the DHCP relay server, as shown in this figure:

The main DHCP server is an Ubuntu 12.04 precise and the DHCP relay server is a Debian 6.0.5 squeeze. The packages you need to install are:

• The DHCP server: isc-dhcp-server
• The DHCP relay server: isc-dhcp-relay

You are supposed to configure the main DHCP server for its own network and, in addition, you'll have to configure it for the other network(s). In my example, the end of the /etc/dhcp/dhcp.conf file looks like this:

option domain-name "local.net";

subnet 10.0.0.0 netmask 255.255.255.0 {

  range 10.0.0.10 10.0.0.20;

  option routers 10.0.0.1;

  option domain-name-servers 10.0.0.250, 10.0.0.251;

}

subnet 192.168.56.0 netmask 255.255.255.0 {

  range 192.168.56.10 192.168.56.20;

  option routers 192.168.56.1;

}

This is a very basic configuration and you might want to include more directives for your own networks.

When installing the package isc-dhcp-relay, the setup process will start automatically and it will modify the file /etc/default/isc-dhcp-relay. However, in case you might want to change something later, here's the content of the file for my example:

# Defaults for isc-dhcp-relay initscript

# sourced by /etc/init.d/isc-dhcp-relay

# installed at /etc/default/isc-dhcp-relay by the maintainer scripts

#

# This is a POSIX shell fragment

#

# What servers should the DHCP relay forward requests to?

SERVERS="192.168.56.2"

# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?

INTERFACES=""

# Additional options that are passed to the DHCP relay daemon?

OPTIONS=""

You can specify many DHCP servers to relay to of the interface on which to bind for requests. Just read the man page for more information.

After the changes and restarting both DHCP servers, the clients in the same network as the DHCP relay server should be able to requests an IP address (try with sudo ifup eth0 on the client):

Listening on LPF/eth0/08:00:27:2b:4c:c3

Sending on   LPF/eth0/08:00:27:2b:4c:c3

Sending on   Socket/fallback

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4

DHCPOFFER from 10.0.0.2

DHCPREQUEST on eth0 to 255.255.255.255 port 67

DHCPACK from 10.0.0.2

bound to 10.0.0.10 -- renewal in 248 seconds.

Notice that the IP address was offered by the DHCP relay server, not the main DHCP server.

Now the interface is configured (type sudo ifconfig eth0 on the client):

eth0      Link encap:Ethernet  HWaddr 08:00:27:2b:4c:c3  

          inet addr:10.0.0.10  Bcast:10.0.0.255  Mask:255.255.255.0

          inet6 addr: fe80::a00:27ff:fe2b:4cc3/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:49 errors:0 dropped:0 overruns:0 frame:0

          TX packets:102 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:8373 (8.1 KiB)  TX bytes:17609 (17.1 KiB)

Just for curiosity, look at the end of the syslog on the main DHCP server and you will read something similar to this:

Jan  7 20:40:30 odin dhcpd: DHCPDISCOVER from 08:00:27:2b:4c:c3 via 10.0.0.2

Jan  7 20:40:30 odin dhcpd: DHCPOFFER on 10.0.0.10 to 08:00:27:2b:4c:c3 via 10.0.0.2

Jan  7 20:40:30 odin dhcpd: DHCPREQUEST for 10.0.0.10 (192.168.56.2) from 08:00:27:2b:4c:c3 via 10.0.0.2

Jan  7 20:40:30 odin dhcpd: DHCPACK on 10.0.0.10 to 08:00:27:2b:4c:c3 via 10.0.0.2

Jan  7 20:44:38 odin dhcpd: DHCPREQUEST for 10.0.0.10 from 08:00:27:2b:4c:c3 via vboxnet0

Jan  7 20:44:38 odin dhcpd: DHCPACK on 10.0.0.10 to 08:00:27:2b:4c:c3 via vboxnet0

Once again, it's the DHCP relay server who made the request on the client's behalf.

How to configure a SSH connection with no password

This is needed to:

• Move from a system's user to another system's user without typing the password.
• Allow automatic scripts to execute remote commands or copy / move data from one system to another.

Be aware of:

• If the user account you use to connect to remote systems is hacked, all your systems might be compromised.
• Do not allow root user to remotely connect without password unless necessary, for the risk is higher.
• The configuration is not bidirectional. You must do all the steps to configure the connection back from the remote to the local system.

In my case, I will show you how to configure a SSH connection from the user sergio of the local system odin (Ubuntu 12.04 with kernel 3.2.0-29) to the user coord of the remote system mudel (Debian 6.0 with kernel 2.6.32-5).

The steps are:

1. Create a pair of keys (public and private) in the user's home of the system you will use to connect to the remote system. The command to use is ssh-keygen.
   You can change the filenames where your keys will be stored.
   When asked about the passphrase, keep it empty, otherwise it will be required when establishing a connection to the remote system.
   sergio@odin:~$ ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/sergio/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/sergio/.ssh/id_rsa.
   Your public key has been saved in /home/sergio/.ssh/id_rsa.pub.
   The key fingerprint is:
   ce:bb:e5:75:e4:8f:23:67:09:12:c8:9c:39:ad:3e:bd sergio@odin
   The key's randomart image is:
   +--[ RSA 2048]----+
   |                 |
   |                 |
   |       o =       |
   |        B o      |
   |        So .  .  |
   |       o. . .o   |
   |       .o.....o. |
   |        o+....=o |
   |        ooE. +...|
   +-----------------+
2. A directory .ssh will be created, containing the two files. Be aware of keeping the permissions of the private key file (id_rsa) readable only by the owner.
   sergio@odin:~$ ls -l .ssh
   total 8
   -rw------- 1 sergio sergio 1679 ago 15 11:46 id_rsa
   -rw-r--r-- 1 sergio sergio  393 ago 15 11:46 id_rsa.pub
3. Append the content of the public key file (id_rsa.pub) to the file ~/.ssh/authorized_keys of the remote system. To do so, you might send it by e-mail, copy and paste, remote copy to a temporary file or use the ssh-copy-id tool, which will do all the work.
   sergio@odin:~$ ssh-copy-id coord@mudel
   The authenticity of host 'mudel (192.168.56.1)' can't be established.
   RSA key fingerprint is 0c:48:50:6c:67:df:1f:8c:ac:22:c2:ee:0b:a8:98:55.
   Are you sure you want to continue connecting (yes/no)? yes
   Warning: Permanently added 'mudel,192.168.56.1' (RSA) to the list of known hosts.
   coord@mudel's password:
   Now try logging into the machine, with "ssh 'coord@mudel'", and check in:
   
     ~/.ssh/authorized_keys
   
   to make sure we haven't added extra keys that you weren't expecting.
4. The first time you establish a SSH connection, the fingerprint of the origin system will be shown and you will be asked if it should be append to the ~/.ssh/known_hosts file of the remote system. Answer yes.
5. Now try to connect.
   sergio@odin:~$ ssh coord@mudel
   Linux mudel 2.6.32-5-686 #1 SMP Tue Mar 8 21:36:00 UTC 2011 i686
   
   The programs included with the Debian GNU/Linux system are free software;
   the exact distribution terms for each program are described in the
   individual files in /usr/share/doc/*/copyright.
   
   Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
   permitted by applicable law.
   Last login: Wed Aug 15 12:07:26 2012
   coord@mudel:~$