I want to create a robust IP blacklist for all my Qubes (with internet access) that will run on sys-firewall. However, that blocklist needs to be active for all internet connections, so I need to make sure that I can’t bypass it by switching a Qube’s networking from sys-firewall to sys-net. So how do I prevent sys-net from providing direct access to all Qubes (now and created in the future, preferably without having to update a list of AppVMs) other than sys-firewall?
As far as I am aware there is no build-in way of doing this. Sys-firewall is already the default in the qubes global settings. But when changing net-vm for a particular qube you need to take special care about not do any mistakes.
It isn’t difficult to do this.
netvms provide NAT, so that an upstream netvm only sees traffic coming
from the IP address of the netvm.
So at sys-net, block all traffic except for that with saddr of the
sys-firewall.
Since IP addresses are fixed, that should be sufficient.
You’ll need to hack on the qubes-firewall table in sys-net to make sure
that other netvms dont jump in ahead of the blocking rule.
1 Like
Okay, maybe there’s something obvious I’m missing, but I’ve spent the better part of four hours trying to find the ‘right’ way to do just that… and I’ve got squat. How would you recommend doing it?
Remember, usualy in a qubes system, sys-net is considered potentially compromised. The best way is to think of it already compromised in some way.
So, if you put that kind of restrictions there, an attacker could potentially subvert them (as in any another OS, by the way).
The best practice is put these rules in the firewall. (If sys-net is compromised, it would be harder to subvert the rules, as they are implemented in another “machine”.
The you only must be carefully not connect your VMs directly to sys-net. But you should not do that anyhow.
I’m well aware of all of that. What I’m trying to avoid isn’t an outside attack or my own clumsiness, but my own deliberate attempt to subvert the rules I set in sys-firewall by changing a qubes’ network to sys-net.
All I need to know is how to prevent sys-net from providing network to any IP other than that of sys-firewall, and then I’ll run chattr -R +i on the needed files and (once everything is set up) enable passworded root to which a trusted individual that is not myself will have the password. It’s a weird situation and request, I get that, but I’ve read up plenty on it and right now, I’m just trying to figure out which of the many ways to implement these rules (nftables vs iptables, etc.) should be used in which location (rc.local vs firewall-user-script, etc.). The documentation gives a lot of options and not a whole lot of info on how to discern which to use in what situation.
Glad you found it. I was just about to jump in.
Make sure you test:
- sys-firewall started, and another qube directly attached.
- another qube directly attached, and set to autostart.
- another qube directly attached, and set to autostart, no other qubes
autostart, and then sys-firewall manually started… - cases where another qubes is attached, stopped, moved to another netvm,
started, moved back to sys-net.
Probably other cases, but that should catch most.
I find that rules in sys-net are useful to cover many cases of stupidity
- ensuring that some sites are only available via Tor, or enforcing
traffic via separate NICs, for example.