Repository navigation
MAC randomization breaks root server and VirtualBox DHCP / IPv6PrivacyExtensions might be problematic #184
Description
[device-mac-randomization]
wifi.scan-rand-mac-address=yes
[connection-mac-randomization]
ethernet.cloned-mac-address=random
wifi.cloned-mac-address=random
- Breaks root servers, namely broke kicksecure.com. This is what the server provide sent by e-mail.
We have detected that your server is using different MAC addresses from those allowed by your Robot account.
Please take all necessary measures to avoid this in the future and to solve the issue.
We also request that you send a short response to us. This response should contain information about how this could have happened and what you intend to do about it.
In the event that the following steps are not completed successfully, your server can be locked at any time after 2024-01-17 16:51:11 +0100.
How to proceed:
- Solve the issue
- Please note, in case you have fixed the problem, please wait at least 10 minutes before rechecking: ...
- After successfully testing that the issue is resolved, send us a statement by using the following link:...
Please visit our FAQ here, if you are unsure how to proceed:
https://docs.hetzner.com/robot/dedicated-server/faq/error-faq/#mac-errors
Important note:
When replying to us, please leave the abuse ID [...] unchanged in the subject line. Manual replies will only be handled in the event of a lock.
Please note that we do not provide telephone support in our department. If you have any questions, please send them to us by responding to this email.
Kind regards
Network department
- Breaks VirtualBox DHCP when using Network Manger (in Kicksecure) after VM reboot (
sudo reboot). It is functional for the first start after powering off and powering on the VM. [1]
Might be related:
https://forums.virtualbox.org/viewtopic.php?t=86753
Could be a Network Manager issue:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1116421
https://askubuntu.com/questions/307717/networkmanager-problem-with-cloned-mac-address
[1] Before someone says that's a VirtualBox issue, no, I mean, maybe, but that doesn't matter.
VirtualBox is a valid environment. If that breaks, other environments will break as well.
Broken networking is extremely frustrating. MAC randomization would be suitable for Kicksecure, but only if stable.
It's not important enough to break common network configurations in common environments.
TODO: This bug has to be reported to Network Manager (NM) as above bug reports apparently never have reached upstream NM.
Activity
disable MAC randomization in Network Manager (NM) because it breaks V…
adrelanos commentedon Jan 6, 2024
Therefore disabled just now in git.
revert umask 027 by default
[-]MAC randomization breaks VirtualBox DHCP[/-][+]MAC randomization breaks root server and VirtualBox DHCP[/+][-]MAC randomization breaks root server and VirtualBox DHCP[/-][+]MAC randomization breaks root server and VirtualBox DHCP / IPv6PrivacyExtensions might be problematic[/+]adrelanos commentedon Jan 7, 2024
By the same logic I am also reverting IPv6PrivacyExtensions.
It's all nice and dandy for end-users but on servers this can break connectivity to the level that SSH access is no longer possible. Recovering from this isn't trivial.
undo IPv6 privacy due to potential server issues
undo IPv6 privacy due to potential server issues
adrelanos commentedon Jan 8, 2024
No. For years (at least since Whonix for VirtualBox with CLI was released), I always made sure to structure the code so it can easily be used without a desktop environment. And don't hardcode a desktop environment. So contributors can in theory add support for other desktop environments.
https://www.kicksecure.com/wiki/Other_Desktop_Environments
(This is only possible if packages are cleanly separated into GUI and CLI.)
At time of writing, Kicksecure on top of Debian installation instructions contain CLI, there's instructions for chroot.
But there might be some contributed texts in the wiki that looked fine but said "desktop" which didn't come to my attention yet. Fixed some just now:
https://www.kicksecure.com/w/index.php?title=About&curid=2242&diff=79224&oldid=79198
Because only then the config is reload. We didn't have code
Yes. Since I attempted several reboots before, I got an e-mail with the different rejected random MAC address every time.
Isn't that was MAC randomization does?
There are none. And that's not a good environment for experimentation as this triggers the abuse handling team.
adrelanos commentedon Jan 9, 2024
By server I mean server.
kicksecure.comitself runs Kicksecure.Kicksecure is supposed to run on servers too. All. Headless, server, all use cases. All that Kicksecure does shouldn't break any of Debian's functionality more than absolutely necessary. Hence deskop, server, headless, cli, chroot, VM, ISO, however it is called should all be supported.
Right. Not only useless but also breaking connectivity / SSH login. Hence, reverted (commented out) in git.
It probably did not change. Because what I can tell with certainty that once I suspected it MAC randomization broke networking, that I successfully restored server connectivity by deleting these config files followed by a reboot.
If MAC address was still customized (randomized) after deleting these config files, networking would still be broken.
Headless possibly but not on server. The server broke because the server provider does not allow MAC address changes. Each rented server must keep its assigned default MAC address as per server provider policy.
adrelanos commentedon Jan 10, 2024
There's already two build targets for derivative-maker:
--flavor kicksecure-xfce --target iso(resulting ISO comes with Calamares)--flavor kicksecure-cli --target iso(Unfortunately, Calamares does not run in CLI mode. (https://github.com/calamares/calamares/issues/530) So installer is unresolved. Will be looked into at later point.)All packages have suffixes such as
-clior-xfcewhere needed.-cliis supposed to be compatible with servers.Things just need to be correctly split into CLI and GUI packages where needed. Not sure about security-misc.
Maybe one day.
adrelanos commentedon Jan 16, 2024
There is now a ticket for the package split:
security-miscintosecurity-misc-shared,security-misc-desktopandsecurity-misc-server#187Because if suitable at all to implement this, MAC randomization and IPv6 privacy, this only fits yet to be created package
security-misc-desktop.That ticket is also a blocker to make progress here.
Since package
security-misc-desktopwould also be installed by default in Kicksecure for VirtualBox and MAC randomization breaking VirtualBox DHCP as mentioned in my original post, I am not sure this functionality is suitable to have by default in Kicksecure anyhow.Also corporate desktop systems are desktop systems. And in this environments, MAC randomization can break connectivity as they use (however useful, but it's done) MAC filters. There are also LAN based ISPs which are also likely to break.
I've just now spelled out the privacy goals and non-goals for Kicksecure here:
https://www.kicksecure.com/wiki/Privacy
Since Kicksecure is primarily focused on security, not privacy (for anonymity, look into Whonix), this feature has a very low priority for Kicksecure. Since high risk of all sorts of network breakage in different environments, this seems unsuitable to be enabled by default.
Also related:
https://www.kicksecure.com/wiki/Stable_Version_User_Experience
There might be a stronger case why a Whonix-Host should randomize MAC addresses by default. Related Whonix documentation wiki page:
https://www.whonix.org/wiki/MAC_Address
But security-misc package is owned of Kicksecure, not Whonix. Also since Whonix-Host is still unavailable at time of writing, discussing this here is both off-topic and pre-mature. So even if Whonix was to implement this, it would not necessarily through this package security-misc but potentially a different package.
related Whonix forum discussions:
https://forums.whonix.org/search?q=mac%20address
adrelanos commentedon Jan 17, 2024
Tails doesn't just enable MAC randomization or any feature but has a holistic view. Tails has a stronger need for this feature, has documentation and a GUI tool (the first boot wizard) allowing users to easily tinker and disable this feature. Tails doesn't just change any config and then lets users down. This is as per Tails merge policy, "Documentation is not optional".
Whonix VMs don't need MAC randomization but for Whonix-Host there's a stronger argument than for Kicksecure.
related:
MAC randomization while scanning is more reasonable as it shouldn't break networking.
No, DHCP is very much a desktop thing. Most Linux distributions nowadays presumably use Network Manger, which comes with its own built-in DHCP client. But that doesn't matter. Any Linux desktop distribution, Android, iOS come with a DHCP client. The DHCP client gets an internal LAN IP from the router (where a DHCP server is running). If DHCP gets disabled in the router settings, most client devices will have broken networking unless the user sets up static IP configuration.
Kicksecure (or Debian) inside VirtualBox by default uses DHCP through Network Manger's built-in DHCP client. It requests an internal LAN IP from VirtualBox's virtual DHCP server. This was broken, with no solution in sight, hence reverted.
It is what it is. Being universal, not breaking Debian's features more than reasonably necessary has been always the goal. This will get only explained more and made more obvious but this will not change. Long standing quote from https://www.kicksecure.com/wiki/About#Usability_by_Default
We might have some ideological, project goal, differences of opinion here.
Kicksecure isn't just for my personal computer security hardening. It needs to work for the actual users of Kicksecure. Knowingly breaking networking inside VirtualBox is not an option. Kicksecure usability is supposed to be better than Debian or Ubuntu. Ideally, I would like to be on the same level as Elementary OS. But that would require inventing/porting more components. That wouldn't just mean not breaking things and good documentation. Maybe one day. But at least not much worse than Debian.
Ubuntu... Actually not sure nowadays.
ubuntu.comdoesn't seem very user focused at the moment for users looking to download and install a Linux distribution. So my comment is more about how Ubuntu was in the past.On the other hand, you view might be more similar to Arch or Gentoo Linux. Not beginner friendly. Works for me. Good enough. Breaks for someone? Never mind. Up to them to figure it out somehow.
Elaborated on, expanded just now:
https://www.kicksecure.com/wiki/Stable_Version_User_Experience
I am aware of a few corporate users with more interest than I can handle.
adrelanos commentedon Jan 17, 2024
DHCP clients on desktops are the default. There no alternative except static IP configuration, which is cumbersome.
Hence Kicksecure (or Debian + security-misc) inside VirtualBox uses DHCP, which is the most common setup, the default, and to be expected. That shouldn't break since it's a very common use case except you want to exclude VirtualBox or VMs generally.
Right. Quite close.
adrelanos commentedon Jan 17, 2024
But true. A DHCP client (examples: desktop host or VM) makes a DHCP request to a DHCP server (examples: router or virtualizer host software). However, that is very common, very normal, and no reasonable way to avoid it. No way around DHCP. Could argue attack surface is lower without DHCP and that's true but manual IP configuration is pretty difficult for users.
ArrayBolt3 commentedon Dec 26, 2025
Looking at this, I appreciate the sentiment, but don't think that the suggested implementation in the bounty is the correct one. We try to implement as many of our features as possible in packages rather than in installer scripts, so that we have a fairly consistent feature set and user interface across all supported hypervisors and physical machines. Implementing this in Calamares would be possible (and wouldn't even be that challenging, from having written Calamares modules it's probably a three-hour job to get the module itself written), but then only physical machines would get the feature, not virtual machines. Implementing this in upstream Calamares would also be a bit weird since many Linux operating systems probably won't want this.
Now that we have security-misc-desktop and security-misc-server split, maybe we can implement this as a default feature in one of those packages. Alternatively, maybe we could make a configuration utility? Would require some more thought and research, but in any event, I think Calamares is the wrong place to implement this.
adrelanos commentedon Jan 16, 2026
adrelanos commentedon Mar 16, 2026
Found this just now:
https://bounties.monero.social/posts/204/1-610m-add-mac-address-spoofing-configuration-screen-to-the-calamares-installer-linux