Jump to: navigation, search

Advanced Security Guide

This page contains changes which are not marked for translation.

Other languages:
English • ‎español • ‎português • ‎中文(简体)‎

Contents

Basics[edit]

Please understand the basics first, read the Computer Security Education.

Network Time Synchronization[edit]

General[edit]

Don't wonder... To prevent against time zone leaks, the system clock inside Whonix was set to UTC. This means it may be a few hours before or ahead of your host system clock. Do not change!

When you suspend/save the state of a VM, clock will stop and continue after resume, thus lag behind. You shouldn't suspend/save the state of Whonix-Gateway. Rather power the Gateway off, if you no longer need it. [1] You can suspend/save the state of Whonix-Workstation, but then the clock will lag behind. To fix it run inside Whonix-Workstation Start Menu -> Applications -> System -> Whonix Timesync.

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] The ISP and/or the time server could either non-intentionally or intentionally (as an attack) introduce a clock skew or the host clock could simply malfunction.

If the host clock is too much off, more than one hour in past or more than 3 hour in future, Tor can't connect to the Tor network. [3] The easiest fix in this situation is to manually fix the clock on the host, to power off Whonix-Gateway and to power on Whonix-Gateway again.

Another side effect of the host clock being too much off is, that downloading operating system updates on the host and cryptographic verification, such as verifying SSL certificates on the host browser may no longer be possible, until you manually fix the clock.

Before you think, your ISP is tampering with NTP, ensure first, that not simply the host clock is defect due to an empty battery.

If you should really ever catch your ISP tampering with NTP, you should probably disable it and manually update the host clock out of band, i.e. using a watch or atomic clock. In case it isn't a large scale attack, but a targeted attack, you most likely have already bigger problems to worry about than NTP. (See Warning page chapter Confirmation attacks.)

You have also another option. You could disable NTP on your host and always manually adjust the clock out of band, i.e. using a watch or atomic clock. This might make your clearnet traffic more fingerprintable [4], since it introduces a device issuing clearnet traffic (at least operating system updates, hopefully), but not using NTP. It is unknown how many people deactivated/broken/uninstalled/never installed NTP. Also unknown, how many people are using alternative time synchronization methods such as authenticated NTP, tails_htp, tlsdate or similar. Search engine research however suggests, that very few people care and do so.

Spoof the Initial Virtual Hardware Clock Offset[edit]

Introduction[edit]

This is useful to prevent Clock Correlation Attacks.

KVM[edit]

For KVM, click on Expand on the right.

Edit the VM xml before import or edit the VM xml after import and change:

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

The adjustment attribute takes any arbitrary value of seconds. Pick a random number of seconds only known to you from 0 to 900 (15 minute range).

VirtualBox[edit]

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 feature or past. Syntax.

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

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

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

Pick one example per VM and use random values within the range. (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

Clock skew apart this small biossystemtimeoffset [5] [6] is always bad for privacy [7].

Qubes[edit]

TODO

Summary[edit]

  • Needs to be done only after importing the Virtual Machine: #Spoof the Initial Virtual Hardware Clock Offset
  • Run Secure Network Time Synchronization after suspend/save/resume or do not use suspend/save/resume at all.
  • Tor can't connect if the host clock is too much off. In this case manually fix the host clock, power off Whonix-Gateway and power on Whonix-Gateway again.
  • Keep an eye on the host clock, ensure that it's always somewhat accurate.

Even though it's a difficult topic, you are advised to read Technical Design chapter Dev/TimeSync.

Footnotes. Additional information, reasoning, design for interested users, developers and auditors.

  1. Otherwise Tor can get confused if time is more than 1 hour in past or more than 3 hour in future and will only reconnect to the Tor network, if clock is manually fixed or powered off and powered on again.
  2. See Design: Dev/TimeSync.
  3. Because Tor can't verify the Tor consensus.
  4. See Fingerprint page to find out what fingerprinting means in this case.
  5. biossystemtimeoffset is being used, to unlink the initial clock synchronization of the VM by the Virtualizer from the host clock.
  6. Powering on a VM will initially synchronize the clock with the host clock until Whonix Timesync adjusts it.
  7. Can lead to linkability, thus would be pseudonymous rather than anonymous.

Deactivate Automatic TimeSync[edit]

Recommended against!
Usually not required!

To deactivate sdwdate, run.

sudo service sdwdate stop

sudo systemctl mask sdwdate

Host Security[edit]

Recommendation to use Whonix with Physical Isolation[edit]

Whonix using Physical Isolation, setup using two different computers AND virtualization. This is the most secure Tor configuration to date. Unfortunately, it is difficult to setup. See Physical Isolation.

Hardening[edit]

General hardening recommendations apply.

  • Minimize attack surface
  • securely configure services
    • e.g. for ssh: use fail2ban, allow only key authentication),

