Advanced Security Guide

---

Basics

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

General

Users should understand that the system clock inside Whonix is set to UTC to prevent against time zone leaks. This means it may be a few hours ahead or behind the user's host system clock. It is strongly recommended not to change this setting.

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. 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. 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. 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. 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

Introduction

Spoofing the initial virtual hardware clock offset is useful to prevent Clock Correlation Attacks.

KVM

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.

[select code]

<clock offset='utc'>

<clock offset='utc'>

To.

[select code]

<clock offset='variable' adjustment='123456' basis='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).

VirtualBox

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.

[select code]

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

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

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

[select code]

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

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).

[select code]

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

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

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.

Qubes

TODO

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.

Summary

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.

Deactivate Automatic TimeSync

Warning: This action is recommended against and is usually not required. In all cases, first check with the Whonix developers.

To deactivate sdwdate, run.

[select code]

sudo service sdwdate stop

sudo service sdwdate stop

[select code]

sudo systemctl mask sdwdate

sudo systemctl mask sdwdate

Host Security

Whonix Platform

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

• Qubes-Whonix.
• Whonix with Physical Isolation, set up using two different computers and virtualization.

As 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, and PDF/image sanitization.

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

Hardening

Key Hardening Steps

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:

• Disable and minimize hardware risks.
• Securely download files and install software on the host.
• Avoid insecure dual-boot arrangements.
• Choose a host OS that is compatible with privacy and security goals.
• Harden the host (Debian) GNU/Linux OS:
  • Use Full Disk Encryption (FDE) on the host.
  • Apply a BIOS password for BIOS set up and boot.
  • Torrify apt-get traffic on the host to prevent fingerprinting and leakage of sensitive security information.
  • Further harden the host OS against physical attacks.
• Apply instructions to harden networking, including:
  • Use a dedicated network connection.
  • Configure a de-militarized zone (perimeter network) if necessary.
  • Test the router / firewall with a port scanning device.
  • Change the default administration router password and lock it down with strict settings.
  • Flash the router with opensource firmware.
• Disable Intel ME blobs.
• Install an opensource BIOS or UEFI firmware replacement.
• Spoof MAC addresses if necessary.
• Disable TCP and ICMP timestamps.
• Remove the NTP client and disable the NTP synchronization feature.

Additional Defenses

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. To reduce the attack surface and mitigate risks, it is necessary to:

• 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:

• Compile time hardening
• Mandatory Access Control
• Intrusion Prevention Systems

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:

• Rootkit Hunter (rkhunter).
• Intrusion Detection System (IDS).
• Snort network intrusion prevention system.
• TIGER security auditing program.
• sxid file and directory change tracker.
• Anti-virus and anti-malware programs.

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

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.

Torify apt-get Traffic

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.

Install apt-transport-tor from the Debian repository.

[select code]

sudo apt-get install apt-transport-tor

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.

[select code]

kdesudo kwrite /etc/apt/sources.list

kdesudo kwrite /etc/apt/sources.list

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

[select code]

sudo nano /etc/apt/sources.list

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.

Note that changing ftp.us.debian.org to http.debian.net picks a mirror near to whichever Tor exit node is being used. Throughput is surprisingly fast. Users should also be aware that all public-facing debian.org FTP services will be shut down on November 1, 2017.

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. This URL scheme also protects from system compromise in the event APT has a critical security bug.

One VM Whonix Configuration

Warning: The one VM Whonix configuration has been deprecated because there is no maintainer. Use at your own risk!

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

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

DMZ

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

Installation

The recommendation to install a host firewall is documented in the Computer Security Education chapter, along with basic settings.

Port Scan

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

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

Users should also follow recommendations in the Computer Security Education chapter to: lock down router settings, consider purchasing a commercial-grade router, and possibly flash the wired/wireless router with an open-source GNU/Linux distribution.

Dedicated Connection

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

Filtering Ports

Introduction

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.

Incoming

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).

Outgoing

Warning: This procedure is not recommended. Port based filtering of outgoing traffic is not applicable (as in useful) in the case of Whonix-Gateway.

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 /etc/tor/torrc.

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

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

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

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

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

[select code]

sudo nano /etc/tor/torrc

