Setting up your first firewall via SSH

Ok, now you have just acquired your first remote server, and you are about to configure its firewall via SSH. This is an important step that you must get right if you don't want to find yourself locked out of the server with no possibility to restore your remote access.

Introduction

There are many firewall front ends which are supposed to make administering firewalls a breeze, but most if not all utilize iptables as their back end. Iptables is itself a Linux user-space front end for Netfilter, the kernel-space back end. Therefore, the examples here will directly use iptables. You are free to transpose the rules for your chosen firewall front end.

Rules are executed in order. Only the first rule that matches the current request applies, so it's important to get the ordering right.

Hidden dangers of front ends

The first rule, then, should be to allow SSH connections, allowing you to peacefully continue remotely administer the server.

Here is good example why using some front ends can lead to disastrous outcome. Front ends are supposed to make life easier by having a user-friendly syntax. For example, with ufw (Uncomplicated Firewall), allowing SSH connections over TCP is supposed to be as simple as typing the following command:

The command is quite explicit and clear. However ufw assumes that SSH is always on the standard port 22. What if for security reasons you are using a different port for SSH? If after adding the above command, you add another command to drop all connections, you will find yourself locked out of your server as soon as you enable the firewall.

That's why it's important to understand what you are actually doing, and how the commands entered with your front end are translated in terms of actual iptables rules.

Safely testing a remote firewall

Starting and stopping the firewall

In order to safely create our first firewall over a remote SSH connection, we are first going to learn how to stop and start the firewall. By default, iptables is enabled but comes with an empty rule set which lets everything in and out:

For Red Had and derivative distributions (CentOS/Fedora Core), iptables is set up as a service. Thus saving/stopping/restarting the firewall is pretty straightforward:

With other distributions (Debian, Ubuntu, etc.) we are going to use a simple script to help us.
We are going to:

1. Create a script to reset the firewall (disable it).
2. Add a cron job to periodically rest the firewall (to avoid being locked out in case we make a mistake).
3. Add a simple rule and save it.
4. Check that the cron job does its job.
5. Restore our previously saved rules.
6. Add more elaborate rules (those that have the potential of locking us out if things go wrong).

Reset the firewall

We are going to use the script below:

Save this script, make it executable.

Add a cron job

Edit /etc/crontab and add the following line:

Further down, we are going to make sure that this cron job effectively disables the firewall every five minutes.

Create a first rule

We are now going to create our very first rule in the chain INPUT of the table 'filter' (the default table).
For the command below, check the significance of each parameter in the iptables manpage:

This rule is to accept tcp connection on the port 22 (the default SSH port). Since the default for the chain INPUT is ACCEPT, and since there are no other rules, this rule on its own does nothing more: everything is still accepted.

But now, we can check that the rule has been added to our iptables rule set:

We are now going to save our rule set to a file before the cron job flushes everything:

Then, after 5 minutes, check again with iptables -L to see whether the added rule has been flushed.

Restore our iptables rule set

Now that we are certain that the firewall is completely reset with the cron job, we can restore our previously saved rule set:

Check again that everything is as it should be at this stage.

Adding common rules

Now that we are certain that we are not going to be locked out of our remote system, we can start adding more rules, periodically saving them.

Our last rule will be to drop everything, but first, we must explicitly allow the incoming traffic that we actually want.

For all the examples below, check the iptables manpage for an explanation of each parameter. This way, you will learn much more than if we were to explain ourselves the significance of each.

Accepting traffic

- Accept establish connections:

- Accept SSH traffic:

Note that the above will allow traffic on the standard port for SSH, i.e. port 22. If for security reasons you have configured SSH to use another port, you will have to specify it explicitly:

See /etc/ssh/sshd_config for the exact port used.

It is important to get this rule right, because it is the one that will allow you to remote administer your server.

- Accept any traffic on the loopback interface. We insert this rule at the 1st position.

To see the list of interfaces on your server, do:

- accept HTTP traffic:

- accept DNS traffic, if you operate a name server:

At this stage, you may want to check the list of TCP and UDP port numbers, checking for any service you might be running and accept the related traffic.

Blocking traffic

We are now ready to actually block some traffic. We are going to log all dropped traffic. For this, we are going to create a custom chain that we shall name 'logdrop':

iptables -N logdrop

We are going to add the following two rules to this chain:

Thus, any traffic that is handled by this chain will be logged and dropped.

Having previously accepted all traffic on the loopback interface, we can now drop all other traffic (i.e. all other traffic on the eth0 or other interfaces).

Testing your firewall

Now that the firewall is all set up, it is time to test it.

Use ping to test the ICMP.
Use nmap to test specific ports via UDP/TCP, e.g.:

You can also use telnet

Other tutorials

IptablesHowTo at the Ubuntu wiki.