Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What do you do when setting up iptables: change the default policy (iptables -P INPUT DROP, for example) or add a catch-all rule at the end of the ruleset (iptables -A INPUT DROP)? If you do prefer one in particular, what's the rationale behind your preference?

This may be too subjective a question for this forum, but perhaps there are some good hard reasons to choose one over the other that I'm not aware of.

Against the policy way I have that it's probably easier to lock oneself out of the server due to an overly optimistic iptables -F. For it I have that it's probably easier to delete the catch-all rule without noticing it, effectively leaving the server wide open (I've had this happen to me in the past).

It's true that you shouldn't rely on the firewall as your only protection from the internet (most of the time you can make internal network services bind only to localhost or the internal network, for example) but sometimes one is forced to expose semi-public services to a specific source network, etc.

Personally I tend to prefer the first if writing a ruleset from scratch, but stick to whatever's in place already if updating an existing one.

share|improve this question
up vote 3 down vote accepted

I use both, setting the policy, and a final drop rule, because I am hardcore like that.

I have my rules defined in a script that I call and update. I never directly call iptables directly other then to occasionally list the rules/stats. I have never really seen a reason why one is better then the other.

share|improve this answer
Thanks for your answer, that's what I thought. And you're right - no reason not to use both either, probably. – Eduardo Ivanec May 10 '11 at 12:04
Actually there is a reason to use both. There is no REJECT policy, so if you are a nice guy the last catch all rule is REJECT (which is nice because it will fail fast!), and if you are fearsome (like me) you add a policy of DROP – Server Horror Aug 29 '13 at 21:12

Here are two reasons why having a catch-all rule may be better:

  1. The default policy has limited options. If you don't want the packet to go through you have once choice: DROP (packet hits the floor). In the catch-all rule you can use REJECT which can send an ICMP response.
  2. If you have any scripts that parse the output of iptables -L, the catch-all rule appears in the same format as all the other rules, making the parsing easier.
share|improve this answer
Interesting points, thanks. – Eduardo Ivanec Jun 20 '11 at 12:44

In terms of trade-off, I would prefer to have a machine w/o a firewall for a period of time, by accident (which is the risk of having -P ALLOW if you flush your rules and forget or similar) than have a machine drop off the network by accident (which is the consequence of a flush if the policy is DROP). My reasoning is, the firewall is not the sole method of securing my servers, so the firewall malfunctioning is an error rather than a catastrophe. A service being unavailable to users most often is a catastrophe.

share|improve this answer
That's true too, but what would you prefer to have: one hour of server downtime while someone at the site reboots the server, or a couple of months of complete internet availability of every port when you flush the rules and don't notice it? Perhaps it depends on how many ports you're forced to leave open, of course. – Eduardo Ivanec May 27 '11 at 15:43
It is a matter of preference. I'd prefer the latter, as it's a theoretical risk rather than an actual service-impacting issue. – jmtd Jun 20 '11 at 12:42

Something I just noticed: the DROP policy allows you to append rules to the ruleset using iptables -A after the fact. This can be handy as it allows you to keep the ruleset ordered easily, and can be specially useful when you construct the ruleset on-the-fly (saving it afterwards with iptables-save or something like it).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.