Advanced Security Guide



Before reading or applying instructions in this section, users should first review the information outlined in the Computer Security Education and Security Guide chapters.

Network Time Synchronization[edit]


Saving or Suspending the VM State

When a user suspends or saves the VM state, the clock will stop and continue after resuming, leading to a time that lags behind the correct value. The Whonix-Gateway state should not be suspended or saved. It is far better to power off the Whonix-Gateway if it is no longer needed. [1] Similarly, if users suspend or save the Whonix-Workstation state, the clock will again lag behind the correct value. This can be manually fixed inside Whonix-Workstation by running: Start Menu -> Applications -> System -> Whonix Timesync.

NTP Issues

The host system clock synchronization mechanism still uses unauthenticated NTP from a single source. This is not optimal, but there is no real solution to this problem. [2] A potential attack vector is created by this NTP behavior; the ISP and/or time server could either inadvertently or maliciously introduce a significant clock skew, or the host clock could simply malfunction.

If the host clock value is grossly inaccurate - more than one hour in the past or more than 3 hours in future - Tor cannot connect to the Tor network. [3] This is easily solved by manually fixing the clock on the host, then powering the Whonix-Gateway off and on again.

Another side effect of a significantly inaccurate host clock concerns operating system (OS) updates and cryptographic verification on the host. Until the host clock is manually fixed, it may no longer be possible to download updates or verify SSL certificates with the host browser.

Users should always check whether a host clock defect relates to an empty battery before assuming the ISP is tampering with NTP.

Disabling NTP

If ISP tampering with NTP is ever confirmed, users are advised to disable NTP and manually update the host clock out of band, for example, using a watch or atomic clock. If the tampering is targeted and not just a widescale attack, then the user already has much bigger problems to worry about than NTP (see Confirmation attacks).

If users follow the advice above to disable NTP on the host and manually adjust the clock out of band, this might make clearnet traffic more fingerprintable. [4] The reason is that it introduces a device issuing clearnet traffic (such as OS updates), but without the use of NTP. It is unknown how many people have NTP which is deactivated, broken, uninstalled, or never in fact installed in the first place. Also unknown is whether many people are using alternative time synchronization methods such as authenticated NTP, tails_htp, tlsdate or similar. However, search engine research suggests that very few people fall into both these categories.

Spoof the Initial Virtual Hardware Clock Offset[edit]



For KVM, click on Expand on the right.

Edit the VM xml before import or edit the VM xml after import and change the following setting.

<clock offset='utc'>

<clock offset='variable' adjustment='123456' basis='utc'>

The adjustment attribute takes any arbitrary value for seconds. The user must pick a random value that is unknown to others, ranging between 0 and 900 (a 15 minute range).


For VirtualBox, click on Expand on the right.

VirtualBox has a feature to spoof the initial virtual hardware clock offset by setting the clock X milliseconds in the future or past. The syntax is outlined below.

VBoxManage modifyvm <name> --biossystemtimeoffset -<milliseconds>
VBoxManage modifyvm <name> --biossystemtimeoffset +<milliseconds>

It is prudent to add a random delay within the following range.

VBoxManage modifyvm <name> --biossystemtimeoffset -60000
VBoxManage modifyvm <name> --biossystemtimeoffset +60000

A spoofing example is below. Users should select their own unique and random values for both the past (-) and future (+) within the specified range. Different values should be used for each distinct VM (on the host).

VBoxManage modifyvm "Whonix-Gateway" --biossystemtimeoffset -35017
VBoxManage modifyvm "Whonix-Gateway" --biossystemtimeoffset +27931

VBoxManage modifyvm "Whonix-Workstation" --biossystemtimeoffset -35017
VBoxManage modifyvm "Whonix-Workstation" --biossystemtimeoffset +27931

Apart from this small biossystemtimeoffset, a clock skew always degrades privacy. [5] [6] [7]



Unfortunately, it is not yet possible to set a random clock offset for Qubes-Whonix VMs to prevent clock correlation attacks since it is unsupported by Xen. A related issue is denying Qubes-Whonix access to "clocksource=xen", which may not be possible without Linux kernel and/or Xen patches. For a detailed discussion of these issues, see here.


In summary:

  • Only spoof the initial virtual hardware clock offset after importing the VM.
  • Always run secure network time synchronization after suspending or saving the VM state and resuming it. Preferably do not use the suspend, save and resume functions at all.
  • Tor cannot connect if the host clock is grossly inaccurate. In this case, users should manually fix the host clock, before powering the Whonix-Gateway off and on again.
  • Users should periodically check the host clock to ensure that it is accurate, or approximately so.

Users are suggested to read the Technical Design chapter, even though it is a difficult topic.

Interested users, developers and auditors should review the footnotes immediately below for additional information, or to explore design elements and the reasoning for this section.

  1. If this advice is ignored, Tor can become confused if the time is more than 1 hour in the past or more than 3 hours in the future. When this happens, Tor will only reconnect to the Tor network if the clock is manually fixed, or powered off and on again.
  2. See Design: Dev/TimeSync.
  3. In this case, Tor cannot verify the Tor consensus.
  4. See the Fingerprint page to discover what fingerprinting means in this case.
  5. biossystemtimeoffset is used to unlink the virtualizer's initial clock synchronization of the VM from the host clock.
  6. After powering on a VM, it initially synchronizes the VM clock with the host clock until Whonix Timesync adjusts it.
  7. Clock skews can lead to linkability, meaning the user would be pseudonymous rather than anonymous.

Deactivate Automatic TimeSync[edit]

To deactivate sdwdate, run.

sudo service sdwdate stop

sudo systemctl mask sdwdate

Host Security[edit]

Whonix Platform[edit]

As noted in the Security Guide, there are two platforms providing greater security than the standard host OS / Type 2 hypervisor Whonix configuration:

In contrast to Qubes-Whonix, physical isolation is:

  • Difficult to set up.
  • Inconvenient and still experimental.
  • Requires a significant time investment.
  • Not clearly superior to Qubes' compartmentalized software approach.
  • Does not support Qubes features like:
    • DisposableVMs.
    • A USB VM.
    • Secure copy and paste operations.
    • Secure copying and transfer of files.
    • PDF/image sanitization.
    • An ephemeral Whonix-Gateway ProxyVM and/or Whonix-Workstation AppVM. [1]


Key Hardening Steps[edit]

For greater security, advanced users should harden the host OS as much as is practicably possible. This includes, but is not limited to applying relevant steps from the system hardening checklist and instructions found later in this chapter:

Additional Defenses[edit]

Attack Surface Reduction

In addition to the checklist above, users should also follow the principles of minimizing the attack surface of the OS, and securely configuring services - for example when using SSH, implementing Fail2ban so only key authentication is allowed.

The attack surface concept deserves more consideration. Simply put, it is the sum of different attack vectors (aggregate of vulnerabilities) where an unauthorized user can try to enter or extract data from an environment. [2] To reduce the attack surface and mitigate risks, it is necessary to: [3]

  • Enforce least privilege for all executed processes and reduce entry points for untrusted users.
  • Control system and network segment access across the network, for example, reduce (unauthenticated) access to network endpoints.
  • Minimize exposed system targets by reducing the amount of code running and removing unnecessary functionality.
  • Remove or shutdown software and services (channels, protocols) that are infrequently or rarely used.
  • Frequently patch security vulnerabilities.

