RE: new iptables user - default options

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2003-10-28 at 14:54, Knight, Steve wrote:
> Thanks Robert - I appreciate your response.
> 
> I have to say I'd agree - it seems to be more of a belt and braces approach
> to use your suggestion, and more in the spirit of what we were told in
> checkpoint kindergarten ["deny everything unless explicitly asked" - also
> sounds a bit like being married].
> 
> Are the rules in each chain processed top down?
> 
Yes, and possibly why the default for deadbat is to create a user chain
- user chains are called from the default chains (or other user chains),
then the rules are checked, when a match is found or the end of the user
chain is reached, execution/parsing continues from where the user chain
was called. This is one method of setting up logging rules, and also
makes debugging a work-in-progress firewall setup easier.

> steve
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Robert P. J. Day [mailto:rpjday@xxxxxxxxxxxxxx] 
> Sent: 28 October 2003 12.34
> To: Knight, Steve
> Cc: netfilter@xxxxxxxxxxxxxxxxxxx
> Subject: Re: new iptables user - default options
> 
> 
> On Tue, 28 Oct 2003, Knight, Steve wrote:
> 
> > Hi there
> > 
> > Rh9 has installed all the default filter policies as "accept" and then
> > forwards all packets from INPUT and FORWARD to a Lokkit chain.
> > 
> > Is this normal?  It seems to me [as a iptables n00b, although I am
> > checkpoint certified] to be ok, as eventually the traffic is hitting the
> > detailed lokkit chain, but is this the default install options that
> everyone
> > gets?
> 
> it seems that it's just a philosophical difference.  you can set the
> DENY policy, then explicitly accept only what you want, or as RH did,
> accept everything only to pass it all to a user-defined chain that
> effectively does the same thing.
> 
> personally, i'd rather see a DENY policy so that, if i somehow messed
> up some of my rules, i'm more likely to be *more* restrictive than
> less restrictive.  but RH's approach seems no worse, just different.
> 
> rday
> 
> 
> 
> .
> 
> 
> -----------------------------------------------------------------------
> Information in this email may be privileged, confidential and is 
> intended exclusively for the addressee.  The views expressed may
> not be official policy, but the personal views of the originator.
> If you have received it in error, please notify the sender by return
> e-mail and delete it from your system.  You should not reproduce, 
> distribute, store, retransmit, use or disclose its contents to anyone.
>  
> Please note we reserve the right to monitor all e-mail
> communication through our internal and external networks.
> -----------------------------------------------------------------------
-- 
--
Raymond Leach <raymondl@xxxxxxxxxxxxxxxxxxxxxx>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux