search

flamusdiu / python-pia

Commandline tool to auto configure PIA services
42 stars 9 forks source link

DNS Leaks for all connections #13

Closed markubiak closed 7 years ago

markubiak commented 8 years ago

Using the default configuration, openvpn may use DNS servers that are not protected by the VPN, causing these DNS providers to possibly snoop on which sites you're browsing. Openvpn can mitigate this by adding the line "block-outside-dns" to the end of every file in /etc/openvpn/*.conf. This fixes the DNS leak and ensures nobody can snoop on you. You can test the leak and the fix using http://dnsleaktest.com

EDIT: This fix does not seem to work. I'm exploring other options. Will update.

maximbaz commented 8 years ago

@markubiak in case you are interested, this is how I solve the issue (with NetworkManager):

#!/bin/bash
#/etc/NetworkManager/dispatcher.d/pia-vpn

interface="$1"
status=$2

case $status in
  vpn-up)
    if [[ $interface == "tun0" ]]; then
      chattr -i /etc/resolv.conf
      echo -e "nameserver 209.222.18.222\nnameserver 209.222.18.218" > /etc/resolv.conf
      chattr +i /etc/resolv.conf
    fi
    ;;
  vpn-down)
    if [[ $interface == "tun0" ]]; then
      chattr -i /etc/resolv.conf
    fi
    ;;
esac

In other words, as long as VPN is connected, the /etc/resolv.conf contains only PIA DNS servers and is made readonly to naively protect the file from being overwritten. A bit hacky, but works well.

markubiak commented 8 years ago

Huh, that chmod stuff is some bash black magic. I'm gonna go do research on why that works. It completely fixed DNS leaks for me though. Thank you! I'm leaving this issue open as it really should be mitigated.

flamusdiu commented 8 years ago

I will have to look more into this.

@markubiak considering most scripts/changes would probably not change the attrib on the file from RO, it stands to reason that setting it to RO would mitigate some other application changing the DNS settings.

flamusdiu commented 8 years ago

I wonder if it has something to do how https://github.com/masterkorp/openvpn-update-resolv-conf works. I'll have to look at this when I get back to my Linux box.

flamusdiu commented 8 years ago

Running openvpn directly doesn't appear to leak DNS. I have been using Connman though I have some issue with it not setting up the VPN properly.

flamusdiu commented 7 years ago

Connecting through the Japan end point. The DNS leak test shows fine:

screenshot_2016-09-17_22-40-25

OpenVPN Config

client
dev tun
proto udp
remote japan.privateinternetaccess.com 1197
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-256-cbc
auth sha256
tls-client
remote-cert-tls server
auth-user-pass /etc/private-internet-access/login.conf
comp-lzo
verb 1
reneg-sec 0
crl-verify /etc/openvpn/crl.rsa.4096.pem
ca /etc/openvpn/ca.rsa.4096.crt
disable-occ
auth-nocache
script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

Conman Config

[global]
Name = Japan
Description = OpenVPN configuration

[provider_openvpn]
Type = OpenVPN
Name = Japan_VPN
Host = japan.privateinternetaccess.com
Domain = privateinternetaccess.com
OpenVPN.Port = 1197
OpenVPN.CACert = /etc/openvpn/ca.rsa.4096.crt
OpenVPN.CompLZO = yes
OpenVPN.RemoteCertTls = server
OpenVPN.AuthNoCache = 0
OpenVPN.ConfigFile = /etc/openvpn/Japan.conf
OpenVPN.Cipher = aes-256-cbc
OpenVPN.Auth = sha256
maximbaz commented 7 years ago

I can actually confirm that DNS is not leaking anymore, neither on "normal" nor on "strong" configurations (tested with NM). The hack I posted earlier is not required anymore.