sudo nano /etc/tor/torrc

Add.

[select code]

ReachableDirAddresses *:80
ReachableORAddresses *:443
## maybe: FirewallPorts PORTS
## See Tor manual: https://www.torproject.org/docs/tor-manual.html.en

ReachableDirAddresses *:80 ReachableORAddresses *:443 ## maybe: FirewallPorts PORTS ## See Tor manual: https://www.torproject.org/docs/tor-manual.html.en

Save.

Reload Tor.

After editing /etc/tor/torrc, Tor must be reloaded for changes take effect.

Note: If Tor does not connect after completing all these steps, then a user mistake is the most likely explanation. Recheck /etc/tor/torrc 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.

[select code]

sudo service tor@default reload

sudo service tor@default reload

Check Tor's daemon status.

[select code]

sudo service tor@default 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.

[select code]

sudo -u debian-tor tor --verify-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 "/etc/tor/torrc".
Configuration was valid

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

Tor Traffic Whitelisting Gateway

Use corridor, a Tor traffic whitelisting gateway. in addition to Whonix.

Hardware Security

It is recommended to use "clean" computers made of parts manufactured by reputable companies and to pay in cash so as to not have hardware IDs leak your identity.

Whonix doesn't do anything against hardware backdoors.

Physical Attacks

Introduction

Physical attacks require an adversary to be physically preset, i.e. to be able to touch your computer.

Full Disk Encryption

On the Host

Note that as said on the warning page, Whonix is not designed as an amnesic operating system.

Protection Against Powerful Adversaries

To protect against theft or robbery, power off your machine at times when this is more likely to happen (traveling) and use FDE (Full Disk Encryption) on the host. After power off, temporarily remove your laptop battery to ensure that the RAM chips are completely powered down to allow for erasure of your encryption key. Note that hibernation is safe too as the swap partition is also encrypted in default FDE configurations like Debian's provided that you did not change anything. Standard advice for picking strong and unique passwords applies here. Never leave your computer unattended. As a rule-of-thumb you should assume that your machine is compromised after any unauthorized physical access. Do not trust or attempt to use your hardware once more even if its returned to you. A sufficiently skilled adversary will be able to infect it and none of the measures stated below will help - besides turning your machine into a powered down "brick" before it is confiscated.

This works provided that you were not already targeted for physical surveillance beforehand and won't be tortured at a black-site. The use of Tor should help prevent it from coming to this.

Extra Measures

Debian hosts:

An interesting solution to the risks of suspending your machine is the luks-suspend scripts. There are some limitations such as it not being packaged for Debian yet and that its only tested with Ubuntu and Arch.

In case of an emergency, you can power-off your machine immediately with the Magic SysRq key feature so that it requires the FDE passphrase on reboot (Baremetal Linux only). Press the key combo Alt + PrintScreen + o (lower-case letter). Does not work on Qubes hosts because Xen hypervisor does not recognize these commands.

USBKill is an anti-forensics script written in the aftermath of the SilkRoad trial. Its purpose is to trigger protection events that prevents adversaries from siphoning files/installing malware/running a mouse jiggler. It creates a USB white-list of allowed devices of which anything else plugged into the machine causes it to erase the computer's RAM and immediately shutdown. This can be adjusted to exclude all devices. It can also be used in reverse, with a white-listed flash drive in the USB port attached to the user's wrist via a lanyard serving as a key. In this instance, if the flash drive is forcibly removed, the program will initiate the desired routines.

Protection Against Lesser Adversaries

The nuke patch for cryptsetup, (written by the Kali pen-testing distro team ) adds the option to nuke all keyslots given a certain passphrase. Note that under most emergency conditions, you won't have enough time to reboot your computer and enter the dead-man switch passphrase. Supplying this as your "real passphrase" to the interceptors of your machine is unlikely an effective strategy. It is standard forensics procedure to create multiple images of the drive beforehand.

The TRESOR kernel patch that keep the disk encryption key outside of the RAM (by storing it inside the CPU) could also be useful. Limitations of TRESOR include: its x86 architecture specific and complicates software debugging by disabling DR registers for security reasons. A specialized attacker who reverses hardware designs will be able to extract secrets held in processor caches or specialized chips like TPMs.

