I would like to have Firewall restrictions on what domains a whonix-ws Qube can access. As far as I understand, the suggested way to achieve this is documented here, but I need a configuration where a compromised whonix-ws will not be able to modify the firewall rules (without privilege escalation and lateral movement, at least).
An approach which gives this separation is to use a debian-11 qube, with Firewall rules set in its Qubes Settings (in dom0). As noted in this forum comment by a Qubes OS dev, this approach needs a proxy before the whonix-gw: “Whonix doesn’t enforce Qubes firewall rules”… “Add a firewall between the [AppVM] and sys-whonix”. To clarify, this involves creating two Qubes:
Are there any security issues with this approach? Specifically, it is it a problem to use sys-whonix in this way?
Another question is, is there an approach that involves setting firewall rules, while using whonix-ws and whonix-gw, but where whonix-ws does not have the ability to modify the rules in case it is compromised?
Let’s call that sys-in-between_anon-whonix_and_sys-whonix until a more handy term can be invented.
I don’t see any issues with it if you can make it work. [1]
The issue I am seeing is that you’ll be most likely breaking stream isolation. Because for that, applications are talking to a Tor SocksPort directly.
Maybe dante (proxy software) running on sys-in-between_anon-whonix_and_sys-whonix can accept the incoming socks connection, apply filtering and then forward these to sys-whonix. If dante cannot do that, you’d have to find a different software and/or write your own.
Very advanced users are free to hook anon-whonix to sys-whonix communications using a sys-in-between_anon-whonix_and_sys-whonix as they see fit but that won’t be easy and will be mostly unsupported.
I would be interested to hear if you manage to do it, how, instructions, wiki improvements, etc. are welcome.
Only if these firewall rules can be load in a different VM such as sys-in-between_anon-whonix_and_sys-whonix or sys-whonix. Unless Qubes / Xen has some extra mechanism that can be applied to VMs that I am unaware of which would be unspecific to Whonix.
You could ask Qubes and/or Xen “Can I enforce firewall rules for a VM without using a ProxyVM?”
[1] Other than arguing increased attack surface, unknown unknowns, advanced fingerprinting (some website checking if you’re the user blocking certain IPs) but nothing immediately tangible. It’s always trade-offs.
I think there is a bit of a misunderstanding, sorry for the confusion.
qube1 is debian-11, not whonix-ws-16. So our new term would rather be called sys-in-between_debian_and_sys-whonix…
I’ve tried qube1 with whonix-ws-16 but it breaks the networking if firewall rules are enabled in qube1 (in the Qubes Settings > Firewall rules: Limit outgoing connections to…). Do you have any idea why in this qube1/qube2 configuration described in my first post, networking breaks if qube1 is whonix-ws-16 instead of debian-11?
So to reiterate the question with this cleared up: Does Tor work as expected when using whonix-gw-16 with debian-11 INSTEAD of whonix-ws-16? (Stream isolation doesn’t matter in my case because qube1 is used for a single compartmentalized activity). Or, must whonix-gw ALWAYS be used with whonix-ws for some reason?
You could ask Qubes and/or Xen “Can I enforce firewall rules for a VM without using a ProxyVM?”
I think the answer from Qubes would be the “Firewall rules” in Qubes settings, but in the linked forum post above, unman said: "Whonix doesn’t enforce Qubes firewall rules”. The ball comes back to Whonix I guess, for why Whonix doesn’t enforce those rules? I’m curious if this would be resolvable. I certainly would prefer to use whonix-ws to debian-11, if possible. The whole point of the firewall rules in this use case is to restrict data exfiltration possibilities in the case of compromise, so firewall rules need to be managed in a separate qube to be useful.
Your can use any number of additional VMs and chain their networking, do firewalling, anything you desire. sys-whonix works as long as the VM in front of sys-whonix is correctly configured as per documentation.
If you insert a new firewall:
sys-net - sys-firewall - sys-whonix - firewall2 - qube
Then you do get benefit of a firewall, but sys-whonix only sees
traffic that seems to originate from firewall2, which may do strange
(and unwanted) things to Tor circuits.
With a note about how this impacts stream isolation. From the same thread:
Here’s an example:
You have 2 qubes, and you ssh into one server.
If you have both connected to sys-whonix then stream isolation
will ensure you use different circuits, (Isolate Client Address is on
by default).
If you attach both to a firewall, then at sys-whonix the ssh traffic
appears to come from the IP of the firewall, so will not trigger stream
isolation, and both streams will use the same circuit. At the server
both logins will appear to come from the same IP address. This may not
be what you want.
This is just an example - I don’t know what steps Whonix takes to
mitigate this, (if any), and I find the documentation unclear, but it is a
potential issue.
As discussed above, such documentation would be using debian-11 as the “workstation” AppVM, because firewall rules applied through Qubes settings don’t work with whonix-ws. As per the documentation for anonymizing debian, such documentation would also include Debian instructions for:
Disable Internet Time Syncing (via sdwdate Whonix package?)
Set your Time Zone to UTC.
Set up a static IP.
EDIT: I will test whether the Qubes Setting’s firewall works with kicksecure , which is obviously preferable to debian-11, and report-back here.
Great news - Firewall rules settings (from Qubes Settings) works on kicksecure-16 (Kicksecure for Qubes).
Any idea why this is? Excerpting from the unman thread again:
sys-whonix breaks this model, because it doesn’t process firewall rules at all.
So in this case:
sys-net - sys-firewall - sys-whonix - qube
NO firewall rules are implemented. (They are not written on
sys-firewall but cant be processed because traffic is encrypted - they
are not written at all.)
I assume that it works on kicksecure and not whonix-ws because where whonix-ws is encrypted, kicksecure is not (given it’s not forcing tor)?
So to re-iterate the documentation addition proposal, it would be with the following configuration:
Easy to misunderstand. What unman maybe meant to say:
The firewall rules are not written on sys-firewall. They are not written at all.
It’s not because the traffic is encrypted. It might have nothing to do with encryption.
Kicksecure at time of writing doesn’t have a firewall by default. In case of
somevm → kicksecure-vm the kicksecure-vm uses Qubes default firewall rules.
Whonix has a firewall by default.
Whonix at time of writing doesn’t use Qubes default firewall rules.
And that forum thread generally.
A patch/git branch contribution or just design proposal of sys-whonix interfacing with qubes-firewall would be interesting to see. Contributions are welcome.
Hi there, just registered to give a thumbs up to OP.
I think sys-whonix behavior ignoring downstream Qubes OS firewall requests from clients is at least very surprising - I would have expected uniform handling from all NetVMs.
Thanks @storms for the links, which got me on the right track. While I still would be in favor of making Qubes-Whonix gateway behave like other NetVMs, wouldn’t it be useful to document this in the wiki as well? Perhaps a separate section “Qubes firewall” section within Whonix-Gateway Firewall - Whonix, which illustrates deviations by linking to this post?