|About this Security Guide Page|
- 1 Basics
- 2 Motivation
- 3 Operating System
- 4 Whonix-Gateway Security
- 5 Host Security
- 5.1 Basics
- 5.2 Power Saving Considerations
- 5.3 Hardware Component Risks
- 5.4 Anonymous Mobile Modems
- 5.5 Anonymous WiFi Adapters
- 5.6 Hardening
- 5.7 Mandatory Access Control
- 6 Virtualization Platform
- 7 Whonix-Workstation Security
- 8 Installing Additional Software
- 9 Updating with Extra Care
- 10 Onionizing Repositories
- 11 Passwords
- 12 Transporting UDP Tunnels over Tor
- 13 Time Attacks
- 14 Tor Versioning
- 15 Verifying Software Signatures
- 16 System Hardening Checklist
- 17 Stay Tuned
- 18 Advanced Security Guide
- 19 Footnotes
- Do Not - Non technical steps staying anonymous
- Computer Security Education
- Post Install Advice
- Surfing Posting Blogging
- Read the Documentation in general
This Motivation chapter may be skipped.
If you need motivation to secure your computer, refer to these articles:
- The Scrap Value of a Hacked PC, Revisited (blog post).
- The Value of a Hacked Email Account (blog post).
If that is too much to read, then just take a glimpse at the graphics:
Important! All packages must stay up-to-date for security purposes.
- For Qubes Whonix update directions, go to the Qubes-Whonix Update Guide.
- For all other Whonix OS builds, follow the update directions below.
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 http://security.debian.org jessie/updates Release.gpg Hit http://security.debian.org jessie/updates Release Hit http://deb.torproject.org jessie Release.gpg Hit http://ftp.us.debian.org jessie Release.gpg Hit http://security.debian.org jessie/updates/main i386 Packages Hit http://deb.torproject.org jessie Release Hit http://security.debian.org jessie/updates/contrib i386 Packages Hit http://ftp.us.debian.org jessie Release Hit http://security.debian.org jessie/updates/non-free i386 Packages Hit http://deb.torproject.org jessie/main i386 Packages Hit http://security.debian.org jessie/updates/contrib Translation-en Hit http://ftp.us.debian.org jessie/main i386 Packages Hit http://security.debian.org jessie/updates/main Translation-en Hit http://ftp.us.debian.org jessie/contrib i386 Packages Hit http://security.debian.org jessie/updates/non-free Translation-en Hit http://ftp.us.debian.org jessie/non-free i386 Packages Ign http://ftp.us.debian.org jessie/contrib Translation-en Ign http://ftp.us.debian.org jessie/main Translation-en Ign http://ftp.us.debian.org jessie/non-free Translation-en Ign http://deb.torproject.org jessie/main Translation-en_US Ign http://deb.torproject.org jessie/main Translation-en Reading package lists... Done
If you see something like this.
W: Failed to fetch http://ftp.us.debian.org/debian/dist/jessie/contrib/binary-i386/Packages 404 Not Found W: Failed to fetch http://ftp.us.debian.org/debian/dist/jessie/non-free/binary-i386/Packages 404 Not Found E: Some index files failed to download. They have been ignored, or old ones used instead. Err http://ftp.us.debian.org jessie Release.gpg Could not resolve 'ftp.us.debian.org' Err http://deb.torproject.org jessie Release.gpg Could not resolve 'deb.torproject.org' Err http://security.debian.org jessie/updates Release.gpg Could not resolve 'security.debian.org' Reading package lists... Done W: Failed to fetch http://security.debian.org/dists/jessie/updates/Release.gpg Could not resolve 'security.debian.org' W: Failed to fetch http://ftp.us.debian.org/debian/dists/jessie/Release.gpg Could not resolve 'ftp.us.debian.org' W: Failed to fetch http://deb.torproject.org/torproject.org/dists/jessie/Release.gpg Could not resolve 'deb.torproject.org' W: Some index files failed to download. They have been ignored, or old ones used instead.
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 'security.debian.org'
It that case, it helps to run.
And then try again.
sudo apt-get dist-upgrade
3. Never Install Unsigned Packages!
If a message like this appears.
WARNING: The following packages cannot be authenticated! icedove Install these packages without verification [y/N]?
Then don't proceed! Press 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.and . Running again should fix it. If not, something is broken or it is a
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: http://deb.torproject.org 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.  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: http://deb.torproject.org stable Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 W: Failed to fetch http://deb.torproject.org/torproject.org/dists/stable/Release 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), then press . 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 Setting up ifupdown ...", so the file isn't coming from a Whonix-specific package. In this case, the user should press as previously advised. . In the example above it is saying "
- If the package name does include Whonix's modular flexible .d style configuration folders. , it is a Whonix-specific package. In that case, the safest bet is pressing , but then any customized settings will be lost (these can be re-added afterwards). Such conflicts will hopefully rarely happen if using
6. Restart Services After Upgrading
To restart services after upgrading, either simply 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
The program will provide some advice. Run it again after applying the advice.
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.
Never use Whonix-Gateway for anything other than running Tor on it!
If the Whonix-Gateway VM is ever compromised, the identity (public IP address), all destinations visited, and the entirety of clear-text (and hidden service) communication over Tor becomes available to the attacker.
Before installing any extra packages on the Whonix-Gateway, please first consult the developers to ask whether that is really necessary and wise.
Warning: Bridged Networking
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.
Please read the Computer Security Education section about Host Security.
Power Saving Considerations
Upon system suspend / standby, Full Disk Encryption keys are still kept in RAM. Users at high risk or traveling should avoid leaving a system in this 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  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.
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.
Hardware Component Risks
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.
Anonymous Mobile Modems
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.
Warning: The technique outlined below may be ineffective against advanced adversaries who can:
- Subvert cellular networks.
- Conduct downgrade attacks on network functioning from 4G to 3G, from 3G to 2G and so on.
- Attack all ciphers used in cellular networks, including A5/1, A5/2 and A5/3.
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.  For greater security, prefer using a new, distant, random, non-circular location when conducting on-line activities.
Anonymous WiFi Adapters
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.
Mandatory Access Control
According to debian.org: 
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: 
- 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 Tor Browser, Icedove and various other programs. The profiles are easily applied and provide a considerable security benefit.
According to Mozilla: 
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, since it is easily applied and provides additional sandboxing protection for the Tor process.
Save and exit.
According to the Firejail project page: 
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, Icedove, LibreOffice, Okular, Thunderbird, Transmission, VirtualBox, VLC and wget. 
1. Boot the Whonix-Workstation (whonix-ws) TemplateVM
2. Add jessie-backports to sources.list
sudo su -c "echo -e 'deb http://http.debian.net/debian 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. Use Apt-pinning Before Installing Dependencies
Apt-pinning provides a safe mechanism to mix and match packages from different Debian repository branches without breaking your base distribution.
A higher pin priority ensures that apt will prefer the stable package version over any other when installing. Note that these files have a .pref extension or none at all.
Open /etc/apt/preferences.d/debian-pinning.pref in an editor with root rights.
Package: * Pin: release a=stable Pin-Priority: 700 Package: * Pin: release a=jessie-backports Pin-Priority: 650 Package: * Pin: release a=testing Pin-Priority: 600 Package: * Pin: release a=unstable Pin-Priority: 550 Package: * Pin: release a=experimental Pin-Priority: 500
Save and exit.
4. Update the Package Lists
sudo apt-get update
5. Install Firejail
sudo apt-get -t jessie-backports install firejail
6. Launch Firejail
To run sandboxed applications, simply prefix your program command with "firejail" in a terminal. For example:
firejail evince firejail vlc
There is no secure and reliable way to create start menu entries / desktop shortcuts using Firejail. In the meantime, start firejailed applications from the command line.
For a further technical discussion of Firejail, see: https://forums.whonix.org/t/firejail-seccomp-more-options-for-program-containment
Sandboxing Tor Browser
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.
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. Optional Step (Untested): Create a Customized Firejail Profile for Tor Browser
Follow these steps to build a custom profile.
4. Create a New Whonix-Workstation-AppVM Based on the Modified Template
Qubes VM Manager ->
5. Launch the Sandboxed Tor Browser
Open a terminal and run.
6. Confirm Tor Browser is Sandboxed
Launch Tor Browser in the anon-whonix AppVM. Then open a terminal and run.
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
Running Firefox-ESR in a Firejail Sandbox (Qubes Debian-8 Template Only)
Note: Preferably clone the Debian-8 TemplateVM prior to taking these steps, as some dependencies are required.
Warning: Do not use Firefox-ESR in a Whonix template! It is easily fingerprinted and less secure than the Tor Browser.
1. Boot the Debian-8 TemplateVM
2. Follow the Steps to Install Firejail from jessie-backports
3. Create a New Debian-8 AppVM Based on the Modified Template
4. Launch the Sandboxed Firefox-ESR
In a terminal, run.
5. Confirm Firefox-ESR is Sandboxed
Open another terminal and run.
The output should confirm Firefox-ESR is now running in a firejail container.
Type 1 vs Type 2 Hypervisors
According to qubes-os.org: 
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
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: 
- 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
For Qubes-Whonix hardware requirements, see here.
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.  
- 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 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.
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.
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.
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.
Note: the following advice refers to Non-Qubes-Whonix users.
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.  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:
- Import both VMs into the virtualizer.
- Start both the Whonix-Gateway and Whonix-Workstation VMs.
- Securely update both VMs.
- After the updates have finished, shut down both VMs. Do not browse anywhere or open any unauthenticated communication channels to the internet.
- Create snapshots of both VMs in their clean state.
- 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.
Warning to VirtualBox Users: VirtualBox's VM Snapshot feature is recommended against because data loss has been experienced using it. Instead, use clones or other methods outlined in the "Reliable Alternative To VirtualBox VM Snapshots" section below.
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 Virtualbox.org. However, a portable application version of VirtualBox is available via a tool provided by VBox.me. 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:
Adding a NAT Adapter to Whonix-Workstation / Updates without Tor
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.
Adding a Host-Only Networking Adapter to Whonix-Workstation / SSH into Whonix-Workstation
If accessing the Whonix-Workstation via SSH, some users may consider something dangerous - adding a second network adapter with host-only networking.
Warning: Never add another network adapter in this manner! It is also potentially dangerous if any other VMs are running except the Whonix-Workstation! The reason is that it will expose the MAC address of the host to the Whonix-Workstation.
The VMware host-only warning regarding routing and connection sharing may equally apply to Whonix: 
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 Hidden Services and access them through another Whonix-Workstation.
- Another alternative is to run the services using Hidden 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.
Installing Additional Software
See Install Software.
Updating with Extra Care
When Whonix, Debian and Qubes packages are installed or updated, default settings point to repositories with a http:// URI.  However, experimental Tor hidden services are already available for the Whonix, Debian and Qubes packages.
There are several security and privacy benefits of using Tor hidden services: 
- 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.
Whonix and Debian Packages
Whonix 14 will prefer Tor hidden services (.onion repositories) by default, even when adding third-party resources. Until then, in order to install or update with the utmost caution, users may consider manually editing their sources.list to point to the Whonix and Debian .onion mirrors.
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 http://ftp.debian.org/debian jessie main contrib non-free deb http://vwakviie2ienjx6t.onion/debian jessie main contrib non-free #deb http://security.debian.org jessie/updates main contrib non-free deb http://sgvtcaew4bxjd7ln.onion jessie/updates main contrib non-free #Optional Backports #deb http://ftp.debian.org/debian 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
sudo whonix_repository --baseuri http://deb.kkkkkkkkkk63ava6.onion --enable --repository stable
Note: Whonix users have four package preferences available: stable, stable-proposed-updates, testers and developers. Change the entry above to reflect this preference. 
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
Note: Qubes users can repeat these steps in the Debian TemplateVM to onionize future installations and updates.
6. Optional: Onionize Tor Project Updates
Note: Only do this if you are using Tor versions from The Tor Project repository. The Tor Project deb apt signing key must be added first (at 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-Whonix users).
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 http://deb.torproject.org/torproject.org jessie main deb http://sdscoq7snqtznauu.onion/torproject.org jessie main
Save and exit.
The following commands must be run in dom0 in order to use Qubes’ Tor hidden service repositories for each type of VM. 
Note: The cat commands are optional and for confirmation only. The downside of this approach is that repository definitions are managed by a Qubes package, meaning further manual updates need to be applied in the future when they change.
In dom0, run.
sudo sed -i 's/yum.qubes-os.org/yum.qubesos4rrrrz6n4.onion/' /etc/yum.repos.d/qubes-dom0.repo && cat /etc/yum.repos.d/qubes-dom0.repo
sudo sed -i 's/yum.qubes-os.org/yum.qubesos4rrrrz6n4.onion/' /etc/yum.repos.d/qubes-templates.repo && cat /etc/yum.repos.d/qubes-templates.repo
In dom0, run.
qvm-run -a --nogui -p -u root $FedoraTemplateVM 'sed -i "s/yum.qubes-os.org/yum.qubesos4rrrrz6n4.onion/" /etc/yum.repos.d/qubes-r3.repo && cat /etc/yum.repos.d/qubes-r3.repo'
Debian and Whonix Templates
In dom0, run.
qvm-run -a --nogui -p -u root $DebianTemplateVM 'sed -i "s/deb.qubes-os.org/deb.qubesos4rrrrz6n4.onion/" /etc/apt/sources.list.d/qubes-r3.list && cat /etc/apt/sources.list.d/qubes-r3.list'
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.
Principles for Stronger Passwords
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: 
- Avoid short passwords of less than 12-14 characters in length - longer passwords are exponentially more difficult to crack than shorter ones. 
- Include: Upper and lower case characters, special characters, digits, spaces, underscores and brackets (unless using Diceware passphrases - see below).
- 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).
Generating Unbreakable Passwords
Warning: It is safe to assume that advanced adversaries with modern technology can conduct bruteforce attacks at a rate of 10s or even 100s of billions of attempts per second. 
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.  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. 
Transporting UDP Tunnels over Tor
According to the Tor Project: 
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. 
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. 
Please first read the related VPN documentation and warnings:
- Tor Plus VPN or Proxy.
- Whonix VPN disclaimer.
- How to connect to Tor before a VPN (
- Tunneling comparison table.
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. 
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. .
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. 
A dedicated virtual machine is recommended for this activity, see: Multiple Whonix-Workstations.
See Time Attacks.
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 and then upgrade the system as usual. This is only recommended for testers.
Even Newer Tor Versions from The Tor Project Repository
Untested and not fully documented. Testers only.
Note: This risks breaking connectivity, for instance if the latest Tor version from deb.torproject.org has not been fully tested by Whonix developers at a specific point in time. 
To proceed despite the risk, install the even newer Tor version by enabling the deb.torproject.org 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. 
Update the package lists.
sudo apt-get update
sudo apt-get install anon-shared-build-apt-sources-tpo
Refresh the package lists. 
sudo apt-get update
Install the (potentially) newer version of Tor. 
sudo apt-get install tor
Verifying Software Signatures
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
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). 
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
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.  This is a necessary step before keys are imported, or trust is placed in OpenPGP output when verifying files or repositories. Software should only be installed after a key's fingerprint has been verified and good signatures are produced for files/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.  In this instance, other "authentication systems" refers to: 
- 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
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.
System Hardening Checklist
It is possible for users to significantly harden their platform and improve the chances of successful, anonymous activity. See: System Hardening Checklist.
Advanced Security Guide
For even more security advice, see the Advanced Security Guide.
- Rollback or indefinite freeze attacks as defined by The Update Framework (TUF) - Threat Model - Attacks and Weaknesses - https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md - http://www.webcitation.org/6F7Io2ncN.
- https://github.com/Whonix/sdwdate/blob/master/etc/qubes/suspend-pre.d/30_sdwdate.sh https://github.com/Whonix/sdwdate/blob/master/etc/qubes/suspend-post.d/30_sdwdate.sh
- 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 /nameto reveal the VM name). Name the AppVM something generic, for example:
- Color: Choose a color label for the Whonix-Workstation AppVM.
- Use this template: Choose the Whonix-Workstation TemplateVM. For example:
- Standalone: Leave the Standalone field unchecked, unless a persistent root filesystem is desired.
- Type: Choose the type
- Allow networking: Choose the desired Whonix-Gateway ProxyVM from the list. For example:
- Name and label: Name the AppVM. Don't include any personal information (if the AppVM is compromised, the attacker could run
- Create Qubes-Whonix-Workstation AppVM
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.
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.
- Other VPN implementations may also be useful, but they have not been researched yet.
- Also read the Tor Project warnings here: https://trac.torproject.org/projects/tor/wiki/doc/TorPlusVPN
- 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: http://www.spiegel.de/media/media-35515.pdf
- This has happened in the past. For example, on one occasion Tor from deb.torproject.org 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.
- 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.
- So the newly installed /etc/apt/sources.list.d/torproject.list takes effect.
- A later version of Tor will not always be installed. For example, at the time of writing the stretch repositories for both packages.debian.org and deb.torproject.org have identical Tor versions. As the Debian stable release ages, the likelihood of receiving a newer Tor version from deb.torproject.org increases.
- 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.
- 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.
- 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.
Impressum | Datenschutz | Haftungsausschluss
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.