MAC Adressen ändern sich von selbst

[dottdottdott]

Hallo,

ich habe das Problem, dass sich bei jedem sleep und reboot die MAC-Adressen ändern (wired und wireless, sowohl usb fals verfügbar).
Ich nutze Debian buster und die installation ist relativ neu, als Network-Manager verwende ich wicd. Macchanger ist nicht für die MAC-Änderung verantwortlich. Die MAC scheinen komplett zufällig zu sein.
Ich bin leider etwas ratlos woran es liegen könnte, kann mir jemand helfen und hat eine Idee?

[breakthewall]

Hinsichtlich des NetworkManager ist ja bekannt, dass dieser stetig die MAC-Adresse ändert, und je nach Bedarf sogar bei jeder neuen Netzwerkverbindung. Bei Wicd könnte das ebenso der Fall sein, auch wenn ich dazu nichts finden konnte. Welcher Desktop wird denn verwendet? Mitunter kann es hier Einstellungen geben, die für das Ändern der MAC-Adresse verantwortlich sind.

[dottdottdott]

NetworkManager ist nicht installiert und das Problem tritt auch auf wenn wicd über systemd disabled ist. Als Desktop verwende ich Awesome WM, allerdings ändert sich die MAC auch, wenn noch kein XServer/WM läuft.

[Taomon]

Zeigt

Code: Alles auswählen

dmesg | grep systemd-udev

irgendwas erhellendes?

Gruß Taomon

[dottdottdott]

Zeigt

Code: Alles auswählen

dmesg | grep systemd-udev

irgendwas erhellendes?

Nein, da finde ich nichts. Ich habe keine Einträge mit udev.

Momentan hat sich das Fehlerbild verändert. Es ändert sich im Moment nur noch die WLAN MAC. Beim Booten habe ich eine zufällige MAC, nach dem ersten sleep habe ich die Hardware MAC. Die MAC ändert sich auch nicht mehr nach jedem Sleep, sondern nur bei etwa 3 von 10 Versuchen, die restliche Zeit bekomme ich jetzt die HW-MAC. Ich habe nichts bewusst am System geändert
Da jetzt scheinbar nur noch WLAN betroffen ist werde ich Karte mal gegen eine mit einem andern Chipset tauschen um ein Treiberproblem aus zu schließen.

[breakthewall]

Ich konnte nach dem expliziten Hinweis auf das WLAN, herausfinden woran das liegt. Um die jeweilige Privatsphäre besser zu schützen, gab es 2016 eine Änderung am Protokoll bzw. am WLAN-Standard selbst. Damit wird die MAC-Adresse grundsätzlich zufällig generiert. Und das erfordert auch keine zusätzlichen Programme die das initiieren.

[BenutzerGa4gooPh]

Ich konnte nach dem expliziten Hinweis auf das WLAN, herausfinden woran das liegt. Um die jeweilige Privatsphäre besser zu schützen, gab es 2016 eine Änderung am Protokoll bzw. am WLAN-Standard selbst. Damit wird die MAC-Adresse grundsätzlich zufällig generiert.

Echt? Ich habe seit Monaten meinen Laptop abwechselnd per LAN und WLAN am Netz. Debian Stretch. Der Laptop hat 2 MAC-IP-Reservations (IPv4) auf dem Router. Kriegt immer die gleichen IPs, auch nach Bereitschaft/Ruhezustand, gerade wieder nachgesehen. Bei MAC-Änderung wäre das nicht der Fall, eine ganz andere IP aus dem dynamischen DHCP-Pool würde genutzt werden. Ich nutze auf dem Gerät network-manager
Des Weiteren funktionieren IP-Mac-Reservations für ein IPhoneSE und ein Android-Tablet und damit meine Paketfilter für deren fixe IPs. Andere IPs (aus DHCP-Pool) würde ich sofort in Firewall-Logs erkennen, weil die Geräte viel quatschen wollen aber nicht dürfen (Drop->Log).

Hinsichtlich des NetworkManager ist ja bekannt, dass dieser stetig die MAC-Adresse ändert, und je nach Bedarf sogar bei jeder neuen Netzwerkverbindung.

Kann ich also nicht bestätigen. Per GUI kann man eine benutzerdefinierte MAC-Adresse angeben. Mach ich nicht.
Zufällige MAC-Änderungen würden zu Authentifizierungsproblemen bei manchen WISPs führen, die MACs prüfen. Des Weiteren wären keine MAC-Access-Listen in WLAN-APs und - Routern mehr möglich und Mac-IP-Reservations würden auch ad absurdum geführt!
Nicht plausibel, so was prinzipiell (default) in ein Protokoll aufzunehmen. Quelle deiner Aussagen? Oder Irrtum - passiert jedem mal.

@TO:
Wie stellst du die MAC-Änderung fest?

Arbeitest du mit IPv4 oder IPv6? Eine IPv6-Adresse wird wohl u. U. zufällig gebildet (Privatsphäre ohne NAT) - habe ich in dunkler Erinnerung, habe mich damit nicht näher beschäftigt. Was dabei mit der MAC passiert, weiß ich nicht.

