ShiftOS(-L): Mac-Adresse im WLAN auswürfeln

Silva

Well-known member
Original poster
11 Januar 2024
672
Es gibt keine Option beim Hinzufügen des WLANs zu sagen ob man seine echte MAC-Adresse ans Netzwerk übermitteln möchte oder nicht.
Ich hätte gerne die Möglichkeit zu sagen: nimm für jede Verbindung in diesem WLAN eine neue zufällige Mac-Adresse um Profilbildung bei WLAN-Betreibern zu unterbinden.
Da nur in wenigen Fällen (IP-Vergabe im Heimischen WLAN zum Beispiel) diese Information echt sein muss, kann man "zufällig" als Standardwert für neue Verbindungen setzen.
 
Das muss standardmäßig funktionieren. Die Adresse muss immer wieder neu generiert und nicht nur bei der ersten Verbindung zu einem neuen Netz einmalig festgelegt werden.
Entwickleroptionen helfen den meisten Leuten nicht weiter.
 
Hat das nicht das Problem, dass gerade bei öffentlichen WLAN die DHCP-Leases dann schnell ausgehen können, wenn das Subnetz ein bisschen knapp ausgelegt ist?
 
Nein. Die verfügbaren Hostadressen pro Subnetz haben nichts mit den Hardwareadressen (Media Access Control adresses) zu tun.
Vielleicht wird's funky wenn Du die MAC alle par Minuten rotieren würdest, dann würde ja auch immer eine Lease frei werden, wenn Du eine neue bekommst. Aber Silva will ja nur bei jedem Connect zu einer WLAN SSID eine andere MAC, mehr oder minder random benutzen.
 
  • Like
Reaktionen: Silva
Woher weiß denn das Netz, dass ein Lease wieder frei ist und nicht nur die MAC ein paar Minuten nix kommuniziert hat? Angenommen mein DHCP Server hat 200 Leases zur Verfügung mit einer Leasetime von 1h, dann kann ich doch mit einem Client und 200 connects das Netz für eine Stunde lahm legen, weil keine Leases mehr da sind. Wo ist mein Denkfehler?
 
Das Netz sendet auf einen Request ein DHCPNACK, "sorry gibt grad nichts" und fertig.
Das führt aber am Ziel vorbei. Es geht hier um die Verhinderung von Profilbildung durch "White Lies" des Clients.
Denial Of Service Attacken sind dadurch allein unwahrscheinlich. Du besuchst einen Laden, einen Ort, gehst wieder und bist beim nächsten Besuch nicht mehr mit deinem ersten Besuch in Verbindung zu bringen.
Wer Netze lahm legen will, geht gezielter vor und nutzt ganz andere Tools.
 
Schon klar. Es wird aber sicherlich einen Haufen öffentlicher WLANs geben, die mies konfiguriert sind. Zum Beispiel ein /24 Subnetz, Leasetime 1 Tag und dann flanieren 50 Leute 5 mal dran vorbei und Ende ist für den Tag.
 
Im ShiftOS kannst du dazu nichts Einstellen in der WLAN Übersicht. Der Teil mit "Privacy" aus der Android Doku fehlt.
 
Woher weiß denn das Netz, dass ein Lease wieder frei ist und nicht nur die MAC ein paar Minuten nix kommuniziert hat? Angenommen mein DHCP Server hat 200 Leases zur Verfügung mit einer Leasetime von 1h, dann kann ich doch mit einem Client und 200 connects das Netz für eine Stunde lahm legen, weil keine Leases mehr da sind. Wo ist mein Denkfehler?
Weil die MACs auf Layer 2 (OSI-Modell) vom ARP (Address Ressource Protokoll) verwendet werden um die Verbindung aufzubauen. Auf einem *NIX-System kannst Du einfach mal arp eingeben, dann siehst Du die Hostnamen und MAC-Adressen, die der Kernel seit Boot so verwendet hat, keine IPs. Heißt, wenn das Netz/der Router dann was an die eben noch gültige MAC routen will, kommt da nix zurück, weil nix ankommt und dann gibt's ein Update des ARP Tables und die Assoziation MAC <-> IP Adresse wird vom DHCP Server neu vergeben.
 
Ist das normales Verhalten, dass der Router aktiv prüft, ob ein Lease wieder "frei" ist? Das Gerät könnte ja noch in der Leasetime zurück kommen. Kenne ich von meinen Netzen so nicht, da bleiben die DHCP-Leases erhalten, so lange wie die Leasetime halt eingestellt ist. Bin aber auch nie in die Nähe von vollständig vergebenem IP-Pool gekommen bisher.
Das das ein lösbares Problem ist, ist auch klar. Ich meinte nur, dass es problematisch sein kann, wenn Geschäfte ein WLAN anbieten und das dann wie so oft keine professionelle Lösung ist, sondern irgendwer da nen Plasterouter hingestellt hat, das Gastnetz aktiviert und nie wieder drüber nachdenkt.