Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Antony Stone <Antony@Soft-Solutions.co.uk>
To: netfilter@lists.netfilter.org
Subject: Re: safe default chain policies
Date: Fri, 2 Apr 2004 16:36:30 +0100	[thread overview]
Message-ID: <200404021636.30508.Antony@Soft-Solutions.co.uk> (raw)
In-Reply-To: <BAY16-F48j6fVCjmpp100021caf@hotmail.com>

On Friday 02 April 2004 4:21 pm, Philippe Anctil wrote:

> Hi Antony,
>
> I will leave the nat chains open. In fact I already did that yesterday. I
> really makes my life better.

I bet it does :)

> May I ask what are your arguments in favor of putting filter output and
> forward chains to drop?

Forward is easy - you do not want your machine forwarding any traffic other 
than what you've decided you want to allow, therefore you set the policy to 
DROP and then write ACCEPT rules for the traffic you want.

If you do it the other way around, and have a default ACCEPT policy with DROP 
rules to block the traffic you don't want, you might (a) forget something, 
(b) not know about something new, (c) make a mistake which stops your script 
loading the rules part-way through....  all sorts of reasons why the firewall 
would be insecure as a result.

Output is a little more questionable - some people say "the only applications 
which will generate packets are the ones I run, therefore I'm going to allow 
all traffic out of my system with a default ACCEPT policy on OUTPUT".

This is okay so long as you really are in control of your machine and you 
really do know what all the applications you run are going to get up to.

The secure attitude uses the same argument as for FORWARD - you block all 
traffic except that which you know you want and write ACCEPT rules for, and 
you can then be sure your machine isn't communicating in any other way than 
you want it to.

> As far as my understanding goes, the output chain is primarily important
> for traffic involving the firewall box itself.

No need for the work "primarily" there.   The OUTPUT chain is *only* for 
traffic coming from the firewall box itself.

> Once traffic passed the input chain, why wouldn't I want it to cross the
> output chain as well?

This suggests to me that you're not quite sure about how netfilter works:

INPUT is for packets coming in the the firewall and terminating there.
OUTPUT is for packets going out of the firewall (having originated on it).
FORWARD is for packets going through the firewall (either way).

One packet will go through only *one* of these chains.   No single packet will 
go through INPUT and FORWARD, or through INPUT and OUTPUT

> My reasoning is similar with the forward chain. If traffic is allowed
> through the input  chain, it is very likely it is allowed to cross the
> forward chain too.

See above.

> In other words, rules in OUTPUT and FORWARD appear redundant to me.

Take a look at one of the excellent diagrams which have been created to show 
how packets traverse the netfilter chains and tables.

Regards,

Antony.

-- 
If at first you don't succeed, destroy all the evidence that you tried.

                                                     Please reply to the list;
                                                           please don't CC me.



  reply	other threads:[~2004-04-02 15:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-02 15:21 safe default chain policies Philippe Anctil
2004-04-02 15:36 ` Antony Stone [this message]
2004-04-02 15:44   ` Antony Stone
  -- strict thread matches above, loose matches on Subject: below --
2004-04-02 19:12 Philippe Anctil
2004-04-02 19:02 Philippe Anctil
2004-04-02 19:23 ` Antony Stone
2004-04-02  4:58 Philippe Anctil
2004-04-02  7:42 ` Antony Stone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200404021636.30508.Antony@Soft-Solutions.co.uk \
    --to=antony@soft-solutions.co.uk \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox