How to: Linux General – Basic IPTables via Command Line

Verified and Tested 02/16/2015

Introduction

A basic guide to securing access to your server with iptables.

Prerequisites

Server running CentOS 6.5 or earlier (these instructions could also work under other distributions of Linux, though with slight changes based on the distribution;

this article will work from CentOS 6.5) If you do not have a server already, consider firing up a virtual private server from Atlantic.Net

iptables installed

Starting with basic IPTables via Command Line

First, let’s verify that iptables is installed and active (all of these commands will require root privileges, so ensure that your user has access to these privileges–or,

if you’d prefer, elevate to root and obviate the need to preface all of your commands with ‘sudo’)

sudo service iptables status

service iptables status

For this new server, iptables is not running, so it’s currently allowing all traffic in. Not good. Let’s fix that.

To cover some basics, we’ll be setting the default behavior to drop all traffic and allow only certain traffic in (this is a security practice often called “whitelisting”).

We’ll first do it all on the command line, and then we’ll set it up so those rules are persistent across reboots.

First, let’s start the service and then check to see what’s running.

sudo service iptables start

sudo service iptables status

Note that the default policy in each of these chains is to accept traffic. Let’s change the default for INPUT to drop traffic.

(WARNING: be sure you have at least one ACCEPT rule in the INPUT chain to allow either your workstation IP address or port 22

if you are accessing this server remotely over ssh. In the above output of the iptables status, note that TCP traffic to port 22 (“tcp dpt:22”) is accepted.

If that rule weren’t there, we could lock ourselves out of this server!)

sudo iptables -P INPUT DROP

The ‘-P‘ indicates that we will be making a change to the overall policy, ‘INPUT‘ is the particular chain to edit, and ‘DROP‘ is the default policy target.

Now, let’s add some specific rules.

First, we’ll allow access for HTTP and HTTPS traffic, which we’ll want accessible from any IP address. When adding rules to iptables,

it’s important to pay attention to the order of those rules since iptables parses rules in order and will process traffic according

to the target indicated in the rule and then exit the chain (in most cases).

In the output above, note that the last rule will reject traffic. If we append an allow rule to the end of this chain, it will never be invoked,

since the reject rule above it will reject the traffic and stop processing any following rules in the INPUT chain.

So, let’s find out which at which line number we want to insert our new rule:

sudo iptables -nL INPUT --line-numbers

Iptables status

The ‘-nL‘ combines a couple of flags: ‘n‘ skips DNS resolution (so we can see which IPs each rule examines); ‘L‘ lists each rule in the indicated chain.

The final option, ‘–line-numbers‘, appropriately enough, adds line numbers to each rule entry. (This output is similar to what you could get with

‘sudo service iptables status‘, but that command provides the rules for all chains, whereas the ‘iptables‘ command above gives us the means to

narrow down the scope of the output by individual chain.)

In this case, we’ll insert our rules just above the reject rule:

sudo iptables -I INPUT 5 -m tcp -p tcp --dport 80 -j ACCEPT

sudo iptables -I INPUT 6 -m tcp -p tcp --dport 443 -j ACCEPT

Iptables list with line numbers

What does all this mean?

* ‘-I‘ indicates that we will be inserting this rule at the indicated line number (the number following the name of the chain within which we are inserting the rule).

* ‘-m tcp -p tcp –dport 80‘ specifies that this rule will match TCP packets arriving in with a destination port of 80 (or 443, in the case of the second rule).

* ‘-j ACCEPT‘ indicates that, if this rule is matched, then “jump” this packet to the ACCEPT target (which is the long way of saying it’s allowed through).

 

Note that once we enter the first command, the reject rule would be pushed down to line number 6, so that’s why the second rule inserts itself on line number 6.

 

Now, let’s add a rule to allow access from a particular IP, regardless of type of traffic or port.

sudo iptables -I INPUT 4 -s 192.168.0.1 -j ACCEPT

Here we’re inserting this rule just above the rule allowing all ssh traffic on line 4. The ‘-s‘ specifies source IP. We could just as easily have allowed a source IP range using CIDR notation as well, so to allow the entire 192.168.0.0/24 range:

sudo iptables -I INPUT 4 -s 192.168.0.0/24 -j ACCEPT

We could make this rule more specific–say we only want to be able to ssh into this server from that 192.168.0.1 address. Let’s also go ahead and throw in a comment!

sudo iptables -R INPUT 4 -s 192.168.0.1 -m tcp -p tcp --dport 22 -j ACCEPT -m comment --comment "Only home workstation can ssh in"

First, since this rule will replace our earlier on, note the ‘-R‘–this means ‘replace’ on the indicated line number instead of insert. This rule combines checking for source IP and destination port, so in order for it to allow traffic, we’ll have to match both. The final match option for the comment is optional, but it can be very helpful when listing iptables rules to indicate briefly why that rule is in place–which can be super helpful when your iptables rules get more involved, or when there are rules that aren’t immediately self-evident when listed (such as the one for the loopback interface, which I’d added the comment for earlier).

 

We could, at this point, remove the rule allowing any IP to access this server via ssh:

sudo iptables –D INPUT 5

(The ‘-D’ specifies that the indicated line number in this chain will be deleted.)

Once are done adding rules, be sure to save:

sudo service iptables save

This will save your currently running iptables rules in /etc/sysconfig/iptables so that, the next time you restart your server,

it will automatically load the rules you’ve spent the time entering here. If you want to edit your iptables file with more descriptive

comments (or manage a larger, more intricate set of firewall rules), see the article on Basic IPTables File Configuration.