netdev - [PATCH] doc: document danger of applying REJECT to INVALID CTs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20200509211744.8363-1-jengelh@inai.de>
Date:   Sat,  9 May 2020 23:17:44 +0200
From:   Jan Engelhardt <jengelh@...i.de>
To:     zenczykowski@...il.com
Cc:     maze@...gle.com, pablo@...filter.org, fw@...len.de,
        netdev@...r.kernel.org, netfilter-devel@...r.kernel.org
Subject: [PATCH] doc: document danger of applying REJECT to INVALID CTs

Signed-off-by: Jan Engelhardt <jengelh@...i.de>
---

Maciej's explanation on how INVALID+REJECT can lead to problems looks
convincing. I hereby present new manpage wording in the form of "if A, then B"
to better build the argument of avoiding REJECT. So the issue is not caused by
an _incoming_ TCP RST as the initial mail might have suggested,
but by RST generated by REJECT (--reject-with tcp-reset).

It is conceivable to me that a connection termination may occur with not only
TCP+RST, but also with TCP+ICMP and UDP+ICMP, so I trimmed any
protocol-specific wording too. Also trimmed is any mention of -j ACCEPT,
because rule order is not the point of the argument.


 extensions/libip6t_REJECT.man | 21 +++++++++++++++++++++
 extensions/libipt_REJECT.man  | 21 +++++++++++++++++++++
 2 files changed, 42 insertions(+)

diff --git a/extensions/libip6t_REJECT.man b/extensions/libip6t_REJECT.man
index 0030a51f..38183dd7 100644
--- a/extensions/libip6t_REJECT.man
+++ b/extensions/libip6t_REJECT.man
@@ -30,3 +30,24 @@ TCP RST packet to be sent back.  This is mainly useful for blocking
 hosts (which won't accept your mail otherwise).
 \fBtcp\-reset\fP
 can only be used with kernel versions 2.6.14 or later.
+.PP
+\fIWarning:\fP You should not indiscrimnately apply the REJECT target to
+packets whose connection state is classified as INVALID; instead, you should
+only DROP these:
+.PP
+Consider a source host retransmitting an original packet P as P_2 for any
+reason, and P_2 getting routed via a different path (load balancing/policy
+routing, or anything of the kind). Additionally, let P_2 experience so much
+delay that the source host issues \fIanother\fP retransmission, P_3, with P_3
+being succesful in reaching its destination and advancing the connection state
+normally. The delayed P_2, when it eventually is processed, may be considered
+to be not associated with any connection tracking entry. Generating a reject
+packet for such a belated packet would then terminate the healthy connection.
+.PP
+So, instead of:
+.PP
+-A INPUT -m conntrack --ctstate INVALID -j REJECT
+.PP
+do consider using:
+.PP
+-A INPUT -m conntrack --ctstate INVALID -j DROP
diff --git a/extensions/libipt_REJECT.man b/extensions/libipt_REJECT.man
index 8a360ce7..9e80d7ea 100644
--- a/extensions/libipt_REJECT.man
+++ b/extensions/libipt_REJECT.man
@@ -30,3 +30,24 @@ TCP RST packet to be sent back.  This is mainly useful for blocking
 hosts (which won't accept your mail otherwise).
 .IP
 (*) Using icmp\-admin\-prohibited with kernels that do not support it will result in a plain DROP instead of REJECT
+.PP
+\fIWarning:\fP You should not indiscrimnately apply the REJECT target to
+packets whose connection state is classified as INVALID; instead, you should
+only DROP these:
+.PP
+Consider a source host retransmitting an original packet P as P_2 for any
+reason, and P_2 getting routed via a different path (load balancing/policy
+routing, or anything of the kind). Additionally, let P_2 experience so much
+delay that the source host issues \fIanother\fP retransmission, P_3, with P_3
+being succesful in reaching its destination and advancing the connection state
+normally. The delayed P_2, when it eventually is processed, may be considered
+to be not associated with any connection tracking entry. Generating a reject
+packet for such a belated packet would then terminate the healthy connection.
+.PP
+So, instead of:
+.PP
+-A INPUT -m conntrack --ctstate INVALID -j REJECT
+.PP
+do consider using:
+.PP
+-A INPUT -m conntrack --ctstate INVALID -j DROP
-- 
2.26.2