es gibt hier eine recht gut verständliche Anleitung zur Nutzung von TAILS: https://capulcu.blackblogs.org/neue-texte/bandi/
Allerdings ist die Anleitung jetzt schon fast zwei Jahre alt und darum wollte ich mal nachfragen, ob sie noch aktuell ist.
Dabei würde mich besonders ein Punkt interessieren:
„WLAN-Adapter als digitaler Fußabdruck“ auf Seite 54. Ist das immer noch so oder gibt es hier schon ein Lösung oder einen Workaround?
Ich verbinde mich nämlich fast immer per WLAN, nur bei mir zuhause hätte ich auch ein Kabel. Das würde für mich dann bedeuten, dass ich Tails nur bei mir zuhause nutzen kann oder habe ich da etwas falsch verstanden?
LG Daniel
@Daniel : Den aktuellen Stand zum Thema findest du unter Tails - MAC Address anonymization. Ich habe das mal überflogen und der Schutz ist immer noch nicht Out of the box implementiert, Zitat:
Active probe fingerprinting. No protection against this is implemented yet.
Es gelten also noch die Vorschläge aus dem von dir verlinkten Handbuch.
Das heißt dann eigentlich TAILS nur am Kabel betreiben?
Wie wahrscheinlich / aufwändig wäre so ein Angriff? Muss da jemand da sitzen und gezielt mich verfolgen. Oder werden die Daten sowieso aufgezeichnet und ein Angreifer muss sich die Daten dann bei Bedarf abholen.
Wie wäre das konkret z.B. wenn sich mein Rechner mit dem Bayern-WLAN verbindet oder wenn sich mein Rechner mit meinem Handy verbindet?
Aktuelle Versionen vom NetworkManger senden nur dann „Probes“, wenn die „automatische Anmeldung“ für ein Hidden WLAN (verstecktes WLAN) gespeichert wurde. Wenn man nur normale WLANs verwendet und im NetworManager speichert, werden keine „Probes“ mehr gesendet. TAILS müsste die Doku mal überarbeiten.
Nein. In der von dir verlinkten Dokumentation wurden ja Maßnahmen genannt wie z.B. die Verwendung von WLAN Adapter, für die es freie Treiber gibt oder Einmal WLAN USB Sticks.
Die Frage nach der Wahrscheinlichkeit wirst im Prinzip nur du beantworten können, sprich: Interessiert sich eine staatliche Stelle für deine digitalen Spuren, die du im öffentlichen Raum hinterlässt?
Welche Daten denkst du denn werden dir gestohlen? Es geht in dem von dir verlinkten Artikel darum, dass die MAC Adresse des WLAN Adapters vom System abgeändert wird, um anonym zu bleiben, dabei aber die neue MAC Adresse aus der dem WLAN Adapter zugehörigen MAC Adresse abgeleitet wird, nicht zufällig ist und schlussendlich eine Identifizierung möglich macht.
Ein Angreifer kann auf verschiedene Arten an die Daten kommen, sogar indem er dich verfolgt, nur dann braucht er deine MAC Adresse nicht, weil er ja weiß wo du warst / bist. Die Daten müssten also wie du schon sagtest vom Access Point geloggt, abgeholt und ausgewertet werden. Das speichern macht nicht jeder Access Point von sich aus. Der Angreifer müsste entlang deiner Route Access Points unter seiner Kontrolle haben. Das geht sicherlich, aber da sind wir dann bei der obigen Frage nach der Wahrscheinlichkeit.
Es geht nicht darum, dass sich dein Rechner mit einem spezifischen WLAN verbindet, sondern dass er permanent seine (leider nicht) zufällige MAC Adresse jedem Access Point mitteilt, ob der Access Point das nun wissen will oder nicht und du somit identifizierbar sein könntest.
Gut zu wissen, nur hatte ich die Macher von Tails so verstanden, dass beim Booten und bis zum Ändern des Modus noch ein Restrisiko erkannt zu werden besteht, oder auch hier muss die Doku noch korrigiert werden. Ich denke aber, dass man bis dahin dem Notebook einen Aluhut aufsetzen kann.
Also wäre eine Lösung den internen WLAN-Adapter zu deaktivieren oder auszubauen und dann, nachdem das Notebook eingeschaltet ist und läuft, den WLAN-Stick einstecken?
Die Daten die Benötigt werden um mich zu deanonymisieren.
Gibt es da eine Anleitung, damit ich das als weniger Versierter Nutzer umsetzen kann?
Das heißt, ich sitze zuhause, habe meinen Rechner mit meinem Handy per WLAN verbunden und werde nicht über die eigentliche Verbindung zu meinem Handy identifiziert sondern weil mein Notebook ständig an alle WLAN Hotspots der Nachbarn seine Daten sendet?
Versteh nicht, was man da anleiten sollte. Einfach nur normale WLANs verwenden und keine Hinnden WLANs (versteckte WLANs, die ihre SSID nicht senden), und dann werden keine „Probes“ mehr gesendet.
Den von dir referenzierten Artikel habe ich mir durchgelesen und unter Linux kann wie von dir geschrieben eine komplett zufällige MAC Adresse generiert werden. Im von @Daniel verlinkten Artikel ( ich beziehe mich auf die siebte überarbeitete von 2021) wird der Beitrag „A Study of MAC Address Randomization in Mobile Devices and When it Fails“ zitiert, laut derer (und hier geht es um Android Smartphones im Jahr 2017) die MAC Adresse nur teilweise abgändert wird und dies ein Problem darstellen kann.
In dem von @Daniel genannten Artikel wird dargelegt, dass selbst bei einer zufälligen MAC Adresse ein Rückschluss auf das Gerät möglich sein kann, sei es über das Timing der Probe Requests oder über weitere Daten, die die gesendeten WLAN Pakete enthalten.
Die Autoren führen als Lösung auf, dass keine Probe Requests gesendet werden sollten, sondern auf Probe Responses vom Access Point gewartet und dann geantwortet werden kann. Und als zweite Maßnahme sollte man WLAN Adapter nehmen, für die es freie Software gibt, weil man dann eine Kontrolle über die Daten hat, die neben der MAC Adresse noch versendet werden.
Ich weiß nicht ob das aktuell geht, aber es wäre die Lösung. Anmerkung: Die Suche deines Rechners nach WLANs hat nichts mit hidden oder non-hidden WLAN zu tun, sie findet immer statt. Eines der IT Mythen ist, dass ein hidden WLAN geschützt ist, weil Angreifer das nicht sehen. Das ist aber nicht richtig, denn auch hidden WLANs lassen sich leicht finden.
Nochmal: Aktuelle Versionen vom NetworkManager senden standardmäßig keine(!) Probes mehr und nutzen statt dessen passives Scanning nach Access Points.
Somit fallen auch alle Probleme durch die Prefered Network List weg. Alle Artikel zu dem Thema, die älter als 3 Jahre sind und vor irgendwas in dem Zusammenhang warnen, sind out-of-date (für alle Linux Version und Android Smartphones).
Es ist dafür nichts zu konfigurieren - alles ok by Default.
Einzige Ausnahme: Nur wenn man ein verstecktes WLAN (Hidden WLAN) nutzt, werden aktive Probes gesendet. Wenn man nicht weiß, was ein „Hidden WLAN“ ist, dann muss man sich auch nicht weiter damit befassen.
Aktuelle Versionen des NetworkManager scannen standardmäßig nach verfügbaren WLANs und senden dafür „Probe Request“ ohne die SSIDs der bekannten Netzwerke. Damit gibt es keine Probleme für die Privatsphäre durch „Probes“, die die Prefered Network List (PNL) verraten könnten. Außerdem werden standardmäßig randomisierte MAC Adressen für das Scannen nach WLAN Access Points genutzt. Warnungen zu dem Thema sind out-of-date. [… Ausnahme: Hidden WiFi…]
Ältere Smartphones sendeten regelmäßig sogenannte „Probe Requests“, um nach WLANs zu suchen. Diese „Probes“ enhielten eine Liste aller WLAN SSIDs (die Prefered Network List, PNL), die das Smartphone kennt und mit denen es sich automatisch verbinden würde. […] Jetzt würde das Ergebnis wahrscheinlich nahe Null liegen, da aktuelle Smartphones nur noch dann „Probe Request“ senden, wenn für versteckte WLANs ein automatischer Login konfiguriert wurde.
Empfehlung des Privacy Handbuch lautet weiterhin: Bluetooth und WLAN nur im Bedarfsfall aktivieren.
Hier muss ich mal eingreifen: Ein Accesspoint sendet keine Probe Requests. Die Verbindung geht immer vom Client aus. Sprich: Dieser sendet ein Probe Request mit der SSID, mit der er sich verbinden möchte. Ein Accesspoint antwortet dann mit dem Probe Response, wenn er die angefragte SSID im Angebot hat.
Das wird in der Dokumentation zu Tails (Link zum PDF Dokument) anders dargestellt. Auf Seite 55 (links unten) wird geschrieben, dass es in Tests möglich war sich ohne das Senden eines Probe Requests mit einem Access Point zu verbinden. Dazu muss der Access Point natürlich einen Probe Response senden, was aber bei der heutigen Dichte an WLAN Clients sicherlich gegeben ist.
Ich erläutere einfach mal, wie sich ein Gerät mit einem WLAN verbindet.
Ein Accesspoint sendet alle 100 ms ein sogenanntes Beacon für jede SSID, die er anbietet.
Der WLAN-Client macht ein sogenanntes passives Scanning. Das heißt, dass er die Luft nach den Beacons und erkennt so, welche WLANs in Reichweite sind. Deshalb listet ein Rechner ja auch alle möglichen WLANs auf, wenn man in die entsprechenden WLAN-Einstellungen klickt.
Wenn du dich erstmalig mit einem WLAN verbinden möchtest, klickst du auf den WLAN-Namen, du wirst dann nach den Anmeldedaten gefragt. Das WLAN wird mit den Anmeldedaten gespeichert. Außerdem ist automatisch die Option aktiviert, dass sich der Rechner selbstständig mit dem WLAN verbindet, sobald dieses in Reichweite ist.
Das bedeutet: Wenn dein Gerät durch das passive Scanning Beacons mit diesem WLAN-Namen sieht, verbindet sich der Rechner. Dazu sendet er ein sogenanntes Probe Request, welches der Accesspoint mit einem Probe Response beantwortet. Dann folgen weitere Schritte, die aber nicht erheblich für diese Diskussion sind.
Es gibt die Möglichkeit, sein WLAN zu verstecken. Dann wird der Accesspoint weiterhin Beacons senden, im Feld für den Namen des WLANs steht aber nichts drin. Das WLAN ist also durchaus sichtbar, nur sein Name nicht. Den herauszufinden, ist allerdings auch kein großes Problem. Deshalb ist das Verstecken des WLANs, was mitunter als Sicherheitsfunktion dargestellt wird, relativ witzlos.
Hast du dein Gerät mit einem solchen versteckten WLAN verbunden, wird in der Regel auch die „automatisch verbinden“-Option aktiviert.
Jetzt hat das Gerät ein Problem: Es soll sich mit dem WLAN verbinden, wenn es in Reichweite ist, aber dieses WLAN zeigt sich nicht mit seinem Namen. Also muss das Gerät regelmäßig nachfragen. Es sendet also ständig Probe Requests mit diesem WLAN-Namen, egal ob du gerade zu Hause, im Büro, am Flughafen, im Zug, am Strand oder sonstwo bist. Genau das ist das bemängelte Verhalten, es wird aktives Scanning genannt. Es ist aber technisch notwendig, um die Funktion „automatisch verbinden“ überhaupt zu ermöglichen.
Abhilfe: Bei versteckten WLANs manuell das automatische Verbinden ausschalten. Oder noch besser: Gar nicht mit versteckten WLANs verbinden.
Vor einigen Jahren habe ich z. B. bei iOS- und Android-Geräten beobachtet, dass diese immer aktives Scanning machen, auch bei nicht versteckten WLANs. Das ist aber schon lange nicht mehr der Fall, das Verhalten wurde abgestellt. Auch von Linux kenne ich das nicht. Ich habe das vor einiger Zeit selbst bei meinen Geräten (Android, Ubuntu, Windows) geprüft.
Entschuldigung, da habe ich dich missverstanden bzw. nicht sorgfältig gelesen.
Du meinst diesen Absatz, nehme ich an:
Nach unserer Warnung im Sommer 2019 gab es Überlegungen unsererseits, wie wir sinnvoll mit der Problematik von Probe Requests und möglichen Angriffen auf das 802.11-Protokoll umgehen können. Eine Richtung, die uns immer noch beschäf tigt, ist das Vermeiden von Probe Requests und die Ermitt-
lung von vorhandenen Access Points über ein passives Lauschen nach Funksignalen (Probe Responses). Die Überlegungen dazu sind in einem Tails-Ticket zusammengefasst: https: //gitlab.tails.boum.org/tails/tails/-/issues/17831 .
Darin schlagen wir vor, Netzwerk-Software 162 unter Debian durch neuere Anwendungen, in denen sich das periodische Scannen nach Access Points deaktivieren lässt, zu ersetzen. In unseren Tests war es darüber möglich, passiv Access Points zu finden und eine Verbindung ohne Probe Requests aufzubauen.
Das Ganze ist bisher nur oberflächlich getestet, aber zumindest eine mögliche Option.
Ich sehe nicht die Behauptung, dass hier die Verbindung vom Accesspoint ausgeht. Wie soll das auch passieren? Der Accesspoint sieht ja den Client nicht, solange dieser keine Daten an ihn sendet. Der Accesspoint kann den Client auch nicht identifizieren und nicht erkennen, dass sich dieser mit ihm verbinden möchte. Den ersten Schritt muss immer der Client machen.
Das genannte Ticket bei Gitlab ist mittlerweile 3 Jahre alt. Ich habe nicht mehr im Kopf, wann ich das aktive Scanning von Mobilgeräten beobachtet habe und wann ich festgestellt habe, dass dies nicht (mehr) stattfindet. Ich denke aber, dass hier ein Gespenst an die Wand gemalt wird. Ich sehe in der Praxis kein aktives Scanning mehr, solange der Client keine versteckten WLANs suchen muss. Ich beschäftige mich mit dem Thema WLAN schon seit über 10 Jahren ziemlich intensiv.
Natürlich werden Probe Requests versendet, wenn sich ein Client mit einem WLAN verbindet. Dies gehört nun einmal zum Verbindungsaufbau dazu, das ist im Standard definiert. In Anbetracht der Tatsache, dass anschließend ja jede Menge weitere Daten vom Client durch die Luft geschickt werden, halte ich einige wenige Probe Requests für sehr unspektakulär. Ich sehe hier keine zusätzlichen Daten, die der potenzielle Angreifer hier gewinnen könnte.
Leider finde ich (auf die Schnelle) auch keine Hinweise darauf, wie der Verbindungsaufbau ohne Probe Requests funktionieren soll. Aber tendenziell sieht der Client anhand des passiven Scannings die verfügbaren WLANs und er könnte direkt mit dem zweiten Schritt weitermachen. Das wäre ein Authentication Request, auf das der Accesspoint mit einem Authentication Response antwortet. Anschließend folgt ein Association Request und ein Association Response. Danach kommt dann die Aushandlung der Schlüssel, um die Datenübertragung zu verschlüsseln.
Ob ein Accesspoint den Verbindungsaufbau beginnend mit dem Authentication Request akzeptiert, weiß ich nicht. Wichtig ist, dass dies nicht nur vereinzelte Accesspoints machen, sondern die überwiegende Mehrzahl bis alle. Jedenfalls würde das nicht dem Standard entsprechen.
Ich möchte auch diesen Satz aus dem Dokument noch einmal herauspicken:
Eine Richtung, die uns immer noch beschäftigt, ist das Vermeiden von Probe Requests und die Ermittlung von vorhandenen Access Points über ein passives Lauschen nach Funksignalen (Probe Responses).
Was soll denn das sein? Vorhandene Accesspoints erkennt das Endgerät durch das passive Scanning anhand der Beacons, nicht anhand der Probe Responses. Probe Responses sind immer eine Reaktion auf Probe Requests. Bei einem WLAN, das seinen Namen aussendet, bringen sie keinen Erkenntnisgewinn. Sie helfen einem Angreifer, den Namen eines versteckten WLANs herauszufinden. Aber geht es bei Tails um den Schutz der Identität des Accesspoints? Nein, nicht wirklich. Es geht um die Anonymität des WLAN-Clients und dessen Benutzers. Dass ich durch Abhören von Probe Responses ein verstecktes WLAN „enttarnen“ kann, ist doch in dem Zusammenhang völlig egal.
Wenn ich mich mit einem versteckten WLAN verbinde und vermeiden möchte, dass jemand sieht, wie das von mir genutzte WLAN heißt, reichen Maßnahmen in dem von mir benutzten Tails nicht aus. Dann muss ich dafür sorgen, dass sich niemand anderes mit dem WLAN verbindet bzw. alle Nutzer auf die Sequenz von Probe Request und Response verzichtet.
Weil aber niemand weiß, wer ich bin (Tails anonymisiert mich ja schließlich), ist das Wissen um das von mir (also der anonymen Person) genutzte WLAN auch nicht relevant.
Mir erscheinen die Ausführungen in diesem Dokument deshalb etwas ungar und unstrukturiert. Ich habe keine Ahnung, welches Problem da gelöst werden soll.
@franz.hartwig : Danke für deine ausführliche Rückmeldung zum Thema. Nach meinem Verständnis gibt es hier zwei Aspekte.
Erstens die Frage nach dem Risiko erkannt zu werden, bzw. der Wahrscheinlichkeit, dass ein staatlicher Akteur versucht herauszufinden wer der Nutzer X ist, der sich am WLAN Y angemeldet hat. Die üblichen Datenkraken können wir in diesem Fall ausschließen, da ich denke dass der Aufwand zu hoch ist und die Daten für diese auf anderem Wege einfacher zu bekommen sind. Die Antwort auf diese Frage kann nur der Nutzer kennen, ich denke aber, dass es die meisten von uns nicht betrifft.
Zweitens die Frage nach dem „Wie“. Und hier scheint es eben laut den oben verlinkten Ausführungen technische Möglichkeiten zu geben und zwar selbst dann wenn die MAC Adresse randomisiert wurde.
Unterm Strich bin ich der Meinung, dass das Risiko vernachlässigbar ist.
