On Thu, Apr 25, 2024 at 06:22:33PM +0100, Daniel P. Berrangé wrote:
> On Thu, Apr 25, 2024 at 01:38:06AM -0400, Laine Stump wrote:
> > V2:
> > https://lists.libvirt.org/archives/list/[email protected]/thread/5RTZ6PC3N3CO6X353QUHLVOL43SWQ4JD/
> >
> > This patch series enables libvirt to use nftables rules rather than
> > iptables *when setting up virtual networks* (it does *not* add
> > nftables support to the nwfilter driver).
>
> I deployed on my machine and restarted virtnetworkd, with nft backend
> active. I have 2 networks running, and got the following result
>
> table ip libvirt {
> chain INPUT {
> type filter hook input priority filter; policy accept;
> counter packets 363 bytes 30801 jump LIBVIRT_INP
> }
>
> chain FORWARD {
> type filter hook forward priority filter; policy accept;
> counter packets 1 bytes 76 jump LIBVIRT_FWX
> counter packets 1 bytes 76 jump LIBVIRT_FWI
> counter packets 1 bytes 76 jump LIBVIRT_FWO
> }
>
> chain OUTPUT {
> type filter hook output priority filter; policy accept;
> counter packets 286 bytes 107221 jump LIBVIRT_OUT
> }
>
> chain LIBVIRT_INP {
> iifname "virbr0" udp dport 53 counter packets 0 bytes 0 accept
> iifname "virbr0" tcp dport 53 counter packets 0 bytes 0 accept
> iifname "virbr0" udp dport 67 counter packets 1 bytes 320
> accept
> iifname "virbr0" tcp dport 67 counter packets 0 bytes 0 accept
> iifname "virbr1" udp dport 53 counter packets 0 bytes 0 accept
> iifname "virbr1" tcp dport 53 counter packets 0 bytes 0 accept
> iifname "virbr1" udp dport 67 counter packets 0 bytes 0 accept
> iifname "virbr1" tcp dport 67 counter packets 0 bytes 0 accept
> }
>
> chain LIBVIRT_OUT {
> oifname "virbr0" udp dport 53 counter packets 0 bytes 0 accept
> oifname "virbr0" tcp dport 53 counter packets 0 bytes 0 accept
> oifname "virbr0" udp dport 68 counter packets 1 bytes 336
> accept
> oifname "virbr0" tcp dport 68 counter packets 0 bytes 0 accept
> oifname "virbr1" udp dport 53 counter packets 0 bytes 0 accept
> oifname "virbr1" tcp dport 53 counter packets 0 bytes 0 accept
> oifname "virbr1" udp dport 68 counter packets 0 bytes 0 accept
> oifname "virbr1" tcp dport 68 counter packets 0 bytes 0 accept
> }
I'm wondering if these DHCP and DNS rules are in fact pointless.
In iptables, there's 1 set of global tables, and other firewall
tools or sysadmin might have put a DENY/REJECT that catches
DHCP/DNS. We inserted libvirt rules at the head of the tables,
so we can then explicitly ACCEPT DHCP/DNS, even if later rules
would deny them. So the LIBVIRT_INP/LIBVIRT_OUT rules are useful
in the context of iptables.
In nftables, there are arbitrary many tables, and a packet needs
to be allowed by *all* the tables, to continue its flow.
If a non-libvirt tables has put in a DENY/REJECT that catches
DHCP/DNS, then no matter what rules we put in the 'libvirt'
tables, we can never undo that DENY/REJECT.
So these LIBVIRT_INP/LIBVIRT_OUT rules are entirely pointless
unless the 'libvirt' table had later rules that could be
DENY/REJECTing DHCP/DNS. We don't today.
The only way I see these DHCP/DNS rules being useful, is if
the LIBVIRT_INP chain had a default 'deny' rule for 'virbr0',
to block the guest from all access to the host. That would
to some extent overlap with a general host firewall tool,
but there might not be one.
Currently our "isolated" config still allows guests to access
the host, just won't route off host. I guess any of the forward
modes could conceptually have a "deny host" access rule.
Still, even if we implemented this "deny host" concept, we
still don't need to add these DHCP/DNS rules to LIBVIRT_INP
and LIBVIRT_OUT, unless 'deny host' is actually active.
IOW, I think we should delete (or comment out) all the DHCP/DNS
rules from your nftables impl currently.
>
> chain LIBVIRT_FWO {
> ip saddr 192.168.122.0/24 iifname "virbr0" counter packets 1
> bytes 76 accept
> iifname "virbr0" counter packets 0 bytes 0 reject
> ip saddr 192.168.100.0/24 iifname "virbr1" counter packets 0
> bytes 0 accept
> iifname "virbr1" counter packets 0 bytes 0 reject
> }
>
> chain LIBVIRT_FWI {
> oifname "virbr0" ip daddr 192.168.122.0/24 ct state
> established,related counter packets 0 bytes 0 accept
> oifname "virbr0" counter packets 0 bytes 0 reject
> oifname "virbr1" ip daddr 192.168.100.0/24 ct state
> established,related counter packets 0 bytes 0 accept
> oifname "virbr1" counter packets 0 bytes 0 reject
> }
>
> chain LIBVIRT_FWX {
> iifname "virbr0" oifname "virbr0" counter packets 0 bytes 0
> accept
> iifname "virbr1" oifname "virbr1" counter packets 0 bytes 0
> accept
> }
>
> chain POSTROUTING {
> type nat hook postrouting priority srcnat; policy accept;
> counter packets 2 bytes 136 jump LIBVIRT_PRT
> }
>
> chain LIBVIRT_PRT {
> ip saddr 192.168.122.0/24 ip daddr 224.0.0.0/24 counter
> packets 0 bytes 0 return
> ip saddr 192.168.122.0/24 ip daddr 255.255.255.255 counter
> packets 0 bytes 0 return
> meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr !=
> 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
> meta l4proto udp ip saddr 192.168.122.0/24 ip daddr !=
> 192.168.122.0/24 counter packets 1 bytes 76 masquerade to :1024-65535
> ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24
> counter packets 0 bytes 0 masquerade
> ip saddr 192.168.100.0/24 ip daddr 224.0.0.0/24 counter
> packets 0 bytes 0 return
> ip saddr 192.168.100.0/24 ip daddr 255.255.255.255 counter
> packets 0 bytes 0 return
> meta l4proto tcp ip saddr 192.168.100.0/24 ip daddr !=
> 192.168.100.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
> meta l4proto udp ip saddr 192.168.100.0/24 ip daddr !=
> 192.168.100.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
> ip saddr 192.168.100.0/24 ip daddr != 192.168.100.0/24
> counter packets 0 bytes 0 masquerade
> }
> }
>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