When using FDE on the host, you shouldn't keep any unencrypted files on that same physical media. It is advisable to move the /boot partition to separate USB media and install Grub, the bootloader, to it. See Pwning Past Whole Disk Encryption. Advanced attackers have virtually limitless possibilities to infect a machine under their physical control such as flashing low-level firmware or adding physical implants.

Perhaps it is possible to get plausible deniability on Linux hosts? That topic is a rabbit hole. See footnote. If physical torture is an option on the table, plausible deniability and FDE will not be of much help.

Special Advice for SSDs

In the case of flash based storage like SSDs and USBs, never storing data unencrypted in the first place is the only solution to protecting data.

Unlike HDDs overwriting data on SSDs is no longer effective in wiping the disk. The most important consequence of this is that old passwords may still be around, potentially for a very long time because fast erase by overwriting the header and key-slot area is insecure. Example: You change your password because you notice it was exposed to shoulder-surfing or CCTV recording. On a SSD the old password is still retrievable and can be used to decrypt the master key and your data because secure overwriting no longer works as with magnetic disks.

Also wear-leveling mechanisms like TRIM leak information about the filesystem that can aid forensics. You must keep TRIM disabled (the default) during Linux LUKS-encrypted installs.

Tips

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

[select code]

sudo apt-get install gnome-disk-utility

sudo apt-get install gnome-disk-utility

Encrypted Guest Images

Primarily, full disk encryption should be applied on the host. That's a much more important place where and the only one where it is effective.

This encrypted images chapter is mostly theoretic at this point, because it contains many open research questions and is currently unsupported.

The threat model here is the following:

• Host is currently running while an adversary gets access to it or the host is unencrypted.
• VM is powered down. (Otherwise the adversary would already have access to it anyhow.)

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

• Whole-disk encryption within the VM.
  • a) Never save (suspend/pause) the VM machine state - always shut it down completely. Otherwise the saved machine state could be stored outside of the encrypted image. Including a RAM dump, which contains the encryption key required to decrypt the image. Upon resuming the VM, that file does not necessarily get securely deleted. Virtualizer specific. In case of VirtualBox, the file could end up in the folder ~/.virtualbox. Getting more definitive answers requires further research.
  • b) Do not use the host system's sleep, suspend, or hibernate functions while the VM is running. Otherwise something very similar to the above a) would happen. This time not the VM's RAM dump would end up on disk, but the host's, which contains the same sensitive data (including encryption keys).
• Wrap the VM files in an encrypted container (such as LUKS container). Newer native support for LUKS encryption of disk images is available as of libvirt 2.10
  • a) and b) equally apply.
• Whole-disk encryption of the host system.
  • a) and b) equally apply.
  • Do not use the host system's sleep or suspend functions - always shut down.

Each of these can be used independently or in conjunction with any or all of the others. However, keep in mind that multiple layers of encryption may begin to significantly impact performance. End modified quote by Iszi.

Other security considerations:

• Swap is an issue. Encrypted swap does not help you as long as the host is powered up. (Key naturally still in RAM.)
• Disabling swap would require to wipe (special secure delete) the existing swap. It might be the safest to never have used swap before.
• Memory dumps caused by BSOD or kernel crashes can still leave unintended traces on the host.
• When a VM has been powered down, the RAM that previously contained the VM's encryption key might not have been wiped yet. Memory pages belonging to a terminated process don't get their contents wiped (zeroed) until they are about to be used by another process. 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 could mitigate this but at the cost of a non-trivial performance hit.
• KVM: Can a KVM guest access data from other process' memory pages because of memory ballooning? KVM guests are Linux processes and subject to Linux memory allocation rules. Its not possible that a VM process accesses the data of memory pages that belonged to another process.
• Xen: Memory ballooning in Xen has privacy concerns because it exposes memory contents of other VMs if ballooning is enabled.
• Therefore unrealistic operational rules?

Security research questions:

• With swap and crash dumps disabled, could it still happen, that the virtualizer writes [parts] of the VM's RAM's content to the disk? Virtualizer specific. TODO: Specifically ask virtualizer vendors about this.

Setup ideas:

