|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 Transporting UDP Tunnels over Tor
- 12 Time Attacks
- 13 Tor Versioning
- 14 System Hardening Checklist
- 14.1 Easy
- 14.1.1 Anonymous Blogging, Posting, Chat, Email and File Sending
- 14.1.2 Disabling and Minimizing Hardware Risks
- 14.1.3 File Handling
- 14.1.4 Mandatory Access Control
- 14.1.5 Passwords and Logins
- 14.1.6 Secure Qubes Operation
- 14.1.7 Tor Browser Series and Settings
- 14.1.8 VirtualBox
- 14.1.9 Whonix Updates
- 14.2 Moderate
- 14.3 Difficult
- 14.4 Expert
- 14.1 Easy
- 15 Stay Tuned
- 16 Advanced Security Guide
- 17 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 intelligence agencies 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
The sandboxed Tor Browser cannot be used until Whonix 14 is released. In the meantime, consider using Firejail as an interim sandboxing measure to restrict the Tor Browser process.
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-8 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'
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 (User -> Tor -> VPN -> Internet).
- 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
System Hardening Checklist
It is possible for users to significantly harden their platform and improve the chances of successful, anonymous activity. This depends upon a user's skill level, motivation and available hardware. The checklist below is intended to provide a quick overview of important issues, categorized by difficulty level (easy, moderate, difficult and expert).
Anonymous Blogging, Posting, Chat, Email and File Sending
- To remain anonymous, follow all the Whonix recommendations to minimize threats of keyboard/mouse biometrics, stylometry analysis and other covert channels.
Disabling and Minimizing Hardware Risks
- In Qubes-Whonix, only use a mouse and keyboard utilizing PS/2 ports (not USB ports) to prevent malicious compromise of dom0 (PS/2 adapters and available controllers are required).
- Do not enable audio input to any VM unless strictly required and consider disabling microphones where possible (muting on the host) or unplugging external devices.
- Preferably detach or cover webcams unless they are in use. In Qubes-Whonix, assign it to an untrusted VM (if needed).
- Avoid using wireless devices, since they are insecure.
- Preferably disable or remove Bluetooth hardware modules.
- Disable or remove problematic devices like ExpressCard, PMCIA, FireWire or Thunderbolt which may allow attackers with physical access to read RAM.
- In File Manager, disable previews of files from untrusted sources. Change file preferences in the TemplateVM's File Manager so future AppVMs inherit this feature.
- Files received or downloaded from untrusted sources (the internet, via email etc.) should not be opened in a trusted VM. Instead, open them in a DisposableVM (right click).
- Untrusted PDFs should be opened in a DisposableVM or converted into a trusted (sanitized) PDF to prevent exploitation of the PDF reader and potential infection of the VM.
Mandatory Access Control
- Enable all available apparmor profiles in the Whonix-Workstation and Whonix-Gateway TemplateVMs.
- Enable seccomp on the Whonix-Gateway AppVM.
Passwords and Logins
- In Qubes-Whonix, store all login credentials and passwords in an offline vault VM (preferably with KeypassX) and securely cut and paste them into the Tor Browser. Copy something else into the clipboard after pasting so the password is purged and cannot be accidentally pasted elsewhere.
- Use unique and random Diceware passphrases of 6-7 words in length for all on-line accounts, system logins and encryption / decryption purposes to prevent the feasibility of brute-forcing attacks.
Secure Qubes Operation
- Verify the authenticity and integrity of the Qubes iso download.
- 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 e.g. pre-configured Fedora, Debian, Whonix and Qubes sources. Untrusted or unverifiable programs should be installed in standaloneVMs or less trusted, cloned templates.
- For critical user data, protect against unintentional leaks by setting an empty NetVM field (set to "none") for the corresponding AppVM.
- Observe the security context of colored windows borders in Qubes before running applications or manipulating data.
- 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 computer hardware meets all other Qubes-Whonix requirements for the best security, functionality and future compatibility with Qubes 4.X releases.
- Always keep the system up to date in dom0, template VMs and standalone VMs.
- Never run applications in TemplateVMs or dom0, except updating tools or editors for configuration purposes (running applications poses security risks).
- 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.
- Follow all other security advice from the Qubes team.
Tor Browser Series and Settings
- Consider using the Alpha series of the Tor Browser. It provides additional ASan (memory corruption) and Selfrando (load-time memory randomization) protection.  
- Default search settings to the DuckDuckGo .onion hidden service.
- Select ClearClick protections in NoScript.
- Run the Tor Browser Security Slider in the highest position.
- Use .onion hidden services where possible to stay within the Tor network.
- Follow all other Whonix recommendations for safe use of the Tor Browser.
- Remove a host of VirtualBox features to reduce the attack surface.
- Take regular, clean VM snapshots that are not used for any activities.
- Spoof the initial virtual hardware clock offset.
- Consider installing newer Tor versions via the Whonix stable-proposed-updates repository or directly from The Tor Project repository.
Create a USB Qube
- Prepare and utilize a USB qube. USB keyboards and mice expose dom0 to attacks, and all USB devices are potential side channel attack vectors.
Host Operating System Distribution
- Install GNU/Linux as the only serious option for a private host operating system. Windows and MacOS are surveillance platforms that do not respect user freedom or privacy.
- The Debian distribution is recommended by Whonix as providing a reasonable balance of security and usability.
Host Operating System Hardening
- Harden the host Debian Linux OS.
- Use Full Disk Encryption (FDE) on the host.
- Apply a BIOS password for BIOS setup and boot.
- Torrify apt-get traffic on the host to prevent fingerprinting and leakage of sensitive security information.
- Follow all other Whonix recommendations to further harden the host OS against physical attacks.
On both platforms:
- If possible, use a dedicated network connection (LAN, WiFi etc.) that is not shared with other potentially compromised computers.
- If using a shared network via a common cable modem/router or ADSL router, configure a de-militarized zone (perimeter network) to restrict Whonix-Gateway accessibility to/from other nodes on the network e.g. printers, phones and laptops.
- Test the LAN's router/firewall with either an internet port scanning service or preferably a port scanning application from an external IP address.
- Change the default administration password on the router to a unique, random, and suitably long Diceware passphrase to prevent bruteforcing attacks.
- WiFi users should default to the WPA2-AES standard which provides the safest protocol and strongest encryption. Do not rely on WiFi Protected Set-up (WPS), which has major security flaws.
- Use the Debian-8 Template for networking (sys-net and sys-firewall) since it is minimal in nature and does not 'ping home', unlike the Fedora Template. 
- For greater security, higher performance and a lower resource footprint, consider using an experimental MirageOS-based unikernel firewall that can run as a QubesOS ProxyVM.
- Install newer kernels to benefit from additional protections (including grsecurity elements) being mainlined by the kernel hardening project.
- Default the Debian, Whonix and Qubes package updates to Tor hidden service repositories.
- Use the alpha sandbox to restrict the Tor Browser. 
- Use Firejail to restrict Firefox-ESR, VLC and other regularly used applications.
- Store encrypted back-ups on a separate back-up disk that is already encrypted with LUKS.
Spoof MAC Addresses
Note: This is only necessary if you expect to travel with your laptop or PC. It is not required for home PCs that do not change locations.
- In Qubes-Whonix, follow these steps to spoof the MAC address on the Debian or Fedora TemplateVM used for network connections.
- In Non-Qubes-Whonix, follow these steps to spoof the MAC address of the network card on a Linux host.
Time Stamps and NTP Clients
- Disable ICMP timestamps and TCP timestamps on the host operating system to prevent leakage of: system information, host time, system uptime, and fingerprinting of devices behind a router.
- Uninstall the NTP client on the host operating system and disable systemd's timdatectl NTP synchronization feature. This prevents time-related attack vectors which rely on leakage of the host time.
- If a Trusted Platform Module is available, use AEM protection to attest that only desired (trusted) components are loaded and executed during the system boot. Unauthorized modifications to BIOS or the boot partition will be notified.
Chaining Anonymizing Tunnels
- Avoid this course of action. The anonymity benefits are unproven and it may actually hurt a user's anonymity and security goals.
- Run all instances of the Tor Browser in a DisposableVM which is preferably uncustomized to resist fingerprinting.
- Use split-GPG for email to reduce the risk of key theft used for encryption / decryption and signing.
- Create an AppVM that is exclusively used for email and change the VM's firewall settings to only allow network connections to the email server and nothing else ('Deny network access except...').
- Only open untrusted email attachments in a DisposableVM to prevent possible infection.
On both platforms:
- Follow the Whonix recommendations to select an email provider compatible with privacy and anonymity:
- Prefer email providers that are: free, support GPG encryption and key management, have encrypted inboxes by default, are outside Five Eyes jurisdictions, and have desktop email compatibility with Icedove (Mozilla Thunderbird).
- In Qubes-Whonix, use dom0, Debian, Fedora and Whonix grsecurity templates to provide significant kernel exploit protections.
- In Non-Qubes-Whonix, install the latest grsecurity kernel on your host or KVM Whonix guest.
Multi-Factor User Authentication
- Use a Yubikey to enhance the security of Qubes user authentication, mitigate the risk of password snooping, and to improve USB keyboard security.
Whitelisting Tor Traffic
- Qubes-Whonix: Configure sys-whonix to use corridor as a filtering gateway to ensure only connections to Tor relays pass through. This provides an additional fail-safe to protect from accidental clearnet leaks that might arise from hypothetical Whonix bugs, but does not address potential Qubes ProxyVM leaks. 
- Non-Qubes-Whonix or Qubes-Whonix: use a standalone corridor as a filtering gateway.
Disable Intel ME Blobs
- It is possible to partially deblob Intel's despicable ME firmware image by removing unnecessary partitions from it. Warning: high risk of bricking your computer!
Flash the Router with Opensource Firmware
- Flash the insecure, limited-utility, proprietary firmware on the router with a powerful open-source Linux alternative. Warning: risk of bricking your router!
- Libreboot is a free, opensource BIOS or UEFI replacement (firmware) that initializes the hardware and starts the bootloader for your OS. Warning: incompatible with newer architectures - risk of bricking your computer!
- If additional hardware is available, consider physical isolation in Non-Qubes-Whonix. Using two different computers and virtualization is one of the most secure configurations available, but may be less secure than Qubes' approach (software compartmentalization).
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 the NSA 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 intelligence agency 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.
- Selfrando provides a significant security improvement over standard address space layout randomization (ASLR) present in Tor Browser and other browsers. Selfrando is incompatible with grsecurity kernels. Due to a bug, Selfrando has not yet been integrated into the alpha series.
- The "hardened" Tor Browser series has been deprecated, see: https://trac.torproject.org/projects/tor/ticket/21912
- This is not possible until Whonix 14 is released.
Impressum | Datenschutz | Haftungsausschluss
Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation. Whonix (g+) 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.