Long Wiki Edits Thread

Website
811

Done!

Made edits throughout the chapter. Please let me know if any changes are needed.

Also, posted new screenshots for use with this chapter. Let me know if they’re OK and I’ll upload them to the sever. ( “Clone Qube” has many redactions).

https://forums.whonix.org/t/updated-screenshots-images-thread/5371/12

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 (anon-whonix 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.

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.

Qubes-Whonix vs Non-Qubes-Whonix

When using multiple Whonix-Workstations, Qubes-Whonix is the recommended choice. This is because Qubes-Whonix is specifically designed for compartmentalization (a.k.a. sandboxing) within multiple running VMs. This gives 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 Why use Qubes over other Virtualizers.

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.

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.

  • 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.
      • Non-Qubes-Whonix: There is no defense against DOSing other Whonix-Workstations.
      • Qubes-Whonix: Not applicable.
    • Whonix-Gateway
      • There is no defense.
  • 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.)
  • Workstation-Firewall:
    • Non-Qubes-Whonix: Whonix-Workstation provides an optional, disabled by default (because it can get into the way for other tasks) firewall, that can prevent different Whonix-Workstations from connecting to each other. (See Whonix-Workstation Firewall.) (Will be enabled by default in Whonix 14.)
    • Qubes-Whonix: Not required. (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 IP’s (as recommended in the instructions below) are automatically using Stream Isolation.[ref]Because How can we help? | Tor Project | Support IsolateClientAddr is Tor’s default.[/ref]
    • Qubes-Whonix: Not required. (Details in chapter #Firewall.)

How to use more than one Whonix-Workstation - EASY

Qubes-Whonix

Setting up additional Whonix-Workstations with Qubes-Whonix

Using multiple Whonix-Workstations with Qubes-Whonix is a simple process. To do this users can create an additional AppVM based upon the Whonix-Workstation template (commonly called whonix-ws) with its own distinctive name. After the new AppVM is created ensure that it uses sys-whonix as its NetVM.

Users can follow this link for step-by-step instructions on how to Create Whonix Workstation AppVMs.

Non-Qubes-Whonix

If you are interested in this with Non-Qubes-Whonix, please press on expand on the right.

Setting up additional Whonix-Workstations with download/default Whonix-Workstations

Non-Qubes-Whonix Only!

[noticebox]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.[end/noticebox]

Each additional Whonix-Workstation VM requires its own MAC address and internal LAN IP address.

1. Clone a fresh Whonix-Workstation VM.

VirtualBox

In VirtualBox Manager [clone#link] 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.

[noticebox]Note: A new MAC address is also required if the additional VirtualBox VM is imported.[end/noticebox]

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. In Whonix-Workstation. Open with root rights

/etc/network/interfaces.d/30_non-qubes-whonix

Change the last octet. For example 10.152.152.11 to 10.152.152.12

4. Save and Exit.

5. In Whonix-Workstation, reboot. Or alternately restart the network.

sudo service networking restart

6. Done.

How to use more than one Whonix-Workstation - More Security

  • Qubes-Whonix users: Can skip this. [ref]Because by Qubes default, AppVMs behind the same ProxyVM [or NetVM] are prevented from connecting to each other.[/ref]
  • Non-Qubes-Whonix users (everyone not using Qubes-Whonix): To prevent workstations from connecting to another one, see Whonix-Workstation Firewall. See also Connections between Whonix-Gateway and Whonix-Workstation.

Multiple Whonix-Gateways

Introduction

Advanced users only.

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 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 Copy Tor State Files to Another sys-whonix Instance (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.)

[noticebox]Note: Multiple Whonix-Gateways are easier to manage and more secure when a single Whonix-Gateway is used at at time.[end/noticebox]

Qubes-Whonix
Setting up additional Whonix-Gateway (commonly called sys-whonix) with Qubes-Whonix.

The only requirement for a newly created sys-whonix is it must be based on whonix-gw TemplateVM and given a distinctive VM name.

1. Create a new sys-whonix VM.

Users can create a new ProxyVM by following the step-by-step directions to Create Gateway ProxyVMs.

Non-Qubes-Whonix

If you are interested in this with, please press on expand on the right.

Introduction
When you are using them at the same time, the risks explained in the introduction chapter on this page apply.

Setting up additional Whonix-Workstations with download/default Whonix-Workstations

Non-Qubes-Whonix

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.

KVM

See Multiple Whonix-Gateways.

Cloning Multiple Qubes-Whonix TemplateVMs

Cloning 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]

  • Packages from a later release - Installing packages from a later release could end up breaking the system. For example, mixing packages from Debian Stable with those from a later release like 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 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 later releases, first read #Install from Debian testing.

  • 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 whonix-ws 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 tunnel-link.

  • 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: Notes on trusting your TemplateVM(s) prior to installing untrusted packages.

Cloning Qubes-Whonix TemplateVMs is very easy and can be done using Qubes Manager.

Qubes Manager-> whonix template -> Clone qube-> New name

2 Likes