gatherer:~#

//Post 3: Linux Firewalls With iptables//

Ahoy!

So today I thought I would write about iptables. Boy oh boy, the firewall unit in my Linux administration class was quite the headache to get my head around. But in true Linux fashion, practicing it and taking notes as I implemented it helped me make sense of it in the end. I reckon I could conjure up a mighty firewall now if required! The crux of it, I found, was memorising the options for the rules. Let's get stuck in!

To make things easier, we've been using a simple bash script to write the rules and execute them one by one. At the top is a triad of iptables -F {chain} to flush the existing tables and iptables -P {chain} DROP to set the default policy to DROP. This is the more secure method, meaning we have to explicitly accept anything we want going in, out, or through our firewall. Reminds me of the policy of least privilege.

From here each rule can be stated one at a time. The firewall works through them, one line at a time, until it hits a DROP or an ACCEPT (or maybe even a REJECT!). This allows for quite granular control. Entries are something like:

iptables -A FORWARD -m conntrack --ctstate NEW -p tcp --dport http -d 192.168.1.5 --out-interface eth9 -j ACCEPT

What a mouthful. It's easy enough when you take a little piece at a time.

iptables -A FORWARD - invokes the iptables command and says to append the rest of the line to the FORWARD chain, for packets going through the firewall.

-m conntrack --ctstate NEW - specifies that we're using connection tracking and to match for NEW connections

-p tcp --dport http - selects TCP, matches for a destination port of 80 (http default port)

-d 192.168.1.6 - matches a destination IP in the packet

--out-interface eth9 - specifies the interface from which the packet departs

-j ACCEPT - finally, if all tests are true, joins the packet to the ACCEPT line

There are numerous other options and flags that can be put into these commands, including options to match true if the requests exceed a certain about within a time limit, options to specify source and destination ports/IP addresses, the very nifty not (!) modifier... presumably a whole lot more!

While I can see how this can be applied to the creation of a fully functioning Linux firewall, I think I shall stick to pfSense for the time-being. Better the devil you know, eh?

- Adam