Proactive Defenses

This includes, but is not limited to:

Retroactive Defenses

The usefulness of this approach is limited because it does not prevent security breaches; it can only help in making future breaches less probable:

The programs listed in this section are only a very brief introduction to this topic. If interested, users should research these topics in depth on the Internet, as they are beyond the scope of this guide.


apt-transport-tor is a package that allows host operating systems or non-Whonix-Workstation VMs that are not behind a torifying gateway (like Whonix-Gateway) to torify their apt-get traffic for individual repositories.

With non-Whonix systems in mind, for security reasons apt-get blocks clearnet connections to .onion domains by default. apt-get developers want to protect users from accidentally trying to use .onion repositories without using Tor. Otherwise, a rouge DNS server could redirect users to a false domain and trick them into thinking they are using Tor when they are not.

Strictly speaking, there is no need to use apt-transport-tor inside Whonix VMs since all traffic is already routed over Tor. apt-get is stream isolated using a preconfigured uwt wrapper. In other words, apt-get in Whonix is already talking to a Tor SocksPort. Nevertheless, apt-transport-tor will be the default in Whonix 14 because it provides better error handling and stream isolation. [4] [5]

Torify apt-get Traffic[edit]

It is recommended to torrify APT's traffic on the host for several reasons:

  • Each machine has its own unique package selection. This allows location tracking, because systems can be fingerprinted across physical networks as system updates are performed.
  • System updates leak sensitive security information like package versions and the varying patch levels. This information aids targeted attacks.

Follow the instructions below to torify APT traffic in Debian. [6]

Install apt-transport-tor from the Debian repository.

sudo apt-get install apt-transport-tor

Edit the sources.list to include only tor:// URLs for every entry.

Open /etc/apt/sources.list in an editor with root rights.

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

kdesudo kwrite /etc/apt/sources.list

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

sudo nano /etc/apt/sources.list

Save and exit.

Other URL Configurations

Alternatively, the tor+http:// URL scheme is possible. apt-transport-tor can also be combined with apt-transport-https, leading to the tor+https:// URL scheme. [7]

Note that changing to picks a mirror near to whichever Tor exit node is being used. Throughput is surprisingly fast. [8] Users should also be aware that all public-facing FTP services will be shut down on November 1, 2017. [9]

Debian URLs can also be pointed to the available onion services http://vwakviie2ienjx6t.onion or http://earthqfvaeuv5bla.onion. This is the most secure option, as no package metadata ever leaves Tor. [10] [11] [12] This URL scheme also protects from system compromise in the event APT has a critical security bug.

One VM Whonix Configuration[edit]

This platform was developed and tested successfully for Whonix v0.1.3.

Basically, a user can use one VM instead of two, with Tor running on the host OS and a single client VM routing activities via Tor. This configuration has several advantages and disadvantages relating to security and other matters. For further information, see OneVM.

Separate VirtualBox User Account[edit]

Security-wise, it makes sense to create a separate user account solely for using VirtualBox, which is not in the admin/sudo group.


If users have a shared network - such as a cable modem/router or ADSL/router setup that is used by others - then configuration of a DMZ for the Whonix-Gateway should be considered.

A properly configured DMZ restricts the Whonix-Gateway from accessing, and being accessible to, other nodes on the network like printers, phones, computers and laptops. This is true even if root access is somehow achieved on the Whonix-Gateway.

Should an incursion take place, a DMZ prevents an adversary from exploring other systems and possibly compromising them. However, in this case a DMZ does not protect the user's anonymity, since the adversary could just ping a remote server and discover the real IP address. Another benefit of a DMZ is that should other systems be compromised, it is more difficult to compromise Whonix-Gateway.

Host Firewall[edit]


Port Scan[edit]

Using an Internet-based port scanner service to test the local LAN's router/firewall is a sensible idea. Users must carefully research and find a legitimate service, since many companies only want to sell a product and will purposefully present false positives. A better alternative is to scan the local LAN with a port scanning application from an external IP address. To scan the home IP address, users can either login remotely (SSH) via an external machine, or proxy through an external IP address. Detailed instructions on accomplishing that are beyond the scope of this document.

A special case is presented by users who share a LAN with other PCs (a stand-alone machine is not used). In this instance, the port scanning/testing service or a port scan application from an external IP address will actually only scan the local LAN's router/firewall and not the actual host's PC. If the latter is misconfigured, then the user could be susceptible to attacks from other machines within the LAN which sit behind the router, and a false sense of security could be the result.

For example, if the user shares the LAN with flatmates who are not so sophisticated in computer security, then those foreign machines should be regarded as potentially malicious. There is every possibility they may have been infected with a botnet already, or other harmful programs. Therefore, the user cannot trust the output of a port scan application running on their machine. If there is no spare machine for testing, then foreign computers on the LAN can be booted from a live CD, and the user can scan their personal machine with a port scan application. Details on how to accomplish that task are also outside the scope of this document.

NAT Router[edit]

Being behind an ordinary NAT router may provide a marginal layer of extra security.

Users should also review the relevant recommendations in the Computer Security Education chapter. This includes locking down router settings, purchase of a commercial-grade router, and for experts, flashing the router with an open-source GNU/Linux distribution.

Dedicated Connection[edit]

If possible, it is safer to avoid sharing the network (LAN, Wi-Fi, hotspot) with other potentially compromised machines.

Filtering Ports[edit]


From time to time a user asks which incoming/outgoing ports are required by Whonix-Gateway. The answer is:

  • Incoming: none.
  • Outgoing: all.

An alternative technique for controlling ports might be corridor (a Tor traffic whitelisting gateway), since it can act as a firewall. [13]


Whonix-Gateway itself does not open any ports. Users are advised to close all ports on the host as outlined in the Computer Security Education chapter (Host Firewall).


Filtering outgoing ports is difficult, since Tor entry guards or bridges listen on a variety of different ports. Limiting ports Tor uses for outgoing traffic is still possible, but recommended against, since it reduces anonymity. The effect is fewer entry guards or bridges are made available to the user. If users wish to proceed despite the risk, follow the instructions below.

On Whonix-Gateway.

Open /usr/local/etc/torrc.d/50_user.conf.

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

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

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

Start Menu -> Applications -> Settings -> /usr/local/etc/torrc.d/50_user.conf

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

sudo nano /usr/local/etc/torrc.d/50_user.conf


ReachableDirAddresses *:80
ReachableORAddresses *:443
## maybe: FirewallPorts PORTS
## See Tor manual:


Reload Tor.

After editing /usr/local/etc/torrc.d/50_user.conf, Tor must be reloaded for changes to take effect.

Note: If Tor does not connect after completing all these steps, then a user mistake is the most likely explanation. Recheck /usr/local/etc/torrc.d/50_user.conf and repeat the steps outlined in the sections above. If Tor then connects successfully, all the necessary changes have been made.

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

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

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

Start Menu -> Applications -> Settings -> Reload Tor

