Block ads and trackers via hosts file on Qube-OS

User Support
1

Hi everyone,
I would like to add StevenBlack’s hosts file to my Qubes-OS system, to block every ads and tracker.
I already checked this document Config files | Qubes OS, but I would like to ask more help. I’m worried of making mistakes, because I see that in the hosts file there are already things inside by default; probably to make sure that the VMs are comunicating correctly.

How can I do it in a secure and right way?

Thanks in advance

2

Simplest way is to install dnsmasq or unbound in your NetVM and use a blocklist. dnsmasq has simpler configuration.

Check the repo above for how to do it with unbound.

  • In your dnsmasq.conf, then set server=8.8.8.8 to configure upstream DNS. 8.8.8.8 is Google; use whichever provider is appropriate for your circumstance, such as your ISP’s or something else on the LAN. Also specify bind-interfaces, no-resolv, and listen-address=127.0.0.1, so that dnsmasq only works over loopback and does not try to reference /etc/resolv.conf.

  • Configure network manager in the NetVM to be DHCP/Addresses Only, set DNS to 127.0.0.1 which adds nameserver 127.0.0.1 to /etc/resolv.conf, and sets up some DNAT rules.

With this, DNS requests within the NetVM will be serviced by dnsmasq, blocked if applicable, or fed to the upstream (8.8.8.8).

The added difficulty is getting downstream AppVMs to work. For this, you’d need to do some firewall changes. As dnsmasq will only be listening on localhost, we have to violate the rules that disallow outside traffic from being able to talk to localhost.

  • Add a user firewall rule to accept port 53 over the vif+ interfaces.
  • Set the sysctl net.ipv4.conf.default.route_localnet to 1.

By configuring network manager to have the DNS server be 127.0.0.1, this will automatically setup the DNAT rule to forward 10.139.1.1:53 from downstream AppVMs to dnsmasq in the NetVM (127.0.0.1:53). But this is considered a martian as no external IP address should be routable to another VM’s 127.0.0.1 address.

The sysctl setting will enable localhost martians for new interfaces, such as the vif’s that have yet to be created. It would be sufficient to only do it for vif interfaces, as opposed to default, but AFAIK, there is not currently a way to execute custom firewall rules when a new downstream VM is connected, which appears to have once been the case in earlier versions of Qubes OS.

Allowing martians to loopback might sound dangerous, but existing firewall rules minimize the danger. The weird thing that would be allowed is something like ping -I eth0 127.0.0.1 from a downstream AppVM to the NetVM, as the default rules allow all ICMP. Assuming additional rules aren’t added that allow vif interfaces to talk to other ports on loopback, it should be safe.

You can do this in your hardware-touching NetVM, or in a ProxyVM, which incurs an additional NAT layer and running VM, but in my opinion does not provide any benefit unless the “upstream” DNS traffic utilizes DoT, DoH, or dnscrypt. Otherwise, the upstream NetVMs can perform their own DNS spoofing like your ISP.

Edit: enabling DNSSEC is one defense that can be added.

3

You can do this simply.
Grab a copy of the hosts file, and remove everything down to
# Start StevenBlack
Copy the edited file to template, and add the contents to the end of
/etc/hosts
e.g cat StevenBlack_edited_hosts >> /etc/hosts
Shutdown template.
Done

4

Actually, it’s like this:

Shutdown template
Reboot the AppVM
Done

5

My $0.02

I try to keep any extra software (even dnsmasq) out of system qubes, especially firewalls/netvms etc. Putting the host file into /etc/hosts in the qube template, as @unman and @fsflover mention, is the safest IMHO

6

cat command didn’t work, even with sudo.
I manually deleted it and replaced with a new file.

Unfortunately, the new file had different/wrong Permissions and now I am setting the manually.
Can someone gently check his own debian-10 template and share with me the default hosts file permissions?

Right now, I edited them and are as following:

Owner: root
Access: Read and Write
Group: root
Access: Read-only
Others:
Access: Read-only

(*) Me = user
Are they correct?

Please, if you can, share also other template’s hosts file permissions. I want to be sure that I did not set them up wrongly.

7

Actually, it’s like this:

Shutdown template
Reboot any AppVM that are running that use that template, if you want
the new hosts file to take immediate effect in the AppVM.
Done

8

No you want

Owner: root
Access: Read and Write
Group: root
Access: Read 
Others:
Access: Read-only

You could have checked this against any other qube.

sudo will not work with redirection, because it doesn’t apply to
redirection. There are ways of working around this.
But it’s easier to sudo su, do your stuff as root, exit. Using sudo
in this sort of case is almost useless.

9

Unfortunately, after I edited the hosts file, I cannot access websites anymore. Can someone try to do the same process and see if it works?

10

I had confirmed this before posting, and have confirmed again.
I doubt that changing the hosts file will block network access.
You can always try removing the new section from a running qubes, and
see if restores access. Also compare the hosts file to another working qube.