Security Guide

(Redirected from Update)

About this Security Guide Page
Support Status stable
Difficulty medium
Maintainer Whonix team
Support Support





This Motivation section may be skipped.

If you need motivation to secure your computer, refer to these articles:

If that is too much to read, then just take a glimpse at the graphics:

Advanced Security Guide[edit]

After reading this chapter, users are recommended to refer to the Advanced Security Guide for even more security advice.

Onionizing Repositories[edit]

When Whonix, Debian and Qubes packages are installed or updated, default settings point to repositories with a http:// URI. [1] However, experimental Tor onion services are already available for the Whonix, Debian and Qubes packages.

There are several security and privacy benefits of using Tor onion services: [2]

  • The user cannot be uniquely targeted for malicious updates (attackers are forced to attack everyone requesting the update).
  • The package repository, or observers watching it, can't track what programs are installed.
  • The ISP cannot easily learn what packages are fetched.
  • End-to-end authentication and encryption provides protection against man-in-the-middle attacks e.g. version downgrade attacks.

Qubes Packages[edit]

The following commands must be run in dom0 in order to use Qubes’ Tor onion service repositories for each type of VM. [5]

The downside of this approach is that repository definitions are managed by a Qubes package, meaning manual updates are needed if the the definitions change in the future.


In dom0, run.

sudo sed -i 's/' /etc/yum.repos.d/qubes-dom0.repo && cat /etc/yum.repos.d/qubes-dom0.repo
sudo sed -i 's/' /etc/yum.repos.d/qubes-templates.repo && cat /etc/yum.repos.d/qubes-templates.repo

Fedora Template

In dom0, run.

qvm-run -a --nogui -p -u root <your_fedora_template> 'sed -i "s/" /etc/yum.repos.d/qubes-r* && cat /etc/yum.repos.d/qubes-r*'

Debian and Whonix Templates

In dom0, run.

qvm-run -a --nogui -p -u root <your_debian_template> 'sed -i "s/" /etc/apt/sources.list.d/qubes-r* && cat /etc/apt/sources.list.d/qubes-r*'

Whonix and Debian Packages[edit]

Until Whonix 14 is released, users may consider manually editing their sources.list to point to the Whonix and Debian .onion mirrors in order to install or update more securely.

The whonix.list and debian.list files in the /etc/apt/sources.list.d directory should be changed in both the Whonix-Workstation and Whonix-Gateway. Qubes-Whonix users note: Complete these steps in the whonix-gw and whonix-ws TemplateVMs.

1. Edit sources.list

In the Whonix-Gateway, edit the debian.list file using an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix, run.

kdesudo kwrite /etc/apt/sources.list.d/debian.list

If you are using a terminal-only Whonix, run.

sudo nano /etc/apt/sources.list.d/debian.list

2. Reference the Onionized Debian Repositories