Eine MAC-Adress-Änderung sollte im Journal stehen, eventuell Gründe, Initiator (wicd?). Die entsprechenden Einträge könntest du mal posten.

Workaround: network-manager - so wicd-Problem. Erst Diagnose, dann Therapie.

[breakthewall]

Kann ich also nicht bestätigen. Per GUI kann man eine benutzerdefinierte MAC-Adresse angeben. Mach ich nicht.
Zufällige MAC-Änderungen würden zu Authentifizierungsproblemen bei manchen WISPs führen, die MACs prüfen. Des Weiteren wären keine MAC-Access-Listen in WLAN-APs und - Routern mehr möglich und Mac-IP-Reservations würden auch ad absurdum geführt!
Nicht plausibel, so was prinzipiell (default) in ein Protokoll aufzunehmen. Quelle deiner Aussagen? Oder Irrtum - passiert jedem mal.

Ich weiß nicht mehr genau wann das kam, entweder mit Version 1.4 oder 1.6 des NetworkManager. Ab dann hatte ich automatisch bei jedem Systemstart eine neue MAC-Adresse. Auch im Bezug auf die Kommunikation mit anderen Endgeräten, gab es nie ein Problem, trotz gegenseitig wechselnder MAC-Adressen. Das mit den WISPs musst näher erklären, zumal die MAC-Adresse des LTE-Routers bzw. Internet-Sticks eigentlich nicht änderbar ist, und den WISP nicht interessieren dürfte was für Endgeräte daran hängen. Solche Geräte sind ohnehin schlecht im Sinne der Privatsphäre. Und wozu sollte man noch auf MAC-Adressen prüfen, wenn das ohnehin kein wirksamer Schutz ist? Das absurde ist eigentlich, dass es solche Funktionen noch gibt, die ebenso Scheinsicherheit zelebrieren, wie das Verstecken der SSID. Aber wer sich damit sicherer fühlt soll es halt nutzen.

Habe die Quelle bei der IEEE nochmal eingesehen, und musste feststellen, dass ich im Halbschlaf besser keine englischen Texte mehr lesen sollte. Es ging dabei nur um einen Vorschlag zur Standardisierung, was jedoch Jahre dauern kann. Doch da das nun wegfällt, wird es ziemlich mysteriös was hier die MAC-Adresse ändert. Da würde mir nur noch einfallen, ob tatsächlich Wicd aktiv genutzt wird, und nicht doch ggf. ein NetworkManager weiterhin präsent ist, ohne es zu merken.

[BenutzerGa4gooPh]

Das mit den WISPs musst näher erklären, zumal die MAC-Adresse des LTE-Routers bzw. Internet-Sticks eigentlich nicht änderbar ist, und den WISP nicht interessieren dürfte was für Endgeräte daran hängen.

Unter WISP verstehe ich einen Wireless-ISP. Also auch Internet per WLAN, nicht nur LTE. Eigene Erfahrung (Internet auf Dorfe ohne DSL-Möglichkeit, kleiner Provider): Der WISP gibt seinen eigenen WLAN-Router dem Kunden nach Anmeldung/Bezahlung mit, WLAN also für Wireless-"Backbone" des WISP, Ethernet für Kundegeräte, -switch. Somit dürfen nur providereigene Router authentifiziert werden. LANCOM hatte (hat?) da ein proprietäres Verfahren, MAC des Provider-Routers (WLAN-IF) in WPAx-Passphrase irgendwie speziell/geheim/proprietär/verschlüsselt eingebunden, MAC und Passphrase bei Authentifizierung geprüft. Keine Admin-Hoheit des Kunden über Providerrouter, deshalb zwar MAC-Adresse spoofbar, verschlüsselte Passphrase mit MAC im wireless Backbone jedoch schwerlich. An den proprietären Namen des (veralteten?) LANCOM-Verfahrens erinnere ich mich gerade mal nicht, müsste suchen.

aktueller: 802.1X/RADIUS kann auch MACs der "Bittsteller" in Authentifizierung (neben Passphrasen) einbeziehen. Wäre also eine weitere Möglichkeit für vom Kunden nicht administrierbare "Zwangsrouter" (in diesem Fall wohl verständlich/akzeptabel) an einem WLAN-Accessnetz des WISP. Soll ja nicht jeder an das "WLAN-Accessnetz" kostenfrei seine eigene Büchse anhängen dürfen, WLAN-APs auf vielen Dächern, Strom und Traffic kosten Geld.

Zertifikate sind natürlich moderner/sicherer, können aber wohl nicht alle Supplicants. Eventuell werden in Firmen auch vorhandene Datenbanken (Active Directory, LDAP) nur mit User/PW zur Authentifizeirung genutzt. (Spoofbare) MAC-Prüfung vielleicht zusätzlich, nur genehmigte "bring your own devices"? In vielen Firmen wird Disziplin durchgesetzt, Spoofing ungern gesehen.

