Re: [pve-devel] hetzner bug with pve-firewall

[Josef Johansson <josef@oderland.se>]

Hi,

Sorry for the late answer.

It seems to do what it's intended to do.

I ran `bridge link set dev fwpr<id>p0 flood off`

If it works ok I will deploy it on more VMs.

Med vänliga hälsningar
Josef Johansson

On 9/14/21 09:21, Josef Per Johansson wrote:
> Hi,
>
> I can check it out for sure, not touching ebtables would be nice.
>
> Sent from Nine
> ________________________________
> From: alexandre derumier <aderumier@odiso.com>
> Sent: Tuesday, 14 September 2021 02:28
> To: Proxmox VE development discussion
> Subject: Re: [pve-devel] hetzner bug with pve-firewall
>
>
> Hi, I just send another patch,
>
> without ebtables, but with disabling unicast_flood on vm bridge ports. 
>
> maybe can you try it ?
>
>
> Le dimanche 12 septembre 2021 à 12:37 +0200, Josef Per Johansson a
> écrit :
>> Hi,
>>
>> Yeah sure! It seems a bit better than my hack!
>>
>> Yeah I meant the mac-address-table, my bad.
>>
>> Sent from Nine
>> ________________________________
>> From: alexandre derumier <aderumier@odiso.com>
>> Sent: Friday, 10 September 2021 18:19
>> To: Proxmox VE development discussion
>> Subject: Re: [pve-devel] hetzner bug with pve-firewall
>>
>>
>> Hi,
>>
>> Le vendredi 10 septembre 2021 à 12:53 +0200, Josef Johansson a
>> écrit :
>>>
>>> I have a patch for the source code regarding only allowing the VMs
>>> MAC
>>> in ebtables for incoming traffic also.
>> I just send a patch too for incoming traffic, maybe could you try it
>> ?
>>
>>
>>
>>>> Traffic is only broadcasted to MAC B if the ARP-table in the
>>>> switch
>>>> times out.
>>>>
>>>> Which makes this problem a hell to diagnose :-)
>> to be exact, if the mac-address-table timeout in the switch. (switch
>> don't have arp, until it's a router)
>> That's why in general, switch need to be configured with mac-address-
>> table aging-time (2h for exemple)  > than arp timeout on servers.
>>
>> Like this, if no traffic occur on servers, and arp is timeout out,
>> server is sending a new arp request, and the switch see the arp reply
>> with the mac address,
>> (and no expiration in mac-address-table).
>>
>> Looking at hetzner problem, the tcpdump send by users show really
>> stranges mac address vendor. (sound like forged flood).
>> Anyway, they should fix this, with static mac in their switch, as
>> they
>> known allowed mac by server anyway.
>> (Until they have poor cheap switch without mac filtering ....)
>> I wonder if they are not only filtering/detecting the wrong mac on
>> their gateway. (as here, we send tcp reset to an external ip, going
>> through the gateway)
>>
>>
>>
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
From d.whyte@proxmox.com  Fri Oct  1 17:31:03 2021
Return-Path: <d.whyte@proxmox.com>
X-Original-To: pve-devel@lists.proxmox.com
Delivered-To: pve-devel@lists.proxmox.com
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id 2214D711BB
 for <pve-devel@lists.proxmox.com>; Fri,  1 Oct 2021 17:31:03 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 170B82D8C7
 for <pve-devel@lists.proxmox.com>; Fri,  1 Oct 2021 17:31:03 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS id 11E7B2D8BE
 for <pve-devel@lists.proxmox.com>; Fri,  1 Oct 2021 17:31:02 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id DC565453EB
 for <pve-devel@lists.proxmox.com>; Fri,  1 Oct 2021 17:31:01 +0200 (CEST)
From: Dylan Whyte <d.whyte@proxmox.com>
To: pve-devel@lists.proxmox.com
Date: Fri,  1 Oct 2021 17:30:50 +0200
Message-Id: <20211001153051.175856-2-d.whyte@proxmox.com>
X-Mailer: git-send-email 2.30.2
In-Reply-To: <20211001153051.175856-1-d.whyte@proxmox.com>
References: <20211001153051.175856-1-d.whyte@proxmox.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.444 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: [pve-devel] [PATCH pve-docs 2/3] pveum: add intro to 'limited API
 Token' section
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>
X-List-Received-Date: Fri, 01 Oct 2021 15:31:03 -0000

Add a short introduction to the section "Limited API Token for
Monitoring", to provide some context

Signed-off-by: Dylan Whyte <d.whyte@proxmox.com>
---
 pveum.adoc | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/pveum.adoc b/pveum.adoc
index a0fabfb..97e0005 100644
--- a/pveum.adoc
+++ b/pveum.adoc
@@ -793,7 +793,13 @@ members of the group `customers` and within the realm `pve`.
 Limited API Token for Monitoring
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Given a user `joe@pve`, with the PVEVMAdmin role on all VMs:
+Permissions on API tokens are always a subset of those of their corresponding
+user, meaning that an API token can't be used to carry out a task that the
+backing user has no permission to do. This section will demonstrate how you can
+use an API token with separate privileges, to limit the token owner's
+permissions further.
+
+Give the user `joe@pve` the role PVEVMAdmin on all VMs:
 
 [source,bash]
  pveum acl modify /vms -user joe@pve -role PVEVMAdmin
-- 
2.30.2