1. No more Google!
Mit jedem Teil der Artikelserie »Take back control!« haben wir uns näher an das Ziel herangetastet, die Herrschaft und Kontrolle über unsere Daten zurückzugewinnen und die Datenkrake Google von unserem Smartphone zu verbannen. Trotz aller Bemühungen hat sich Google allerdings noch immer an der ein oder anderen Stelle im System eingenistet – diese kleinen »Lücken« gilt es nun noch zu schließen.
Anschließend seid ihr dann mit dem entsprechenden Rüstzeug ausgestattet, mit dem ihr auch in Zukunft die Herrschaft und Kontrolle über euer Android-Gerät bzw. eure Daten behalten könnt.
- Android ohne Google: Take back control! Teil1
- LineageOS – Take back control! Teil2
- Magisk: Bei der Macht von Root – Take back control! Teil3
- AFWall+: Digitaler Türvorsteher – Take back control! Teil4
- F-Droid: Freie und quelloffene Apps – Take back control! Teil5
- AdAway: Werbe- und Trackingblocker – Take back control! Teil6
- Shelter: Big-Brother-Apps isolieren – Take back control! Teil7
- Android-Systemeinstellungen & Google-Fallstricke – Take back control! Teil8
Hinweis
Die nachfolgenden Tipps und Einstellungen sind für LineageOS 16.0 bzw. Android 9.0. Benutzt ihr eine davon abweichende Android-Version könnt ihr die vorgestellten Einstellungen eventuell nicht 1:1 auf eurem System durchführen. Es kann also vorkommen, dass ihr eine Einstellung in einem anderen Menü findet oder auf eurem Gerät so nicht verfügbar ist.2. Ortungsmöglichkeiten | Standort | (A-)GPS
Im Rahmen der Positionsermittlung können Smartphone-Anbieter bzw. Apps euren Standort relativ genau bestimmen. Dies geschieht über verschiedene Datenpunkte bzw. Informationsquellen wie verfügbare WLAN-Netzwerke, eingeloggte Mobilfunkmasten, Bluetooth-Beacons oder GPS-Positionsdaten eures Geräts.
Sofern GPS in geschlossenen Räumen nicht zur Verfügung steht, weicht die Positionsbestimmung auf andere Informationsquellen aus. Eine dieser Informationsquellen ist bspw. die WLAN-/Mobilfunkmast-basierte Ortung, die auch in geschlossenen Räumen eine relativ genaue Positionsbestimmung ermöglicht. Diese Bestimmung erfolgt relativ einfach mittels der vom Smartphone übermittelten WLAN- und Mobilfunk-Informationen. Diverse Anbieter wie Google, Apple, Mozilla und Co. haben über die Zeit gigantische Datenbanken aufgebaut, in denen die genaue Position von Mobilfunkmasten und WLAN-Hotspots bzw. WLAN-SSIDs vermerkt sind. Hierdurch sind sie in der Lage, die mit dem Smartphone gesammelten Informationen mit denen aus den Datenbanken abzugleichen, wodurch die jeweiligen Anbieter sofort Kenntnis über den Standort des Smartphones erhalten können.
Unterstütze den Blog mit einem Dauerauftrag!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Standort nur bei Bedarf aktivieren
Generell solltet ihr die Positions- bzw. Standortbestimmung nicht dauerhaft aktiviert haben. Abgesehen von der hohen Beanspruchung des Akkus, fragen insbesondere Apps aus dem Play Store gerne die Positionsdaten ab, um Bewegungsprofile von Nutzern zu erstellen. Ihr solltet die Standortbestimmung daher nur bei Bedarf aktivieren und lediglich ausgewählten Apps den Zugriff auf die Berechtigung »Standort« erlauben.
2.2 WLAN- und Bluetooth-Tracking deaktivieren
Android sammelt auch dann im Umkreis befindliche WLAN-Netzwerkinformationen und Bluetooth-Beacons, wenn die WLAN- bzw. Bluetooth-Schnittstelle »vordergründig« deaktiviert ist. Das kostet nicht nur Akku, sondern wird von Apps auch zum Positions-Tracking missbraucht. Die permanente Suche nach WLAN- und Bluetooth-Netzwerken könnt ihr folgendermaßen über die Einstellungen deaktivieren:
Sicherheit & Standort -> Standort -> Suche. Entfernt anschließend die Häkchen beiWLAN-SucheundBluetooth-Suche.
2.3 WLAN-Tracking entgegenwirken
Weiterhin gilt es einen Trend zu berücksichtigen, der auch vor deutschen Städten keinen Halt macht: Das sogennante WLAN-Tracking. Anbei ein paar Vorschläge, wie ihr euch davor schützen könnt:
- Wenn ihr außer Haus geht, solltet ihr eure WiFi-Schnittstelle manuell deaktivieren. WiFi-Randomizer oder andere Schutzmechanismen gegen das WLAN-Tracking sind leider nur bedingt dazu geeignet, um Schutz zu bieten. Besser ist es noch immer, die WiFi-Schnittstelle zu deaktivieren.
- Wer die manuelle Deaktivierung der WiFi-Schnittstelle gerne mal vergisst, der kann sich die App WiFi Automatic aus dem F-Droid Store installieren. Ihr wolltet euch überlegen, ob das WLAN aktiviert wird, wenn ihr das Gerät entsperrt und auch nach wie vielen Minuten das WLAN deaktiviert wird, sobald das Display aus ist – je nach Bedarf könnt ihr die Zeiten anpassen bzw. einzelne Funktionen der App auch deaktivieren.
- Unter LineageOS gibt es noch eine elegante Möglichkeit die WLAN-Schnittstelle über ein Systemprofil automatisch zu deaktivieren. Öffnet dazu:
Einstellungen -> System -> Systemprofile -> Standard -> Tippt auf das Zahnrad bzw. Systemicon.
Dort tippt ihr unter
Auslöser, die dieses Profil aktivierenauf WLAN. Wählt dort anschließend euer WLAN aus und legt als Auslöser fest:Beim Trennen
Dann wechselt ihr zurück (1x) und selektiert unter
Drahtlos & NetzwerkeWLAN und legt dort fest:Ausschalten
Was passiert nun? Ganz einfach: Sobald ihr euch vom definierten WLAN trennt oder einfach außer Reichweite kommt, wird sich die WiFi-Schnittstelle automatisch deaktivieren. Ihr müsst in Zukunft also nicht mehr selbst daran denken euer WLAN abzuschalten, sondern über die Systemprofile lässt sich das ganz einfach steuern.
2.4 (A)GPS deaktivieren
LineageOS kontaktiert für SUPL-Daten standardmäßig einen Google-Server unter der Adresse »supl.google.com«. Diese Anfrage beschleunigt die Bestimmung des (GPS-)Standorts bei der Verwendung von Assisted GPS (abgekürzt als A-GPS) – übersendet dabei allerdings bei jedem Aufruf ebenfalls die IMEI-Nummer des Geräts. Das Problem: Die Kombination der IMEI-Nummer mit der Funkzellen-ID ermöglicht dem Betreiber eines SUPL-Servers die eindeutige Identifizierung eines Nutzers, sobald das Smartphone via SUPL-Anfrage den Standort lokalisiert bzw. eingrenzt. Das SUPL-Protokoll ist so gesehen also eigentlich relativ sinnvoll, nur wissen wir nicht, was die Betreiber der SUPL-Server mit diesen Informationen anfangen.
Es gibt zwei unterschiedliche Konfigurationsdateien, in der ein anderer SUPL-Server definiert werden kann:
/etc/system/gps.conf
oder
/vendor/etc/gps.conf
Dort sucht ihr nach folgenden Einträgen:
SUPL_HOST=supl.host.com or IP SUPL_PORT=7275 (kann variieren)
Bisher identifizierte SUPL-Server-Alternativen sind:
- supl.vodafone.com: Standort Deutschland, Eigenhosting
- supl.sonyericsson.com: Standort ist Irland, Hosting bei Amazon
- agpss.orange.fr: Standort ist Frankreich, Eigenhosting
- supl.qxwz.com: Standort China, Hosting unbekannt
- agps.supl.telstra.com: Standort Australien, Eigenhosting
Jetzt müsst ihr euch die Frage stellen, ob euch eine schnelle GPS-Positionsbestimmung via SUPL wichtig ist oder doch vielleicht eure Privatsphäre. Sollte es die Privatsphäre sein, dann müsst ihr folgende Änderung an der gps.conf vornehmen und danach euer Gerät neu starten:
SUPL_HOST=localhost SUPL_PORT=7275
Hinweis
Es genügt nicht die Zeilen auszukommentieren. Dann wird ein Fallback aktiv. Woher die Fallback-Informationen stammen konnte ich leider noch nicht feststellen. Das BQ Aquaris Pro nutzt als Fallback den Google-SUPL-Server. Die SUPL-Anfrage wird übrigens immer nach einem Geräte-Neustart abgesetzt, sobald eine Standortbestimmung erfolgt – über die Einstellungen bzw. GUI lässt sich das Verhalten nicht deaktivieren bzw. steuern.Weitere Informationen zur Thematik und wie man mittels tcpdump kontrolliert, wohin die SUPL-Anfrage abgesendet wird sind im Beitrag »Android: IMSI-Leaking bei GPS-Positionsbestimmung« zusammengefasst.
3. Telefonnummernsuche deaktivieren
Sobald man die Telefon-App startet, sucht die App lokal auf dem Gerät nach der eingegebenen Nummer bzw. dem Namen. Allerdings nicht nur lokal, sondern auch online wird gesucht – standardmäßig über Google. Das bedeutet: Jedes mal wenn ihr lokal nach einer Nummer bzw. Namen sucht, erhält Google diese Informationen ebenfalls.
Das ist aus Datenschutzperspektive natürlich mehr als unschön und ich kann ehrlich gesagt nicht nachvollziehen, weshalb LineageOS solche Funktionen aktiv lässt, ohne den Nutzer darauf hinzuweisen. Immerhin lässt sich die Funktion deaktivieren bzw. auch andere Anbieter auswählen:
Telefon-App starten und rechts oben im Suchfeld auf die drei Pünktchen tippen -> Einstellungen -> Telefonnummernsuche
Dort entfernt ihr die Häkchen bei:
- Vorwärtssuche
- Personensuche
- Rückwärtssuche
Alternativ könnt ihr auch andere Dienste wählen. Beim Dienst für die Vorwärtssuche bspw. OpenStreetMap. Wie gut das funktioniert, habe ich bisher allerdings nicht ausprobiert.
4. Schnittstellen (Bluetooth / NFC)
Moderne Rechner und auch Smartphones sind mit einer Vielzahl an Schnittstellen und Sensoren wie WiFi, Bluetooth, Kamera, Mikrofon, NFC usw. ausgestattet. Insbesondere die nicht verwendeten Schnittstellen sollten, da sie durchaus weitere Angriffsvektoren darstellen, nur dann aktiv sein, wenn ihr sie wirklich benötigt. Für die meisten Android-Geräte bedeutet das: Generell solltet ihr die WiFi-, Bluetooth- und auch NFC-Schnittstelle nur bei Bedarf aktivieren und bei längerer Nichtbenutzung das Smartphone in den Flugmodus versetzen.
5. DNS-Einstellungen
Via DNS wird ein Domainname in eine dazugehörige IP-Adresse übersetzt. Im Grunde ist dies zunächst ein harmloser Vorgang. Allerdings sollte man sich darüber im Klaren sein, dass man bei jeder Kommunikation mit einem DNS-Server mannigfaltige Informationen von sich übermittelt. So wird bei jedem Kontakt des DNS-Servers bspw. immer die (eigene) IP-Adresse inklusive der zu besuchenden Webseite bzw. dem zu besuchenden Webdienst an den DNS-Server transferiert und vielfach von diesem auch abgespeichert. Durch die Auswertung dieser gespeicherten Informationen wäre ein DNS-Serverbetreiber theoretisch in der Lage, euer komplettes Internetnutzungsverhalten feingranular nachzuvollziehen.
5.1 WLAN-Netzwerk
IT-Unternehmen wie Google betreiben oftmals ihre eigenen DNS-Server. Im Falle von Google laufen die Haupt-DNS-Server unter den IP-Adressen 8.8.8.8 und 8.8.4.4. Falls ihr euch mit eurem eigenen oder mit einem fremden WLAN verbinden wollt, empfiehlt es sich, die DNS-Einstellungen eures Smartphones zu kontrollieren. Zumeist sind standardmäßig die Google-DNS-Server eingestellt. Dies solltet ihr vermeiden, indem ihr lieber einen von euch selber ausgewählten DNS-Server einstellt:
Einstellungen → WLAN → Ein langer Fingertipp auf eure aktive WLAN-Verbindung → Bleistiftsymbol (oben rechts) antippen.
Anschließend geht ihr wie folgt vor:
- Wählt »Erweiterte Optionen einblenden« und selektiert bei IP-Einstellungen anschließend »Statisch«.
- Definiert eure IP-Adresse, die des Gateways und ganz unten setzt ihr zum Abschluss die IP-Adresse für den
DNS 1undDNS 2. - Bei DNS 1 und DNS 2 trag ihr jeweils einen neuen DNS-Server ein. In der Empfehlungsecke findet ihr DNS-Server, die weder loggen noch zensieren.
- Alternativ könnt ihr natürlich auch die IP-Adresse eures Routers als DNS-Server eintragen. Ihr müsst dann allerdings auf eurem Router die entsprechenden DNS-Server konfigurieren. Im Normalfall werden euch nämlich die DNS-Server von eurem Netzbetreiber automatisch zugewiesen.
Hinweis
Um herauszufinden, ob die eingestellten DNS-Server auch tatsächlich genutzt werden, eignet sich bspw. der DNS-Leak-Test.5.2 Mobiles (Provider-)Netzwerk
Eine Sonderstellung nehmen die DNS-Server vom Mobilfunkprovider ein. Diese könnt ihr mit herkömmlichen Mitteln nicht einfach über ein Menü für das 4G/5G Datennetzwerk ändern. Das bedeutet: Ihr bekommt von eurem Mobilfunkanbieter DNS-Server fest zugewiesen. Es gibt allerdings drei unterschiedliche Lösungswege, mit dem ihr den DNS-Server eures Mobilfunkanbieters »überschreiben« könnt.
[1. Lösung] Bei der schnellen Lösung aktiviert ihr einfach DNS over TLS (DoT) – möglich ab Android-Version 9.x (Pie). Alle DNS-Anfragen und Antworten werden anschließend über eine TLS-gesicherte Verbindung übertragen, die zwischen eurem Android und einem DNS-Server aufgebaut wird. Die Aktivierung von DoT ist relativ simpel:
Einstellungen -> Netzwerk & Internet -> Erweitert -> Privates DNS
- Selektiert dort
Hostname des privaten DNS-Anbieters - Im Feld darunter tragt ihr dann die Adresse des DNS-Servers ein, der DoT unterstützt. Empfehlungen findet ihr hier.
- Beispiel dismail.de:
fdns1.dismail.de
- Beispiel dismail.de:
Anschließend werden alle DNS-Anfragen, die von eurem System abgesetzt werden, via TLS-verschlüsselter Verbindung zum gewählten DNS-Server übermittelt und beantwortet. Dies ist eine globale Einstellung und gilt für alle Netzwerk-Interfaces (WLAN, Mobil etc.).
[2. Lösung] Bei der zweiten Lösung seid ihr flexibler bzw. die DNS-Einstellungen gelten nicht global für alle Schnittstellen. Der Eingriff ist allerdings komplexer und erfordert die Nutzung der CustomScripts der AFWall+. Mit folgendem Codeschnipsel könnt ihr andere DNS-Server für das mobile Interface (rmnet*) erzwingen:
# Force a specific dns server for rmnet[*] interface $IPTABLES -t nat -I OUTPUT -o rmnet+ -p tcp --dport 53 -j DNAT --to-destination 116.203.32.217:53 $IPTABLES -t nat -I OUTPUT -o rmnet+ -p udp --dport 53 -j DNAT --to-destination 116.203.32.217:53
Nachteil dieser Lösung: Die DNS-Anfragen werden nicht verschlüsselt, sondern im Klartext übermittelt. Im vierten Teil der Serie ist der Umgang mit AFWall+ bzw. CustomScripts ausführlich beschrieben.
[3. Lösung] Denkbar ist auch die dauerhafte Nutzung eines VPN-Tunnels. Bei dieser Variante werden die DNS-Server vom VPN-Gateway vorgegeben und der gesamte Verkehr über den VPN-Tunnel abgewickelt – also ebenfalls die DNS-Anfragen. Bei dieser Lösung benötigt ihr allerdings eine VPN-Gegenstelle bzw. Gateway. Am ehesten eignet sich für die Umsetzung ein Raspberry Pi, OpenWrt-Router oder vergleichbares mit WireGuard, der zu Hause auf die Anfragen von unterwegs wartet. Dann könnt ihr den gesamten Traffic – egal ob fremdes WLAN oder Mobilfunknetz – durch den VPN-Tunnel leiten und profitiert ebenfalls von euren lokalen Erweiterungen wie einem Pi-hole bzw. Unbound & Hyperlocal etc.
Diese Variante funktioniert in der Praxis außerordentlich gut, da das WireGuard-Protokoll schnell eine Verbindung aufbaut, kaum Overhead mitbringt und äußerst stabil läuft. Eindeutig zur Nachahmung empfohlen.
6. Captive-Portal
Zum Captive-Portal-Check hatte ich bereits einen Abschnitt im vierten Teil der Serie untergebracht. Zur Erinnerung:
Zur Prüfung, ob eine Verbindung zum Internet besteht, sendet Android eine Anfrage an die Adresse »connectivitycheck.gstatic.com«. Ist die Anfrage erfolgreich, besteht Zugang zum Internet. Mit dieser Anfrage übermittelt das System jedes Mal Informationen zur IP-Adresse des Anschlusses, dem Zeitpunkt des Internet-Zugangs und welcher Browser aktuell verwendet wird an Google. Gerade datenschutzbewusste Nutzer wollen allerdings nicht jedesmal einen »Ping« an Google versenden, wenn sie online gehen.
Mein Lösungsvorschlag:
- Entweder ihr deaktiviert den Captive-Portal-Check vollständig
- oder ihr nutzt einen alternativen Captive-Portal-Check. Unter der Adresse »captiveportal.kuketz.de« biete ich einen solchen Captive-Portal-Check an – es wird nichts geloggt oder ausgewertet.
Für welche Variante ihr euch auch entscheidet, in der Empfehlungsecke ist ausführlich beschrieben, wie ihr den Captive-Portal-Check vollständig deaktiviert oder einen alternativen Server verwendet.
7. Geräteverschlüsselung
Die Vollverschlüsselung eines Smartphones soll Angreifern nach einem Diebstahl den Zugriff auf die Daten des Geräts erschweren. Alle aktuellen Modelle werden im Normalfall ab Werk mit einer aktiven Geräteverschlüsselung ausgeliefert. Ausnahmen finden wir allerdings bei Custom-ROMs – auch bei LineageOS. Je nach Maintainer bzw. Problemen bei der Anpassung für LineageOS kann es vorkommen, dass die Geräteverschlüsselung (temporär) nicht aktiviert ist. Ist die Geräteverschlüsselung nicht aktiv, solltet ihr wie folgt vorgehen:
- Erkundigt euch im XDA-Forum oder beim Maintainer, weshalb die Geräteverschlüsselung nicht aktiv ist
- Gibt es dafür keinen nachvollziehbaren Grund bzw. ist eine Geräteverschlüsselung problemlos für euer Gerät aktivierbar, dann solltet ihr diese auch aktivieren
- Vor der Aktivierung der Geräteverschlüsselung solltet ihr eure Daten (regelmäßig) sichern. Falls der (Verschlüsselungs-)Vorgang abbricht oder ihr euch nicht mehr an die PIN/Passwort erinnert, ist die Verschlüsselung nur mit einem Zurücksetzen des Geräts rückgängig zu machen – und dabei gehen alle Daten auf dem internen Speicher verloren.
Falls die Geräteverschlüsselung bei euch noch nicht aktiv sein sollte, solltet ihr das wie folgt nachholen:
Sicherheit & Standort -> Erweitert -> Verschlüsselung & Anmeldedaten -> Smartphone verschlüsseln
Beachtet bitte die Hinweise auf dem Bildschirm, bevor ihr die Verschlüsselung ausführt. Anschließend werden alle (Benutzer-)Daten des internen Gerätespeichers verschlüsselt. Zu beachten ist, dass bisher nur der interne Gerätespeicher verschlüsselt wird, Daten auf einer eventuell vorhandenen externen (SD-)Speicherkarte oder Daten, die in der Cloud gespeichert werden, jedoch nicht. Ihr könnt euch überlegen, ob ihr die eventuell vorhandene (SD-)Speicherkarte ebenfalls verschlüsselt. Hierbei solltet ihr bedenken:
- Aufgrund der Verschlüsselung lässt sich die (SD-)Speicherkarte nicht mehr entnehmen und einfach am PC benutzen.
- Wollt ihr euer Smartphone zurücksetzen, dann solltet ihr zuvor nicht vergessen, die SD-Karte wieder zu entschlüsseln. Andernfalls könnt ihr auf die Daten später nicht mehr zugreifen und müsst die SD-Karte neu formatieren.
8. Displaysperre einrichten
Eine aktive Geräteverschlüsselung ist nur der erste Schritt. Mindestens ebenso wichtig ist ein sicheres Passwort bzw. PIN, mit dem der Zugriff auf das Smartphone geschützt wird. Es gilt folgender Merksatz:
Die Geräteverschlüsselung bzw. der Schutz, den sie bietet, ist nur so gut, wie das verwendete Passwort / PIN.
Das bedeutet: Der Sinn und insbesondere die Sicherheit der Geräteverschlüsselung steht und fällt mit der Qualität des verwendeten Passworts / PINs. Dieses insbesondere deshalb, weil Google noch immer keinen (softwareseitigen) Brute-Force-Schutz integriert hat, der das Gerät bspw. nach der dritten Fehleingabe einfach herunterfährt.
Folgendes müssen wir uns daher schonungslos vor Augen führen: Das Passwort bzw. die PIN stellt die einzige Hürde dar, die ein Angreifer überwinden muss. Ist das Passwort schlecht gewählt oder die PIN zu kurz, kann ein Angreifer mit vertretbarem Aufwand (bspw. Brute-Force-Angriff) Passwort bzw. PIN berechnen.
8.1 Rechenbeispiel
Bei einer vierstelligen PIN existieren insgesamt 10^4 unterschiedliche Kombinationen, also insgesamt 10000. Im Mittel benötigt ein Angreifer also 5000 (10000 / 2) Versuche, um die PIN zu berechnen. Folgendes gilt es zu berücksichtigen:
- Nach 5 Fehlversuchen erzeugt Android (Pie) eine 30-Sekunden-Verzögerung zwischen der nächsten Eingabe
- Ab der 11. Fehleingabe erzeugt Android (Pie) nach jeder Fehleingabe eine 30-Sekunden-Verzögerung
Das ergibt ca. einen mittleren Zeitaufwand von: 5000 * 30 Sekunden = 150000 Sekunden. Das entspricht:
- 2500 Minuten
- 41,666 Stunden
In gut 41 Stunden ist eine vierstellige PIN im Mittel zu knacken. Zum Vergleich eine achstellige PIN:
- 25000000 Minuten
- 416666,666 Stunden
- 17361,111 Tage
- 2480,158 Wochen
- 47,564 Jahre
Rein rechnerisch betrachtet stellt die Verwendung einer achtstelligen PIN auch einen versierten Angreifer vor ein Problem – außer natürlich, er kann sich eine Schwachstelle (bspw. Umgehung der 30-Sekunden-Verzögerung) zu Nutze machen und den Vorgang beschleunigen. Unsere Überlegung klammert Geheimdienste und andere Organe mit entsprechenden finanziellen Mitteln und Manpower natürlich aus. Es wäre utopisch zu glauben, dass ein achtstelliger PIN jeden Angreifer aufhalten würde – dem ist nicht so.
8.2 PIN | Passwort
Android bietet euch unterschiedliche Displaysperren an:
- Keine
- Wischen
- Muster
- PIN
- Passwort
Ihr solltet in jedem Fall eine PIN oder Passwort wählen. Sowohl die Option Keine als auch Wischen bieten keinen Schutz und führen die Geräteverschlüsselung ad absurdum. Von der Entsperrung via Entsperrmuster (Pattern) solltet ihr ebenfalls absehen. Verglichen mit einem ausreichend langen PIN / Passwort leiden Entsperrmuster bspw. an wenig Kombinationsmöglichkeiten und sind oftmals wenig komplex.
Rein rechnerisch bietet eine achstellige PIN einen ausreichenden Schutz gegen einen Angreifer. Ihr könnt natürlich auch eine längere PIN oder ein komplexes bzw. langes Passwort (Maximal 16 Zeichen) wählen, um euer Gerät zu schützen. Das hängt ganz von eurem persönlichen Bedrohungslevel ab.
Damit ihr eure PIN bzw. Passwort nicht bei jedem Entsperrvorgang eingeben müsst, bietet euch Android eine Entsperrung via Fingerabdruck an – sofern euer Gerät einen Fingerabdrucksensor integriert hat. Ob ihr diesen Fingerabdrucksensor nutzen wollt, ist von euch abhängig. Allerdings sollte man bedenken, dass biometrische Merkmale wie Fingerabdrücke, Gesichter etc. imitiert werden können – es gibt sogar bereits sogenannte »Generalschlüssel« (künstliche Fingerabdrücke), mit denen sich der Fingerabdrucksensor überlisten lässt. Der 0815-Dieb von der Kirmes wird sich vermutlich allerdings kaum die Mühe machen, den Fingerabdrucksensor zu überlisten – möglich ist es aber. Das solltet ihr bei der Einrichtung berücksichtigen:
Sicherheit & Standort -> Displaysperre
- Wählt dort »PIN« und vergebt eine mindestens achtstellige PIN. Je nach Sicherheitsbedarf bzw. eurem individuellen Risikomanagement sind natürlich auch längere PINs oder sogar ein Passwort denkbar.
- Nachdem ihr die PIN festgelegt habt, solltet ihr das Systemicon (ganz rechts) in der Zeile »Displaysperre« antippen. Dort solltet ihr die Zeit für das »automatische Sperren« nicht höher als 30 Sekunden setzen.
8.3 WrongPinShutdown
Mit der F-Droid-App WrongPinShutdown könnt ihr einen softwareseitigen Brute-Force-Schutz nachrüsten. Innerhalb der App könnt ihr einstellen, nach wie vielen fehlgeschlagenen Anmeldeversuchen das Gerät abgeschaltet wird. Standardmäßig sind 3 Fehleingaben voreingestellt:
Nach einem Neustart des Geräts wird ein potenzieller Angreifer erneut mit der PIN- bzw. Passworteingabe konfrontiert. Die Verzögerungen bzw. Timeouts sind dann allerdings länger – nach mehrmaliger falscher PIN-Eingabe werden Timeouts von ca. 20 – 30 Sekunden erzeugt. Nach ca. 50 Fehleingaben erscheint dann auch die Meldung:
Achtung: Sollten die nächsten 9 Versuche, das Gerät zu entsperren, fehlschlagen, werden die Gerätedaten gelöscht!
9. Fazit
Die Wiedererlangung der Datenhoheit im Android-Universum ist kein Ziel, das sich mal eben so an einem freien Wochenende erreichen lässt. Der Weg zu mehr Selbstbestimmung ist steinig und voller unvorhersehbarer Stolpersteine. Aber die Mühe lohnt sich – auch wenn ein »blinder Fleck« bleibt. Denn sobald ihr Daten mit anderen Menschen austauscht, sei es über E-Mail oder Messenger, so gibt es schlichtweg keine Garantie, dass die übermittelten Daten vom Empfänger sensibel behandelt werden oder nicht direkt nach Erhalt in der Microsoft-Cloud landen bzw. die Kontaktdaten via Google-Konto synchronisiert werden.
Es ist also nicht damit getan die Artikelserie 1:1 umzusetzen. Denn selbst wenn ihr mit euren Daten verantwortungsvoll umgeht und ausschließlich Dienste und Software einsetzt, mit denen ihr die Kontrolle behaltet, seid ihr eben immer externen Einflüssen ausgesetzt. Daher gilt auch weiterhin: Macht euch die Mühe und klärt andere Menschen auf – in der Empfehlungsecke findet ihr eine ganze Menge an Tipps und Anregungen, die auch für eure Mitmenschen von Interesse sein könnten.
Rückblickend ziehe ich eine positive Bilanz und bin überzeugt, euch einen praktikablen Weg aufgezeigt zu haben, mit dem ihr die Herrschaft und Kontrolle über euer Android-Gerät bzw. eure Daten auch in Zukunft behalten könnt.
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Konfigurationsempfehlungen – Android unter Kontrolle Teil5
iodéOS: Datenschutzfreundlich, aber Abstriche bei der Sicherheit – Custom-ROMs Teil3
CalyxOS: De-Googled geht anders – Custom-ROMs Teil2
/e/: Datenschutzfreundlich bedeutet nicht zwangsläufig sicher – Custom-ROMs Teil6
Airgeddon: Wie WLANs gehackt werden und wie man sich davor schützt
36 Ergänzungen zu “Android-Systemeinstellungen & Google-Fallstricke – Take back control! Teil8”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Gibt es die VPN Pi-Lösung mit Pi-hole und OpenVPN auch mit Pi-hole und Wireguard und wenn ja, lohnt es sich von OpenVPN auf WireGuard umzusteigen?
Klar.
Du kannst WireGuard mit Pi-hole kombinieren. Sobald WireGuard offiziell in Debian Stable angekommen ist, werde ich dazu eine Anleitung verfassen.
Und nun: Back to topic, bitte. ;-)
Danke für den Hinweis auf die alternativen SUPL-Server, werde ich mal ausprobieren.
Wäre dies nicht auch etwas für die Empfehlungsecke „Alternative Google-Dienste“ ;-)
Bzgl. der App „WiFi Automatic“ kann ich Deiner Empfehlung nicht folgen die Option „Schalte WLAN aus… wenn kein Netzwerk in Reichweite“ zu deaktivieren. In meinem Umfeld sind sehr sehr viele WLANs und die App schaltet zuverlässig WLAN aus, wenn ich mich außerhalb meiner „gemerkten“ WLANs befinde. (Ich denke die Option hat einen etwas unglücklichen Titel)
Die LOS-Option per Trigger WLAN auszuschalten, ist zumindest für mich nicht brauchbar. Vermutlich durch die vielen WLANs in der Umgebung, kommt es immer wieder zu kurzfristigen WLAN-Abbrüchen (obwohl das Gerät unbewegt auf dem Tisch liegt, tritt mit diversen Geräten auf).
Die LOS-Option macht was sie machen soll und deaktiviert sofort das WLAN und der Nutzer (ich) bin dann überrascht, daß ich mich plötzlich im mobilen Datenbereich bewege :-(
Mit der o.g. App Wifi Automatic und einer Wartezeit von 1 Minute, macht das Gerät sofort wieder einen WLAN-Verbindungsaufbau und der WLAN-Abbruch bleibt vom Anwender unbemerkt (wie bei 99% aller Anwender, die sowieso immer das WLAN anlassen)
noch ein Nachtrag zum Änderung von gps.conf
Meiner Erfahrung nach wird die Änderung bei jedem LOS-Update leider überschrieben :-(
Hmmm. Das gilt es zu beobachten. Ist mir noch nicht aufgefallen.
Bei meinem Aquaris X mit LOS16 sind die supl.host-Zeilen bereits mit # deaktiviert. Muss ich # entfernt und die o.a. Änderung vornehmen?
Steht doch alles im Beitrag. Im Zweifel testen. Steht auch im Beitrag.
Ja, du hast Recht. Habe die Passage angepasst. Keine Ahnung wie ich darauf gekommen bin.
Hallo Mike,
danke für den Artikel. Ein Teil davon lässt sich auch auf Stock Android übertragen, vieles habe ich bereits umgesetzt.
Zu WrongPinShutdown wünsche ich mir noch mehr Informationen.
Welche Informationen fehlen denn? Umfangreich ist die App ja nun wahrlich nicht. Anzahl der Fehlversuche einstellen und bei Bedarf den Befehl zum ausschalten ändern. Fertig.
Ist die Artikelserie hiermit nun abgeschlossen oder kommt da noch eine 9te usw. ?
Ich frage deswegen weil
“ Rückblickend ziehe ich eine positive Bilanz und bin überzeugt, euch einen praktikablen Weg aufgezeigt zu haben, mit dem ihr die Herrschaft und Kontrolle über euer Android-Gerät bzw. eure Daten auch in Zukunft behalten könnt. “
sich so liest, als ob alles wichtige nun gesagt/geschrieben sei !
Das ist der letzte Teil der Serie.
Ergänzend, allerdings Android 8:
So hilfsbereit und aufmerksam, wie hilflos wären wir ohne das große G ;-)
Standort immer aktiviert lassen geht auch: Man installiert einfach alle Goohle Play Apps uaf das Arbeitsprofil. Dann kann man unter Standort > „Standort in Arbeitsprofil verwenden“ deaktivieren.
Dann gewährt man nur OSMAnd Zugriff auf den Standort. Das fragt den Standort nur ab, wenn man die App aufruft.
Mir ist unklar, wie man die Datei /vendor/etc/gps.conf ändert. Mit Amaze scheitere ich, den Pfad zur Datei zu finden. Nutze ich Termux + Nano kommt die Meldung, dass die Datei ‚unwritabel‘ ist. Bei Magisk hat Termux Superuser-Rechte. Nutze ich TWRP, dann mit welchem Editor? Hier fehlen mir die Kenntnisse.
Der Zugriff ist nur mit Root-Rechten möglich. Für Amaze kannst du das in den Einstellungen freischalten.
Mit Termux musst du zunächst mit `su` die Rechte erweitern, sonst nutzt es nichts, dass Termux prinzipiell über root Rechte verfügt.
Unter Termux+Nano ist die Datei gps.conf meist schreibgeschützt, da der Pfad zur datei meist unter /system (Herstellerabhängig) befindet und /system immer nur lesend eingehängt ist (manchmal auch nur per link dort hin, z.B. /vendor unter amaze leitet dann weiter auf /system/vendor , je nach modell ).
Dies läßt sich mit rootrechten unter Termux mit
mount -o rw,remount /system
beheben, um /system lesend und schreibend bis zum nächsten reboot einzuhängen (der Amaze(-Editor) macht das hingegen automatisch). Dann klappt es auch mit nano.
Mit
mount -o ro,remount /system
läßt es sich der Schreibzugriff wieder rückgängig machen.
Da die gps.conf aber leider bei jedem update wieder überschrieben wird, empfiehlt es sich aber unter /data/eigenerordner/ eine sciptdatei zu erstellen, die die selbst dort abgespeicherte und modifizierte gps.conf „rüberkopiert“.
Die scriptdatei oder weitere läßt sich auch mit weiteren modifikationen erweitern, z.B. mit einträgen aus losdiet um nicht benötigte LOS-Apps, die mit jedem update wieder installiert werden, zu entfernen.
Generell, was vielleicht oben noch fehlt:
Temporäres MAC-address spoofing für WLAN, wenn man sich ab und an unbedingt in femde Netzte einwählen möchte.
Danke für die schöne Serie und vor allem für die Info, daß das auskomentieren der suppl zum fallback führt.
Dank der Hinweise (’su‘ und ‚mount -o rw,remount /system‘) konnte ich die gps.conf erfolgreich ändern! Das mit der sciptdatei klingt sehr interessant. Für mich allderdings ohne Anweisung aktuell zu schwierig (.sh, crontab, chmod, chow..?). Ich bin schon am nächsten Schritt gescheitert tcpdump zu installieren ($ pkg install tcpdump?!), um „$ tcpdump -i any -s0 port 7275“ auszuführen.
Bei mir war die Datei weder mit Amaze mit Root-Rechten noch über adb zu ändern. Auch ein mount -o rw,remount /system half nicht.
Auf meinem Phone ist die passende Datei /system/etc/gps.conf
Funktioniert hat nur:
1. ins TWRP-Recovery booten
2. system-Partition mounten
3. mit adb shell verbinden
4. über den vi-Editor die Änderung vornehmen.
Habe mein Aquaris nach Mikes Anleitung soweit ans laufen gebracht. Um es in Zukunft aktuell zu halten, würde ich aber gerne noch wissen, wie man mit den Updates verfahren muss. Denn wenn ich es richtig verstehe, darf man z.B. nicht alle auf dem Aquaris erscheinenden Update-Angebote annehmen, sondern muss z.B. Firmware-Updates nach Mikes Anleitung durchführen, um keine Daten zu verlieren (https://www.kuketz-blog.de/android-firmware-update-bq-aquaris-x-pro/). Wie ist es aber z.B. mit den Aquaris-Meldungen zu TWRP („TWRP App Update Required“) oder Magisk („Aktualisierung für magis Manager verfügbar!“)? Muss man hier z.B. bestimmte Reihenfolgen einhalten – wie vielleicht zuerst Firmwareupdates oder Magisk oder TWRP? Woran muss man noch bei Updates denken? Danke im Vorraus…
Die Frage hat mit dem vorliegenden Beitrag wenig zu tun.
Empfehlenswerte Reihenfolge: TWRP, Firmware, Custom-ROM, Magisk.
Vielen Dank für diese Info.
Bezüglich Off-Topic: Da viele Nutzer Probleme nach Updates bekommen haben, fehlt aber dann ein wichtiger Teil Deiner „Take back control“ Reihe, etwa „Updates – das Aquaris/Lineage sicher und aktuell halten“. Es hilft ja nichts, wenn man das Aquaris mühlselig aufgesetzt hat und man es sich durchs Aktualisieren zerschießt bzw. keine Aktualierungen mehr durchzuführen traut.
Auch was z.B. für ein Upgrade auf LineageOS 16.0 ohne Datenverlust zu beachten ist, würde sicher viele interessieren.
Upgrades, also Sprünge von bspw. LineageOS 15.1 auf eine höhere Version wie 16 Verhalten sich im Grunde genommen wie »Neuinstallationen«. Mit einer Ausnahme: Es wird nichts gewiped bzw. gelöscht, sondern einfach über die bestehende Installation installiert. Siehe Punkt 6.1 – ohne Löschen.
Firmware-Updates habe ich bereits in einem kleinen Microblog-Beitrag beschrieben: Firmware-Update BQ Aquaris X Pro
Ein paar weitere Fragen:
(1) Wenn das Telefon verschlüsselt ist und mittels Display-Sperre und bsp. WrongPinShutdown geschützt ist, sollte man die ‚SIM-Kartensperre‘ trotzdem aktiviert haben?
(2) In den Einstellungen gibt es den Punkt „Trust“. Kann man damit sinnvolle Einstellungen treffen?
(3) Zu Updates: LineageOS-Update werden täglich zur Verfügung gestellt. Auch wenn es nicht immer Change-Logs gibt. Ich habe daraus für mich ein wochentliches Update abgeleitet. Falls es dazu mehr zu wissen gibt, wäre das interessant.
Danke für diesen Blog und Serie.
Zuvor hatte ich ein einfaches Nokia Mobiltelefon genutzt. Ich war so genervt von Android und iOS. Mit dem BQ Aquaris nutze ich wieder ein Smartphone mit seinen Vorteilen. In Kürze bekomme ich noch das 2017 vorbestelltes Librem 5. Allerdings werden einen die geringe Anzahl verfügbarer Apps sehr einschränken.
1.) Ja, die SIM-Karte kann ja auch entnommen werden.
Die beiden anderen Fragen sind abseits dieses Beitrags. Ich gehe nur kurz auf Frage 3 ein: Einmal im Monat reicht eigentlich, nachdem die Sicherheitsupdates eingepflegt wurden.
Moin moin!
Kurzer Abstecher zum Captive Portal Check. Ich hab die beiden Hosts in Blokada in die Blacklist eingestellt. Bei Tablet SM-T113 mit Android 4.4.4 mit Blokada 2.2 und Smartphone GS270 Android 8.1 mit Blokada 3.7 besteht weiterhin Verbindung zum Internet. Blokada meldet die Sperrung der Hosts. Gibt es da noch einen versteckten Fallback oder gibt es da Hersteller bedingte Ausnahmen?
Hallo Zusammen,
ich habe überlegt, ob es nicht auch funktioniert die url „supl.google.com“ per Adaway auf localhost umzuleiten. Diese Lösung sollte weder den Fallback aktivieren und auch ein ROM-Update überleben. Auch ein Boot-up leak schließe ich aus, da die geänderte Hostsfile ja bereits beim booten aktiv ist.
Was meint Ihr?
Grüße
Ein sehr interessanter Ansatz. Gibts hier Erfahrungen bzw. klappt das?
Klar, wenn A-GPS über das Baseband direkt geht, kann man nix machen. Aber wenn man es vom Betriebssystem verhindern möchte, kann man dies doch bestimmt mit Afwall oder?
In Adaway unter Umleitungen eingerichtet wird nach einem Neustart ein Ping zu supl.google.com von 127.0.0.1 beantwortet. Sofern nichts über das Modem raus geht würde ich diese Methode dem manuellen Anpassen nach jedem Update vorziehen.
Dieses Fazit sugerriert, wir hätten nach „Take back control!“ die Herrschaft und Kontrolle über unser Android Gerät. Ist das wirklich so?
Hier gab es ja noch eine offene Frage:
Im Sinne der Ziele der Artikelserie: Ja. Aber natürlich bleibt immer auch ein »blinder Fleck«. Denn sobald ihr Daten mit anderen Menschen austauscht, sei es über E-Mail oder Messenger, so gibt es schlichtweg keine Garantie, dass die übermittelten Daten vom Empfänger sensibel behandelt werden oder nicht direkt nach Erhalt in der Microsoft-Cloud landen bzw. die Kontaktdaten via Google-Konto synchronisiert werden.
Weiterhin gibt es auch Risiken bzw. Gefahren, vor denen man sich nicht schützen kann – außer man hat kein Smartphone. Das zeigt aktuell Simjacker bzw. generell die Thematik, dass das Baseband und andere Komponenten eines Smartphones proprietär sind.
Fazit: »Take back control!« ist nach meinem Wissen der aktuell beste Ansatz, um die (größtmögliche) Herrschaft und Kontrolle über ein Android Gerät zu erlangen.
Vielen Dank für diese Klarstellung! Nichts ist schlimmer als wenn sich Nutzer in falscher „Sicherheit“ wähnen, also z.B. Menschen wie ich, die dachten, allein durch die Installation von LineageOS ohne Gapps würde ihr Endgerät nicht mehr an Google funken. Denkste!
Mein Fazit: ich habe leider überhaupt nicht mehr das Gefühl, daß ich eine Herschafft oder die Kontrolle über mein Android Gerät hätte. Durch das „Take back control!“ Tutorial habe ich aber gelernt, wie massiv der Überwachungsmechanismus von Google ist (man bedenke ca. 2 Milliarden Endgeräte!). Dafür bin ich sehr dankbar, und ich denke, daß die Arbeit diese Schweinereien aufzudecken unglaublich wichtig ist! Also ein großes Dankeschön und weiter so!
Zum Thema Displaysperre und Verschlüsselung:
Netterweise gibt es seit kurzem für LineageOS 16 einen commit, sodass ein
vdc cryptfs changepw password altes_Passwort neues_Passwort wieder funktioniert.
Damit kann man unter LineageOS 16 unterschiedliche Passwörter für Verschlüsselung und Displaysperre setzen.
Ein paar Rückfragen zum A-GPS Problem:
1) Sollte eine SUPL Anfrage nicht auch von der im Schritt 4 des Tutorials eingerichteten Firewall abgefangen werden (können)?
2) Statt die SUPL Anfragen mit AdAway für eine spezifische Domain zu blockieren, könnte man doch auch eine allgemeinere Firewall Regel anlegen, die den SUPL Port Range blockiert. Wäre das nicht etwas „zuverlässiger“? Allerdings, welche Ports wären das dann genau?
3) Wie könnte man testen ob das Baseband direkt SUPL Anfragen rausschickt? Vemutlich müsste man dazu einen eigenen „Cell Tower“ aufstellen und den Datenverkehr inspizieren? Wie geht das? Neben den SUPL Anfragen kommen dann vielleicht auch noch andere Dinge zum Vorschein.
Zu 3)
https://greatscottgadgets.com/hackrf/one/ könnte da weiterhelfen. Mit ~ 360 € aber kein Pappenstiel.