Proactive Defenses

Retroactive Defenses

  • The usefulness of this approach is limited. It doesn't prevent security breaches. It can only help making future breaches less likely.
  • rkhunter
  • IDS (Intrusion Detection System)
  • Snort
  • TIGER
  • sxid
  • antivirus, antimalware

These are only pointers for you to search the web about these topics and these are probably beyond the scope of this guide.

apt-transport-tor[edit]

It is recommended to Torrify APT's traffic on the host for many reasons:

  • Each machine has its own unique selection of packages that can be used to fingerprint a system across physical networks as system updates are performed, allowing location tracking.
  • System updates leak sensitive security information like package versions and the patch levels for a system. This information aids targeted attacks.

Instructions[1]:

Install apt-transport-tor from Debian repos:

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.

TIPS

Alternatively this URL scheme can be used tor+http://. It allows combining apt-transport-tor with apt-transport-https tor+https://.[2]

Note that changing ftp.us.debian.org to http.debian.net picks a mirror near to whichever Tor exit node you are using. Throughput is surprisingly good.[3]

Changing Debian URLs to point to the onion addresses http://vwakviie2ienjx6t.onion or http://earthqfvaeuv5bla.onion is the most secure option as no package metadata ever leaves Tor.[4][5][6] This protects your system from compromise even in the event of APT having a critical security bug.

One VM[edit]

One VM is deprecated. It was tested and developed for 0.1.3. The concept worked. It's deprecated now, because it has no maintainer.

Alternatively, you could also use one VM instead of two, where Tor runs on the host. It has some security and other kinds of advantages/disadvantages listed in the article. See OneVM.

Separate user account for VirtualBox[edit]

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

DMZ[edit]

If you are using a shared network, as in a cable modem/router or ADSL/router setup, that is shared with others, you should consider configuring a DMZ for your Whonix-Gateway.

This DMZ would restrict the Whonix-Gateway from accessing and from being accessible by other nodes on the network, eg printers, phones, computers, laptops, even if root access was somehow achieved on it.

Should an incursion occur, it would prevent the adversary from exploring other systems and possibly compromising them. It won't however do anything to protect your anonymity, because they could just ping some remote server and discover your real IP address. Or should other systems be compromised, it would be more difficult to compromise Whonix-Gateway.

Host Firewall[edit]

Computer Security Education[edit]

Installing a host firewall has been already recommended in Computer Security Education#Host Firewall.

Port Scan[edit]

Using a port scanner service on the internet to test your local LAN's router/firewall is a good idea, if you are careful to find a legitimate one instead of somebody who only wants to sell you something and will give you false positives deceptively. That's good, but even better is to run a port scan application from an external IP to scan your own IP. Either remote login (ssh) on some external machine of your own or proxy through an external IP to scan your own IP. The details on how to do so are outside the scope of this document.

However, if you are not using a stand-alone machine, but are on a LAN with other PCs, it is important to keep in mind that these testing services or your own port scan application from an external IP, actually only scan the local LAN's router/firewall, but these tests do not test your actual host's PC, which, if badly configured, could be susceptible to attacks from other machines within the LAN, behind the router. A false sense of security could be the result.

