Whonix KVM dnsmasq - listen port on host operating system - attack surface reduction

KVM
1

dnsmasq on the host operating system is increasing the attack surface.

How did I find that out?

  1. Install Debian.

  2. Check open ports and write them to a file.

    sudo netstat -tulpen > old

  3. Install packages required for Whonix KVM according to Whonix KVM documentation.

  4. Check open ports again and write them to a different file.

    sudo netstat -tulpen > new

  5. Use any (graphical) diff viewer of your choice.

    meld old new

  6. Result:

dnsmasq opens a listen port on the host operating system that is reachable from LAN and from the Internet (if not using a NAT router or host operating system firewall)

tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 0 19969 1975/dnsmasq

tcp6 0 0 :::53 :::* LISTEN 0 19971 1975/dnsmasq

Whonix KVM TODO: Include instructions how to configure dnsmasq to listen on localhost only (if no way to get rid of it completely).

NOTE: I am not a maintainer of Whonix KVM.

2
3

Forum moderation:

Linking to footnotes is confusing because the numbering and therefore links to footnotes will change over time when new footnotes are added.

It gets more confusing due to oneboxing. → Kicksecure ™ Forums Usage Instructions, Best Practices and FAQ chapter Avoid Oneboxing for Anchored Links in Kicksecure wiki

Content:

Copying that footnote here for further discussion.

So I can see an open TCP port. However it responds as if it’s “tcpwrapped”. That implies if you connect over a different interface from virbr0 , dnsmasq closes the connection without reading any data. So data you send to it doesn’t matter; it can’t e.g. exploit a classic buffer overflow.

4

I think it’s needed. More on tcpwrapped:

Specifically, it means that a full TCP handshake was completed, but the remote host closed the connection without receiving any data.

So two things here:

  • We still don’t want a TCP handshake to be completed because unsolicited incoming connections have a higher attack surface than not allowing unsolicited incoming connections.
  • Even the information “port 53 tcpwrapped” should not be leaked over the LAN or internet. Could even be deducted “Maybe it’s a Whonix KVM user”.

related:
A writeup on “unsolicited incoming connections” → Opening Ports in Whonix.

I don’t know which one would be applicable here, but here’s a long list of dnsmasq CVEs to review:

Potential solution, untested:

1 Like
5

Note this is not specific to Whonix and could be interpreted as Linux host running libvirt, This is already discoverable and hard to hide the type of OS running on a network because of the different ways they react.

Binding to localhost would break it because the whole point is to have it listening on whatever arbitrary internal LAN IP ranges libvirt binds it to on the fly. OP can go ahead and try to uninstall it and deal with the fallout, but as a default option this is unworkable.

Does ufwall change nmap results? or is it using raw ports?

1 Like
6

Try?
Probably I think.

Maybe Whonix for KVM should advice to setup a host firewall beforehand.

I doubt that. Raw ports is mostly only a DHCP thing. But this is DNS. Not DHCP.

1 Like
7

I see your point of view but I agree with @Patrick on this one.
Your point heavily assumes “Linux machine running a KVM machine is not that suspicious” is entirely in context of specific countries in specific times.

Some tight dictatorship countries, especially during times of unrest will arrest you incase they suspect even slightest of “above average technical ability” e.g. running Linux host and running virtual machines on it.

Their mindset would be “this person or group is running Linux, people run Linux because they have something to hide! oh and on top of that he is running a virtual machine! what is he scared of so much”

This sounds comical but There are countless arrests or interrogations based solely on this “logic” and I should mention that “arrests” in those countries means torture to death

A more tangible issue for other countries is fingerprinting. They don’t have to be sure that a Whonix VM was started or is installed, they just have to know that a VM is there and it is enough to narrow down the search considerably

Do not undermine value of metadata, a lot of people die every day because of it. We kill people based on metadata

So, optimally the host should not leak information on whether or not they have VMs/dnsmasq or anything out of ordinary

2 Likes
8

I hate to be the bearer of bad news, but our security choices and improvements do have a unique fingerprint on the network for those who want to look. The fact we disable TCP timestamps and remove TCP ISNs is readily apparent. Rather than stick to the less secure defaults that can endanger users in other ways, we have chosen to move ahead and adopt these improvements.
.
If having a firewall solves this - which I think Patrick said, then the solution is easy enough to apply and I hope satisfactory

2 Likes
9

That is in the VMs and not the host (dnsmasq fingerprinting) correct?

The TCP timestamps being disabled is only inside of the VM, however the dnsmasq is on the host so it should still be considered. Just because Whonix has some obvious fingerprint able properties in exchange for security, does not mean you should allow more fingerprints, especially ones that are unnecessary like in this case of dnsmasq exposing it’s self on the host.

This is interesting because AFAIK Whonix disables these in linux-harden kernel which I thought is in use only in Workstation and not Gateway and I assumed that means no fingerprint (at least outside of tor) or does Gateway and workstation both use same kernel with same options? if so that could be an improvement to disable some hardening kernel features in Gateway, no?

10

Forum moderation:

You’re raising the fingerprinting point here already:

Please do not duplicate the same discussion in multiple forum threads.

11

Unfortunately I have to raise one point here. We could make a meaningful distinction between:

  • A) ISP level network fingerprint analysis versus leaking “user of dnsmasq or something similar, maybe a Whonix user?” versus,
  • B) Leaking that information to anyone who can use a port scanner over LAN (if using a WiFi hotspot or big LAN or LAN based ISP) or even over WAN (if not using a NAT router and/or compromised NAT router).

We cannot do anything about A) (as per TCP linux-hardened fingerprinting) but B) is avoidable. For that, either

  • 1) dnsmasq would need to be avoided, or
  • 2) Whonix KVM documentation could include instructions on how to setup a host firewall since specifically important due to dnsmasq.

Whonix-Gateway requires neither

  • X) DHCP, nor
  • Y) DNS.

DHCP:
DHCP isn’t needed by Whonix-Gateway because whonix-gw-network-conf/etc/network/interfaces.d/30_non-qubes-whonix at master · Whonix/whonix-gw-network-conf · GitHub is using static networking - no DHCP needed since many Whonix versions.

DNS:
DNS isn’t needed by Whonix-Gateway because Tor does not require DNS.
(Except perhaps for some pluggable transports
Related: Whonix-Gateway System DNS - Whonix

So I don’t understand why Whonix KVM requires dnsmasq.

12

KVM needs it by default. not really a Whonix thing. We already recommend installing a firewall in the host hardening guide. I’m not sure that requiring users to take extra steps on their hosts is conducive to a good first time user experience nor scaring them away by saying the hypervisor installs unsafe packages (which it isn’t from a security perspective because no one can connect to it) makes any sense. Putting a dozen caveats and warnings on a download page will make people ignore the project and leave.

13

I saw some instructions for running a Debian host with KVM and a Debian guest inside a KVM VM. And some of these instructions didn’t require dnsmasq.

Maybe dnsmasq is required as per, quote libvirt: Running your own dnsmasq with libvirtd

On linux host servers, libvirtd uses dnsmasq to service the virtual networks, such as the default network. A new instance of dnsmasq is started for each virtual network, only accessible to guests in that specific network.

But that doesn’t sound like the host dnsmasq systemd unit is required. Could you test please to disable the host dnsmasq systemd unit? (The package dnsmasq can remain being installed.)

Check if running:

sudo systemctl status dnsmasq

Then stop it.

sudo systemctl stop dnsmasq

Does that break Whonix-Gateway connectivity?
Does that break Whonix-Workstation connectivity?

14

I tested setting up a brand new KVM host without dnsmasq installed and with the default KVM network deleted.

I was able to import the Whonix-External network but could not start it due to an error about dnsmasq command being missing.

So it appears this is required for NAT networks in particular and not purely the default network.

I will test two things:

  1. Creating a stub dnsmasq executable that will simply exit 0 or halts execution so that it appears to be running in the background; and
  2. Modifying the Whonix-External network XML configuration in the hope of removing the dnsmasq requirement.

And report back.

I don’t feel we should need dnsmasq on a KVM host used exclusively for Whonix as we don’t need the host to be able to ping the VMs by name.

1 Like
15

Any update?

16

Please test. Whonix KVM dnsmasq - listen port on host operating system - attack surface reduction - #13 by Patrick @HulaHoop

17

Hm. Says

Unit dnsmasq.service could not be found.

Yet I can see dnsmasq instances when doing netstat -tulpen

1 Like
18

Big surprise. Works for me.

sudo apt install --no-install-recommends dnsmasq

sudo systemctl status dnsmasq

â—Ź dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; preset: enabled)
Active: active (running) since Sun 2023-09-03 08:12:01 EDT; 10s ago

Using Debian bookworm?

Also maybe no need to install package dnsmasq?
dnsmasq Depends: on dnsmasq-base. Try uninstall dnsmasq and install dnsmasq-base insteaad.

sudo apt purge dnsmasq
sudo apt install --no-install-recommends dnsmasq-base

That will result in the dnsmasq binary being installed (part of package dnsmasq-base) (which might be needed by KVM) but the systemd daemon won’t be installed (part of package dnsmasq). So the daemon presumably won’t be needlessly running on the host operating system.

19

Yes, though upgraded not clean install.

Turns out dnsmasq-base is the package I always had installed which explains how it is present though its service is not running.

Anything else to do here?

20

Update KVM wiki pages to reflect this change.