From patchwork Sat Apr 30 09:45:27 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Peter_M=C3=BCller?= X-Patchwork-Id: 5573 Return-Path: Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4Kr4Gl5FPLz3x1v for ; Sat, 30 Apr 2022 09:45:35 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4Kr4Gj19K3z3tg; Sat, 30 Apr 2022 09:45:33 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4Kr4Gh6qshz2yfp; Sat, 30 Apr 2022 09:45:32 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4Kr4Gg3JS9z2xv9 for ; Sat, 30 Apr 2022 09:45:31 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4Kr4Gf41wMz17w for ; Sat, 30 Apr 2022 09:45:30 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1651311931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=yj8MNXwiQ7J+lVj5DuvMgXwHPFDkkGwrhJluZ1TBWRA=; b=zY77BJzZITjKv+PgfY/ci/vvVuh/QfrPNOAz1va1ysemkbeoIOfjzrZjrzSE66vegDAlXw 8+75shZTN1wlJIAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1651311931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=yj8MNXwiQ7J+lVj5DuvMgXwHPFDkkGwrhJluZ1TBWRA=; b=bOjk9LiklFlSM9Y0ESGaielmyGPr9Fp3UjOovxOMIFJnWQgfdUFO4yB57+SEugU2BySreI mrKl4LqkqRME/WoxpYmttKE7V39BuGNuT09jS9OaZSHPF1dxN//f6rbSA7HHWrExj+z/R/ jPADkVafUGwuTMXq8XGhDZN8+7Ve8i9InSwTUsRuzF207ZzhCNBEcR0i77BHV6+fkk3L0i w54YtNcYBdodH8k3Q7fZOioy684JdgrRujzNGXED1pcxbp1khCMUb+okalcv+fglaZjj4V QmtbtkpkXt2MI9eWxdeR5eZ41oA9tdJhIZh2s5jAaqgOByYWd81zMdTxrQ8LuA== Message-ID: <2a19b137-55c7-ecb4-6161-8e87dc1a9a6b@ipfire.org> Date: Sat, 30 Apr 2022 09:45:27 +0000 MIME-Version: 1.0 Content-Language: en-US To: "IPFire: Development" From: =?utf-8?q?Peter_M=C3=BCller?= Subject: [PATCH] sysctl: Use strict Reverse Path Filtering X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: development-bounces@lists.ipfire.org Sender: "Development" The strict mode, as specified in RFC 3704, section 2.2, causes packets to be dropped by the kernel if they arrive with a source IP address that is not expected on the interface they arrived in. This prevents internal spoofing attacks, and is considered best practice among the industry. After a discussion with Michael, we reached the conclusion that permitting users to configure the operating mode of RPF in IPFire causes more harm than good. The scenarios where strict RPF is not usable are negligible, and the vast majority of IPFire's userbase won't even notice a difference. This supersedes <495b4ca2-5a4b-2ffa-8306-38f152889582@ipfire.org>. Suggested-by: Michael Tremer Signed-off-by: Peter Müller Reviewed-by: Adolf Belka --- config/etc/sysctl.conf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config/etc/sysctl.conf b/config/etc/sysctl.conf index 5fc3e3d89..7fe397bb7 100644 --- a/config/etc/sysctl.conf +++ b/config/etc/sysctl.conf @@ -12,13 +12,13 @@ net.ipv4.tcp_syn_retries = 3 net.ipv4.tcp_synack_retries = 3 net.ipv4.conf.default.arp_filter = 1 -net.ipv4.conf.default.rp_filter = 2 +net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.default.log_martians = 1 net.ipv4.conf.all.arp_filter = 1 -net.ipv4.conf.all.rp_filter = 2 +net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.log_martians = 1