Cut and paste the following .onion mirrors and comment out (#) the corresponding http repositories.

#deb jessie main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie main contrib non-free

#deb jessie/updates main contrib non-free
deb http://sgvtcaew4bxjd7ln.onion jessie/updates main contrib non-free

#Optional Backports
#deb jessie-backports main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie-backports main contrib non-free

Save and exit.

3. Reference the Onionized Whonix APT Repository

To use the v3 onion, run. [7]

sudo whonix_repository --baseuri http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion --enable --repository stable

4. Confirm the Onionized Repositories are Functional

sudo apt-get update && sudo apt-get dist-upgrade

5. Repeat Steps 1 to 4 for the Whonix-Workstation

6. Optional: Onionize Tor Project Updates

Only complete this step if the Tor versions from The Tor Project repository are being used. The Tor Project deb apt signing key must be added first (see the link above), or the user will receive error messages when completing these steps.

The following commands are run in either the Whonix-Gateway or whonix-gw TemplateVM (for Qubes R3.2 users).

Note: Qubes-R4.0 TemplateVMs are non-network connected by default which will cause attempts to download the apt key in whonix-gw to fail.[8] To work around this issue users can fetch the Tor apt singing key from a (networked) anon-whonix AppVM. Then copy the key over to whonix-gw in a text file.

To add the Tor Project deb apt signing key, run. (In anon-whonix VM for Qubes-R4.0)

sudo apt-key adv --keyserver --recv-keys A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89

To display the keys fingerprint, run.

sudo apt-key adv --fingerprint A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89

Compare the fingerprint displayed in terminal with the one listed on this website

(Qubes-R4.0 only!) In anon-whonix, copy the Tor singing key to a new text file named tor.key

sudo apt-key export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 > /tmp/tor.key

(Qubes-R4.0 only!) In anon-whonix, copy the tor.key text file over to whonix-gw.

qvm-copy /tmp/tor.key whonix-gw

If the following error appears, it can be safely ignored (hit "OK" when prompted).

 qfile-agent: Fatal error: stat whonix-gw-version (error type: No such file or directory)

(Qubes-R4.0 only!) In whonix-gw, add the Tor signing key to the list of trusted keys.

sudo apt-key add ~/QubesIncoming/anon-whonix/tor.key

To onionize Tor Project updates first create a torproject.list file using an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix, run.

kdesudo kwrite /etc/apt/sources.list.d/torproject.list

If you are using a terminal-only Whonix, run.

sudo nano /etc/apt/sources.list.d/torproject.list

Next, cut and paste the following text and comment out (#) the corresponding http repository.

#Tor Project Mirror
#deb jessie main
deb http://sdscoq7snqtznauu.onion/ jessie main

Save and exit.

Operating System[edit]

End-of-life Software[edit]

Users should not run software that has reached end-of-life status, because developers will not fix existing defects, bugs or vulnerabilities, posing serious security risks.

A recent example is VLC in Debian jessie, which reached end-of-life status in May, 2018. Therefore, a different media player should be used until Whonix 14 is released, because VLC in jessie has current unpatched security vulnerabilities.

Installing Additional Software[edit]

See Install Software.


Be sure to read and understand CVE-2016-1252 secure apt-get upgrading.

1. Update the Package Lists

Check package lists on at least a daily basis and keep the host operating system updated. To update Whonix-Gateway and Whonix-Workstation packages lists, run.

sudo apt-get update

The output should look similar to this.

Hit jessie/updates Release.gpg                                                                                                    
Hit jessie/updates Release                                                                                                        
Hit jessie Release.gpg                           
Hit jessie Release.gpg
Hit jessie/updates/main i386 Packages
Hit jessie Release                                             
Hit jessie/updates/contrib i386 Packages    
Hit jessie Release                           
Hit jessie/updates/non-free i386 Packages  
Hit jessie/main i386 Packages               
Hit jessie/updates/contrib Translation-en  
Hit jessie/main i386 Packages                
Hit jessie/updates/main Translation-en                        
Hit jessie/contrib i386 Packages                                
Hit jessie/updates/non-free Translation-en                    
Hit jessie/non-free i386 Packages                               
Ign jessie/contrib Translation-en              
Ign jessie/main Translation-en
Ign jessie/non-free Translation-en
Ign jessie/main Translation-en_US
Ign jessie/main Translation-en
Reading package lists... Done

If you see something like this.

W: Failed to fetch 404 Not Found

W: Failed to fetch 404 Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.

Err jessie Release.gpg
  Could not resolve ''
Err jessie Release.gpg
  Could not resolve ''
Err jessie/updates Release.gpg
  Could not resolve ''
Reading package lists... Done
W: Failed to fetch  Could not resolve ''

W: Failed to fetch  Could not resolve ''

W: Failed to fetch  Could not resolve ''

W: Some index files failed to download. They have been ignored, or old ones used instead.

Or this.

500  Unable to connect

Then something went wrong. It could be a temporary Tor exit relay or server failure that should resolve itself. Check if the network connection is functional by changing the Tor circuit and trying again. Running whonixcheck might also help to diagnose the problem.

Sometimes a message like this will appear.

Could not resolve ''

It that case, it helps to run.


And then try again.

2. Upgrade

sudo apt-get dist-upgrade

Please note that if the Whonix APT Repository was disabled (see Disable_Whonix_APT_Repository), then manual checks are required for new Whonix releases and manual installation from source code.

3. Never Install Unsigned Packages!

If a message like this appears.

WARNING: The following packages cannot be authenticated!
Install these packages without verification [y/N]?

Then don't proceed! Press N and <enter>. Running apt-get update again should fix it. If not, something is broken or it is a man-in-the-middle attack, which isn't that unlikely since updates are retrieved over Tor exit relays and some of them are malicious. Changing the Tor circuit is recommended if this message appears.

4. Signature Verification Warnings

There should be no signature verification warnings at the moment. If such a warning appears, it will look like this.

W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: stable Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681

Caution is required in this case, even though apt-get will automatically ignore repositories with expired keys or signatures, and the user will not receive upgrades from that repository. Unless the issue is already known or documented, it should be reported so it can be further investigated.

There are two possible reasons why this could happen. Either there is an issue with the repository that the maintainers have yet to fix or the user is the victim of a man-in-the-middle attack. [9] The latter is not a big issue, since no malicious packages are installed. Further, it may automatically resolve itself after a period of time when a different, non-malicious Tor exit relay is used, or following a manual change of the Tor circuit.

In the past, various apt repositories were signed with an expired key. To see how the documentation looked at that point, please click on Expand on the right.

For instance, the Tor Project's apt repository key had expired and the following warning appeared.

W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: stable Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681

W: Failed to fetch  

W: Some index files failed to download. They have been ignored, or old ones used instead.

This issue had already been reported. There was no immediate danger and it could have safely been ignored. Just make sure to never install unsigned packages as explained above.

For another example, see the more recent Whonix apt repository keyexpired error.

Please report any other signature verification errors if/when they appear. This outcome is considered unlikely at this time.

5. Changed Configuration Files

If a message like this appears.

Setting up ifupdown ...
Configuration file `/etc/network/interfaces'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : background this process to examine the situation
 The default action is to keep your current version.
*** interfaces (Y/I/N/O/D/Z) [default=N] ? N

Be careful. If the updated file isn't coming from a Whonix specific package (some are called whonix-...), then press n. Otherwise, Whonix settings affecting anonymity, privacy, and security might be lost. Advanced users who know better can of course manually check the differences and merge them.

This is how to determine if the file is coming from a Whonix-specific package or not:

  • Whonix-specific packages are sometimes called whonix-.... In the example above it is saying "Setting up ifupdown ...", so the file isn't coming from a Whonix-specific package. In this case, the user should press n as previously advised.
  • If the package name does include whonix-..., it is a Whonix-specific package. In that case, the safest bet is pressing y, but then any customized settings will be lost (these can be re-added afterwards). Such conflicts will hopefully rarely happen if using Whonix's modular flexible .d style configuration folders.

6. Restart Services After Upgrading

To restart services after upgrading, either simply reboot.

sudo reboot

Or to omit rebooting, use the needrestart method (harder). For users interested in the latter method, please click on Expand on the right side.

Do this once. Install needrestart.

sudo apt-get update
sudo apt-get install needrestart

Run needrestart.

sudo needrestart

The program will provide some advice. Run it again after applying the advice.

sudo needrestart

If nothing else has to be restarted, it should show.

No services need to be restarted.

This feature might become more usable and automated in the future. (T324)

7. Restart After Kernel Upgrades

When linux-image-... is upgraded, a reboot is required to profit from any security updates.

Updating with Extra Care[edit]

See How-to: Install or Update with Utmost Caution.


If weak passwords (passphrases) are used, they can be easily determined by brute-force attacks, whether or not Whonix is installed. In essence, attackers systematically try all passwords until the correct one is found, or attempt to guess the key which is created from the password using a key derivation function (an exhaustive key search). This method is very fast for short and/or non-random passwords.

Generating Unbreakable Passwords[edit]

To generate passphrases which cannot be bruteforced even over a timeframe of several billion years (barring breakthroughs in quantum computing), users should default to diceware passphrases of 7-8 words in length, with the words chosen randomly by dice rolls. This provides password entropy of 80-96 bits. [11] Generally speaking, lower entropy is reasonable to prevent online attacks due to limits on incorrect username/password combinations, but up to 128 bits of entropy is suggested for important cryptographic keys; a Diceware passphrase of 10 words in length. [12]

Principles for Stronger Passwords[edit]

Users should read Wikipedia: Weak Passwords to learn better practices for generating strong passwords, and to learn if current passwords are weak. (w). The general principles for stronger passwords are: [13]

  • Avoid short passwords of less than 12-14 characters in length - longer passwords are exponentially more difficult to crack than shorter ones. [14]
  • Include: Upper and lower case characters, special characters, digits, spaces, underscores and brackets (unless using Diceware passphrases - see above).
  • Do not re-use passwords anywhere.
  • Generate passwords randomly.
  • Avoid dictionary-based passwords or those dependent on keyboard patterns, special letter or number sequences, usernames, relative or pet names, biographical information, or persons known to the user.
  • Avoid information that might be publicly linked to the user or the user's account, or which is known by friends or acquaintances.
  • If passwords are written down, they should not be left in obvious places.
  • Consider using a secure password manager, so hundreds of different passwords can be kept stored in an encrypted password database, with access only requiring one master password (which itself should be a cryptographically strong password).

Platform Security[edit]

Host Security[edit]


Please read the Computer Security Education section about Host Security.

Anonymous Mobile Modems[edit]

Mobile modems refers to portable broadband modems which allow your computer to connect to the internet via the cellular network. These devices support use of the 2G, 3G and 4G networks.

For activities necessitating the best possible anonymity, it is theoretically safer to use an anonymous mobile modem far away from one's normal location, rather than use a local internet connection. The reason is the dial-up or broadband provider normally knows your name, postal address and non-anonymous payment method. This is problematic if Tor or Whonix is compromised, since an adversary could pressure the service provider and very easily confirm your identity. However, if a mobile modem user is successfully attacked, the IP address leaked will not immediately lead back to the postal address of the user.

It is safest to assume that identification and location information can be discovered if specifically targeted, alongside potential eavesdropping of activities and communications. Always conduct a threat assessment of planned activities before following any course of action!

Default Configuration Whonix Users


  • Plug or integrate the mobile modem into the host operating system as its internet connection replacement (easy).
  • Plug the mobile modem into the Whonix-Gateway and only route Whonix-Gateway's traffic through it, not the host traffic (difficult; undocumented and therefore not recommended).

Physically-Isolated Whonix Users

Use the second method outlined above. There is no host in the sense that the Whonix-Gateway is running bare-metal on a second computer.

Safe Purchase of a Mobile Modem and SIM Card


  • Buy the mobile modem anonymously. This may be in a store, second-hand, or on the street. Be sure to leave no personal data during the purchase.
  • Be aware of cameras and potential witnesses to your purchases.
  • Do not use the modem for any non-anonymous activity prior to using it for Whonix purposes.
  • Telecommunication companies routinely log the serial numbers of phones (IMEI) and SIM cards, as well as the phone number for network logins. Therefore it is also necessary to:
    • Buy the SIM card anonymously (prepaid is better).
    • Buy cash codes in different stores anonymously.
    • Never use the anonymous SIM card with a non-anonymous phone or mobile modem beforehand.

Mobile Modem Warnings

  • Many devices are manufactured by a handful of countries that have run insecure software in the recent past.
  • Devices often show critical zero days. For example: remote code executive flaws, exploitable firmware, vulnerability to cross-site scripting and CSRF vulnerabilities.

Carefully choose all hardware and conduct manufacturer research beforehand!

Mobile Modem Operation

When using cellular networks, users often only get a shared external IP address due to scarcity of IPv4 IPs. This can lead to thousands of users sharing one IPv4 address at the same time. Also, some providers do not yet log the users' (NAT) ports. Consequently, providers cannot pinpoint users when they are given an IP address and time stamp. This is a nice feature, but do not rely on it for strong anonymity!

Some providers assign additional and unique IPv6 IP addresses to their users. This is not a concern for intended Tor usage, as it does not yet automatically utilize IPv6. [15] For greater security, prefer using a new, distant, random, non-circular location when conducting on-line activities.

Anonymous WiFi Adapters[edit]

Normally the dial-up or broadband provider knows your name, postal address and non-anonymous payment method. If Tor or Whonix is compromised, then an adversary only needs to pressure the service provider to confirm your identity. This is not the case if using an anonymous WiFi adapter plugged or integrated into the Whonix-Gateway.

For safer use, it is recommended to:

  • Buy the WiFi adapter anonymously in a store, second-hand or on the street.
  • Never provide personal data during a purchase.
  • Do not use the adapter for prior, non-anonymous activity. Some providers or hotspots log MAC addresses and the username (if paid).
  • If possible, only use free hotspots or pay for them anonymously. Otherwise abstain from paid hotspots.
  • For greater security, always use a new, distant, random, non-circular hotspot location.
  • Check for cameras and witnesses during online activities.


Whonix does not yet improve host security. It is recommended to use a secure host operating system like Debian GNU/Linux and manually harden it. Also follow relevant steps in the system hardening checklist for greater security.

Hardware Component Risks[edit]

In the default configuration, Whonix provides significant protection against circumvention of the proxy obedience design. This includes:

  • Applications not honoring proxy settings (proxy bypass IP leaks).
  • Applications disclosing the user's real IP (protocol IP leaks).
  • Remote code execution exploits with user-only rights (exploit + unsafe browser).
  • Remote code execution exploits with root rights (exploit + root exploit + unsafe browser).

However, if a second exploit is used to break out of the VM, the default Whonix installation is broken and the user's real IP address will be identified. Only Whonix run with physical isolation will defeat this attack. This is because the Whonix-Workstation host does not know the real IP address, only the Whonix-Gateway which is running on another machine. Consequently, to successfully deanonymize the user, the attacker must also: exploit the physically isolated Whonix-Gateway, subvert the Tor process, or attack the Tor network at large.

Nevertheless, physically-isolated users should be aware that if an adversary manages to break out of the Whonix-Workstation VM using an exploit, then additional risks are posed by the hardware components that are built-in or have been additionally installed. This includes CPU and HDD / SSD temperature sensors, microphones and cameras.

In the case of Whonix with physical isolation:

  • The user's IP address is still safe, but the temperature sensors can be used for anonymity set reduction.
  • Different CPU, HDD and SSD models will report different sensor information, depending on climate and weather. If possible, it is advised to remove or to obfuscate the sensor results.
  • Cameras and microphones can be covertly activated by the adversary. Remove external hardware and/or disable them in BIOS if possible. At a minimum, cover them or ideally remove them.

In the case of a default Whonix installation, the same general recommendations apply, although it does not really matter since the user will have been deanonymized successfully.


The hostname given to a user’s home computer or device can be leaked via a number of protocols, posing a privacy risk depending on the specificity of the naming convention. For further information, see here.

Power Saving Considerations[edit]

Users at high risk or traveling should avoid leaving a system in the suspend or standby state. Instead, the recommended power mode to use is hibernation. This will lock all system partitions to a safe state, though there is a small trade-off in startup time.

On GNU/Linux hosts, standby will not always result in having LUKS keys retained in memory. Some experimental projects [16] and custom setups with systemd+scripting are able to erase the keys before system suspend to avoid mistakes.

Following a system standby period, the network fingerprint for Tor on the Whonix-Gateway is identical to a standard Tor instance on the host that has gone through the same procedure. There are some old connections that go stale and need renewal, but nothing is seen by a network adversary because time leak identifiers have been stripped out of Tor's protocol / OpenSSL, and TCP Timestamps are gone.

Non-Qubes-Whonix only:
In order to reconnect, manual time adjustment is required or the VM can simply be powered off and then powered on again. This step will not be necessary once hypervisor specific post resume hooks are used, because guest clocks will be seamlessly updated upon power state changes from the host.

Qubes-Whonix only:
Has automatic seamless time adjustment after resume. [17]

Qubes-Whonix Security[edit]

The following list of actionable items can help to improve security and anonymity on the Qubes platform, and by extension Qubes-Whonix users. It is advised to regularly consult Qubes forums and other channels for the latest security news and advice.

GPG and Software Packages

  • Always keep the system up to date in dom0, template VMs and standalone VMs.
  • Check gpg is enabled in config files (gpgcheck=1) if new Fedora repositories are installed.
  • Safely import new signing keys by checking it is the same from multiple sources.
  • Preferably only install packages from trusted sources, for example pre-configured Fedora, Debian, Whonix and Qubes sources.
  • Untrusted or unverifiable programs should be installed in Standalone VMs or less trusted, cloned templates.

Hardware / Hardware Settings

  • Enable VT-d/IOMMU via BIOS to have DMA protection, effective network isolation, and the ability to assign PCIe devices to a HVM. Check it is running via dom0 (qubes-hcl-report).
  • Ensure Intel VT-x or AMD-V is available, since it is required for running HVM domains, such as Windows-based AppVMs.
  • Prepare and utilize a USB qube to protect against side-channel attacks. [18]
  • Use a Yubikey to enhance the security of Qubes user authentication, mitigate the risk of password snooping, and to improve USB keyboard security.
  • Prefer Intel Integrated Graphics Processing (IGP) units for greater system stability and security. [19]
  • Ensure computer hardware meets all other Qubes-Whonix requirements for the best security, functionality and future compatibility with Qubes 4.X releases.

ISO and Qubes Version

  • Verify the authenticity and integrity of the Qubes iso download.
  • Prefer Qubes R4.0 over earlier releases, as fully virtualized (HVM or PVH) VMs provide greater protection against processor speculative execution bugs like the Meltdown and Spectre attacks, and other exploits. [20] [21]

Protecting User Data and Activities

  • For critical user data, protect against unintentional leaks by setting an empty NetVM field (set to "none") for the corresponding qube.
  • For sensitive activities, do not run trusted, high-value VMs in paralell with untrusted VMs. [22]
  • Observe the security context of colored windows borders in Qubes before running applications or manipulating data.
  • If paying in cryptocurrencies, utilize a “split” bitcoin wallet which creates an offline “cold storage” wallet and an online “watching only” wallet.
  • Avoid dual / multi-boot configurations in Qubes. The other OS could modify the unprotected /boot partition or firmware to maliciously compromise Qubes and/or spy on user activities.
  • Be careful when running command line operations. Refer to a suitable resource first, then proceed.
  • Use split-GPG for email to reduce the risk of key theft used for encryption / decryption and signing.

Template and Other VMs

  • Never run applications in TemplateVMs or dom0, except updating tools or editors for configuration purposes (running applications poses security risks).
  • Avoid configuring network traffic between two qubes for security reasons.
  • Consider leveraging the non-persistence of Qubes' templates to fend off malware by locking-down, quarantining and checking the contents of /rw private storage. [23] [24] [25]
  • Consider split dm-crypt to isolate device-mapper based secondary storage encryption (not the root filesystem) and LUKS header processing to DisposableVMs.
  • Consider running sys-net, sys-firewall and sys-usb as Static DisposableVMs.

Whonix-Gateway Security[edit]


According to [26]

AppArmor is a Mandatory Access Control framework. When enabled, AppArmor confines programs according to a set of rules that specify what files a given program can access. This proactive approach helps protect the system against both known and unknown vulnerabilities.

AppArmor provides a number of advantages: [27]

  • It protects the operating system and applications from external or internal threats, including zero-day attacks.
  • "Good behavior" is enforced and it mitigates exploits via unknown application flaws.
  • AppArmor security policies define the system resources that individual applications can access, and with what privileges. For instance:
    • Network access.
    • Raw socket access.
    • Read, write or execute file permissions on specific paths.

Strongly consider using the Whonix AppArmor profiles which are available for various programs which run in both the Whonix-Gateway and Whonix-Workstation, such as Tor, Tor Browser, Thunderbird and others. The profiles are easily applied and provide a considerable security benefit.


If the Whonix-Gateway VM is ever compromised, the attacker can discover: the user's identity (public IP address); all destinations visited; and the entirety of clear-text and onion service communication over Tor.

Before installing any extra packages on the Whonix-Gateway, first consult the developers to check whether that is necessary and wise.


According to Mozilla: [28]

Seccomp stands for secure computing mode. It is a simple sandboxing tool in the Linux kernel, available since Linux version 2.6.12. When enabling seccomp, the process enters a "secure mode" where a very small number of system calls are available (exit(), read(), write(), sigreturn()). Writing code to work in this environment is difficult; for example, dynamic memory allocation (using brk() or mmap(), either directly or to implement malloc()) is not possible.

Strongly consider enabling seccomp on Whonix-Gateway (Qubes-Whonix: Whonix-Gateway ProxyVM; sys-whonix), since it is easily applied and provides additional sandboxing protection for the Tor process.

Open /etc/tor/torrc.

If you are using Qubes-Whonix, complete the following steps.

Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named sys-whonix) -> Tor User Config (Torrc)

If you are using a graphical Whonix-Gateway, complete the following steps.

Start Menu -> Applications -> Settings -> /etc/tor/torrc

If you are using a terminal-only Whonix-Gateway, complete the following steps.

sudo nano /etc/tor/torrc


Sandbox 1

Save and exit.

Tor Connection Padding[edit]

Connection padding is available for the Tor process from version onward. This helps to resist traffic analysis, as The Tor Project explains: [29] [30]

Connections between clients and relays now send a padding cell in each direction every 1.5 to 9.5 seconds (tunable via consensus parameters). This padding will not resist specialized eavesdroppers, but it should be enough to make many ISPs’ routine network flow logging less useful in traffic analysis against Tor users.

Padding is negotiated using Tor’s link protocol, so both relays and clients must upgrade for this to take effect. Clients may still send padding despite the relay’s version by setting ConnectionPadding 1 in torrc, and may disable padding by setting ConnectionPadding 0 in torrc.

Consider enabling ConnectionPadding client-side by following these steps.

Open /etc/tor/torrc.

If you are using Qubes-Whonix, complete the following steps.

Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named sys-whonix) -> Tor User Config (Torrc)

If you are using a graphical Whonix-Gateway, complete the following steps.

Start Menu -> Applications -> Settings -> /etc/tor/torrc

If you are using a terminal-only Whonix-Gateway, complete the following steps.

sudo nano /etc/tor/torrc


ConnectionPadding 1

Save and exit.

Warning: Bridged Networking[edit]

Do not change Whonix-Gateway's first or second network interface to a bridged network. This is untested and should not be necessary. Users who feel it is necessary in their circumstances should get in contact.

For further interest, here is a discussion thread, and another one, debating whether NAT or a bridged network is more secure.

Whonix-Workstation Security[edit]


If the Whonix-Workstation VM is ever compromised, the attacker has access to the data it contains, including all credentials, browser data and passwords. The IP address is never leaked, since this requires a compromise of the Whonix-Gateway VM, but this information may still result in identity disclosure.

In Non-Qubes-Whonix:

The best practice is to keep a clean master copy of the Whonix-Workstation VM, make snapshots / clones of the master, and then only use these for internet activity. The user can then 'rollback' (use a new clean clone / snapshot VM) after risky activity, or if they suspect the integrity of the system has been compromised. See the multiple VM snapshots recommendation below.

In Qubes-Whonix:

The best practice is to use DisposableVMs for all your internet activity. Alternatively, periodically delete your Whonix-Workstation AppVM(s) and create fresh instances from the Whonix-Workstation TemplateVM.

Adding a Host-Only Networking Adapter to Whonix-Workstation / SSH into Whonix-Workstation[edit]

If accessing the Whonix-Workstation via SSH, some users may consider something dangerous - adding a second network adapter with host-only networking.

The VMware host-only warning regarding routing and connection sharing may equally apply to Whonix: [31]

If you install the proper routing or proxy software on your host computer, you can establish a connection between the host virtual Ethernet adapter and a physical network adapter on the host computer. This allows you, for example, to connect the virtual machine to a Token Ring or other non-Ethernet network. On a Windows 2000, Windows XP or Windows Server 2003 host computer, you can use host-only networking in combination with the Internet connection sharing feature in Windows to allow a virtual machine to use the host's dial-up networking adapter or other connection to the Internet. See your Windows documentation for details on configuring Internet connection sharing.

If it is necessary to SSH or VNC into the Whonix-Workstation, then:

  • It is safest to do this from another Whonix-Workstation. When using VMs, they can see each other if they are within the same virtual LAN. When using Physical Isolation, VMs can see each other if they are within the same LAN.
  • Alternatively run the services using Onion Services and access them through another Whonix-Workstation.
  • Another alternative is to run the services using Onion Services and access them from the host using ordinary torification methods.
  • A final method is to SSH from the host into Whonix-Gateway (see File Transfer for instructions) and then SSH from there into the Whonix-Workstation.

Note: The last two methods are not recommended. They risk weakening isolation between the host and Whonix-Workstation.

Adding a NAT Adapter to Whonix-Workstation / Updates without Tor[edit]

Anonymity is compromised if another NAT network adapter is added to the Whonix-Workstation. If this advice is disregarded, then your identity is leaked if/when infection occurs. Therefore, it is strongly recommended to always update over the Tor network. Although Tor updating is slow by comparison, it prevents inadvertent leaks.


Strongly consider using the Whonix AppArmor profiles which are available for various programs which run in both the Whonix-Gateway and Whonix-Workstation, such as Tor, Tor Browser, Thunderbird and others. The profiles are easily applied and provide a considerable security benefit.



According to the Firejail project page: [32]

Firejail is a SUID program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces and seccomp-bpf. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table. Written in C with virtually no dependencies, the software runs on any Linux computer with a 3.x kernel version or newer. The sandbox is lightweight, the overhead is low. There are no complicated configuration files to edit, no socket connections open, no daemons running in the background. All security features are implemented directly in Linux kernel and available on any Linux computer. The program is released under GPL v2 license.

Firejail has built-in profiles for a large number of popular Linux programs, including many which are used in Whonix. A small sample of the 100+ profiles includes: Chromium, CryptoCat, Dolphin, Evince, Firefox, HexChat, LibreOffice, Okular, Thunderbird, Transmission, VirtualBox, VLC and wget. [33]

Installing Firejail[edit]

1. Boot the Whonix-Workstation (whonix-ws) TemplateVM

2. Add jessie-backports to sources.list

sudo su -c "echo -e 'deb jessie-backports main' > /etc/apt/sources.list.d/jessie-backports.list"
Or alternatively use the .onion mirror.
sudo su -c "echo -e 'deb http://vwakviie2ienjx6t.onion/debian jessie-backports main' > /etc/apt/sources.list.d/jessie-backports.list"

3. Update the Package Lists

sudo apt-get update
4. Install Firejail

sudo apt-get -t jessie-backports install firejail
5. Launch Firejail

Note: In Qubes-Whonix, a new Whonix-Workstation AppVM based on the modified template should be created before running any applications. Never launch programs in your Whonix-Workstation TemplateVM.

To run sandboxed applications, simply prefix your program command with "firejail" in a terminal. For example:

firejail evince

firejail vlc

6. Optional: Use Additional Firejail Command Line Options

The full list of command line options can be found in the official Firejail documentation. Alternatively, run the following command in konsole in the Whonix-Workstation AppVM.

man firejail

The interested reader should note the host of additional security features. For instance, VLC could be run while blocking access to the internet as follows.

firejail --net=none vlc

Similarly, the following commands would run Firefox or Tor Browser with seccomp restrictions and debug output. [34]

firejail --debug --seccomp firefox

firejail --debug --seccomp torbrowser

For a further technical discussion of Firejail, see here.

7. Optional: Automatically Prepend Tor Browser with Firejail

In Whonix 14, users can automatically prepend the Tor Browser binary with Firejail by editing etc/torbrowser.d/50_user.conf and adding the following text. [36]

tb_starter_bin_pre="firejail --seccomp"

Running Firefox-ESR in a Firejail Sandbox (Qubes Debian Template)[edit]

1. Boot the Debian-8 or Debian-9 TemplateVM

2. Follow the Steps to Install Firejail from jessie-backports

3. Create a New Debian-8 or Debian-9 AppVM Based on the Modified Template

4. Launch the Sandboxed Firefox-ESR

In a terminal, run.

   firejail firefox

Note: Refer to the official Firefox Sandboxing Guide for further command line options.

5. Confirm Firefox-ESR is Sandboxed

Open another terminal and run.

   firejail --tree

The output should confirm Firefox-ESR is now running in a firejail container.

   XXXX:user:firejail /usr/lib/firefox-esr/firefox-esr

Sandboxing Tor Browser[edit]

Mitigating the risk of Tor Browser security breaches makes sense, because it is an untrusted application with a huge attack surface; it is frequently and successfully attacked in the wild. [37]

Note: Consider cloning the Whonix-Workstation-TemplateVM prior to installing Firejail. Firejail installs a host of dependencies and users may not want these in the default template.

1. Boot the Whonix-Workstation TemplateVM

2. Follow the Steps to Install Firejail from jessie-backports

3. Create a New Whonix-Workstation-AppVM Based on the Modified Template

Qubes VM Manager -> VM -> Create AppVM

Create Qubes-Whonix-Workstation AppVM.png

4. Optional Step (Untested): Create a Customized Firejail Profile for Tor Browser

Follow these steps to build a custom profile.

5. Launch the Sandboxed Tor Browser

Open a terminal and run.

   firejail torbrowser

6. Confirm Tor Browser is Sandboxed

Launch Tor Browser in the anon-whonix AppVM. Then open a terminal and run.

   firejail --tree

The output should show Tor Browser is now running in a Firejail container.

   XXXX:user:firejail torbrowser
   XXXX:user:/bin/bash /usr/bin/torbrowser
   XXXX:user:bash /home/user/.tb/tor-browser/Browser/start-tor-browser --all
   XXXX:user:./firefox --class Tor Browser -profile TorBrowser/Data/Browse

VM Snapshots[edit]

Apart from offering protection against hardware serial leaks, VMs have another major advantage: the ability to quickly discard and restore a system. This process is easy in Qubes-Whonix, since every template-based AppVM used for activities is based on a TemplateVM which is only used for software installation and updates, and nothing else. AppVMs are easily discarded and recreated in a clean state whenever the user requires it. [39] In Non-Qubes-Whonix, greater precaution is required.

It is strongly recommended the user keep a master copy of the Whonix-Workstation VM which is:

  • Kept updated.
  • Does not have any additional software installed.
  • Does not have any default settings changed.
  • Is not used directly for any activities.

Regular "clean" snapshots or clones of the master VM should be made for activities that require anonymity. Particular care must be taken that clean and unclean states are never mixed up!

The correct method for the safest operation of Non-Qubes-Whonix is as follows:

  1. Import both VMs into the virtualizer.
  2. Start both the Whonix-Gateway and Whonix-Workstation VMs.
  3. Securely update both VMs.
  4. After the updates have finished, shut down both VMs. Do not browse anywhere or open any unauthenticated communication channels to the internet.
  5. Create snapshots of both VMs in their clean state.
  6. Only use the snapshots for browsing or initiating any external connections.

Note: The only exception made is running apt, since it has a guaranteed way to securely download and verify packages.

For important VirtualBox information, please press on Expand on the right.

Although VirtualBox's snapshot feature is useful when making interim snapshots of live running systems, it is not recommended as a reliable method for backing up VMs. The user risks possible data loss, primarily in the form of corrupted virtual hard drives (VHDs). Reverting can be very painful, or even impossible, following VHD corruption. Alternative methods are copy / paste, cloning, and exporting / importing. These methods reliably provide VM backups, but disk resources are used inefficiently and manual versioning is required.

SubVersioN (SVN) Backup Tool

SubVersioN is considered the best alternative tool for backing up VM operating environments. It is similar to VirtualBox's snapshot feature, but is much more reliable and efficient. Prior to using it, familiarize yourself with the tool's documentation and design. SVN clients are available for various platforms.

SVN is a tool typically used by software developers to conduct: collaborative configuration management, version control, and backup / restore of file sets under development by many people over extended period of time. Basic functionality of versioning, backing up and restoring changes to sets of files is available. However, SVN is considered superior to CVS, GIT and other options for VM backups, because it does not have any file size limitations by design. Regardless of how big or small the files are, SVN handles them reliably and efficiently. See the following section: "Be patient with large files".

When versioning file sets, SVN employs "atomic commits". By way of comparison, Concurrent Versions System (CVS) does not employ atomic commits. Manual backup procedures are inherently not atomic functions. Additionally, SVN also handles sparse (dynamic) virtual hard disk files, an option VirtualBox offers when instantiating new virtual disk drives.

Similar to VirtualBox's snapshot capability, SVN also takes into consideration differences in files - both textual and binary - from version to version. For instance, if a 50 GB virtual hard drive grows by an additional 60 GB over the course of a week, SVN's repository will not necessarily increase by an additional 60 GB when a new back up is performed. The outcome depends on how much of the original file changed since the previous backup. SVN will analyze differences between newer files against older files in its repository and only save the differences. Therefore, the repository may only grow as little as 10 GB+, making more efficient use of system resources.

VirtualBox's snapshot feature provides 'branching' capability. This means one can revert to an earlier version of your VM and start a new branch / version of your VM from where you left off earlier. SVN also provides similar branching capability.

Note: For backups and restores, configuration management tools like SVN require significant additional disk space over and above the size of the file. For instance, a 50 GB file typically requires approximately 150 GB of disk space to manage that instance of the VM because you require: 50 GB for the original source file, 50 GB in SVN's database repository, and another 50 GB for SVN's local workspace working folder ('./.svn'). Although this overhead may seem inefficient, it is not when you consider SVN's functionality and reliability in comparison to manual backup methods outlined earlier.

Complete Operating Environment Backups

In addition to backing up the Whonix-Gateway and Whonix-Workstation(s) virtual hard drive files, it is also possible to back up the whole of the VirtualBox application and Whonix environment for a completely restoreable solution. Cloning is another possible option, but that requires more advanced technical skills.

Typically, the VirtualBox application installed is the one provided by However, a portable application version of VirtualBox is available via a tool provided by This application converts VirtualBox's 'install application' into a 'portable application', thereby providing the option to port VMs to other computers via external USB hard drives and/or sticks. By instantiating VMs under portable VirtualBox's '~/data/.VirtualBox/Machines' folder, it is possible to backup and restore the complete operating environment of not only Whonix, but also specific instances of VirtualBox and SVN for complete portability. This method captures the entire Whonix operating environment under one parent folder, rather than distributing it across various user and system folders:

2014-05-11 09 42 19.png

2014-05-11 09 46 43.png

2014-05-11 09 54 39.png

System Hardening Checklist[edit]

It is possible for users to significantly harden their platform and improve the chances of successful, anonymous activity. See: System Hardening Checklist.

Time Attacks[edit]

See Time Attacks.

Tor Versioning[edit]

Newer Tor Versions from the Whonix Repository

Newer Tor versions via the Whonix stable-proposed-updates repository can be installed. Enable the Whonix stable-proposed-updates repository in the Whonix-Gateway (Qubes-Whonix: whonix-gw) and then upgrade the system as usual. This is only recommended for testers.

Even Newer Tor Versions from The Tor Project Repository

Note: This action risks breaking connectivity, for instance if the latest Tor version from has not been fully tested by Whonix developers at a specific point in time. [40]

To proceed despite the risk, install the even newer Tor version by enabling the repository. The anon-shared-build-apt-sources-tpo package must be installed. This enables The Tor Project's apt-get signing key and installs the apt source torproject.list. [41]

In the Whonix-Gateway (Qubes-Whonix: whonix-gw), update the package lists.

sudo apt-get update

Install anon-shared-build-apt-sources-tpo.

sudo apt-get install anon-shared-build-apt-sources-tpo

Refresh the package lists. [42]

sudo apt-get update

Install the (potentially) newer version of Tor. [43]

sudo apt-get install tor

Transporting UDP Tunnels over Tor[edit]

Tor Design

According to the Tor Project: [44]

Tor transports data over encrypted TLS tunnels between nodes, which is in turn carried by TCP.

The current Tor design does not support the transport of UDP-based protocols through exit nodes in the network. This is unlikely to be supported in the near future due to incompatibility with cryptographic protocols in use and those planned.

The consequence is that UDP-based protocols and applications cannot be used to transmit UDP datagrams between guards and exit nodes in the default environment, for example, some VoIP or video applications. [45]

Transporting UDP Tunnels over Tor with a VPN

A solution to this problem is to use a tunneling protocol. In simple terms, this allows a user to access a foreign protocol or network service that the underlying (Tor) network does not support or provide directly.

The tested and working method in Whonix is to utilize a Virtual Private Network (VPN) with a trusted provider that does not block UDP traffic (User -> Tor -> VPN -> [Other Anonymizing Network] -> Internet). Some VPN protocols such as OpenVPN may use UDP while implementing reliable connections and error checking at the application level. [46]

Please first read the related VPN documentation and warnings:

Before following the instructions to tunnel UDP over Tor.

The current Tor architecture may cause negative performance impacts on user activities. This arises from high latency due to congestion in the network, queue length on nodes (mixing of traffic across multiple nodes), and TCP mechanisms which attempt to account for lost packets and hold delivery of future packets until a resend is complete. [47]

Understand that adding a second connection in the tunneling chain adds significant complexity. This potentially increases the user's security and anonymity risks due to: misconfiguration, the increased attack surface of secure tunneling software, the difficulty in anonymously paying for VPN services, and potential bottlenecks with VPN providers. Depending on the configuration, this may also increase fingerprinting risk, remove stream isolation of activities, and lead to a permanent destination X in the Tor network. [48].

Whonix Recommendations

Whonix recommends the use of OpenVPN as the most secure (SSL/TLS-based) protocol, rather than reliance upon IKE, L2TP/IPsec or PPTP. OpenVPN is considered extremely secure when used with encryption algorithms such as AES. [49]

A dedicated virtual machine is recommended for this activity, see: Multiple Whonix-Workstations.

Verifying Software Signatures[edit]

For greater system security, it is strongly recommended to avoid installing unsigned software. Users should also make sure that signing keys and signatures are correct and/or use mechanisms that heavily simplify and automate this process, like apt-get upgrades.

What Digital Signatures Prove[edit]

Users should bear in mind that using digital signatures to verify the trustworthiness of software is not an infallible process. Digital signatures increase the certainty that no backdoor was introduced by a third party during transit, but this does not mean the software is absolutely "backdoor-free". The following is a summary of what digital signatures prove and do not prove.

Digital Signatures Prove

  • Someone with access to the private key has made a signature.
  • The file contents have not been tampered with (preserving integrity).
  • May indicate the given file is authentic.

Digital Signatures do not Prove

  • Any other property, for example, that the file is not malicious. Nothing stops a person from signing a malicious program.
  • That persons signing the file are inherently trustworthy, for example, Microsoft, Whonix developers and so on (but trust must be eventually placed in someone). [50]

If all files downloaded from trusted vendors are verified, then this removes the threat of server compromises, dishonest staff at hosting companies or ISPs, Wi-Fi attacks and so on. The reason is files that have been tampered with will produce bad digital signatures, so long as the public keys used for signature verification are the authentic, original ones (see below).

Checking Digital Fingerprints of Signing Keys[edit]

Based on the preceding information, a critical first step in verifying software is legitimate is to confirm the authenticity of the signing key via its fingerprint. [51] This is a necessary step before keys are imported, or trust is placed in OpenPGP output when verifying files or repositories.

The standard advice in Whonix documentation is to carefully obtain copies of the OpenPGP fingerprint from multiple secure websites, and to use other authentication systems to check they match. [52] In this instance, other "authentication systems" refers to: [53]

  • Use the PGP Web of Trust.
  • Check the key against different keyservers.
  • Use different search engines to search for the fingerprint.
  • Use Tor to view and search for the fingerprint on various websites.
  • Use various VPNs and proxy servers.
  • Use different Wi-Fi networks (work, school, internet cafe, etc.).
  • Ask people to post the fingerprint in various forums and chat rooms.
  • Check against PDFs and photographs in which the fingerprint appears (e.g., slides from a talk or on a T-shirt).
  • Repeat all of the above from different computers and devices.

Checking Digital Fingerprints of Signed Software[edit]

Once a user has carefully:

  • Downloaded a signing key pair.
  • Checked the signing key's fingerprints against multiple sources.
  • Imported the key pair.
  • Downloaded the software package intended for installation.
  • Downloaded the accompanying signature file for the software package (.asc files are GPG signatures).

Then the file(s) signatures must be verified against the signing key.

Below is an example of how to check the file signature, using the Tor Browser bundle v6.5.2 downloaded directly from The Tor Project website.

In a terminal run.

gpg --verify tor-browser-linux64-6.5.2_en-US.tar.xz.asc tor-browser-linux64-6.5.2_en-US.tar.xz

The OpenPGP output should show a "good signature", with the primary key fingerprint matching the one verified by the user earlier on. In this example.

    gpg: Signature made Tue 24 Jan 2015 09:29:09 AM CET using RSA key ID D40814E0
    gpg: Good signature from "Tor Browser Developers (signing key) "
    gpg: WARNING: This key is not certified with a trusted signature!
    gpg:          There is no indication that the signature belongs to the owner.
    Primary key fingerprint: EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290

The software can now be safely installed. If the output states "bad signature", then the files and digital signatures should be removed and downloaded again.

Virtualization Platform[edit]

Type 1 vs Type 2 Hypervisors[edit]

According to [54]

Not all virtual machine software is equal when it comes to security. You may have used or heard of VMs in relation to software like VirtualBox or VMware Workstation. These are known as “Type 2” or “hosted” hypervisors. (The hypervisor is the software, firmware, or hardware that creates and runs virtual machines.) These programs are popular because they’re designed primarily to be easy to use and run under popular OSes like Windows (which is called the host OS, since it “hosts” the VMs). However, the fact that Type 2 hypervisors run under the host OS means that they’re really only as secure as the host OS itself. If the host OS is ever compromised, then any VMs it hosts are also effectively compromised. By contrast, Qubes uses a “Type 1” or “bare metal” hypervisor called Xen. Instead of running inside an OS, Type 1 hypervisors run directly on the “bare metal” of the hardware. This means that an attacker must be capable of subverting the hypervisor itself in order to compromise the entire system, which is vastly more difficult.

The take-home message is that Qubes-Whonix is more secure than the default Whonix configuration using a Type 2 hypervisor like VirtualBox. Therefore, it is recommended to install Qubes-Whonix if users have suitably modern hardware.

Qubes-Whonix vs Physically-Isolated Non-Qubes-Whonix[edit]

In Non-Qubes-Whonix, using a separate computer for physical isolation is certainly more secure than using the same computer for everything in the standard host OS / Type 2 hypervisor configuration. However, it is not clear this is superior to Qubes' compartmentalized software approach.

Consider the pros and cons of physical isolation relative to Qubes: [56]


  • Physical separation doesn’t rely on a hypervisor. (It’s very unlikely that an attacker will break out of Qubes’ hypervisor, but if one were to manage to do so, one could potentially gain control over the entire system).
  • Physical separation can be a natural complement to physical security. (For example, you might find it natural to lock your secure laptop in a safe when you take your unsecure laptop out with you).


  • Physical separation can be cumbersome and expensive, since we may have to obtain and set up a separate physical machine for each security level we need.
  • There’s generally no secure way to transfer data between physically separate computers running conventional OSes. (Qubes has a secure inter-VM file transfer system to handle this).
  • Physically separate computers running conventional OSes are still independently vulnerable to most conventional attacks due to their monolithic nature.
  • Malware which can bridge air gaps has existed for several years now and is becoming increasingly common.

In summary, the relative merits of physical isolation do not necessarily provide any more protection than Qubes' approach. Physical isolation is relatively difficult, still experimental, inconvenient, and requires a significant time investment. On the other hand, Qubes is relatively easy to install, has fully integrated Whonix, and is convenient for most activities.

Qubes also supports a host of features unavailable in the physically-isolated model, such as: DisposableVMs, a USB VM, secure copy / paste operations between VMs, secure copying and transfers of files between VMs, and sanitization of PDFs and images.

For these reasons, Qubes-Whonix is recommended for the majority of users seeking a higher-security solution.

Qubes-Whonix Hardware Requirements[edit]

For Qubes-Whonix hardware requirements, see here.

VirtualBox Hardening[edit]

For an overview on VM security risks in general, see: How secure are Virtual Machines really?

The less features enabled, the smaller the attack surface. The following features can be removed or disabled without impacting core functionality:

  • Disable Audio.
  • Do not enable Shared Folders.
  • Do not enable video acceleration.
  • Do not enable 3D acceleration. [57] [58]
  • Do not enable the Serial Port.
  • Remove the Floppy drive.
  • Remove the CD/DVD drive.
  • Do not attach USB devices.
  • Disable the USB controller which is enabled by default. Set the Pointing Device to "PS/2 Mouse" or changes will revert.
  • Do disable Advanced Configuration and Power Interface (ACPI). ACPI information is passed to guest OS by default, which allow guest OS to obtain battery status and manufacturer information.
  • Do not enable the Remote Display server.
  • Enable PAE/NX (NX is a security feature).

Not enabling IO APIC, EFI may also provide some protection, but this requires further investigation.

Stay Tuned[edit]

It is important for users to read the latest Whonix news to stay in touch with ongoing developments, such as notifications about important security vulnerabilities and improved Whonix releases.


  4. Tor v3.2 or higher must be running in Whonix-Gateway (`sys-whonix`).
  5. The cat commands are optional and for confirmation only.
  7. Requires Tor v3.2 or above running in Whonix-Gateway (sys-whonix).
  9. Rollback or indefinite freeze attacks as defined by The Update Framework (TUF) - Threat Model - Attacks and Weaknesses - -
  18. Automatically configured in Qubes R4, but an optional configuration in R3.2.
  19. Proprietary binary blobs of other GPU manufacturers pose security risks, and available open source drivers are notoriously unstable in Qubes.
  20. Qubes R3.2 and earlier versions rely on para-virtualized (PV) VMs.
  21. For instance, this recent security bug allows an attacker to escape from a PV domain and exploit the dom0 hypervisor. It only affects Qubes R3.2, since Qubes R4 only runs untrusted code in PVH or HVM domains by default.
  22. A successful exploit of the untrusted qube provides an avenue for attacking the sensitive qube.
  23. The vm-boot-protect.service is suitable for standalone VMs, AppVMs, netVMs, Whonix AppVMs and others. Do not use the vm-boot-protect-root service for Whonix AppVMs.
  24. This service: starts before the private volume is mounted, protects /home desktop and shell startup executables, quarantines /rw configs and scripts (with whitelisting), re-deploys custom / default files to /rw on each boot, conducts SHA256 checking against unwanted changes, and more.
  25. Disabling of the Qubes' default passwordless-root is also required.
  30. At the time of writing, the Jessie proposed updates repository in Whonix supports this Tor version.
  34. Preliminary tests of other security features reveals they are not yet functional in Whonix, for instance --apparmor, --private, and --overlay-tmpfs. If the user does not specify a path to a specific profile when running Firejail, it will search for any relevant profile automatically. If a profile is not found, a default profile will be used.
  35. This must be removed in Whonix 14 and replaced with the method below.
  37. Firejail has been tested to work with both Tor Browser 7.0.6 and 7.5a5.
    • Create Qubes-Whonix-Workstation AppVM
      • Name and label: Name the AppVM. Don't include any personal information (if the AppVM is compromised, the attacker could run qubesdb-read /name to reveal the VM name). Name the AppVM something generic, for example: anon-whonix.
      • Color: Choose a color label for the Whonix-Workstation AppVM.
      • Use this template: Choose the Whonix-Workstation TemplateVM. For example: whonix-ws.
      • Standalone: Leave the Standalone field unchecked, unless a persistent root filesystem is desired.
      • Type: Choose the type AppVM.
      • Allow networking: Choose the desired Whonix-Gateway ProxyVM from the list. For example: sys-whonix.
      • Press: OK.
  39. This has happened in the past. For example, on one occasion Tor from came with AppArmor changes that were incompatible with anon-gw-anonymizer-config's /etc/apparmor.d/local/system_tor.anondist which resulted in Tor's systemd unit failing.
  40. Alternatively you can use The Tor Project's native instructions for Debian, but these manual steps are more difficult and involved. The verification of The Tor Project apt-get signing key is also harder. Since you already trust Whonix, the logical choice is to trust another Whonix package to install the right signing key.
  41. So the newly installed /etc/apt/sources.list.d/torproject.list takes effect.
  42. A later version of Tor will not always be installed. For example, at the time of writing the stretch repositories for both and have identical Tor versions. As the Debian stable release ages, the likelihood of receiving a newer Tor version from increases.
  45. Other VPN implementations may also be useful, but they have not been researched yet.
  47. Also read the Tor Project warnings here:
  48. IKE is being exploited by advanced agencies to decrypt IPSec traffic. IPsec configured with pre-shared keys is vulnerable to MITM attacks. PPTP is an obsolete method for VPN implementation with a host of security weaknesses. For further reading on adversary capabilities against VPN protocols see:
  49. Digital signatures are still useful in this case, because the user can choose to limit trust to a few select people/organizations such as Whonix developers.
  50. For example, anybody could generate an OpenPGP key pair and pretend to be the "Whonix Project", but only Patrick Schleizer's generated key pair is legitimate.
  51. Website checks are only as secure as the imperfect TLS system, which is itself based on certificate authorities that have been frequently compromised in recent years.
  56. Quote

    Untrusted guest systems should not be allowed to use VirtualBox's 3D acceleration features, just as untrusted host software should not be allowed to use 3D acceleration. Drivers for 3D hardware are generally too complex to be made properly secure and any software which is allowed to access them may be able to compromise the operating system running them. In addition, enabling 3D acceleration gives the guest direct access to a large body of additional program code in the VirtualBox host process which it might conceivably be able to use to crash the virtual machine.

  57. Quote

    If the "3D-Acceleration" feature of VirtualBox is activated, running the proof-of-concept code from inside the VM provides the ability to read framebuffers from the host system.

Random News:

Don't mind having your name connected to Whonix? Follow us on Twitter / Facebook / g+.

https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.

Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)