From patchwork Fri Apr 21 12:23:00 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Tremer X-Patchwork-Id: 6804 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 4Q2tw83gqDz3x6v for ; Fri, 21 Apr 2023 12:23:04 +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 4Q2tw73pYsz9S7; Fri, 21 Apr 2023 12:23:03 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4Q2tw72l99z30D6; Fri, 21 Apr 2023 12:23:03 +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) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4Q2tw66GxVz2y4G for ; Fri, 21 Apr 2023 12:23:02 +0000 (UTC) Received: from michael.haj.ipfire.org (michael.haj.ipfire.org [172.28.1.242]) (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 "michael.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4Q2tw56tVzzNk; Fri, 21 Apr 2023 12:23:01 +0000 (UTC) Received: by michael.haj.ipfire.org (Postfix, from userid 0) id 4Q2tw56Fs8zTh73; Fri, 21 Apr 2023 12:23:01 +0000 (UTC) From: Michael Tremer To: development@lists.ipfire.org Subject: [PATCH] firewall: Drop legacy rules for PPPoE/PPTP Date: Fri, 21 Apr 2023 12:23:00 +0000 Message-Id: <20230421122300.2326005-1-michael.tremer@ipfire.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 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: , Cc: Arne Fitzenreiter , Michael Tremer Errors-To: development-bounces@lists.ipfire.org Sender: "Development" These rules where created to permit any local traffic to the firewall when using a PPP connection that utilised Ethernet as transport. This is however nonsensical and a security issue for any other connection methods that call the RED interface "red0" and use PPP (e.g. QMI). Since PPPoE packets do not flow through iptables, these rules can be dropped safely. We do not know whether PPTP works at all these days. Fixes: #13088 - firewall: INPUT accepts all packets when using QMI for dial-in Tested-by: Stefan Schantl Tested-by: Arne Fitzenreiter Signed-off-by: Michael Tremer --- src/initscripts/system/firewall | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/src/initscripts/system/firewall b/src/initscripts/system/firewall index dfa08d58b..50f2b3e02 100644 --- a/src/initscripts/system/firewall +++ b/src/initscripts/system/firewall @@ -424,19 +424,6 @@ iptables_red_up() { fi fi - # PPPoE / PPTP Device - if [ "$IFACE" != "" ]; then - # PPPoE / PPTP - if [ "$DEVICE" != "" ]; then - iptables -A REDINPUT -i $DEVICE -j ACCEPT - fi - if [ "$RED_TYPE" == "PPTP" -o "$RED_TYPE" == "PPPOE" ]; then - if [ "$RED_DEV" != "" ]; then - iptables -A REDINPUT -i $RED_DEV -j ACCEPT - fi - fi - fi - # PPTP over DHCP if [ "$DEVICE" != "" -a "$TYPE" == "PPTP" -a "$METHOD" == "DHCP" ]; then iptables -A REDINPUT -p tcp --source-port 67 --destination-port 68 -i $DEVICE -j ACCEPT