search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
532 stars 46 forks source link

document how to safely use Bitmask #2021

Open mfc opened 8 years ago

mfc commented 8 years ago

Bitmask is a free FOSS VPN client (and encrypted email application). It would be great to document how to use the VPN client in Qubes safely, following this email thread:

https://groups.google.com/d/msg/qubes-users/dUgf68iiN4I/rqVOSnnHJwAJ

adrelanos commented 8 years ago

I can look into bitmask during Whonix 14 development.

ghost commented 8 years ago

I'm able to use Bitmask without any DNS leakage, how did you set it up? As a fail safe, you might want to white-list the IP-address of the VPN server in the firewall settings.

mfc commented 8 years ago

@JasperWeiss can you draft a step-by-step walkthrough on how you set it up? if you want to include fail-safes then that would be doubly-helpful. thanks!

ghost commented 8 years ago

Tests seem to indicate it isn't leaking any DNS queries (they keep running forever) but in theory it is still possible. Bitmask does fail closed so it shouldn't be a problem when the connection drops. The problem is that the VPN VM still allows connections to pass in the clear if Bitmask isn't started yet or if it's disabled.

The way I have it setup is as follows:

I did some testing using ping on an app VM connected to the VPN VM: while Bitmask is running, ping google.com results in:

PING google.com (173.194.65.101) 56(84) bytes of data.
64 bytes from ee-in-f101.1e100.net (173.194.65.101): icmp_seq=1 ttl=45 time=47.3 ms

while Bitmask isn't running, ping google.com results in:

PING google.com (216.58.212.206) 56(84) bytes of data.
From 10.137.3.1 icmp_seq=1 Destination Host Prohibited

So here we can see that DNS queries are in fact leaking even though it can't access the IP address it resolved (Only the VPN service server's IP address is whitelisted). Whether DNS queries are also routed in the clear when Bitmask is running is unclear to me since all dns leak tests keep running forever.

Obviously disabling 'Allow DNS queries' in the Qubes firewall settings will not allow any DNS traffic at all, so that's not very useful. Perhaps there should be an option in the firewall settings to whitelist specific DNS addresses?

adrelanos commented 8 years ago

This is very similar to the issues described in https://github.com/QubesOS/qubes-issues/issues/1941.

@JasperWeiss:

set the sys-firewall VM as it's net-VM. Under the firewall section in the VM's preferences set it to 'Deny network access except...' then add only the ip address of the server.

That would not cover the shared VPN/Tor server leak bug (issue description).

ghost commented 8 years ago

@adrelanos

That would not cover the shared VPN/Tor server leak bug (issue description).

That, and DNS traffic. Which is what I'm a little more worried about. Could it be possible to make the whitelisting/blacklisting of IP adresses apply for DNS traffic, too? Another option would be to only allow traffic from the bitmask client. That would also fix #1941. I'm not sure whether this is possible from outside the VM though.

mfc commented 8 years ago

setup a stand-alone debian based VPN VM

is there a reason it needs to be stand-alone?

Whether DNS queries are also routed in the clear when Bitmask is running is unclear to me since all dns leak tests keep running forever.

https://dnsleaktest.com not work for you?

That would not cover the shared VPN/Tor server leak bug (issue description).

I would argue this is outside the scope of this ticket/issue. The intention is a functional VPN setup, not a VPN-Tor setup, at least for now.

adrelanos commented 8 years ago

Michael Carbone:

That would not cover the shared VPN/Tor server leak bug (issue description). I would argue this is outside the scope of this ticket/issue. The intention is a functional VPN setup, not a VPN-Tor setup, at least for now.

Although the issue description regrettably limited to Tor, the issue itself is not limited to Tor related leaks. In such VPN server / web / advertising server related matches, connections without VPN are possible.

ghost commented 8 years ago

@mfc

is there a reason it needs to be stand-alone?

Yes, since you'll be installing Bitmask on it. You could install it inside the template but that means you've got Bitmask installed on all VM's based on that template which is not what we want.