For example if you share your LAN with flatmates, who are not so sophisticated in computer security, you should regard their machines as possible malicious (may be conquered by a botnet already). Therefore you can not trust the output of a port scan application running on their machine. If you have no spare machine of your own, you could eventually boot their computer from a Live CD, which includes a port scan application, to scan your machine. The details on how to do so are outside the scope of this document.

NAT Router[edit]

Being behind an ordinary NAT router may be another tiny extra layer of security.

Dedicated connection[edit]

If possible, not sharing the network (LAN, Wi-Fi, hotspot) with other possibly compromised machines is safer.

Filtering Ports[edit]

Introduction[edit]

From time to time someone asks, which ports incoming/outgoing Whonix-Gateway requires. The answer is.

  • incoming: none
  • outgoing: all

An alternative might be corridor, a Tor traffic whitelisting gateway. [7]

Incoming[edit]

Whonix-Gateway itself does not open any ports. Closing ports on the host is still advised. That was already covered in the Computer Security Education, chapter Host Firewall.

Outgoing[edit]

Recommended against. Port based filtering of outgoing traffic isn't applicable (as in useful) in 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 possible, although recommended against, since it reduces anonymity (fewer entry guards (or bridges) are available to you). If you want to do so anyway...

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:

sudo nano /etc/tor/torrc

And add.

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 you must reload Tor so your changes take effect. (Note: if after completing all these steps and you are not able to connect to Tor, you have most likely done something wrong. Go back and check your /etc/tor/torrc and redo the steps outlined in the sections above. If your are able to connect to Tor, then you have completed your changes correctly.)

For Qubes-Whonix, complete the following steps:

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

For graphical Whonix-Gateway, complete the following steps:

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

For 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

Should show something like the following.

Sep 17 17:40:41.416 [notice] Read configuration file "/etc/tor/torrc".
Configuration was valid

This has also been discussed in the old forum.

Tor traffic whitelisting gateway[edit]

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

Hardware Security[edit]

It's 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[edit]

Introduction[edit]

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

Full Disk Encryption[edit]

On the Host[edit]

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

Protection Against State-Level Adversaries[edit]

To protect against theft or seizure, 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. 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[edit]

Debian hosts:

An interesting solution to the risks of suspending your machine is the luks-suspend scipts.[9] 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).[10][11][12] Press the key combo Alt + PrintScreen + o (lower-case letter). Does not work on Qubes hosts because Xen hypervisor does not recognize these commands.[13]

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. [14]

Protection Against Lesser Adversaries[edit]

The nuke patch for cryptsetup, (written by the Kali pen-testing distro team [15]) adds the option to nuke all keyslots given a certain passphrase. [16] 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 patch that keep the disk encryption key outside of the RAM (by storing it inside the CPU) could also be useful.[17] [18] Limitations of TRESOR include: its x86 architecture specific and complicates software debugging by disabling DR registers for security reasons. [19] 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's possible to get plausible deniability on Linux hosts? That topic is a rabbit hole. See footnote. [20] If physical torture is an option on the table, plausible deniability and FDE will not be of much help.

Special Advice for SSDs[edit]

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.[21][22] You cannot rely on wear-leveling mechanisms like TRIM because they expose data blocks to forensics.[23] You must keep TRIM disabled (the default) during Linux LUKS-encrypted installs.

Tips[edit]

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

sudo apt-get install gnome-disk-utility

Encrypted Guest Images[edit]

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).
    • 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. [24] 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.
  • 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.[25]
  • 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.

Forum discussion about this encrypted images chapter:
How Useful is In-Guest Encryption?

Side channel attacks[edit]

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

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

Screen lock[edit]

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

BIOS password[edit]

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[edit]

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 Encryptoion. 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 not standard procedure within law enforcements and similar organizations anywhere in the world yet, 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's 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[edit]

See Evil Maid Attack.

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

Problematic Interfaces[edit]

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[edit]

About Debian[edit]

Debian Announcements[edit]

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[edit]

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[edit]

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's an open question for research if that really improves security.

grsecurity[edit]

About grsecurity[edit]