If you are using a terminal-only Whonix-Gateway, press on Expand on the right.

Complete the following steps.

Reload Tor.

sudo service tor@default reload

Check Tor's daemon status.

sudo service tor@default status

It should include a a message saying.

Active: active (running) since ...

In case of issues, try the following debugging steps.

Check Tor's config.

sudo -u debian-tor tor --verify-config

The output should be similar to the following.

Sep 17 17:40:41.416 [notice] Read configuration file "/usr/local/etc/torrc.d/50_user.conf".
Configuration was valid

This issue has also been discussed in the old Whonix forum.

Tor Traffic Whitelisting Gateway[edit]

It is possible to configure Whonix-Gateway (sys-whonix) to use corridor as a local proxy to establish the following tunnel:

User -> corridor -> Tor > Internet

This approach is not necessarily more anonymous, but it is an additional fail-safe since a Tor traffic whitelisting gateway can help protect from accidental clearnet leaks.

Hardware Security[edit]

Trusted computer hardware is fundamental to anonymity and security. Users are recommended to purchase and use "clean" computers that have components manufactured by reputable companies. It is preferable to pay in cash so hardware IDs do not leak the user's identity.

As outlined in the Computer Security Education chapter, it is safest to purchase a computer that is solely used for Whonix activities because this minimizes the risk of a prior hardware compromise.

Physical Attacks[edit]


Physical attacks require adversaries to have direct access to a user's computer and cannot be conducted remotely.

Full Disk Encryption[edit]

On the Host[edit]

Protection Against Powerful Adversaries[edit]

To protect against theft or robbery of personal information or data, users should apply FDE (Full Disk Encryption) on the host, and power off their computer when exposed to higher-risk situations like traveling. Laptop users should temporarily remove the laptop battery after powering off. This ensures that the RAM chips are completely powered down and that any encryption key/s in memory are erased. Hibernation is also a safe alternative, as the swap partition is encrypted in the default FDE configuration for various platforms (like Debian), provided the user did not change anything.

Users should follow the standard advice for picking strong and unique passwords, so that the password cannot be feasibly brute-forced. If possible, computers should never be left unattended.

If unauthorized access is strongly suspected or confirmed, the hardware should not be trusted or used after it is back in the user's possession. This scenario is only relevant to a smaller subset of users who are already targeted for physical surveillance. A sufficiently skilled adversary can infect it with spyware or sabotage it in a number of ways that are virtually undetectable. For example, malicious firmware could be installed to record all activities, or the machine rendered inoperable by bricking the hardware. In that eventuality, none of the measures outlined below would help.

Extra Measures[edit]

LUKS Suspend Scripts

On Linux hosts, there is one interesting solution for the risks posed by a computer in a suspended state; luks-suspend scripts.[15] This approach has some limitations because it is not yet packaged for Debian, and it has only been tested in the Ubuntu and Arch distributions. As of 2018, luks-suspend and keyslot nuking (mentioned below) is being merged upstream. [16]

Magic Key Feature

In an emergency, Non-Qubes-Whonix users can power-off the computer immediately with the Magic SysRq key feature. This is invoked by pressing the key combination: Alt + PrintScreen + o (lower-case letter). On bare-metal linux systems, the FDE passphrase is prompted after rebooting.[17] [18] [19] The magic key feature does not work on Qubes hosts because the Xen hypervisor does not recognize these commands. [20]


USBKill is an anti-forensics script written in the aftermath of the SilkRoad trial. Its purpose is to trigger protection events that prevent adversaries from siphoning files, installing malware, or running a mouse jiggler. The script creates a white-list of allowable USB devices. If anything else is plugged into the machine, the RAM is erased and the computer is immediately shutdown.

USBKill can also be configured to exclude all devices from being attached. In another high-security configuration, a white-listed flash drive serves as a key, and must be in the USB port at all times. If the flash drive is forcibly removed, the program will initiate the desired routines. [21] [22]

Protection Against Lesser Adversaries[edit]

The reader is reminded that advanced attackers have virtually limitless possibilities to infect a computer under their physical control, such as flashing low-level firmware or adding physical implants.

It may be possible to get plausible deniability on Linux hosts using methods other than thosed listed below, but the topic is a rabbit hole (see footnotes in this section). [23] Plausible deniability and FDE are also useless if the user is subject to physical abuse by a captor.

Nuke Patch for cryptsetup

The Kali penetration testing distro team has written a nuke patch for cryptsetup, which adds the option to nuke all keyslots after a certain passphrase is entered. [24]

Supplying the dead-man switch as the "real passphrase" to the interceptors of the machine is unlikely to be an effective strategy. It is standard forensics procedure to create multiple images of the drive beforehand.

TRESOR Kernel Patch

Another useful protection is the TRESOR kernel patch, which keeps the disk encryption key outside of RAM by storing it inside the CPU. TRESOR does have several limitations. It is only available for the x86 architecture, and it complicates software debugging by disabling DR registers for security reasons. [25] Moreover, a specialized attacker who can reverse engineer hardware designs is also capable of extracting secrets held in processor caches or specialized chips like TPMs.

Separate /boot Partition

When FDE is used on the host, it is inadvisable to keep any unencrypted files on that same physical media. High-risk users are recommended to move the /boot partition to a separate USB media. The bootloader (Grub) should then also be installed on the separate USB. To read more on this subject, see Pwning Past Whole Disk Encryption.

Advice for Solid-state Drives and USB Storage[edit]

Unlike hard-disk drives (HDDs), overwriting data on SSDs is no longer effective in wiping the disk. [26] [27] For instance, it is insecure to rely upon a fast erase mechanism by overwriting the header and key-slot area. [28]

The most dire potential consequence is that old passwords are not erased, and for a significant period. Consider the following concrete example: a user changes their computer password because they noticed it was exposed to shoulder-surfing or CCTV. On a SSD, the old password is still retrievable and can be used to decrypt the master key and all data. The reason is that secure overwriting is only guaranteed with magnetic disks.

Wear-leveling mechanisms like TRIM also leak information about the filesystem that can aid forensics. [29] [30] [31] [32] [33] It is strongly recommended to keep TRIM disabled (the default) during Linux LUKS-encrypted installations.


Install the GNOME disk utility on the host to easily encrypt removable storage before use, or to change the passphrase of a LUKS enabled system.

In a terminal, run.

sudo apt-get install gnome-disk-utility

Encrypted Guest Images[edit]

The greatest security benefit comes from applying full disk encryption on the host because that is the only place where it is most effective. Nevertheless, for the interested reader this section makes recommendations to deal with the following threat model:

  • The host is running when an adversary gets access to it, or the host is unencrypted.
  • The VM is powered down (otherwise the adversary would already have access to it).

The following security considerations are based on modified quotes by Iszi from the answer posted on, which was a user contribution to stackexchange, licensed under cc by-sa 3.0 with attribution required.

Full Disk Encryption within the Virtual Machine[edit]

When using FDE within the VM, never save (suspend/pause) the VM machine state, but instead shut it down completely. If this advice is ignored, the saved machine state could be stored outside of the encrypted image. This includes a RAM dump, which contains the encryption key required to decrypt the image. Upon resuming the VM, that stored file is not necessarily securely deleted, since it is virtualizer-specific. [34]

