Tim wrote: > Shouldn't that be the other way around? You've allowed various things,
then disallowed everything (which logically should include what you've previously allowed).
But that isn't quite how it works. As a packet traverses your chain and it matches a rule it follows that rule. For example, if the first rule in your chain is to ACCEPT incoming traffic on port 80 to your machine then packets that come in to port 80 on your machine match the first rule and are accepted, no longer following the rest of the chain.
If your first rule is a DROP then traffic will be dropped *before* it gets a chance to be accepted.
My default policy (first action) is to drop packets, then I open up holes for a few things I'm happy about. Works well for me...
Default policy isn't so much the first action, but the action to take if a packet didn't match anything in your chain. It is what happens if a packet failed to match any of the ACCEPTs in your chain, it will drop it. As you add rules to a chain, they will be consulted before the default policy and acted on.
So in your example one of the first thing you do is define the policy of the chain, or what will happen if a packet doesn't match any of the rules you add later.
This is from the Netfilter site in the section regarding how a packet traverses the rules:
"A chain is a checklist of rules. Each rule says `if the packet header looks like this, then here's what to do with the packet'. If the rule doesn't match the packet, then the next rule in the chain is consulted. Finally, if there are no more rules to consult, then the kernel looks at the chain policy to decide what to do. In a security-conscious system, this policy usually tells the kernel to DROP the packet."
/jft
