Firewall questions about state and policy?

1. It is a good idea to apply your policies as early as possible. Put them at the start. DROP rules on internal traffic can cause problems.
2. This rule would be consideref a fault, as it implements and ACCEPT policy. Adding an accept rule per service is the correct way to build your firewall.
3. An accept policy indicates you are running a mostly open policy. (We locked the front door locked, but you can use any other door to get in.) Best policy is a mostly closed policy. We keep all door and windows locked, and only unlock the ones we need.
4. It would appear there is no difference, although all the rules I have seen use state. The conctrack module will monitor the state. Use this rule with the port accept rule in question 2 to enable services.

You may want to look at the Shorewall documentation to see what can be done with iptables. I use it to build a firewall on all my Linux instances (including OpenWRT). It has well documented sample (default/base) configurations for servers with 1, 2 or 3 interfaces.

The Linux Documentation Project also has documentation.

You didn't mention anything about the nat table, so I'm going to assume that this question relates to writing iptables firewall scripts for standalone servers, and not for multi-homed/gateway boxes.

1. You are correct: Each chain has a single policy, so it doesn't matter where or in what order that policy rules are stated.

2. This rule establishes a convention that many/most firewall scripts use: that of statefulness. Just a minor nitpick, though. I would not include the NEW state, and I would also include a rule for the INPUT chain, i.e.:

   $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

   $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

   I put these rules near or at the top of all of my firewall scripts, as they allow me to concentrate on creating rules for filtering connection attempts, and not have to think about non-connection-establishing packets. In my opinion, a firewall script without these rules is likely to be more complicated, and thus more prone to mistakes, than one that includes them.

3. This policy rule allows all outgoing traffic. As a policy, allowing everything is obviously less secure than allowing only explicit kinds of traffic. So if security is your utmost priority, you'll want to set a DROP policy on the output chain instead. Just be aware that you'll then have to include a number of rules to allow outgoing traffic to a possibly large number of mundane things, such as: DNS, SMTP, IMAP, POP3, HTTP, HTTPS, etc.