While the VM is running, users should not use the host system's sleep, suspend, or hibernate functions. Similar to the first scenario, these actions leave a RAM dump on disk, but this time it belongs to the host. This also contains sensitive data, such as encryption keys.

Virtual Machine Files in an Encrypted Container[edit]

VM files can also be stored in an encrypted container, such as a LUKS container. Newer and native support for LUKS encryption of disk images is available as of libvirt 2.10 [35] The same precautions should be taken as outlined in the previous section, as the risks equally apply.

FDE within the VM, LUKS encrypted containers for VM images, and FDE on the host can all be used independently, or in conjunction. However, increasing the layers of encryption may begin to significantly degrade performance. End modified quote by Iszi.

Other Security Considerations[edit]

Encryption is an area with many pitfalls. The user should also consider the following:

  • Swap. An encrypted swap provides no protection so long as the host is powered up, because the key is still in RAM.
  • Disabling swap. This action requires a special, secure wiping of the existing swap. It is safer to have never used swap before.
  • Memory dumps. These are caused by BSOD or kernel crashes, and can leave unintended traces on the host.
  • Powered down VMs. After a VM has shutdown, the RAM that previously contained the VM's encryption key might not have been wiped yet. Memory pages belonging to a terminated process do not have their contents wiped (zeroed) until they are about to be used by another process. [36] [37] [38] [39]
  • KVM. It is not expected that KVM guests could access data from other process' memory pages via memory ballooning, since KVM guests are Linux processes and subject to Linux memory allocation rules. [40]
  • Xen. Memory ballooning in Xen creates privacy concerns because it exposes the memory contents of other VMs if ballooning is enabled. [41]

The host of security considerations suggest that an unrealistic set of operational rules are required to defend the integrity of a purely encrypted guest image, without host FDE.

Open Security Research Questions[edit]

The following questions and configurations require further research:

  • With swap and crash dumps disabled, it is unknown whether the virtualizer writes parts of the VM's RAM contents to the disk. TODO: Specifically ask virtualizer vendors about this possibility.
  • Potential setup configurations:
    • Theoretically, a fullly encrypted operating system (currently: Debian) could be installed inside a VM and Whonix could be built using --target root inside another VM. This is analogous to the physical isolation model, but secure VM settings would be missing (similar to Manually Create Whonix VM Settings).
    • An encryption feature could be added to grml-debootstrap and/or the Whonix build script. There was an attempt to already do that, but this has stalled.
    • cryptsetup-reencrypt could be used, allowing for the shipping of encrypted Whonix images. The master key and the password (potentially blank) would be known to the public at first. Later, users would use cryptsetup-reencrypt to fix the master key and password, that is, to make the encryption effective.

Further Reading

For further information about encrypted images, see How Useful is In-Guest Encryption?. Users interested in running Whonix as a live OS, should read this entry. [42]

Side Channel Attacks[edit]

Side-channel attacks are made possible by physical effects caused by cryptosystem operations (on the side) which provide extra information about system secrets like cryptographic keys, state information, or full/partial plaintexts. Wikipedia defines side-channel attacks as: [43]

...any attack based on information gained from the physical implementation of a cryptosystem, rather than brute force or theoretical weaknesses in the algorithms (compare cryptanalysis). For example, timing information, power consumption, electromagnetic leaks or even sound can provide an extra source of information, which can be exploited to break the system.

Side-channels emerge because computation takes place on a non-ideal system, composed of transistors, wires, power supplies, memory, and peripherals. Component characteristics vary with the instructions and data that are processed, allowing measurable variance to be used by attackers. [44]

The main side-channel attack classes are: [45]

  • Cache attacks. Attackers monitor cache accesses made by the user in shared physical systems like virtualized environments or cloud services.
  • Timing attacks. Attacks are based on measuring how long various computations take to perform, such as the attacker's password compared to the user's unknown one.
  • Power-monitoring attacks. Attacks use measurements of varying hardware power consumption during computation.
  • Electromagnetic attacks. Leaked electromagnetic radiation allows attacks that can provide plaintexts and other information. Cryptographic keys can be inferred via this method; for example, see TEMPEST.
  • Acoustic cryptanalysis. Sound produced during computation is used for attacks.
  • Differential fault analysis. Secrets are discovered by introducing faults in a computation.
  • Data remanence. Sensitive data are read after supposedly being deleted.
  • Software-initiated fault attacks. Row hammer is an example of this attack, whereby off-limits memory is changed by rapidly accessing adjacent memory, leading to state retention loss.
  • Optical. Secrets and sensitive data are read by visual recordings with a high resolution camera, or other devices.

While Whonix has some limited countermeasures to side-channel attacks, in general it cannot provide protection against most classes, nor hardware keyloggers, TEMPEST, miniature cameras and so on. Full disk encryption is also helpless against these attacks.

For further reading on this complex topic, see here, here and here.

Screen Lock[edit]

Locking the screen on the host prevents others from viewing or using the device. It is advisable to set the screen to lock after a certain period of inactivity, and a strong password is recommended.

To manually lock the screen: [46] [47]

  • Windows:
    • Open Start Menu -> Click User Icon -> Select Lock; or
    • Ctrl + Alt + Del -> Select Lock; or
    • Windows key + L.
  • macOS:
    • Apple menu button -> Lock Screen; or
    • CMD + Ctrl + Q. [48]
  • Linux:
    • Menu panel -> Lock Screen.
    • Shortcuts are specific to the desktop environment in use, for example, GNOME, KDE, Xfce and so on.

BIOS Password[edit]

The Basic Input/Output System (BIOS) is non-volatile firmware which performs hardware initialization during the computer's booting process after it is powered on. It also provides runtime services for operating systems and progams. BIOS in modern PCs initialize and test system hardware components, as well as loading a boot loader or operating system from a mass memory device. The Unified Extensible Firmware Interface (UEFI) is the successor to BIOS that was released in 2011. [49]

All local settings are stored in BIOS, including power options, boot options and memory information. The BIOS menu allows the user to set and change a boot password for the computer upon start up. An administrator password can also be set to prevent others from changing BIOS settings. To set a BIOS boot password: [50] [51]

  • Turn on / restart the computer.
  • Press the relevant key to access the BIOS menu. It is usually one of: Del, F2, Esc, F10, or F12.
  • Navigate to the Security or Password section using the arrow keys.
  • Search for an entry named "Password on boot" or similar.
  • Enter the new, strong password.
  • Save the changes made to BIOS settings. On most PCs, this is done by pressing F10 or Esc -> Save and Exit. Check the bottom of the BIOS screen to be sure.
  • Reboot the computer and confirm a password prompt now appears.

For greater security, a password should be set to access the BIOS menu itself. Search the Security or Password BIOS menu for "Set supervisor password", "User password", "System password", or something similar. [52] Also, users may prefer to configure BIOS to only allow booting from HDD/SSD so the computer cannot be booted from CD-ROM or USB flash drives.

It should be noted that there are numerous methods of bypassing, removing or resetting BIOS passwords, so this method will only prevent casual attempts to gain access.

Cold Boot Attacks[edit]

