Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNS Leaks for all connections #13

Closed
markubiak opened this issue Aug 8, 2016 · 32 comments
Closed

DNS Leaks for all connections #13

markubiak opened this issue Aug 8, 2016 · 32 comments

Comments

@markubiak
Copy link

markubiak commented Aug 8, 2016

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
Copy link

maximbaz commented Aug 16, 2016

@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
Copy link
Author

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
Copy link
Owner

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
Copy link
Owner

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 flamusdiu added the bug label Sep 18, 2016
@flamusdiu
Copy link
Owner

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
Copy link
Owner

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
Copy link

maximbaz commented Sep 25, 2016

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
Copy link
Owner

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

@maximbaz
Copy link

maximbaz commented Sep 25, 2016

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
Copy link
Owner

well shoot... I will look at it.

@flamusdiu flamusdiu reopened this Sep 25, 2016
@maximbaz
Copy link

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
Copy link
Owner

exactly... I will look in a bit

@flamusdiu
Copy link
Owner

@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
Copy link

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
Copy link
Owner

yes, it's managed by systemclt.

@flamusdiu
Copy link
Owner

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

@maximbaz
Copy link

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
Copy link
Owner

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

@flamusdiu
Copy link
Owner

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

@maximbaz
Copy link

maximbaz commented Jan 1, 2017

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

@flamusdiu
Copy link
Owner

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
Copy link

maximbaz commented Jan 2, 2017

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
Copy link
Owner

~> cat /etc/resolv.conf 
# Generated by Connection Manager
nameserver 127.0.0.1
nameserver ::1

Here's mine. very odd.

@maximbaz
Copy link

maximbaz commented Jan 3, 2017

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
Copy link
Owner

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

@flamusdiu
Copy link
Owner

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
Copy link
Owner

@maximbaz are you running systemd-resolved?

@flamusdiu
Copy link
Owner

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
Copy link

maximbaz commented Jan 3, 2017

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
Copy link
Owner

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
Copy link
Owner

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
Copy link

maximbaz commented Jan 3, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants