Basic Firewalling with iptables

The standard for firewalling on linux has been iptables(8) for many years. Most distributions have their own configuration tools to help create firewalls and they have some merit, but here I'll describe some basic information that is generic and therefore valid across distributions.

The exact functionality available in your linux kernel's firewall is dependent on how your kernel is built and what version you have. If you're rebuilding a kernel, the relevant options are under 'Network Packet Filtering Framework(Netfilter)'. I'm not going to use anything exotic in this article, it will probably just work with 2.6.x kernels offered by almost any distribution.

Like many of my articles, I am only considering machines that run services that listen to network requests. The considerations and requirements for say, standard desktop/laptop usage would be quite different. Also, I'm not going to discuss routing here, so the only chains that we're concerned with will INPUT and OUTPUT.

Why should I use a firewall on my server?

The purpose of using a firewall is to increase the security of your environment and as such, should be considered as part of your overall security strategy. It's more layer of defence.

If you are concerned that there might possibly be a vulnerability somewhere in:

the software that listens to network requests on your servers
the configuration of any of that software

If you are not concerned about this, it implies that you are not thinking about security and shouldn't be running network services in adversiarial environments like the public internet. Furthermore, if you're not running a firewall of any kind, you'd better have some justification; nowadays, it just looks like negligence.

Yes, there is a cost involved in terms of direct time to administer the firewall rules and a complexity cost (who hasn't spent time wondering why $foo service is unreachable only to discover that it's blocked at the firewall?) and it's conceivable that it's not worth it in some situations, but current common practice recommends firewalls for public network servers.

Working on firewalls

If you're developing firewalls on a remote machine, you'll probably lock yourself out at one point or another, so make sure you have a way to get back in.

In order to be able to get back in once you've locked yourself out while developing rules, you could create a cronjob that runs iptables -F every ten minutes or so to reset the firewall. Then comment out the cronjob once you're happy with your new rules.

Basics

Each firewall rule is created by the execution of an iptables(8) command. Its parameters specify the characteristics of the packets to which the rule will be applied and the target which is what happens to matched packets.

Criteria

There are many potential criteria for matching packets but the simplest and most commonly used are:

source location (--source, -s,--src):

where on the network did it come from? An IP address or CIDR location, can be negated with !.
destination location (--destination,-d,--dst):

where on the network is it going to? An IP address or CIDR location, can be negated with !.
protocol (--protocol, -p):

specify a protocol. I'm only concerned with TCP or UDP for now.
source port (--sport):

specify an originating tcp/udp port or port range.
destination port (--dport):

specify a destination tcp/udp port or port range.
mark (--mark):

specifies a mark value which has been assigned by a previous rule using the MARK target

Targets

The target specifies what to do with a matching packet.

ACCEPT
DROP
REJECT
LOG
MARK

These are largely self-explanatory. The distinction between DROP and REJECT is that REJECT sends an error packet back and can be useful for troubleshooting, at the least. Opinions vary on whether one should use DROP or REJECT in general. Those wanting to be considered 'Well Behaved' should probably use REJECT, but using DROP is less of a drain on your system and more of a drain on the originator. Of course, unless this target fires a lot, you'll likely not notice the difference.

Commands

Append a rule to the chain:

-A, --append <chain> <rule-specification>

Insert a rule to the chain at the numbered location, default 1 (beginning):
```
-I, --insert <chain> [rule-number] <rule-specification>
```
List all the rules in the specified chain, default all:
```
-L, --list [chain]
```
Delete all the rules in the specified chain, default all:
```
-F,--flush [chain]
```

Examples

Accept TCP packets for mysql from localhost, drop them from other sources:

iptables -A INPUT --src 127.0.0.1/8 -p tcp --dport 3306 -j ACCEPT
iptables -A INPUT --src ! 127.0.0.1/8 -p tcp --dport 3306 -j DROP

Accept traffic that is in response to locally initiated, outbound packets:
```
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
```
Drop other traffic that came in to the (external) address:
```
iptables -A INPUT --dst $EXT_IP -j DROP
```

Drop new connection requests above a certain rate:

iptables -A INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 300  -j DROP

Rate limit concurrent sessions to a port per ip address:

iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 80 -j REJECT --reject-with tcp-reset

Store IP addresses that are initiating SSH connections and drop packets from those addresses if new connections are coming in too fast (>4 in 2 minutes):

iptables -A INPUT -i $EXT_IP -p tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
iptables -A INPUT -i $EXT_IP -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 120 --hitcount 5 -j LOG --log-level info --log-prefix "Blocked as SSH Scan: "
iptables -A INPUT -i $EXT_IP -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 120 --hitcount 5 --name DEFAULT --rsource -j DROP
iptables -A INPUT -i $EXT_IP -p tcp --dport 22 -m tcp -j ACCEPT

Linux has had sophisticated routing functionality for years, here's a list of some sources that I've used for information:

Linux also has Quality of Service (QOS) functionality, also known as "traffic shaping" or "traffic control", the latter terms gives the tool its name: tc. The web has a dearth of information about tc, but there is some:

AllGoodBits.org