Multiple Whonix-Workstation™
Donate
Compartmentalization. Better separation of different tasks and/or pseudonyms by using multiple Whonix-Workstation.
Introduction[edit]
Whonix is a secure operating system comprised of two virtual machines which are isolated both from each other and the host. This configuration averts many threats posed by malware, misbehaving applications and user error. While Whonix protects against many real world threats, [1] it is still possible for skilled adversaries to compromise Whonix-Workstation (Qubes-Whonix: anon-whonix).
If a single Whonix-Workstation is used for all anonymous activities and is exploited, the attacker gains access to available data and can monitor all online activity. To minimize the impact of a compromise, it is recommended to utilize multiple Whonix-Workstation to compartmentalize different identities and/or additional software. Depending on individual preferences and requirements, a second, third ... nth Whonix-Workstation VM can be created.
Multiple Whonix-Workstation Rationale[edit]
Different torifed clients can be used in a completely isolated manner with Multiple Whonix-Workstation. By compartmentalizing each different identity or client, an attacker can only read the data in the compromised VM. For example, if Tor Browser in VM-1 was compromised it could not read a user's IRC identity in VM-2. [2]
One disadvantage of this configuration is that if the host Internet connection goes offline or Tor on Whonix-Gateway (sys-whonix) suddenly fails, then all Whonix-Workstation will go offline simultaneously. If multiple Tor clients were running and abruptly stop in unison, a network observer could link these activities to the same person. For instance, a strong correlation is formed if two Tor users in one IRC channel go offline at exactly the same time.
Qubes-Whonix vs Non-Qubes-Whonix[edit]
Qubes-Whonix is the recommended choice for multiple Whonix-Workstation because it is specifically designed for compartmentalization (a.k.a. sandboxing) of multiple running VMs. This provides significant speed and security advantages relative to the traditional Type 2 hypervisor model, where two (or more) Whonix VMs are run inside programs like VirtualBox on top of the host OS. For further information, see: Type 1 vs Type 2 Hypervisors and Why use Qubes over other Virtualizers?
Qubes-Whonix also has a TemplateBased filesystem which saves time and improves usability compared to Non-Qubes-Whonix:
- Centralized Updates: App Qubes
are based on the corresponding Template's root filesystem. After updating the Template, those same updates will be reflected in the root filesystem of every App Qube. Non-Qubes-Whonix users must spend more time in updating each VM individually. - Minimal Disk Usage: App Qubes require far less disk space than traditional VMs since the App Qube's root filesystem is based on the corresponding template. The App Qube only requires enough disk space to hold user files in the
/homedirectory. - VM Management: Cloning VMs is a simple two-step process which can be done in Qube Manager. Non-Qubes-Whonix requires a multi-step process to clone and configure each VM.
Safety Precautions[edit]
While multiple Whonix-Workstation are recommended, this is not an endorsement for using them simultaneously!
It is safest to only use one Whonix-Workstation at a time and for a single activity. New risks are introduced by running multiple Whonix-Workstation at the same time. For instance, if a single Whonix-Workstation was compromised, it could potentially perform various side channel attacks to learn about running processes in other VMs, and not all of these can be defeated. Depending on user activities, a skilled adversary might be able to correlate multiple Whonix-Workstation to the same pseudonym. Therefore, ideally, shut down all but one Whonix-Workstation before using any other Whonix-Workstation.
Cross-VM Attack Vectors[edit]
Table: Cross-VM Attack Vectors
| Category | Description |
|---|---|
| Attacks via the shared bridge |
Multiple workstation VMs are all connected to the gateway using the same virtual bridge; they share an IP subnet. A variety of attacks permit devices sharing a bridge to view or steal one another's traffic, or to impersonate one another at the IP layer. The exact attacks available depend on the specific bridge implementation, but some are always available. At a minimum, VMs sharing a bridge can always trivially detect one another, and determine one another's local IP addresses on the bridge, simply by watching broadcast traffic like ARP and IPv6 neighbor discovery. The snooping and impersonation vulnerabilities are particularly dangerous because the communication between the Tor process running on the gateway and the client programs running on the workstation is neither encrypted nor cryptographically authenticated. Connections are made either using the (cleartext) SOCKS5 protocol or using Tor's transparent connection proxying feature. Even if the actual application data are encrypted, DNS lookups and circuit creation data are always sent in the clear. A workstation VM that intercepts another workstation's bridge traffic is in a position to know the destinations of all outgoing connections over Tor from that other workstation, as well as the timing and volume of traffic sent over each such connection. It may also be possible to intercept Tor control traffic generated by the "new identity" button. If the user sends cleartext data at the actual application layer, then hostile VMs are in a position to steal those data as well. In effect, none of the workstation VMs receives Tor's core protections with respect to the other workstation VMs. Although many things in each workstation may be protected against the other workstations, for Tor purposes all of the VMs effectively share the same compartment. This could be mitigated by providing each workstation VM with a separate virtual bridge and a separate virtual interface on the gateway VM. The gateway configuration should also be reviewed to make sure that the gateway isn't routing unnecessary traffic between the workstations at the IP layer. For a potential remedy see Connections between Whonix-Gateway and Whonix-Workstation. |
| Distributed Denial of Service (DDOS) Attack |
An adversary that managed to compromised a VM with malware could stress any system such as CPU, GPU, HDD, RAM, network connection and other Whonix-Workstation. If a Distributed Denial of Service (DDOS) Attack
|
| Local VM Fingerprinting | See VM Fingerprinting. |
| Exploits against other Whonix-Gateway [4] |
Following infection, an adversary could try to exploit the Whonix-Gateway. |
| Exploits against other Whonix-Workstation | Following infection, an adversary could try to exploit other Whonix-Workstation:
|
| Identity Correlation through Circuit Sharing |
When different applications use the same Tor circuit and exit relay, these activities can be linked to the same pseudonym (see Stream Isolation for further details):
|
| Impersonation |
Multiple Whonix-Workstation are supposed to have different internal IPs configured. Once a VM is compromised by malware it could attempt to impersonate another VM by taking its internal IP.
|
How-to: Use more than One Whonix-Workstation - Easy[edit]
Non-Qubes-Whonix
Note: The following instructions only apply to Download/Default-Whonix-Workstation or Whonix VMs built from source code. To use another operating system like Windows, other GNU/Linux, BSD etc. please see the Other Operating Systems chapter instead.
Each additional Whonix-Workstation VM must have its own MAC address and internal LAN IP address.
1. Clone a fresh Whonix-Workstation VM.
- VirtualBox: In VirtualBox Manager, clone a clean Whonix-Workstation.
- KVM: In Virtual Machine Manager, clone a clean Whonix-Workstation:
Highlight Whonix-Workstation→Open→Virtual Machine→Clone
2. Assign a new MAC address to the cloned VM.
Note: A new MAC address is necessary if an additional VirtualBox VM is imported.
- VirtualBox: In VirtualBox Manager, assign a new MAC address:
VirtualBox→Settings→Network→Adapter 1→Advanced→Mac Address→Create a new MAC address (press the green round arrow icon)→OK - KVM: To change the internal network in KVM, see: Creating Multiple Internal Networks.
3. Edit the network interfaces file in Whonix-Workstation.
sudoedit /etc/network/interfaces.d/30_non-qubes-whonix
Ignore all lines starting with a hashtag ("#"). That is because comments are only for documentation and notes. However, comments are ignored by the system.
Look for line address 10.152.152.11. Change the last octet. For example, change 10.152.152.11 to 10.152.152.12
Save and exit.
4. Review your changes.
The following command is optional but handy to show all file contents without comments.
cat /etc/network/interfaces.d/30_non-qubes-whonix | grep --invert-match \#
That should show for example:
auto lo
iface lo inet loopbackg
auto eth0
iface eth0 inet static
address 10.152.152.12
netmask 255.255.192.0
gateway 10.152.152.10
It would even be possible to replace the contents of that config file will above contents. When using more than 1 additional Whonix-Workstation however 10.152.152.12 should be changed to 10.152.152.13 and so forth.
5. Reboot.
Reboot the Whonix-Workstation or alternately restart the network.
sudo service networking restart
6. Done.
Qubes-Whonix
1. Create an additional App Qube based on the Whonix-Workstation Template (whonix-workstation-17) and give it a distinctive name such as for example anon-whonix2. (A more distinctive name is desirable.)
2. Confirm the new Whonix-Workstation App Qube is using a Whonix-Gateway (such as for example the default sys-whonix) as its net qube.
If creating a new App Qube is unfamiliar, follow this step-by-step instructions:
Figure: App Qube Creation using Qubes VM Manager (QVMM)
A.) Create Qubes-Whonix-Workstation App Qube
B.) Name and label: Name the App Qube. Don't include any personal information (if the App Qube is compromised, the attacker could run qubesdb-read /name to reveal the VM name). Name the App Qube something generic, for example: anon-whonix-2.
C.) Color: Choose a color label for the Whonix-Workstation App Qube.
D.) Use this template: Choose the Whonix-Workstation Template. For example: whonix-workstation-17.
E.) Standalone: Leave the Standalone field unchecked, unless a persistent root filesystem is desired.
F.) Type: Choose the type App Qube.
G.) Allow networking: Choose the desired Whonix-Gateway ProxyVM from the list. For example: sys-whonix.
H.) Press: OK.
I.) Open a dom0 terminal.
J.) Add qvm-tag anon-vm to the newly created App Qube. [6]
Note: Replace anon-whonix-2 with the actual name of the VM.
qvm-tags anon-whonix-2 add anon-vm
M.) Done.
3. Depending on the net qube setting.
If you are using the default sys-whonix as gateway
If the Whonix-Workstation App Qube is connected to sys-whonix: No special instructions required.
If you are using a gateway other than sys-whonix
If the Whonix-Workstation App Qube is connected to any Whonix-Gateway other than sys-whonix, apply the following instructions:
The other gateway should be set up according to the instructions on the Multiple Whonix-Gateway wiki page.
Note: Inside the Whonix-Workstation App Qube.
A.) Create folder /usr/local/etc/sdwdate-gui.d.
sudo mkdir -p /usr/local/etc/sdwdate-gui.d
B.) Open with root rights.
sudoedit /usr/local/etc/sdwdate-gui.d/50_user.conf
C.) Add the following text.
Note: The following example uses sys-whonix-2 as an example. Replace sys-whonix-2 with the name of the VM of Whonix-Gateway which this Whonix-Workstation App Qube uses as its net qube. For example, sys-whonix-3.
gateway=sys-whonix-2
D.) Save the file.
E.) Restart the VM. [7]
F.) In case of issues.
sdwdate-gui qrexec denied messages? See Qubes-Whonix troubleshooting, sdwdate-gui qrexec.
4. Done.
The process of setting up an additional Whonix-Workstation App Qube has been completed.
How-to: Use more than One Whonix-Workstation - More Security[edit]
- Qubes-Whonix: This step can be skipped. [3]
- Non-Qubes-Whonix: See: Connections between Whonix-Gateway and Whonix-Workstation.
See Also[edit]
Footnotes[edit]
- ↑ See: Protection Against Real World Attacks.
- ↑ Without using an additional exploit to successfully break out of the infected VM, which is a difficult task.
- ↑ 3.0 3.1 3.2 3.3 3.4
By default, App Qubes which are behind the same
net qubeare prevented from connecting to each other in Qubes. - ↑ To minimize the threat of exploits it is recommended to apply relevant instructions found in the System Hardening Checklist.
- ↑
Since IsolateClientAddr is the Tor default.
- ↑
Developer documentation about
qvm-tags - ↑ Or restart sdwdate-watcher (sdwdate-gui). killall sdwdate-watcher /usr/libexec/sdwdate-gui/start-maybe
The most watertight privacy operating system in the world.
At Whonix we value freedom and trust, supporting Open Source and Freedom Software
2012-2023 ENCRYPTED SUPPORT LP
We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 11 year success story and maybe DONATE!