• Theoretically, one could install a full disk encrypted operating system (currently: Debian) inside a VM and then build Whonix using '--target root' inside a VM. Similar to physical isolation. Secure VM settings would be missing. (Similar to Manually Create Whonix VM Settings.)
• Or add an encryption feature to grml-debootstrap and/or Whonix's build script. There was an [1] to do that, which stalled.
• cryptsetup-reencrypt could be used. Encrypted Whonix images could be shipped. The master key and the password (perhaps empty if possible) would be known to the public at first but users could use cryptsetup-reencrypt to fix the master key and password, i.e. to make the encryption effective.

Forum discussion about this encrypted images chapter:

• How Useful is In-Guest Encryption?
• Running Whonix as a live OS in a VM is an attractive alternative as it prevents data-remnance in the first place.

Side Channel Attacks

Whonix does not defeat hardware keylogger, miniature cameras, TEMPEST.

Needless to say, that also FDE does not protect against these threats.

Screen Lock

Always lock the screen of the host (or better shut down) if you leave the system unattended.

BIOS Password

Can't hurt to have BIOS password for BIOS setup and boot. After you are done installing, allow only booting from HDD.

Cold Boot Attacks

Due to how modern computing works, basically everything that you have done during a session is stored in the RAM. If an attacker has physical access to your computer when you are running Whonix, it may enable her to recover everything that have been achieved during the session - even if you are using Full Disk Encryption. From typed texts to saved files, including passwords and encryption keys. The more recent the activity, the more likely it is that it is still in the RAM.

Furthermore, it has been shown that the data present in the RAM might be recoverable for seconds or even minutes after the computer is powered off using a cold boot attack.

In both cases the RAM contents can be analyzed in a computer forensics laboratory which might turn into a major disaster depending on what they find.

As far as the authors know, cold boot attacks are very uncommon, but it might still be good to be prepared and stay on the safe side.

Wipe RAM on shutdown (e.g. using a kexec script) - or do not leave the computer unattended immediately after shutdown. Unfortunately there is not yet an upstream script, to implement wiping the RAM on shutdown. We can not provide a solution for this attack, this is solved nowhere but partially in Tails and Liberte Linux (not checked), waiting for upstream solution, see Dev#Wipe RAM panic script. It is up to you to implement a panic button which will wipe the RAM, please Contribute. The least you can do is Vote at upstream for the feature.

Hypothetical... So, what should you do when you hear an attacker knocking at your door? You could just press the hypothetical panic button on the host. It would start to wipe the contents of the RAM by filling it out with random junk, thus erasing everything that was stored there before, including the encryption key of the encrypted storage devices you might use and the traces of your session. Then you would wait, possibly trying to buy valuable time by barricading your door.

Evil Maid Attack

See Evil Maid Attack.

If you have a TPM chip, see Anti Evil Maid.

Problematic Interfaces

Some interfaces such as ExpressCard, PCMCIA, FireWire or Thunderbolt may depending on the host operating system settings allow an attacker with physical access to read the RAM. You are advised to securely configure those interfaces, to disable them or to remove them.

Operating System

About Debian

Debian Announcements

Since Whonix is based on Debian, it takes advantages of the all of the work done by the Debian security team. As quoted from (http://security.debian.org/):

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.

Consider also subscribing to the Debian security announcement mailing list.

Harden Debian

• Debian Security Information
• Securing Debian Manual Chapter 6 - Automatic hardening of Debian systems
• Securing Debian Manual
• Debian Hardening Walkthrough
• Feel free to research even more.

Most hardening steps can not be easily added by default to Whonix. Mostly the user has to understand them and to be aware of them, require knowledge and effort, otherwise one thing or another will break. This is still under investigation and open for suggestions. Having a secure operating system will always be an important topic.

Harden Software Repositories

Many operating systems provide multiple repositories. Since Whonix's example implementation is based on Debian, you should read Ubuntu Repositories (similar in Debian) and Debian Policy Manual Chapter 2 - The Debian Archive as introduction.

In conclusion, the main repository gets most attention and security updates. It would make sense to tweak /etc/apt/sources.list and to only use software from the main repository and to only install security fixes, no other updates.

Whonix currently doesn't do that by default and it is an open question for research if that really improves security.

Hardened Kernels

The upstream Kernel Self Protection Project (KSPP) was started in 2015 with the goal of introducing more hardening features into mainline Linux, including many features from the formerly publicly available patchset Grsecurity. The good side is users no longer need to compile and tweak settings to get a secure kernel as that will be the default.

The Hardened Kernel Project is a collaborative effort between Arch and Gentoo devs who handled Grsecurity packaging in their respective distros with the goal of accelerating mainlining of the patchset.

Note that while important, a hardened kernel only addresses a subset of security risks. It can't protect against backdoors or security issues related to design, policy or yet unknown classes of exploits.

Vulnerabilities at Install Time

Introduction

The issue with:

• 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)

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