Modern computer architecture poses a significant risk to Whonix users. Adversaries with physical access to a computer running Whonix may be able to recover all session activities, even if FDE is enabled.

Even when a computer is powered off, the data in RAM does not immediately disappear. Depending on the circumstances, data can survive for up to several minutes. For example, this occurs when a computer loses power abruptly and does not go through the normal shutdown cycle. [54] If an adversary has immediate physical access to a computer, a cold boot attack can be mounted.

Forensic experts have two main methods of extracting data from RAM: [55]

  • The running computer is cold-booted and a lightweight operating system is booted from a removable disk. A tool is used to dump pre-boot physical memory contents to a file.
  • The memory modules are quickly removed from the original system and placed in another computer under the adversary's control. The machine is then booted to access the memory contents.

In both cases, the RAM contents can be analyzed in a computer forensics laboratory. Depending on what is found, the user may be in serious peril. Notably, cold boot attacks have proven effective against Trusted Platform Modules (TPMs), as well as full disk encryption regardless of the vendor or operating system. For certain memory modules, the time window for an attack can be extended to several hours by cooling them with a refrigerant. [56]

Cold boot attacks are thought to be a very uncommon method of recovering data, but high-risk users should be prepared for such a contingency to stay on the safe side. So long as a cold boot attack is not mounted directly after shutdown, then contents of RAM should be emptied within minutes. [57]

Preventative Measures[edit]

Whonix does not yet provide an analogous feature to Tails, which wipes RAM on shutdown by overwriting it with random data. Possible interim solutions include:

Cold boot attacks are a clear and present danger for high-risk users due to the limited countermeasures available. In the purely hypothetical situation where an adversary is knocking earnestly on the door, best would be pressing the panic button on the host, leading to the contents of RAM being quickly wiped. Failing that, the computer should be immediately shut down, and access to the computer delayed as long as possible.

Evil Maid Attack[edit]

See Evil Maid Attack.

If the user has a TPM chip, see Anti Evil Maid.

Problematic Interfaces[edit]

There are a number of computer interfaces that pose the risk of a direct memory access (DMA) attack. Potentially exploitable interfaces include ExpressCard, PCMCIA, FireWire, PCI, PCI Express or Thunderbolt.

In practice, attached devices are permitted to read and write directly to memory, often without supervision of the operating system. This is in contrast to user-mode applications that are usually prevented from accessing memory locations that are not explicitly authorized by virtual memory controllers. [62]

A successful DMA attack on an unattended, live computer allows the adversary to: [63] [64] [65] [66]

  • Partially or fully read the memory address space.
  • Unlock screensavers without a passphrase.
  • Read documents, files or other digital traces present in memory.
  • Access sensitive cryptographic material in memory.
  • Circumvent FDE.
  • Inject executable code.
  • Take control of the entire system, for example via the network.

DMA attack software tools which mimic the abilities of state-level adversaries are even available on GitHub! [67] Mitigating the threat of a DMA attack requires mostly physical security countermeasures; it is recommended to:

  • Securely configure these interfaces.
  • Disable them in BIOS or UEFI.
  • Consider blocking or removing them completely.
  • Never allow unknown and potentially malicious devices to be inserted into these ports. [68]
  • Use linux kernel options to disable DMA by Firewire devices.
  • Use IOMMU technology where available and software which supports it, like Qubes. [69]

Operating System[edit]

About Debian[edit]

Debian Announcements[edit]

Since Whonix is based on Debian, it takes advantage of all the hard work done by the Debian security team: [70]

Debian takes security very seriously. We handle all security problems brought to our attention and ensure that they are corrected within a reasonable timeframe. Many advisories are coordinated with other free software vendors and are published the same day a vulnerability is made public and we also have a Security Audit team that reviews the archive looking for new or unfixed security bugs.

Experience has shown that "security through obscurity" does not work. Public disclosure allows for more rapid and better solutions to security problems. In that vein, this page addresses Debian's status with respect to various known security holes, which could potentially affect Debian.

Users should consider subscribing to the Debian security announcement mailing list to stay informed about the latest security advisories.

Harden Debian[edit]

Most hardening steps cannot be easily added to Whonix by default. Before attempting additional hardening measures, users need to understand them and apply steps carefully. This requires knowledge and effort, otherwise system errors or breakage is likely. This issue is still under investigation and the Whonix developers remain open to suggestions, as maintaining a secure operating system will always be an important topic.

Harden Software Repositories[edit]

Many operating systems provide multiple repositories. Since the Whonix implementation is based on Debian, interested users should read Ubuntu Repositories (similar to Debian) and Debian Policy Manual Chapter 2 - The Debian Archive as an introduction.

In summary, the main repository receives the most developer attention and security updates. This suggests it would make sense to tweak /etc/apt/sources.list to only use software from the main repository, and only install security fixes and no other updates.

Currently, Whonix does not do that by default and it is an open research question whether this will actually improve security.

Hardened Kernels[edit]

The upstream Kernel Self Protection Project[71] (KSPP) was established in 2015 with the goal of introducing more hardening features into mainline Linux. This includes many features found in the Grsecurity patchset, which was publicly available until early 2017. One advantage of KSPP is that users will no longer need to compile and tweak settings to create a secure kernel, as many hardening features become the default over time in various distributions. Up-to-date information on available hardening features can be viewed here.

The Hardened Kernel Project is a collaborative effort between Arch and Gentoo developers who handled Grsecurity packaging in their respective distributions with the goal of accelerating mainlining of the patchset. [72][73]

While kernel hardening is important, it only addresses a subset of security risks. It cannot protect against backdoors or security issues related to design, policy or yet unknown exploit classes.

Vulnerabilities at Install Time[edit]


Various installation media expose users to vulnerabilities, including:

  • Installer DVDs (including Debian and others).
  • Live DVDs (such as Tails and others).
  • Readily downloadable and importable VM images (Whonix and others).
  • VM images that are built with frozen sources rather than current sources (including Whonix).

The reason is that the latest stable releases sometimes contain vulnerable, remotely exploitable applications that are very likely to be used over untrusted networks [74] which are in a position to run man-in-the-middle attacks. One example of this in the recent past was vulnerability [CVE-2014-6273], which affected apt-get.

Readers are welcome to help research this issue further, and document sane and effective solutions. Forum discussion.

Possible Solutions[edit]


When using virtual machines, Whonix-Gateway could be configured to use the host apt-cache. Physically isolated Whonix-Gateways could use an apt-cache running on a separate machine. apt-cacher-ng is an example implementation of such an apt-cache.

Operating system updates would not be anonymized by default, which is a big disadvantage. [75] The user would need to figure out how to configure apt-cacher-ng on the host to force downloads through Tor.

Eventually Whonix-Workstation could use an apt-cache that is running on Whonix-Gateway. Unfortunately, this would increase Whonix-Gateways's attack surface if/when Whonix-Workstation is compromised. On the other hand, it would decrease Whonix-Workstation's attack surface if/when a vulnerable apt-get is used to download via untrusted Tor exit relays.


Another possibility is somehow using apt-offline to complete the initial updates of both Whonix-Gateway and Whonix-Workstation.

Building from Source Code using Current Sources[edit]

