DNS propagation in Qubes

[Micah Lee]

I'm trying to make all DNS requests in Qubes go over TLS (more information about this [1]).

I've got this successfully working in sys-net by running a local DNS server on udp 53 that forwards DNS requests to a remote DNS server over TLS, and then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've confirmed that this works great in sys-net -- all of my DNS requests are encrypted to my remote DNS server, and none are plaintext.

The problem is when I do this, DNS in other downstream VMs all fail. The Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused about how to make this set up work. Any ideas? Thanks!

[1] https://dnsprivacy.org/wiki/
[2] https://www.qubes-os.org/doc/networking/

​​

[Unman]

Which Qubes version are you using Micah?

[Micah Lee]

Qubes 4.0.

[Unman]

On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote:

In sys-net you have PR-QBS chain in nat table that redirects DNS
requests to the network DNS server.

You'll need to remove that chain and replace it with one directing DNS
traffic to the local server.
You'll also need to open the udp port to inbound traffic.

[David Hobach]

If you do that, you'll lose any qubes firewall-based control on DNS
traffic though. I.e. all of your downstream VMs will have DNS access.

Essentially you'll have to implement your own local version of the qubes
firewall to achieve qubes-firewall support. I happened to have done that
some time ago, but the code quality is not good enough to share it
(sorry). nft usage in 4.0 further complicates it from my point of view.
You could try to move the forward chain rules to the input chain on
every firewall change...

Maybe qubes will support it one day; here's the feature request:
https://github.com/QubesOS/qubes-issues/issues/3051
I'm not sure why it got tagged as doc though - maybe I didn't see the
obvious solution.

[Yuraeitha]

@David

We're currently trying to start a Qubes Community doc guide collection at the moment, which is thought to be entirely run by volunteers on day-to-day in order to help save the Qubes staff time. Nothing official yet though, but here one of the ideas being worked on is so you can open up your script to allow others to help you finish it and review it. Basically, if this comes to fruition, then it allows you to publish unfinished scripts, either to work with others and finish it together, or let others takeover if you don't want to continue it. Kinda something like that, of course credits should be put like always. If this comes to fruition, maybe you can start up a collaboration to have people with the right background review it and quality check it?

[Chris Laprise]

If this is about changing the iptables rules in a proxyVM, then you're
allowed to do so with qubes-firewall-user-script and the new
qubes-firewall.d in /rw/config. Just be mindful of what the default
rules are and Insert/Append as needed.

For example, if you don't want DNS requests to be routed elsewhere you
can flush the PR-QBS chain in the nat table and maybe add another dnat
rule there redirecting to localhost (this would catch all DNS requests,
not just the ones sent to the Qubes internal DNS addresses). Then you
can add an INPUT rule for port 53.

Maybe I'm missing something but this doesn't look hard. As another
possible avenue if the above fails, you could look for a guide to
setting up 'stubby' on a local router; this has the best chance of
working as proxyVMs are much like routers.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Chris Laprise]

>>>> [1] https://dnsprivacy.org/wiki/
>>>> [2] https://www.qubes-os.org/doc/networking/

Micah,

If you have any specific instructions on how to setup the forwarder
you're using, I'd be happy to try it myself and post a solution for use
with qubes-firewall.

I found the dnsprivacy wiki to be a bit scattered and not very specific.
Their video "tutorial" is really a lecture on the concept.

[Micah Lee]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On March 8, 2018 11:26 AM, Chris Laprise <tas...@posteo.net> wrote:

> ​​
>
> >>>\> \[1\] https://dnsprivacy.org/wiki/

>
> > > > > \[2\] https://www.qubes-os.org/doc/networking/
>
> Micah,
>
> If you have any specific instructions on how to setup the forwarder
>
> you're using, I'd be happy to try it myself and post a solution for use
>
> with qubes-firewall.
>
> I found the dnsprivacy wiki to be a bit scattered and not very specific.
>
> Their video "tutorial" is really a lecture on the concept.

Thanks, yes I'd love to share instructions. I haven't gotten it working yet -- I'm traveling right now and haven't spent a lot of time on it, and might not for the next week or two. But once I figure it out I'd like to write a blog post or something with instructions. But maybe I should sent it to this list first for people to test and give feedback.

[Alex Dubois]

On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>

For your info, I have a wiki on how to use dns-crypt here: https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md
It is supposed to be exposed via blog.bowabos.com but github changed something and the static site does not get automatically generated at the moment...

[Chris Laprise]

Nice. I gave this a try on debian-9, using apt to install dnscrypt-proxy
and unbound.

One problem is that the howto assumes particular Qubes 10.137.2.x and
10.138.2.x nets for unbound.

