Not only do wrappers offer highly readable policy languages (some more readable than others), they usually provide a toolchain that adds some protection against foot shooting. For example, "firehol try" will:

1) save your active ruleset
2) load the candidate ruleset
3) wait for 30 seconds for you to type "commit"
4) roll back to the saved ruleset if you don't.

I cut my teeth on raw iptables, and I enjoyed showing off my iptables fu in front of others. But the flush of pride isn't worth the headache of having less experienced staff trip up all over your ruleset and toolchain.

This makes it extremely easy to avoid locking yourself out of a box. And all three of the wrappers I listed above embody all of your best practices, except perhaps for "Be stringent with your rules".

I appreciate that there are some arguments against wrappers. I used to spout all of these:

1) if you can't drive iptables, you shouldn't be operating a firewall
2) wrappers produce inefficient rulesets
3) you learn one wrapper, then find yourself lost when it comes to raw iptables.

In fact, I found none of this to matter when my business serviced numerous corporate firewall customers. What I found was:

1) wrappers made it possible for my staff to do -most- of the work
2) wrapper inefficiency only made a measurable difference for one, highly specialized firewall
3) staff took at interest in the generated raw iptables, using the wrapper as a learning aid.

Ciao,
Sheldon.

A couple of suggestions:
1) Carry out iptables actions from inside a "screen" session, particularly with chains of commands (as my understanding goes). This for one makes sure all the actions will be carried out, but also means that if you have accidentally screwed up you can re-attach and pick up where you left off from whatever other method you can use to get onto the server (different IP address, remote hands service(?)).

2) Have a "get out of jail free" card ready to hand. Either within the context of a screen session, or through the 'at' scheduler, have something in place to restore a working iptables configuration set for xx seconds / minutes in the future. Do your potentially disruptive thing, see if you've still got connectivity and if you have, stop that scheduled restore.

iptables aren't as complicated as some people would have you believe (whilst being incredibly powerful), but it is easy to make mistakes that you're often better approaching it from the perspective "I'm going to screw up" and ensure you've covered your arse appropriately

Not really. I've just found that even the most seasoned systems administrators will overlook the policy line on a chain if they're not used to looking for it. I normally check it when I log into a server that I don't normally administer, but that's only because I've been burned many times by it.

I like to make bash scripts to make my firewall.. You could use something similar.. Just create an array with your allowed ports and one with your allowed hosts. Then loop though the arrays accepting traffic from those hosts on the allowed ports. Here is an example if what I use. http://systemsninja.com/firewall.txt It does use a default drop policy which goes against this blog, but that can be changed with ease

Rackerhacker -
Is there any benefit other than what you named to not using a default DROP policy? I ask because a book I just finished reading: Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort suggested using a default drop policy. I did find moving to the default DROP made it very annoying for the first few hours while debugging trying to get my backups and system updates working (had to allow the outbound ftp AND http traffic).

I don't really have a specific ruleset to be honest. I normally just toss together some relevant rules for the particular instance I'm running. If you want to allow access on port 3306 for three IP addresses that aren't in continuous IP space, you'd have to write three separate rules for it.