Linux kernel is not a secure OS, Linus himself made it pretty clear that he doesn't think highly of the "security community"[26]. His threat model and a Tor User threat model don't have much in common. Good that Linux is open source and if we disagree with a policy or politics we can just patch or fork it... Grsecurity/PaX is the most comprehensive kernel patch providing much needed security hardening both for the kernel itself and for making userland protections more effective.

Sadly Debian does not ship a grsecurity kernel. [27] That means either a packager/maintainer of Whonix needs to compile them EVERY TIME there is a security update to the kernel (which is pretty frequently) or the Whonix users themselves need to compile and update their kernels. This is undesirable because kernel compilation is not set and forget, you need a bit of knowledge, it takes a while, especially in a resource restricted VM and you need to keep updated about new releases via mailing lists or similar because your software updater doesn't automatically handle custom kernels (even emerge in hardened gentoo doesn't). All this would most likely only result in users running old, outdated kernel versions.

Furthermore, for Whonix-Gateway and the Identity/Location TCB grsecurity only addresses a subset of security risks: It can mitigate some kernel vulnerabilities (and we only really care about the networking stack which is pretty secure judging from its track record). Maybe some (memory corruption) vulnerabilities in apt-get and Tor that aren't already mitigated by the existing userland hardening done by Ubuntu. It can't protect against backdoors or security issues related to design, policy or yet unknown classes of exploits. We feel that these relatively small advantages outweigh the issues introduced by using a custom compiled kernel. We hope a binary distro will step forward and start using grsecurity. In that case we'll most likely switch Whonix-Gateway to that distro as soon as possible.

For Whonix-Workstation the benefits are even more doubtful. To be effective grsecurity needs to lock down some functions that are needed by Xorg, JIT compilers... but we need those to be working. To solve this we'd have to write a restrictive RBAC policy which is far from trivial. We think accepting that Whonix-Workstation will be exploitable and acting accordingly (using snapshots and rolling back to clean state) is the right approach for a desktop system.

If you disagree with this assessment or have any suggestions how to improve the current situation please let us know.

Experts only: There is also Hardened Gentoo based Whonix-Gateway. Outdated, needs maintainer. See Hardened Gentoo TG .

Updates:

Footnotes:

  1. https://packages.debian.org/apt-transport-tor
  2. https://lwn.net/Articles/672350/
  3. https://retout.co.uk/blog/2014/07/21/apt-transport-tor
  4. http://richardhartmann.de/blog/posts/2015/08/24-Tor-enabled_Debian_mirror/
  5. https://onion.debian.org
  6. https://onion.torproject.org
  7. W corridor for Whonix KVM ticket
  8. W corridor for Whonix KVM ticket
  9. https://github.com/vianney/arch-luks-suspend/issues/7
  10. https://en.wikipedia.org/wiki/Magic_SysRq_key
  11. http://www.thegeekstuff.com/2008/12/safe-reboot-of-linux-using-magic-sysrq-key/
  12. https://phabricator.whonix.org/T553
  13. https://forums.whonix.org/t/fde-emergency-feature-testing-requested
  14. https://www.kali.org/tutorials/emergency-self-destruction-luks-kali/
  15. https://github.com/offensive-security/cryptsetup-nuke-keys
  16. https://en.wikipedia.org/wiki/TRESOR
  17. https://www1.cs.fau.de/tresor
  18. https://security.stackexchange.com/a/119835
  19. https://evilzone.org/operating-system/plausible-deniability-in-qubes-os/msg86174
  20. http://www.infosecisland.com/blogview/12153-Data-Remains-on-USB-and-SSDs-After-Secure-Erase.html
  21. http://www.theregister.co.uk/2011/02/21/flash_drive_erasing_peril/
  22. http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
  23. https://security.stackexchange.com/a/42186 : "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."
  24. http://docs.openstack.org/security-guide/content/data-privacy-concerns.html : 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.
  25. http://www.networkworld.com/article/2274866/lan-wan/torvalds--fed-up-with-the--security-circus-.html
  26. https://wiki.debian.org/grsecurity
  27. https://wiki.archlinux.org/index.php/Grsecurity

Installation[edit]

Try these instructions: grsecurity

