VPN on whonix workstation

Support
1

Hi everyone,

Can anyone tell me how to get airvpn working on whonix workstation? I’m completely stuck and airvpn support haven’t been able to help me so far.

It would be awesome if people could use a vpn on whonix workstation.

Thanks

2

Combining Tunnels with Tor

Connecting to a VPN before Tor

Connecting to Tor before a VPN

Whonix versus Proxies - Whonix

VPN Tunnel Setup Examples

Advanced Security Guide - Whonix

1 Like
3

AirVPN should work on the Workstation with the Eddie client. Make sure of the following stuff though:

  • Eddie version must be debian 32 bits
  • Network lock should not be activated
  • Connection to the VPN is through TCP only (Tor does not support UDP): go to Preferences, chose Protocols, and TCP 443. You could also try SSH I think (?)
  • In Preferences/Advanced, disable the “Check if the tunnel works” option
  • Maybe also disable the “Check AirVPN DNS” option in Preferences/DNS
4

Thanks for the replies - I’ve downloaded the debian 32 bits version but there’s no way of opening up any executable file in order to run the program. is there code that I need to input?

5

No idea. However, Whonix places no artificial restrictions on that.

Does it work on Debian as per Free Support for Whonix ™?

6

You must use the dpkg command:

open a terminal (konsole) and go to the directory where you downloaded the eddie file, example Downloads:

cd Downloads

then type

sudo dpkg -i eddie-ui_2.13.6_linux_x86_debian.deb

it will say something that the installation failed. It is normal, you must install the dependencies (openvpn stuff):

sudo apt-get install -f

once it is done, retype

sudo dpkg -i eddie-ui_2.13.6_linux_x86_debian.deb

now the installation should be successfull. You can launch airvpn with the terminal:

airvpn

or by searching in the KDE menu:

snapshot3
snapshot3.png297×534 13.6 KB

2 Likes
7

The only caveat with this approach is you trust “Eddie” running on your Whonix system with probably a shitload of privileges.

No doubt also increasing the attack surface.

This is why implementation examples of VPNs have manual set up in configs, as opposed to blindly trusting “Eddie” and the capability of AirVPN contracted programmers.

2 Likes
8

AirVPN can also be run on the command line with openvpn conf files. Probably better security-wise…

2 Likes
9

Buddy, I think its a problem of your vpn because I am using hma VPN on whonix workstation and it is working awesome.

10

Hi everyone - I’ve been away for a bit but I tried onions_knights’ instructions and they worked! it seems it was just a dpkg command that was needed.

But I agree with the privacy concerns voiced regarding eddie, so would the installation instructions for the command line version be very different?

thanks again

11

You can use openvpn config files with AirVPN. They still need sudo privileges to be run, so I am not sure how it would make a difference security-wise? (I know I wrote quite the contrary three weeks ago, but after reflecting on it I don’t see the difference, maybe someone more knowledgeable could explain?)

12

It’s referenced in the wiki somewhere, but I couldn’t find it. But this looks at security risks of the whole sudo idea in Linux (obviously running everything as root is even worse):

http://dmitry.khlebnikov.net/2015/07/should-we-use-sudo-for-day-to-day.html

I like this (long) example:

What is the problem with the ‘sudo’ approach?

Well, there are several in fact. The most pressing issue is that the usage of ‘sudo’ (or ‘su’, or any other utility that has its SUID bit set) is crossing the security boundary from the less privileged account to the more privileged account. This open doors (or, widens the attack surface) to privilege escalation techniques. In plain English it makes the non-privileged account to be essentially equal to the privileged one, let me explain by a fairly simple example:

  • imagine if you are a developer and you work on the server under your non-privileged account;
  • as part of your daily routine you need to download some third party package and install it (we are going to leave out all the security complexities involved with such an activity like verifying signatures, using a separate instance to prepare a package for deployment, etc.);
  • the installation of the package usually requires executing some third party code under your non-privileged account. This code was not written by you and there is a high chance that you did not read/verify the foreign code line by line in order to ensure that it does not do anything malicious since this would be quite time consuming, would require a lot of effort, and your team has more important priorities than this (remember, this is an example based on situations you would encounter in the real world, which is by no means perfect);
  • it happens, that that particular third party was compromised and some malicious code has been injected into the package installation routines;
  • after the execution of the installation routine (and the malicious code for that matter) your ~/.bashrc (for example) is modified in such a way that each time you login it starts up a key logger or some other kind of remotely controllable piece of software that talks back to its master;

So far we just got an issue localised to this non-privileged account only (with a possibility to spread across the entire fleet of servers that non-privileged account has access to in case of the NFS mounted home directories). Is this bad? Yes, it is since it may disrupt this particular project, steal reachable sensitive information, could be used as a trampoline to jump start further research and exploitation of other vulnerable resources. Is it critically bad? Not necessarily. If the systems are built properly with host-based security in mind, if the proper privilege separation techniques are used throughput the company infrastructure, etc. the impact is localised and with proper monitoring systems it would be detected eventually and investigated (keep in mind that it is really hard for a non-privileged account to hide their activities from more privileged processes).

Now, let’s add ‘sudo’ to the mix, e.g. suddenly the developer decided to install an additional library package into the system. So, what would happen next? You guessed it: the developer would need to type in their password to convince ‘sudo’ that they are “allowed” to do such a privileged thing as installing a system package, the malicious software installed by the attacker would happily intercept that and sent it back to its master.

From this point on, the attacker has the account password of the account where their software runs and which they control. The attacker can now utilise ‘sudo’ powers at their will. The security impact would be ranging from “high” to “extreme” depending on how committed the attacker are.

Following the logic, why would we want to introduce an additional complexity that does not address the issue it was supposed to address, this is “to limit exposure of the root account”?

2 Likes
13

Thanks, very instructive.