https://dnsleaktest.com not work for you?

No, the test runs indefinitely without returning any results.

I would argue this is outside the scope of this ticket/issue. The intention is a functional VPN setup, not a VPN-Tor setup, at least for now.

I don't quite agree. The fact that Tor traffic could be send out in the clear rather than being routed through the VPN service means it's leaking; which is precisely what this issue is about.

I'd like to quickly mention this project. It sets a few IP table rules to block all traffic except when it's coming from processes within the 'qvpn' group. It then adds the VPN client to that group. This seems to solve #1941 as well as DNS leakage. Currently I haven't been able to get it to work with Bitmask so perhaps someone could have a look at it. There's one problem with this approach, which is the fact that these firewall policies are enforced from within the VPN VM rather than by the Firewall VM. So I'm wondering if we can detect from which application the traffic originates from outside the VM (E.g, can we make the Firewall VM only allow traffic from Bitmask client on the VPN VM?)

mfc commented 8 years ago

is there a reason it needs to be stand-alone?

Yes, since you'll be installing Bitmask on it. You could install it inside the template but that means you've got Bitmask installed on all VM's based on that template which is not what we want.

if the user wants to create additional Bitmask-based ProxyVMs then installing it in the template makes perfect sense. I think in general the default should be installing applications that are required for a given action, and if you want to mention that the user can create a standalone VM instead that is always a possibility.

https://dnsleaktest.com not work for you?

No, the test runs indefinitely without returning any results.

from both Bitmask ProxyVM and AppVM? hmmm not encouraging for trying to confirm no DNS leaks, and as you mention DNS is leaking. so it sounds like we aren't there yet.

I don't quite agree. The fact that Tor traffic could be send out in the clear rather than being routed through the VPN service means it's leaking; which is precisely what this issue is about.

This issue is about documenting how to use Bitmask to prevent DNS and clearnet leaks which we still haven't figured out. Then running Tor over it and ensuring that if the server is also hosting a Tor entry guard on the same IP address and if your VPN breaks you don't get a leak is a much lower priority. It sounds like we should start with ensuring VPN won't easily break.

If you disagree then maybe the guide should use Whonix-WS with the leak protection additions Patrick recently created.

I'd like to quickly mention this project.

Is there any way to incorporate it into the walkthrough?

sounds like we are still looking for documentation we can put on the website walking the user through setting up Bitmask VPN as a ProxyVM with basic leak protection.

adrelanos commented 8 years ago

Bitmask is not installable from official Debian repository. In such cases, for better security it's advisable to either use a separate TemplateVM, or with perhaps lower overhead, a separate StandaloneVM.

This issue is about documenting how to use Bitmask to prevent DNS and clearnet leaks which we still haven't figured out. Then running Tor over it and ensuring that if the server is also hosting a Tor entry guard on the same IP address and if your VPN breaks you don't get a leak is a much lower priority. It sounds like we should start with ensuring VPN won't easily break.

It's not tied to Tor at all. Nowadays more and more services are hosted in data centers. It does not seem that unlikely to me, that both a VPN provider and an unrelated website oder advertising company is sharing the same IP. This could result in a clearnet leak. We have a highly specialized economy nowadays. Some people provide cloud computing services and call them for example amazon aws. Others specialize in hosting VPNs or advertising tracking services - for that they use might use cloud computing. A match seems not that unlikely too me.

I am wondering how special this ticket is. I mean, how different is Bitmask from OpenVPN. Since Bitmask is based on OpenVPN... It could very well be the case that anything done in https://github.com/QubesOS/qubes-issues/issues/1941 or documented under https://www.qubes-os.org/doc/vpn/ "only needs OpenVPN -> OpenVPN / Bitmask".

mfc commented 8 years ago

Bitmask is not installable from official Debian repository. In such cases, for better security it's advisable to either use a separate TemplateVM, or with perhaps lower overhead, a separate StandaloneVM.

ah yes that makes perfect sense.

