Hi,
in unsererm Dorfgemeinschaftshaus mit Freifunk WLAN wurde eingebrochen. Nur der Router blieb stehen :-). Aus der Router-Statistik kann ich erkennen, das zur fraglichen Nachtzeit auch WLAN Clients verbunden waren.
Nun zur Frage: Kann man von den Clients auf die Täter schliessen? Eigentlich ist die MAC doch eindeutig - kann man die noch nachträglich irgendwo auslesen?
Hallo @Mark_Wild!
Aus der gespeicherten MAC kannst du vielleicht noch auf den Hersteller des verbundenen Gerätes oder gar nur des WLAN-Bausteines schließen.
Dazu kommt noch erschwerend, dass es heutzutage „modern“ ist, dass die MAC nach dem Zufallsprinzip wechselt. (Einstellung: Telefon-MAC oder Zufalls-MAC oder ähnlich).
Die bearbeitende Behörde kann also bei Vorliegen eines vermutlichen Tätergerätes (und deaktivierter Zufalls-MAC) sagen, ob dieses Gerät zum Zeitpunkt in das WLAN eingebucht war. Ob das ausreicht?
vy 73 de Peter
Hallo Peter - dank dir für die Info. Ich denke für die Behörde ist ausreichend, wenn wir ihnen die Info geben können, das im Falle eines Verdachts nachgewiesen werden kann, dass der Täter zur fraglichen Zeit vor Ort war. Aber schon da scheitern meine Kenntnisse: Wie kann ich über die Kommandozeile die zur Tatzeit eingebuchten MACs auslesen?
Du vermutlich gar nicht; IPv4-Adressvergabe erfolgt auf dem Gateway, d. h. Du mußt rausfinden, welches Gateway batman-adv zu der Zeit präferierte (wahrscheinlich das gleiche wie aktuell, aber muß nicht so sein) und in dessen DHCP-Server-Logfile dann die MAC-Adressen suchen. Problem: viele GWs sind datensparsam eingerichtet, d. h. ob und was geloggt wird und wie lange das Logfile gespeichert wird, …
Zudem landen in dem Logfile IIRC alle Anfragen aller Knoten (die batman-adv herschickt) über das Batman-Interface: beweisen, daß MAC de:ad:be:ef:23:42 sich genau über den fraglichen Knoten (und nicht den drei Straßen weiter) angemeldet hat, könnte unmöglich sein. (In Gluon machen die Knoten eigentlich nur WiFi-An-/Abmeldung, der Rest geschieht auf den GWs, ganz grob gesprochen. Evtl. findest Du noch was per logread auf dem Knoten.)
Hallo wusel - sorry für meine Unkenntnis, aber eigentich ist doch nur die MAC entscheidend (sofern - wie oben beschrieben - keine Zufalls MAC verwendet wurde).
Und da es nur einen Router gibt, sollte es auch dort ein Logfile geben, welche Clients mit welchen MAC Adressen in den vergangenen x Tagen verbunden waren.
Problematisch dürfte sich allerdings auch hier die von dir erwähnte „Dantesparsamkeit“ erweisen.
Sicher, aber woher wilst Du die kennen? An zwei Stellen hinterläßt ein Client bei einem Gluon-Setup Spuren:
Einmal am Knoten selber (→ logread):
Mon Jun 5 16:30:07 2023 daemon.info hostapd: owe1: STA f2:4f:58:36:82:8a IEEE 802.11: authenticated
Mon Jun 5 16:30:07 2023 daemon.info hostapd: owe1: STA f2:4f:58:36:82:8a IEEE 802.11: associated (aid 1)
Mon Jun 5 16:30:07 2023 daemon.notice hostapd: owe1: AP-STA-CONNECTED f2:4f:58:36:82:8a
Mon Jun 5 16:30:07 2023 daemon.info hostapd: owe1: STA f2:4f:58:36:82:8a RADIUS: starting accounting session DFC02A6D4FD77FB8
Mon Jun 5 16:30:07 2023 daemon.info hostapd: owe1: STA f2:4f:58:36:82:8a WPA: pairwise key handshake completed (RSN)
Und einmal auf dem Gateway:
Jun 5 16:30:08 l2tp-dus03 dhcpd[6272]: DHCPDISCOVER from f2:4f:58:36:82:8a via bat17
Jun 5 16:30:09 l2tp-dus03 dhcpd[6272]: DHCPOFFER on 10.235.96.29 to f2:4f:58:36:82:8a (wusels-Note20) via bat17
Jun 5 16:30:09 l2tp-dus03 dhcpd[6272]: DHCPREQUEST for 10.235.96.29 (10.235.96.27) from f2:4f:58:36:82:8a (wusels-Note20) via bat17
Jun 5 16:30:09 l2tp-dus03 dhcpd[6272]: DHCPACK on 10.235.96.29 to f2:4f:58:36:82:8a (wusels-Note20) via bat17
Ich kenne Euer Netzsetup nicht, wir haben i. d. R. 4 GWs pro Mesh (›Domäne‹), und ohne die Info aus dem Knoten – die spätestens beim Reboot, aber auch sonst nach gewisser Zeit verloren geht – müßte man auf allen GWs suchen, welche Geräte in der fraglichen Zeit »dicovered« haben und könnte dennoch nur raten, ob ein Gerät über den »Einbruchs-Knoten« oder einen anderen ins Netz ging. Tagsüber haben wir in den größeren Netzen ca. 1 DHCPDISCOVER alle 2 Sekunden:
root@l2tp-ber01 ~ # grep DHCPDISCOVER /var/log/syslog | grep "Jun 5 16:30" | awk '{for(i=1; i<=6; i++) printf("%s ", $i); printf("\n");}'
Jun 5 16:30:00 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:01 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:01 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:01 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:01 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:02 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:06 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:10 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:12 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:19 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:19 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:20 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:20 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:21 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:24 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:27 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:29 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:31 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:32 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:37 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:40 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:41 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:46 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:47 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:50 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:51 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:53 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:55 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:56 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:58 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:59 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Jun 5 16:30:59 l2tp-ber01 dhcpd[15972]: DHCPDISCOVER
Falls Du also die STA-CONNECTED-Meldungen von Deinem Freifunk-Knoten aus der fraglichen Zeit noch hast: super. Falls nicht: eher schlecht — außer, das Gateway bedient ausschließlich den fraglichen Knoten. Falls der DHCP-Server dort dann noch so fröhlich mitloggt wie im Beispiel oben, kommt auch der Gerätename ins Logfile — personalisiert ein weiteres Indiz.
Wie gesagt, flott handeln – logread, also das syslog auf dem Knoten, ist sehr flüchtig, sprich: der Puffer wird laufend überschrieben; das syslog auf den Gateways könnte nach 7, aber auch nach schon 1 Tag gelöscht werden – und wissen, wo welche Daten herkommen, sprich, wie aussagekräftig sie sind.
Hi,
lieben Dank für die detaillierte Darstellung - natürlich war mein syslog schon nach 1 Tag überschrieben 
Habe gesehen, das man den Wert auf 7 Tage erhöhen kann (hätte ich mal besser vorher gemacht).
Wie andere hier schon (um)schrieben, ist Gluon maximal ungeeignet für Forensik.
Wir vermeiden Datenaufzeichnung, Logs sind durch RAM-Einschränkungen usw. nicht besonders lang.
Es ist gegen das Interesse von Freifunk seine Nutzer auszuspähen.
Wer sich seinen Router selber per ssh umkonfiguriert, kann das Log vergrößern und gewisse Dinge aufzeichnen lassen (ggf. indem Logs an einen externen Server oder auf einen USB Stick gesendet/gespeichert werden)
Customeinstellungen sind aber meist nach dem nächsten Gluonupdate wieder weg.
Wer sowas braucht/will, muss wohl andere Router ala Fritz!Box installieren, die dann WLAN-Anmeldungen aufzeichnen können, um sie dann gebündelt an eine Mailadresse zu schicken (Push-Benachrichtigungen). Oder Router, die wenigstens einen eigenen DHCP-Server besitzen, der die Geräte ein paar Tage lang auflistet.
Bzgl. Randomization: Android 10 (September 2019) und iOS 14 (September 2020) verbinden sich mit WLANs standardmäßig mit zufälligen MACs, um Nachverfolgung der Nutzer durch WLAN-Anbieter zu erschweren/zu verhindern. (Datenschutz)
Das betrifft den Großteil, dessen was gerade auf dem Markt verkauft wird. Es ist nicht auszuschließen, dass die Diebe ältere Geräte nutzten, aber es ist unwahrscheinlich.
Mehr als ein Indiz, dass jemand da war, hast du also nicht und selbst mit einem umkonfigurierten Freifunk-Accesspoint hättest du kaum mehr.