Problems of not doing MAC spoofing on sys-net:
The ISP could collect your real MAC, sell it, or use it for malicious purposes!
The original MAC is associated with whoever bought the PC with the original MAC; therefore, on any network, even when using Qubes OS, without MAC spoofing they will be able to discover who owns that MAC by checking invoices from suppliers, stores, etc… that’s why you need to do MAC spoofing in everything!
Solution:
- Configure the template that is used by sys-net with
setting, services, add network-manager
Enter in the template and:
sudo cat > /etc/NetworkManager/conf.d/00-macrandomize.conf << 'INNEROFF'
[connection]
ethernet.cloned-mac-address=stable
connection.stable-id=${CONNECTION}/${BOOT}
INNEROFF
sudo systemctl restart NetworkManager
In Qubes 4.3, for example, sys-net uses the default template debian-13-xfce!
If sys-net is a disposable template that uses default-dvm as a disposable template, then the template of default-dvm is default-template debian-13-xfce!
In the case of WiFi, sys-net already randomizes the MAC by default by Qubes! Ethernet does not!
Fingerprint in Qubes: hostname is unset (empty), and that can be a problem! Manual solution for certain contexts!
This is a Qubes fingerprint, because by default it doesn’t display the hostname. This is metadata that allows a forensic attacker who has access to your personal router’s logs: if you connect directly to your ISP router or any other external/public network, all devices may have hostnames probably, but with Qubes you won’t — so it becomes inferable that you’re using Qubes, since it’s characteristic of Qubes to use an empty hostname, while most devices have some hostname set by default on the network!
Tails also has a default hostname unset. This is metadata that can be inferred as being Tails or Qubes (or another anonymity OS with the same characteristic)!
This is metadata that can help investigators in researching and correlating certain of your activities in your network ou other!
The ideal is to look like the other devices in the network. One solution is:
Qubes with hostname unset, and all other devices in the network also have hostname unset (empty) too, and then you’ll need to configure this manually on all of them (I mean your home network).
Change hostname manually in Qubes to blend in with other devices and look like them!
Alternatively, if you need, you can set a hostname in sys-net on each login with:
- Disconnect the Ethernet cable or don’t connect to WiFi. Stay offline, make the hostname change first, then connect!
sudo ip link set enk2s0 down
sudo hostnamectl set-hostname YOUR-CUSTOM-HOSTNAME
sudo hostnamectl status
sudo ip link set enk2s0 up
When using the ip link commands to bring the interface up and down, you may get some command output errors, but in tests it always disconnects and reconnects, and the hostname change still takes effect.
Connect to the internet!
Random MAC + custom hostname in sys-net!
Now the Qubes will also have a hostname that resembles the other devices in the network, avoiding those metadata leaks!
In this case, the ideal is to use the sys-net named disposable, which you can choose during installation, so it will always return to hostname unset when needed again. You’ll just have to restart and you’re done!
For me, it’s working well — there’s no leakage of the real MAC address in the tests I ran. If anyone has any issues, please let me know!
Note
The post was edited because many people complained about adding MAC spoofing for Wi‑Fi, since Qubes already does that by default. They also complained about the MAC being randomized using OpenSSL; the ideal approach is to use a MAC with an OUI and set ethernet.cloned-mac-address=stable, using nmcli the way Qubes does by default.
Previously, everything was configured directly in /rw/config/rc.local inside the sys-net or its disposable templates; however, if sys-net or the disposable template gets “bugged,” then /rw/config/rc.local won’t work, which happens in many cases. Sometimes you have to repair sys-net and create a new one for /rw/config/rc.local— at least that happened to me once and I had to repair it.
Other AppVMs or disposable VMs that use the Debian 13 XFCE template (default template) are not affected in the tests.
If you prefer, you can clone the default template, make this configuration, and configure sys-net to use it—leaving the original default template as-is!
I ask the moderators to change the post title, since I can’t edit it!
