Change Mac address and Hostname by default?

General Discussion
1

Greetings, I’m new to Qubes. I greatly value the staff working on the Qubes project, and I can see how fascinating it is.
But I do have a few problems.

  • Why systems aiming for privacy won’t necessarily spoof hostnames and mac addresses, like tails for instance.

  • Would it be impossible for the qubes team to make this the default setting for sys-vpn or to offer me the option to decide whether I need it or not? Some people who are looking for privacy occasionally lack knowledgeable computing experience.

Sometimes I require step-by-step assistance for a variety of services, but I can’t seem to locate the comprehensive instruction. I greatly value this forum, however we need to make it simpler for users of Qubes.

For those seeking privacy, I thank you for this project.

1 Like
2

Welcome to the Community @Bop667, I’m glad you like Qubes OS!

Qubes is mostly aimed at security. It contains Whonix for privacy, but Whonix doesn’t directly connect to the Internet; it’s connected via sys-net (and sys-firewall). By default, sys-net doesn’t do the spoofing, but one can configure it: Contents/docs/privacy/anonymizing-your-mac-address.md at master · Qubes-Community/Contents · GitHub.

VPN configuration may depend on the provider, so it’s hard to include a default VPN qube by default. However there are already preconfigured options available for some cases:

Feel free to ask the Community for a help. It’s why this forum exists.

3

Thanks for your kind and informative response …

4

Randomize a single connection

Right click on the Network Manager icon of your NetVM in the tray and click ‘Edit Connections…’.

Select the connection to randomize and click Edit.

Select the Cloned MAC Address drop down and set to Random or Stable. Stable will generate a random address that persists until reboot, while Random will generate an address each time a link goes up. Edit Connection

Save the change and reconnect the connection (click on Network Manager tray icon and click disconnect under the connection, it should automatically reconnect).

I followed the first step successfully .

the second step:

“These steps should be done inside a template to be used to create a NetVM as it relies on creating a config file that would otherwise be deleted after a reboot due to the nature of AppVMs.”

I will open fedora-36 terminal :

sudo touch /etc/NetworkManager/conf.d

sudo nano /etc/NetworkManager/conf.d

and then I will past this 00-macrandomize.conf

So, What is the next steps ?!

5

You say you have followed the first step successfully.
If this has been successful then you may not need to do anything else.

The instructions you have used state:
“However, use of the NetworkManager GUI to set these options is unreliable - there are numerous reports of changes not being saved for particular cards or interfaces. You should check carefully that any settings you make in the GUI are saved, before relying on this method. If the settings are not saved, you can use the method described below using a config file.”

I tried this recently and when I went back into network manager it did not appear to have saved the settings I entered. So, as recommended, I went on to use the second method to which you are referring.

If you do need to do this then the “sudo touch” and “sudo nano” commands that you have posted are incorrect.

00-macrandomize.conf is not supposed to be the content of the new file - it is supposed to be the name of the new file.

Also, /etc/NetworkManager/conf.d is a directory within which you need to create the new file.

So you could use something like the following…

sudo vi /etc/NetworkManager/conf.d/00-macrandomize.conf

(I have used vi above but you can use nano if that is what you prefer and have installed).

Then you need to paste or type in the content which is given in the instructions you have been referring to (the first line of the sample content is [device] and the last line is ipv6.ip6-privacy=2) - and save the file.

The instructions then tell you to create a new NetVM using the edited template.

However, if your existing NetVM already has fedora-36 as its template or, as is more likely, has a dvm (e.g. fedora-36-dvm) as its template which, in turn, has fedora-36 as its template then you won’t need a new NetVM - just shutdown all affected VMs and restart.

The instructions go on to state:
“You can check the MAC address currently in use by looking at the status pages of your router device(s), or inside the NetVM with the command sudo ip link show.”

This is worth doing in between complete shutdown and restarts of your NetVM to verify the mac address is changing.

1 Like
6

Ok. Thanks for your feedback

Could you tell the commands for changing host-name ?

7

Ok. Thanks for your feedback

Could you tell the commands for changing host-name

