diff mbox series

doc: document danger of applying REJECT to INVALID CTs

Message ID 20200509211744.8363-1-jengelh@inai.de
State New
Headers show
Series doc: document danger of applying REJECT to INVALID CTs | expand

Commit Message

Jan Engelhardt May 9, 2020, 9:17 p.m. UTC 
Signed-off-by: Jan Engelhardt <jengelh@inai.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 mbox series

Patch

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