Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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 are some of the most common and wrong ways to configure a firewall? I'll start the list with the following:

Blindly blocking ICMP. This was common practice in 1998 when smurf attacks were all the rage. Today you run the risk of creating a PMTU black hole and making it hard to diagnose problems. If you must block ICMP, at least allow fragmentation needed and echo request/replies through.

Stale Rules. It's too bad we can't set an expiration date on rules. When I migrate a service I often forget to remove the rules for the old service.

share|improve this question
This could get somewhat argumentative, methinks. – squillman Aug 10 '10 at 19:41
Good point. I've toned down my example a bit. Hopefully we can dispel some myths without any poo-flinging. – Gerald Combs Aug 10 '10 at 20:05

Opening it up to get it working... then never coming back and locking anything down.

share|improve this answer
default policy: accept, after a fully tuned ruleset, because otherwise some detail won't work. Seen it way too many times. – Joris Aug 10 '10 at 21:14
+100 - I was tempted to get violent last time I heard, "But something might stop working, and we can't spare the time to lock it down one port at a time." BUT THAT'S OUR JOB... /headdesk – Kara Marfia Aug 10 '10 at 22:26

Subsequent to John's example - not using comments against rules if your firewall supports them.

There's nothing worse than seeing a firewall for the first time and seeing all sorts of strange rules that make no sense to the naked eye, and the comments are all blank and there's no documentation.

share|improve this answer

On the subject of stale rules, as per your example - Proper documentation and procedures WILL eliminate such issues. I suggest that your problem is not at the firewall at all.

share|improve this answer
It will also help when someone comes along and says "Hmm, why are we blocking outbound port 4345 from this single IP address? I wonder if I just delete (not disable) this rule what will happen..." and then the universe explodes. – Mark Henderson Aug 11 '10 at 0:39
And of course we then tackle the subject of version control... – John Gardeniers Aug 11 '10 at 3:57

Personally I consider splitting inbound and outbound rules into two main groups being an anti-pattern. Having to deal with two huge groups is a nightmare. I prefer to group rules for incoming and outgoing traffic that is related to a certain protocol/application. This way is much easier to manage them.

share|improve this answer

Move the problem elsewhere.

eg. local PCs firewall is stopping some service or app working, so disable it completely and say "the firewall on the edge router will be ok to protect all the PCs".

share|improve this answer

Hand-crafting and maintaining them.

Ancient 3rd-party scripts that "work good enough so we won't bother replacing them", require manual editing instead of using config files, and are completely incomprehensible to people who haven't read the thesis describing how they work.

share|improve this answer
Sounds more like a commenting/documentation problem than the fact that someone wrote a script. – Chris S Aug 11 '10 at 14:55
@Chris edited accordingly. – Andrew Aug 11 '10 at 15:57

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.