Provision Whonix VPS (GUI) for Onion Services

Development
1

I’ve been very excited by the progress of the OnionJuggler project’s integration into Whonix, which makes administrating an Onion site accessible to individuals without sys admin experience through a TUI. @Patrick @nyxnor

The question remains - how does this user provision and configure Whonix on a VPS, in order to be able to use OnionJuggler? I have a proposal and would love feedback on the design before getting started. In addition to being useful for individuals lacking sys admin experience, the hope with this project is to also provide greater security by reducing user error through an “infrastructure as code” approach.

Qubes-Whonix or Whonix KVM?

The first question is whether the VPS should use Qubes-Whonix or Whonix KVM. Any recommendations on this are greatly appreciated. Neither option is particularly documented. The following assumes Whonix KVM, based on this comment made in Nov '20:

Can Qubes-Whonix use it as server OS for hosting Tor onion hidden service?

If you mean through a remote server (VPS or root server): currently usability for this is still very lacking at time of writing.

  • SSH into Qubes dom0 is hard
  • no CLI version
  • no documentation on how to use with CLI on a remote server as far as I am aware off

With the work on qubes-remote-support, does this change anything?

The GUI Design Proposal

The User Experience I am looking for is something like this:

  • Prior: use cryptocurrency to anonymously buy a VPS
  • use GUI to provision Debian on the VPS
  • use GUI to distromorph Debian to Kicksecure, then configure Whonix KVM on Kicksecure
  • use GUI to launch the Onion Juggler TUI window
  • use GUI to sync local static website with VPS

I envision a docs website that would guide the user through this process. Perhaps the best way of sharing the proposed design is a description of each envisioned button:

Button #1: Create VPS

‘Create VPS’ links to a documentation website, which provides a step by step guide to provision a Debian VPS at several cloud providers that accept cryptocurrencies, such as:

  • RamNode costs about $5 a month for a server with 1GB of memory and two virtual CPU (vCPU) cores. Only accepts Bitcoin.
  • NiceVPS costs about €14.99 a month for a server with 1GB of memory and one vCPU core. Accepts Monero and Zcash.
  • Cinfu costs about $4.79 a month for a server with 2GB of memory and one vCPU core. Supports Monero and Zcash.
  • PiVPS costs about $14.97 a month for a server with 1GB of memory and one vCPU core. Supports Monero and Zcash.
  • SecureDragon costs about $4.99 a month for a server with 1GB of memory and two vCPU cores. Only accepts Bitcoin.

Ideally this button would actually do the provisioning with a technology like Terraform, though from what I can tell all of the Terraform Providers, which use the cloud provider API, don’t accept cryptocurrencies. All major cloud providers—AWS, Google Cloud, Microsoft Azure, Alibaba, and so on—require a credit card before approving your account. I haven’t looked into this closely.

Button #2: Configure Whonix

‘Configure Whonix’ takes a Debian VPS and uses configuration management technology to arrive at Kicksecure running Whonix via KVM.

I think that Ansible is the right choice for how this is implemented. It is trusted by the Freedom of Press Foundation (see their GitHub, as a new forum member I can’t hyperlink) for configuration management. In my view, the main benefit of Ansible (versus shell scripts) is that it can be ‘idempotent’ - it describes an end state of the system, so no matter how many times the user presses the GUI button, nothing changes if the VPS is already at the desired end state.

From “UNIX and Linux System Administration Handbook”:

The traditional approach to sysadmin automation is an intricate complex of home-grown shell scripts supplemented by ad hoc fire fighting when scripts fail. This scheme works about as well as you might expect. Over time, systems managed in this way usually degenerate into a chaotic wreckage of package versions and configurations that can’t be reliably reproduced. It’s sometimes called the snowflake model of system administration because no two systems are ever alike.

An Ansible Playbook would be maintained which

  • Distromorphs Debian to Kicksecure
  • Configures Whonix KVM as per the Wiki
  • Configures an automated update mechanism
  • Etc.

If Qubes-Whonix was the direction, this button would use Salt rather than Ansible.

The goal is that the user never needs to interact with a CLI in order for the VPS to be properly configured and up to date.

Button #3: Onion Juggler

‘Onion Juggler’ establishes an SSH connection and launches the Onion Juggler TUI in Whonix-Workstation.

Button #4: Sync Static Website

‘Sync Static Website’ will prompt the user for the directory location of the static website, establish an SSH connection, and syncs the local directory with the files served by Onion Juggler on the VPS.

The documentation also provides advice on how the user can create a static website. The most user friendly option is the desktop app Publii, though any Static Site Generator is possible of course.

Button #5: Settings

Any settings that need to be modified can be done in Settings: local SSH key location, local static website directory location, etc.