Another problem is that on Qubes 4.0 the vif interfaces plus eth0 all
share the same IP address. This isn't explained in the Qubes networking
or firewall docs, so it may be a bug...

To keep unbound.service from failing I changed unbound.conf to this:

> interface: <eth0 address here>
> access-control: 10.137.0.0/24 allow
> harden-large-queries: yes
> private-address: 10.0.0.0/8
> private-address: 192.168.0.0/16
> val-permissive-mode: yes
> do-not-query-localhost: no

...and for now omitted the '-d' destination part in iptables.

Then if I issue:

> sudo iptables -t nat -F PR-QBS
> sudo iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $eth0_address
> sudo iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $eth0_address

it appears to work from a downstream appVM. But I haven't checked yet to
see if its really using the dnscrypt proxy; even if it is, the config
may need to be adjusted for better security.

[David Hobach]

On 03/11/2018 11:21 AM, Chris Laprise wrote:
> ...and for now omitted the '-d' destination part in iptables.
>
> Then if I issue:
>
>> sudo iptables -t nat -F PR-QBS
>> sudo iptables -t nat -A PR-QBS  -i vif+ -p udp --dport 53 -j DNAT --to
>> $eth0_address
>> sudo iptables -t nat -A PR-QBS  -i vif+ -p tcp --dport 53 -j DNAT --to
>> $eth0_address
>
> it appears to work from a downstream appVM. But I haven't checked yet to
> see if its really using the dnscrypt proxy; even if it is, the config
> may need to be adjusted for better security.

I just tested that one (my implementation was also doing pretty much
exactly that + a local INPUT chain firewall so it was a 5 min test
removing the INPUT firewall):

Since you'll need something like

-I INPUT -p udp -m udp --dport 53 -j ACCEPT
-I INPUT -p tcp -m tcp --dport 53 -j ACCEPT

it makes DNS accessible for all downstream VMs regardless of the
qubes-firewall settings, i.e. apprently the nft FORWARD rules are not
applied for DNAT to localhost.

That's probably why I had opened that github issue & implemented a local
firewall back then...

You can verify my findings by using the dom0 qvm-firewall command line
to revoke DNS access for a downstream VM & then use e.g. dig in that VM.
The qubes-vm-settings GUI won't work as in 4.0 DNS & ICMP is always allowed.

So yes, if one is aware of that issue, one can certainly use it the way
you described. If you rely on the qubes-firewall to work as expected,
you shouldn't use it.

[David Hobach]

On 03/11/2018 03:03 PM, David Hobach wrote:
> So yes, if one is aware of that issue, one can certainly use it the way
> you described. If you rely on the qubes-firewall to work as expected,
> you shouldn't use it.

P.S.:
An alternative might be to setup the local DNS service in a VM closer to
the Internet, i.e. not in the proxy VM which also implements the qubes
firewall.

Something like
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM
with qubes-fw <-- client VM

I didn't test that though.

[Chris Laprise]

On 03/11/2018 10:03 AM, David Hobach wrote:
> On 03/11/2018 11:21 AM, Chris Laprise wrote:
>> ...and for now omitted the '-d' destination part in iptables.
>>
>> Then if I issue:
>>
>>> sudo iptables -t nat -F PR-QBS
>>> sudo iptables -t nat -A PR-QBS  -i vif+ -p udp --dport 53 -j DNAT
>>> --to $eth0_address
>>> sudo iptables -t nat -A PR-QBS  -i vif+ -p tcp --dport 53 -j DNAT
>>> --to $eth0_address
>>
>> it appears to work from a downstream appVM. But I haven't checked yet
>> to see if its really using the dnscrypt proxy; even if it is, the
>> config may need to be adjusted for better security.
>
> I just tested that one (my implementation was also doing pretty much
> exactly that + a local INPUT chain firewall so it was a 5 min test
> removing the INPUT firewall):
>
> Since you'll need something like
>
> -I INPUT -p udp -m udp --dport 53 -j ACCEPT
> -I INPUT -p tcp -m tcp --dport 53 -j ACCEPT

I used this, which is Alex's example without '-d':

iptables -I INPUT 3 -j ACCEPT -p udp --sport 1024:65535 --dport 53 -m
conntrack --ctstate NEW

>
> it makes DNS accessible for all downstream VMs regardless of the
> qubes-firewall settings, i.e. apprently the nft FORWARD rules are not
> applied for DNAT to localhost.
>
> That's probably why I had opened that github issue & implemented a local
> firewall back then...
>
> You can verify my findings by using the dom0 qvm-firewall command line
> to revoke DNS access for a downstream VM & then use e.g. dig in that VM.
> The qubes-vm-settings GUI won't work as in 4.0 DNS & ICMP is always
> allowed.
>
> So yes, if one is aware of that issue, one can certainly use it the way
> you described. If you rely on the qubes-firewall to work as expected,
> you shouldn't use it.