Self-created builds from source code using current sources would solve this problem. However, frozen sources have been implemented for reasons outlined in the "Current Sources" chapter; using Current Sources comes with its own issues.

Always Up-to-date Builds[edit]

If Whonix regularly released up-to-date builds, this would be an optimal solution for end users. However, the maintenance effort - building, testing and uploading - is resource intensive and currently not feasible for the Whonix team. Greater community support is needed with testing, alongside an automated test suite for Whonix.

Virtualization Platform[edit]



VirtualBox is developed by Oracle, a company which has a reputation of not being very "open". In the past, concerns have been raised about how they announce security issues in their products and how well they communicate with each other, leading to a negative perception by the security community.

VirtualBox is primarily a simple, "user-friendly", desktop solution and is most certainly not designed with the Whonix threat model in mind. Development is reported to be at a standstill and the author is not aware of any serious code audits having been completed. [76] Whonix developers would like to recommend a different VM solution at least as an alternative, but many popular, open source options like KVM and Xen are not cross-platform. Further, the latter examples seem to still lack a reliable "internal networking" feature, which Whonix heavily depends upon. Any readers who have in-depth knowledge of this issue are encouraged to edit this paragraph accordingly.

Users that have a strong preference for security should strongly consider using Qubes-Whonix, if they have suitably modern hardware. In short, Qubes-Whonix is more secure than the default Whonix configuration using a Type 2 hypervisor like VirtualBox.

Related VirtualBox Links:

See also:

Secure Labeling[edit]

VirtualBox has a secure labeling feature (VBoxSDL) which has not yet been implemented in Whonix. [77] This feature addresses the security risk of running in full screen mode:

When running guest operating systems in full screen mode, the guest operating system usually has control over the whole screen. This could present a security risk as the guest operating system might fool the user into thinking that it is either a different system (which might have a higher security level) or it might present messages on the screen that appear to stem from the host operating system.

In order to protect the user against the above mentioned security risks, the secure labeling feature has been developed. Secure labeling is currently available only for VBoxSDL. When enabled, a portion of the display area is reserved for a label in which a user defined message is displayed. The label height in set to 20 pixels in VBoxSDL. The label font color and background color can be optionally set as hexadecimal RGB color values.

Any readers who are knowledgeable in this area are encouraged to share their knowledge and edit this section accordingly.

Before this feature could be implemented in Whonix, one prerequisite is that users do not end up with non-standard desktop resolution, as this degrades anonymity as per Protocol-Leak-Protection and Fingerprinting-Protection.


Prefer Qubes for a higher-security solution. Qubes also supports a host of features unavailable in the Type 2 hypervisor model (VirtualBox, KVM, VMware etc.) 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.

Whonix-Workstation Security[edit]



Whonix is by no means a perfectly hardened system. Additional hardening measures are most welcome, but at the same time, hardening by default is very difficult. Until the Whonix Anonymous Operating System project realizes a significant increase in resources or community assistance, such measures will remain out of scope and hardening will be left to the upstream operating system. See Operating System for further details.


Learn more about AppArmor, which helps to protect against vulnerabilities by confining a program's file access based upon strict rule-sets. It is recommended to apply the available Whonix AppArmor profiles, which are available for various programs which run in both the Whonix-Gateway and Whonix-Workstation, such as Tor, Tor Browser, Thunderbird and others.

Multiple Tor Browser Instances and Workstations[edit]

Appropriate compartmentalization of user activities is important when different identities and/or additional software are in use. Multiple Tor Browser instances provide some separation of distinct identities, however this issue has not yet been solved by Tor Browser or Tor Button. A more secure method of compartmentalization is using Multiple Whonix-Workstations. [78]

Multiple Tor Browser Instances[edit]

To better separate different contextual identities, users should consider starting multiple Tor Browser instances and running them through different SocksPorts. Follow the instructions in the Manually Downloading Tor Browser article and make minimal step changes where required, for example, Tor Browser must be extracted into a different folder.

It is also necessary to use a different SocksPort, see Change/Remove Proxy Settings. The Stream Isolation page explains why different SocksPorts should be used. Additional Tor Browser instances should use one of the custom SocksPorts 'without IsolateDestAddr' and 'without IsolateDestPort'. These SocksPorts are subject to change, but currently range from 9153 to 9159 (see Stream Isolation for a complete list of SocksPorts).

This method is less secure than using multiple Whonix-Workstations, which is outlined below.

Multiple Whonix-Workstations[edit]

For tasks requiring different identities and/or additional software, users are recommended to utilize two or more Whonix-Workstation VMs since different torified clients are isolated from each other. In this way, an exploit in Tor Browser in one Whonix-Workstation cannot simultaneously read the user's identity in another VM (for example, an IRC account). [79] Note that this method is less secure than using a Whonix-Workstation DisposableVM with Tor Browser in Qubes-Whonix.

Second Optional (Extra) Firewall[edit]

There is a second, extra firewall available for Whonix-Workstation; it can be found inside Whonix-Workstation in /usr/bin/whonix_firewall. It is optional and disabled by default because it would otherwise risk breakage of user applications.

The Whonix anonymity design does not require the Whonix-Workstation firewall be enabled, as the Whonix-Gateway firewall is responsible for routing all traffic over Tor. Nevertheless, it can be enabled for users who want additional security, as it can help protect against various threats, for example:

  • A compromised Whonix-Gateway which is trying to attack Whonix-Workstation and exfiltrate sensitive data.
  • In the case of multiple Whonix-Workstations, attacks originating from other compromised Whonix-Workstations.

Read the script comments and run man whonix_firewall before deciding to use it.

Whonix-Gateway Security[edit]

Static VirtualBox IP[edit]

Instead of using DHCP to obtain the internal IP for the Whonix-Workstation eth0 NAT adapter, a static IP could be used instead. This might marginally improve security, since the DHCP package can then be removed.

Open /etc/network/interfaces on github and read the comments. Then, comment out DHCP and comment in Static VirtualBox IP.

Disable Control Port Filter Proxy[edit]


If CPFP is disabled, the user will no longer receive helpful Whonix notifications when Tor is not fully bootstrapped, since the whonixcheck and sdwdate tools rely upon it.


On Whonix-Gateway[edit]

Deactivate CPFP in Firewall[edit]

Modify Whonix User Firewall Settings

Note: If no changes have yet been made to Whonix Firewall Settings, then the Whonix User Firewall Settings File /etc/whonix_firewall.d/50_user.conf appears empty (because it does not exist). This is expected.

If using Qubes-Whonix, complete these steps.

Qubes App Launcher (blue/grey "Q") -> Template: whonix-gw -> Whonix User Firewall Settings

If using a graphical Whonix-Gateway, complete these steps.

Start Menu -> Applications -> Settings -> User Firewall Settings

If using a terminal-only Whonix-Gateway, complete these steps.

sudo nano /etc/whonix_firewall.d/50_user.conf

For more help, press on Expand on the right.

Note: The Whonix Global Firewall Settings File /etc/whonix_firewall.d/30_default.conf contains default settings and explanatory comments about their purpose. By default, the file is opened read-only and is not meant to be directly edited. Below, it is recommended to open the file without root rights. The file contains an explanatory comment on how to change firewall settings.

