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