1. First things first
Unsere Artikelserie »Your phone – Your data« erhält erfreulicherweise immer mehr Zuspruch und erfreut sich zunehmend größer werdender Beliebtheit. Denn sie macht deutlich, dass wir uns der ausufernden, intransparenten und unkontrollierten Sammlung unserer teilweise sehr sensiblen Daten nicht ohnmächtig ergeben müssen. Vielmehr können wir, sofern wir hierzu bereit sind, uns ein wenig von der gewohnten Bequemlichkeit zu verabschieden, sehr wohl etwas bewegen und ein »befreites« Smartphone erhalten. Mit einem entsperrten und zugleich gerooteten Android-Gerät haben wir die Grundvoraussetzung dazu geschaffen. Im Idealfall habt ihr ebenfalls den Wechsel zu einer alternativen Firmware, wie OmniROM oder dem CyanogenMod vollzogen. Damit sind noch längst nicht alle Hürden genommen, doch wir kommen unserem Ziel, die Herrschaft und Kontrolle über unser Android-Gerät wiederzuerlangen, immer näher.
Durch die Installation des CyanogenMods inklusive der in Teil 3 beschriebenen notwendigen Modifikationen, haben wir uns von den herstellereigenen Android-Systemen losgesagt. Doch allein der Wechsel zu einer alternativen Firmware schützt uns nicht zwangsläufig vor dem ungewollten Abfluss sensibler Daten. Vielmehr bedarf es zwingend weiterer Anpassungen des Systems und dem Einsatz elementarer Apps. Zwei dieser Apps, wollen wir euch mit dem vorliegenden Beitrag näher vorstellen.
Um die Datenkontrolle über unser Smartphone zu erlangen, ist der Einsatz einer Firewall zwingend notwendig. Ursprünglich sollten uns Firewalls primär vor »Gefahren« von außen schützen. Dieser primäre Einsatzzweck von Firewalls hat sich jedoch zunehmend gewandelt. Firewalls auf Client-Systemen dienen nunmehr vermehrt der Überwachung und Kontrolle ausgehender Datenverbindungen. Mit der AFWall+ steht für unser Android-Gerät eine der wohl »wertvollsten« Apps zur Verfügung. Sie verfügt über eine grafisches Interface, mit dem wir ausgehende Datenverbindungen von installierten Apps steuern können. Ferner lassen sich mittels eigener »Custom-Scripts«, die von AFWall+ bereitgestellten Funktionalitäten nahezu uneingeschränkt erweitern. Denn wir greifen über die Custom-Scripts direkt auf die von Linux Systemen bekannte Firewall/NAT-Filter iptables zu, die wir damit unseren Bedürfnissen entsprechend anpassen können.
Um die für unser Projekt benötigten Apps zu erhalten, müssen diese natürlich erst einmal auch von irgendwoher bezogen werden. Wie in Teil 1 dargestellt, verbietet sich für unser Projekt der Bezug dieser Apps aus dem Google Play-Store. Daher gilt es, einen alternativen App-Marktplatz zu finden. Für unser Projekt haben wir uns aus den nachfolgend dargestellten Gründen für den F-Droid Store entschieden.
- Your phone Your data – Android ohne Google Teil1
- Grundstein legen – Android ohne Google Teil2
- CyanogenMod – Android ohne Google?! Teil3
- F-Droid und AFWall+ – Android ohne Google?! Teil4
- Network Log – Android ohne Google?! Teil5
- XPrivacy – Android ohne Google?! Teil6
- Datenschutzfreundliche Apps und Dienste – Android ohne Google?! Teil7
Update
März 2016: Die Artikelserie wurde das letzte Mal im März 2016 aktualisiert. Sie lässt sich inklusive Android 6.x (Marshmallow) einwandfrei umsetzen.2. Das Rad (bisher) nicht neu erfunden
Es soll nicht verheimlicht werden, dass es immer wieder Stimmen gibt, die unsere Artikelserie für wenig konkret und zielführend halten. Vielmehr sei alles das, was wir in den bisherigen Beitragsteilen thematisiert haben, schon in den einschlägigen Foren behandelt worden.
Dem können und wollen wir nicht widersprechen. Die »angeprangerten« Wiederholungen waren jedoch notwendig, um den Leser in das Thema »Android« einzuführen und ihn für die grundsätzlichen Problematiken, die mit dem Einsatz eines »nicht befreiten Smartphones« einhergehen zu sensibilisieren. Es sei an dieser Stelle nochmals darauf hingewiesen, dass es sich bei Your phone – Your data um ein Projekt handelt, das für jeden Nutzer, also egal ob Anfänger oder Experte, nachvollziehbar sein soll. Gewisse thematische Wiederholungen sind deshalb unvermeidbar.
Erst durch die von uns gewählte Vorgehensweise war es uns möglich, den Grundstein für die nachfolgenden, immer konkreter werdenden Ausführungen zu legen. Einige Punkte, die wir im Nachfolgenden ansprechen werden, sind in den einschlägigen Foren bisher noch gar nicht oder nur am Rande thematisiert worden. Daher bekommen möglicherweise auch unsere Kritiker doch noch einen gewissen Erkenntnismehrwert von unserer Beitragsserie.
3. F-Droid Store
Android’s Beliebtheit und hoher Verbreitungsgrad ist zu einem großen Teil auf die »Offenheit« des Systems zurückzuführen. Als Anwender erfährt man nahezu keine Einschränkung und kann das System nach Belieben anpassen. Auch bei der Installation neuer Apps sind dem Anwender im Prinzip keine Grenzen gesetzt. Er darf vielmehr frei entscheiden, aus welcher Quelle er seine Apps bezieht.
Wie vorstehend angesprochen, haben wir uns für unser Projekt für den F-Droid Store entschieden. Im Gegensatz zu den meisten anderen App-Stores werden auf diesem »Marktplatz« ausschließlich freie und quelloffene Apps zum Download angeboten. Wie schon in Teil 1 angesprochen, kommt diese Besonderheit des F-Droid Stores dem Grundgedanken unseres Projekts sehr entgegen. Denn eine Datenkontrolle können wir nur dann erreichen, wenn wir auch die Funktionsweise der zu installierenden Apps nachvollziehen bzw. überprüfen können. Nur so lässt sich »Vertrauen« in die App aufbauen. Ein großer Nachteil von proprietären Apps ist nämlich, dass wir grundsätzlich nicht (ohne gegen geltendes Urheberrecht zu verstoßen) die App dekompilieren dürfen, um die Funktionsweise zu überprüfen. Aus diesem Grund sind quelloffene Apps für unser Projekt, in dem es im Wesentlichen um die Gewährleistung von Transparenz geht, unsere erste Wahl.
Der F-Droid-Store ist grundsätzlich vergleichbar mit dem Google Play-Store. Jedoch gibt es, wie vorstehend schon kurz angesprochen, eine große Ausnahme:
Im Gegensatz zum Google Play-Store werden im F-Droid Store keine proprietären, sondern ausschießlich FOSS-Apps (Free and Open Source Software) angeboten, deren Quellcode öffentlich einsehbar ist und prinzipiell von jedem verändert werden darf. Wie für den Google Play-Store gibt es auch für den F-Droid-Store eine Client-App, mit der sich Apps herunterladen bzw. aktualisieren lassen. Darüber hinaus bietet F-Droid auf der eigenen Webseite von jeder App die jeweilige APK-File und zusätzlich auch immer den Quellcode dieser App zum Download an.
Zugegebenermaßen ist im Gegensatz zum Google Play-Store die App-Auswahl beim F-Droid Store eher dürftig. Dieses insbesondere deshalb, weil es in den F-Droid-Store nur quelloffene Apps schaffen, wovon es traurigerweise nicht so viele gibt. Das Positive ist hierbei aber, dass der Anwender im F-Droid-Store für praktisch alle Bereiche seiner beabsichtigten Smartphonenutzung oftmals sogar bessere (offene) Alternativen finden kann. Um Kritikern zuvorzukommen: Unser Ziel ist ein »freies Android Gerät«. Nach unserer Auffassung gelingt diese »Befreiung« allerdings nur mit quelloffenen Apps. Aus diesem Grund müssen wir bei der App-Auswahl klare Abstriche machen und daher möglicherweise auch »gewohnte« Apps durch entsprechende, quelloffene Alternativen ersetzen. Dass dieses nicht immer leicht ist, ist uns bewusst. Im Sinne des Projektes aber unabdingbar. Wie in Teil 3 der Artikelserie dargestellt, verzichten wir ebenfalls auf die Installation der GAPPS (Google Apps), was die App-Auswahl zusätzlich einschränkt.
Hinweis: Wer auf diverse proprietäre Anwendungen nicht verzichten will oder kann, der hat mit dem APK-Downloader noch immer die Möglichkeit, kostenlose Apps aus dem Google Play-Store herunterzuladen und auf seinem Androiden zu installieren. Weiterhin beitet der Amazon App Store ein breites Angebot an Apps an. Wir möchten jedoch an dieser Stelle nochmals die Warnung vorausschicken, dass viele der dort verfügbaren Apps ungeniert auf sensible Daten unseres Smartphones zugreifen und diese »munter« zu diversen Anbietern versenden. Es empfiehlt sich deshalb in jedem Falle immer auch eine Reglementierung dieser datenhungrigen Apps über Tools wie XPrivacy vorzunehmen. In einem späteren Teil dieser Artikelserie werden wir auf die Nutzung von XPrivacy noch detaillierter eingehen.
Der Kuketz-Blog ist spendenfinanziert!
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.
3.1 F-Droid Besonderheiten
Mit dem F-Droid Store hat sich ein alternativer App-Store etabliert. Vom Angebot der dort verfügbaren Apps profitieren vor allem kritische Anwender, die Wert auf freie und quelloffene Anwendungen legen. Die geringe App-Auswahl im F-Droid-Store mag den Google Play-Store gewohnten Nutzern auf den ersten Blick ein wenig »verschrecken«. Durch den Google Play-Store anvertraute Apps, wird er im F-Droid Store meistens vergeblich suchen. Wie wir vorstehend dargelegt haben, gibt es jedoch im F-Droid Store zu den meisten Google Play-Store Apps auch brauchbare quelloffene Alternativen, denen man eine Chance geben sollte.
Gerade Anwender, bei denen Datenschutz bzw. der Geheimnisschutz (wie z. B. Anwälte oder Ärzte) eine wichtige Rolle spielt, sollten alleine aus berufsethischen Gründen immer darauf achten, keine (proprietären) Apps zu installieren, bei denen die Datenverarbeitung intransparent ist und immer die Gefahr besteht, dass Apps auf Informationen ihrer Mandanten bzw. Patienten zugreifen.
Trotz der Sympathie, die wir dem F-Droid-Store entgegenbringen wollen wir an dieser Stelle aber auch nicht verschweigen, dass dieser alternative App-Vertriebskanal auch ein paar Besonderheiten und »Mankos« hat, die wir im Folgenden kurz darstellen werden:
- In den Nutzungsbedingungen zum F-Droid-Store weisen die Betreiber darauf hin, dass Sie trotz aller Anstrengungen nicht vollständig gewährleisten zu können, dass Schadsoftware über den F-Droid Store angeboten wird. Vor der Veröffentlichung einer App prüfen die F-Droid-Betreiber den Quellcode der jeweils einzustellenden App auf potenzielle Sicherheits- bzw. »Datenschutz«- Probleme. Wurden keine Probleme gefunden, wird diese dann kompiliert und im F-Droid Store bereitgestellt. Aufgrund dieser Einschränkungen sollte man den F-Droid Store deshalb in keinem Fall als Garant für einen schadsoftwarefreien Marktplatz begreifen. Vielmehr ist auch hier Mißtrauen angebracht. Denn die Frage, ob eine App schadhaft ist oder nicht, lässt sich oftmals erst durch ausgiebige und umfangreiche Langzeittests der App beantworten. Diese kann und will der F-Droid-Betreiber (verständlicherweise) nicht leisten.Ein erstes »Manko« des F-Droid-Store ist daher, dass eine neu einzustellende App grundsätzlich nicht vollumfänglich geprüft wird bzw. werden kann. Dieses ist, nach Angaben von Google bspw. beim Google Play-Store anders. Hier wird eine App, bevor sie in den Google Play-Store aufgenommen wird, durch sog. Bouncer automatisch auf »Schadsoftware« geprüft. In einer virtuellen Umgebung werden hierbei Apps auf ihr Verhalten und ihre Funktionsweise untersucht, um die Veröffentlichung von Schadsoftware zu vermeiden. Allerdings kann auch Google einen Schadsoftware freien Store nicht gewährleisten. Gelegentlich schaffen es App-Plagiate in den Store und fordern bei der Installation weitreichende Berechtigungen.
- Im Gegensatz zum Google Play-Store haben App-Entwickler im F-Droid Store praktisch keine Kontrolle über den Release- und Update-Prozess. Dies kann im Einzelfall zu veralteten und unsicheren App-Versionen führen, da Updates in der Regel von den jeweiligen Maintainern zur Verfügung gestellt werden. Falls der Maintainer also nachlässig wird oder gerade »verhindert« ist, kann dies zur Folge haben, dass auf bekanntgewordene Sicherheitslücken nicht zeitnah reagiert wird. Ferner müssen wir uns bei der Verwendung des F-Droid Stores bei jedem App-Release oder Update einer App darauf verlassen, dass der jeweilige Maintainer keine Quellcodeveränderungen vorgenommen hat, die sich u.U. negativ auf unsere Daten oder Gerät auswirken können.
- Trotz dieser von uns als »Mankos« angesehenen Fakten, wollen wir aber eine Besonderheit des F-Droid Stores nicht unerwähnt lassen. Diese Besonderheit ist den im F-Droid Store aufgenommenen FOSS-Apps geschuldet. Aufgrund der bei FOSS-Apps geltenden Lizenzbedingungen ist es grundsätzlich jedermann, unter Einhaltung bestimmter Vorgaben möglich, den Quellcode zu verändern. Von dieser Möglichkeit macht das F-Droid Team von Zeit zu Zeit auch gerne Gebrauch und entfernt (eigenmächtig) sogenannte »Antifeatures« aus der ursprünglichen App-Version. Das Entfernen von Antifeatures hat das Team des F-Droid Stores bspw. beim Telegram-Messenger unter Beweis gestellt. Hierzu gab es zu lesen:»Several proprietary parts were removed from the original Telegram client, including Google Play Services for the location services and HockeySDK for self-updates. Push notifications through Google Cloud Messaging and the automatic SMS receiving features were also removed.«
Die Vorgehensweise des F-Droid Teams auf Services bzw. Funktionen, die dem »Datenschutz« nicht gerade zuträglich sind, zu verzichten bzw. diese herauszuprogrammieren, hat uns zusätzlich in unserer Entscheidung bestärkt, F-Droid als App-Quelle für unser Projekt zu wählen. Solltet ihr euch auch trotz der beschriebenen Mankos bzw. Besonderheiten dafür entscheiden, F-Droid auf eurem Androiden zu installieren, solltet ihr hierbei wie folgt vorgehen.
3.2 Installation der F-Droid App
Über einen mobilen Browser lässt sich die Installation der F-Droid App rasch erledigen. Öffnet dazu den Link über euren Android-Browser. Alternativ könnt ihr das Android APK-File auch erst auf den Rechner laden und mittels USB auf das Endgerät übertragen. In jedem Fall müsst ihr für diese Installation die Funktion »Installation von Apps aus unbekannten Quellen zulassen« aktivieren. Diese findet ihr unter »Einstellungen -> Sicherheit -> Unbekannte Herkunft«. Nach Abschluss der Installation solltet ihr das gesetzte Häkchen in jedem Fall wieder entfernen. Für eure eigene Sicherheit ist es empfehlenswert, Apps ausschließlich aus »vertrauenswürdigen« Quellen zu beziehen und die angeforderten Berechtigungen vor der Installation genau zu überprüfen.
Ebenso wie der Umgang mit Root-Rechten (siehe Beitrag 2) solltet ihr niemals eure Verantwortung unterschätzen, die eine App-Installation mit sich bringt. Eine unbedachte App-Installation kann sich nämlich durchaus negativ auf die Sicherheit eures Geräts auswirken. Die deaktiviere Einstellung »Installation von Apps aus unbekannten Quellen zulassen« lässt sich deshalb als »Schutzfunktion« gegen schadhafte Apps verstehen, die sich vornehmlich über dubiose Webseiten verbreiten und von unbedarften Anwendern einfach installiert werden. Außer für die Installation des F-Droid Stores solltet ihr es deshalb zukünftig unbedingt vermeiden, Apps bzw. APK-Dateien von (ominösen) Webseiten herunterzuladen.
Habt ihr F-Droid erfolgreich installiert, gilt es die App zu starten und die erste für unser Projekt essenziell wichtige App auf eurem Androiden zu installieren.
3.3 Erste App-Installation
Nach einem initialen Start der F-Droid App sollten sich die Paketquellen automatisiert aktualisieren. Falls dies nicht geschieht, solltet ihr die Paketquellen »manuell« einlesen. Hierzu tippt ihr oben rechts auf die drei Pünktchen und wählt »Paketquellen aktualisieren«.
Über die Lupe suchen wir anschließend nach »afwall« und installieren die aktuellste Version der AFWall+ Firewall-App für euer Android-System. Unter Ziffer 4 werden wir die Bedienung und Konfiguration von AFWall+ näher erläutern.
3.4 Zwischenfazit
Nach unserer Auffassung stellt der F-Droid Store eine komfortable Variante für die Installation und Pflege von FOSS-Apps dar. Aufgrund der vorherigen Ausführungen gilt es aber letztendlich immer auch zu berücksichtigen:
- Trotz all der von F-Droid getroffenen Sicherheitsmaßnahmen müssen wir im Hinblick auf die Prüfung bzw. die Beurteilung hinsichtlich der Datenschutzkonformität / der Sicherheit der Apps, der korrekten Kompilierung und der ordnungsgemäßen Bereitstellung / Updaten dieser Apps auf das Team von F-Droid vertrauen.
- Technikversierte Anwender haben zusätzlich die Möglichkeit, insbesondere wenn sie dem F-Droid-Team nicht vertrauen, den App-Quellcode selber zu überprüfen, zu kompilieren und die eigens kompilierten Apps auf ihrem Gerät zu installieren.
Letztendlich steht und fällt deshalb mal wieder einmal alles mit unserem »Vertrauen« in die Apps bzw. den F-Droid Store. Ob der F-Dorid Store bzw. die dort angebotenen Apps unser Vertrauen verdienen, lässt sich in gewissem Maße relativ »einfach« testen. Hierzu müssen wir die AFWall+ installieren, mithilfe derer wir überprüfen können, ob sich die Apps tatsächlich auch so verhalten, wie wir es von ihnen erwarten.
Um zu testen, ob die AFWall+ wiederum auch tatsächlich alle Verbindungen der Apps erkennt und blockiert, können wir durch die App PCAPdroid verifizieren, auf die wir jedoch erst in einem späteren Artikel eingehen werden.
4. AFWall+
AFWall+ ist ein Front-End für die aus der Linux Welt bekannte iptables Firewall. Sie ermöglicht die Kontrolle darüber, welche App oder Systemdienst Zugriff auf das Datennetzwerk über 2G/3G, Roaming, (W-)LAN oder VPN haben soll. Sie stellt für unser Projekt ein essentielles Tool gegen den ungewollten Abfluss von Informationen dar. Wie bereits dargestellt genügt es nämlich nicht, den Wechsel zu einer alternativen Firmware (bspw. CyanogenMod) zu vollziehen, um neugierige Systemkomponenten oder vorinstallierte Apps vor dem Aufbau ungewollter Datenverbindungen abzuhalten.
Aufgrund der »Telefonierfreudigkeit« gewisser Apps, muss es daher auf einem »frisch« installierten System unser primäres Ziel sein, »neugierigen« Systemkomponenten und Apps das »Nachhause-Telefonieren« zu verbieten. Ist das erst einmal geschafft, könnt ihr selber durch die Auswertung von Logfiles der AFWall+ bzw. PCAPdroid entscheiden, welche Verbindungen bzw. Apps ihr zulassen wollt und welche besser gesperrt werden bzw. bleiben sollten. Im Zusammenhang mit »telefonierfreudigen« Apps wollen wir euch nicht verheimlichen, dass wir selbst auf dem eigentlich »freien« CyanogenMod, weiterhin Datenverbindungen von Systemkomponenten und vorinstallierten Apps zu Google IP-Adressen und der Amazon Cloud beobachten konnten. Das Kuriose hierbei war, dass es uns auch nicht gelungen ist, alle Apps bzw. Systemfunktionen eindeutig zuzuordnen.
Zwar sind nicht alle dieser Verbindungen per se »schädlich« oder haben zum Ziel unsere Daten zu »verraten«. Aber was bei uns in jedem Fall durch diese Erkenntnis blieb, war und ist ein mulmiges Gefühl. Wenn wir nämlich trotz all unserer Bemühungen, sämtliche »telefonierfreudigen« Dienste (bspw. Update-Service) unseres Androiden abzuschalten dennoch weiterhin beobachten können, dass immer noch ungefragt »ominöse« Verbindungen aufgemacht werden und wir hierbei nicht wissen und zuordnen können, was für Daten bzw. Informationen von welchen Diensten übermittelt werden, ist das für eine Vertrauensbildung gegenüber Google und Co. nicht gerade zuträglich.
Denn eines sollte man sich immer vor Augen führen. Mit jeder neuen Verbindung, die unser Smartphone mit den entsprechenden Servern herstellt wird, ob wir wollen oder nicht, zumindest unsere IP-Adresse, die eine personenbezogene Information von uns darstellt, an die entsprechenden Organisationen übermittelt. Die Übermittlung und weitere Verarbeitung dieser Information erfolgt, ohne dass wir hierüber (ausreichend) informiert wurden bzw. werden. Alleine diese Tatsache ist aus datenschutzrechtlicher Sicht nicht gerade unproblematisch.
Mit dem Tool Network Log könnt ihr euch selber ein Bild von der Kommunikationsfreudigkeit« eurer Systeme bzw. Apps machen.
4.1 Hinweis
AFWall+ vollständig zu überblicken und alle Funktionen (bspw. Custom-Scripts) zu beherrschen, stellt zunächst eine nicht zu unterschätzende Herausforderung dar. Vermutlich werden wir es in unserer Darstellung nicht schaffen, alle potenziell aufkommenden Fragen abschließend zu beantworten bzw. euch eine vollständige Anleitung über die Bedienung dieser komplexen App an die Hand zu geben. In unserer Ausführung werden wir auf die wichtigsten Funktionen eingehen und die elementaren Einstellungen der AFWall+ besprechen.
Da jedes Android-Smartphone inklusive der darauf installierten Apps für sich gesehen praktisch einzigartig ist, können wir es euch nicht abnehmen, eigene Erfahrungen mit der AFWall+ zu sammeln. Diese könnt ihr sehr gerne auch über die Kommentar-Funktion des Blogs, mit anderen Lesern teilen und diskutieren.
4.2 User-Interface
Unmittelbar nach dem Start werden alle installierten Apps eingelesen und untereinander aufgelistet. Systemkomponenten bzw. vorinstallierte Apps lassen sich relativ einfach anhand der roten Schriftfarbe identifizieren. In der Spalte über den Apps sind die verschiedenen Netzwerk-Interfaces erkennbar, die es euch ermöglichen, Apps entsprechend der Verbinungsart (WLAN, mobile Datenverbindung über 2G/3G/LTE oder Roaming) zu reglementieren.
Die AFWall+ bietet hierfür zwei unterschiedliche Betriebsmodi an. Ihr als Nutzer könnt zwischen dem White-List- und dem Black-List-Modus wählen:
- White-List Modus: Ausschließlich selektierte Apps (mit einem Häkchen) dürfen WLAN-, mobile Daten oder das Roaming-Interface nutzen, um darüber eine Datenverbindung aufzubauen. Demzufolge dürfen alle Apps, bei denen ihr kein Häkchen gesetzt habt, auch nicht nach »außen« kommunizieren.
- Black-List Modus: Hier verhält es sich genau umgekehrt. Hierbei gilt es nämlich alle Apps zu selektieren (anzuhaken), die nicht nach »außen« über das entsprechende Interface kommunizieren dürfen.
Im Auslieferungszustand arbeitet die AFWall+ nach dem White-List Prinzip, was wir euch ebenfalls empfehlen können. Die Basisfunktionalität ist somit schnell erklärt: Alle Apps die ihr mit einem Häkchen verseht, dürfen eine Verbindung in das Internet bzw. vom Gerät nach »außen« aufbauen. Damit ihr neue Apps aus dem F-Droid Store herunterladen bzw. installieren könnt, solltet ihr in der F-Droid Spalte ein entsprechendes Häkchen z. B. beim WLAN-Interface setzen.
4.3 Einstellungen
Über die drei Pünktchen im oberen rechten Rand der AFWall+, gelangt ihr in ein weiteres Optionsmenü, worüber ihr die »Einstellungen« erreicht. Dort solltet ihr Folgendes in jedem Fall aktivieren:
- Wenn die AFWall+ noch in englischer Sprache läuft, könnt ihr die Sprache unter dem Punkt »Language« in »German« ändern.
- Häkchen bei »User Identifier (UID) anzeigen«. Aktiviert diese Option, damit die Zuordnung von gesperrten Netzwerkpaketen über das Firewall-Log einfacher gelingt. Bei Android wird nämlich jeder App eine eindeutige ID (UID) vom System zugewiesen, anhand derer ihr das »Verhalten« einer App nachvollziehen könnt.
- Auch ein Häkchen bei »Aktive Regeln: Anwendungen von Firewall-Regeln bei jeder Verbindungsänderung (Roaming/LAN/WLAN/3G/Tethering)«. Die AFWall+ hat nämlich kein Exklusivrecht bzw. alleinige Kontrolle über das in Android integrierte iptables. Im Prinzip kann jede System- bzw. Root-App mit Zugriff auf iptables die Regelsätze entsprechend anpassen. Laut dem Entwickler (ukanth) soll diese Funktion sicherstellen, dass möglichst keine Daten das Gerät verlassen. Bei jeder Änderung des Netzwerkzustands (bspw. WLAN An / Aus) werden die in AFWall+ definierten Regeln erneut geladen.
- Häkchen bei »Start-Datenleck-Fix«: Verhindert Datenlecks beim Systemstart«. Die durchaus sinnvolle Funktion soll verhindern, dass Apps während dem Boot-Vorgang Verbindungen nach »außen« aufbauen. Die AFWall+ klingt sich deshalb in einer frühen Boot-Phase als init.d Skript in das System ein und kann das Datenleck unterbinden. Es gilt zu beachten, dass diese Funktion derzeit noch experimentell ist und nicht auf allen Geräten funktioniert. Bei CyanogenMod sollte der Datenleck-Fix aber funktionieren.
4.4 Firewall-Protokoll
Einige Apps funktionieren nur dann korrekt, wenn die entsprechenden »Helper-Apps« ebenfalls Zugriff auf das Internet bekommen. Erfahrungsgemäß werdet ihr besonders bei Apps mit Video- oder Audioinhalten auf erste Schwierigkeiten stoßen, da viele Android-Apps hierfür die Systemkomponente »Media Server« benötigen. Erst nachdem dieser App ebenfalls der Internetzugriff erlaubt ist, kann die Darstellung bzw. Wiedergabe von Video- und Audioinhalten gelingen.
Um entsprechende Abhängigkeiten der Apps voneinander zu identifizieren oder um sich einfach mal vor Augen zu führen, welche Anfragen nach »draußen« von der AFWall+ blockiert werden, stellt das Firewall-Protokoll ein sinnvolles Hilfsmittel dar. Standardmäßig ist in der AFWall+ diese Protokollierung nicht aktiv. Deshalb müsst ihr diese über »Einstellungen« zunächst einmal aktivieren. Hierfür setzt ihr einfach ein Häkchen bei »Aktiviere Firewall-Logs«. Wenn ihr zusätzlich ein Hinweisfenster eingeblendet haben wollt, mit dem euch in Echtzeit angezeigt wird, was die Firewall alles blockt, könnt ihr diese Funktion unter dem Punkt »Protokolldienst einschalten« aktivieren.
Anschließend erreicht ihr das Log über die drei Pünktchen und den Menüeintrag »Firewall-Protokoll«. In Abhängigkeit von der jeweiligen AppID werden dort abgelehnte Verbindungsanfragen protokolliert. Ein Eintrag in diesem Log ist wie folgt aufgebaut und enthält folgenden Informationen:
- Das Übertragungsprotokoll: TCP oder UDP
- Das Ziel oder die Quelle in Form einer IP-Adresse
- Der angefragte Dienst bzw. Port
- Anzahl der blockierten Anfragen
Zugegebenermaßen ist es zunächst nicht einfach, eine blockierte Anfrage einer App bzw. einer »Helper-App« zuzuordnen, um diese bei Bedarf in der AFWall+ freizuschalten.
Trefft ihr auf Probleme bei der Zuordnung, solltet ihr in jedem Fall die vorstehend beschriebene Funktionalität der AFWall+ »Protokolldienst einschalten« nutzen. Ihr erhaltet nämlich bei der Nutzung der entsprechenden App direkt ein kurzes Hinweisfenster eingeblendet, in dem angezeigt wird, welche Verbindung von der AFWall+ gerade blockiert wurde. Mit diesem Wissen könnt ihr dann bei Bedarf die entsprechende App in eurer AFWall+ freischalten.
Auch die App PCAPdroid kann ebenfalls zur »Aufklärung« beitragen. Wie bereits angesprochen, werden wir darauf aber in einem weiteren Artikel noch detailliert eingehen.
4.5 Empfohlene Regelsätze
Nach einer Erstinstallation von AFWall+ steht ihr vor der Herausforderung zu entscheiden, welche Apps tatsächlich Internetzugriff benötigen bzw. bekommen sollten. Weiterhin gilt es vermeintliche Abhängigkeiten von Apps zu ihren »Helper-Apps« aufzulösen, um diesen gegebenenfalls auch den Zugriff nach »außen« zu erlauben. Bei der Gestattung und dem Vergeben von Zugriffsberechtigungen können wir euch nur ans Herz legen, eher einen harten, strengen Kurs einzuschlagen. Ihr solltet deshalb nur den Apps Internet-Zugriff gestatten, wenn dieses auch wirklich notwendig ist.
Ausgehend von einer »frischen« CyanogenMod Installation schlagen wir folgende Whitelist-Regeln für eure AFWall+ vor:
- (Root) – Apps die Root-Rechte benötigen: Wird unter anderem für die DNS-Namensauflösung via netd Daemon benötigt. (ab Android 6.x also notwendig)
- (NTP) – Internet Zeitserver: Ermöglicht die Zeitsynchronisation, falls ihr unter »Datum & Uhrzeit« die Funktion »Autom. Datum/Uhrzeit« aktiviert habt.
- CM Updater: Auch für das CyanogenMod bzw. für eure Installation erscheinen kontinuierlich Updates. Das Whitelisting der »CM Updater« App soll uns auf neue Updates hinweisen und diese bei Bedarf einspielen.
- F-Droid: Da wir über den F-Droid Store in Zukunft Apps beziehen wollen, muss dieser App der Zugang ins Internet bzw. nach »draußen« gewährt werden.
Je nach euren App-Vorlieben und den entsprechenden Anwendungszwecken solltet ihr ferner folgende Regeln in Betracht ziehen:
- (Tethering) – DHCP+DNS-Dienste: Falls ihr euer Android-Gerät als »Hotspot« verwendet, solltet ihr diese Systemfunktion »white-listen«.
- Media server: Wie beschrieben, ist dieses eine klassische »Helper-App«. Erst durch das Whitelisting dieser App, können Apps Video- und Audioinhalte wiedergegeben werden.
Im Einzelfall kann es notwendig werden, weiteren »Helper-Apps« den Zugriff auf das Internet zu erlauben. Für den »Normalgebrauch« sollten jedoch die oben dargestellten Regelsätze zunächst erst einmal ausreichen.
Auf unserem »freien« Android-Gerät sieht es derzeit folgendermaßen aus:
4.6 Besonderheiten ab Android 4.3+
Besonders aufmerksame Anwender werden über PCAPdroid Pakete bemerken, die von der AFWall+ nicht korrekt blockiert werden. Die beiden Systemkomponenten
- (Kernel) Linux Kernel
- (Root) – Apps die Root-Rechte benötigen
versenden selbst dann noch Datenpakete, wenn dies per Regelwerk eigentlich überhaupt nicht erlaubt ist. Für dieses seltsam anmutende und »beunruhigende« Verhalten ist u.a. Android 4.3 verantwortlich.
- Seit Android 4.3 werden DNS-Anfragen standardmäßig über den netd Daemon »geschleust«. Dieser netd-(Root)Dienst als Teil unseres Androiden arbeitet ähnlich wie ein Proxy bzw. Tunnel. Aufgrund dieser »DNS-Tunnelverbindung« kann unsere AFWall+ nicht die entsprechenden DNS-Requests einer App bzw. einer speziellen UID zuordnen. Mithin ist sie auch standardmäßig nicht in der Lage, derartige DNS-Requests zu blocken. Durch gewisse Einstellungen in der AFWall+ könnt ihr dieses (ominöse) Verhalten eures Androiden unterbinden. Hierzu öffnet ihr wiederum im Optionsmenü den Punkt »Einstellungen«. Scrollt in diesem Menü ganz nach unten zum Eintrag »DNS-Proxy«. Dort ändert ihr die Funktion »automatisch« in »DNS über netd deaktivieren«. Durch diese kleine und unscheinbare Funktionsänderung erreicht ihr, dass von nun an alle DNS-Anfragen über die »App« bzw. UID »(Root) – Apps die Root-Rechte benötigen« verschickt werden und somit die AFWall+ die DNS-Anfragen den entsprechenden Apps zuordnen kann. Wollt ihr nach dieser Funktionsänderung weiterhin mit eurem Androiden surfen oder E-Mails empfangen, solltet ihr spätestens jetzt dieser »App« den Zugriff nach »außen« erlauben.Eine weitere, durchaus umständlichere Methode, um die entsprechenden DNS-Anfragen von Apps zu kontrollieren ist, sich das Programm dnsproxy2 zu installieren und mittels dieses Programms die DNS-Anfragen »umzuleiten«.
- Weiterhin tauchen im Zusammenhang mit der Systemkomponente »(Kernel) Linux Kernel« immer wieder Pakete auf, die auf den ersten Blick nicht zuzuordnen sind. Eine genauere Analyse dieser Verbindungen sorgt allerdings auch hier schnell für Klarheit. Es handelt sich hierbei um »Service-Pakete«, wie TCP-Retransmissions oder den Versuch einen »verwaisten« Port zu schließen. Ihr werdet nämlich feststellen, dass all diese Pakete in unmittelbarer Verbindung mit Apps stehen, denen ihr den Zugriff auf das Internet erlaubt habt.
4.7 Custom-Scripts
Erfahrene Anwender können über Custom-Scripts der AFWall+ den vollen Funktionsumfang der iptables Firewall ansteuern. Bevor ihr aber wild herumexperimentiert, solltet ihr euch vor diesem nicht unkomplizierten Unterfangen zunächst ausführlich über iptables und der hierbei gebotenen Möglichkeiten informieren. Eine gute Informationsquelle ist der Wikipedia-Artikel und auch der offizielle Einstieg in die Custom-Scripts im AFWall+ Wiki.
Hinweis: Ein falscher Umgang mit iptables bzw. Custom-Scripts kann euer Smartphone für sämtliche Netzwerkverbindungen von jetzt auf gleich komplett sperren. Eine Aufhebung dieser Sperrung ist nicht so einfach möglich bzw. nur dann, wenn ihr euch vorher ausreichend informiert habt. Die nachfolgenden Ausführungen sollen euch aufzeigen, wie ihr Custom-Scripts wirkungsvoll einsetzen könnt.
4.7.1 Einschränkung
Unter den Optionen könnt ihr bei AFWall+ eine »IPv6-Unterstützung« aktivieren. Allerdings verträgt sich diese Einstellungen nicht immer einwandfrei mit den Custom-Scripts bzw. den Befehlssätzen. Wollt ihr also Custom-Scripts verwenden, so solltet ihr diese Option in jedem Fall deaktiviert lassen. Ansonsten werden die iptables-Regeln oftmals nicht korrekt angewendet und die AFWall+ vollständig deaktiviert. Mit zwei Befehlszeilen sorgen wir dafür, dass keine IPv6-Pakete versendet bzw. empfangen werden können.
4.7.2 Facebook Beispiel
Angenommen wir haben mit dem sozialen Netzwerk »Facebook« überhaupt keine Berührungspunkte, sprich wir nutzen es nicht und wollen auch nicht, dass Facebook unsere Daten bekommt. Die Krux beim Surfen im Netz ist jedoch, dass viele Webseiten »Social Media Buttons« verwenden, um Anwendern die Möglichkeit zu geben, die Inhalte schnell auf den entsprechenden Plattformen mit anderen Nutzern der Netzwerke zu teilen. Ein in diesem Zusammenhang sehr beliebter »Button« ist der Facebook »Like Button«. Mit diesem kanPCAPdroidn ein Facebook Nutzer sein »Gefallen« bzgl. eines Weseiteninhaltes ganz einfach ausdrücken und mit anderen Facebookmitgliedern teilen. Das Problem an diesem »Button« ist jedoch oftmals (wenn nicht die sog. Zwei Klick Lösung gewählt wurde), dass man als unbeteiligter Nutzer schon mit dem Laden des Buttons gewisse Informationen, wie seine IP-Adresse direkt an Facebook übermittelt. Da der Nutzer (normalerweise) praktisch keine Möglichkeit hat, sich vor dieser Datenübermittlung zu »schützen« ist der Einsatz dieses Buttons datenschutzrechtlich auch nicht gerade unproblematisch. Darüber hinaus »verschwendet« unser Browser mit jedem Laden dieses Buttons und der Übermittlung unserer Informationen wertvolle Zeit und Datenvolumen, was für viele ein weiteres Ärgernis darstellt.
Mit unserer AFWall+ und den Custom-Scripts können wir hier allerdings Abhilfe schaffen. Im Folgenden wollen wir euch deshalb aufzeigen, wie ihr der Datensammelwut von Webseiten bzw. von Facebook Einhalt gebieten könnt. Hierzu benötigen wir im Prinzip nur zwei Custom-Scripts für die AFWall+.
Der Inhalt dieser Skripte basiert auf Informationen, die Facebook selber den Devolpern von Webseiten (öffentlich) zur Verfügung gestellt hat. Facebook hat nämlich nach eigenen Aussagen Verständnis dafür, dass der Developer einer Webseite, auf der sich auch sensible Informationen befinden, nicht unbedingt will, dass sog. »Facebook-Crawler« diese sensible Bereiche betreten und diese Informationen indexieren bzw. abgreifen. Aus diesem Grund informiert Facebook die Developer, welche IPs sie sperren sollen, um diese Crawler vom Sammeln der Informationen abzuhalten. Wir wollen an dieser Stelle betonen, dass es uns fern liegt, mit unseren Scripten in das Geschäftsfeld von Facebook einzugreifen. Vielmehr wollen wir das Ansinnen Facebooks, nämlich die »Privatsphäre« der Nutzer zu schützen, gerne auch für unser Projekt aufgreifen. Wir verwenden deshalb nur die Informationen, die uns Facebook selber unter dem Punkt »Facebook Crawler« öffentlich zu Verfügung gestellt hat. Ob die dort gegebenen Informationen bzw. IP’s noch aktuell sind, müsst ihr allerdings selber herausfinden. Die von Facebook bereitgestellten Informationen dienten uns jedenfalls als Basis für die beiden nachfolgend dargestellten Skripte.
Update
18.01.2015: Viele von euch haben Probleme mit der Einbindung der Custom-Scripts. Im Folgenden sind die häufigsten Ursachen zusammengefasst:- Aufgrund der unterschiedlichen Zeichencodierungen sollten Windows-User den Notepad++ Editor für die Skripterstellung verwenden und vor der Übertragung auf das Android-Gerät eine EOL (End of Line)-Konvertierung in das Unix-Format vornehmen.
- Die korrekte Pfadangabe ist anschließend wichtig, damit das Skript überhaupt geladen werden kann. AFWall+ scheint auf einigen Geräten ein Problem mit den »virtuellen« Pfaden zu haben. Anstatt mit dem Pfad ». /storage/emulated/0/WEITERER_PFAD« könnt ihr es mal mit ». /storage/sdcard0/WEITERER_PFAD« versuchen. Der Punkt am Anfang des Skripts und ein Leerzeichen sind dabei ebenfalls zu beachten. Noch dazu können sich die Pfadangaben von Gerät zu Gerät unterscheiden. Einfache Datei-Explorer Apps zeigen euch meist nur den »virtuellen« Pfad zum Speicher an. Mit einer Terminal-App auf dem Gerät oder Remote über adb könnt ihr den korrekten Pfad ausfindig machen.
- Entscheidend für das korrekte Laden eures Custom Scripts ist darüber hinaus eine korrekte iptables Syntax.
- Deaktiviert in AFWall+ unter »Einstellungen« die IPv6-Unterstützung.
Startup-Skript:
Das Skript »iptables.sh« wird immer ausgeführt, wenn die Firewall gestartet wird bzw. die Regelsätze neu geladen werden.
## ## iptables.sh ## AFWall+ additional firewall rules ## Mike Kuketz ## www.kuketz-blog.de ## Changes: 25.08.2014 ## IPTABLES=/system/bin/iptables IP6TABLES=/system/bin/ip6tables # All 'afwall' chains/rules gets flushed automatically, before the custom script is executed # Flush/Purge all rules expect OUTPUT (quits with error) $IPTABLES -F INPUT $IPTABLES -F FORWARD $IPTABLES -t nat -F $IPTABLES -t mangle -F $IP6TABLES -F INPUT $IP6TABLES -F FORWARD $IP6TABLES -t nat -F $IP6TABLES -t mangle -F # Flush/Purge all chains $IPTABLES -X $IPTABLES -t nat -X $IPTABLES -t mangle -X $IP6TABLES -X $IP6TABLES -t nat -X $IP6TABLES -t mangle -X # Deny IPv6 connections $IP6TABLES -P INPUT DROP $IP6TABLES -P FORWARD DROP $IP6TABLES -P OUTPUT DROP ## Block Facebook https://developers.facebook.com/docs/apps/security ## Outgoing Connection $IPTABLES -A "afwall" -d 31.13.24.0/21 -j REJECT $IPTABLES -A "afwall" -d 31.13.64.0/18 -j REJECT $IPTABLES -A "afwall" -d 66.220.144.0/20 -j REJECT $IPTABLES -A "afwall" -d 69.63.176.0/20 -j REJECT $IPTABLES -A "afwall" -d 69.171.224.0/19 -j REJECT $IPTABLES -A "afwall" -d 74.119.76.0/22 -j REJECT $IPTABLES -A "afwall" -d 103.4.96.0/22 -j REJECT $IPTABLES -A "afwall" -d 173.252.64.0/18 -j REJECT $IPTABLES -A "afwall" -d 204.15.20.0/22 -j REJECT
Shutdown-Skript:
Das Skript »iptables_off.sh« wird immer dann ausgeführt, wenn die Firewall deaktiviert wird.
## ## iptables_off.sh ## AFWall+ shutdown actions ## Mike Kuketz ## www.kuketz-blog.de ## IPTABLES=/system/bin/iptables IP6TABLES=/system/bin/ip6tables # Flush/Purge all rules $IPTABLES -F $IPTABLES -t nat -F $IPTABLES -t mangle -F $IP6TABLES -F $IP6TABLES -t nat -F $IP6TABLES -t mangle -F # Flush/Purge all chains $IPTABLES -X $IPTABLES -t nat -X $IPTABLES -t mangle -X $IP6TABLES -X $IP6TABLES -t nat -X $IP6TABLES -t mangle -X # Allow IPv4 connections $IPTABLES -P INPUT ACCEPT $IPTABLES -P FORWARD ACCEPT $IPTABLES -P OUTPUT ACCEPT # Deny IPv6 connections $IP6TABLES -P INPUT DROP $IP6TABLES -P FORWARD DROP $IP6TABLES -P OUTPUT DROP
Die beiden Text-Dateien, legt ihr im Android-Dateisystem ab, um sie anschließend über AFWall+ aufrufen zu können. Tippt dazu wiederum auf die drei Pünktchen und wählt die Option »Setze eigenes Skript«. Hinterlegt dort jeweils das Startup- und Shutdown-Skript.
Sobald die neuen Regelsätze geladen sind passiert Folgendes: Wann immer euer Browser oder eine andere App dazu angewiesen wird, von den externen Quellen (Facebook IP-Adressen) Inhalte zu laden, wird die Verbindung von der AFWall+ verworfen bzw. die anfragende App bekommt ein »-j REJECT«. Technisch gesehen bekommt die anfragende App ein sogenanntes ICMP destination-unreachable Paket übermittelt und damit weiß, dass keine Verbindung mehr aufgebaut werden kann. Externe Inhalte auf Webseiten oder Apps die von Facebook stammen bzw. dort gehostet werden, fallen den Custom-Scripts damit zum »Opfer«. Als positiver Nebeneffekt werden Webseiten etwas schneller geladen und das Datenvolumen minimal entlastet.
Hinweis: Die vorstehenden Ausführungen stellen lediglich ein Beispiel mittels Informationen dar, die Facebook öffentlich zu Verfügung gestellt hat. Durch dieses Beispiel wollten wir euch demonstrieren, was mittels »Custom-Scripts« alles möglich sein kann. Gerne dürft ihr deshalb die Kommentarfunktion des Blogs nutzen und mit den anderen Lesern eure speziellen Einsatzzwecke und Vorgehensweisen von Custom-Skripts zu teilen bzw. zu diskutieren.
4.8 Letzter Hinweis
Wer jegliche »fremdgesteuerte« Datenübermittlung seines Smartphones verhindern möchte, sollte Folgendermaßen vorgehen:
Nach dem ersten Start eures frischen Custom-Roms solltet ihr zunächst alle Netzwerkverbindungen wie WLAN und mobiler Datenverkehr deaktivieren.
Bevor ihr Apps installiert, solltet ihr euch zuerst das AFWall+ APK-File über euren Rechner herunterladen, die APK-Datei per USB auf euer Android-Gerät übertragen und mittels eines Dateimanagers von Hand installieren. Nehmt dann die AFWall+ entsprechend unserer Ausführungen unter Ziffer 4.5 in den Betrieb.
Erst danach solltet ihr die Netzwerkinterfaces wie WLAN und mobile Daten wieder aktivieren. So vermeidet ihr auf einem frisch installierten System jegliches Abfließen von Daten.
5. Fazit
Mit dem F-Droid Store haben wir Zugriff auf FOSS-Apps, die uns als Alternative zu bekannten Apps dienen sollen. Insbesondere profitieren wir als kritischer Anwender von den freien und quelloffenen Anwendungen, die im F-Droid-Store angeboten werden. In Kombination mit alternativen Diensten, gelingt es uns damit mehr und mehr, die Datenherrschaft auf unserem Smartphone zurückzuerlangen.
Besonders AFWall+ stellt ein herausragendes Tool dar, um den ungewollten Abfluss von Informationen von unserem Smartphone zu verhindern. Uns war es deshalb ein besonderes Anliegen, das iptables Firewall-Interface ausführlich vorzustellen. Es sollte nämlich durch unsere vorstehenden Ausführungen deutlich werden, dass selbst ein alternatives bzw. »freies« CyanogenMod uns per se nicht vor dem Aufbau von Datenverbindungen nach »außen hin« schützt. Über Custom-Scripts sind wir in der Lage, gezielt IP’s zu blocken und können uns damit richtig »austoben«.
Im nachfolgenden Beitrag der Artikelserie werden wir das Tool PCAPdroid detalliert besprechen. Ihr könnt damit selbst nachvollziehen bzw. kontrollieren, welche Verbindungen euer System nach außen initiiert und damit den Wirkungsgrad der AFWall+ verifizieren. Bevor wir allerdings weiter in die Analyse von Datenverbindungen einsteigen, war es uns zunächst wichtig aufzuzeigen, wie ungewollte Verbindungen eingedämmt werden können.
Autoren:
Bildquellen:
F-Droid: „Logo“, https://f-droid.org/
Ü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:
AFWall+: Wie ich persönlich die Android-Firewall nutze
AFWall+: Digitaler Türvorsteher – Take back control! Teil4
ASN-Skript: Datensammler haben ausgeschnüffelt – IPFire Teil3
F-Droid und App-Alternativen – Android unter Kontrolle Teil3
F-Droid: Freie und quelloffene Apps – Take back control! Teil5
98 Ergänzungen zu “F-Droid und AFWall+ – Android ohne Google?! 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.
Hallo,
ich glaube mich zu erinnern, daß ich mal wo gelesen hab, daß wenn man die F-Droid APP zur System-APP macht, man dann die Einstellung „Installation von unbekannten Quellen erlauben“ sogar aus lassen kann.
Vielleicht kann das ja mal einer testen, danke. Ansonsten bin ich sehrgespannt was noch alles kommt.
Danke für die Artikelserie.
Hallo,
mich würde auch interessieren, wie man die „unbekannte Quelle“-Warnungen bei App-Installation über F-Droid vermeidet.
auch von mir vielen Dank für die sehr interessanten Ausführungen!
Fabian
Hallo,
dazu musst du die F-Droid-App deinstallieren. Und dann nach /system/app kopieren. Anschließend wär ein neustart gut.
Einfach mal testen. Oder such mal mit Goole nach „f-droid system app“
… das hat bei mir geholfen. Aus dem F-Droid Forum:
es gibt eine sehr leichte Lösung dafür:
– F-Droid als normale App installieren
– Installation aus unbekannten Quellen erlauben
– /system/app mover aus F-Droid installieren
– Installation aus unbekannten Quellen verbieten
– F-Droid per /system/app mover zur system-App machen
– /system/app mover deinstallieren
Vielen Dank für die Erklärung unter „4.6 Besonderheiten ab Android 4.3+“
seit dem update meines Galaxy S3 im Feb. Wurmt mich das, konnte aber nix im deutschsprachigen Raum dazu finden. Ich wollte schon zurück auf 4.1.2.A
Um andere zum Rooten zu ermutigen:
Ich habe für mich den Schritt „Custom Rom“ erstmal ausgelassen, aber dafür:
– bloatware raus (samsung apps + cloud usw.)
– GAPPS raus
– F-droid und Xposed installer drauf
– AFWall+ , Netzwerk Log drauf
– hier bin ich auf Xprivacy gestoßen (ist gar nicht so kompliziert wie´s ausschaut, etwas Geduld und mit köpfchen hächchen setzen, dann passt es) DANKE! Klasse App.
– Tint browser (mit Addblock und incognito funktion)
– Custom Scripts sind der nächste Schritt.
Danke Mike, bleib bitte am Ball.
Hallo,
erstmal vielen Dank für diesen guten Artikel.
Ich hätte noch eine Frage zu dnsproxy2. Muss ich um dieses Script zu installieren wirklich erst das Android NDK installieren? Dachte man kann das ganze einfach über adb abwickeln. Aber auch da klappt es mit den Befehlen nicht.
Gruß
Ja das NDK wird zum »builden« der App benötigt.
Ok danke.
Hab gerade in den Einstellungen von Afwall+ gesehen das es dort auch folgende Option gibt : “ Disable DNS via netd “ . Hat diese Option die selbe Funktion wie das Script ?
Hallo Julian,
vielen Dank für deinen wertvollen Hinweis.
In diesem Zusammenhang fällt mir mal wieder das Sprichwort ein:
„Wieso schwer, wenn es auch einfach geht“.
Wir haben deinen Hinweis unter Punkt 4.6 unseres Beitrags aufgenommen und mit den entsprechenden Hinweisen versehen.
Danke für den inspirierenden Artikel. Werde mich demnächst intensiv damit auseinandersetzen.
Wenn ich die DNS-Anfragen in AFWall+ bei »DNS-Proxy« von »automatisch« in »DNS über netd deaktivieren« umschalte geht bei gar nichts mehr online, auch die Apps die eine Erlaubnis bei AFWALL+ haben können dann nicht mehr online gehen. Woran könnte das liegen? Sobald ich wieder auf automatisch switsche funktiniert wieder alles…
Hat diese Systemfunktion bzw. App Zugriff auf das Internet: (Root) – Apps die Root-Rechte benötigen?
Meinst du damit ob in der White List von AFWall+ die Netzwerk-Freigabe bei Root – Apps die Root-Rechte benötigen gesetzt ist?
Antwort Mike: Ja das meine ich.
Hallo,
gibt es punkto Apps-Updates schon neue tool wie man seine Playstoreapps immer aktuell halten kann?
Ich muss leider google services nutzen, da Threma diese leider voraussetzt bzw braucht.
Thx grüße Razzor
Ich nutze Threema ohne Google-Dienste, habe unter Einstellungen – Fehlerbehebung „Polling“ aktiviert. Wenn Threema nicht im Vordergrund ist, wird trotzdem zuverlässig alle 15 min auf Nachrichten geprüft. Die einzige bisher entdeckte Einschränkung ist das Senden des aktuellen Standortes: funktioniert nicht, da Threema auf die Google-Maps-API zugreifen will.
Hallo,
wenn es dich stört, dann versuch mal von hier den LocationService und die MAPS.
https://forum.xda-developers.com/showthread.php?t=1715375
Interessant, sehe ich mir mal an. Danke
Wie steht es denn mit Messengern bei F-Droide? Ich nutze Xabber, TextSecure und Threema. Threema schließt sich natürlich aus aber OpenWhisperSystem sähe in F-Droid keine Option. Ein sicherer Kommunikationsweg mit dem man wie gewohnt seine Kontakte erreichen kann ist relativ wichtig für die meisten. Die Beiträge sind hier zu lesen.
https://github.com/signalapp/Signal-Android/issues/127
Nur Telegram konnte ich bei F-Droide finden welches ich weder für sicher, noch vertrauenswürdig halte. Man entzieht sich zwar der Kontrolle Googles wenn man die GAPPS weglässt jedoch auch der Sicherheit die Google durch regelmäßige App Kontrollen gewährleistet. Ein Virenscanner macht deiner Meinung nach jedoch keinen Sinn, also wie wird die Sicherheit dann gewährleistet? Ich nutze übrigens Omnirom habe allerdings ein paar Probleme und versuche nun CM. Etwas Skepsis CM gegenüber kommt jedoch schon auf da es nun einen gewerblichen Weg einschlägt und sich somit abhängig macht. Es wird ja einen Grund haben weshalb gleich 3 Hauptentwickler sich von CM abgewandt haben und Omnirom gründeten.
Kannst du etwas dazu sagen?
Gruß Omega
Hallo Mike,
wie sieht es denn mit dem nächsten Teil aus. Bisher tolle Artikelserie.
Wie sagt man so schön: »when it’s done« ;-)
Vermutlich in zwei Wochen. Im Moment leidet der Blog etwas, da einfach die Zeit fehlt.
Hallo Mike,
nachdem ich nun mein Moto G mit CM11 und freecyn installiert habe, habe ich festgestellt daß z.B. die Sportschau-App nicht mehr geht. Ich schau mir daher mal die Sport1-App an. Soll man solche Sachen hier diskutieren, oder wie wäre es mit einem Thread bei Android-Hilfe.de.
Willst du einen einrichten, und in deinen Artikeln vermerken, oder darf ihn einen erstellen und dort auf deine Seite verweisen?
Du darfst natürlich gerne einen Thread erstellen. Ein Forum ist in jedem Fall besser für Diskussionen und den Austausch.
Hab ich gemacht:
https://www.android-hilfe.de/forum/android-allgemein.20/android-ohne-google-account-sinnvoll-nutzbar.17993.html
Edit: Leider wurde mein Beitrag in einen anderen Thread integriert! Schade.
Hi,
ich hab Euer Tutorial soweit durchgeführt und mein neue onplus one von google soweit befreit und mit cyanogenmode (CM) geflasht, läuft wunderbar.
Dazu gibt es nun noch die eine oder andere Anregung oder Frage.
Zum Beispiel, wie verhält sich der Browser aus dem aktuellen CM ist dieser Vertrauenswürdig oder sollte dieser durch eine Alternative ersetzt werden.
Um nun für alle Familienmitglieder ein „freies“ Smartphone zu verfügung zu stellen, finde ich es etwas mühsam die Apps immer manuell zu installieren.
Nun wäre natürlich der fdroid Server eine Alternative, wenn ich mir aber die Specs dazu anschaue, kann diese nicht einfach auf einem Webserver so installiert werden, sondern braucht fast einen Linuxserver um fdroid Server zu hosten.
Habt ihr Euch da mal Gedanken zu einer Alternative gemchacht.
Ich stelle es mir so vor, dass die Apps mit einem alten Android Smartphone immer up to date gehalten werden und die Apps auf einen Speicher geladen werden, von wo diese dann an die Devices ausgegeben und aktualisiert werden.
Wäre natürlich toll, wenn das alte Smartphone dies irgendwie automatisch machen würde.
Aktualiserte App runterladen und auf den Speicher schieben, der Client auf den Devices aktualisiert dann die Apps.
Gibt es dazu Ideen?
Denke dass ist dann die letzte Massnahme um auch etwas Komfort zu haben.
Gruss Theo
Hallo Theodot,
ich nutze es selber nicht, aber bei aptoide.com kann man sich selber einen Store anlegen. Da kannst du dann die Apps die du haben willst selbst hochladen, und deine Familienmitglieder können SIe dann downloaden! Habe es aber selbst nicht getestet. Der F-Droid Client ist überigens ein Abkömmling vom Aptoide-Client. Der ist auch OpenSource und funktioniert in etwa genauso.
Hallo Theodot,
vielen Dank für dein Feedback.
Nach meinen Erfahrungen „telefoniert“ der Standardbrowser gerne mal nach Hause.
Auch den Verlauf, Cookies usw. dieses Browsers zu löschen, gestaltet sich als durchaus umständlich. Aus diesem Grund bin ich auf den Tint Browser umgestiegen. Mit diesem bin ich sehr zufrieden.
Wer etwas mehr Komfort will, sollte auf Firefox mit den entsprechenden Plugins umsteigen.
Diesbezüglich werden Mike und ich aber noch in einem weiteren Beitrag etwas schreiben.
Bzgl. deiner Anregung für die lieben Familienmitglieder haben Mike und ich uns auch schon so unsere Gedanken gemacht. Deshalb planen wir in einem weiteren Beitrag, einen oder mehrere Lösungswege hierfür aufzuzeigen. Eine etwaige Mitarbeit oder Ideen für die Lösung dieser durchaus kniffligen Geschichte sind natürlich immer herzlich willkommen.
Viele Grüße
Gerald
Dann warte ich gespannt auf Eure tollen weiteren Beiträge.
Leider kann ich als Dummies nicht viel Beitragen, ausser Euch etwas zu Spenden.
Interessant wäre auch, was für “sichere” facebook Client Alternativen es gibt.
Ich nutze zum Beispiel „fast for Facebook“.
Welche anderen Messenger man sonst benutzen kann etc…dass ist ein spannendes Thema.
Viele Grüße Theo
Hallo!
Gerade erschien dieser Artikel bei Heise:
https://www.heise.de/security/meldung/Black-Hat-2014-Netzbetreiber-Software-zum-Fernsteuern-von-Mobilgeraeten-erlaubt-Missbrauch-2287821.html
Meine Frage in Bezug zu deinem Blog hier: Ist diese Netzbetreiber-Software auf den Smartphones auch aktiv und nicht deinstallierbar, wenn man Cyanogenmod verwendet?
Wenn ja, dann frage ich, ob die ganze Mühe, Smartphones sicher zu machen, vergeblich!
Wie gelangt diese „Netzbetreiber-Software überhaupt auf das Smartphone? Vom Hersteller ab Werk oder wird sie direkt nach dem Einlegen der SIM-Karte des jeweiligen Netzwerkbetreibers auf dem Smartphone installiert?
Beste Grüße
Clemens
Hallo,
ich wollte mich nun mit dem Einspielen von Custom Scripts beschäftigen. Ich habe obige Facebook Scripts in den 2 Dateien abgelegt und in AFWall die Pfade eingegeben. Beim Aktivieren meldet AFWall aber nun „Fehler beim Anwenden der IPTables Regeln“
Woran kann das liegen?
Gruß
Gert
Das kann mehrere Ursachen haben:
– Falscher Pfad zu den Skriptdateien (achte auf den Punkt und die Leerzeile vor dem eigentlichen Pfad!)
– Fehler in der Befehls-Syntax
– Fehlende Berechtigung die Dateien zu lesen
Hm, alles noch mal geprüft.
– Pfad inkl. „. /“
– Befehle aus Beitrag kopiert
– AFWall hat keine XPrivacy Beschränkungen
Habe auch mal die Befehle direkt reingeschrieben, nicht als Pfad (geht das überhaupt?)
Welche Berechtigungen muss denn die Datei haben: Besitzer ? Gruppe ? S R W X ?
AFWall+ Version ist v1.3.4
Unter Custom-Scripts bitte nur den Pfad eingeben, keine iptables Befehle.
Die Berechtigungen für die Skripte bei mir sind: S()-R(x)-W(x)-X() für die Benutzer »Besitzer« und »Gruppe«. Somit sind die Skripte lediglich les- und schreibar. Explizite Rechte zum Ausführen (X) werden nicht benötigt.
Ich würde den Befehlssatz auf eine Zeile reduzieren. Beispielsweise Inhalt:
$IPTABLES --flush INPUTBei nur obiger Zeile in iptables.sh und iptables_off.sh kommt kein Fehler
Dann liegt es höchstwahrscheinlich an der »Zeichenübernahme« beim Kopieren. Bitte nochmal folgende Zeichen prüfen bzw. selbst neu eingeben:
– Das Minuszeichen
– Die Hochkommas
Ich weiß jetzt, woran es liegt. Ich hatte in den AFWall+ Einstellungen den Punkt „IPv6-Unterstützung“ aktiviert. Wenn ich den rausnehme wird das Skript akzeptiert.
Ist IPv6 nicht nötig?
Die “Zeichenübernahme” funktioniert mit dem Standard Windows Editor nicht, da (wie ich jetzt gelernt habe) UNIX andere Zeilenendzeichen verwendet. Zum Erstellen der *.sh Files deshalb einen anderen Editor verwenden, der UNIX Format beherscht. Zum Beispiel:
notepad-plus-plus.org
https://www.editpadlite.com/
Vielen Dank für die sehr interessante Artikelserie!
Habe bis auf CM alles umgesetzt.
Statt CM habe ich ein AOSP benutzt, also ein Android, das massiv abgespeckt ist.
Zusätzlich habe ich noch den Playstore mit Play-Dienst gelöscht.
Jetzt gehen fast keine Pakete mehr raus, von denen ich nicht weiß, wofür sie gut sind.
Gibt es eigentlich auch irgendwo IP-Listen, mit denen ich den gesammten IP-Raum von Google blocken kann?
Schau mal auf dieser Seite https://developers.google.com/apps-script/guides/jdbc?hl=en unter »Setup for other databases«
Kann mir jemand sagen, wo man die Ip-ranges / list für Microsoft u. Apple finden kann…?
Ich bin begeistert!
Es funktioniert perfekt!
Jetzt kommt mein Telefon nicht mehr an Google oder Facebook ran!
Un das Script habe ich gleich noch abgewandelt für meinen Linux-PC!
Genial!
Vielen Dank!
Vielen Dank für den großartiken Artikel!!
Ich bin von der Artikelserie „Android ohne Google“ begeistert!
Ich habe auf meinem Sony Xperia Z1 Compact alle jämmerlichen Google-Apps gelöscht und das hier beschriebene Tool AFWall+ installiert. Nur Firefox, die E-Mail App von Sony (mit Network log überprüft – sie baut zum E-Mail-Server eine Verbindung auf) und F-Droid haben die Berechtigung zum Internet.
Außerdem habe mit der zusätzlichen Funktion „Custom Scripts“ in AFWall+ alle IP-Adresse der Datenkrake Google gesperrt. Funktioniert prima!
Nun meine Frage:
AFWall+ sperrt, soweit ich das verstanden habe, die Verbindungen nach draußen, aber wie schaut es für Verbindungen von Draußen zum Smartphone aus?
Kann z.B. die Datenkrake Verbindung trotzdem eine Verbindung zu meinem Smartphone aufbauen, ohne dass ich etwas davon bemerke? Wäre es sicherer, wenn ich zusätzlich in Custom Scripts mit INPUT alle IP-Adressen von der Datenkrake sperre?
Viele grüße
Wenn du magst, kannst du auch in die INPUT-Chain die IP-Adressen der »Datenkraken« aufnehmen.
Würde dann so aussehen:
Hallo,
kann ich einer App, in diesem Fall EssentialPIM, zur Synchronisation mit der entsprechenden Windows-Software auf meinem PC, die Kommunikation durch die AFWall zur IP-Adresse meines PCs in meinem lokalen WLAN erlauben?
Gruß
Das geht über »Einstellungen -> LAN Control -> Häkchen setzen«. Anschließend erscheint in der AFWall+ Ansicht eine weitere Spalte für das lokale LAN / WLAN.
Ich meine nicht allgemein erlauben, sondern NUR eine spezielle IP als Destination erlauben, nämlich meinen PC.
Das würde über eine Regel in den Custom-Scripts funktionieren.
Beispielsweise: $IPTABLES -A „afwall-wifi“ –destination „192.168.0.1“ -m owner –uid-owner $EssentialPIM_UID -j ACCEPT
Super, probier ich am WE mal aus. Danke!
Ist damit die Funktion „LAN-Steuerung“ unter Einstellungen -> Benutzeroberfläche gemeint?
Ich würde gern bestimmten Apps (Audio, Video, Foto – Playern) Zugriffs auf das WLAN erlauben, aber eben nur auf das WLAN (z.B. den NAS) und nicht ins Internet. In meiner Fritzbox, kann ich zwar einzelnen Geräten den Zugang zum WLAN erlauben und gleichzeitig den Zugang zum Internet verbieten, aber nur dem gesamten Gerät.
Klappt das mit dieser Funktion? Einfach WLAN verbieten (kein Haken) und LAN erlauben (Haken)?
Gruß
Rainer
Hallo Rainer,
ja das sollte so wie von dir beschrieben funktionieren. Für manche Protokolle wie bspw. UPnP kann es aber sein, dass du auch ein Häkchen bei WLAN benötigst. Ansonsten funktioniert bspw. die Kommunikation zwischen Gerät und FritzBox Mediaserver nicht einwandfrei.
Einfach ausprobieren und gegebenenfalls mit den Firewall Protokollen arbeiten, falls es nicht funktioniert.
Hallo,
Habe Probleme, dass custom script einzubinden. Das shutdown script funktioniert ohne Probleme. Habe die Datei mit Notepad++ erstellt, Pfad überprüft, Befehle direkt von der Homepage kopiert.
Die Fehlermeldung lautet „Command exited with status 126. Can’t execute: Permission denied“
Woran kann das noch liegen?
Gruß
Marc
Hat sich erledigt.
Ist ja schön und gut, wenn man Notepad++ zum Erstellen der Dateien benutzt, aber man sollte dann eben doch die EOL Konvertierung auf Unix vollziehen. Danach hat alles wunderbar geklappt.
Danke für diese tolle Artikelserie!
Hallo Mike. Hier nur mal ein kurz ein großes Dankeschön für Deinen Blog hierlassen. Lese hier schon länger mit und konnte einiges hier mitnehmen. Wirklich klasse Dein Einsatz hier für ein wenig mehr Datensicherheit im Android-Universum auch wenn das sicher manchmal ein Kampf gegen Windmühlen ist. Dont stop it ! Grüße Mark
Hallo zusammen,
nach ein paar Tagen des Gewöhnens an den CM11, bin ich soweit erstmal zufrieden. Herzlichen Dank an diesen tollen Blog, ohne den ich den Umstieg auf CM nie in Angriff genommen hätte.
Was mir zum rundum glücklich sein jetzt noch fehlt bzw. was mir noch Probleme bereitet ist folgendes:
1.) Kann mit den Tipps zum DL via Chrome App Installer keine Apps aus dem Google Store installieren. Er hat nur ein GT-I9300 Telekom als Gerät bei mir gelistet und sagt, die App wird demnächst installiert. Er erkennt mein S3 aber nicht als mein Gerät. Hatte ja zuvor dummerweiser via Installer den CM11 aufgespielt und da war als FW wohl die Telekom-Variante aufgespielt. Mein Gerät ist aber schon immer ein internationales ohne Branding gewesen. Nach der manuellen Installation habe ich auch die INT-FW aufgespielt. Kann es daran liegen?
2.) Habe in F-Droid weder ein gutes Wetter-Widget ala AccuWeather oder WeatherPro entdecken können. Habt ihr da einen Tipp? Benötige ich unbedingt.
3.) Bin noch auf der Suche nach einer guten Notizen App – hierzu konnte ich im F-Droid auch nichts finden. Gibt es noch gute Markets außer F-Droid, wo man sich mit Apps austoben kann?
4.) Meine Akkulaufzeit ist nach dem Aufspielen des CM11 auch stark gesunken. Es gibt auch keine effiziente Energiesparfunktion. Zumindest habe ich keine entdeckt außer die Standort-Option.
Freue mich auf euer Feedback.
Hallo Mike, was genau wird denn eigentlich alles an Traffic erlaubt, wenn man bei „(Root) – Apps die Root-Rechte benötigen“ das Häkchen setzt? Hatte bisher vermutet, dass man damit alle Root-Apps vollständig whitelistet, aber dann würdest du das ja wohl nicht empfehlen, oder?
Lies dir dazu nochmal Punkt »4.6 Besonderheiten ab Android 4.3+« durch.
Zudem kann eine Root-App theoretisch immer ins Internet – jedenfalls wenn sie das unbedingt wollte. Daher sagen wir auch: Nur jene Root-Apps installieren, denen man »vertraut«. Darauf sind wir in der Artikelserie aber schon ausführlich eingegangen.
Ich hatte mir alles genau durchgelesen, vorher poste ich keine Fragen. Dennoch habe ich es mir jetzt noch einmal durchgelesen, sehe aber immer noch nicht, wo da meine Frage beantwortet wird, was genau alles an Traffic erlaubt wird, wenn man bei “(Root) – Apps die Root-Rechte benötigen” das Häkchen setzt. Die Frage wäre im Artikel nur beantwortet, wenn die in Punkt 4.6 beschriebene Möglichkeit, DNS-Anfragen über diese UID zu senden, die einzige Änderung wäre, die sich aus dem Setzen des Häkchens ergäbe.
Ist dem denn so, oder stimmt doch meine Vermutung, das jeglicher(!) Traffic von Root-Apps durch das setzen des Häkchens erlaubt wird?
Das fände ich ich schon heikel und schlimmer als das beschriebene Schleusen der DNS-Anfragen über den netd-Daemon, wobei das natürlich jede(r) für sich selbst entscheiden muss, was für ihn/sie das geringere Übel ist.
Du schreibst, Root-Apps könnten immer ins Internet, wenn sie wollten. Da das Setzen des Häkchens bei “(Root) – Apps die Root-Rechte benötigen” jedoch offensichtlich einen Unterschied macht, hat man als Benutzer aber doch die Möglichkeit die Verbindungsrechte der Root-Apps zu beeinflussen, unabhängig davon, ob sich diese Apps über die Beschränkungen hinwegsetzen könnten, wenn sie wollten, oder nicht. Sie tun es offensichtlich „freiwillig“ nicht, sonst müsste man das Häkchen ja nicht setzen.
Hi Moe,
ich habe deine Frage nicht vergessen. Diese findet sich aktuell in Klärung beim Entwickler.
Was ich dir berichten kann:
Ein Häkchen bei »(Root) – Apps die Root-Rechte benötigen« ist für diverse systemeigene Dienste wichtig, so zum Beispiel VPN-Verbindungen oder eben DNS-Anfragen. Zusätzlich installierte Apps, die Root-Rechte benötigen, scheinen mit der Bezeichnung nicht gemeint zu sein. Diese werden davon unabhängig über die entsprechende UID von der AFWall+ kontrolliert.
Aber nochmal: Root-Apps sind theoretisch in der Lage die iptables-Firewall zu umgehen. Daher nutzen wir selbst nur eine beschränkte Auswahl an Apps, die Root-Rechte erfordern bzw. denen wir »vertrauen«.
Hallo,
per Note++ habe ich die beiden Auszüge in die entsprechenden Dateien kopiert und auf das Handy geschrieben. In AFWall habe ich dann bei den Skripten die Pfade angegeben. Dabei kommt es allerdings zu einem Fehler. Wenn ich die Pfade wieder raus lösche, funktionieren die Regeln wieder. Dann allerdings habe ich das Prolem, dass ich ständig die Meldung erhalte: AFWall+ blockierte: (ROOT) – Apps die Root-Rechte benötigen(0) -192.168.178.1:53
Dabei habe ich keinen Haken an entsprechender Stelle gesetzt. Seit dem äuft gar kein Traffic mehr – Alles ist tot.
Weis dazu vllt jmd Rat? Frohe Weihnachten btw!
Versuch es mal in Notepad++ mit der EOL Konvertierung auf Unix.
Hallo Mike,
bei mir ist es auch so, daß ich trotz EOL: Unix im Notepad++ leider keine Coustom-Scripts definieren kann. Es kommt immer zu dem bekannten Fehlern. Wenn ich die Scripts im CM-Dateimanager anschaue, sehen die ganz normal aus, kein Problem mit dem Zeilenende! Muß man die Scripte evtl. in ANSI oder so machen? Ich hatte in Notepad++ UTF8 mit BOM voreingestellt.
Die Scripte wieder löschen geht bei mir Problemlos.
Hallo Mike,
auch ich kann das aben angeführte Script (mit UNIX-EOL) nicht aktivieren. Alle bisher genannten Tipps helfen nicht. Ohne Script funktioniert die Firewall. Habe auch vergebens mehrere Speicherorte für die Script-Datein (/sdcard/afwall, ./sdcard/afwall, /etc, ./etc) mit entsprechenden Zugriffsrechten ausprobiert.
Nutze die aktuelle Version 1.3.4.1 unter CM 11 (Android 4.4.4)
Gibt es noch eine Idee?
Ich habe unter Ziffer 4.7.2 die häufigsten Ursachen inklusive Problemlösung zusammengefasst. Ansonsten habe ich keine weiteren Ideen. ;-)
Habe mein Problem gelöst:
Zwischen dem einleitenden Punkt und der Pfadangabe muss ein Leerzeichen stehen. (Also kein relativer Pfad). Das ist oben so beschrieben, hatte ich aber überlesen. Der funktionierende Eintrag sieht dann bei mir so aus: . /sdcard/afwall/iptables.sh
Vielen Dank und ein dickes Lob für die gut geschriebenen Beiträge, die mit Hintergrund und Praxis dem Datenschutz bei Andoid eine Chance geben.
Leider bekomm ich es nicht hin. Kann jemand mal irgendwo die zwei *.sh ablegen, damit ich weiß ob es an denen liegt oder am Pfad! Danke.
Kuck mal unter Settings→Firewall Rules. Ganz unten kriegst du eine Fehlermeldung.
Ich bekomme es leider nicht hin. Jedenfalls nicht, wenn ich zwei Einträge rein schreibe. Beide beginnen mit „. /“
Ist es so überhaupt möglich?
Ich auch nicht. Ich hab hier mal die Daten aus dem LOG:
22:44:19 Starting root shell…
22:44:19 [libsuperuser] [SU%] START
22:44:19 Root shell is open
22:44:24 [libsuperuser] [SU%] SHELL_DIED
22:44:24 libsuperuser error -2 on command ‚. /sdcard/Download/iptables.sh‘
22:44:28 Starting root shell…
22:44:28 [libsuperuser] [SU%] START
22:44:29 Root shell is open
Nur sagt mir das nicht, ob das FILE defekt ist oder der Pfad!
Wahrscheinlich nicht möglich aber ich frage trotzdem mal.
Man kann ja LAN und WiFi getrennt regeln. Aber was tun wenn man z.B auf seine Sachen im Heimnetz
zugreifen möchte aber nicht will das die App ins WWW geht?
Man muss ja beides aktivieren den ohne WiFi kein Heimnetz…
Hier hab ich noch einen schönen Artikel gefunden:
https://blog.torproject.org/mission-impossible-hardening-android-security-and-privacy
Dort heißt es das „Fix Startup Data Leak“ in CM nicht funktioniert. Allerdings ist der Artikel ein Jahr alt.
Und will bei euch auch ständig der Taschenrechner kommunizieren?
Außer dem Linux Kernel ist das bei mir das einzige nach 2 Tagen Nutzung.
Hallo Mike,
ich bin absoluter Neuling auf dem Gebiet, habe mich aber bereits erfolgreich bis hierhin durchgekämpft. :) Vielen Dank für diese super Anleitung hier!
Jetzt hätte ich allerdings eine Frage. Ich habe bei meinem Galaxy S3 mit CM 10.2.0-i9300 die Pfade der beiden Skripte so eingegeben, wie sie mir mein Dateimanager angezeigt hat. Dann auf OK und dann kam… nichts. Immerhin auch keine Fehlermeldung, aber auch keine Bestätigung. Ich kann auch nirgends bei AFWall+ irgendwas finden, dass die beiden Skripte nun laufen. Wenn ich auf „Skript festlegen“ gehe, sind die beiden Felder leer wie am Anfang, im Firewall-Protokoll und bei den Firewall-Regeln ist auch nichts zu finden. Ist das normal so?
Danke und Gruß,
Günter
Nein das ist nicht normal. Du kannst nochmal die Ergänzung vom 18.01.2015 prüfen (weiter oben im Text). Mehr kann ich dazu leider auch nicht sagen.
Das bedeutet dass AFWall die Dateien nicht lesen kann.
Vermutlich sind sie nicht im richtigen Dateiformat angelegt.
Du musst unbedingt Notepad++ verwenden und auf UNIX umstellen, du findest die Einstellung unter: Bearbeiten/Format Zeilenende/ konvertiere zu UNIX (LF)
Ich hatte damit anfangs auch meine Probleme ;-)
Bleib dran, du schaffst das!
Hm, also ich habe die beiden Skripte von oben in Notepad++ kopiert, das Zeilenende auf UNIX geändert und die Skripte als iptables.sh und iptables_off.sh auf die SD Karte gespeichert, wo ich sie im Dateimanager auch finden kann. Nur wenn ich die Pfade bei AFWall eintippe, passiert nichts.
Mich hat schon mal gewundert, dass keine Fehlermeldung kommt. Haben einige hier ja beschrieben.
Ich hätte jetzt als nächstes vermutet (wie es oben ja auch steht), dass mir der Dateimanager nur die virtuellen Pfade anzeigt. Leider weiß ich nicht, wie man mit den korrekten Pfad findet. Ich habe die App „Terminal Emulator,“ aber keine Ahnung, wie das geht. Kann mir das jemand vielleicht kurz erklären?
Vielen Dank schonmal im Voraus!
Grüße, Günter
Du kannst die Dateien auch mit dem Editor vom ES-Explorer editieren. Ich hab sie unter Linux von hier in den „Kate“ Editor kopiert und mit der Einstellung „unix“ abgespeichert.
Dann auf die int. SD in den Ordner afwall kopiert und mit dem Totalcommander den Pfad überprüft.
bei mir: ./storage/sdcard0/afwall/iptables.sh
Das geht auch ohne Probleme! AFWall+ meldet die erfolgreiche Aktivierung des Scripts.
um IP’s zu sperren, habe ich die Datei um folgende Zeile erweitert:
iptables -A OUTPUT -s 0.0.0.0 -j DROP
statt der 0.0.0.0 sind die IP’s der zu sperrenden Seiten einzutragen. Die hab ich vorher mit „Network Log“ aufgezeichnet.
Bei mir läufts wohl so. ;-) Hab jedenfalls nix negatives bemerkt.
Top Arbeit!
Was ist davon zu halten,https://play.google.com/store/apps/details?id=com.jianjia.firewall&hl=de
was die Sicherheit den VPN betrifft?
OpaL
Das Prinzip wird ähnlich zur »No Root Firewall« sein: https://www.kuketz-blog.de/android-firewall-ohne-root-%E2%80%A2-noroot-firewall/
Vielleicht lieber REJECT anstatt DROP verwenden. =)
https://serverfault.com/questions/157375/reject-vs-drop-when-using-iptables
Okay.
Danke dir Mike.
Hallo. Ich komme noch nicht ganz klar.
Mein Handy ruft zu oft bei GOOGLE an. Im Range 173.194.0.0, zb. TCP6 173.194.112.1:80
Ich habe schon mehrere Sachen probiert, leider ohne Erfolg.
Beispiele:
Muss ich in der AFWall+ noch zusätzlich IP v6 Unterstützung aktivieren? Wo liegt der Fehler?
Die erste Zeile funktioniert bei mir.
Nach Änderungen der Konfiguration: Im Menü „Anwenden“ nicht vergessen.
Hallo!
Also, am 21.9.14 hatte ich mich schon mal gemeldet, wegen der Adressen von Google.
Und das ganze hatte auch wunderbar funktioniert.
So gut, daß ich das ganze auch auf meinem Linux-PC umgesetzt hatte.
Leider stelle ich in letzter Zeit fest, daß ich Google oder Youtube sowohl auf Android, wie auch auf meinem Linux-PC trotzdem aufrufen kann.
Die IP-Ranges habe ich soeben noch mal überprüft.
Ich kann mir das nicht erklären!
Hat jemand eine Idee?
Meine einzige Erklärung wäre die, daß Google neue IP-Range dazugenommen hat, die sie nicht mehr auf ihrer Seite veröffentlicht haben.
https://developers.google.com/apps-script/guides/jdbc?hl=en
Oder welche Erklärung gäbe es sonst noch?
Firewall geht! Wenn ich eine der gesperrten IP pinge (unter Linux), meldet ping, daß es keine Route zum Host finden kann.
WÜrde mich sehr interessieren, was da los sein kann.
So, gerade habe ich mal probiert, google zu pingen und bekam als Adresse 216.58.211.14
Whois meldet mir, daß der IP-Range 216.58.192.0/19 zu google gehört!
Ist bisher nicht in Deiner Liste, lieber Mike. Vielleicht bitte noch aufnehmen.
Ich werde immer mal wieder ping probieren, denn die IPs wechseln auch noch von Zeit zu Zeit.
Bin auf der Suche nach weiteren IP-Ranges für google. ;-)
Hallo Stefan,
ich kann mich nicht erinnern irgendwo eine Liste mit Google IP-Adressen veröffentlicht zu haben. Vermutlich hatte ich dir das per E-Mail zugeschickt.
Von Zeit zu Zeit muss die Liste aktualisiert werden. Eigentlich geht das relativ fix mit folgenden Befehlen auf dem Terminal:
Hallo Mike und Stefan,
die o.g. nslookup-Abfragebefehle ergeben keine vollständige Auflistung der Google-IP-Adressräume.
Beispielsweise wird der Google-Adressbereich 173.255.112.0/20 nicht ausgewiesen.
Ja, das habe ich auch schon bemerkt.
Und zwei weitere Adressräume fehlen dabei auch auch.
Ja ihr habt beide Recht. Ich habe jetzt die IPv4-Adressen direkt vom Google AS extrahiert: https://ipinfo.io/AS15169
Ob das nun alle sind, kann ich auch noch nicht sagen. Mit einem kleinen Shell-Skript lassen sich alle Adressen extrahieren. Allerdings sind dann einige Adressblöcke doppelt bzw. lassen sich auch zu einem größeren zusammenfassen.
Ich hab mir auch ein Python Skript gebastelt, was die Adressen zusammenfasst und mir dann gleich in Copy-Paste Zeilen für AFWall umwandelt. Ist aber noch eine Spielerrei.
Ihr könnt die Adressen erstmal folgendermaßen auslesen:
curl --silent https://ipinfo.io/AS15169 | grep -EiIoh '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}/[0-9]{1,2}' | uniqIch lese mit viel Interesse wie ihr hier versucht Google auszusperren. Speziell die Seite https://ipinfo.io/AS15169 fand ich spannend. Mein Fachwissen hält sich aber leider in engen Grenzen.
Mir ist allerdings eins aufgefallen. Google firmiert scheinbar nicht nur unter AS15169. Benutzt auf der folgenden Seite einfach mal die Suchfunktion nach „google“.
https://ipinfo.io/countries/us
AS16591
AS36384
AS36040
…
Ich hab bei 10 Treffern aufgehört reinzugucken. Für Facebook hab ich nur einen Treffer gefunden. Irgendwie erscheint mir das manuelle Sperren von Google IP-Ranges bei dieser Menge wie ein Kampf gegen Windmühlen. Hab ich das System falsch verstanden?
Gruß
Rainer
Schau mal hier: Google und Facebook IP-Adressen blockieren
Hallo,
Nach Übernahme der Skripts läuft der Hotspot nicht mehr. Er schaltet sich in kurzen Intervallen aus und ein. Nach Entfernung des Skripts steht der Hotspot stabil. Auch lässt sich eine Client Verbindung aufbauen, jedoch gelingt kein Aufruf einer Website.
Alle restlichen Einstellungen entsprechen den hier im Artikel vorgestellten Vorschlägen. Ich weiß nicht was ich jetzt probieren kann, um den Hotspot zum vollständigen Funktionieren zu bringen.
Kann mir jemand bei diesem Problem helfen, hat jemand eine Idee, was zu tun ist?
https://ipinfo.io/AS15169
Wow! Da taucht ja noch eine Menge mehr auf!
Die letzenzwei Zeilen könnten DNS sein. Kommt mir von irgendwo bekannt vor.
Aber ich hatte durch Pingen noch mal drei weitere kleine Ranges gefunden, die in der Liste z.B. nicht auftauchen. (Die drei letzten Zeilen in meinem Routerscript, das ich Dir sandte.)
Aber das kann sein, daß die nicht direkt zu google gehören. Eins davon war z.B. google Irsael.
Auf jeden Fall vielen Dank für die Arbeit! Superklasse! Nur so lassen sich die Löcher vielleicht doch noch stopfen.
Hallo,
mein Handy läuft nun schon länger unter Cyanogenmod und mit AFWall.
Nun will ich das Handy meines Sohnes zumindest rooten und mit AFWall und XPrivacy ausstatten damit es keine unbemerkten Kontaktaufnahmen gibt. Auf Google & Co. kann/will er verständlicherweise ;-) nicht verzichten.
Welches OS würdet Ihr dazu empfehlen? Original Android, Cyanogenmod, oder etwas anderes?
Gruß
Gert
Nachtrag:
Ich glaube, wenn ich für meinen Sohn mit Cyanogenmod und XPrivacy anfange muss ich mich nachher um alles kümmern…
Wenn man beim Stock ROM Android Lollipop bleibt und nur das Handy rootet, um AFWall nutzen zu können sollte das zum Ausschließen ungewünschter App-Verbindungen doch auch schon Einiges helfen? Ich weiß, keine tolle Lösung aber besser als nichts. Was meint Ihr?
Mike,
danke für den Beitrag zu AFWall+. Ich bin nun keine Android-Power-User aber der Zwang zu Google und Co. ist mir schon unheimlich. Da helfen deine Beiträge schon, dass man wieder etwas mehr Überblick und Sicherheit erhält. Auch schön, dass man feststellen kann „man ist mit seiner Denkweise nicht allein“. Und das alles noch in deutsch, das hilft schon sehr.
Nach langen Überlegungen, und auch weil die Android-Version veraltet war, habe ich mich getraut mein S3 mini zu rooten und es hat nun CyanogenMod 12.x mit Android 5.1.1 (Lollipop). Beim starten von AFWall+ bekam ich erst mal einen Dämpfer –> Meldung kein Root. Nach etwas Recherche hilft folgende Vorgehensweise:
1. Entwicklermodus einschalten:
– gehe zu „Einstellungen“
– gehe zu „Über das Telefon“
– gehe Zu „Build-Nummer“
— diese mehrfach anklicken. Countdown wird angezeigt (wieviele Klicks bis zum Entwicklermodus)
– gehe zurück zu Einstellungen
– dort erscheint zusätzlicher Eintrag „Entwickleroptionen“
2. Root einschalten:
– gehe zu „Entwickleroptionen“
– gehe zu „Root-Zugriff“
— wähle „Apps & ADB“ aus
– gehe zurück
3. AFWall+ startet nun beschwerdefrei
Vielleicht ist diese Info hilfreich, wenn es wie bei mir nicht gleich beim ersten Start von AFWall+ klappt. Es ist ein gutes Gefühl wenn man wieder etwas mehr Kontrolle hat.
Nochmals danke, ich werde deine Beiträge weiterhin verfolgen.
Thomas
Hallo scripte funktionieren wunderbar , allerdings kann ich auf mein openvpn server nicht mehr verbinden.
Hat evt jemand eine lösung, evt whitelist für den openvpn server ???
Gruess
Hallo Mike,
vielen Dank für den sehr nützlichen Artikel, hat bei mir einwandfrei geklappt mit dem Custom Skript. Ich möchte aber gerne auf eine Sache hinweisen, vor der auch im Artikel verlinkten „AFWall+ Wiki“ ausdrücklich gewarnt wird:
„please note that this can create a serious security breach on your device, since the script will be always executed as root! You must place your script where other applications will not be able to modify it (the sdcard is NOT a good place!).“
In Euren Beispielen platziert Ihr das Custom-Skript eben genau dort, auf der SD-Karte!
Zumindest bei meinem Gerät (2013er Moto G mit CyanogenMod 13, wo die SD-Karte nur emuliert wird) kann ich die Berechtigungen unter /storage/emulated/0/… NICHT mit chmod anpassen, so dass dort tatsächlich jede App mit SD-Karten-Berechtigung Änderungen vornehmen könnte.
Ich habe das Custom Skript deshalb unter einem extra angelegten Verzeichnis unter /data/ mit Owner=root und Gruppe abgelegt.
Ob die Berechtigungen auf der SD-Karte grundsätzlich nicht anpassbar sind oder dies eine Besonderheit meiner Konfiguration darstellt, kann ich nicht beurteilen, aber es ist in der Tat existenziell wichtig, dass keine App (außer vielleicht AFWall+ selbst) über Schreibberechtigung auf das Custom Skript verfügt – dies sollte in dem Artikel noch behandelt werden.
Viele Grüße, Markus
F-Driod nutzt anscheinend Amazon Web Services (AWS).
(Nicht nur F-Driod)
Bei dem Blockieren von Amazon (IPListen), kann man mit F-Droid keine Aktualisierungen mehr laden, geschweige denn Apps Laden/Installieren.
Ohne Blocken der A. AS funktioniert es.
Gibt es noch eine Datenkrakenlose Alternative?^^
Oder ist es ganicht mehr möglich, sich ein wenig Privatsphäre zurückzuholen?
https://www.speicherguide.de/news/amazon-tuetelt-mega-cloud-deal-mit-cia,-nsa,-fbi-co-ein-20203.aspx
https://bigbrotherawards.de/2012/kommunikation-cloud