Multiple Whonix-Workstation: Difference between revisions

From Whonix
Jump to navigation Jump to search
Browse history interactively
[unchecked revision][checked revision]
Content added Content deleted
m (Text replacement - "[[Qubes|{{non_q" to "[[Non-Qubes-Whonix|{{non_q")
 
(262 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Header}}
{{Header}}
{{Title|title=
Multiple {{project_name_workstation_long}}
}}
{{#seo:
{{#seo:
|description=Compartmentalization. Better separation of different tasks and/or pseudonyms by using multiple Whonix-Workstations.
|description=Compartmentalization. Better separation of different tasks and/or pseudonyms by using multiple {{project_name_workstation_short}}.
|image=https://www.whonix.org/w/images/0/01/Petunia-14052640.jpg
|image=Petunia-14052640.jpg
}}
{{multiple-vms-mininav}}
[[image:Petunia-14052640.jpg|thumb]]
{{intro|
Compartmentalization. Better separation of different tasks and/or pseudonyms by using multiple {{project_name_workstation_short}}.
}}
}}
= Introduction =


{{project_name_short}} 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 {{project_name_short}} protects against many real world threats, <ref>See: [[Whonix against Real Attacks|Protection Against Real World Attacks]].</ref> it is still possible for skilled adversaries to compromise {{project_name_workstation_short}} ([[Qubes|{{q_project_name_short}}]]: <code>{{project_name_workstation_vm}}</code>).
== Introduction ==


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 real world threats,<ref>Read [[Security in Real World]] to see how Whonix protects against real world attacks</ref>it still possible for an adversary with the proper skills to compromise Whonix-Workstation (<code>anon-whonix</code> [[Qubes-Whonix]]). Moreover, if only one Whonix-Workstation is used for anonymous activities, the attacker would have access to all data on the Whonix-Workstations and could monitor all online activity. To minimize the impact of compromise, users are encouraged to use muliple Whonix-Workstations to compartmentalize different identities and/or additional software. Depending on the users requirements, a second (or nth) Whonix-Workstation VM could be used.
If a single {{project_name_workstation_short}} 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 {{project_name_workstation_short}} to compartmentalize different identities and/or additional software. Depending on individual preferences and requirements, a second, third ... n<sup>th</sup> {{project_name_workstation_short}} VM can be created.


== Multiple {{project_name_workstation_short}} Rationale ==
'''Why use multiple Whonix-Workstations'''


Mulitple Whonix-Workstations can be used to run different torifed clients in isolated Whonix-Workstation VMs. By compartmentalizing each different identity or client, an attacker can read only the data in the compromised VM. For example, if Tor Browser in VM-1 was compromised it could not read your IRC identity in VM-2. However, keep in mind, if Tor inside the Whonix-Gateway or your host internet connection goes offline, all Whonix-Workstations will go offline. If multiple Tor clients were running simultaneously, an attacker could guess that you are the same person. For example, if two Tor users in one IRC channel go offline at the same moment.
Different torifed clients can be used in a completely isolated manner with Multiple {{project_name_workstation_short}}. 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. <ref>Without using an additional exploit to successfully break out of the infected VM, which is a difficult task.</ref>


One disadvantage of this configuration is that if the host Internet connection goes offline or Tor on {{project_name_gateway_short}} (<code>{{project_name_gateway_vm}}</code>) suddenly fails, then all {{project_name_workstation_short}} 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 identity (pseudonym). For instance, a strong correlation is formed if two Tor users in one chat channel go offline at exactly the same time.
'''Qubes-Whonix vs Non-Qubes-Whonix'''


