[pve-devel] [RFC container/firewall/manager/proxmox-firewall/qemu-server 00/37] proxmox firewall nftables implementation

[DERUMIER, Alexandre]

-------- Message initial --------
De: Stefan Hanreich <s.hanreich at proxmox.com>
Répondre à: Proxmox VE development discussion <pve-
devel at lists.proxmox.com>
À: pve-devel at lists.proxmox.com
Objet: Re: [pve-devel] [RFC container/firewall/manager/proxmox-
firewall/qemu-server 00/37] proxmox firewall nftables implementation
Date: 03/04/2024 14:25:40

On 4/3/24 14:03, DERUMIER, Alexandre via pve-devel wrote:
> maybe revert the kernel patch ? ^_^
> https://antiphishing.vadesecure.com/v4?f=YVdEbUdjdUhGSnlic1ZwZTZs5NC0
> IK5UpoMm-JbYmH0g8SvUq6T2pULKyCWNdAtigmuEY2RK_MUtsxeEJS-
> hxg&i=VG1PWDJGYXFXcTREa3RZRfomnJARQnrbyjpk2iZcdNI&k=BnAq&r=M1hxaWZ5bn
> NuVExjSWtSa9ErN2N5EUBGcCr8vO1Apj6WrYRZZdbucoU7ZCJIs1cd&s=3ec641e9b97c
> 0cd606bd785a4f86cf529a63c00affecb597ebc3fa3e7f6b8764&u=https%3A%2F%2F
> git.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.gi
> t%2Fcommit%2Fnet%2Fbridge%2Fnetfilter%2Fnft_reject_bridge.c%3Fh%3Dv6.
> 8.2%26id%3D127917c29a432c3b798e014a1714e9c1af0f87fe

>>I also thought about it shortly. If we can ensure that certain
>>conditions are met that might be an option. We would have to think
>>about
>>broadcast/multicast traffic like ARP / DHCP I would assume. It seems
>>a
>>bit drastic from my POV, which is why dropped that thought.

I think you can just use DROP for this kind of traffic, as anyway, you
don't expect to receive a response like tcp-reset or icmp port
unreachable.

only udp,tcp,icmp (unicast traffic) should be interesting (and can be
protected from unicast_flood)




> Or Improve it for upstream, something like:
> 
> if !bridge_unicast_flooding && !bridge_mac_learning && proto =
> tcp|udp
>     allow_use_of_reject

>>that might be a possibility, although I'm not sure that information
>>about the bridge is available in the netfilter modules.

Yes, I'm not sure that it's possible to have this kind of information.
Maybe simply adding a sysctl flag to allow|disallow usage of reject in
forward/postrouting.
Like this, the userland software can enabled it if it known that's it's
safe.



_______________________________________________
pve-devel mailing list
pve-devel at lists.proxmox.com
https://antiphishing.vadesecure.com/v4?f=YVdEbUdjdUhGSnlic1ZwZTZs5NC0IK
5UpoMm-JbYmH0g8SvUq6T2pULKyCWNdAtigmuEY2RK_MUtsxeEJS-
hxg&i=VG1PWDJGYXFXcTREa3RZRfomnJARQnrbyjpk2iZcdNI&k=BnAq&r=M1hxaWZ5bnNu
VExjSWtSa9ErN2N5EUBGcCr8vO1Apj6WrYRZZdbucoU7ZCJIs1cd&s=18886ae882494937
dd226c13263c6706f72f922dea16c781a962348d3ddbfc6a&u=https%3A%2F%2Flists.
proxmox.com%2Fcgi-bin%2Fmailman%2Flistinfo%2Fpve-devel