Re: [fw-wiz] Linux Bridge/Firewall

From: Christopher Hicks (
Date: 11/29/03

To: Firewall Wizards mailing list <>, Chris Ditri <>
Date: Sat, 29 Nov 2003 11:05:19 -0500 (EST)

On Wed, 26 Nov 2003, Chris Ditri wrote:
> Normally, I split up the packets into 3 chains, one for udp, one for
> tcp, etc. etc. This is supposed to decrease the overhead by not
> running everything though one chain. It minimizes processing. Should
> something like this be implemented on my bridge/firewall? (logically
> splitting traffic into chains).

You say "chains", but I'm assuming you're using iptables. If you're using
actually using ipchains (ehh...), the answer below for INPUT and OUTPUT is
woefully incomplete.

Most likely most of your packets are going to be TCP so the performance
benefit of this is minimal. Breaking up your chains into logical trees
reduces the amount of processing done. I like having between about two
and six rules in each chain.

Having all the "real processing" done in a chain all its own opens up all
sorts of possibilities. My Linux firewall that sits in front of my kids
Internet connection had scheduled jobs to stop their masq'd and/or squid'd
access to various times of day. Since the iptables commands just remove
one at a time I could add an extra "block this kids MASQ acess" rule into
the FORWARD chain and the cron job could keep going adding and removing
its extra block this kid rule.

> Should I try to set my INPUT and OUTPUT to DROP, and make exceptions?

Unless you're running some proxy there's no need for the whole world to be
able to get into your box. So INPUT should be only what you want to let
in for box management. If you want to do only console management then
INPUT could be DROP only. Setting OUTPUT to DROP would prevent trojans
from using that box to impregnate other boxes, but it would mean that you
couldn't make ssh connection from the bridge and DNS lookups wouldn't
work. Updates would need to be sneakernetted to the box too. That seems
a bit harsh to me, but I'm lazy.

> Or is it safe to leave it alone?

OUTPUT is safe to leave alone, INPUT should be tight.

> Should I bag the whole thing and use ebtables (something I am completely
> unfamiliar with). I personally don't see why I would want to do this... I
> don't know if I have a need to block and allow based upon mac address...

What you're doing sounds to be going in the right direction. Unless
you're trying to be ultraparanoid MAC filtering isn't worth the trouble.

No, no, you're not thinking, you're just being logical.
-Niels Bohr, physicist (1885-1962)
firewall-wizards mailing list

Relevant Pages

  • Re: OT swingsets
    ... Don't try making your own seats, it's like reinventing the wheel, ... and chains rated for more than you would guess - centripetal ... forces plus two kids on one seat, and you have a ton of force... ... climbing those chains and slipping onto a slightly open hook. ...
  • Re: Current plans - Mammoth
    ... bags into kids, old, an useful. ... and the Chains Required signs were up. ... back to deeply rutted ice and I was gad Ihad the chains on. ...
  • Re: Question. on iptables concept
    ... > one from the outside world to access any resource to the local LAN. ... as routed packets _do not_ go through INPUT nor OUTPUT chains. ... Built-in chains behaviour for filtering implies that whatever packet you ...
  • Re: Right Interface - Wrong IP
    ... I've setted up a similar configuration, with exactly the same rules, the same iptables' chains, and all works fine. ... My filling is that, when generating packets, the interaction between netfilter and iproute2 looks like this: ... Netfilter OUTPUT hooks are traversed ... POSTROUTING hooks are traversed ...
  • Re: Fw: [fw-wiz] Is the order of the rules entered in iptables important?
    ... The INPUT, OUTPUT, and FORWARD chains are all different in IPTables. ... Input is for Packets destined for the local box. ... I was wondering if that is because the boot script has, ...