I imagine the issue was somewhere else (perhaps in PIA's configs or in update-resolv-conf), and now it got fixed.

flamusdiu commented 7 years ago

@maximbaz okay, then I'll close this. =D

maximbaz commented 7 years ago

I have just been able to observe the leak. Interestingly enough, when I re-run the same test, the leak is gone!

I think this is what happens. Without any extra hacks, the /etc/resolv.conf looks like this:

# Generated by resolvconf
nameserver 209.222.18.222
nameserver 209.222.18.218
nameserver 192.168.1.1

Which means, whenever possible PIA's DNS take priority. But if for some reason those servers are unable to resolve an address, my provider's DNS kicks in and therefore leaks the location.

It's not reproducing 100% of the time, and I'm not exactly sure why. But in my mind inconsistent DNS leak is even worse than permanent leak, because you never know when it happened.

I'm returning back to using the hack that I posted earlier.

These are the websites which were able to detect the leak when the site was loaded for the first time: http://dnsleak.com/ https://whoer.net/

flamusdiu commented 7 years ago

well shoot... I will look at it.

maximbaz commented 7 years ago

I'm not sure though that the changes needs to be done in this project.

We need to investigate why the line nameserver 192.168.1.1 appears in the /etc/resolv.conf. Who is putting it there and why? Is it because of PIA's config? Is it because of the update-resolv-conf.sh?

flamusdiu commented 7 years ago

exactly... I will look in a bit

flamusdiu commented 7 years ago

@maximbaz what doe /etc/resolv.conf show before you activate the VPN? Are you using systemd?

Mine:

# Generated by Connection Manager
nameserver 127.0.0.1
nameserver ::1⏎
maximbaz commented 7 years ago

This is the contents of the /etc/resolv.conf immediately after the system boot:

# Generated by resolvconf
nameserver 192.168.1.1

I don't know exactly what is the process behind generating it. I think I use systemd (I manage services using systemctl tool, which is the part of systemd, right?).

I use router, and 192.168.1.1 is the address of the router.

flamusdiu commented 7 years ago

yes, it's managed by systemclt.

flamusdiu commented 7 years ago

Can you do a systemctl list-units | grep enabled? Post the results.

maximbaz commented 7 years ago

No matches.

Maybe let's switch to a chat, @flamusdiu? Let's try this one for example: https://niltalk.com/r/qwilX Password: 12345

flamusdiu commented 7 years ago

that's odd ... it's always best to catch me on G+/HO -> https://bit.ly/AzuleOnyx

flamusdiu commented 7 years ago

@maximbaz Is this still happening? I haven't noticed it on my end, yet. =(

maximbaz commented 7 years ago

Yep, still happens. Try this website again, it constantly shows the leak for me: https://whoer.net/

flamusdiu commented 7 years ago

Yeah, I dislike that page. I feel it's pushing FUD.

1) It's shows "safe" or "None" as green. This honestly would cause people to think they are "fine" without VPNs.

2) I get 40% even after I disabled Flash. How the hell do I get the same score? Oh wait, they are using some "formula" which I have really no access to which changes the values.

3) Who the heck would change system times to match their VPN end point?

4) Apparently, a mid range hit for "knowing" you are using a VPN. Seriously? For most people this is even an issue.

5) No documentation on what their recommended fix for some of them. My biggest hit? IP Address is different. Probably something do with the VPN configuration. If you are providing this service, shouldn't you research and give information on how to fix the flaws you are talking about?

DNS appears to be fine for me here.

maximbaz commented 7 years ago

Agree on all points, the website is obscure, however it does show me a leak, and that's why I suggested it :)

As soon as I disable my "fix" mentioned above, in this column I begin to see my own country:

image

When the "fix" is enabled, as you can see, the DNS IP address matches my own IP address.

flamusdiu commented 7 years ago 
~> cat /etc/resolv.conf 
# Generated by Connection Manager
nameserver 127.0.0.1
nameserver ::1

Here's mine. very odd.

maximbaz commented 7 years ago

FYI, I cannot set nameservers to localhost as you have in your /etc/resolv.conf. If I do that, nothing gets resolved. I have to set some remote IP address, let it be PIA or something else.

Is it possible that you have some kind of a DNS resolver service running locally? Or how does that work in your case?

But I don't know, maybe the problem is with NetworkManager ¯\_(ツ)_/¯

I'm perfectly fine using the workaround, so it's up to you @flamusdiu, if you want, close the issue as "Won't fix", or make the workaround be installed as a part of python-pia, or we keep investigating further.

flamusdiu commented 7 years ago

Maybe it has to do with the diff between ConnMan and NM?

flamusdiu commented 7 years ago

I don't know; I may play with it some more. I might have to do a clean install just with NM (maybe using Gnome DE or something) and see if it happens. ¯_(ツ)_/¯

flamusdiu commented 7 years ago

@maximbaz are you running systemd-resolved?

flamusdiu commented 7 years ago

Looks like it keeps using 8.8.8.8 and not my local DNS server. grr.

Also, see this -> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1449001

maximbaz commented 7 years ago

are you running systemd-resolved?

Apparently I do not, so that's how your localhost entries do resolve hosts for you. Good to know!

I think there's something (NetworkManager itself?) that adds extra records to /etc/resolv.conf and that causes the leak. If we know a way to ensure that no extra entries are added, that would be the fix. Until then, a workaround is doing this for us.

Also good point is that systemd-resolved also falls back to 8.8.8.8, it's not cool, though I think not as vulnerable as using DNS of your own internet provider, which when is known basically tells your location pretty accurately.

flamusdiu commented 7 years ago

Yes, just it's not using my local DNS for some dam reason. I just noticed this. Though, i don't mind them using it; It for the love of something holy, shouldn't be forcing configuring. I expect it to fail -- this isn't windows or ubuntu -- when things are not configured right. Not some blind work around.

flamusdiu commented 7 years ago

NM automatically changes /etc/resolv.conf if you don't tell it not to do that. Though, seems, NM without systemd-resolv (or maybe even with it) using dispatch scripts to mod the DNS entries.

maximbaz commented 7 years ago

FYI: this bug is also tracked in https://github.com/masterkorp/openvpn-update-resolv-conf/issues/14, however it is also closed there with a conclusion that it is probably NetworkManager that is doing all the trouble.