How to: Basic IPTables File Configuration

Verified and Tested 02/07/2015

Introduction

This article will discuss configuring iptables via the /etc/sysconfig/iptables file, which can be useful if you have an intricate set of rules to keep track of or if you’d prefer not to have to deal with all the flags and options involved with configuring iptables via the command line.

Basic IPTables File Configuration

One of the primary benefits of manually configuring the iptables file is comments. While you can utilize comments via the match module (‘-m comment –comment’), you can make more extensive use of comments in the iptables file itself using the ‘#‘ character at the beginning of the line:

# This is a comment and will be ignored when iptables is loaded

So we have a point of comparison, let’s take a look at what an iptables files might look like if we save via the sudo service iptables save command.

sudo service iptables save

That might be fine when we have this small number of rules, but imagine if we had hundreds of rules to keep track of. It might be difficult for us to parse through those rules without a little commentary to help us remember what the intent of creating those rules was in the first place. So, let’s add a little commentary. Use your text editor of choice to open an editable copy of the iptables file (the following screenshots were taken from vim, but we’ll include nano in the command entry to make things easier for new learners):

sudo nano /etc/sysconfig/iptables

This is (with one exception) the same file as the one without comments above. If you’re not the sort used to reading through a bunch of iptables rules, this file can be a lot less intimidating (and if your comments are clear enough, they can even remind you how a particularly intricate rule is supposed to work!).

The sharp-eyed may have noticed that the ssh rules in this iptables file are a little flimsy, in that the second line (in allowing all ssh traffic in) essentially invalidates the point of the first line specifying that one particular IP is allowed to ssh in. These rules are configured to demonstrate some basic rule formats. In production, you’d likely have a more restrictive set of rules in place.

There is one rule change to take note of between the two iptables rules sets. In order to demonstrate another use of the comment character, we’ve added the “#” before the INPUT rule specifying that we reject traffic that doesn’t match any of the preceding rules and added a new rule that says we should log all traffic before taking the default action for this chain (DROP). (More information on logging iptables activity can be found in this article on basic troubleshooting of iptables). Since we’ve only commented out the REJECT rule, if we wanted to, we could remove the one “#” character to reinstate that rule, instead of having to type it out again. This can be useful while testing various rules or for including a rule you might want to activate in the future or for a limited time.

Note that each rule in the /etc/sysconfig/iptables file begins with the ‘-A‘ command. If you are familiar with adding using iptables on the command line, you may recognize that these rules look very similar to what follows the sudo iptables portion of the command when making iptables changes via the CLI. The ‘-A‘ command indicates that the rule should the appended to the end of the indicated chain. Note that no line number is required (as it might be for ‘-I‘ or -R‘) since ‘-A‘, by definition, will add the rule to the end of the list of rules in that chain. This is why the order of rules is important since iptables filters traffic by parsing these rules in the order they fall in the chain.

Once you have completed any edits you want to make to this file and saved it, you’ll need to load the new rules. The simplest way to ensure that all changes are loaded is to restart the iptables service. This action will flush all current iptables rules running and then reload the rules as they currently exist in the /etc/sysconfig/iptables file.

sudo service iptables restart

Now, let’s add a new rule, and we’ll include an error so we can see what happens when we restart the iptables service:

Yep, “tco” is certainly an unknown protocol. This output is kind enough to provide the line number in the file at which it encounters the error and a brief description of the error, so that’s one benefit. But then this output also points to one disadvantage to making changes to your firewall rules via the /etc/sysconfig/iptables file and restarting the entire service. Note the first line of the output indicates that all chains are being set to ACCEPT. The following lines flush all the rules and unload all modules, all of which complete successfully, as indicated by the bracketed “OK”s. When the iptables service encounters the error while reloading, it fails to load the entire iptables file. So that means your server is left without any filtering in place, and all chains defaulting to ACCEPT.

If you also have NAT or MANGLE rules set up in your iptables file, then you’d also lose your address translations there, so that can be one big drawback to making changes to the file and restarting the service wholesale.

Ideally, as your iptables rules set becomes more complicated, your best bet is to make any changes (with explanatory comments) in the /etc/sysconfig/iptables file and then to manually add the new rule(s) via the command line, especially if these changes are being performed on a production server. Your mileage may vary based on your needs.