8

I haven’t tried the commands for changing hostname and wouldn’t want to try to advise about something I haven’t done myself. I looked at the instructions and noticed that one of the files mentioned ( /etc/dhcp/dhclient.conf) is missing from my system and I don’t know what impact that has. There are other posts on the forum about this file but I don’t know enough to help any further.

1 Like
9

Anyone can help to change Hostname ?

10

For clarity, WIFI MAC randomization is the default in 4.1, per network: enable MAC randomization for wifi connections by default by marmarek · Pull Request #297 · QubesOS/qubes-core-agent-linux · GitHub

Consequently, you will see NetworkManager configuration file under templates:
/usr/lib/NetworkManager/conf.d/31-randomize-mac.conf

Duplicate of:

As for hostname randomization its documented at: Contents/docs/privacy/anonymizing-your-mac-address.md at master · Qubes-Community/Contents · GitHub

That documentation says to either add a configuration file to prevent hostname to be sent either globally or per connection settings (which again would need persistence if using disposable sys-net option per install or salt recipe application post-install: not recommended for the same reasons detailed below which should be replaced per proper habits).

It is not uncommon to see dhcp requests without hostnames being sent. If using disposable sys-net, you would need to setup persistence in the disposable template, which I would not recommend personally.

I receive this question often: “How can I have disposable sys-net remember my passwords”, which for me doesn’t make any sense. Why having disposable sys-net if one wants it to add persistence, even more to add persistence of sensitive information unrelated to a specific use case (login to hotel hotspot) that could leak other network login informations if sys-net was momentarily successfully exploited to leak only that hotel hostpot?

If you pick up the habit of opening your vault’s KeepassXC on a clean boot to login where needed, and add copy pasting your needed Wifi login information as first step after booting when you, and only when you require network, copy pasting your needed wifi credentials to connect to needed wifi is a better approach then having sys-net contain all your previous wifi login information, including the wifi information to be part of your work network or anywhere else. Bonus, using disposable sys-net will not auto-login on networks you previously logged in before. This is a security advantage, since you now have the control of deciding when you want to login on the network, to login only when you need to be online without sys-net having booted doing that choice instead of you.

Randomizing WIFI MAC is already there by default. I am not sure why hostname leak prevention is not pushed as a default as well, and poked the @adw at MAC Randomization for iwlwifi · Issue #938 · QubesOS/qubes-issues · GitHub. I invite you to do so as well if this is not prioritized.

Edit: It may as well be already fixed? I do not see on network hotspots I control any sys-net anymore in hostnames?

11

Anyone can help to change Hostname ?

Windows-like hostnames:

$ cat /rw/config/rc.local
#!/bin/sh
bash -c 'name="LAPTOP-$(head /dev/urandom | tr -cd \"A-Z0-9\" | fold -w8 | grep -v "\"" | head -n1)" && \
echo "$name" > /etc/hostname && \
hostname "$name" && \
ipv4_localhost_re="127\.0\.0\.1" && \
sed -i "s/^\($ipv4_localhost_re\(\s.*\)*\s\).*$/\1${name}/" /etc/hosts && \
sed -i "s/^\(::1\(\s.*\)*\s\).*$/\1${name}/" /etc/hosts'
12

Could you help with the steps (commands) one by one for this guide ?

NetworkManager can be configured to use dhclient for DHCP requests. dhclient has options to prevent the hostname from being sent. To do that, add a file to your sys-net template (usually the Fedora or Debian base template) named e.g. /etc/NetworkManager/conf.d/dhclient.conf with the following content:

13

Thank you for your comment - however, I was referring to the part of the documentation that does say edit (not add).

You stated:

I was referring to this part of the documentation…
" Afterwards edit /etc/dhcp/dhclient.conf and remove or comment out the line starting with send host-name ."

14

Any update here ?1

15

Not sure what is unclear about the instructions.

Btw if you don’t send your hostname, there’s usually no point in randomizing it.

1 Like
16

Qubes implementation and hostname leak prevention issue opened independently at https://github.com/QubesOS/qubes-issues/issues/7701

1 Like
17

For the sake of clarity; this is not so clear.
Not disclosing a hostname, on fingerprinting enforcing devices, can go a really long way.

So for the sake of privacy, i’m not totally convinced myself that no hostname disclosure is better then sending laptop-random-numbet-matching-windows-style-hostname, combined with unique, and valid OUI existing mac at each wifi connection.

A fingerprinting enabled endpoint, or a device enforcing some kind of NAC protection can really go a long way. I have not followed development of actual solutions, but it is super easy to apply dhcp client fingerprinting, OUI lookup and tag/refuse devices that look illegitimate.

For the sake of privacy, Fedora dhcp bits will look like Redhat/Centos, no idea really of the market size, butnyou already are different thrn Windows/MacOS/Android for sure and would be tagged as “not-so-common” prior of having an address on the network. Your MAC being “local”, not containing a valid OUI would also flag you as being uncommon. And then, once obtaining an IP, if the first thing your computer does is to talk to Tor also openly available guard nodes IP, you might be ringing whistles. Once again, it depends. Not to be paranoid here, but all of those are readily available open information, and the more “common” you are on the network, the less you shine out of the others. And that is the desired basic behavior.

Long story short, I still think a randomized mac is better then none, but it’s intuition more then factual. I do not have access to data; but I doubt the percentage of consumer devices not reporting hostnames is pretty low and accordingly, shines a bit more on the wire. The less we shine the better.

Example: Support

18

Of course you’re right that “no hostname” is a fingerprint as well. Everything is.

Anyway hoping that a Qubes OS machine is incorrectly fingerprinted by a passive network sniffer as Windows is not plausible either as Qubes OS doesn’t run any SMB shares and doesn’t talk to some domain controllers etc.

IIRC those PC-XYZ configurations aren’t too common either - usually Windows sends its workstation name, too. PC-XYZ was from the Win 2003/8/12 area or so when the hostname wasn’t explicitly configured IIRC. I recall that I had picked that hostname pattern back in the days as I had a hard time finding any other non-unique hostname patterns on the Internet.

I’d rather prefer to have it look like “some Linux”, which is true, but also not very precise. Apparently the “no hostname” is the dhclient default which means that many dhclient devices will do just that. “sys-net” is a 100% Qubes OS fingerprint. It’s at least not unique to a single person, but Qubes OS users are scarce nonetheless.

Btw if you like to, you can use Send-Hostname to set whatever other static hostname you like. I guess one could also dynamically modify the dhclient config via a systemd service if one would really need that.

19

For consistency, community doc removed the section on how to randomize hostname in this commit anonymize MAC & hostname: some updates by 3hhh · Pull Request #203 · Qubes-Community/Contents · GitHub

I updated issue https://github.com/QubesOS/qubes-issues/issues/7701 consequently.

@ninavizz : Seeing the number of questions popping on this forum about mac randomization (which is default) and hostname leak prevention (default under Fedora-34+ : no hostname as part of dhcp requests) is reflective of users not knowing this.

@ninavizz commented that it should have been part of 4.1 releases notes…
But it hasn’t!

As of today, Qubes 4.1:

  • enables MAC randomization by default for wifi (not Ethernet) on both Fedora and Debian templates
  • Has Fedora templates since at least Fedora-34 not leak hostname (absence of /etc/dhcp/dhclient.conf)

https://github.com/QubesOS/qubes-issues/issues/7701 is about implementing the same behavior across all Templates for hostname leak prevention.

Since this is implementation related, the place to discuss this (I believe) is under Qubes issues, not forum posts. Or have all forum posts link to the actual state of things on the matter? @deeplow : throughts?

@adw : can something be made to make this clear to everyone? Can Releases notes be modified?

20

Because the comment was in the wrong place. (It was not on the actual issue that needed to be included in the release notes. Instead, it was in some side discussion on a PR.)

Done:
https://github.com/QubesOS/qubes-doc/commit/09fe4f0cd79fe40dc26d9cb7174998e1ca5f9a3f

2 Likes