What do people think of a project like this? Is there a better approach? Any feedback is very appreciated!

2

Do you have development skills to implement this?

Or is this a feature request?

1 Like
3

This account represents a team that has development skills in python GUIs, devops, and Ansible. Before we got started we wanted to float the idea to the community for input.

2 Likes
4

Would very much be interested in a GUI.

With the work on qubes-remote-support, does this change anything?

Will leave this for Adrelanos to answer but Qubes is not prepared to be a server on VPS for example, but can me managed remotely via qubes-remote-support.

Button #1: Create VPS
‘Create VPS’ links to a documentation website, which provides a step by step guide to provision a Debian VPS at several cloud providers that accept cryptocurrencies, such as:

This can only be a doc I believe, it is difficult to find non-KYC VPS and have individual APIs conform build with Terraform for example. But IDK, best to check it.

Button #2: Configure Whonix
‘Configure Whonix’ takes a Debian VPS and uses configuration management technology to arrive at Kicksecure running Whonix via KVM.

This would be cool.

Button #3: Onion Juggler
‘Onion Juggler’ establishes an SSH connection and launches the Onion Juggler TUI in Whonix-Workstation.

The GUI will > Button #2: Configure Whonix but not have GUI for OnionJuggler?
I believe a GUI for OnionJuggler would facilitate a lot the usage, but then would require VNC instead of SSH as X11 forwarding is a security risk. But if it is out of scope of the GUI, then no problem, I continue the TUI.

Button #4: Sync Static Website
‘Sync Static Website’ will prompt the user for the directory location of the static website, establish an SSH connection, and syncs the local directory with the files served by Onion Juggler on the VPS.

This would also be cool. Reload the webserver at the end for the changes to be applied.

All relevant settings can be modified in the GUI, then yes.

Let’s assume onionjuggler.conf is ceteris paribus because there is no need for the user to modify them as they already work, and the end-user is unexperienced, he just needs to setup an onion service. The service name does not matter much, it is just for identification. The ports do matter though, although it is probably gonna be 80 127.0.0.1:80 something to worry about much.

The remaining settings are ssh keys location, ssh config to set the VPS block host, hostname, keys, user, etc. The other settings are local directory and remote directory of static website. Plus maybe some authorization code from the VPS. I’ve never seen a GUI for handling this type of actions, should be interesting. Also an option to see logs from the GUI is very useful, see tor-control-panel for example of actions to be done on this new GUI

5

Before we go too far… May I suggest some very small steps please? Most importantly:
VPS implies virtualization. So the server itself is based on virtualization. I.e. nested virtualization.

Before considering a GUI. Can you run Whonix on a VPS?

If not, maybe this will only be possible on root servers.

But is anonymous registration allowed?
Accept cryptocurrencies is nice but doesn’t necessarily mean anonymous / pseudonymous registration permitted.

Qubes isn’t really designed to be run on a VPS at time of writing since it requires a GUI. There no Qubes CLI version at time of writing.

qubes-remote-support is completed, available but also primarily used with a GUI to remote administrate GUI systems.

6

The list I provided is from the No Starch Press book “How to Hack Like A Ghost” (Ch 1. Becoming Anonymous Online), so are collected with an eye to KYC policies. For the documentation idea, I’m imagining a more extensive list with a walkthrough of anonymously provisioning a VPS for each VPS service we are aware of that is affordable and anonymous. This list would be maintained to reflect changing policies and would have abundant screenshots to make it easy to follow.

If automated provisioning with Terraform isn’t an option anyways, another option provided in the book:

Some services, like BitLaunch, can act as a simple intermediary. BitLaunch accepts Bitcoin payments but then spawns servers on DigitalOcean and Linode using its own account (for three times the price, of course, which is downright outrageous). Another intermediary service with a slightly better deal is bithost, which still takes a 50 percent commission. The trade-off, on top of the obvious rip-off, is neither of these providers gives you access to the DigitalOcean API, which can help automate much of the setup.

I have not actually tried to run Whonix with nested virtualization yet. My understanding is that in the best case scenario, this is inefficient with resources (which I imagine not being a problem to serve a few static websites), and that in a worst case scenario it causes networking and low level processor issues that can be a nightmare to diagnose and resolve.

Unfortunately it seems that renting a bare metal server is prohibitively expensive for the user base I am imagining. For example, at NiceVPS in the list above, the price jumps from €14.99 a month for a VPS to €189.99 a month for a bare metal server.

The following options seem possible to pursue:

1) Whonix KVM on a VPS (nested virtualization)

This could be tested for resource use and any other issues. I worry that issues can be specific to a provider and hard to anticipate, depending on what virtualization technology they are using. If anyone has experience with this, I’d love to hear about it.