I am wondering how special this ticket is. I mean, how different is Bitmask from OpenVPN.

I have no problem setting up OpenVPN in a ProxyVM using the Network Manager so that it doesn't leak DNS. I think Bitmask is special case since it's non-Debian repo deb, etc. So it sounds like it requires particular documentation/tweaks in order to use correctly that is not necessarily related to OpenVPN ProxyVMs in general.

tasket commented 8 years ago

I'd recommend following this progression:

  1. test bitmask in a plain proxyvm first
  2. manually add the dns dnat firewall rules, see if downstream can do dns lookups 2a. try using a script for dnat, like the one in vpn doc
  3. check whether bitmask tries to alter iptables, and asses whether they use forward-blocking 3a. if not, manually add the two -i FORWARD -j DROP firewall rules for eth0
  4. find a way to run bitmask as specific group and add rest of rules from vpn doc

@JasperWeiss Numbers 1-3a are of primary importance. Number 4 is secondary as it protects against access initiated from the inside of the vpn vm.

Applying firewall rules internally is a good idea because of the detailed traffic information in that firewall, and because a dedicated vpn vm should be generally trusted anyway. If its untrusted (which doesn't make much sense) and you're filtering upstream, the vpn client could still send packets with sensitive info to whichever address you're allowing, and this could be intercepted by a hostile router or ISP (or sys-net).

adrelanos commented 8 years ago

repository issues https://github.com/leapcode/bitmask_client/issues/1007

bitmask does not start https://github.com/leapcode/bitmask_client/issues/1008

adrelanos commented 8 years ago

connect to Tor before bitmask (User -> Tor -> bitmask -> Internet) broken https://github.com/leapcode/bitmask_client/issues/1009

adrelanos commented 8 years ago

bitmask shared VPN/Tor server leak bug? https://github.com/leapcode/bitmask_client/issues/1010

adrelanos commented 8 years ago

As per https://github.com/leapcode/bitmask_client/issues/1009#issuecomment-234293666 connect to Tor before bitmask (User -> Tor -> bitmask -> Internet) will not be possible soon.

We want to fix it but right now our focus is in email and VPN is in maintenance mode. Not sure when will a leap developer have time to fix this. But patches are welcome ;P

adrelanos commented 7 years ago

vpnprocess.py error https://github.com/leapcode/bitmask_client/issues/1020

iuriguilherme commented 7 years ago

My attempt, step by step

  1. Cloned debian-8 TemplateVM and named it debian-8-bitmask;
  2. Followed bitmask install instructions for jessie in debian-8-bitmask TemplateVM, shutting it down after all has been done;
  3. [cosmetic] Ran qvm-sync-appmenus debian-8-bitmask to have the Bitmask XFCE menu entry in the ProxyVMs which will use that TemplateVM;
  4. Created a sys-bitmask ProxyVM as the qubes and the whonix instructions told me;
  5. Set sys-bitmask NetVM to sys-net;
  6. [opinion] Opened Bitmask software inside sys-bitmask and registered for Calyx, since Riseup and Oblivia are down and Codigosur is not accepting bitcoin as of today;
  7. Created an AppVM temp-bitmask with sys-bitmask as its NetVM and fedora-24 as TemplateVM; 7.1. I opened suggested website https://dnsleaktest.com in Firefox inside temp-bitmask. IP shown at the main page was the advertised in the bitmask client, however in both tests (simple and extended), the wheels were spinning forever. Probably Jeremy Campbell is using a free Google Static Maps API and he reached a limit; 7.2. I used other services, and the two that worked showed that I was leaking at least on DNS server which is hardcoded in my router: https://www.perfect-privacy.com/dns-leaktest/ and https://dns-leak.com/ Update: I got other dns test websites working, but haven't tested all setups.;
  8. I changed sys-bitmask NetVM to sys-whonix, and the bitmask client couldn't connect anymore. The dns leak test websites through temp-bitmask reported a tor exit node ip address (all the same), and no DNS leaks;
  9. I changed sys-bitmask NetVM to sys-firewall, the bitmask client connected again. The dns leak test websites through temp-bitmask reported the vpn ip address, and again at least one DNS leak Update: I found out that this didn't make any sense. I've set sys-firewall's NetVM to sys-whonix, and temp-bitmask's NetVM to sys-firewall instead. The below map is updated;
  10. I changed temp-bitmask NetVM to sys-whonix. The dns leak test websites through temp-bitmask reported a tor exit node ip address (all the same), and no DNS leaks;
  11. I changed sys-whonix NetVM to sys-bitmask, which caused Qubes Manager to crash. NetVM didn't change. I then shut down sys-whonix, successfully changed NetVM to sys-bitmask and started it again.

To refresh, I have now the following setup:

internet \/ sys-net (NetVM)
\/ sys-bitmask (ProxyVM) \/ sys-whonix (ProxyVM)

\/ sys-firewall (ProxyVM) || \/ temp-bitmask (AppVM)

The dns leak test websites https://www.perfect-privacy.com/dns-leaktest/ and https://dns-leak.com/ opened in Firefox inside temp-bitmask reported a tor exit node ip address (all the same), and no DNS leaks. The Bitmask client running inside sys-bitmask is reporting activity.

One thing that should be noted is that the external ip address reported to the dns leak test websites is always the same. So:

  1. I changed temp-bitmask's TemplateVM from fedora-24 to whonix-ws and ran torbrowser. The rest of the setup remains the same. Now every dns leak test website has a different ip, and no dns leaks.

Conclusion

sys-net > sys-firewall > Bitmask VPN ProxyVM > Whonix Gateway ProxyVM > Whonix Workstation AppVM is what Works For Me (tm). This comment is being sent from Tor Browser in a Whonix DispVM with that setup. I haven't tried to rob a bank yet to see if it really works, though.

Notes

If by using Bitmask on its own without Whonix I am leaking DNS, then I'm leaking DNS to the Tor exit node, even though I'm not leaking to the final destination. If that's not true, then please correct me.

I've tried messing with the networking at sys-net, and it seems that bitmask works in the "fail close" pattern. If I deliberately "turn off" Bitmask, then the sys-bitmask ProxyVM allows traffic to flow normally. While this could be intended behavior if you were running Bitmask in a regular desktop OS, in the case of Qubes, if I wanted to turn off bitmask, I'd change my AppVM's NetVM instead. So I expect that if I'm using sys-bitmask as NetVM, then it will enforce its use.

Bitmask seems to start when the sys-bitmask ProxyVM is started, out of the box. And it sits in the notification area, so saving the login and password in the client provides a Just Works (tm) way to automatically tunnel all traffic in the VPN service, along with the regular Qubes scripts to start all other necessary VMs.

An important thing that should be noted is that by doing these tests, I've broke the Paranoid Rules (tm) and successfully, irrevocably recorded forever in ECHELON's database all tied up my Tor routes, my Calyx VPN IP and my real world DNS. So now, no one will ever have to do it again. You're welcome.

Another important thing is that I'm relying on the Perfect-Privacy dns leak service. I couldn't find another which was working for me, and as of right now I haven't enough knowledge to pull up my own dns leak test service. Update: I got these to work too:

Not relevant or related, but the WebRTC test, also this one in a non Tor Browser (regular Firefox) leaks the AppVM internal IP address. Not that we all didn't know about that anyway.

Now I will go through the qubes and the whonix instructions to make sure everything is set the Proper Way (tm).

tasket commented 6 years ago

@desci The next bitmask release will automatically enable anti-leak fw rules tailored for Qubes proxyVMs. However, their main app pre-release isn't stable yet so I have only been able to get it to run manually from their bundled package. There is a thread in leap-discuss list covering this issue.

mfc commented 3 years ago

I was going to close this since it's old and not recently updated but apparently it is still a recent issue tracked on the LEAP side (Bitmask, Riseup VPN, Calyx VPN, all are same codebase):