On Mon, 3 Jun 2024 10:52:54 +0200 Marek Marczykowski-Górecki wrote:

> Not much. But the same firewall applies to sys-firewall, VPN qubes and
> some other configurations. And in those cases it matters a bit more.

Yes. That's why I asked about sys-net.

I have never used a VPN, neither a VPN qube. Looking at this:

https://forum.qubes-os.org/t/configuring-a-proxyvm-vpn-gateway/19061

I understand it has only eth0 and vifs - just like sys-firewall. So,
IIUC, the only special (uplink-wise) qube is sys-net. If this is so, it
seems we can have the following (I change netdev to inet which also
supports ingress):

table inet antispoof {
        set downstream_ipv4 {
                type ipv4_addr
        }

        set downstream_ipv6 {
                type ipv6_addr
        }

        chain antispoof-downstream {
                ip  saddr @downstream_ipv4 counter packets 0 bytes 0 drop
                ip6 saddr @downstream_ipv6 counter packets 0 bytes 0 drop
        }

        # Handle eth0 early
        chain antispoof-eth0 {
                type filter hook ingress device "eth0" priority -500
                policy accept

                jump antispoof-downstream
        }

        # Demi's idea, extended
        chain antispoof-other {
                type filter hook prerouting priority raw
                policy accept

                # Prevent processing eth0 twice and skip loopback too
                iifgroup != 2 iifname != { "lo", "eth0" } \
                        jump antispoof-downstream
        }

        # ... per-vif chains dynamically created by vif-route-qubes
}

What do you think?

> > Do you mean (conntrack) established,related?  
> 
> It may cover some of those cases, yes. But I'm not sure if all (check
> for example if traceroute would still work).

Do you mean traceroute initiated from sys-net towards a downstream
qube? Is that supposed to work?

> But also, that sentence was about the long list of subnets that
> shouldn't appear on the internet, but in most cases you connect to
> LAN first, and those would be filtered out too. Generally, if you
> have a link to some network (or even a single host), it is wrong to
> filter out its source IP as spoofed one, because it isn't spoofed.

It seems to me much more complicated than that.

> Antispoofing rules should drop _only_ spoofed traffic - packets that use
> source IP that doesn't belong to its actual source. Antispoofing rules
> are not a place for other policy decisions.

Yes. Bogons are separate.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/20240603194557.327c5602%40localhost.

Reply via email to