2) Whonix-Ws on one VPS and Whonix-Gw on a second VPS

This seems to be the most desirable option to me. We get the benefits of Whonix without nested virtualization for double the price. Networking can be handled by configuration management (Ansible or otherwise).

3) Kicksecure on a VPS

OnionJuggler can be run on Kicksecure, though we lose some of the security benefits of hosting an onion service on Whonix, such as " Even if somebody hacks the hidden server software – such as micro-httpd, nginx, or apache – the attacker cannot steal the onion service key or bypass Tor". It would be half the price of option #2.

4) Whonix KVM on a bare metal server

Definitely possible but prohibitively expensive for many users.

Perhaps several of these options could be possible to deploy depending on the user’s budget and threat model.

Thanks for the info. Qubes Whonix would also not have options to avoid nested virtualization, so for just that reason seems less desirable.

Awesome!

Agreed it warrants investigating. Terraform would especially simplify option #2 above involving two VPS instances.

I’d like to avoid VNC on the remote server if possible. To be clear, I was imagining the GUI being a desktop GUI running on the user’s local machine (Whonix or Tails depending on user preference), not a GUI running on the remote server. This local GUI would SSH into the remote server behind the scenes. So perhaps the OnionJuggler menu could be in the desktop GUI, and also without needing to use VNC - it would simply run the onionjuggler-cli remotely through SSH. I agree that this would improve usability.

I agree with all of your comments re the Settings button.

1 Like
7

I suggest try to get Whonix anything working in the cloud first before we get to far ahead with any implementation details.

Yeah. If the VPS is for example based on OpenVZ, then it may not be possible to run any other virtualizer and the inter-VM network communication. Needs testing.

Whonix by default requires a secure connection between the two VMs, Whonix-Gateway and Whonix-Workstation. That’s a given in the supported virtualizers. When separting Whonix-Gateway and Whonix-Workstation in different cloud accounts it would be unencrypted by default. Encryption is not needed if Whonix is used normally, locally since it stays on the local computer only. Adding encryption / authentication between the two VMs isn’t implemented at time of writing and also not easy. Needs research and development.

Related:

Many root servers don’t cost that much but then probably payment methods don’t offer crypto and/or require KYC. Needs research.

8

For scenario 1. Whonix KVM on a VPS (nested virtualization), could you expand on what testing should cover? I was thinking I would first try a KVM VPS, so KVM in KVM.

For scenario 2. Whonix-Ws on one VPS and Whonix-Gw on a second VPS, I would propose using Nebula:

Nebula is a mutually authenticated peer-to-peer software defined network based on the Noise Protocol Framework. Nebula uses certificates to assert a node’s IP address, name, and membership within user-defined groups. Nebula’s user-defined groups allow for provider agnostic traffic filtering between nodes. Discovery nodes allow individual peers to find each other and optionally use UDP hole punching to establish connections from behind most firewalls or NATs. Users can move data between nodes in any number of cloud service providers, datacenters, and endpoints, without needing to maintain a particular addressing scheme.

Nebula uses Elliptic-curve Diffie-Hellman (ECDH) key exchange and AES-256-GCM in its default configuration.

Nebula was created to provide a mechanism for groups of hosts to communicate securely, even across the internet, while enabling expressive firewall definitions similar in style to cloud security groups.

To see an example configuration for authenticated and end-to-end encrypted channels between VPS instances see the heading " Nebula Setup" at:
blog.malicious.group/automating-c2-infrastructure-with-terraform-nebula-caddy-and-cobalt-strike/

For scenario 4. Whonix KVM on a bare metal server, I will try to poke around for affordable bare metal servers that are also anonymous. A more affordable use case for this scenario is owning the hardware, but that comes with a different risk model for the event of a successful deanonymization attack on the onion service in that it is likely to lead to your identity. However, given that this could be acceptable to some it is almost certainly a scenario to include in deployment options, given that we know that it works well.

9

Not yet the time to be picky. So if anything works whatsoever then that’s great.

Note: I am not a maintainer of Whonix KVM.

1 Like
10

For a KVM VPS, nested virtualization needs to be enabled at the host level of the cloud provider:

https://docs.kernel.org/next/virt/kvm/x86/running-nested-guests.html#enabling-nested-x86

Here is the list of providers from the previous post, but with information on if nested virtualization is supported, and whether they expose an API which can be used by a Terraform Provider:

RamNode

Terraform Provider API:
Openstack
https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs

KVM VPS:
Nested Virtualization supported

NiceVPS

Terraform Provider API:
None.

KVM VPS:
Nested Virtualization supported

Integrity Canary - Bonus:
https://nicevps.net/index/canary

