Actions

Dev/Qubes Remote Support

From Whonix

< Dev

QubesOS to be remotely manageable from on-demand, ephemeral, hidden onion service to dom0/AdminVM.

challenges[edit]

  • There are no Open Source remote support tools which are usable by laymen.
    • There is teamviewer but it's proprietary and therefore the teamviewer company could take over any users who use it.
  • The existing Open Source tools do not account for that most users nowadays are behind common NAT routers which make it hard to receive unsolicited incoming connections, i.e. hard to run servers. Would require port forwardings which are difficult for users. The internet is full of users seeking help how and failing to create port forwardings. Users are also often on networks (3/4G) that do not even support incoming (server) connections.
  • Even if some remote support instructions use Open Source software and work on Linux, these won't work easily in Qubes dom0 since non-networked by default.
  • Most if not all existing remote support Open Source software does not use encryption by default.
    • Therefore any man-in-the-middle could take over the connection and compromise the remote support receiver.
      • It's possible to run VNC over encrypted/authenticated SSH but this is not something which laymen users that need remote support are capable to use.

goals[edit]

  • functional for users with reasonable slow internet connections
  • reasonable security
  • Open Source
  • work behind NAT

desired security properties[edit]

  • encrypted
  • authenticated
  • clear and reliable signaling to the user whether remote admin is enabled and whether it is currently in use
  • Even after sys-whonix compromise the attacker should not be able to access dom0 through VNC.

implementation[edit]

  • Command line tools (which can be called by any GUI).
  • Whonix-Workstation script. (GUI and command line tools would run here.)
  • Whonix-Gateway script. (Tor onion service)
  • dom0 package (Qubes dom0 configuration, SSH/VNC server)
  • Packaging of a (python) GUI [1] (the GUI itself to be written by Marek)

sys-whonix GUI[edit]

able to see already existing hidden services per sys-whonix in a widget.

Adding remote support thought requirements:

  • List configured onion services.
  • Delete them.
  • Create new remote support related hidden onion service. When done, output onion address, port and shared secret for the user to copy paste to chosen secured communication channel.
  • create time based or persistent remote support
  • multiple remote support onions at the same time remove?
  • optionally a feature to send access info to the support agent from the GUI

Missing parts[edit]

Avoidable?

  • Qubes dom0 salt
  • Qubes dom0 GUI

Idea[edit]

general[edit]

  • x2go supports SSH.
    • (Needless to say that SSH or any extra encryption complicates things.)
    • TODO: test if x2go can work in acceptable speed over a Tor onion. FreeNX (maybe outdated), SPICE, x2go... x2go [in packages.debian.org: yes] seems most promising.
  • Run an SSH server in dom0.
  • magic-wormhole?
    • [in packages.debian.org: yes]
    • (File_Sharing#Magic-Wormhole)
    • These code words are quite usable. Example: 7-crossover-clockwork We'd need two of these.

questions:

  • SSH server running in dom0 is OK?
  • I guess running VNC (and perhaps SSH) in dom0 is OK?
  • Things can always be more compartmentalized, secure but also getting more and more complicated, fragile.

I am considering to script this entirely from dom0 using `qvm-run`. Only expectation: installed (use salt?) and non-broken sys-whonix

Draft Concept[edit]

remote support provider[edit]

On remote support provider machine.

  • dom0 qvm-start sys-whonix
  • dom0 qvm-run sys-whonix create .onion service config file in /usr/local/etc/torrc.d/40_remote_support.conf
  • dom0 qvm-run sys-whonix reload Tor
  • dom0 qvm-start remote-support-provider-server-vm
  • dom0 qvm-run remote-support-provider-server-vm install openssh-server
  • make openssh-server reachable through .onion running in sys-whonix
  • dom0 wormhole send connection.zip
    • write wormhole code into script variable
  • connection.zip contains
    • .onion hostname of remote support provider
    • ~/.ssh/known_hosts
    • .auth_private file (private key) for authenticated Tor onion service
    • ssh key
  • tell remote support receiver out of band (telephone, chat, e-mail) the wormhole code
  • wait for remote support receiver to start the remote support receiver tool and to enter the wormhole code
  • in remote-support-provider-server-vm: x2go connect to remote support receiver localhost:port [reverse ssh]

remote support receiver[edit]

On remote support receiver machine.

  • dom0 sudo dnf install x2go-server
  • dom0 qvm-start sys-whonix
  • dom0 wormhole receive connection.zip
    • Must be done in dom0. Not sys-whonix. Because goal is sys-whonix to be untrusted.
  • dom0 install ~/.ssh/known_hosts
  • dom0 qvm-run sys-whonix install .auth_private file (private key)
    • sudo sourcefile=~/user.auth_private anon-server-to-client-install (adjust path)
  • dom0 qvm-run sys-whonix test connection to .onion
  • dom0 test connection to .onion
  • dom0 reverse ssh connect to remote support provider .onion
  • There is now an open port on remote support receiver machine over ssh and over .onion available to remote support provider.

qubes-remote-support-provider-gui[edit]

Not needed. Remote support provider can use CLI tools for connection setup. Would be encapsulated into a simple CLI call and telling the remote support receiver the wormhole code. Once the remote support receiver connected to the remote support provider (reverse SSH), the remote support provider can use a $VNC viewer (which is graphical) to connect.)

notes[edit]

  • Can use two wormhole codes if not avoidable.
  • Automatically re-connect if reverse SSH is down.

ssh keys[edit]

challenges:

  • Have to manage file /root/.ssh/authorized_keys using scripts.
    • Use secure, long, script generated passwords instead?

send access into to gpg agent[edit]

> optionally a feature to send access info to the support agent from the GUI (for example GPG encrypted email)

Patrick said: I would discourage that. Challanges:

  • calling e-mail / gpg from command line
  • calling e-mail / gpg from dom0 or adminVM?

Preliminary Work Done[edit]

See also[edit]