Please help research and document sane and effective solutions. Forum discussion.

Possible Solutions

apt-cache

Whonix-Gateway (when using virtual machines) 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 would be a big disadvantage. One would have to figure out how to configure apt-cacher-ng on the host to download through Tor.

Eventually Whonix-Workstation could use an apt-cache that is running on Whonix-Gateway. This would increase Whonix-Gateways's attack surface once Whonix-Workstation is compromised while decreasing Whonix-Workstation's attack surface when using a vulnerable apt-get to download through untrusted Tor exit relays.

apt-offline

Somehow using apt-offline to do the initial updates of Whonix-Gateway and Whonix-Workstation.

Building from Source Code using Current Sources

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

Always Up-to-date Builds

A good solution for end users; however, the maintenance effort (building, testing, uploading) is beyond our current ability. We need help with testing and with an automated test suite for Whonix.

Virtualization Platform

VirtualBox

Introduction

VirtualBox is developed by Oracle, a company which is known for not being very "open". That includes how they announce security issues in their products as well as how they are perceived by the security community and how they will communicate with each other.

VirtualBox is primarily a simple, "user friendly", desktop solution and most certainly not designed with our threat model in mind. I haven't heard of anyone seriously auditing the code and I'd like to recommend a different VM solution at least as an alternative. There's KVM and Xen, open source but not cross-platform. It seems they are still lacking in terms of a reliable "internal networking" feature which Whonix heavily depends on. (If you know more, please edit this paragraph).

Anyone looking into Whonix solely because of security should really consider using Whonix with Qubes.

Related VirtualBox Links:

• Custom Ticket Search
• New Ticket

See also:

• Virtualization_Platform on licensing issues.
• Why Use KVM Over VirtualBox?
• Why use Qubes over other Virtualizers?

Secure Label

Secure labeling with VBoxSDL has not yet been added to Whonix. If you know more, please share your knowledge.

We must not end up with non-standard desktop resolution, as per Protocol-Leak-Protection and Fingerprinting-Protection.

Qubes

Prefer Qubes.

Whonix-Workstation Security

Hardening

Introduction

Whonix is not a perfectly hardened system. Additional hardening would be very welcome. At the same time, hardening by default is very difficult. That's why this is outside the scope of the Whonix Anonymous Operating System project, unless the project gets serious amounts of help with it. Hardening is left to the upstream operating system. See Operating System for details.

AppArmor

Learn about AppArmor. Check out Whonix's AppArmor profiles.

More than One Tor Browser in Whonix

As the Warning page stated, Whonix doesn't magically separate your different contextual identities and since Tor Browser and Tor Button do not yet solve this, for further separation of identities you could use Multiple Whonix-Workstations, which would be more secure.

Alternatively, less secure than Multiple Whonix-Workstations, you could start multiple instances of Tor Browser and run them through different SocksPorts. The instructions in the Manually Downloading Tor Browser article need minimal changes.

You need to extract Tor Browser into a different folder.

You also have to use a different SocksPort, see Change/Remove Proxy Settings. (See Stream Isolation page for explanation why you should use different SocksPorts.) Additional Tor Browsers should use one of the custom SocksPorts 'without IsolateDestAddr' and 'without IsolateDestPort'. These are subject to change - currently 9153-9159. (See Stream Isolation for a complete list of SocksPorts.)

Using Multiple Whonix-Workstations

See Multiple Whonix-Workstations.

Second Optional (Extra) Firewall

