REJECT as a default policy

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

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

2010/1/11 Gary Smith <[email protected]>:

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

That makes a little more sense now.

Yes.

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.

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

/Lars

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

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