Re: [iptables PATCH] iptables-nft: fix basechain policy configuration

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

 





Am 09.10.20 um 12:14 schrieb Phil Sutter:
Hi Harald,

On Fri, Oct 09, 2020 at 12:07:57PM +0200, Reindl Harald wrote:
Am 09.10.20 um 11:37 schrieb Phil Sutter:
I guess fundamentally this is due to legacy design which keeps builtin
chains in place at all times. We could copy that in iptables-nft, but I
like the current design where we just delete the whole table and start
from scratch.

Florian made a related remark a while ago about flushing chains with
DROP policy: He claims it is almost always a mistake and we should reset
the policy to ACCEPT in order to avoid people from locking themselves
out. I second that idea, but am not sure if such a change is tolerable
at all.
bad idea!

Why?

because in doubt you always to be packets dropped

nothing is locking you out just because of a short drop phase, at least
not over the past 12 years, that's what tcp retransmits are for

What I had in mind was 'ssh somehost iptables -F INPUT'.

when someone shoots you with so much passion in the foot let him

nobody does that without a script which will simply come back du tcp-retransmit and it's prettfy fine that after a flush DROP is the default policy

a default of ACCEPT for INPUT is crazy

when you once accept i have someone which should never have been
accepted in the conntracking - sorry - but when i say drop i literally
mean drop at any point in time

My English language parser failed this part, sorry. :)

accepting one unwanted packet leads in "ctstate RELATED,ESTABLISHED" triggering later no matter if you fix the policy afterwards



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux