From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9])
by lore.proxmox.com (Postfix) with ESMTPS id 9928D1FF16F
for <inbox@lore.proxmox.com>; 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 <pve-devel@lists.proxmox.com>,
Hannes Laimer <h.laimer@proxmox.com>
References: <20241115123321.49338-1-h.laimer@proxmox.com>
Content-Language: en-US
From: Stefan Hanreich <s.hanreich@proxmox.com>
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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
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 <h.laimer@proxmox.com>
> ---
> 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