From patchwork Sat May 9 21:17:44 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Engelhardt X-Patchwork-Id: 219534 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1E72C54E4A for ; Sat, 9 May 2020 21:17:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BE9C821473 for ; Sat, 9 May 2020 21:17:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728309AbgEIVRs (ORCPT ); Sat, 9 May 2020 17:17:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727108AbgEIVRs (ORCPT ); Sat, 9 May 2020 17:17:48 -0400 X-Greylist: delayed 37485 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Sat, 09 May 2020 14:17:48 PDT Received: from a3.inai.de (a3.inai.de [IPv6:2a01:4f8:10b:45d8::f5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4925CC061A0C; Sat, 9 May 2020 14:17:48 -0700 (PDT) Received: by a3.inai.de (Postfix, from userid 65534) id C67BC58769D1B; Sat, 9 May 2020 23:17:45 +0200 (CEST) Received: from a4.inai.de (a4.inai.de [IPv6:2a01:4f8:10b:45d8::f8]) by a3.inai.de (Postfix) with ESMTP id 31CFB58734C07; Sat, 9 May 2020 23:17:44 +0200 (CEST) From: Jan Engelhardt To: zenczykowski@gmail.com Cc: maze@google.com, pablo@netfilter.org, fw@strlen.de, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org Subject: [PATCH] doc: document danger of applying REJECT to INVALID CTs Date: Sat, 9 May 2020 23:17:44 +0200 Message-Id: <20200509211744.8363-1-jengelh@inai.de> X-Mailer: git-send-email 2.26.2 In-Reply-To: References: MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Signed-off-by: Jan Engelhardt --- 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