Thanks for the specific caveat.

Qubes 3.2 firewall had a dns incompatibility when you configured a
tunnel such as openvpn. I was able to fix that problem (pretty
seamlessly) with sed :) .

[Alex Dubois]

Sent from my mobile phone.

> On 11 Mar 2018, at 10:21, Chris Laprise <tas...@posteo.net> wrote:
>
>> On 03/10/2018 04:43 PM, Alex Dubois wrote:
>>> On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee wrote:
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>
>>>> On March 8, 2018 11:26 AM, Chris Laprise <tt@p...o.net> wrote:
>>>>
>>>> ​​
>>>>
>>>>>>> \> \[1\] https://dnsprivacy.org/wiki/
>>>>
>>>>>>>> \[2\] https://www.qubes-os.org/doc/networking/
>>>>
>>>> Micah,
>>>>
>>>> If you have any specific instructions on how to setup the forwarder
>>>>
>>>> you're using, I'd be happy to try it myself and post a solution for use
>>>>
>>>> with qubes-firewall.
>>>>
>>>> I found the dnsprivacy wiki to be a bit scattered and not very specific.
>>>>
>>>> Their video "tutorial" is really a lecture on the concept.
>>>
>>> Thanks, yes I'd love to share instructions. I haven't gotten it working yet -- I'm traveling right now and haven't spent a lot of time on it, and might not for the next week or two. But once I figure it out I'd like to write a blog post or something with instructions. But maybe I should sent it to this list first for people to test and give feedback.
>> For your info, I have a wiki on how to use dns-crypt here: https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md
>> It is supposed to be exposed via blog.bowabos.com but github changed something and the static site does not get automatically generated at the moment...
>
> Nice. I gave this a try on debian-9, using apt to install dnscrypt-proxy and unbound.
>
> One problem is that the howto assumes particular Qubes 10.137.2.x and 10.138.2.x nets for unbound.

Yes I need to rewrite it for Qubes 4.

The other blog post on Atlassian stack also needs a rewrite and I have now a better network topology (more secure) for it. Time is my problem

[David Hobach]

On 03/11/2018 03:15 PM, David Hobach wrote:
> An alternative might be to setup the local DNS service in a VM closer to
> the Internet, i.e. not in the proxy VM which also implements the qubes
> firewall.
>
> Something like
> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM
> with qubes-fw <-- client VM
>
> I didn't test that though.

I just tested that as well now and it works as expected without any of
the aforementioned caveats.

So I'd recommend the one above over the previously discussed
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
(at least I was talking about that architecture - maybe the others were
talking about something different...).
The same holds true for VPN users.

I also documented this at
https://github.com/QubesOS/qubes-issues/issues/3051

[Alex Dubois]

Sent from my mobile phone.

This type of architecture is bad practice as the attack surface of DNS is bigger than Qubes firewall, and an attack on this daemon compromise all traffic, not just DNS.

A better arch is
Internet
- netVM
- - firewallVM
- - - Service (ie DNS or VPN)
- - - clientVM1
- - - clientVM2

And firewallVM intercept the traffic for the VM that needs it.
Note that a service can also be a client for another service.
Note2 that does not mean that the arch should be flat, if you are worried that a mis conf of firewallVM could put you at risk you could do
Internet
- NetVM
- - FirewallVM
- - - FirewallVPN
- - - - clientVPNVM
- - - - vpmServiceVM
- - - firewallDNS
- - - - clientDNSVM
- - - - dnsServiceVM
- - - firewallWebServer
- - - - ReverseProxyAuthVMservice
- - - - - webServerVMservice
- - - - - - webDMserviceVM
- - - - ClientWebVM

[David Hobach]

On 03/13/2018 07:14 AM, Alex Dubois wrote:
>> On 12 Mar 2018, at 18:40, David Hobach <tri...@hackingthe.net> wrote:
>>
>>> On 03/11/2018 03:15 PM, David Hobach wrote:
>>> An alternative might be to setup the local DNS service in a VM closer to the Internet, i.e. not in the proxy VM which also implements the qubes firewall.
>>> Something like
>>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with qubes-fw <-- client VM
>>> I didn't test that though.
>>
>> I just tested that as well now and it works as expected without any of the aforementioned caveats.
>>
>> So I'd recommend the one above over the previously discussed
>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
>> (at least I was talking about that architecture - maybe the others were talking about something different...).
>> The same holds true for VPN users.
>
> This type of architecture is bad practice as the attack surface of DNS is bigger than Qubes firewall, and an attack on this daemon compromise all traffic, not just DNS.
>
> A better arch is
> Internet
> - netVM
> - - firewallVM
> - - - Service (ie DNS or VPN)
> - - - clientVM1
> - - - clientVM2

