iptables - Configuration (part 2)

So now down to the nitty gritty of actually getting rules written for iptables.

To add a rule the commands can range from very simple, to long and complex.

The simplest type I use is something like this:

A quick break down of this:

• iptables – the program called to run the command
• -A – Append the rule, here to the chain INPUT
• -d – Destination address the packet is trying to get to
• -p – Protocol, here tcp but could be udp.
• -dport – Destination port, where is being accessed, here is port 80 for http
• -j – Jump, this says what to do if everything in the rule is matched, so if everything is okay, the packet is accepted.

The first tip I learnt was to write these commands into a bash script, as having to re-type them (even with bash_history) would be a laborious task when clearing and reloading rules during the configuration phase.

So I write commands like this for all the ports I want open, and then finish the bash off with:

This tells iptables to drop, firstly anything sent to me, then anything trying to pass through my ip. You may wonder why I’m dropping everything, surely that invalidates all the previous rules? Well no, it doesn’t as when a rule is matched it immediately jumps to its destination ignoring all else, which is why these must come at the end of the rules.

You may also be wondering, why DROP? I’ve heard about REJECT. The difference between them is subtle, as both drop the packets. However, reject sends back a response to say ‘no access’. So to minimise traffic, it seems best from my point of view to drop anything else.

There are advantages and disadvantages to doing it both ways, but so called stealth isn’t really a reason for or against either. A port scan will return closed on reject, and open on accept, but something like filtered on dropped packets, so there isn’t much stealthy advantage.

Now, there is a lot more that can be done, the rules I’ve mentioned so far are truly the most basic, but more on that in the next part. I also mentioned Chains, those will come up again sometime in the future. I also still haven’t covered how to actually make this into a working firewall.

More advanced configuration in part 3.