Hostname leak prevention

[tlaurion]

Qubes 4.1.1

On 2017-04-09 15:25, Joonas Lehtonen wrote:

Hi,
if you setup MAC randomization via network manager in a debian 9
template as described here:
https://www.qubes-os.org/doc/anonymizing-your-mac-address/
you still leak your hostname.
Once your MAC address is randomized you might also want to prevent the
disclosure of your netvm's hostname to the network, since "sys-net"
might be a unique hostname (that links all your random MAC addresses and
the fact that you likely use qubes).
To prevent the hostname leak via DHCP option (12):

• start the debian 9 template
• open the file /etc/dhcpd/dhclient.conf
• in line number 15 you should see "send host-name = gethostname();"
• comment (add "#" at the beginning) or remove that line and store the file
• reboot your netvm

I tested the change via inspecting dhcp requests and can confirm that
the hostname is no longer included in dhcp requests.

@andrewdavidwong : That question on preventing sys-net to leak hostname pops up really frequently on the forums.
The solution is documented at https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/anonymizing-your-mac-address.md#prevent-hostname-sending, but who needs documentation when the defaults could be implemented at really low cost. Afterall, all this documentation https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/anonymizing-your-mac-address.md#anonymizing-your-mac-address is still existing which is misleading since MAC randomization is now default under Q4.1 and Q4.0 is now EOL, so the same should probably happen under qubes-core-agent-linux as it was done to implement MAC randomization as a safer default for all under QubesOS/qubes-core-agent-linux#297

Or maybe there is a separate issue for hostname leak prevention I was not able to find, in such case, sorry for the noise and I expect others to be able to find such link in following post.

Link to forum posts I crosslinked here to show user's confusions: https://forum.qubes-os.org/t/change-mac-address-and-hostname-by-default/13182/10

debian-11:

user@debian-11:~$ sudo grep -R -e host-name -e hostname /etc/dhc* /var/lib/NetworkManager/
/etc/dhcp/dhclient.conf:send host-name = gethostname();
/etc/dhcp/dhclient.conf:	domain-name, domain-name-servers, domain-search, host-name,
/etc/dhcp/dhclient.conf:#  option host-name "andare.swiftmedia.com";

Fedora-34(35)(36):

[user@fedora-34 ~]$ sudo grep -R -e host-name -e hostname /etc/dhc* /var/lib/NetworkManager/
(no output)

@adw: I'm not sure why WIFI hotspots under my control are not showing any sys-net hostname anymore, but would love to know if some hidden hostname leak prevention were implemented under Qubes/by default under NetworkManager which is not using dhcp local configurations? @marmarek ? From snippets above, it seems that debian should leak, where fedora should not (or implement some default which is not, which would explain why my disp sys-net based on fedora is not).

Originally posted by @tlaurion in #938 (comment)

[tlaurion]

Following the above comments, it seems that fedora template, not containing any send-hostname statement, is the reason no hostname shows on my WiFi router for my randomized mac address.

I didn't do anything special here then selecting the defaults at install to create my disp sys-net based on fedora.

Not related, but following each new fedora template download or following in place upgrade and cloning actual template to newer version, the disposable fedora template needs to point to the new parent template, otherwise reusing old template.

As far as my testing went, Fedora-34 didn't have send-hostname, hence not needing randomization. This is to note a different observed fingerprint then the standard Windows/MAC hostname scheme, and maybe raising attention since no hostname, which is not shouting on the network "sys-net" therefore "I'm using Qubes OS"

The question here is if other templates offered by Qubes offer different hostname leaking behavior, which from the traces above shows that Debian template and others based sys-net qubes are probably leaking sys-net as of today.

This issue is about smoothing that behavior difference out, and making sure that what is now in documentation is transferred in implementation for all use cases.

[tlaurion]

For consistency, community instructions on how to randomize hostname were removed under Qubes-Community/Contents@4ea74ce

It would make sense that all templates remove /etc/dhcp/dhclient.conf, as it is the case for Fedora templates, so that the behavior is the same for all sys-net based templates.

[feffiboujike]

The reason the hostname is not being sent on debian-11 is because /etc/hostname (the static hostname) file is missing (it needs to be present when NetworkManager service is started).

I can't confirm what is happening on Fedora or debian-11-minimal but I would say the reason hostname is or is not being sent is due to that file.

You can run the command nmcli general hostname to see what hostname NetworkManager is using. If the hostname is blank then nothing will be sent.

It is a good thing that this file is missing because I don't believe there is any other way to prevent the hostname being sent globally until https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/584 is resolved. The current method of switching to dhclient and commenting out the send host-name line is not a solution. If the /etc/hostname file is present then dhclient will still send a hostname, regardless of how dhclient is configured. There is another suggestion on the forums that removing dhclient.conf should prevent hostname sending, but this doesn't work either.

It would be good to alert the Qubes developers about this so that they don't introduce an /etc/hostname (at least not until the NM bug is resolved).

[DemiMarie]

In light of https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2029, I’m marking this as waiting for upstream This issue is waiting for something from an upstream project to arrive in Qubes. Remove when closed. .