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.
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?
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
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
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?
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).
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.
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?
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? dnsmasqDepends: on dnsmasq-base. Try uninstall dnsmasq and install dnsmasq-base insteaad.
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.