## Please use "/etc/whonix_firewall.d/50_user.conf" for your custom configuration,
## which will override the defaults found here. When Whonix is updated, this
## file may be overwritten.

See also Whonix modular flexible .d style configuration folders.

To view the file, follow these instructions.

If using Qubes-Whonix, complete these steps.

Qubes App Launcher (blue/grey "Q") -> Template: whonix-gw -> Whonix Global Firewall Settings

If using a graphical Whonix-Gateway, complete these steps.

Start Menu -> Applications -> Settings -> Global Firewall Settings

If using a terminal-only Whonix-Gateway, complete these steps.

nano /etc/whonix_firewall.d/30_default.conf

Add the following content.



Reload Whonix-Gateway Firewall.

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

Qubes App Launcher (blue/grey "Q") -> Whonix-Gateway ProxyVM (commonly named sys-whonix) -> Reload Whonix Firewall

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

Start Menu -> Applications -> System -> Reload Whonix Firewall

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

sudo whonix_firewall

Deactivate CPFP[edit]

Stop CPFP.

sudo service control-port-filter-proxy-python stop

Disable autostart of CPFP.

sudo systemctl mask control-port-filter-proxy-python


Check if CPFP is still running or disabled.

ps aux

If the following output appears, then disabling did not work.

debian-+  1005  0.2  1.8  46096 13216 ?        Ss   20:46   0:00 /usr/bin/python /usr/sbin/cpfpd start
Deactivate whonixcheck CPFP Running Test[edit]

Open /etc/whonix.d/50_user.conf in an editor with root rights.

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

kdesudo kwrite /etc/whonix.d/50_user.conf

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

sudo nano /etc/whonix.d/50_user.conf

Add the following content.

whonixcheck_skip_functions+=" check_control_port_filter_running "


On Whonix-Workstation[edit]

Deactivate whonixcheck's Tor Bootstrap Test[edit]

Because it relies on CPFP.

Open /etc/whonix.d/50_user.conf in an editor with root rights.

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

kdesudo kwrite /etc/whonix.d/50_user.conf

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

sudo nano /etc/whonix.d/50_user.conf

Add the following content.

whonixcheck_skip_functions+=" check_tor_bootstrap "


Deactivate sdwdate-plugin-anon-shared-con-check[edit]

TODO: create a ticket and explanation for uninstalling sdwdate-plugin-anon-shared-con-check

Users can either uninstall or deactivate sdwdate-plugin-anon-shared-con-check. The latter method is currently easier and outlined below.

Open /etc/sdwdate.d/50_anon_dist_con_check_plugin_user in an editor with root rights.

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

kdesudo kwrite /etc/sdwdate.d/50_anon_dist_con_check_plugin_user

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

sudo nano /etc/sdwdate.d/50_anon_dist_con_check_plugin_user

Add the following content.




Restart sdwdate.

sudo service sdwdate restart

Tor Browser Updater[edit]

If a user wants to update Tor Browser using Tor Browser Updater by Whonix developers while CPFP is disabled, then follow the steps below. [81]

update-torbrowser --no-tor-con-check

Or create a file /etc/torbrowser.d/50_user.conf with the following content.


Block Networking until sdwdate Finishes[edit]

sdwdate-gui is effectively unused in Qubes, since it is not yet automatically started due to usability issues. [82] [83] Although sdwdate is functional, there are corner cases where time or other server, daemon or client program information might be leaked before sdwdate changes the time. [84] In that case, the user would only be left with the protections afforded by Boot Clock Randomization.


If users can persist with the usability issues of one sdwdate-gui systray instance per virtual machine, then consider enabling sdwdate-gui autostart. This will keep you informed about the status of the Tor network connection and sdwdate's progress, and will also help to test this feature.

It is recommended to enable autostart of sdwdate-gui.

Open /usr/lib/sdwdate-gui/start-maybe in an editor with root rights.

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

kdesudo kwrite /usr/lib/sdwdate-gui/start-maybe

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

sudo nano /usr/lib/sdwdate-gui/start-maybe

Remove the following code.

if [ -d /usr/lib/qubes ]; then
   ## Do not automatically start sdwdate-gui in Qubes due to various issues.
   ## -
   ## -
   ## -
   exit 0

Save and exit.

The next version of sdwdate-gui will have a more convenient way to enable it. Check back later when sdwdate-gui has been modified to stop automatically starting.


Make sure sdwdate-gui is always present in systray. TODO: describe better how to achieve that.

All Whonix Users[edit]

To block network access until sdwdate succeeds: [85] [86]

Open /etc/whonix_firewall.d/50_user.conf in an editor with root rights.

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

kdesudo kwrite /etc/whonix_firewall.d/50_user.conf

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

sudo nano /etc/whonix_firewall.d/50_user.conf

Copy and paste the following text.


Save the file and reboot.

whonixcheck Hardening[edit]

Prevent Polluting TransPort[edit]

Deactivate the TransPort Test for better Stream Isolation.

Open /etc/whonix.d/50_user.conf in an editor with root rights.

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

kdesudo kwrite /etc/whonix.d/50_user.conf

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

sudo nano /etc/whonix.d/50_user.conf

Add the following content.



Prevent Connections[edit]

Deactivate SocksPort Test, TransPort Test and Tor Browser Update check.

Open /etc/whonix.d/50_user.conf in an editor with root rights.

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

kdesudo kwrite /etc/whonix.d/50_user.conf

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

sudo nano /etc/whonix.d/50_user.conf

Add the following content.

whonixcheck_skip_functions+=" check_torbrowser "


Prevent Downloading Whonix News and Whonix User Census Counting[edit]

This will prevent downloading of Whonix News and Whonix census (counting of Whonix users) [87].

Open /etc/whonix.d/50_user.conf in an editor with root rights.

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

kdesudo kwrite /etc/whonix.d/50_user.conf

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

sudo nano /etc/whonix.d/50_user.conf

Add the following content.

whonixcheck_skip_functions+=" download_whonix_news "

Prevent Running apt-get[edit]

This prevents the running of apt-get by whonixcheck.

Open /etc/whonix.d/50_user.conf in an editor with root rights.

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

kdesudo kwrite /etc/whonix.d/50_user.conf

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

sudo nano /etc/whonix.d/50_user.conf

Add the following content.

whonixcheck_skip_functions+=" check_operating_system "

Prevent Autostart[edit]

sudo systemctl mask whonixcheck


See Tor.

Chaining Anonymizing Gateways[edit]

By default, all Whonix-Workstation traffic is forced through Whonix-Gateway. Alternatively, a chain of anonymizing gateways can be built, with sample tunnel configurations outlined below.


## chain:
Whonix-Workstation -> VPN-Gateway    -> Whonix-Gateway -> clearnet
## connection scheme:
user               -> Tor            -> VPN            -> Internet


## chain:
Whonix-Workstation -> Whonix-Gateway -> VPN-Gateway    -> clearnet
## connection scheme:
user               -> VPN            -> Tor            -> Internet

Pre- and Post-Tor-VPN

