-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, May 23, 2024 at 09:39:55AM -0000, qubist wrote:
> On Thu, 23 May 2024 02:08:20 +0200 Marek Marczykowski-Górecki wrote:
>
> > As for the implementation, few remarks:
> > - - you create separate chain per IP, each with policy drop - it will
> > fail for multiple IPs (for example both IPv4 and IPv6)
>
> What do you mean by fail?
I mean one of them will drop packets that would be allowed by the
other. So, no traffic will be allowed.
> The suggested implementation successfully creates separate
> uniqely-named chains for the IPv4 and IPv6 addresses of the same vif
> and automatically removes them upon vif's disconnect. Example:
>
> # nft list table netdev antispoof
> table netdev antispoof {
> chain antispoof-vif16-0-10-137-0-91 {
> type filter hook ingress device "vif16.0" priority -500;
> policy drop;
> iifgroup 2 ip saddr 10.137.0.91 accept
> counter packets 0 bytes 0
> }
>
> chain antispoof-vif16-0-fd09-24ef-4179-a89-5b {
> type filter hook ingress device "vif16.0" priority -500;
> policy drop;
> iifgroup 2 ip6 saddr fd09:24ef:4179::a89:5b accept
> counter packets 8 bytes 640
> }
> }
>
> > - it should be one chain with possibly multiple rules (or one with a
> > set?)
>
> Using a single chain for all vifs and IP addresses is quite challenging
> for the following reasons:
No, I mean one chain per vif (but for all its IPs), instead of one per
IP.
(...)
> There is something else that bothers me, which I would like to discuss
> with you:
>
> While working on a more meticulous IPv6 filtering, I noticed the
> following. This is both about existing implementation, as well as about
> the suggested one (which simply inherits the algorithm):
>
> Certain ICMPv6 messages (Router Advertisement and Redirect), currently
> cannot transit the firewall,
Those are actually intentional, we don't do dynamic IP configuration on
purpose (attack surface reduction), and even if for some reason one VM
would try to sent such packets (could be an attempt to change
sys-firewall's configuration by one of AppVMs...), they should be
blocked. Same for Redirect.
> because, as per RFC 4861, they MUST have a
> link-local source address. Considering the ${ip} address list, sent by
> Xen to the script, does not contain these addresses, the antispoofing
> mechanism blocks the possibility for creating a fully functional local
> IPv6 network between 2 or more qubes without hacking the nftables chain
> structure and custom scripting to detect vif name etc. This BTW makes
> the existing _icmpv6 chain simply unreachable by any external packet.
The link-local traffic should not be forwarded anyway. And definitely
shouldn't be used to communicate between two separate qubes.
> I also notice that all qubes receive the same link-local address for
> eth0:
>
> inet6 fe80::216:3eff:fe5e:6c00/64
>
> obviously based on the same MAC address they receive too.
Yes, but the MAC address can be changed (see "mac" property). And the
vif script should have access to it too I think.
> This practically means that to distinguish packets during filtering,
> matching of the interface name (which is dynamic) is also required and
> that makes things fairly complicated if qube A filters traffic from
> qube B. This seems similar to issue #8833, just for a different
> component.
>
> So, I wonder what is the correct approach in regards to that. On one
> hand, it is very much desired to disallow qube-to-qube network chatter
> by default, even if the qubes have IPv6 enabled. On the other, there
> needs to be a mechanism allowing the user to easily configure a custom
> IPv6 qubes-LAN.
Still, link-local addresses shouldn't be used to communicate between two
different links. There may be some cases where app-qube <-> sys-firewall
communication is affected by the unexpected filtering of all link-local
traffic, but I don't think it affects anything in practice (haven't seen
any issues). That said, allowing specific link-local address in the
antispoofing rules (and later filter undesirable packets using normal
rules) might be a good idea.
> I would very much like to know what you think about that.
>
> > - - "downstream" map is gone (without a replacement using the new
> > method), opening spoofing on eth0 - see QSB-056 for details:
> > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-056-2019.txt
>
> Are you suggesting that we should antispoof eth0 too?
Yes, the change you propose should not regress one of the issues
classified as security bugs before...
For example, sys-net should not be able to pretend to be one of your
AppVMs. That's especially relevant if you'd configure sys-firewall to
allow traffic between some AppVMs.
> The bigger
> firewall hardening I am working on already includes eth0 bogon
> filtering. In case you mean something else, please explain.
>
> > If you open a pull request on github, we have quite extensive set of
> > tests I can schedule from there.
>
> I will see how to do that but let's please clarify first. If you can
> share what these tests are, I could probably run them locally too.
Sure: https://www.qubes-os.org/doc/automated-tests/
For network specifically, there is qubes.tests.integ.network
and qubes.tests.integ.network_ipv6.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmZPFKIACgkQ24/THMrX
1ywunQf/dKBcABY6r9ojW1M6fl58OtBsgWaZp7TTEIVXZ9oUpos6srpFA0tXfVuL
99zeGb/Wi4nU0nlwGv2cQlIPd1ZeUXa2aZMbF0EyLh2M1VYRg3K1tOvgqiqOzwjL
6kG8wrvlucf+mWyjf2QzUWV7/lzs+h79yFix81uZLHseb8SqsvReOzlCUcIWgIQ+
V2wWrJzN9QenmJIWRkprv8hto7CLmB/46iJMq+xv5yuuYyvXwL2RW9C9jSYd/S+E
1fL/B/y5c/HMGkmAjMnFzR2rApfW6/6kavaycq0fLXcf9/4jh3e6Ph1rpEPnpUnj
Dg2tmtL1afXsZAIMun5H760h6S036A==
=nfpb
-----END PGP SIGNATURE-----
--
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/Zk8UosQInkkNAY7g%40mail-itl.