Or...

Advanced users only!
These instructions are not in a state yet where they are easily usable by anyone.

Install genmkfile. See instructions for apparmor-profile-torbrowser but replace apparmor-profile-torbrowser with genmkfile.

Install grsecurity-installer. See instructions for apparmor-profile-torbrowser but replace apparmor-profile-torbrowser with grsecurity-installer.

To speed up compilation, you might want to assign additional CPU cores and more RAM to your virtual machine.

Run grsecurity-installer to download kernel sources, grsecurity patch, compile and install the grsecurity kernel.

sudo bash -x grsecurity-installer

During make menuconfig you need to enable grsecurity.

TODO: expand

Vulnerabilities at Install Time[edit]

Introduction[edit]

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[1] 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[edit]

apt-cache[edit]

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[2]. 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[edit]

Somehow using apt-offline to do the initial updates of 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. 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[edit]

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[edit]

VirtualBox[edit]

Introduction[edit]

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:

See also:

Secure Label[edit]

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[edit]

Prefer Qubes.

Whonix-Workstation Security[edit]

Hardening[edit]

Introduction[edit]

Whonix isn't 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[edit]

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

More than one Tor Browser in Whonix[edit]

These instructions only work with TBB 3.x and above.

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[edit]

See Multiple Whonix-Workstations.

Second, Optional, Extra Firewall[edit]

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[edit]

Static VirtualBox IP[edit]

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[edit]

Introduction[edit]

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[edit]

On Whonix-Gateway[edit]

Deactivate CPFP in Firewall[edit]

Modify Whonix User Firewall Settings.

Note: Initially, if you have not made any changes to Whonix Firewall Settings, then Whonix User Firewall Settings File /etc/whonix_firewall.d/50_user.conf appears empty, because it does not exist. This is expected.

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

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

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

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

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

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

For more help, press on expand on the right.

Note: Whonix Global Firewall Settings File /etc/whonix_firewall.d/30_default.conf contains default settings and explanatory comments what these settings purpose. It gets opened read-only by default. By default you are not supposed to directly edit the file. Below, we recommend 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, complete the following steps.

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

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

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

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

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

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

Add the following content.

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:

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

Reboot.

Check if CPFP is still running or disabled.

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[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 "

Save.

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 "

Save.

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

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:

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.

DISPATCH_PREREQUISITE=""

Save.

[3]

Restart sdwdate.

sudo service sdwdate restart

Tor Browser Updater[edit]

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

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

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

TB_NO_TOR_CON_CHECK="1"

whonixcheck Hardening[edit]

Prevent polluting TransPort[edit]

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:

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_DISABLE_TRANS_PORT_TEST="1"

Save.

Prevent connecting to torproject.org[edit]

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:

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_DISABLE_SOCKS_PORT_TEST="1"
WHONIXCHECK_DISABLE_TRANS_PORT_TEST="1"
whonixcheck_skip_functions+=" check_torbrowser "

Save.

Prevent downloading Whonix News[edit]

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:

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]

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:

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

Tor[edit]

See Tor.

Chaining Anonymizing Gateways[edit]

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's 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's 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's 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:

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[edit]

Other important stuff[edit]

Last, but definitely not least.

Footnotes[edit]

  1. Such as Tor exit relays.
  2. Leaks list of installed packages to ISP level adversaries and update servers. You usually don't want them to know that you installed a webserver and therefore likely host a hidden web service and so forth.
  3. This will undo setting by /etc/sdwdate.d/31_anon_dist_con_check_plugin.

License[edit]

Whonix Advanced Security Guide wiki page Copyright (C) Amnesia <amnesia at boum dot org>
Whonix Advanced Security Guide wiki page Copyright (C) 2012 -2014 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:

Do you know our Documentation, Technical Design and Developer Portal already?


Impressum | Datenschutz | Haftungsausschluss

https | (forcing) onion
Share: Twitter | Facebook | Google+
This is a wiki. Want to improve this page? Help welcome, 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 above, content of this page is copyrighted and licensed under the same Free (as in speech) license as Whonix itself.