Cinfu

VPS is based on OpenVZ (container not a VM), so nested virtualization is unlikely to work well with a KVM image.

PiVPS

They haven’t gotten back to me yet.

SecureDragon

Their knowledge base says that they do not accept anonymous orders:

https://securedragon.net/clients/index.php?rp=/knowledgebase/205/Why-do-you-not-accept-anonymous-orders-through-proxyorVPN-with-fake-information.html

BitLaunch

Bitlaunch is an intermediary to DigitalOcean, Vultr, and Linode.

Terraform Provider API:
Unofficial (Community)
https://github.com/pathtofiletf/terraform-provider-bitlaunch

There is also a command-line tool:
https://developers.bitlaunch.io/docs/cli-tool-blcli

VPS:
Nested virtualization is not available, despite being available at some of the primary providers such as Digital Ocean

https://www.digitalocean.com/community/questions/does-digitalocean-support-kvm-or-nested-virtulzation

Bithost

Bithost is an intermediary to DigitalOcean, Vultr, Hetzner and Linode.

They haven’t gotten back to me yet.

Conclusions…

Is it worth testing nested virtualization when there are only two confirmed anonymous providers which support it, both warning of performance issues? I’m inclined to think that scenario #2 (two VPS instances , using Nebula) is more promising in being adaptable to all the VPS providers, and scenario 3 & 4 could also warrant automated deployments for different budgets.

Low budget:
3) Kicksecure on a VPS

Medium budget:
2) Whonix-Ws on one VPS and Whonix-Gw on a second VPS

High budget (or owned hardware):
4) Whonix KVM on a bare metal server

11

Since you’re contributing this functionality, I think it’s good to ask here for user feedback but the call is yours.

The connection between Whonix-Workstation and Whonix-Gateway might be hard to secure. Also that would introduce more latency depending on how far away the other server is.

Normally the Tor client as far as I know runs on the same machine. For example there isn’t a long line (internet cable) between Tor Browser and Tor. But there’s certainly a long line from Tor to the Tor exit relay. By running applications on a different IP than Tor (split Whonix-Workstation and Whonix-Gateway on different IPs with a long line in between) might introduce additional lag. Not sure how much that matters.

Also this opens up for new de-anonymization attacks such as website traffic fingerprinting. Sounds strange, I hope this doesn’t get cited out of context but in a scenario where Whonix-Gateway runs on a different far away remote computer than Whonix-Workstation the connection between gateway an workstation isn’t torified.

This might work too but please test. You could even test that locally if you have enough RAM. Set up a VM and then inside that VM run the two Whonix VMs.

That for surely seems the easiest to get something started, a proof of concept, etc.

12

When I built the CI with DigitalOcean, I learned that you can indeed run virtualbox on a debian droplet there, so I imagine it will work on at least some other providers.

Real world performance is unverified. I ran in to issues with the GUI and havent looked in to it since then.

You can reuse lots whatever useful ansible automation for provisioning the VPS if youd like.

1 Like
13

Another consideration…regardless of this VPS effort, it might be worth building a server GUI with onionjuggler so that users can easily set up onion services on a home server

Ansible could automate the host

Ideas:

  • 1 click static site w/ drag and drop
  • 1 click wordpress
  • 1 click discourse
1 Like
14

I have a concern with making onion service hosting on a VPS “one click” to a user with no sys-admin knowledge. I don’t think it’s feasible to guarantee that the onion service is properly configured (accounting for VPS differences, etc.) if the user can’t read logs, error output, doesn’t understand what is happening behind the GUI, etc.

I think where the onionjuggler tool really shines is enabling a sys-admin to follow best practices in onion service configuration. They can use the cli just fine, and the VPS provisioning etc doesn’t need to be abstracted away, which is a tall order. Services like noblogs.org make wordpress blogs accessible to any user, and similar collectives of sys-admins could form to make onion blogs accessible to any user.

@nyxnor Has onionjuggler been tested on kicksecure? Is it conceivable that the bash scripts fail in a way that leads to a misconfiguration which isn’t apparent to the user?

Due to the problems of nested virtualization with whonix in a cloud environment, kicksecure seems to be the way to go on a VPS. You can start with a Debian image, which all VPS providers offer, then distro morph.

@Mycobee I could imagine that ansible would be a good fit for configuring anything on the Kicksecure VPS that is out of scope of onionjuggler (i.e. a way to automate updates, etc).

15

Please move any extended discussion on Kicksecure over to the Kicksecure forums.

You can also contact the onionjuggler project upstream directly.

From perspective of the Whonix forum: onionjuggler in Kicksecure is off-topic. This is to keep things tidy, separated and keep confusion of one project for another very low.

2 Likes