Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ
Ξ We've updated our CA certificate. All members need to be using the latest ones by Dec 22. See this page for more infoΞ

[DNS] Domains Not Resolving On Certain Exit Nodes

Looking for assistance with a cryptostorm connection issue? Post here & we'll help out. Also: if you're not sure where to post, do so here & we'll move things around as needed. Also: for quickest support, email our oddly calm & easygoing support reps at support@cryptostorm.is :)
User avatar

Topic Author
parityboy
Site Admin
Posts: 1220
Joined: Wed Feb 05, 2014 3:47 am

[DNS] Domains Not Resolving On Certain Exit Nodes

Postby parityboy » Sat Mar 17, 2018 6:28 pm

I have noticed that certain exit nodes are guilty of not resolving domains that other exit nodes will happily resolve and return an IP address for, so I thought it would be a good idea to collate them in a single thread.

Anyway, here's a start.

gleam.io fails to resolve on England exit node, resolves on Frankfurt.


wpaschukat
Posts: 16
Joined: Sun Mar 22, 2015 3:25 am

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby wpaschukat » Wed Mar 21, 2018 7:51 pm

Same for Italy (Milan) for mycliplister.com (apparently asset server for multiple shops), is happily resolved in Germany (Dusseldorf).


hollyguild

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby hollyguild » Mon Apr 09, 2018 4:54 am

I've noticed this as well on Canadaeast, however I'm not sure how to tell which server it is exactly. It's not all of them.

User avatar

df
Site Admin
Posts: 322
Joined: Thu Jan 01, 1970 5:00 am

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby df » Wed May 23, 2018 10:58 pm

This is due to the TrackerSmacker DNS-based anti-invasive/malicious ads/tracking that's running on about half of the DeepDNS servers.
The ones that have TS enabled are using https://github.com/notracking/hosts-blocklists
If a legitimate or popular enough site ends up in that list, we can add an exclusion if anyone needs it.

Here's a quick/messy one-liner that shows the current list of servers that have it enabled:

[root@b ~]# for x in `host public.deepdns.net|grep addr|awk '{print $NF}'`;do check=`host test.com $x 2>&1|grep " has "`;if [[ $check = *"0.0.0.0"* ]];then echo "$x has TS enabled"; else echo "$x does NOT have TS enabled";fi;done
5.133.8.187 has TS enabled
212.129.46.32 has TS enabled
212.129.46.86 does NOT have TS enabled
173.208.95.75 has TS enabled
5.101.149.3 has TS enabled
5.254.96.195 has TS enabled
173.234.159.235 has TS enabled
198.7.58.227 has TS enabled
185.212.169.139 has TS enabled
185.60.147.77 does NOT have TS enabled
213.163.64.208 has TS enabled
185.94.193.234 has TS enabled
209.58.147.36 has TS enabled
108.62.19.131 does NOT have TS enabled
167.114.84.132 has TS enabled
80.233.134.52 has TS enabled
89.163.214.174 does NOT have TS enabled
212.83.175.31 has TS enabled
104.238.195.139 has TS enabled
162.221.207.228 has TS enabled
185.107.80.84 has TS enabled
109.71.42.228 has TS enabled
185.117.118.20 has TS enabled
173.234.56.115 has TS enabled
64.120.5.251 has TS enabled
84.16.240.43 does NOT have TS enabled

One of these days I'll figure out a decent way to make TS optional on all servers, but I haven't figured out a reliable method yet.

User avatar

Topic Author
parityboy
Site Admin
Posts: 1220
Joined: Wed Feb 05, 2014 3:47 am

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby parityboy » Fri May 25, 2018 5:58 pm

@df

I think this was mentioned back in the early days of TrackerSmacker being deployed - since the password credential isn't used as part of Cryptostorm's security model, why not use that as a field to pass switches to the exit node to activate/deactivate certain features?

User avatar

df
Site Admin
Posts: 322
Joined: Thu Jan 01, 1970 5:00 am

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby df » Fri May 25, 2018 6:37 pm

@parityboy
That's one method I was thinking of, the only problem is that doing it that way requires all the server-side OpenVPN's to be restarted so that I can change --auth-user-pass-verify from via-env to via-file, or change --script-security 2 to 3.
Another idea I was considering is using pdns-recursor's (part of DeepDNS) LUA scripting to monitor for a specific hostname, say "nots.cryptostorm.is". If the client resolves that IP, then a new iptables rule is created that forwards all further DNS to a secondary pdns-recursor instance that has TS disabled.
For the users that don't know how to run `nslookup` or `ping` to activate that DNS resolution, they could simply use their browser to go to the hostname.
One benefit of doing it that way is that I can also have the hostname resolve to that 10.31.33.7 IP that all the servers have an Apache listening on, mostly used for widget updates. I could setup a VirtualHost config on there so when people goto http://nots.cryptostorm.is/ they see a page telling them that TS is disabled now.
I guess for widget users, it'd be easier since I could do the nslookup from there, so widget people only have to select the "Disable TrackerSmacker" option.

Anyways, I'll test out the LUA/pdns thing. If the performance hit is too much, I guess I'll bite the bullet and change all the configs to use via-file or script-security 3 so I can access the password.

User avatar

Topic Author
parityboy
Site Admin
Posts: 1220
Joined: Wed Feb 05, 2014 3:47 am

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby parityboy » Sat May 26, 2018 5:02 pm

@df

The only issue with the two-step approach is that it's two steps. :) A small price to pay for better security but you know what people are like. :P One good thing about the password field approach is that it's scalable - you can add switches to activate other features in the future, much like a Web API. :)

User avatar

df
Site Admin
Posts: 322
Joined: Thu Jan 01, 1970 5:00 am

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby df » Sat May 26, 2018 10:15 pm