## chain:
Whonix-Workstation -> VPN-Gateway    -> Whonix-Gateway -> VPN-Gateway -> Internet
## connection scheme:
user               -> VPN            -> Tor            -> VPN         -> Internet

Whonix is not limited to VPN-Gateways; the VPN can be replaced with a Proxy-Gateway.


## chain:
Whonix-Workstation -> Proxy-Gateway  -> Whonix-Gateway -> clearnet
## connection scheme:
user               -> Tor            -> Proxy          -> Internet

Other Connection Schemes

Virtually any combination is possible: a Post-Tor-Proxy; a Pre/Post-Tor-SSH; or the proxy being replaced with JonDo or perhaps I2P.

The user should always remember that the connection will be created in reverse order. This is best explained using an example. [88]

## chain:
Whonix-Workstation -> Proxy-Gateway  -> Whonix-Gateway -> VPN-Gateway -> clearnet
## connection scheme:
user               -> VPN            -> Tor            -> Proxy       -> Internet

Upon reflection, it becomes clear why the connection happens in reverse order:

  • Whonix-Workstation has no way but to go through the Proxy-Gateway.
  • The Proxy-Gateway has no way but to go through Whonix-Gateway.
  • In this case, the last element in the chain is the VPN-Gateway, which must obviously connect through clearnet.

Thus, the VPN-Gateway uses clearnet, the Whonix-Gateway uses the VPN-Gateway to connect, the Proxy-Gateway uses Whonix-Gateway to connect, and Whonix-Workstation uses the Proxy-Gateway to connect. Since the Proxy-Gateway has option but to go through Whonix-Gateway followed by VPN-Gateway, it is clear why it will be the last hop in front of the destination server.

Other Considerations

Whether these combinations make sense in terms of security and anonymity is hotly debated and depends on the user's personal threat model, see Tor plus VPN or Proxy.

Before attempting complex tunnel configurations, the following basic knowledge is required:

This resource may also be useful: Inspiration.

Users must also have an understanding of, and be able to edit /etc/network/interfaces on Whonix-Gateway and/or on Whonix-Workstation. In the case of non-Qubes-Whonix, this refers to the virtual internal network name in VirtualBox settings.

This process is generally difficult because there are no other anonymizing gateways (VPN / JonDo / I2P / Proxy / SSH / VPN) available for download in Whonix, just the Whonix-Gateway which uses Tor to anonymize traffic. Users often have to look for instructions and/or build an anonymizing gateway themselves. [89]

For a VPN-Gateway, see also:

Useful External Links[edit]

Other Important Stuff[edit]

Users are also recommended to learn more about the following topics:


  1. In Qubes R4.
  2. attack surface
  4. For instance it reports if the .onion address is too long or short, and will use different circuits for different sources.
  5. apt-transport-tor will not result in Tor over Tor scenarios due to built-in Whonix settings preventing this.
  9. and
  13. W corridor for Whonix KVM ticket
  14. Until in-RAM execution of disposableVMs is implemented in Qubes-Whonix, this threat is not easily mitigated.
  21. For example, this can be done quickly if the flash drive is attached to the user's wrist via a lanyard.
  27. cryptsetup FAQ - Section: 5.19 What about SSDs, Flash and Hybrid Drives?
  33. In the case of VirtualBox, the file could end up in the folder ~/.virtualbox. A definitive answer requires further research.
  35. : "Linux zeroes out (i.e. fills with zeros) all pages of memory not when they are released, but when they are given to another process. Thus, no process may obtain data excerpts from another process. However, the pages will retain their old contents until they are reused."
  38. The threat is similar to cold boot attacks, but in this case it might even be a "warm" attack, because under this threat model, the machine and RAM is still powered. PAX_MEMORY_SANITIZE and its KSPP successor may mitigate this, but at the cost of a non-trivial performance hit.
  39. : "Memory ballooning is a memory management feature used in most virtualization platforms which allows a host system to artificially enlarge its pool of memory by taking advantage or reclaiming unused memory previously allocated to various virtual machines."
  40. : Xen explicitly assigns dedicated memory regions to instances and scrubs data upon the destruction of instances (or domains in Xen parlance). KVM depends more greatly on Linux page management; A complex set of rules related to KVM paging is defined in the KVM documentation. It is important to note that use of the Xen memory balloon feature is likely to result in information disclosure. We strongly recommended to avoid use of this feature.
  41. Live OS systems are designed to not leave traces of user activity on disk.
  47. Some macOS systems instead use Ctrl + Shift + Power button OR Ctrl + Shift + Eject key.
  51. If the system has both a supervisor password and a user password, then set passwords for both.
  57. Unfortunately, an upstream script does not yet exist to implement this feature, so Whonix is currently unable to provide a solution for this attack.
  58. Tails and Liberte Linux have partially solved this problem.
  59. Instead of waiting for an upstream solution, see the Dev#Wipe RAM panic script. The user would need to implement a panic button which will wipe the RAM. Please contribute if you code this feature or consider voting for this feature upstream.
  66. This is not an endorsement for the use of hacking tools.
  67. This is another reason why high-risk users should never leave their devices unattended.
  68. IOMMU maps device-visible virtual addresses to physical addresses. The security benefit is that operating systems that are run in guest virtualized machines - AppVMs in Qubes - do not know the physical memory addresses on the host that are being accessed. This makes DMA attacks very difficult and can lead to memory corruption if attempted.
  73. Such as Tor exit relays.
  74. This leaks a list of installed packages to ISP-level adversaries and update servers. For example, it is inadvisable to reveal that a webserver was installed when it is likely to be used to host a hidden web service and so forth.
  76. Partially because it is not available on the MacOS X platform.
  77. One or more additional Whonix-Workstations can be easily created.
  78. This does not protect against the sudden loss of networking, which could reveal to the attacker that two activities / accounts suddenly going off-line are probably related.
  79. This will undo settings set by /etc/sdwdate.d/31_anon_dist_con_check_plugin.
  80. It is simply easier to update using Tor Browser's internal updater instead.
  82. It is installed by default, and is functional when manually started. Users should check back at a later date for further news on sdwdate-GUI development.
  85. Time keeping is crucial for security, privacy, and anonymity. sdwdate is a Tor friendly replacement for rdate and ntpdate that sets the system's clock by communicating via onion end-to-end encrypted TCP with Tor onion webservers.
  87. "Internet" below refers to the destination server (a website for example).
  88. There are some instructions for a pfSense based VPN-Gateway which can be found with search engines, but it is untested for leaks.
  89. Some application-specific documentation will have no relevance, but a thorough study of other documentation will increase the user's awareness and gradually improve anonymity and security practices.


Whonix Advanced Security Guide wiki page Copyright (C) Amnesia <amnesia at boum dot org>
Whonix Advanced Security Guide wiki page Copyright (C) 2012 - 2018 ENCRYPTED SUPPORT LP <>

This program comes with ABSOLUTELY NO WARRANTY; for details see the wiki source code.
This is free software, and you are welcome to redistribute it under certain conditions; see the wiki source code for details.

Random News:

Have you contributed to Whonix? If so, feel free to add your name and highlight what you did on the Whonix authorship page.

https | (forcing) onion

Share: Twitter | Facebook

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

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