== {{q_project_name_short}} vs {{non_q_project_name_short}} ==
When using multiple Whonix-Workstations, [[Qubes|Qubes-Whonix]] is the recommended choice. This is because [[Qubes|Qubes-Whonix]] is specifically designed for compartmentalization (a.k.a. sandboxing) within multiple running VMs. This gives [[Qubes|Qubes-Whonix]] a significant advantage in both speed and security when compared to the traditional model of running multiple Virtual Machines within an existing OS (for example, running two VM's under [[VirtualBox]] or [[KVM]]). For more information, see [[Qubes/Why_use_Qubes_over_other_Virtualizers|Why use Qubes over other Virtualizers]].


[[Qubes|{{q_project_name_short}}]] is the recommended choice for multiple {{project_name_workstation_short}} 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) {{project_name_short}} VMs are run inside programs like [[VirtualBox]] on top of the host OS. For further information, see: [[Virtualization_Platform_Security#Type_1_vs_Type_2_Hypervisors|Type 1 vs Type 2 Hypervisors]] and [[Qubes/Why_use_Qubes_over_other_Virtualizers|Why use Qubes over other Virtualizers?]]
[[Qubes-Whonix]] also provides the benefit of a TemplateBased filesystem which saves time and provides much better usability over to Non-Qube-Whonix.
* '''Centralized updates''' - [https://qubes-os.org/doc/glossary/#appvm AppVMs] are based on a TemplateVM. This means their root filesystem is based on the root filesystem of the corresponding template. Users need only update the TemplateVM and those updates will be reflected in [https://qubes-os.org/doc/glossary/#templatebasedvm TemplateBasedVM's] root filesystem. This saves a great amount of time over [[Non-Qubes-Whonix]] which requires each VM to be updates individaully .
* '''Minimal disk usage''' - TemplateBasedVMs require much less disk space than traditinal Virtual Machines. Since the AppVM's root filesystem is based the corresponding template. The AppVM only requires enough disk space to hold user files in the <code>/home</code> directory
* '''VM management''' - Cloning VMs is a simple two step process which can be done in Qubes Manager. This is a time saver compared to Non-Qubes-Whonix that uses a multi-step process to clone and configure each VM.


{{q_project_name_short}} also has a TemplateBased filesystem which saves time and improves usability compared to {{non_q_project_name_short}}:


* <u>Centralized Updates:</u> [https://www.qubes-os.org/doc/glossary/#app-qube 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 [https://www.qubes-os.org/doc/glossary/#app-qube App Qube]. [[Non-Qubes-Whonix|{{non_q_project_name_short}}]] users must spend more time in updating each VM individually.
'''Safety-precautions'''
* <u>Minimal Disk Usage:</u> 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 <code>/home</code> directory.
* <u>VM Management:</u> Cloning VMs is a simple two-step process which can be done in Qube Manager. {{non_q_project_name_short}} requires a multi-step process to clone and configure each VM.


= Safety Precautions =
While multiple Whonix-Workstations are recommended, it is safer to use only one Whonix-Workstation at any given time, and for a single activity.


{{mbox
Leaving multiple Whonix-Workstations running at the same time introduces new risks. If one of the Whonix-Workstation VMs was compromised, it can perform various attacks and not all of them can be defeated. Depending on the activities a user was performing in other Whonix-Workstations, a skilled adversary could correlate the various running Whonix-Workstations to the same pseudonym.
| image = [[File:Ambox_warning_pn.svg.png|40px|alt=warning]]
| text = While multiple {{project_name_workstation_short}} are recommended, this is <u>not</u> an endorsement for using them simultaneously!
}}


It is safest to only use one {{project_name_workstation_short}} at a time and for a single activity. New risks are introduced by running multiple {{project_name_workstation_short}} at the same time. For instance, if a single {{project_name_workstation_short}} 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 {{project_name_workstation_short}} to the same pseudonym. Therefore, ideally, shut down all but one {{project_name_workstation_short}} before using any other {{project_name_workstation_short}}.
* An adversary could stress either/and CPU, HDD, RAM, network connection and other Whonix-Workstations. It is possible the host could be negatively affected as well.
* DDOSing:
** Other Whonix-Workstations.
*** There is no defense against DOSing other Whonix-Workstations.
** Whonix-Gateway
*** There is no defense against DOSing other Whonix-Gateway.
* Exploits:
** This risk can be reduced by following the recommendations found in the [[System Hardening Checklist]].
** The adversary could try to exploit the Whonix-Gateway.
** The adversary could try to exploit other Whonix-Workstations.
*** Non-Qubes-Whonix: Applies
*** Qubes-Whonix: Not applicable. [Unless Whonix-Gateway is compromised first.] (Details in chapter [[#Firewall]].)
* Impersonating
** Non-Qubes-Whonix: A defense against impersonating (i.e. MITM or malicious gateway) other Whonix-Workstations or the Whonix-Gateway can be implemented using authentication, this is linked in the [[#How to use more than one Whonix-Workstation - More Security]] section below.
** Qubes-Whonix: Not required. (Details in chapter [[#Firewall]].)
* Identity correlation through circuit sharing <ref>See [[Stream Isolation]] page for definition.</ref>
** Non-Qubes-Whonix: Is not at risk as long as the Whonix-Workstations aren't compromised. Multiple Whonix-Workstations using different internal IPs (as recommended in the instructions below) are automatically using [[Stream Isolation]].<ref>Because [https://www.torproject.org/docs/tor-manual.html.en IsolateClientAddr] is Tor's default.</ref>
** Qubes-Whonix: Not required. (Details in chapter [[#Firewall]].)


= Cross-VM Attack Vectors =
== How to use more than one Whonix-Workstation - EASY ==
'''Table:''' ''Cross-VM Attack Vectors''
=== Qubes-Whonix ===
'''Setting up additional Whonix-Workstations with [[Qubes|Qubes-Whonix]]'''


{| class="wikitable"
Using multiple Whonix-Workstations within [[Qubes|Qubes-Whonix]] is a simple process. To do this users can create an additional AppVM based upon the Whonix-Workstation template (commonly called <code>whonix-ws</code>) with its own distinctive name. After the new AppVM is created ensure that it uses <code>sys-whonix</code> as its [https://qubes-os.org/doc/glossary/#netvm| NetVM].
|-
! scope="col"| '''Category'''
! scope="col"| '''Description'''
|-
!- scope="row" | 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.
To create new AppVM users need only follow this link for step-by-step instructions: [[Qubes/Create_Workstation_AppVMs|Create Whonix Workstation AppVMs]].


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.
=== Non-Qubes-Whonix ===
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px">
If you are interested in this with [[Non-Qubes-Whonix]], please press on expand on the right.
<div class="mw-collapsible-content">
'''Setting up additional Whonix-Workstations with download/default Whonix-Workstations'''


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.
{{Non-Qubes-Whonix}} Only!


For a potential remedy see [[Connections between Gateway and Workstation|Connections between {{project_name_gateway_short}} and {{project_name_workstation_short}}]].
{{mbox
|-
| type = notice
! scope="row"| Distributed Denial of Service (DDOS) Attack
| image = [[File:Ambox_notice.png|40px|alt=Info]]
|
| text ='''Note:''' The following instructions only apply for Download/Default-Whonix-Workstations or if you build it yourself from source code. If you would like to use an operating systems such as Windows, other Linux, BSD etc. please see the [[Other Operating Systems]] chapter instead.
An adversary that managed to compromised a VM with [[Malware and Firmware Trojans|malware]] could stress any system such as CPU, GPU, HDD, RAM, network connection and other {{project_name_workstation_short}}. If a [https://en.wikipedia.org/wiki/Denial-of-service_attack Distributed Denial of Service (DDOS) Attack] is launched from an infected {{project_name_short}} VM, then:
}}


* {{project_name_gateway_short}}:
** The {{project_name_gateway_short}} can also be DDOSed, and there is no current defense. This might bring down networking of any connected {{project_name_workstation_short}}.
* {{project_name_workstation_short}}
** <u>{{non_q_project_name_short}}</u>: Other {{project_name_workstation_short}} can be DDOSed. For a potential remedy see [[Connections between Gateway and Workstation|Connections between {{project_name_gateway_short}} and {{project_name_workstation_short}}]].
** <u>{{q_project_name_short}}</u>: Safe. <ref name=qubes-isolated />
* Potentially the host could be negatively affected as well.
|-


! scope="row"| Local VM Fingerprinting
'''Each additional Whonix-Workstation VM that is set up requires its own MAC address and internal LAN IP address.
| See [[VM Fingerprinting]].
|-


! scope="row"| Exploits against other {{project_name_gateway_short}} <ref>To minimize the threat of exploits it is recommended to apply relevant instructions found in the [[System_Hardening_Checklist|System Hardening Checklist]].</ref>
'''1.''' Clone a fresh Whonix-Workstation VM.
|
Following infection, an adversary could try to exploit the {{project_name_gateway_short}}.
|-


! scope="row"| Exploits against other {{project_name_workstation_short}}
'''VirtualBox'''
| Following infection, an adversary could try to exploit other {{project_name_workstation_short}}:


* <u>{{non_q_project_name_short}}</u>: At risk.
In VirtualBox Manager [https://dirkstrauss.com/clone-virtualbox-vm/ clone] a clean Whonix-Workstation.
* <u>{{q_project_name_short}}</u>: Users are safe, unless {{project_name_gateway_short}} is compromised first. <ref name=qubes-isolated />
|-


! scope="row"| Identity Correlation through Circuit Sharing
'''KVM'''
|
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):


* <u>{{non_q_project_name_short}}</u>:
In Virtual Machine Manager clone a clean Whonix-Workstation.
** If not compromised: Safe. Multiple {{project_name_workstation_short}} which have different internal IPs configured (see the instructions further below) are automatically [[Stream Isolation|stream-isolated]]. <ref>
Since [https://web.archive.org/web/20170303015402/https://www.torproject.org/docs/tor-manual.html.en IsolateClientAddr] is the Tor default.
</ref>
** If compromised: Not safe. Stream isolation might be broken through impersonating. A compromised VM could use the IP of another VM. Thereby break stream isolation. For a potential remedy see [[Connections between Gateway and Workstation|Connections between {{project_name_gateway_short}} and {{project_name_workstation_short}}]].
* <u>{{q_project_name_short}}</u>: Safe. <ref name=qubes-isolated />
|-


! scope="row"| Impersonation
<pre>
|
Highlight Whonix-Workstation -> Open -> Virtual Machine -> Clone
Multiple {{project_name_workstation_short}} 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.
</pre>

* <u>{{non_q_project_name_short}}</u>: Same as above.
* <u>{{q_project_name_short}}</u>: Safe. <ref name=qubes-isolated />
|-

|}

= How-to: Use more than One {{project_name_workstation_short}} - Easy =

{{Tab
|type=controller
|content=
{{Tab
|title= =={{non_q_project_name_short}}==
|type=section
|image=
|addToClass=info-box
|active=true
|content=

{{Anchor|qubes}}
{{mbox
| type = notice
| image = [[File:Ambox_notice.png|40px|alt=info]]
| text ='''Note:''' The following instructions only apply to Download/Default-{{project_name_workstation_short}} or {{project_name_short}} 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.
}}
{{mbox
| image = [[File:Ambox_warning_pn.svg.png|40px|alt=warning]]
| text = Each additional {{project_name_workstation_short}} VM <u>must</u> have its own MAC address and internal LAN IP address.
}}

'''1.''' Clone a fresh {{project_name_workstation_short}} VM.

* <u>VirtualBox</u>: In VirtualBox Manager, [https://dirkstrauss.com/clone-virtualbox-vm/ clone] a clean {{project_name_workstation_short}}.
* <u>KVM</u>: In Virtual Machine Manager, clone a clean {{project_name_workstation_short}}: <code>Highlight {{project_name_workstation_short}}</code> &rarr; <code>Open</code> &rarr; <code>Virtual Machine</code> &rarr; <code>Clone</code>


'''2.''' Assign a new MAC address to the cloned VM.
'''2.''' Assign a new MAC address to the cloned VM.

{{mbox
{{mbox
| type = notice
| type = notice
| image = [[File:Ambox_notice.png|40px|alt=Info]]
| image = [[File:Ambox_notice.png|40px|alt=info]]
| text = '''Note:''' A new MAC address is also required if the additional [[VirtualBox]] VM is imported.
| text = '''Note:''' A new MAC address is necessary if an additional [[VirtualBox]] VM is imported.
}}
}}


* <u>VirtualBox</u>: In VirtualBox Manager, assign a new MAC address: <code>VirtualBox</code> &rarr; <code>Settings</code> &rarr; <code>Network</code> &rarr; <code>Adapter 1</code> &rarr; <code>Advanced</code> &rarr; <code>Mac Address</code> &rarr; <code>Create a new MAC address (press the green round arrow icon)</code> &rarr; <code>OK</code>
'''VirtualBox'''
* <u>KVM</u>: To change the internal network in KVM, see: [[KVM#Creating_Multiple_Internal_Networks|Creating Multiple Internal Networks]].


'''3.''' Edit the network interfaces file in {{project_name_workstation_short}}.
In VirtualBox Manager assign a new MAC address:


{{CodeSelect|code=
VirtualBox -> Settings -> Network -> Adapter 1 -> Advanced -> Mac Address ->
sudoedit /etc/network/interfaces.d/30_non-qubes-whonix
Create a new MAC address (press the green round arrow icon) -> Ok.
}}


Ignore all lines starting with a hashtag ("<code>#</code>"). That is because comments are only for documentation and notes. However, comments are ignored by the system.
'''KVM'''


Look for line <code>address 10.152.152.11</code>. Change the last octet. For example, change <code>10.152.152.1'''1'''</code> to <code>10.152.152.1'''2'''</code>
To change the internal network in KVM. See: [[KVM#Creating_Multiple_Internal_Networks|Creating Multiple Internal Networks]]


Save and exit.
'''3.''' In Whonix-Workstation. {{Open with root rights|filename=

/etc/network/interfaces.d/30_non-qubes-whonix
'''4.''' Review your changes.

The following command is optional but handy to show all file contents without comments.

{{CodeSelect|code=
cat /etc/network/interfaces.d/30_non-qubes-whonix {{!}} grep --invert-match \#
}}
}}


That should show for example:
Change the last octet. For example 10.152.152.11 to 10.152.152.12

<pre>
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
</pre>

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 <code>10.152.152.12</code> should be changed to <code>10.152.152.13</code> and so forth.


'''4.''' Save and Exit.
'''5.''' Reboot.


'''5.''' In Whonix-Workstation, reboot. Or alternately restart the network.
Reboot the {{project_name_workstation_short}} or alternately restart the network.


{{CodeSelect|code=
{{CodeSelect|code=
Line 122: Line 197:


'''6.''' Done.
'''6.''' Done.
</div>
</div>


}} <!-- close tab: {{non_q_project_name_short}} -->
== How to use more than one Whonix-Workstation - More Security ==
{{Tab
{{Anchor|Firewall}}
|title= =={{q_project_name_short}}==
* [[Qubes|Qubes-Whonix]] users: Can skip this. <ref name=qubes_network_isolated>Because by Qubes default, AppVMs behind the same ProxyVM [or NetVM] are prevented from connecting to each other.</ref>
|content=
* [[Non-Qubes-Whonix]] users (everyone not using Qubes-Whonix): See also [[Connections between Whonix-Gateway and Whonix-Workstation]].


'''1.''' Create an additional App Qube based on the {{project_name_workstation_short}} Template (<code>{{project_name_workstation_template}}</code>) and give it a distinctive name such as for example <code>{{project_name_workstation_vm}}2</code>. (A more distinctive name is desirable.)
= Multiple Whonix-Gateways =
==== Introduction ====
'''Advanced users only.'''


'''2.''' Confirm the new {{project_name_workstation_short}} App Qube is using a {{project_name_gateway_short}} (such as for example the default <code>{{project_name_gateway_vm}}</code>) as its [https://www.qubes-os.org/doc/glossary/#net-qube <code>net qube</code>].
Multiple Whonix-Gateways can be used along side multiple Whonix-Workstations. However, this has both advantages and disadvantages. This set up is more secure since the Whonix-Gateway VMs are isolated from each other. In the event that one Whonix-Gateway is compromised, it is not certain the others will be compromised as well. However, the newly cloned Whonix-Gateways will end up with a different set of Tor entry guards, unless you take precautions.<ref>Such as manually sharing your entry guards. Qube-Whonix users can [[Tor#Copy_Tor_Configuration_files_and_Settings_to_Another_sys-whonix_Instance|copy the Tor state folder to another sys-whonix]] (Non-Qubes-Whonix no documentation ever written to my knowledge) or using the same [[Bridges]]</ref>. Your ISP could guess that you are using two different Tor data folders, for whatever that's worth. (If you are using multiple Tor Browsers, you end up with different sets of Tor entry guards as well.)


If creating a new App Qube is unfamiliar, follow this step-by-step instructions:
{{mbox

| type = notice
{{box|text=
| image = [[File:Ambox_notice.png|40px|alt=Info]]

| text ='''Note''': Multiple Whonix-Gateways are easier to manage and more secure when only a single Whonix-Gateway is used at the same time.
'''Figure:''' ''App Qube Creation using Qubes VM Manager (QVMM)''

{{ContentImage|
[[Image:Create_Qubes-Whonix-Workstation_AppVM.png|App Qube Creation using Qubes VM Manager (QVMM)]]
}}
}}


'''A.)''' Create Qubes-{{project_name_workstation_short}} App Qube
==== Qubes-Whonix ====
'''Setting up additional Whonix-Gateways (commonly called <code>sys-whonix</code>) with [[Qubes|Qubes-Whonix]]'''


'''B.)''' Name and label: Name the App Qube. Don't include any personal information (if the App Qube is compromised, the attacker could run <code>qubesdb-read /name</code> to reveal the VM name). Name the App Qube something generic, for example: <code>{{project_name_workstation_vm}}<u>-2</u></code>.
The only requirement for a newly created <code>sys-whonix</code> is it must be based on <code>whonix-gw</code> TemplateVM and <u>given a distinctive VM name</u>.


'''C.)''' Color: Choose a color label for the {{project_name_workstation_short}} App Qube.
1. Create a new <code>sys-whonix</code> VM.


'''D.)''' Use this template: Choose the {{project_name_workstation_short}} Template. For example: <code>{{project_name_workstation_template}}</code>.
Users can create a new <code>sys-whonix</code> ProxyVM by following the step-by-step directions: [[Qubes/Create_Gateway_ProxyVMs| Create Gateway ProxyVMs]].


'''E.)''' Standalone: Leave the Standalone field unchecked, unless a persistent root filesystem is desired.
==== Non-Qubes-Whonix ====
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px">
If you are interested in this with [[Non-Qubes-Whonix]], please press on expand on the right.
<div class="mw-collapsible-content">


'''F.)''' Type: Choose the type <code>App Qube</code>.
===== Introduction =====
When using multiple Whonix-Gateway VMs at the same time, the risks explained in the introduction chapter on this page apply.


'''G.)''' Allow networking: Choose the desired {{project_name_gateway_short}} ProxyVM from the list. For example: <code>{{project_name_gateway_vm}}</code>.
'''Setting up additional Whonix-Workstations with download/default Whonix-Workstations'''


'''H.)''' Press: <code>OK</code>.
{{Non-Qubes-Whonix}}


'''I.)''' Open a dom0 terminal.
===== VirtualBox =====
In this case, you also have to change Whonix-Gateway network interface2 and Whonix-Workstation network interface1 from internal network "Whonix" to something else.


'''J.)''' Add qvm-tag <code>anon-vm</code> to the newly created App Qube. <ref>
===== KVM =====
[[Dev/Qubes#qvm-tags|Developer documentation about <code>qvm-tags</code>]]
</ref>


<u>Note:</u> Replace <code>{{project_name_workstation_vm}}<u>-2</u></code> with the actual name of the VM.
See [[KVM#Multiple_Whonix-Gateways|Multiple Whonix-Gateways]].
</div>
</div>


{{CodeSelect|code=
= Multiple Qubes-Whonix TemplateVMs =
qvm-tags anon-whonix-2 add anon-vm
}}


'''M.)''' Done.
Multiple [[Qubes-Whonix]] TemplateVMs provides much greater flexibility over a single template when choosing software packages. The additional cloned templates can be customized with software to meet specific requirements which would not be possible if a single TemplateVM was used.<ref>Users may also wish to clone the default template and use the clone as default template for AppVMS. This ensures availability of a “known-good” backup template.</ref>
}} <!-- close tab: {{q_project_name_short}} -->


'''3.''' Depending on the <code>net qube</code> setting.
* '''Packages from a later release''' - Installing packages from a later release could end up breaking the system. For example, mixing packages from [https://wiki.debian.org/DebianStable Debian Stable] with those from a later release like [https://wiki.debian.org/DebianTesting Debian Testing] can lead to a destabilized system due to associated software dependencies required for full functionality.<ref>Using packages from different repositories can lead to [[Install Software#Dependency_Hell| Dependence Hell]]</ref><ref>This problem can be avoided by cloning additional Whonix templates and preferring packages from a single repository in each TemplateVM.</ref>Prior to installing Debian packages from a later release, first read [[Install Software#Install_from_Debian_testing| #Install from Debian testing]].


{{Tab
* '''Custom software''' - With additional cloned templates users can install custom software used for a specific application. For example, users can [[Tunnel UDP over Tor]] by configuring <code>whonix-ws</code> to route all applications through a VPN tunnel. However, this method has the disadvantage of increasing the risk of identity correlation. To limit this risk, the AppVM based on this template should only be used for the particular application that a users needs to route through the <i>tunnel-link</i>. Before installing custom software users are encouraged to read [[Install Software#General_Advice| Install Software General Advice]]
|type=controller
|content=
{{Tab
|title= ===If you are using the default sys-whonix as gateway===
|type=section
|addToClass=info-box
|active=true
|content=


If the {{project_name_workstation_short}} App Qube <u>is connected to <code>{{project_name_gateway_vm}}</code></u></u>: No special instructions required.
* '''Untrusted packages''' - Users should not install untrusted packages in a template used for sensitive activities. With multiple cloned TemplateVMs, a single template can be designated as a less trusted domain in which to install those packages.<ref>Users are strongly encouraged to install only signed packages from a trusted source.</ref> Read [https://qubes-os.org/doc/software-update-vm/#notes-on-trusting-your-templatevms Notes on trusting your TemplateVM(s)] prior to installing untrusted packages.


}} <!-- close tab A -->
=== Cloning TemplateVMs ===
{{mbox
{{Tab
|title= ===If you are using a gateway other than sys-whonix===
| type = notice
|content=
| image = [[File:Ambox_notice.png|40px|alt=Info]]

| text ='''Note:''' Each TemplatesVM's root filesystem runs independently from all other TemplateVMs.<ref>This applies to all TemplateVMs regardless if they were cloned.</ref> This requires users to update each TemplateVM seperatly from all other TemplatesVMs
If the {{project_name_workstation_short}} App Qube <u>is connected to any {{project_name_gateway_short}} other than <code>{{project_name_gateway_vm}}</code></u>, apply the following instructions:

The other gateway should be set up according to the instructions on the [[Multiple Whonix-Gateway]] wiki page.

{{box|text=
<u>Note:</u> Inside the {{project_name_workstation_short}} App Qube.

'''A.)''' Create folder <code>/usr/local/etc/sdwdate-gui.d</code>.

{{CodeSelect|code=
sudo mkdir -p /usr/local/etc/sdwdate-gui.d
}}
}}


'''B.)''' Open with root rights.
Cloning templates in [[Qubes-Whonix]] is a simple and process that can be accomplished by using Qubes Manager. However, care should be excersized when choosing names for both TemplateVMs and the AppVM based on those templates. The newly cloned TemplateVMs should be given names that are not easily confused for other TemplatesVMs. This will minimize the chances of a user basing an AppVM on the wrong template.<ref>There could be serious security concerns if a user based a trusted AppVM on the wrong template such as a TemplateVM with untrusted packages.</ref> When creating AppVMs based on cloned TemplateVMs, a purpose-based naming convention should be used so there is no ambiguity as to the intended use of an AppVM. For example, if an AppVM is created to tunnel UDP over Tor, users would append <code>tunnel-udp</code> (the purpose) to the end of <code>anon-whonix</code> which would create the name <code>anon-whonix-tunnel-udp</code>.
<!-- WIKI EDITORS NOTE: Template:Open_with_root_rights should not be used. -->

{{CodeSelect|code=
sudoedit /usr/local/etc/sdwdate-gui.d/50_user.conf
}}

'''C.)''' Add the following text.

Note: The following example uses <code>{{project_name_gateway_vm}}<u>-2</u></code> as an example. Replace <code>{{project_name_gateway_vm}}<u>-2</u></code> with the name of the VM of {{project_name_gateway_short}} which this {{project_name_workstation_short}} App Qube uses as its <code>net qube</code>. For example, <code>{{project_name_gateway_vm}}<u>-3</u></code>.

{{CodeSelect|code=
gateway={{project_name_gateway_vm}}-2
}}

'''D.)''' Save the file.

'''E.)''' Restart the VM. <ref>
Or restart sdwdate-watcher (sdwdate-gui).

{{CodeSelect|code=
killall sdwdate-watcher
}}

{{CodeSelect|code=
/usr/libexec/sdwdate-gui/start-maybe
}}
</ref>

'''F.)''' In case of issues.

sdwdate-gui qrexec denied messages? See [[Qubes/Troubleshooting#sdwdate-gui_qrexec_settings|{{q_project_name_short}} troubleshooting, sdwdate-gui qrexec]].
}} <!-- close box -->

}} <!-- close tab: Qubes-Whonix B -->

'''4.''' Done.

The process of setting up an additional {{project_name_workstation_short}} App Qube has been completed.

}} <!-- close tab: Qubes-Whonix -->
}} <!-- close tab controller: Qubes-Whonix A B -->
}} <!-- close tab controller: platform selection -->

= How-to: Use more than One {{project_name_workstation_short}} - More Security =

{{Anchor|Firewall}}
* [[Qubes|{{q_project_name_short}}]]: This step can be skipped. <ref name=qubes-isolated>
By default, App Qubes which are behind the same <code>net qube</code> are prevented from connecting to each other in Qubes.
</ref>
* [[Non-Qubes-Whonix|{{non_q_project_name_short}}]]: See: [[Connections between Gateway and Workstation|Connections between {{project_name_gateway_short}} and {{project_name_workstation_short}}]].

= See Also =


{{multiple-vms-mininav}}
Cloning Qubes-Whonix TemplateVMs is very easy and can be done using Qubes Manager.


* [[Whonix-Workstation]]
<code>Qubes Manager</code> -> <code>whonix template</code> -> <code>Clone qube</code>-> <code>New name</code>
* [[Whonix-Workstation_to_Whonix-Workstation_Connections|Connections between two different Whonix-Workstations]]
</div>
</div>


= Footnotes =
= Footnotes =

Latest revision as of 10:01, 4 March 2024

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 identity (pseudonym). For instance, a strong correlation is formed if two Tor users in one chat 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 Qubesarchive.org 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 Qubearchive.org. 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 /home directory.
  • 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]

warning 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) Attackarchive.org is launched from an infected Whonix VM, then:

  • Whonix-Gateway:
    • The Whonix-Gateway can also be DDOSed, and there is no current defense. This might bring down networking of any connected Whonix-Workstation.
  • Whonix-Workstation
  • Potentially the host could be negatively affected as well.
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:
  • Non-Qubes-Whonix: At risk.
  • Qubes-Whonix: Users are safe, unless Whonix-Gateway is compromised first. [3]
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):

  • Non-Qubes-Whonix:
    • If not compromised: Safe. Multiple Whonix-Workstation which have different internal IPs configured (see the instructions further below) are automatically stream-isolated. [5]
    • If compromised: Not safe. Stream isolation might be broken through impersonating. A compromised VM could use the IP of another VM. Thereby break stream isolation. For a potential remedy see Connections between Whonix-Gateway and Whonix-Workstation.
  • Qubes-Whonix: Safe. [3]
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.

  • Non-Qubes-Whonix: Same as above.
  • Qubes-Whonix: Safe. [3]

How-to: Use more than One Whonix-Workstation - Easy[edit]

Non-Qubes-Whonix

info 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.

warning 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, clonearchive.org 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.

info 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 qubearchive.org.

If creating a new App Qube is unfamiliar, follow this step-by-step instructions:

Figure: App Qube Creation using Qubes VM Manager (QVMM)

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]

See Also[edit]

Footnotes[edit]

  1. ↑ See: Protection Against Real World Attacks.
  2. ↑ Without using an additional exploit to successfully break out of the infected VM, which is a difficult task.
  3. ↑ 3.0 3.1 3.2 3.3 3.4 By default, App Qubes which are behind the same net qube are prevented from connecting to each other in Qubes.
  4. ↑ To minimize the threat of exploits it is recommended to apply relevant instructions found in the System Hardening Checklist.
  5. ↑ Since IsolateClientAddrarchive.org is the Tor default.
  6. ↑ Developer documentation about qvm-tags
  7. ↑ Or restart sdwdate-watcher (sdwdate-gui). killall sdwdate-watcher /usr/libexec/sdwdate-gui/start-maybe
Your support makes
all the difference!

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 12 year success story and maybe DONATE!

Retrieved from "https://www.whonix.org/w/index.php?title=Multiple_Whonix-Workstation&oldid=99117"