An Introduction To Iptables: The Linux Firewall – Part 3

29th May, 2017 by

In previous posts, we introduced you to iptables and covered how it works. Last time, we looked at how you would configure the rules for your firewall at the command line. This time, we’ll look at an alternate method allowing you to edit a configuration file and give some general guidance on rules you should be setting.

We previously mentioned iptables-save and iptables-restore commands for saving and restoring your iptables chains and rules. A handy tip about these files is they are simply a listing of commands to be applied to iptables the same way that you would at the command line. This means that an alternate method of editing your firewall rules would be to use iptables-save to save the current configuration, then add or remove lines from the saved file, then restore the file. For example:

sudo iptables-save > ~/iptables.rules

nano ~/iptables.rules

sudo iptables-restore < ~/iptables.rules

To break down the commands, the first saves the iptables ruleset into the current user’s home directory (denoted by the ~ symbol). We can then edit the file in nano.  Afterwards, the file can be save and then imported into iptables using iptables-restore.  

This method of editing the firewall rules can be very useful when you are new to iptables or are having to work on more complicated rules. This will allow you to copy an existing line with a working rule and then paste it in and edit it to suit the new intended purpose. You can also keep a constantly saved copy that you work from and always only restore into iptables which can allow you to add comments around lines to make it easier to see the intention of the various rules. Working like this requires all the users on the server who manage the firewall all work the same way. This is as if someone sends a command directly to iptables to alter the configuration it won’t be reflected in the file and will be removed on the next restore. Saving again from iptables will lose any comments from the file.

Some general guidelines to work to when designing your firewall rules are as follows:

1) Always use a default policy of DROP and add rules to ACCEPT traffic that you know you want to get to your server.

This can be annoying when you miss a rule and it blocks something from accessing your server, but it’s better than missing a rule and leaving something open to the internet.

2) Check your rules regularly and remove any that are no longer relevant.

Keeping up on what rules you have in place can keep you focused on what’s important.

3) Restrict access to your server as much as possible.

By this, I mean where-ever possible when granting access to a port on the server specify the source IPs that are allowed to connect to it. Only allow access to the whole internet when absolutely necessary, such as ports 80 and 443 on a web server. You should never allow access from the whole internet to management services such as SSH, or your control panel management ports if you use one.

4) Don’t leave your firewall disabled.

It’s easy for me to write “Never disable your firewall” here, but that very much ignores the fact that the real world isn’t that easy. Sometimes to debug communication problems, you may need to disable your firewall.  The key thing is that if you do, you must remember to re-enable it afterward.

This is the end of our introduction to the iptables firewall. Hopefully, you’ve gained an understanding of how it works, how to configure it and should be able to successfully firewall your own server.