Dev/Build Documentation/Physical Isolation/9
WARNING: Please don't forget reading the Warnings chapter.
- 1 Introduction
- 2 Prerequisites
- 3 Host Preparation
- 4 How To Install Whonix-Gateway on Hardware (RECOMMENDED)
- 4.1 Get Debian
- 4.2 Install Debian
- 4.3 Network Configuration
- 4.4 Logon and upgrade Debian
- 4.5 Preparation
- 4.6 Get the Source Code
- 4.7 Get the Signing Key
- 4.8 OpenPGP Verify the Source Code
- 4.9 Choose Version
- 4.10 Clean up and Sanitize
- 4.11 Build Configuration (Optional)
- 4.12 Custom Build Tags
- 4.13 VM Settings (Optional)
- 4.14 Skip Steps (Optional)
- 4.15 Source Code Changes
- 4.16 Network Verification
- 4.17 Minor Things
- 4.18 Run Build Script
- 4.19 Final Steps
- 4.20 Cleanup
- 5 How To Install Whonix-Gateway in a VM (UNTESTED / NOT RECOMMENDED)
- 6 Install Whonix-Workstation in a VM (RECOMMENDED)
- 7 Install Whonix-Workstation on hardware (NOT RECOMMENDED)
- 8 Further required reading
- 9 Extra packages for better hardware support
- 10 Troubleshooting
- 11 Footnotes / References
When setting up Whonix in the form of two Virtual Machines running on the same physical host, exploits targeting the VM implementation or the host can still break out of the torified Client VM and expose the IP of a user. Malware running on the host has full control over all VMs. To protect such attacks we need a different approach: In this context we called it Physical Isolation, because the gateway system is installed on separate hardware. This drastically reduces the TCB by more than the half.
In total we'll be installing and configuring two computers and set up an isolated point to point network between them (you could also set up a an ordinary, completely isolated, LAN behind the Whonix-Gateway). One computer acts as the client or "Whonix-Workstation", the other as a proxy or "Whonix-Gateway" which will transparently route all of the Whonix-Workstation's traffic through Tor.
The Whonix-Gateway on its own physical device can either run directly on hardware or inside a virtual machine. Both options have advantages and disadvantages. We recommend to use no additional Virtual Machine for the Whonix-Gateway.
The Whonix-Workstation should always be installed in a Virtual Machine: A VM hides hardware serial numbers. See also Recommendation to use multiple VM Snapshots.
The host operating system(s) should only be used for downloading operating system updating, hosting Whonix-Gateway or Whonix-Workstation and nothing else.
Bonus points if the physical systems are exclusively used for hosting Whonix, or if storage devices are separated for Whonix and non-Whonix use cases, to avoid a Whonix hard drive getting infected by a another operating system.
WARNING: Less tested than VM builds. Needs your help for more rigid testing!
WARNING: Instructions are difficult. Only advanced Linux users can understand them.
WARNING: Dev/Build Anonymity has not been considered for this article.
WARNING: Do also read the warnings in the latest build instructions for VM images. Some of them, Don't add private files to Whonix's source code folder! and Check if the OpenPGP public keys are still up to date. also applies to the physical isolation page.
WARNING: This article currently lacks information about Whonix-Gateway's and Whonix-Workstation's MAC address. See also
Using spare hardware + Virtual Machine
- You can install a graphical host.
- Use the Whonix download version.
- You can use the graphical network manager on the host, for example to connect to WiFi.
- You can setup easily a VPN on the host. Tor will be tunneled through the VPN.
- Higher attack surface, because the Virtual Machine code get's involved.
Using spare hardware without Virtual Machine
- More secure, because less code is involved.
- Slightly more complicated setup
- More difficult to set up VPN
- More difficult to set up 3G networking compared to using a Windows host
We recommend that you use two dedicated computers for Whonix that are never used for activities that could lead back to your identity. Alternatively you can use an already existing and otherwise used computer for the Whonix-Gateway. To offer some isolation you should disconnect all internal and external drives and boot from a eSATA, USB or another internal drive into a clean environment.
- non-anonymous box (leave it as it is, like you want)
- non-anonymous home dial up internet router (leave it as it is, like you want)
- This really does not have to be a big desktop computer or ordinary server. There are alternatives.
- smartphone ,
- pad, tablet,
- notebook, netbook,
- Raspberry Pi (Whonix User Help Forum, older thread for old version Whonix 0.5.6: Installing Whonix Gateway on Raspberry Pi),
- router ,
- set top box,
- how to utilize such a device as a linux server is beyond the scope of this guide, there are already better resources
- anonymous 3G modem (see below) or anonymous wifi adapter (see below)
- You get the idea. Use a device which suits you.
- System Requirements
- Whonix-Gateway: A device with at least two network adapters, at least one of them ethernet , capable of running Linux. It will run Debian. 
- Whonix-Workstation: A device connected via ethernet to the Whonix-Gateway. It must only have this one NIC and no other network connectivity! Must be connected by wire. This will be the torified client system or Whonix-Workstation. It must be capable of running Debian.
- We recommend to use a VM as the client, the same Whonix-Workstation, that most non Physical Isolation users use.   
- Host build environment has a working internet connection to Debian mirrors.
- General advice from Build Documentation about Build Security applies
- Optionally, it would be useful, if you knew how to open a second virtual console.
- You need to build on Debian Stable (Wheezy). (How to obtain Debian safely: ) 
- Build dependencies and configurations get automatically applied, so you don't have to worry about that. 
- It is recommended to set your terminal (for example Konsole) to unlimited scrollback, so you can watch the full build log.
How To Install Whonix-Gateway on Hardware (RECOMMENDED)
Download a Debian Stable/Wheezy 32 bit installation iso. Detailed instructions doing so are unfortunately not part of this guide. However, the Debian page contains some help.
You can choose iso of any desktop environment (KDE, LXDE, Xfce, ...) but since you'll be using the command line, Debian Stable/Wheezy network install (netinst) version is recommended (it's the most minimal).
(You could also use a Debian Stable/Wheezy 64 bit installation iso, these instructions should also work, but it's less tested.)
In the installer boot menu of Debian Stable (Wheezy) press "Install" and choose following settings:
Select a language: English Select your location: United States Configure the keyboard: (select yours) Hostname: host Domain name: (empty) Root password: (set up a strong password) Full name for the new user: user Username for your account: user Password for the new user: (choose a good password, different from root password) Partitioning method: Guided - use entire disk (it's a good idea to set up cryptsetup encrypted LVM at this point) Partitioning scheme: All files in one partition (select the listed device in the next step) Partition disks/overview: Finish partitioning Write changes to disk: Yes Debian archive mirror country: Go back Continue without a network mirror: Yes Use a network mirror: No Participate in the package usage survey: No Software selection: None; deselect all options (using Space) Install the GRUB boot loader: Yes (select the listed device in the next step) Finish the installation: Continue
If you are interested in seeing a visual walk-through of the minimal installation of Debian Stable Wheezy, click on Expand on the right.
In the menu select "Install"
Set language as English.
Set location as United States.
Select your keyboard.
Installing additional content.
Network will auto-configure (hopefully).
Set the hostname to "host".
Leave the domain name empty.
Pick a strong root password.
Reenter the password.
Full name should should be "user".
Username should also be "user".
Enter a strong user password.
Reenter the password.
Network time procedure.
Use a guided partitioning method with the whole disk (FDE is a good idea if you plan to use physical isolation or as your main system).
Select the suggested disk.
Partition all files in one partition.
Confirm the changes.
It takes a few minutes to get the base system installed.
We don't need any extra packages so don't select a mirror, "Go back".
Confirm that you want to continue without a mirror.
"No thanks" to survey participation.
Deselect (no star) the given option (using Space).
Select your disk.
Finishing the installation.
Done! The system will reboot.
OPTIONAL - CUSTOMIZING FULL DISK ENCRYPTION
If you are interested in configuring a custom encryption algorithm to enhance security during the minimal installation of Debian Stable Wheezy, click on Expand on the right.
1. Under "Partitioning method", select Manual
2. Select the disk you are installing to and press enter, then select <Yes> to create a new empty partition table.
3. Select the "FREE SPACE" of the drive you are installing to, press Enter, "Create a new partition" should already be selected; press Enter again.
4. Now create a boot partition. This is the unencrypted partition your system boots from. The standard is 254.8 MB. Type "254.8 MB" (without the quotes) and press Enter.
5. Under "Type for the new partition:", Primary should already be selected, press Enter again; Under "Location for the new partition: "Beginning" should already be selected, press Enter again to go to the Partition settings screen.
Use the following settings for your boot partition:
Use as: Ext2 file system Mount point: /boot Mount options: noatime Label: none Reserved blocks: 5% Typical Usage: standard Bootable flag: on
Then select "Done setting up the partition" and press Enter, you will be brought back to the main partitioning menu.
6. Select "Configure encrypted volumes" and press Enter, then select <Yes> when asked to write the changes to disk and configure encrypted volumes.
7. Create encrypted volumes should already be selected, press Enter and select the free space of the drive you are installing to by pressing the spacebar, then select <Continue> and press Enter again. Additional components will load, then you will be brought to the configuration page for your encrypted partition. Here you can customize your encryption settings.
Use as: physical volume for encryption Encryption method: Device-mapper (dm-crypt) Encryption: twofish [Recommend "twofish" and "serpent" as alternatives. "Serpent" is the slowest and only recommended if you have a fast system (and a fast drive), as it creates a lot of system overhead. "Twofish" is an algorithm created by Bruce Schneier, and is a lot faster, computationally-speaking. For most use-cases, "twofish" should be sufficient as an alternative algorithm] Key size: 256 (leave as-is) IV algorithm: xts-plain64 [for most use-cases, xts-plain64 should be sufficient. Do not change this unless you know what you are doing. You could inadvertently create a security hole] Encryption key: Passphrase (leave as-is) Erase data: yes (this will wipe the partition) Bootable flag: off
8. After you have completed your configuration, select "Done setting up this partition", and press Enter, then select <Yes> and press enter to write the changes to disk, then on the next screen select "Finish", and press Enter.
9. It is highly recommended that you erase the partition before you continue. Please note this may take a while for large drives. If you have already securely wiped your device before starting this installation, you can skip this step. To erase the partition, select <Yes> and press enter.
10. Choose a strong password. This password should be at LEAST 26 characters, including symbols. Remember: the stronger your password, the stronger your encryption. The weaker the password, the weaker your encryption. After entering your password and confirming it, you will be brought back to the main partitioning menu.
11. Under your new "Encrypted volume" (which should be at the top of the list), highlight the partition that was just created under it (it should say ext4), and press Enter. Under "Use as:", change this to "physical volume for LVM", and press Enter, then select "Done setting up the partition", and press Enter again to be brought back to the main partitioning menu.
12. Now select "Configure the Logical Volume Manager" and press Enter.
13. Highlight "Create volume group", and press Enter. Under "Volume group name:", enter HOST_VG, and press Enter.
14. Use the spacebar to select your encrypted partition, then select <Continue> and press Enter.
(Optional) SWAP USERS: O1. Now create your swap partition. Highlight "Create logical volume" and press Enter, then select HOST_VG and press Enter again. Type SWAP, press Enter. O2. Enter your volume size (2.5 GB is usually a good standard size for most systems) then select <Continue> and press Enter.
15. Highlight "Create logical volume" and press Enter, then select HOST_VG and press Enter again. Type ROOT, press Enter.
16. Under the "Logical volume size:", your entire volume should already be displayed, press Enter again.
17. Highlight "Finish", then press Enter to be brought back to the main partitioning menu.
18. You should see your new partition for ROOT displayed on this screen [LVM VG HOST_VG, LV ROOT - xxx.x GB Linux device-mapper (linear)]. Select the partition underneath the heading and press Enter
19. Change "do not use" to the filing system of your choice. Ext4 is good for most installations. XFS is more suitable for filesystems on top of encryption and is more robust with better performance. For the purposes of this documentation, the following configuration is provided:
Use as: XFS journaling file system Mount point: / Mount options: defaults Label: none
20. Once you're done, select "Done setting up this partition", and press Enter to return to the main partitioning menu.
(Optional) SWAP USERS: O1. You should see your new partition for SWAP displayed on this screen [LVM VG HOST_VG, LV SWAP - 2.5 GB Linux device-mapper (linear)]. Select the partition underneath the heading and press Enter. O2. Change "do not use" to "swap area", and press Enter. Then select "Done setting up the partition" to return to the main partitioning menu.
21. Highlight "Finish partitioning and write changes to disk" and press Enter, then select <Yes> when asked to confirm the changes. Your installation will continue automatically.
The external interface (usually eth0) may need to be configured according to the requirements of your local network, e.g. static or simply left to use dhcp if the gateway is connected to a dhcp capable router. For wlan follow the upstream documentations: debian wiki, Ubuntu help.
Make sure the internet is working.
Logon and upgrade Debian
Logon, install all security updates and reboot.
## (host) login with "root" root ## Add a new repository source. echo "deb http://ftp.us.debian.org/debian stable main" >> /etc/apt/sources.list ## Refresh package lists and upgrade apt-get update && apt-get dist-upgrade -y
Install sudo and git. 
## Install "sudo" and git. apt-get install sudo git -y
You must build as user "user" and that user must be a member of the "sudo" group. Rebooting applies the changes.
## Add "user" to "sudo" group addgroup user sudo ## Reboot the system shutdown -r now ## (host) login with "user" user
You may want to take an image of your installation in case the build script fails in the middle.
Get the Source Code
Install git and get the source code from the git repository.
## Install git and curl sudo apt-get install git curl ## Get source code. git clone --recursive https://github.com/Whonix/Whonix
Remember it's Whonix, not whonix! If you are prompted for a username for github, it means you have mistyped the web address.
Get into the source folder.
Get the Signing Key
This chapter is recommended for better security, but not strictly required. (See Trust)
Import the key.
curl --tlsv1 --proto =https https://www.whonix.org/patrick.asc | gpg --import
gpg --fingerprint 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA
pub 4096R/2EEACCDA 2014-01-16 [expires: 2015-01-16] Key fingerprint = 916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA uid [ unknown] Patrick Schleizer <firstname.lastname@example.org> sub 4096R/0x3B1E6942CE998547 2014-01-16 [expires: 2015-01-16] sub 4096R/0x10FDAC53119B3FD6 2014-01-16 [expires: 2015-01-16] sub 4096R/0xCB8D50BB77BB3C48 2014-01-16 [expires: 2015-01-16]
Only getting the signing key from one source, from the download you want to verify isn't safe. For better security, Learn about Whonix Signing Key.
OpenPGP Verify the Source Code
This chapter is recommended for better security, but not strictly required.
Get a list of available git tags.
Verify the tag you want to build.
## ... Replace with tag you want to build. git tag -v 9.6
Output should look similar to this.
object 1844108109a5f2f8bddcf2257b9f3675be5cfb22 type commit tag 9.6 tagger Patrick Schleizer <email@example.com> 1392320095 +0000 . gpg: Signature made Thu 13 Feb 2014 07:34:55 PM UTC using RSA key ID 77BB3C48 gpg: Good signature from "Patrick Schleizer <firstname.lastname@example.org>" [ultimate]
|Check if the gpg signature timestamp makes sense. For example, simply said, if you previously saw a signature from in 2015 and now you are seeing a signature from 2014, then you could be target of a rollback (downgrade) or indefinite freeze attack. |
gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner.
Is explained on the Whonix Signing Key page and can be ignored.
Beginning from git tag 9.6 and above, by convention, git tags should point to signed git commits. (forum discussion) It is recommended to verify the signature of the git commit as well. (Replace 9.6 with the actual git tag you want to verify.)
git log --show-signature HEAD^..9.6
Output should look similar to this.
commit 5aa1c307c943be60e7d2bfa5727fa5ada3a79c4a gpg: Signature made Sun 07 Dec 2014 01:22:22 AM UTC using RSA key ID 77BB3C48 gpg: Good signature from "Patrick Schleizer <email@example.com>" [ultimate] Author: Patrick Schleizer <firstname.lastname@example.org> Date: Sun Dec 7 01:22:22 2014 +0000 .
Git checkout, which version (or git branch) you want to build.
In case you want to build a specific git tag.
git checkout 9.6
You have to replace 9.6 with the actual version you want to build. The stable version, the testers-only version or the developers version. Common sense is required while choosing the right version number. For example, the biggest version number is not necessarily the most recommended / latest stable version. You can learn about current versions reading Whonix News Blogs. New versions are also announced on the whonix-devel mailing list. So you could alternatively check its archives. Signing up for whonix-devel is another way to get informed about new releases.
Clean up and Sanitize
This is also important for security.
git clean -ndff
And look if that looks sane. (Generally should, unless you are modifying Whonix's source code, then you should understand git a bit better and know what you are doing.) If it looks like the following, everything is fine.
Would remove packages/apparmor-profile-gwenview/ Would remove packages/kde-privacy/
Now get rid of these folders.
git clean -dff
Removing packages/apparmor-profile-gwenview/ Removing packages/kde-privacy/
Make sure you have checked out the right commit for each git submodule.
git submodule update --init --recursive
Check if there are no extraneous files. This is important for security.
git status --porcelain
Should only show and nothing else.
# Not currently on any branch. nothing to commit (working directory clean)
Otherwise we'd need to get rid of these files first.
Build Configuration (Optional)
Usually you do not have to change the build configuration. Whonix build from source code comes with safe defaults. Whonix's APT Repository will NOT be used.
The most interesting build configurations (Terminal-Only, NoDefaultApps etc.) are documented in the following chapters below.
If you are interested, click on Expand on the right.
If you used build configurations earlier, it might be better to delete your build configuration folder since a few example files names change changed in meanwhile.
sudo rm -r /etc/whonix_buildconfig.d
Alternatively, if you know what you are doing, you can of course also manually get into the /etc/whonix_buildconfig.d folder, examine and change its contents to your linking.
/etc/whonix_buildconfig.d is a modular flexible .d style configuration folder.
Less popular build configurations are documented in the buildconfig.d folder and on the Dev/Source_Code_Intro#Build_Configuration page in a less user friendly documented way.
It is recommended to copy and paste text when creating build configuration files to avoid typos. Also keep care, that your editor even when you are using copy and paste, won't capitalizes variable names which are supposed to be lower case.
Terminal-Only Builds (Optional)
Advanced users can build a no-default-gui / no-KDE / terminal-only Whonix-Gateway and/or Whonix-Workstation.
If you are interested, click on Expand on the right.
terminal-only builds are less tested due to lack of contributor manpower. Should work well in principle.
NoDefaultApps Builds (Optional)
Advanced users can install fewer recommended packages to make the resulting build smaller and more customizable. (recommended as in useful to have, not necessary to have them for some other reason.)
If you are interested, click on Expand on the right.
NoDefaultApps builds are less tested due to lack of contributor manpower. Should work well in principle.
NOTE: You most likely want to combine this with terminal-only builds, see above.
NOTE: Such a NoDefaultApps system would for example not include Arm on Whonix-Gateway. So please do not create a NoDefaultApps build and then complain, that packages are missing.
We're just excluding a few meta packages. (Meta packages are packages, which do not hold files on its own, but only instruct apt-get to install other packages.)
CurrentSources Builds (Optional)
Advanced users could install from Current Sources (custom) instead of from Frozen Sources (default in 7.4.0 and above). Both options have security advantages and disadvantages.
If you are interested, click on Expand on the right.
CurrentSources builds are rarely tested due to lack of contributor manpower. Should work reasonably well in principle as long as no packages are removed from Debian. The worst thing that can probably happen, is that the build fails due to missing packages.
- Whonix's build script will use http://snapshot.debian.org instead of the more popular ftp.us.debian.org.
- Snapshot.debian.org will never change, i.e. their packages and versions will remain the same forever*[currentsources 1] [currentsources 2].
- Using Frozen Sources has the advantage that all builders end up with a very similar [currentsources 3] image. This gives builders more confidence, that they have ended up with an intact image.
- Are a precondition for the Verifiable Builds security feature.
- It follows, when building a fresh image it will contain outdated packages. (You can upgrade after booting for the first time.)
- Package downloads are still verified, but we have to ignore the valid-until field. Which means, a man-in-the-middle attack capable adversary could feed you with packages even older than configured in the version of Whonix you are building. Any packages which were ever signed with the APT repository signing key of that codename[currentsources 4]. You might not like that and therefore prefer building from Current Sources.
- At some point, for example if remotely exploitable vulnerabilities are found in the apt-get version (defined by Frozen Sources) it may be dangerous to continue building that version.
- We should compare our images with each other to ensure no man-in-the-middle attack has happened while building Whonix.
Current Debian APT repository:
- Packages and versions may change over time. Packages may be removed, replaced with others, versions get security other other updates.
- Build script may break the older the Whonix source code version release becomes. (Break as in the build won't finish - not as in creating images containing bugs.)
- Each builder ends up with an individual image.
- Valid-until field gets verified.
If you prefer to build from Current Sources, please add the following build script command line argument.
- Besides a few rare exceptions.
- As long the great snapshot.debian.org service lasts.
- Timestamps, temporary files and who knows what else (open research question) differ.
- Codename as in Testing, Wheezy, Jessie.
64bit Builds (Optional)
Advanced users can create 64bit instead of 32bit builds.
If you are interested, click on Expand on the right.
64bit builds are less tested due to lack of developer manpower. Should work well in principle.
By default, Linux 32 bit is used andkernel is installed. This can be changed using any of the following command line parameters.
Linux 64 bit. Less tested. Only installskernel.
Linux 32 bit. Only installskernel. Does not install kernel.
Linux 32 bit. Only installskernel. Does not install kernel.
kFreeBSD 64 bit. Entirely untested.
kFreeBSD 32 bit. Entirely untested.
Whonix APT Repository (Optional)
Whonix's APT Repository is disabled by default since Whonix 7.3.3. You may enjoy this for Trust reasons. You can later update Whonix debian packages from source code if you want. If you are interested in enabling Whonix's APT repository right after building (you could do that also after booting your build for the first time if you wanted) for convenience while sacrificing the extra security of not updating from source code, click on Expand on the right side.
Do you want to opt-in for Whonix's APT Repository?
Only Minimal Report (Optional)
By default Whonix's last build step creates a report file of all hdd contents. (See Verifiable Builds for details.) This step is optional. First introduced in Whonix 7.4.8. Whonix should work fine without that step. It is used for extra security. This step takes quite some time. This step is recommended. If you want to disable it, click on Expand on the right side.
Do you want to opt-out of the report creation build step?
APT Cache (Optional)
When building in a virtual machine, builders can use their own http proxy (apt cache) on the host, which will greatly improve build speed when building several times in a row (debugging, development).
If you are interested, click on Expand on the right.
This isn't required when you are building virtual machine images, because then apt-cacher-ng is automatically set up for you. Only useful when using --install-to-root in a virtual machine.
Requires Whonix 22.214.171.124 or above.
On the host.
sudo apt-get install apt-cacher-ng
Be sure to have a firewall, so not the whole internet can use your apt-cacher-ng service.
Inside your Virtual Machine.
Don't forget to replace 192.168.0.1 with your host's internal IP (use "sudo ifconfig" on your host to find out what your internal IP is).
Don't forget to add -E to sudo, so environment variables are preserved. Examples.
sudo -E ./whonix_build --install-to-root --tor-gateway --build sudo -E ./build-steps.d/1100_prepare-build-machine --install-to-root --tor-gateway
Custom Build Tags
Only if you are using your own git tags! In that case click on Expand on the right.
If you created for example a git tag "9.1" and want to receive Whonix News for "9", apply this.
Please look into. Look for.
## Override what version whonixcheck will show in its window title and which ## Whonix News will be downloaded. Change only if you know what you are doing. #whonix_build_version="6" #whonix_deb_package_version="2:7-debpackage1"
Create a fileand add for example. (You still have to replace "7" with the custom git tag you are using.
When you later update from Whonix debian packages from for example "9.1" to "10", these settings have to be commented out.
VM Settings (Optional)
Only relevant for VM builds.
Examples below. Values can be changed.
VirtualBox's --vmsize option (virtual RAM).
VirtualBox's --vram option (virtual video RAM).
grml-debootstrap's --vmsize option.
grml-debootstrap's --filesystem option.
grml-debootstrap's --hostname option. (The anon-base-files package will change that later again.)
grml-debootstrap's --password option.
grml-debootstrap's --debopt option.
Skip Steps (Optional)
Source Code Changes
Only in case you made changes to the Whonix source folder! In that case click on Expand on the right.
Not required if you only added using your own build configuration in folder.
If you made changes to the Whonix source code, those have to be git committed before building Whonix. Otherwise you'll get an error message. (Which looks like this: )
To git commit changes, some basic git knowledge would be of help. To give you an idea, the workflow could look like this.
git status git add * git status #git add path-to-file ## Preview. #git diff --cached git commit -a git status
Whonix 10 and above
If you made changes to the Whonix source code, it is the easiest to use the following build parameter.
Otherwise changes would have to be committed to git first.
Before running the whonix_build script make sure eth1 and eth0 refer to the correct interfaces.
## May be helpful. dmesg | grep eth
Otherwise you have to change the variables in the configuration files. To find the affected files, the following commands may be helpful. 
grep -r eth0 * grep -r eth1 *
Most configuration files work well inside Virtual Machines and on hardware. Only minor things such as deactivating powersaving, passwordless reboot, shutdown etc. are only recommended for Virtual Machines. You can easily comment them out by putting a hash # in front of them. They are marked, to find them, grep can be used. Skip this for now. You can change these files later after building Whonix. (Simpler.)
grep -r VMONLY* *
Run Build Script
It is recommended that you create a log of the build process by redirecting all the output to a log file. Be aware that by doing so no build progress will appear on the screen - instead a text log file will be created in your home folder.
sudo ./whonix_build --tor-gateway --install-to-root --build >> ~/log-phyiso 2>&1
To optionally watch the progress, open a second virtual console and type.
tail -f ~/log-phyiso
If don't want to create a log of the build process (the build progress will then appear on screen) use the following command.
This is not recommended because if anything goes wrong during the build, it will be harder to pinpoint the exact error without the actual log file.
sudo ./whonix_build --tor-gateway --install-to-root --build
You will autologin as new user "user". (If you didn't install as user "user", your old user and home folder does of course still exist.)
The build script will have replaced yourwith the respective file from . Your original network configuration file can still be found under . Should you require specific changes (those you might have required to add in the network configuration step above, such as eventually setting up WiFi), you need to make them again in . Restart your network again ( ) or reboot.
Remove temporary files.
How To Install Whonix-Gateway in a VM (UNTESTED / NOT RECOMMENDED)
It is advised to install a new OS just for hosting the Gateway VM, any OS that can run VirtualBox works but we recommend an Open Source system.
Adapter 1 can be set up as a NAT network. Adapter 2 must either be set to NAT as well (but you will need to forward ports from the host to the guest) or much simpler: use bridged networking and set it to the second physical interface (the one that goes into the isolated network/point to point ethernet). See "NAT vs Bridging" below.
This configuration is entirely untested and not recommended unless you need to run Tor through a VPN (can't that be done without VMs?) or an unsupported 3G modem and can't afford a 3rd physical device.
When using NAT for a virtualized Gateway you need to set up port forwarding in VirtualBox. Using bridged network may be easier, but then the router may see the Whonix-Gateway MAC address which identifies as Whonix-Gateway. (Should not be of concern in home networks. Should be of concern in untrusted networks or when using a modem to connect.)
Install Whonix-Workstation in a VM (RECOMMENDED)
Install and update a host operating system. On the host can run any OS that is capable of running VirtualBox, but be aware of Transparent Proxy Leaks. It is recommended against to use Windows or another other commercial proprietary system as host operating system.
Note sure what we wanted to say with this sentence: If the physical network (between Whonix-Gateway and a router) uses 10.152.152.* you need to review and edit all shell scripts and switch the internal network to something else!
Host Network Adapter
The host has to be configured to use the static IP configuration.
## Whonix-Workstation ## /etc/network/interfaces for the host, ## when using Physical Isolation, ## with Whonix-Workstation in a VM. auto lo iface lo inet loopback auto eth0 iface eth0 inet static ## Increment last octet of address ## on optional additional hosts. address 10.152.152.11 netmask 255.255.192.0 gateway 10.152.152.10 #pre-up /usr/bin/whonix_firewall ## Out commented. ## For what do we require the network and broadcast ## instances anyway? #network 10.152.152.0 #broadcast 10.152.152.255 #auto eth0 #iface eth0 inet dhcp ## end of /etc/network/interfaces
If the physical network (between Whonix-Gateway and a router) uses 10.152.152.* you need to review and edit all /etc/network/interfaces.
NAT vs Bridging
In the default Whonix VirtualBox image, the network adapter setting for Adapter 1 (eth0) is set to internal network and will therefore not work out of the box. There are two choices to fix this. NAT (recommended) or bridged network.
If you use NAT you will have to edit the /etc/network/interfaces/ in Whonix-Workstation to use DHCP (easier, shown in the example below) or a static IP for VirtualBox NAT.
sudo nano /etc/network/interfaces/
Replace it with.
## Whonix-Workstation ## /etc/network/interfaces in a VM ## when using Physical Isolation. auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp ## end of /etc/network/interfaces
Bridged Network (UNTESTED / NOT RECOMMENDED)
If you use bridged networking things will (or should, we haven't tested anything yet) just work.
Since in the bridged network case, Whonix-Workstation can see the MAC address of whatever network adapter it is connected to, you should change the MAC address of the Workstation host and of the Whonix-Gateway.
Install Whonix-Workstation on hardware (NOT RECOMMENDED)
Install Whonix-Workstation on hardware without using a VM is recommended against, because hardware serials would be visible to Whonix-Workstation.
The instructions are very similar, if not the very same, to those in "How To Install Whonix-Gateway on hardware" above. You have to use --tor-workstation instead of --tor-gateway.
Further required reading
Documentation. The host security chapter applies to both computers!
Extra packages for better hardware support
Some packages for bare metal may or may not be missing. Here is a probably incomplete list of packages, which may or may not be useful for better hardware support. Some suggestions.
xorg xserver-xorg-input-all xserver-xorg-input-wacom xserver-xorg-input-geode xserver-xorg-input-vmmouse xserver-xephyr xserver-xorg-input-* xserver-xorg-* acpi-support-base acpid acpi discover discover-modprobe discover-data hwdata mdetect apt-cache show task-desktop apt-cache show task-kde-desktop apt-cache show task-laptop
If you have EFI bios.
To get a more complete list, install Debian (with KDE) on bare metal using the regular Debian installer medium.
- diff "dpkg -l" with Whonix
- diff "sudo lsmod" with Whonix
- contribute your findings
- Slow network speed? Eventually it's the fault of your wifi driver? We had such a report in the forum.
- No connection between Whonix-Gateway and Whonix-Workstation? Could have something to do with Auto-MDIX. We had such a report in the forum.
Footnotes / References
- Just some hints to get started. It is difficult and beyond the scope of Whonix, because you don't have an Ethernet interface. Some (after market) firmwares support USB-host. (You can plug USB devices into your phone, such as an USB ethernet card. For example some rooted android smartphones can install Debian Linux.
- something like OpenWRT
- The other one may be either an Anonymous 3G modem; Anonymous WiFi adapter, another ethernet or wifi connected to your modem/router.
- Theoretically you could use any OS that supports iptables or pf. If you don't want to use Debian you will have to edit the source code. This will be easy for Debian derivatives but much more difficult for *BSD for example. In any case, the choice of OS shouldn't really matter because this system isn't used for anything but running Tor. A cheap plug computer, something like Raspberry Pi or the hardware used by Torouter would be sufficient.
- If you don't connect by wire, you significantly weaken isolation and security. One the Whonix-Workstation were infected, it could jump onto another network and start leaking.
- Any OS can be used. But this is not recommended! If you do anyway, read warning, especially for Windows: Transparent Proxy Leaks.
- From the Download page or build it yourself from source code.
- A generic VM image can neither leak identifying hardware serial numbers nor unique software fingerprints. (e.g. trough software updates).
- This ensures that you get the latest security features and most secure configurations. (Such as stream isolation that protects against Identity correlation through circuit sharing, XChat IRC hardening or Whonix's Protocol-Leak-Protection and Fingerprinting-Protection etc.)
- Debian ISO OpenPGP verification
- The build scripts could be adapted to run on other *NIX systems as well but currently they assume apt-get and grml-debootstrap to be available. You need about 15 GB of free space.
- By build-steps.d/1100_prepare-build-machine.))
- You need git to obtain the source code. Alternatively, you could also download a git tag as an archive using a (torified) browser: https://github.com/Whonix/Whonix/tags
- From https://github.com/adrelanos/Whonix and not from https://github.com/Whonix/Whonix, because only adrelanos/Whonix contains git tags of the testers-only version.
- See Trust.
- Defined as per TUF: Attacks and Weaknesses:
+ true './build-steps.d/1200_create-debian-packages ERROR: Git reports uncommitted changes! ' + true './build-steps.d/1200_create-debian-packages INFO: Running "git status" for your convenience. ' + git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: whonix_build_both # no changes added to commit (use "git add" and/or "git commit -a") + true './build-steps.d/1200_create-debian-packages INFO: Running git "clean --dry-run -d --force --force" for your convenience. ' + git clean --dry-run -d --force --force + true './build-steps.d/1200_create-debian-packages You most likely like to revert debian/control to run: git checkout -- debian/control make clean or if you know what you are doing: git clean --dry-run -d --force --force git reset --hard' + error 'Uncommitted changes! See above!' ./build-steps.d/1200_create-debian-packages: line 109: error: command not found ++ error_handler_general ++ local return_code=127 ++ rm --force /etc/apt/sources.list.d/whonixtestingtemp.list ++ rm --force /etc/apt/apt.conf.d/90whonix-build-confold +++ caller ++ echo ' BASH_COMMAND: error "Uncommitted changes! See above!" return_code: 127 ERROR ./build-steps.d/1200_create-debian-packages: | caller: 109 ./build-steps.d/1200_create-debian-packages ' BASH_COMMAND: error "Uncommitted changes! See above!" return_code: 127 ERROR ./build-steps.d/1200_create-debian-packages: | caller: 109 ./build-steps.d/1200_create-debian-packages ++ exit 1
- Should be really only a very few files. We used variables for eth0 and eth1 wherever possible.
Log in | OpenID | Contact | Impressum | Datenschutz | Haftungsausschluss | Investors | Donate