There is a Second, Optional, Extra Firewall for Whonix-Workstation, which is disabled by default. You find it inside Whonix-Workstation in /usr/bin/whonix_firewall.

Read the script comments and decide if you want to use it.

Whonix-Gateway Security

Static VirtualBox IP

Instead of using DHCP to obtain the internal IP for Whonix-Workstation eth0 NAT adapter, you could also use a static IP instead. Perhaps this could (minimally?) improve security, since you can remove one more package: the DHCP package.

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

Disable Control Port Filter Proxy

Introduction

Disabling Control Port Filter Proxy (CPFP) can improve security by decreasing the attack surface while sacrificing usability. By disabling it, you no longer will receive helpful notifications when Tor is not fully bootstrapped anymore by tools that come with Whonix (whonixcheck and sdwdate).

How

On Whonix-Gateway

Deactivate CPFP in Firewall

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.

[select code]

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

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.

[select code]

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

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

Add the following content.

[select code]

CONTROL_PORT_FILTER_PROXY_ENABLE=0

CONTROL_PORT_FILTER_PROXY_ENABLE=0

Save.

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.

[select code]

sudo whonix_firewall

sudo whonix_firewall

Deactivate CPFP

This work for Whonix 13 but needs to be updated for Whonix 14.

Stop CPFP.

[select code]

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

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

Disable autostart of CPFP.

[select code]

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

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

Reboot.

Check if CPFP is still running or disabled.

[select code]

ps aux

ps aux

If you see the following, then disabling didn't 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

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

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

[select code]

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

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

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

[select code]

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

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

Add the following content.

[select code]

whonixcheck_skip_functions+=" check_control_port_filter_running "

whonixcheck_skip_functions+=" check_control_port_filter_running "

Save.

On Whonix-Workstation

Deactivate whonixcheck's Tor Bootstrap Test

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.

[select code]

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

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

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

[select code]

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

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

Add the following content.

[select code]

whonixcheck_skip_functions+=" check_tor_bootstrap "

whonixcheck_skip_functions+=" check_tor_bootstrap "

Save.

Deactivate sdwdate-plugin-anon-shared-con-check

Uninstall (TODO: currently a bit difficult, needs ticket and explanation) or currently easier, deactivate sdwdate-plugin-anon-shared-con-check.

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.

[select code]

kdesudo kwrite /etc/sdwdate.d/50_anon_dist_con_check_plugin_user

kdesudo kwrite /etc/sdwdate.d/50_anon_dist_con_check_plugin_user

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

[select code]

sudo nano /etc/sdwdate.d/50_anon_dist_con_check_plugin_user

sudo nano /etc/sdwdate.d/50_anon_dist_con_check_plugin_user

Add the following content.

[select code]

DISPATCH_PREREQUISITE=""

DISPATCH_PREREQUISITE=""

Save.

Restart sdwdate.

[select code]

sudo service sdwdate restart

sudo service sdwdate restart

Tor Browser Updater

If you want to update Tor Browser using Tor Browser Updater by Whonix developers while CPFP is disabled...

[select code]

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

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

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

[select code]

TB_NO_TOR_CON_CHECK="1"

TB_NO_TOR_CON_CHECK="1"

whonixcheck Hardening

Prevent Polluting TransPort

On Whonix-Workstation.

Deactivate 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.

[select code]

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

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

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

[select code]

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

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

Add the following content.

[select code]

WHONIXCHECK_DISABLE_TRANS_PORT_TEST="1"

WHONIXCHECK_DISABLE_TRANS_PORT_TEST="1"

Save.

Prevent torproject.org Connections

On Whonix-Gateway and Whonix-Workstation.

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.

[select code]

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

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

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

[select code]

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

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

Add the following content.

[select code]

WHONIXCHECK_DISABLE_SOCKS_PORT_TEST="1"
WHONIXCHECK_DISABLE_TRANS_PORT_TEST="1"
whonixcheck_skip_functions+=" check_torbrowser "

WHONIXCHECK_DISABLE_SOCKS_PORT_TEST="1" WHONIXCHECK_DISABLE_TRANS_PORT_TEST="1" whonixcheck_skip_functions+=" check_torbrowser "

Save.

Prevent Downloading Whonix News