I believe your essential point was not to use proxy VMs for services at all.

My main point was not to mix a Qubes Firewall VM with local services. I
think you basically agree with that.

I however also disagree with your point wrt proxy VM usage as there's no
attack vector for E2E encrypted traffic on proxy VMs except for DoS
which you'll notice.
If you're using non-E2E encrypted traffic (except for maybe DNS) you
have a different problem altogether and even then I'd trust my proxy VM
a lot more than any other hop (your Wifi provider? the 4+ backbone
providers you pass?) on the route to the destination.

Moreover it is rather inconvenient to configure each and every client VM
to use that service VM which can also lead to unexpected
misconfigurations & leakages.

[Alex Dubois]

Sent from my mobile phone.

> On 13 Mar 2018, at 18:49, David Hobach <tri...@hackingthe.net> wrote:
>
> On 03/13/2018 07:14 AM, Alex Dubois wrote:
>>> On 12 Mar 2018, at 18:40, David Hobach <tri...@hackingthe.net> wrote:
>>>
>>>> On 03/11/2018 03:15 PM, David Hobach wrote:
>>>> An alternative might be to setup the local DNS service in a VM closer to the Internet, i.e. not in the proxy VM which also implements the qubes firewall.
>>>> Something like
>>>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with qubes-fw <-- client VM
>>>> I didn't test that though.
>>>
>>> I just tested that as well now and it works as expected without any of the aforementioned caveats.
>>>
>>> So I'd recommend the one above over the previously discussed
>>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
>>> (at least I was talking about that architecture - maybe the others were talking about something different...).
>>> The same holds true for VPN users.
>> This type of architecture is bad practice as the attack surface of DNS is bigger than Qubes firewall, and an attack on this daemon compromise all traffic, not just DNS.
>> A better arch is
>> Internet
>> - netVM
>> - - firewallVM
>> - - - Service (ie DNS or VPN)
>> - - - clientVM1
>> - - - clientVM2
>
> I believe your essential point was not to use proxy VMs for services at all.
>
> My main point was not to mix a Qubes Firewall VM with local services. I think you basically agree with that.

Yes agree

>
> I however also disagree with your point wrt proxy VM usage as there's no attack vector for E2E encrypted traffic on proxy VMs except for DoS which you'll notice.

Let’s agree to disagree;). This is possibly true client to VPN, but the attack surface VPN to internetVPN is not small, there are a substantial number of line of code for the support of various protocols, with negotiation phases, parsing of data stream into such control flow. (I.e. some of the long list of OpenSSL vuln lead to remote code exec I suspect).
So my point is you can use proxy if all the clients are going to use the VPN. And this apply also only if all the traffic would flow through the service (VPN use case OK, dns or http proxy not OK).

> If you're using non-E2E encrypted traffic (except for maybe DNS) you have a different problem altogether and even then I'd trust my proxy VM a lot more than any other hop (your Wifi provider? the 4+ backbone providers you pass?) on the route to the destination.

I may have misunderstood you, but this is outside the subject of the discussion or please clarify.

>
> Moreover it is rather inconvenient to configure each and every client VM to use that service VM which can also lead to unexpected misconfigurations & leakages.

I agree that it is less trivial to setup but you lower your attack surface significantly.

So I agree that it depends on the circumstances, but I think my statement is preferable as a general rule, and I think Qubes should move toward supporting such setup, making it easier to configure.

Best Regards
Alex
>

[gas...@gmail.com]

Is there a clear guide of how to set up a DNS VM in Qubes OS?

I tried setting up dnsmasq in the VPN VM behind sys-firewall, both with NetworkManager and as a standalone service.  It didn't work.  I also tried on another VM behind the VPN VM. 

All I got working is making DNS requests to the specific VM.  E.g.

$ dig example.com @10.137.0.23

But I wasn't able to hijack the DNS requests with iptables for general requests without "@".  tcpdump seems to indicate that the DNS queries don't even get routed through the VPN VM, which doesn't make sense to me, so I might be missing something.

Any clear step-by-step guide anywhere?

Thanks.

[David Hobach]

I randomly found
https://blog.tufarolo.eu/how-to-configure-pihole-in-qubesos-proxyvm/

It looks reasonable, but I didn't test it. Use it at your own risk.
Depending on your chain of VMs the Qubes firewall may or may not work
for DNS - just test it if it matters to you.