Edit, mal nachgeschaut: Ich arbeite nicht bei dem WISP, es besteht u. a. die Möglichkeit, eine interne RADIUS-Datenbank des zentralen Accespoints (Zugang für providereigene WLAN-Clients bei Kunden = CPE) zu nutzen und so Zertifikate oder User/PW in Verbindung mit MACs der CPE zu prüfen.
https://www.lancom-systems.de/docs/LCOS ... table.html
https://www.lancom-systems.de/docs/LCOS ... 10330.html
https://www2.lancom.de/kb.nsf/1275/46F6 ... 1E003A852B

[dottdottdott]

Danke noch mal für die Antworten.
Network-Manager ist nicht installiert und im Journal habe ich auch nichts finden können (gleiche einträge bei MAC wechsel wie bei konstanter MAC).
Mit einer andern Wlan Karte tritt der Fehler nicht auf, also eventuell ein Probleme mit dem Treiber (ath9k). Ich werde mal versuchen das Problem mit einem anderen Rechner und der Karte zu reproduzieren.

[BenutzerGa4gooPh]

Habe die Quelle bei der IEEE nochmal eingesehen, und musste feststellen, dass ich im Halbschlaf besser keine englischen Texte mehr lesen sollte.

So schlimm ist's schon nicht mit dir.
Habe was zur Randomization gefunden:

MAC Randomization / Zufällige MAC-Adressen
Um das Identifizieren von Geräten und Nutzern über WLAN-Access-Points zu erschweren, setzt man auf zufällig gewählte MAC-Adressen, wenn ein Gerät aktiv nach WLAN-Netzen sucht (Probe Requests). Auf diese Weise wird das Tracking erschwert und die Privatsphäre der Nutzer wieder hergestellt. Die korrekte MAC-Adresse der Netzwerkschnittstelle wird erst dann verwendet, wenn sich das Gerät tatsächlich mit einem WLAN-Netz verbindet.
Diese Funktion existiert ab Windows 10, ab iOS 8 und ab Android 6.

Im Rahmen der IEEE-802-Normen ist es grundsätzlich zulässig, dass IEEE-802-Geräte zufällig generierte MAC-Adressen verwenden können, die nur für die Zeitdauer einer Sitzung konstant bleiben. Es bedarf nur der Umsetzung durch die Hardware-Hersteller.
Die Problematik dabei ist, dass in großen lokalen Netzwerken die Wahrscheinlichkeit von Adress-Kollisionen steigt. Weil zufälligerweise zwei Hosts die gleiche MAC-Adresse haben. Der Betrieb eines lokalen Netzwerks setzt allerdings voraus, dass jede MAC-Adresse einzigartig ist.

Aus diesem Grund wird der Vorschlag diskutiert, fast den gesamten Adressraum für lokal verwaltete MAC-Adressen zu verwenden, um die Wahrscheinlichkeit von Adresskonflikten so gering wie möglich zu halten. Das Problem dabei ist, dass verschiedene Verfahren auf feste Zuweisungen der MAC-Adressen in Middle-Boxen (z. B. Switche, Firewalls, Router, Deep-Packet-Inspection-Systeme) angewiesen sind.

Klar ist, dass zufällige MAC-Adressen für stationäre Geräte weniger sinnvoll und auch nicht notwendig sind. Anders bei mobilen Geräten, die sich in wechselnden Netzen anmelden und hier WLAN-Tracking erfolgen kann. Hier könnte ein Locally Administered Address Space für mehr Privatsphäre sorgen.
Ein Locally Administered Address Space kann auch virtuelle Maschinen mit MAC-Adressen ausstatten, die kein eigenes Hardware-Interface haben.

http://www.elektronik-kompendium.de/sit ... 406201.htm
Aufwand und Probleme wegen des dämlichen Trackings.

[habakug]

Hallo,

hier [1] ist das Verhalten des NetworkManager nochmal erklärt.

The probability of collision is extremely low (because the range of Wi-Fi is some 100 meters). It is like a million times more likely that you loose association because your neighbor turns on his Microwave oven then that he accidentally uses NetworkManager and accidentally choose the same MAC address as you.

Gruss, habakug

[1] https://blogs.gnome.org/thaller/2016/08 ... ger-1-4-0/

[BenutzerGa4gooPh]

hier [1] ist das Verhalten des NetworkManager nochmal erklärt.

Hoffentlich wird man sich in einem weit vergreiteten Standard-Tool wie network-manager bezüglich eindeutiger und verständlicher Defaults einig, ändert diese nicht laufend - und jede Hardware spielt mit. (Abgesehen davon, dass Support-Foren Existenzberechtigung benötigen. )

Randomization during Wi-Fi scanning
...
“permanent”: use the permanent MAC address of the device. Before 1.4.0, the permanent MAC address was used if the “cloned-mac-address” property was left empty, thus it was the default.
“preserve”: don’t change the MAC address of the device upon activation.
...
Update-2017-01-25: with 1.6 release and newer, the default value changed from “permanent” to “preserve” [commit],[bug].

Auzug aus Link von @habakug mit Dank für Infos!