On Whonix-Gateway and Whonix-Workstation.

Prevent downloading Whonix News.

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

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

[select code]

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

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

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

[select code]

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

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

Add the following content.

[select code]

whonixcheck_skip_functions+=" download_whonix_news "

whonixcheck_skip_functions+=" download_whonix_news "

Prevent Running apt-get

On Whonix-Gateway and Whonix-Workstation.

Prevent downloading running 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.

[select code]

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

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

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

[select code]

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

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

Add the following content.

[select code]

whonixcheck_skip_functions+=" check_operating_system "

whonixcheck_skip_functions+=" check_operating_system "

Prevent Autostart

[select code]

sudo systemctl mask whonixcheck

sudo systemctl mask whonixcheck

Tor

See Tor.

Chaining Anonymizing Gateways

Experts only!

All Whonix-Workstation traffic is by default forced through Whonix-Gateway. Alternatively, you could also build a chain of Anonymizing Gateways. Examples:

Post-Tor-VPN.

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

Pre-Tor-VPN.

## 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

It is not limited to VPN-Gateways. You could also replace the VPN with a Proxy-Gateway.

Post-Tor-Proxy.

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

Or with a Post-Tor-Proxy, or with a Pre/Post-Tor-SSH. Or replace the proxy with JonDo or perhaps I2P. Virtually any combinations are possible.

It is important to understand, that the connection will be created in reverse order. This is best explained using an example.

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

If you think about it, 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. The last one in the chain, in this case, the VPN-Gateway, 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 no way 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.

Whether such combinations make sense or not is controversially discussed and depends on your personal threat model, see Tor plus VPN or Proxy.

Legend:

• Internet: the destination server - could be for example a website

Recommended basic knowledge:

• Tunnels/Introduction
• Stream Isolation

May be useful as well: Inspiration.

You must know, understand and edit /etc/network/interfaces on Whonix-Gateway and/or on Whonix-Workstation (and if not using physical isolation, the virtual internal network name in VirtualBox settings).

It will be difficult, because there are no other Anonymizing Gateways (VPN/JonDo/I2P/Proxy/SSH/VPN) available for download besides Whonix-Gateway which uses Tor to anonymize traffic, which you already know about. You have to look for instructions (there are some for a pfSense based VPN-Gateway you can find using a search engine, but untested for leaks, which does not imply, that there are leaks) and/or build such a Anonymizing-Gateway yourself.

For a VPN-Gateway, see also:
VPN-Gateway (w)

Useful External Links

• http://www.aboutdebian.com/security.htm
• http://www.cyberciti.biz/faq/debian-ubuntu-linux-software-integrity-checking-with-aide/
• http://serverfault.com/questions/11659/what-steps-do-you-take-to-secure-a-debian-server
• http://seifried.org/lasg/
• https://wiki.ubuntu.com/BasicSecurity
• https://wiki.ubuntu.com/BasicSecurity/DidIJustGetOwned
• https://help.ubuntu.com/community/Antivirus

Other important stuff

Last, but definitely not least.

• Time Attacks
• Read Stream Isolation.
• Read Connections between Whonix-Gateway and Whonix-Workstation.
• Read Entropy.
• Restrict TransPort: Explained under Whonix-Workstation is firewalled.
• MAC Address: If you are interested in the discussion about anonymizing MAC addresses, you could read the development discussion and draw conclusions from it, see Computer Security Education MAC Address.
• Of course you should read all Documenation pages. (Although some stuff will not be of concern for you. For example, if you are not interested in TorChat, Remailers or Mixmaster, you obviously don't have to thoroughly study these pages.
• Design: Still reading? Great! Please check the Technical Design, it contains further recommendations on what is less than ideal and how it could possibly be improved.

License

Whonix Advanced Security Guide wiki page Copyright (C) Amnesia <amnesia at boum dot org>
Whonix Advanced Security Guide wiki page Copyright (C) 2012 - 2017 Patrick Schleizer <adrelanos@riseup.net>

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:

Please contribute by helping to answer Whonix questions.

---

Impressum | Datenschutz | Haftungsausschluss

https | (forcing) onion
Share: Twitter | Facebook | Google+

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 (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. (Why?)