REJECT as a default policy

REJECT as a default policy

[Lars Nooden]

I'd like to add the ability to use the REJECT target as a default policy
to the netfilter / iptables wishlist.

Using REJECT as a default is currently possible as a kludge a few steps
would be saved by allowing it as a default policy.  Perhaps that might
even speed up some filtering in some cases.

A good (IMHO) discussion of DROP vs REJECT has been written by Peter Benie :
	http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject


Regards,
/Lars

RE: REJECT as a default policy

[Gary Smith]

> I'd like to add the ability to use the REJECT target as a default policy
> to the netfilter / iptables wishlist.
> 
> Using REJECT as a default is currently possible as a kludge a few steps
> would be saved by allowing it as a default policy.  Perhaps that might
> even speed up some filtering in some cases.
> 
> A good (IMHO) discussion of DROP vs REJECT has been written by Peter Benie :
> 	http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
> 

So change:
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

To:
:INPUT REJECT [0:0]
:FORWARD REJECT [0:0]
:OUTPUT REJECT [0:0]

I'm not really seeing the added value myself.  I think it could have a negative benefit to many who use the chains and expect the default rule to be ACCEPT in order to fall through to the next rule.  

Or am I not seeing your bigger picture of how REJECT would affect the sub chains?

Gary Smith

Re: REJECT as a default policy

[Richard Horton]

2010/1/11 Gary Smith <gary.smith@holdstead.com>:

> I'm not really seeing the added value myself.  I think it could have a negative benefit to many who use the chains and expect the default rule to be ACCEPT in order to fall through to the next rule.
>
> Or am I not seeing your bigger picture of how REJECT would affect the sub chains?

I think all the OP means is DROP is valid policy target where as
REJECT isn't. The big problem though is that DROP / ACCEPT as policy
targets or jump targets require no options where as the REJECT target
can take options to control the returned ICMP code, which with the
current policy handler you couldn't specifiy.




-- 
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.solstans.co.uk - Solstans Japanese Bobtails and Norwegian Forest Cats
http://www.pbase.com/arimus - My online photogallery

RE: REJECT as a default policy

[Gary Smith]

> > Or am I not seeing your bigger picture of how REJECT would affect the sub
> chains?
> 
> I think all the OP means is DROP is valid policy target where as
> REJECT isn't. The big problem though is that DROP / ACCEPT as policy
> targets or jump targets require no options where as the REJECT target
> can take options to control the returned ICMP code, which with the
> current policy handler you couldn't specifiy.
> 

That makes a little more sense now.

Re: REJECT as a default policy

[Lars Nooden]

Richard Horton wrote:
> I think all the OP means is DROP is valid policy target where as
> REJECT isn't. 

Yes.

> The big problem though is that DROP / ACCEPT as policy
> targets or jump targets require no options where as the REJECT target
> can take options to control the returned ICMP code, which with the
> current policy handler you couldn't specifiy.

Ok.  The limitation is a characteristic of the current policy handler,
so it's a non-trivial task to allow REJECT as a default policy.

Mart Frauenlob wrote:
> you will not have control over how many (limit) and what type of icmp
> error is through'n out (would need new policy handler).

Thanks, Mart and Richard.  That answers a pair of question I was going
to ask but unsure of how to phrase.

/Lars

Re: REJECT as a default policy

[Lars Nooden]

Gáspár Lajos wrote:
> IMHO:
> I do not like to waste resources.
> An "unwanted/unallowed" incoming packet is already wasting time/bandwidth.
> A reply (ICMP or whatever else) to this makes you waste your precious
> resources.
> (Think about the ASYMMETRIC DSL)

Don't misunderstand the request.  It is not a request to prohibit the
possibility of using DROP as the default policy for chain, but one of
*also* allowing use of REJECT as a default policy for a chain.  It is
simply easiest, from a configuration standpoint, to set default with
a "-P"

There are times and conditions when DROP will be the appropriate
default, there are times and conditions when REJECT is the appropriate
default.  Currently REJECT can be done by adding it to the end of a
chain, effectively making it default.

Regards
/Lars

Re: REJECT as a default policy

[Mart Frauenlob]

On 12.01.2010 14:31, Lars Nooden wrote:
> Gáspár Lajos wrote:
>> IMHO:
>> I do not like to waste resources.
>> An "unwanted/unallowed" incoming packet is already wasting time/bandwidth.
>> A reply (ICMP or whatever else) to this makes you waste your precious
>> resources.
>> (Think about the ASYMMETRIC DSL)
> 
> Don't misunderstand the request.  It is not a request to prohibit the
> possibility of using DROP as the default policy for chain, but one of
> *also* allowing use of REJECT as a default policy for a chain.  It is
> simply easiest, from a configuration standpoint, to set default with
> a "-P"
> 
> There are times and conditions when DROP will be the appropriate
> default, there are times and conditions when REJECT is the appropriate
> default.  Currently REJECT can be done by adding it to the end of a
> chain, effectively making it default.
> 
> Regards
> /Lars

well, if you write a new policy handler, i've got some feature requests :)

1: allow to set policies on custom (user created) chains (iptables -N
chain -P ACCEPT/DROP/REJECT).

2: for REJECT give ways to limit/hashlimit/recent match, with fallback
to DROP.
i.e. iptables -N foo -P REJECT --reject-with ... -m hashlimit ... -m
recent ... --policy-fallback DROP/DELUDE/TARPIT

oops, i've added DELUDE and TARPIT to the policy wishlist ;)
how about:
iptabes -N foo -P TARPIT -m hashlimit ... -m recent ...
--policy-fallback DROP



thanks a lot :))

regards

Mart

Re: REJECT as a default policy

[Mart Frauenlob]

On 11.01.2010 13:02, Lars Nooden wrote:
> I'd like to add the ability to use the REJECT target as a default policy
> to the netfilter / iptables wishlist.
> 
> Using REJECT as a default is currently possible as a kludge a few steps
> would be saved by allowing it as a default policy.  Perhaps that might
> even speed up some filtering in some cases.
> 
> A good (IMHO) discussion of DROP vs REJECT has been written by Peter Benie :
> 	http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
> 


imagine you get scanned / ddosed / synflooded. For every invalid packet
coming in, you send out an icmp packet. Your host and line could get
quite busy with just sending irrelevant responses, making the dos attack
even more successful.

you will not have control over how many (limit) and what type of icmp
error is through'n out (would need new policy handler).


that's why i personally prefer to DROP to untrusted, while placing
REJECT rules with a limit before the drop-policy, to trusted sides.

regards

Mart