@parityboy
Yea, plus doing this with LUA/pdns means all DNS requests would have to pass through that LUA script, which would decrease performance.
The password option does sound easier for clients, even with the required instance restart.

The only thing I haven't decided yet is do I make TS the default, and require setting a specific password to disable it, or do I make it disabled by default, and have setting the password enable it.

EDIT:
It doesn't look like the password method is going to work. The server-side --auth-user-pass-verify script is the only thing that has access to the password, unless I did some additional logging that would tie a token to an IP, which is definitely not a good idea. Also, I would need the client's internal 10.x.x.x internal IP to forward DNS for that client to the non-TS DNS server, and that internal IP doesn't get generated until the --client-connect script runs, which doesn't have access to the password.

I think I found a solution that'll work though. If I add to the client config "dhcp-option DNS 10.31.33.7", then it'll set that IP as the primary DNS server, and keep the one pushed by the VPN server as a secondary.
Already tested on an empty server and doing that lets me resolve things blocked by TS, and when I tell nslookup to use the secondary DNS server, it's correctly blocked by TS.
The only real downside to doing it this way is that I can't instantly enable or disable TS, the client would have to disconnect/reconnect for that change to take effect.
There are other more complex options that would allow me to instantly enable/disable TS, but they all seem to require more steps than I think most users would care for.
For widget users, it would be easy enough to select the TS option and have the widget do all the work.
But for Linux or OpenVPN GUI users, I don't see them doing all that work.
Adding a single line to the config seems more likely, especially if I update the configs on github to include the option, but commented out.

Also, I've seen a lot of complaints from non-CS members who are using the DNS servers on their systems and some things not resolving because of TS, and since they don't know about TS (our fault for poorly documenting it), they think the server is bugged.
Mainly for that reason, I think when I make this need option live, I'll have TS disabled by default.
So instead, adding "dhcp-option DNS 10.31.33.7" to the client config would enable TS.

User avatar

Topic Author
parityboy
Site Admin
Posts: 1220
Joined: Wed Feb 05, 2014 3:47 am

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby parityboy » Wed May 30, 2018 3:46 am

@df

Cheers for the explanation. :)

Quick question: can the server push more than one DNS server entry to the client? Are they stacked on the client, i.e. last in first out?

Also, when the OpenVPN server forks an instance for a given session, can it load a configuration file for that specific instance, or is the configuration global?

I'm wondering if it would be possible to indeed use the password as an option source, combined with sed to modify a config on the fly before pushing anything back to the client. That way, you could use the auth script to choose which DNS option to send to the client.


Forget it, it's going to spawn a process as soon as the connection comes in so it will already have its config. Pity.

User avatar

df
Site Admin
Posts: 322
Joined: Thu Jan 01, 1970 5:00 am

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby df » Wed May 30, 2018 4:52 am

@parityboy
Yea. First one pushed would be the primary, second one pushed would be the secondary, etc.
In my test, when I added "dhcp-option DNS 10.31.33.7" to my client config, it set that as the primary DNS and the one pushed by the OpenVPN server as the secondary DNS.
If had a regular/default client config and I changed the server-side config from:
push "dhcp-option DNS 212.129.46.86"
to:
push "dhcp-option DNS 212.129.46.86"
push "dhcp-option DNS 8.8.8.8"
then it would set 212.129.46.86 as the primary and 8.8.8.8 as the secondary.

As for your second question, I think that is somewhat possible if we were doing client certificates and static IP pools, but with our current setup all clients appear the same in this context.
Most configuration directives are loaded in from a single file, and all clients use that configuration.
Some dynamic directives can be pushed from the server though, like in our --client-connect script @ https://cryptostorm.is/conf/session_up.sh.txt we use to randomly generate then push the 10.x.x.x IP the client gets assigned.
Reason we do that is by default OpenVPN uses simple sequential numbering for the last octets in that 10.x.x.x IP.
With sequential numbering, if you connect to the server and get 10.22.0.4 then you know there's 2 other clients on that OpenVPN server instance (.1 is the gateway, .2 is client1, .3 is client2, .4 is you).
That might be useful information in a correlation attack, like if you knew the b-class of a client's real IP but weren't sure, you could DDoS parts of that b-class until the number of clients on the VPN server decreased.
When it decreased, you probably hit the client, so you rinse and repeat until the target network gets small enough that you end up with a single IP.
Not a very likely scenario if a server's busy enough with many clients connecting/disconnecting all the time, but since randomly generating those 10.x.x.x VPN IPs is easy enough, we thought it'd be better to have it :-P

Anyways, all the OpenVPN directives to call scripts are: up, down, ipchange, route-up, tls-verify, auth-user-pass-verify, client-connect, client-disconnect, and learn-address
See https://community.openvpn.net/openvpn/w ... nPage#lbAT and other parts of the manual

User avatar

Topic Author
parityboy
Site Admin
Posts: 1220
Joined: Wed Feb 05, 2014 3:47 am

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby parityboy » Sat Jun 02, 2018 7:29 am

@thread

westerndigital.secure.force.com now fails to resolve on England and Frankfurt. This site handles support for Western Digital (warranty, RMA etc.) so I have no idea how it made its way onto a blocklist.

User avatar

df
Site Admin
Posts: 322
Joined: Thu Jan 01, 1970 5:00 am

Re: [DNS] Domains Not Resolving On Certain Exit Nodes

Postby df » Sat Jun 02, 2018 7:33 am

@parityboy
dunno either. I just added force.com to the whitelist and updated England.
Frankfurt isn't using TS, so it's not blocking anything. Probably got cached on your system.


Return to “member support & tech assistance”

Who is online

Users browsing this forum: No registered users and 24 guests

cron

Login