1. Ungewollte Datenverbindungen
Im vierten Teil der Artikelserie »Datenschutz für Android« beschäftigen wir uns mit ausgehenden Datenverbindungen. Um die Datenkontrolle über unser Smartphone zu erlangen, ist der Einsatz einer sogenannten Firewall zwingend erforderlich. Ursprünglich sollten uns Firewalls primär vor »Gefahren« von außen schützen. Dieser ursprüngliche Einsatzzweck von Firewalls hat sich jedoch zunehmend gewandelt. Firewalls auf Client-Systemen dienen nunmehr vermehrt der Überwachung und Kontrolle ausgehender Datenverbindungen. Mit DroidWall können wir dies erreichen.
Update
28.11.2017: Diese Artikelserie ist mittlerweile veraltet. Wer die Herrschaft und Kontrolle über sein Android-Smartphone anstrebt, dem kann ich die Artikelserie »Your phone – Your data« oder »Android unter Kontrolle« ans Herz legen.Im vorliegenden Beitrag werde ich demonstrieren, wie ihr den Aufbau externer Datenverbindungen von eurem Gerät kontrollieren könnt. Indirekt stärkt ihr damit euer Recht auf informationelle Selbstbestimmung.
- aSpotCat – Datenschutz für Android Teil1
- PDroid vs. LBE Privacy Guard – Datenschutz für Android Teil2
- PDroid Custom ROM Patch – Datenschutz für Android Teil3
- DroidWall Android Firewall – Datenschutz für Android Teil4
- SRT AppGuard – Datenschutz für Android Teil5
2. DroidWall
DroidWall dient als grafisches Frontend für den bekannten Paketfilter iptables. Die App ist in der Lage einzelnen Anwendungen und Systemkomponenten den Zugriff auf das Internet zu untersagen. Ausgehende Datenverbindungen werden direkt an der mobilen Schnittstelle (2G/3G/UMTS/LTE) oder dem WLAN-Interface gefiltert und können nur nach eurer Zustimmung eine Kommunikationsbeziehung zu entfernen Servern aufbauen. Viele Apps »telefonieren« gerne nach Hause und übersenden damit sensible Informationen an Entwickler oder Marketing-Unternehmen. Für die Verwendung von DroidWall wird ein gerootetes Gerät vorausgesetzt. In vorangegangenen Beiträgen der Artikelserie »Datenschutz für Android« bin ich auf Risiken und die Durchführung des Root-Vorgangs bereits eingegangen.
Du kannst den Blog aktiv unterstützen!
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 Black or White?
DroidWall bietet zwei unterschiedliche Betriebsmodi an. Ihr dürft euch zwischen »White list« oder »Black list« entscheiden. Die Unterschiede sind im Folgenden kurz zusammengefasst:
- White list: Lediglich selektierte Apps dürfen eine Verbindung in das Internet aufbauen.
- Black list: Hier ist es gerade umgekehrt. Selektierte Apps dürfen keine Verbindung initiieren.
Ich empfehle den „White list“ Modus. Dies ist auch der vorgeschlagene Standard von DroidWall.
2.2 White Modus
Neben dem Modus könnt ihr beeinflussen welche »Verbindungsart« ihr erlaubt bzw. verbietet. DroidWall unterscheidet zwischen WLAN- und 2G/3G-Verbindungen. Setzt ihr lediglich im linken Feld (WLAN) ein Häkchen, kann eine App anschließend keine Daten über die mobilen Dateninterface austauschen.
Habt ihr alle Entscheidungen getroffen, gilt es diese über das Optionsmenü abschließend zu speichern. Mit einem Fingertip auf »Apply Rules« könnt ihr dies vornehmen. DroidWall übersetzt die »Häkchen« anschließend in Regelsätze, die von iptables verstanden und verarbeitet werden können.
2.3 More Options
DroidWall unterstützt noch weitere Zusatzfunktionen, die für den ein oder anderen unter euch interessant sein könnten. Dazu zählen:
- Logging: Mit der Logging-Funktion könnt ihr beobachten zu welchen Gegenstellen (IP-Adressen) Apps Verbindungen aufbauen.
- Password: Zum Schutz gegenüber Veränderungen könnt ihr ein Passwort hinterlegen. Sobald die Regelsätze modifiziert werden müsst ihr euch über das Passwort gegenüber DroidWall authentifizieren.
- Custom-Scripts: Ohne die Custom-Scripts kennt DroidWall im Prinzip lediglich die Funktion »Verbindung erlauben« bzw. »Verbindung verbieten«. Zur welcher IP-Adresse eine App eine Verbindung aufbaut und welchen Port (Dienst) sie dabei nutzt könnt ihr über die GUI nicht beeinflussen. Mittels den Custom-Scripts könnt ihr dies nachholen und sehr fein granular steuern wohin Apps Verbindungen aufbauen dürfen.
2.4 Log Beispiel
Anbei noch ein Auszug aus einem Log-Bericht:
DroidWall hat gerade das Spiel Lair Defense und Jetpack Joyride vor dem Zugriff auf das Internet abgehalten. Beide Spielen haben keinen online Modus und benötigen im Grunde keinen Zugriff auf das Internet. App-Updates werden über den Google Play Store eingespielt. So stellt sich für uns die Frage, wozu diese Apps Internet-Zugriff benötigen und ob wir diesen nicht besser über DroidWall reglementieren. In der Praxis existieren genügend Apps, die sich ungefragt an sensiblen Nutzerdaten »bereichern«. Daher halte ich eine Kombination bestehend aus PDroid und DroidWall als unverzichtbar.
3. Fazit
DroidWall stellt eine Bereicherung im Kampf gegen den ungewollten Datenabfluss dar. Apps denen ihr nicht vertraut könnt ihr damit den »Mund« verbieten. Nicht jede App benötigt Zugriff auf das Internet.
Im nachfolgenden Teil der Artikelserie »Datenschutz für Android« möchte ich das Tool SRT AppGuard vorstellen. Im Gegensatz zu PDroid und DroidWall ist für die Nutzung kein gerootetes Gerät notwendig. Ob sich damit allerdings auch in ähnlicher Form sensible Daten schützen lassen, wird im nächsten Beitrag beantwortet.
Bildquellen:
DroidWall: https://code.google.com/archive/p/droidwall/
Ü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:
OpenPDroid, PDroid 2.0 oder PDroid – Ja was denn nun?
PDroid 2.0 – Eine Alternative zu PDroid?
PDroid vs. LBE Privacy Guard – Datenschutz für Android Teil2
PDroid Custom ROM Patch – Datenschutz für Android Teil3
XPrivacy – Android ohne Google?! Teil6
9 Ergänzungen zu “DroidWall Android Firewall – Datenschutz für Android Teil4”
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.
Es gibt jetzt einen Fork von DroidWall, der aktiv weiterentwickelt wird und Open Source ist. AFWall+. https://forum.xda-developers.com/showthread.php?t=1957231
Werde ich mir bei Gelegenheit mal im Detail anschauen. Installiert ist AFWall+ jedenfalls schonmal… :)
Erst einmal vielen Dank für die sehr gut strukturierten und informativen Blog-Beiträge. Sehr hilfreich für mich, Android-Neuling, Webanwendungsentwickler und „Datenschutz-Paranoiker“. :)
Ich nutze selber seit kurzer Zeit CyanogenMod 9.1 mit PDroid und AFWall+. Dabei stellte sich mir folgende Frage:
Wie kann ich sicher sein, dass eine Anwendung A (z.B. eine Backup-Anwendung), die keinen Internetzugriff aber Zugriff auf die SD-Karte und auf private Daten, nicht einfach die privaten Daten auf der SD-Karte speichert, und eine Anwendung B (Internetzugriff, SD-Karten-Zugriff, kein Zugriff auf private Daten, z.B. ein Download-Manager) diese Kopie der privaten Daten von der SD-Karte liest und über das Internet versendet?
Werden Dateien, die von einer Anwendung geschrieben werden, immer mit entsprechenden Benutzerzugehörigkeiten und -rechten angelet, so dass andere Anwedungen keinerlei Zugriff aud diese Dateien bekommen? Wohl kaum, da sonst z.B. heruntergeladene Musik nicht wiedergegeben werden und ein Dateimanager auch nicht funktionieren könnte.
PDroid kennt leider keine Einschränkungen des Zugriffs auf die SD-Karte. Es wiegt den Benutzer sogar evtl. in falscher Sicherheit vor o.g. Szenario, da es Anwendungen ohne Internetzugriff in den Einstellungen als „harmlos“ bezeichnet.
Hallo Christian,
danke für deine interessante Frage. In der Tat hast du damit Recht. Wie kann man sich wirklich sicher sein, dass PDroid korrekt arbeitet?
Auf die Schnelle habe ich dazu nichts gefunden und auch keine Antwort parat. Sowas muss geprüft werden.
Ein weiterer Punkt auf meiner To-Do Liste. ;)
Das ist ein grundsätzliches Problem, eine App, die auf die SD-Karte zugreifen kann, kann immer auf ALLE Daten auf der SD-Karte zugreifen.
Das von dir angesprochene Szenario ist daher durchaus denkbar. Doch dazu müssten ja Anwendung A und Anwendung B in bösartiger Absicht zusammenarbeiten.
Ich halte das für relativ unwahrscheinlich, denn wenn man aufpasst, Berechtigungen überprüft und Open-Source-Software bevorzugt, sollten solche Anwendungen erst gar nicht den Weg aufs Telefon finden.
Und man kann ja auch „harmlosen“ Apps mit PDroid Berechtigungen verweigern, wenn man die Apps über die Optionen einblendet.
Unter Jelly Bean gibt es übrigens in den Developer Options die Option „Protect SD-Card“. Mit dieser Einstellungen müssen Apps nachfragen, bevor sie auf die SD-Karte zugreifen dürfen. Leider scheint diese Option noch nicht zu greifen, bei mir blieb sie ohne Effekt.
Natürlich müssten hier zwei Apps zusammen arbeiten, was das Ganze schon mal erheblich verkompliziert.
Wären die beiden Apps aber geschickt gestrickt, könnten Sie z.B. nur bei gleichzeitig vorhandener Installation der anderen App (z.B. über ein harmloses File auf der SD-Karte erkenntlich gemacht) ihre kombinierte Schadwirkung entfalten. Somit würde jegliche Prüfung, die beide Apps getrennt prüft, keinerlei Schadwirkung finden können, falls die Apps nicht OpenSource sind.
Sinnvoll wäre daher IMHO ein getrennter Speicherbereich auf der SD-Karte für jede App (den die App gar nicht bemerkt, da sie ganz normal über /mnt/sdcard darauf zugreift), also quasi genau so, wie momentan auch schon die Daten im internen Speicher getrennt abgelegt werden. Eine zusätzliche Absicherung über Unix-Dateirechte wäre toll, scheitert aber erstmal an VFAT. Custom-ROMs unterstützen allerdings auch teilweise schon andere Dateisysteme auf der SD-Karte.
Danach müsste man „nur noch“ einigen Anwendungen kompletten Zugriff auf die SD-Karte geben (z.B. Dateimanager, Paketverwaltung, …).
Meine Frage: Gibt es ein Tool, evtl. auch wie PDroid als Patch des Systems realisiert, der eine solche „Virtualisierung“ der SD-Karte vornimmt?
Hallo Christian,
nein. Sowas ist mir leider nicht bekannt. Wäre aber in der Tat interessant.
Wenn ich in der Whitelist z.b. Bei Whatsap beide Haken rausnehme kann ich trotzdem Nachrichten schicken. Habe ich da was falsch verstanden?
Whitelist Häkchen raus bedeutet: Alles selektierte darf NICHT senden bzw. mit dem Internet kommunizieren.
Bei Whiteliste Häkchen rein bedeutet: Alles ausgewählte DARF senden bzw. mit dem Internet kommunizieren.