From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 9928D1FF16F for ; Fri, 15 Nov 2024 14:13:58 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7977613F33; Fri, 15 Nov 2024 14:13:59 +0100 (CET) Message-ID: <508606c2-8e34-4d6f-b975-a4e96d022b13@proxmox.com> Date: Fri, 15 Nov 2024 14:13:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion , Hannes Laimer References: <20241115123321.49338-1-h.laimer@proxmox.com> Content-Language: en-US From: Stefan Hanreich In-Reply-To: <20241115123321.49338-1-h.laimer@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.665 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH] firewall: resources: accept invalid ct state by default X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 11/15/24 13:33, Hannes Laimer wrote: > We only add a `block-conntrack-invalid` jump to the in chain, if > the `nf_conntrack_allow_invalid` option is not set in the config. But we > already drop connections with an invalid ct state by default. So we have > to either allow connections with an invalid ct state by default, or explicitly > allow them when checking for the option and keeping them blocked by default. > I chose to change the 'default' as it has the same result but is > simpler a change. > > Signed-off-by: Hannes Laimer > --- > relevant code[1] > ``` > if self.config.host().block_invalid_conntrack() { > log::debug!("set block_invalid_conntrack"); > > commands.push(Add::rule(AddRule::from_statement( > chain_in, > Statement::jump("block-conntrack-invalid"), > ))); > } > ``` This setting is for toggling invalid traffic on host level and works because in the host default-in chain we have: ct state established,related accept and then insert in the option-in chain jump block-conntrack-invalid depending on the `nf_conntrack_allow_invalid` setting. For VMs this isn't configurable, we always drop conntrack invalid traffic: > > chain pre-vm-out { > - meta protocol != arp ct state vmap { established : accept, related : accept, invalid : drop } > + meta protocol != arp ct state vmap { established : accept, related : accept, invalid : accept } > } > > chain vm-out { > @@ -326,7 +326,7 @@ table bridge proxmox-firewall-guests { > } > > chain pre-vm-in { > - meta protocol != arp ct state vmap { established : accept, related : accept, invalid : drop } > + meta protocol != arp ct state vmap { established : accept, related : accept, invalid : accept } > meta protocol arp accept > } > This change has a problem though: It would *always* allow traffic with ct state invalid for VMs. I see two ways of solving this problem: * We introduce a knob at VM level that lets you decide whether to drop ct invalid traffic or not. (Invalid traffic would then still be evaluated by the firewall rules if it's allowed in principle, as is the case on host-level) * We apply the host-level setting to VMs as well. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel