here is how to randomize mac address

[Anonymous]

Randomizing all hardware mac addresses in Qubes OS only requires a simple change to the configuration files of systemd in the default netVM and we recommend that this be the default configuration packaged by the official Qubes developers. Here's how to change it in Qubes 3.0 -
Step 1. Open a terminal on the fedora-21 template VM in which to type the following commands.
Step 2. Create a configuration file to preserve the static mac addresses of qubes provided virtual nics with the following command:
sudo sh -c 'printf "[Match]\nMACAddress=fe:ff:ff:ff:ff:ff\n[Link]\nNamePolicy=kernel database onboard slot path\nMACAddressPolicy=persistent\n" > /usr/lib/systemd/network/98-xen-provided.link'
Step 3. Modify the default link configuration file to create random mac addresses for all other nics:
sudo sed -i s/MACAddressPolicy=persistent/MACAddressPolicy=random/ /usr/lib/systemd/network/99-default.link

These instructions were modeled on method 2.1 for mac address spoofing given at https://wiki.archlinux.org/index.php/MAC_Address_Spoofing

[Michael Carbone]

Anonymous:

Thanks for bringing this up. There is currently an issue discussing how
best to implement MAC address spoofing, feel free to jump in:

https://github.com/QubesOS/qubes-issues/issues/938

Michael

--
Michael Carbone

Qubes OS | https://www.qubes-os.org
@QubesOS <https://www.twitter.com/QubesOS>

GPG fingerprint: 2DBE 2014 E7B0 0730 303D 7AAB 99AB 0624 6EEB F5A8

[timet...@gmail.com]

One needs to be exceptionally careful with randomizing a MAC address these days. The reason why is that every random MAC address is not a valid MAC address. If the random MAC address is not a valid MAC address many routers will reject the address and default to the "burned in" address, thus inadvertently exposing your real address.

The program Machanger tries to get around this problem by allowing one to burn-in a random MAC address. The problem with this approach is that it can, in some circumstances, break networking entirely (which for some users may be preferable to exposing real MAC). The other problem is that--reputedly--there is malware than can still see the real MAC by looking at the firmware data.

My own view is that the safer route is simply to use network manager and spoof the MAC address there. It means that one needs to create each wifi profile by hand before connection but it prevents any automated process from inadvertently unmasking the MAC.

[Unman]

If you look at the discussion Michael refers to, you'll see I proposed
using macchanger in a systemd call as well as the method above.
The advantage in both cases is that MAC gets set well before networking
is initialised. This isn't necessarily the case if relying on Network
Manager.

In my experience I've never had any problem with changing the qubes MAC,
so I wouldn't bother with step2. YMMV

Macchanger provides the -b option to "burn in" only where a fully
random MAC is generated. In that case it *is* possible to generate non
working addresses, as with the udev rule - if you look at the discussion
in qubes-issues I recommend using -e which retains the original vendor
string, (and therefore does not require use of -b since it retains the
BIA bit setting).

unman

[timwelter]

 
If you comments over on github were the last few strung together then I agree and think you made the most complete supported argument for using it thru systemd calls.  Until some goes thru a much more length and difficult path to include with a GUI in NM if possible I think your proposal offer the most.

I have seen projects stalled because of some people worrying so much about yet identified what ifs nothing ever happens or its delayed much more then it ever needed to be.  While its extremely critical for steps to be well thought out and prudent, its another thing entirely to try and reach perfect before taking a single step forward in implementation.  With the TAIls research as a road map you already have a very good map of the process hat is being dealt with.

Further I dealt with lots of travel in the past with months on the road using Hotel wifi/hotspots and very few would have had issue with mac address as was mentioned.

I will be implementing this.

Cheers,

Tim

[Chris Laprise]

On 07/03/2017 11:11 AM, ausafra...@gmail.com wrote:
> I did this exactly and it worked. The Mac address was changed. But can you confirm it is the right way/most Anonymous way of anonymizing mac address, because there are some different and very complicated instructions(which I can't understand ) on Qubes Official website: https://www.qubes-os.org/doc/anonymizing-your-mac-address/
>
> How different is this method from the one given in the official website? Is it less Anonymous/secure than the official method?
> Thanks a lot!
>

There are problems with older versions of Network Manager improperly
reacting to randomization settings (whether its own or coming from
systemd), causing the original address to be exposed under some
conditions. There is more than one issue with these pre-1.4.2 versions.

So its best to use a recent version of Network Manager that supports
randomization properly, then it can be configured directly in a more
fine-grained way than systemd parameters allow... a user can decide if
they want scan-only randomization or guide the randomization with a MAC
bitmask, for example.

The Qubes doc basically amounts to:

1) upgrade template (Debian 9 or Fedora 25 will do)
2) check Network Manager version
3) create a settings file in /etc/NetworkManager/conf.d folder.

The "Configuring Qubes with macchanger" section is a separate method
that often fails; it should be disregarded.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Chris Laprise]

It should be noted that Wifi NICs can be identified by more than just
MAC address. Software developers are just beginning to grapple with this
issue so don't rely on this for thorough anonymization.

[Chris Laprise]

On 07/04/2017 01:34 AM, Ausaf Rashid wrote:
> I have a doubt. My template VM of my NetVM is fedora-23(by default).
> So.. should I need to upgrade to Debian 9 or do I need to upgrade to
> Fedora 24?
> That may seem a noob question, but in the Qubes Website they have shown
> to upgrade to Debian 9, not fedora 24, so will upgrade of Debian 9 work
> in my case? Or should I upgrade my fedora?
>
> Thanks a lot. 😇

(Posting back to public list...)

Its best to install a Fedora 24 or Debian 8 template, then upgrade it.
Fedora 23 template is obsolete and shouldn't be used.

You can install new template in dom0:
sudo qubes-dom0-update qubes-template-debian-8

Then upgrade:
https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/

I personally prefer Debian because it has more software and its update
process is more secure than Fedora.

Hope that helps!

[Chris Laprise]

On 07/04/2017 11:20 AM, Ausaf Rashid wrote:
> So this is what I need to do:
> Upgrade to Debian 9(I had Debian 8 installed, it was just that it wasn't
> being used by any of the VMs)
>
> And then upgrade Fedora 23 to fedora-24.
>
> I need maximum security/Anonymity so I'll be using Debian 9 as you
> suggested.
>
> Then I need to change the templates of all the VMs using Fedora to
> Debian 9, right (I am not sure whether I need to this step)?
>
> Here's the pic of my VM manager which shows which of my VMs use
> Fedora(upgrade to Fedora 24 is not done yet and Debian 9 upgrade is
> going on)
>
> https://drive.google.com/file/d/0B6WGzRCGUJYCeFU0SFliSTVzbzQ/view?usp=drivesdk
>
> Also, just check that the NetVMs of all my VMs are correct(assuming that
> I need to use tor under the protection of Whonix in Anon-whonix app-vm).
> I messed with the NetVMs so it'll be great if you just checked and
> confirmed that it's right.
>
> Also do I need to do steps under:" Compacting the Upgraded Template" in
> upgrading Debian 9 website?
>
> So after Debian 9 upgrade and changing the Template VM of the VMs, I can
> follow the rest of the steps on the website, right?
>

Yeah, its pretty straightforward in that you upgrade to Debian 9 (best
to do this in a clone of Debian 8 but not absolutely required). then
create a netVM (you can call it sys-net2 or similar) and add your
network devices to the Devices tab in the VM settings. If you switch the
old sys-net over to Debian 9 and use that, the settings from the older
Network Manager could cause problems.

You don't have to move the other VMs over to Debian, and you will find
that the Debian template comes with fewer apps pre-installed. This can
cause frustration if you expect all the usual apps to be there; menu
items will disappear. One way to address this is to use 'sudo tasksel'
after the upgrade completes; selecting a Gnome desktop will bring in
most of the usual apps.

[Chris Laprise]

On 07/08/2017 05:07 PM, Ausaf Rashid wrote:
> I made a new net VM(named my new net VM) based on Debian 9 followed the
> website and changed the configuration settings by putting that mac.conf
> file in the location ( did this by opening Gedit from my net VM:"new net
> VM" as root, writing the given codes and saving it at the given
> location, this was the right method right? That is , to save that config
> file from the " new net VM" vm)?
>
> Then I changed the net VM of sys- firewall(that was the only one using
> Sys-net VM, the default NetVM) to "my new net VM". Again is it the right
> thing to do?
>
> But now the problem is that I can't see any interface to connect to WiFi
> ( wireless network) although I am able to connect to Ethernet.
>
> Note that I am able to use the old NetVM and the WiFi interface and WiFi
> works properly. Also that when I checked it I found out that my "new net
> VM" doesn't have Linux firmware installed.
> If this helps.
> Thank you a lot.

(Posting back to qubes-users.)

It sounds like you almost got it: The conf file is saved in the
template, not the netVM. After you do that, shutdown both the template
and the netVM, then re-start the netVM.