1. Firewall
Im letzten Teil der Artikelserie »Take back control!« haben wir uns mithilfe von Magisk Root-Rechte auf unserem Android-System verschafft. Dieser Schritt war notwendig, da Apps wie AFWall+ und AdAway Root-Rechte zwingend voraussetzen.
An dieser Stelle sollten wir uns nochmal ins Gedächtnis rufen, dass uns ein Wechsel zu einem alternativen Betriebssystem wie LineageOS nicht zwangsläufig vor dem ungewollten Abfluss sensibler Daten schützt. Vielmehr bedarf es weiterer Anpassungen, damit wir das Android-Smartphone »selbstbestimmt« nutzen können. Eine wichtige Komponente unserer Abwehrstrategie ist die Verwendung einer Firewall, mit der wir den Datenverkehr des Androiden kontrollieren. 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.
Für Android existieren verschiedene Firewall-Lösungen – nennenswert sind allerdings nur zwei: NetGuard und AFWall+. Im vorliegenden Beitrag stelle ich euch die Installation und Konfiguration von AFWall+ vor. Die Firewall entspricht eher dem Grundgedanken der Artikelserie »Take back control!«, da sie mehr Freiheiten bietet.
- 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
2. AFWall+
AFWall+ ist ein Front-End für die aus der GNU/Linux-Welt bekannte Firewall iptables. Sie ermöglicht die Kontrolle darüber, welche App oder Systemdienst Zugriff auf das Datennetzwerk über 2G/3G/LTE/5G, Roaming, WiFi oder VPN haben soll. Sie ist aus meiner Sicht ein essentieller Bestandteil eines jeden gerooteten Android-Geräts, um den ungewollten Abfluss von Informationen zu kontrollieren.
AFWall+ ist in seiner Basis-Funktionalität relativ einfach zu bedienen, sofern man das Konzept einer Firewall einmal verstanden hat. Kompliziert wird es erst mit speziellen Anwendungsfällen, die über CustomScripts abgebildet werden. Wer eine benutzerfreundliche Alternative zu AFWall+ sucht oder sein Gerät nicht rooten kann / möchte, der sollte einen Blick auf NetGuard werfen.
2.1 Digitaler Türvorsteher
Nicht nur Android-Apps sind in der Regel äußerst »telefonierfreudig«, sondern auch Systemkomponenten. Wie häufig euer System und eure Apps »nach Hause« telefonieren ist abhängig von unterschiedlichen Faktoren. Auf zwei entscheidende möchte ich kurz eingehen:
- App-Store: Ein großer Nachteil der überwiegend proprietären Apps, die sich im Google Play Store befinden, ist die mit ihrer Proprietät verbundene Intransparenz der Datenverarbeitung. Denn bei diesen proprietären Apps wissen wir nicht und können es auch oftmals nicht überprüfen, was sie eigentlich (ohne unser Wissen) so anstellen – sprich, welche Daten sie an den Hersteller bzw. Dritte übermitteln. Eine weitere Problematik von proprietären Apps ist die oftmals schwer überprüfbare »Überwachung« des Nutzers durch Tracker- und Werbemodule, wie Andreas Itzchak Rehberg (Izzy) in seiner lesenswerten Analyse »Was hat es mit den Modulen in Android Apps auf sich?« aufzeigt. Das bedeutet: Gerade derjenige, der seine Apps vornehmlich aus kommerziellen App-Stores wie dem Play Store bezieht, der sollte den ausgehenden Datenverkehr zwingend mit einer Firewall kontrollieren – oder besser: Auf einen Großteil der Apps verzichten und überwiegend auf Apps aus dem F-Droid Store zurückgreifen.
- System: Es sind jedoch nicht die Apps alleine, die eure Daten größtenteils ungeniert abfragen und übermitteln. Auch euer System bzw. unterschiedliche Dienste auf dem System erfassen ständig Daten und übermitteln diese an den (Smartphone-)Hersteller – allen voran Google selbst. Auf handelsüblichen Android-Smartphones sind bspw. die Google-Play-Dienste bereits vorinstalliert, die im Hintergrund eine Vielzahl von Informationen erfassen und an Google übermitteln. Dieser ausgehende »Schnüffelverkehr« lässt sich ebenfalls über eine Android-Firewall reglementieren und eindämmen. Doch auch hier gilt: Der Verzicht auf das »Original-System« bzw. Stock-ROM ist langfristig die klügere Variante, um die Datenhoheit über sein Smartphone zu behalten. Insbesondere aber auch deshalb, weil die offiziellen Stock-ROMs oftmals nur kurz mit Sicherheitsupdates versorgt werden. Eben aus diesen Gründen haben wir bereits LineageOS installiert.
Es gibt also gute Gründe für den Einsatz einer Firewall auf einem Android-System. Natürlich kann man sich trefflich darüber streiten, ob all diese Verbindungen per se »schädlich« sind oder zum Ziel haben, unsere Daten zu »verraten« – ein mulmiges Gefühl ist jedenfalls immer da. 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.
2.2 Installation
Als Installationsmedium nutzen wir direkt das APK-File von AFWall+, das über F-Droid angeboten wird. Das hat einen einfachen Grund: Im späteren Verlauf der Artikelserie werden wir F-Droid in Betrieb nehmen und können darüber anschließend nahtlos Updates für AFWall+ einspielen:
- Download: Bezieht zunächst die neueste Version von AFWall+ von der F-Droid -Seite. Klickt unten bei »Packages« auf
Download APK(Version 3.1.0) und sichert die Datei zunächst auf eurem Rechner. - PGP-Signatur: Optional könnt ihr die PGP-Signatur der heruntergeladenen APK-Datei prüfen und so sicherstellen, dass die Datei nicht beschädigt oder verändert wurde. Dazu müsst ihr zunächst den öffentlichen F-Droid-Signing-Key importieren:
gpg --keyserver pgp.mit.edu --recv-keys 0x41e7044e1dba2e89
Anschließend kann der Fingerabdruck geprüft werden:
gpg --verify dev.ukanth.ufirewall_17111.apk.asc dev.ukanth.ufirewall_17111.apk
Ist der Haupt- und Unter-Fingerabdruck identisch mit jenen auf der Webseite von F-Droid?
Haupt-Fingerabdruck = 37D2 C987 89D8 3119 4839 4E3E 41E7 044E 1DBA 2E89 Unter-Fingerabdruck = 802A 9799 0161 1234 6E1F EFF4 7A02 9E54 DD5D CE7A
- Installation: Sofern die PGP-Signatur übereinstimmt, könnt ihr die APK-Datei via USB-Kabel auf das Gerät kopieren. Auf eurem Gerät könnt ihr die Datei anschließend antippen und die Installation starten. Vor der Installation von AFWall+ wird in Android eine Warnung erscheinen. Dieser Mechanismus soll davor schützen, dass man versehentlich Apps aus »unbekannten Quellen« (fernab des Google Play Stores) installiert und sich darüber Schadsoftware einfängt. Der Hinweis wird mit einem Fingertipp auf
Weiterbestätigt und die Installation abgeschlossen. - Initialer Start: Beim Start von AFWall+ wird die App prüfen, ob sie für bestimmte Operationen Root-Rechte erlangen kann. Magisk wird diese Abfrage abfangen und euch die Wahl überlassen, ob sich die App Root-Rechte verschaffen darf. In unserem Fall ist dies natürlich gewünscht – daher bestätigen wir die Abfrage mit einem Tipp auf
Gewähren:
3. AFWall+ in der Praxis
AFWall+ vollständig zu überblicken und alle Funktionen (bspw. CustomScripts) zu beherrschen, stellt zunächst eine nicht zu unterschätzende Herausforderung dar. Vermutlich werde ich es in meiner 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 meiner Ausführung werde ich 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, kann ich es euch nicht abnehmen, eigene Erfahrungen mit der AFWall+ zu sammeln. Diese könnt ihr sehr gerne auch über die Kommentar-Funktion des Blogs oder im Forum mit anderen Lesern teilen und diskutieren.
Hinweis
Erfahrungsgemäß treten bei der Einführung von neuen Android-Versionen immer mal wieder Probleme mit AFWall+ auf. Die nachfolgende Anleitung bezieht sich daher auf Android Pie – also Android 9.3.1 Das User-Interface
Unmittelbar nach dem Start werden alle installierten Apps eingelesen und untereinander aufgelistet. Systemkomponenten bzw. vorinstallierte Apps lassen sich relativ einfach anhand der grünen (oder auch mal gelben) Schriftfarbe identifizieren. In der Spalte über den Apps sind die verschiedenen Netzwerk-Interfaces erkennbar, die es euch ermöglichen, Apps entsprechend der Verbindungsart (WLAN, mobile Datenverbindung über 2G/3G/LTE/5G, VPN, LAN oder Roaming) zu reglementieren.
Die AFWall+ bietet hierfür zwei unterschiedliche Betriebsmodi an. Als Nutzer könnt ihr 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 ein anderes Interface zur Kommunikation 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 ich auch genauso beibehalte und jedem empfehlen kann. 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.
3.2 Basiskonfiguration
Über die drei Pünktchen im oberen rechten Rand der AFWall+ gelangt ihr in ein weiteres Optionsmenü, worüber ihr die »Einstellungen« erreicht. Meine vorgeschlagenen Einstellungen sind wie folgt:
- Sprache umstellen: Wenn die AFWall+ noch in englischer Sprache läuft, könnt ihr die Sprache unter dem Punkt »Languages/Plugins« in
Germanändern. - APP-UID: Bei Android wird jeder App eine eindeutige ID (UID) vom System zugewiesen, anhand derer ihr das »Verhalten« einer App nachvollziehen könnt. Damit eine Zuordnung über das Firewall-Log später einfacher gelingt, solltet ihr ein Häkchen unter »Benutzeroberfläche« ->
APP-UID-Anzeigesetzen. - Interfaces | IPv6: Unter dem Eintrag »Regel/Verbindung« solltet ihr prüfen, ob das Häcken bei
Aktive Regelngesetzt ist. Wenn ja, wird bei jeder Änderung des Netzwerkzustands (bspw. WLAN An / Aus) die in AFWall+ definierten Regeln erneut geladen. Weiterhin könnt ihr Netzwerk-Interfaces aktivieren bzw. deaktivieren, über die später die Apps kommunizieren sollen. Ich setze bspw. ein Häkchen beiVPN-Steuerung, weil ich oftmals eine VPN-Verbindung aufbaue und gewisse Apps darüber dann auch mit der Außenwelt kommunizieren dürfen. Ob ihr die Unterstützung für IPv6 aktiv lasst, müsst ihr individuell für euch entscheiden – persönlich deaktiviere ich den IPv6-Support. - Datenlecks beim Systemstart verhindern: Die durchaus sinnvolle Funktion soll verhindern, dass Apps während des Boot-Vorgangs Verbindungen nach »außen« aufbauen. Ein AFWall+-Skript klinkt sich deshalb in einer frühen Boot-Phase als systemd-Skript in das System ein und kann das Datenleck unterbinden. Für die Aktivierung setzt ihr unter »Experimentell« das Startverzeichnis für das Skript auf
/data/adb/service.d/. Anschließend dürft ihr das Häkchen beiStart-Datenleck behebennicht vergessen.
3.3 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. Generell gilt: Ihr solltet nur jenen Apps Internet-Zugriff gestatten, bei denen dies auch wirklich notwendig ist.
Ausgehend von einer »frischen« LineageOS-Installation schlage ich folgende Whitelist-Regeln für eure AFWall+ vor:
- (Root) – Apps mit Root-Rechten: Ein Häkchen bei dieser Systemregel ist Pflicht. Sie wird unter anderem für die DNS-Namensauflösung benötigt.
- (NTP) – Internet-Zeitserver: Ermöglicht die Zeitsynchronisation, falls ihr die Funktion »Autom. Datum/Uhrzeit« aktiviert habt.
- Updater: Für LineageOS erscheinen in der Regel kontinuierlich Updates. Das Whitelisting der App »Updater« soll uns auf neue Updates hinweisen, die wir bei Bedarf dann einspielen.
- Medienspeicher, Download-Manager […]: Auch bei dieser Regel solltet ihr ein Häkchen setzen. Ansonsten könnt ihr via Browser bspw. keine Dateien herunterladen. Bei dieser Freigabe handelt es sich um eine »Helper-App«. Einige eurer Apps werden nur dann korrekt funktionieren, wenn ihr solche Helper-Apps identifiziert und entsprechend freischaltet.
Anschließend könnt ihr die Firewall zum ersten Mal aktivieren. Tippt dazu auf die drei Pünktchen und wählt anschließend Firewall aktivieren. Nach der initialen Konfiguration (ohne zusätzliches Häkchen bei VPN-Interface) ergibt sich folgendes Bild:
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 einmal ausreichen. Erfahrungsgemäß werdet ihr aber besonders bei Apps mit Video- oder Audioinhalten auf erste Schwierigkeiten stoßen, da viele Android-Apps hierfür die Systemkomponente »(Medien) – Medienserver« benötigen. Erst nachdem dieser App ebenfalls der Internetzugriff erlaubt ist, kann die Darstellung bzw. Wiedergabe von Video- und Audioinhalten bei einigen Apps gelingen.
3.4 Logging-Funktion
Um entsprechende Abhängigkeiten von Apps zu ihren Helper-Apps 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 Hilfsmittel dar. Standardmäßig ist in der AFWall+ diese Protokollierung nicht aktiv. Deshalb müsst ihr diese über »Einstellungen -> Protokoll« zunächst einmal aktivieren. Hierfür setzt ihr einfach ein Häkchen bei Protokolldienst einschalten. Wenn ihr zusätzlich ein Hinweisfenster eingeblendet haben wollt, mit dem euch in Echtzeit angezeigt wird, was die Firewall alles blockt, könnt ihr ebenfalls ein Häkchen bei Meldungen einblenden setzen.
Anschließend könnt ihr das Protokoll über »Einstellungen -> Protokoll anzeigen« einsehen. Über das Menü habe ich Zur alten Ansicht wechseln ausgewählt, um die IP-Adressen einzusehen:
Wie wir dem Bild entnehmen können, versucht das neu installierte LineageOS über die UKW-Radio-App und den Chrome-Browser Verbindungen zu Google-Adressen aufzunehmen. Das ist insofern fraglich, weil die Apps nicht einmal gestartet wurden. Daher nochmal zur Erinnerung: Allein der Wechsel zu einem alternativen Betriebssystem wie LineageOS schützt uns nicht zwangsläufig vor dem ungewollten Abfluss von Informationen bzw. dem Kontakt mit Datensammlern wie Google.
Keine Sorge, in einem weiteren Teil der Artikelserie werden wir diese Datenschleudern identifizieren und deaktivieren. Mit der AFWall+ habt ihr nun eine erste »Grundimmunisierung« vor solch unliebsamen Verbindungen.
Hinweis
Ein weiteres Hilfsmittel zur Identifikation von Netzwerkverbindungen ist die App PCAPdroid.3.5 Captive Portal Check deaktivieren
Ihr werdet es sicherlich bemerkt haben, beim WLAN-Symbol in der Android-Menüleiste wird ein kleines Kreuz angezeigt. Jedes Mal wenn sich euer Android-Gerät mit einem WLAN verbindet, führt das System einen Captive Portal Check durch. Android will damit sicherstellen, dass sich euer Gerät nicht nur mit einem WLAN Access Point verbunden hat, sondern tatsächlich auch Ziele im Internet erreichen kann. Üblicherweise ist der Captive Portal Check immer dann sinnvoll, wenn ihr euch in einem Hotel befindet und der Zugang zum Internet zunächst über einen Coupon oder Ähnliches freigeschaltet werden muss. Dass der Check fehlgeschlagen ist, könnt ihr nun an einem kleinen Ausrufezeichen oder »X« direkt am unteren Rand des WLAN-Symbols erkennen – AFWall+ blockt die entsprechenden Pakete einfach.
Android sendet zur Prüfung eine Anfrage an die Adresse »connectivitycheck.gstatic.com«. Ist die Anfrage erfolgreich bzw. wird mit dem HTTP Response-Code 204 beantwortet, besteht Zugang zum Internet. Mit dieser Anfrage übermittelt das System Informationen zur IP-Adresse des Anschlusses, dem Zeitpunkt des Internet-Zugangs und welcher Browser aktuell verwendet wird an Google.
Ihr habt nun zwei Möglichkeiten, um der Übermittlung an Google aus dem Weg zu gehen:
- Ihr nutzt meinen Connectivity-Check bzw. eine gleichwertige Alternative
- oder deaktiviert den Connectivity-Check vollständig
Um den Connectivity-Check unter Android Pie zu deaktivieren, benötigt ihr Root-Rechte für die ADB. Öffnet daher zunächst Magisk navigiert zu den Einstellungen und wählt bei Superuser-Zugriff Apps und ADB. Anschließend öffnet ihr die Systemeinstellungen von Android und navigiert zu System -> Entwickleroptionen. Setzt dann ein Häkchen bei Lokales Terminal. Anschließend öffnet ihr die Terminal-App, autorisiert den Root-Zugriff (bei Anfrage) und gebt folgende Befehle ein:
su su pm disable com.android.captiveportallogin settings put global captive_portal_detection_enabled 0 settings put global captive_portal_server localhost settings put global captive_portal_mode 0 reboot
Den Befehl »su« (substitute user identity – Wechsel zum Benutzer root) müsst ihr vermutlich aufgrund von SELinux zweimal eingeben. Erst dann werden die Befehle angenommen bzw. ausgeführt. Nach einem Neustart wird der Captive Portal Check deaktiviert sein und das kleine Kreuz am WLAN-Symbol verschwinden.
Hinweis
Die Deaktivierung des Captive Portal Checks kann dazu führen, dass ihr in Hotels die Login-Seite zum WiFi nicht mehr angezeigt bekommt. Bisher ist mir dieses Problem allerdings noch nicht untergekommen – eventuell hat jemand einen Lösungsvorschlag, wie man sich dennoch einloggen kann.4. CustomScripts: Nur für Nerds!
Erfahrene Anwender können über CustomScripts 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 CustomScripts im AFWall+-Wiki.
Hinweis
Ein falscher Umgang mit iptables bzw. CustomScripts 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 CustomScripts wirkungsvoll einsetzen könnt.4.1 Startup- und Shutdown-Skript
Das Skript »iptables.sh« wird immer ausgeführt, wenn die Firewall gestartet wird bzw. die Regelsätze neu geladen werden. Alle Befehle sind kommentiert – ihr solltet das Regelwerk bitte keinesfalls einfach kopieren und bei euch einsetzen, sondern euch zuvor eingehend mit iptables befassen und an eure Bedürfnisse anpassen:
## iptables.sh ## AFWall+ CustomScript & some tweaks ## Mike Kuketz ## www.kuketz-blog.de ## Changes: 25.09.2018 ## ## iptables -L ## iptables -S ## iptables -L -t nat #################### # Tweaks # #################### ## Kernel # Disable IPv6 echo 0 > /proc/sys/net/ipv6/conf/wlan0/accept_ra echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6 echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6 # Privacy IPv6 Address echo 2 > /proc/sys/net/ipv6/conf/all/use_tempaddr echo 2 > /proc/sys/net/ipv6/conf/default/use_tempaddr ## System # Disable Captive Portal - Android Pie 9 pm disable com.android.captiveportallogin settings put global captive_portal_detection_enabled 0 settings put global captive_portal_server localhost settings put global captive_portal_mode 0 # Disable Global NTP Server settings put global ntp_server 127.0.0.1 #################### # iptables # #################### IPTABLES=/system/bin/iptables IP6TABLES=/system/bin/ip6tables #################### # Defaults # #################### # IPv4 connections $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT DROP # IPv6 connections $IP6TABLES -P INPUT DROP $IP6TABLES -P FORWARD DROP $IP6TABLES -P OUTPUT DROP ##################### # Special Rules # ##################### # Allow loopback interface lo $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A "afwall" -o lo -j ACCEPT # Set a specific DNS-Server (dismail.de AdBlocking DNS-Server) for all networks except home WiFi (192.168.150.0/24) $IPTABLES -t nat -I OUTPUT ! -s 192.168.150.0/24 -p tcp --dport 53 -j DNAT --to-destination 116.203.32.217:53 $IPTABLES -t nat -I OUTPUT ! -s 192.168.150.0/24 -p udp --dport 53 -j DNAT --to-destination 116.203.32.217:53 # Force a specific NTP (ntp0.fau.de), Location: University Erlangen-Nuernberg $IPTABLES -t nat -A OUTPUT -p tcp --dport 123 -j DNAT --to-destination 131.188.3.222:123 $IPTABLES -t nat -A OUTPUT -p udp --dport 123 -j DNAT --to-destination 131.188.3.222:123 # Allow captive portal check (captiveportal.kuketz.de) $IPTABLES -A "afwall" -d 46.38.242.112 -p tcp --dport 80 -j ACCEPT $IPTABLES -A "afwall" -d 46.38.242.112 -p tcp --dport 443 -j ACCEPT ##################### # Incoming Traffic # ##################### # Allow all traffic from an established connection $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Alle Pakete ordentlich zurückweisen $IPTABLES -A INPUT -p tcp -j REJECT --reject-with tcp-reset $IPTABLES -A INPUT -j REJECT --reject-with icmp-port-unreachable
Und das Shutdown-Skript, zum Deaktivieren / Herunterfahren der Firewall:
## iptables_off.sh ## AFWall+ shutdown actions ## Mike Kuketz ## www.kuketz-blog.de #################### # iptables # #################### IPTABLES=/system/bin/iptables IP6TABLES=/system/bin/ip6tables #################### # Purge/Flush # #################### # 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 #################### # Defaults # #################### # 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
Hinweis
Als Speicherort für eure CustomScripts eignet sich der Pfad »/data/local/«.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.
4.2 Datensammler wirksam blockieren
Über die Option »Skript festlegen« binde ich noch weitere Skripts ein. Unter anderem blockiere ich mit Hilfe des ASN-Skripts alle ausgehenden Verbindungen zu Google und Facebook:
bash asn_ipfire.sh --afwall "Google,Facebook"
Die Skripts werden jeweils als eigene Zeile unter Skripte festlegen eingetragen:
Der Inhalt von block_google.sh:
##################### # Block Google # ##################### /system/bin/iptables -A "afwall" -d 8.8.4.0/24 -j REJECT /system/bin/iptables -A "afwall" -d 8.8.8.0/24 -j REJECT /system/bin/iptables -A "afwall" -d 8.34.208.0/20 -j REJECT /system/bin/iptables -A "afwall" -d 8.35.192.0/20 -j REJECT /system/bin/iptables -A "afwall" -d 23.236.48.0/20 -j REJECT /system/bin/iptables -A "afwall" -d 23.251.128.0/19 -j REJECT /system/bin/iptables -A "afwall" -d 35.184.0.0/12 -j REJECT /system/bin/iptables -A "afwall" -d 35.200.0.0/14 -j REJECT /system/bin/iptables -A "afwall" -d 35.204.0.0/15 -j REJECT /system/bin/iptables -A "afwall" -d 63.88.73.0/24 -j REJECT [...]
Und der Inhalt von block_facebook.sh:
##################### # Block Facebook # ##################### /system/bin/iptables -A "afwall" -d 31.13.24.0/21 -j REJECT /system/bin/iptables -A "afwall" -d 31.13.64.0/18 -j REJECT /system/bin/iptables -A "afwall" -d 45.64.40.0/22 -j REJECT /system/bin/iptables -A "afwall" -d 66.220.144.0/20 -j REJECT /system/bin/iptables -A "afwall" -d 69.63.176.0/20 -j REJECT /system/bin/iptables -A "afwall" -d 69.171.224.0/19 -j REJECT /system/bin/iptables -A "afwall" -d 74.119.76.0/22 -j REJECT /system/bin/iptables -A "afwall" -d 103.4.96.0/22 -j REJECT /system/bin/iptables -A "afwall" -d 157.240.0.0/17 -j REJECT /system/bin/iptables -A "afwall" -d 173.252.64.0/18 -j REJECT /system/bin/iptables -A "afwall" -d 179.60.192.0/22 -j REJECT /system/bin/iptables -A "afwall" -d 185.60.216.0/22 -j REJECT /system/bin/iptables -A "afwall" -d 204.15.20.0/22 -j REJECT
Sobald die neuen Regelsätze geladen sind, passiert Folgendes: Wann immer euer Browser oder eine andere (System-)App dazu angewiesen wird, von den externen IP-Adressen (Google, Facebook) 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 weiß damit, dass keine Verbindung mehr aufgebaut werden kann. Externe Inhalte auf Webseiten oder Apps, die von Google oder Facebook stammen bzw. dort gehostet werden, fallen den CustomScripts damit zum »Opfer«. Als positiver Nebeneffekt werden Webseiten etwas schneller geladen und das Datenvolumen entlastet.
Hinweis
Sobald ihr alle IP-Adressen von Google blockiert, könnt ihr selbstverständlich auch keinen Google-Dienst mehr nutzen bzw. es werden euch auch keine Captchas mehr auf Webseiten eingeblendet – das kann unter Umständen dazu führen, dass ihr die Google-Captchas nicht mehr lösen könnt. Solltet ihr also alle Google-IP-Adressen blockieren, dann solltet ihr gerade bei Registrierungsprozessen für Webseiten damit rechnen, dass dies via mobilen Browser nicht funktioniert. Als Alternative könnt ihr in solchen Fällen auf den Tor Browser am Desktop ausweichen bzw. Tor Browser für Android benutzen.5. Fazit
Wie heißt es so schön:
Vertrauen ist gut – Kontrolle ist besser.
Für die Artikelserie »Take back control!« stellt AFWall+ ein unverzichtbares Werkzeug dar. Mir war es deshalb ein besonderes Anliegen, das iptables-Firewall-Interface ausführlich vorzustellen. Es sollte nämlich durch die vorstehenden Ausführungen deutlich werden, dass selbst ein alternatives bzw. »freies« System wie LineageOS uns per se nicht vor dem Aufbau von Datenverbindungen nach »außen« bzw. zu Google und Co. schützt.
Bereits in der Standardkonfiguration leistet AFWall+ wertvolle Dienste. Aber erst die CustomScripts und die zusätzlichen kleinen Tweaks, wie zum Beispiel das Umleiten aller (mobilen) DNS-Anfragen an den Anbieter meines Vertrauens oder das Blockieren der IP-Adressräume bekannter Datensammler, sind das Tüpfelchen auf dem i.
Im nachfolgenden Beitrag der Artikelserie werden wir den alternativen App-Store F-Droid in Betrieb nehmen. Ein Mekka für kritische Anwender, die Wert auf freie und quelloffene Anwendungen bzw. FOSS-Apps legen.
Ü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
F-Droid und AFWall+ – Android ohne Google?! Teil4
ASN-Skript: Datensammler haben ausgeschnüffelt – IPFire Teil3
Magisk: Bei der Macht von Root – Take back control! Teil3
F-Droid: Freie und quelloffene Apps – Take back control! Teil5
60 Ergänzungen zu “AFWall+: Digitaler Türvorsteher – Take back control! 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.
Für fortgeschrittene Nutzer, die mit Custom Scripts arbeiten bietet sich ein Blick in das Wiki von maloe auf notabug.org an:
https://notabug.org/maloe/ASN_IPFire_Script/wiki#3-asn-ipfire-script-and-android
Es ist nicht mehr notwendig die Skripte zu teilen. Zudem werden die Regeln sauber verarbeitet, ohne dass sich AFWall an zu vielen Regeln verschluckt.
Interessant. Hatte ich bisher nicht auf dem Schirm oder maloe hat vergessen es mir mitzuteilen. ;-)
Für faule Nutzer gibt es noch diese Seite:
https://notabug.org/angrytux/afwall_easy
Hatte aber gedacht, dass Mike absichtlich auf so etwas nicht verweisen möchte, damit man sich auch mit dem Inhalt der Skripte, also den ipchaines auseinandersetzt und nicht einfach alles blind übernimmt…
Vorteilhaft ist natürlich, dass die Datensammler-Listen automatisch nach je 100 Zeilen in einzelne Dateien zerlegt werden. Das hatte ich anfangs nicht beachtet und bin fast daran verzweifelt.
@Mike: Vielleicht sollte man das im Beitrag erwähnen?
Darf ich nach der erfolgreichen Installation von AFWall+ eigentlich mit dem Smartphone in das WLAN gehen bzw. die SIM Card einbauen oder sind wir erst in einem späteren Teil der Serie soweit?
Du darfst die SIM-Karte nun einlegen.
Ich möchte die Artikelserie umsetzen, ich habe aber auf diesen Artikel gewartet, da ich es richtig machen möchte. Nun geht die Serie ja noch weiter mit f-droid, ich habe in vorbereitung darauf in Zukunft LineageOS zu benutzen mich schon mal daran gewöhnt keine Play Store Apps zu benutzen. Daher meine frage: Kommen im nächsten Artikel noch große Sicherheitsrisiken oder kann ich die Artikelreihe nun schon ruhigen gewissens umsetzen?
Die Artikelserie wird noch mindestens 3 Teile haben – eventuell auch mehr.
Wenn du darauf nicht warten möchtest, dann kannst du dir natürlich schon F-Droid installieren.
Geplant ist bisher noch:
– F-Droid
– AdAway
– Einstellungen vom System
– eventuell microG
– eventuell noch etwas anderes
Und falls Du mit F-Droid nicht auf Mike’s nächsten Artikel warten (oder Dich bereits im Vorfeld informieren) möchtest, kannst Du schon einen Blick in meine Artikel-Serie zu F-Droid werfen – die mit der Vorstellung von F-Droid beginnt (weitere Teile sind von dort verlinkt).
Wer’s schon an anderer Stelle gelesen hat: Ja, das ist die Serie, die in leicht veränderter Form auch schon in der c’t zu finden war. Und ein vierter Teil ist schon unterwegs.
Aber natürlich bin ich auf Mike’s Artikel zu F-Droid schon furchtbar gespannt. Bis dahin werde ich mich jetzt auch endlich mal mit AFWall+ beschäftigen: LOS15 (mit Oreo) ist seit kurzem für eines meiner Geräte verfügbar, welches ich daher ohnehin neu aufsetzen muss…
Fantastisch! Perfekt fürs Osterwochenende ;) Danke!
Im Start-up-Skript für Android 8 werden die Regeln und Ketten nun nicht mehr gelöscht. Macht es daher Sinn, bei einer Änderung in Afwall+, die Firewall vor dem „Anwenden“ der neuen Regeln zu deaktivieren, damit mit dem Shutdown-Skript die alten Regeln und Ketten gelöscht werden?
Super Artikel!!
Was hat es denn für einen Sinn den Ausgang zunächst mit „IPTABLES -P OUTPUT DROP“ zu blockieren und ihn später wieder mit dem Setzen des DNS-Servers zu öffnen?
Erreicht man dadurch mehr Sicherheit?
Ich habe z.B INPUT und FORWARD blockiert aber nicht OUTPUT. Macht das einen großen Unterschied zu deiner Methode? Ist das die unsichere Variante?
-P Setzt die Default-Policy auf der Chain „d.h. was passiert wenn es in der Chain keine explizite Rule für ein Paket gibt“. Vorsicht: Das -P ist im Script zwar oben dran… hat aber nix mit der Reihenfolge zu tun.
IPTABLES -P OUTPUT DROP => In der „OUTPUT“ wird per Default gedroppt. Wenn man was zulassen will, geschieht das via Weitergabe ans Target „ACCEPT“. (-j ACCEPT)
Sog. Whitelisting.
Generell: Vorsicht mit so Rules. Wenn einem die Funktionalität der Chains/IPTables/Policies nix sagt… Finger weg von Custom Rules. Ihr schiesst euch so ins Bein ;)
hth
Das ist mir eigentlich klar. Wahrscheinlich habe ich mich schlecht ausgedrückt.
Was ich wissen möchte, was versucht man mit OUTPUT Drop zu erreichen?
Und wenn man lediglich Port 53 freigibt, wie sieht es aus mit Port 443 und 80 (und falls ein Email-Client benutzt wird, müsste da nicht auch Port 993 bzw. 995 freigegeben werden?)??
Du brauchst die imap/pop3/smtp ports zB nicht freigeben, da eine Freigabe des Email clients dieser UID Cerbindungen auf allen Ports gestattet
Die Output drop policy führ dazu, dass ausgehende pakete auf die keine Regel zutrifft blockiert werden.
Danke für die Info!
Aber irgendwie will Afwall nicht die Policy für den OUTPUT auf Drop stellen. Nach ausführen der Skripts bleibt der Regler für den Ausgang aktiv und auf ‚Regeln anzeigen‘ steht weiterhin „Chain OUTPUT ACCEPT“.
Wo liegt der Haken? Kennt jemand dieses Verhalten? Vielleicht könnte mir auch mal der Autor helfen! :-(
Hallo,
zu 3.5 Captive Portal Check deaktivieren
Gibt es auch einen entsprechenden Befehl für das WLAN x Problem für Android 9 so wie oben für Oreo aufgeführt? dieser geht unter 9 / Lineage 16.0 leider nicht :(
Bisher habe ich kein Gerät mit Android 9. Wird sich aber demnächst ändern – dann schaue ich mal.
Aktuell ist mir keine Lösung bekannt.
Hallo Peter,
Folgendes scheint zu funktionieren:
1) Erst SELinux auf Permissive stellen
su
setenforce 0
2) Dann den Portal Check deaktivieren
settings put global captive_portal_mode 0
3) Danach SELinux wieder auf Enforcing schalten.
setenforce 1
Ob dieses Vorgehen optimal oder empfehlenswert ist, kann ich nicht sagen.
Es löst jedenfalls die bekannten Probleme mit dem Wifi-X und Apps, die nicht funktionieren (u.a. Signal). In der AFWall kann CaptivePortalLogin (UID 10051) dabei weiter geblockt bleiben.
Schönen Gruß!
Vielen Dank für die aktuellen Anleitungen !
2 Fragen habe ich zum Teil über AFWall+:
a) gpg mag nicht mit pgp.mit.edu kommunizieren
gpg –keyserver pgp.mit.edu –recv-keys 0x41e7044e1dba2e89
gpg: Empfangen vom Schlüsselserver fehlgeschlagen: Keine Daten
Woran kann es liegen ? Ich führe es als normaler Nutzer aus.
b) iptables_on.sh
enhält einen Abschnitt
# Disable Captive Portal – Android Oreo 8
Die Anleitung unter „3.5 Captive Portal Check deaktivieren“ hatte ich so verstanden, dass die Änderung dauerhaft ist.
Nach meinem Verständnis ist die AppId 1000 nicht zwangsläufig das Radio sondern ein Zusammenschluss von vielen Diensten.
Kleiner Hinweis: Im Bash-Befehl fehlt zwischen Google und Facebook ein Komma (bash asn_ipfire.sh –afwall „Google,Facebook“) oder man führt es getrennt für Google und Facebook aus
Korrekt. War noch die alte Schreibweise des Skripts. Danke!
Falls jemand, wie ich zu später Stunde Dinge überliest, und Probleme beim Einbinden der CustomScipts hat.
https://github.com/ukanth/afwall/wiki/CustomScripts#loading-scripts-from-files
Zwingend erforderlich ist:
– Root -> Apps und ADB
– Dateiformat -> ASCII (! WinEditor erzeugt nur ANSI oder UTF8)
ggf. per adb: echo … die Dateien anlegen
– Berechtigungen -> 755 (Group/User 0)
Dann gehts auch :)
Danke für den Artikel Mike.
Bis ausser Punkt 4. & 4.1 ( bin atm ein NON Nerd ) alle anderen Schritte erfolgreich auf meinem BQ Aquaris X umgesetzt bekommen.
Teil 5 darf kommen ….
Ich nutze aktuell NetGuard, um meinen Internetverkehr zu kontrollieren.
Wenn ich das richtig sehe, werden mit AfWall+ in der obigen Konfiguration keine Verbindungen zu CDNs, Akamai, o. Ä. (Außer eben von Google und FB) blockiert. Lasst ihr solche Verbindungen grundsätzlich zu? Gibt es ggf. noch einen Artikel zu diesem Thema?
Das ist eine Beispielkonfiguration. Jeder sollte selbst entscheiden, was er noch blockieren möchte.
Das es sich hierbei um eine Beispielkonfiguration handelt und diese den individuellen Bedürfnissen angepasst werden kann/sollte, ist mir bewusst.
Ich frage mich trotzdem, ob du / andere Leser solche Verbindungen (CDN / Akamai / etc.) immer zulässt /zulassen. Wenn nein, wie wird das blockiert? Mit dem ASN-Skript und Custom-Scripts? NetGuard? Ich habe hier auf dem Blog oder im Forum mal gelesen, dass NetGuard in Verbindung mit AFWall+ nicht notwendig sei. Wenn ich mir aber ansehe, was beim Surfen über NetGuard alles geblockt wird, weiß ich nicht, wie ich diese Verbindungen ohne NetGuard bzw. mit AFWall+ blocken sollte.
Du kannst dir die IPs anderer Datensammler über ASNs fetchen (zB afwall easy, oda dass ipfire asn script wenn du dir nicht selbst was schreiben willst) und diese zusätzlich per custom Script blockieren.
Ich verwende zusätzlich noch AdAway und uBlock Origin am Smartphone -> also bei mir AFwall (inkl custom scripts + Adaway + uBlock Origin)
Habe nach dem Aufsetzen der AFWall+ zunächst keine Verbindung bekommen. Erst nachdem ich:
Einstellungen -> Experimentell -> Interne Verbindungen erlauben
aktiviert hatte, funktionierte es (LOS 15.1, 16.0 und AFWall+ v3.1.0). Warum funktioniert es laut Mikes Beitrag ohne diese Funktion?
Danke, Mike, für die neue Artikelserie!
Bei mir hat alles erst nach einem Reboot funktioniert.
Yeap, nach einem Reboot klappte es auch bei mir ohne diese Zusatzeinstellung – Danke! Trotzdem würde mich interessieren, warum es bei mir auch ohne Reboot und mit ‚Interne Verbindungen erlauben‘ funktioniert hat.
Ich kann bei meinem aquaris pro mit lineage 15.1 in AfWall+ unter experimentel nicht das Startverzeichnis für das Skript auf /data/adb/service.d/ einstellen. Es gibt nur /system/etc/init.d/ und /etc/init.d/ zur Auswahl. Was mache ich falsch?
Du hast kein Magisk installiert.
Wenn du mit LineageOS-Su gerootet hast, kann ich dir nicht sagen, ob es funktioniert. Ich vermute mal, da fehlen die Schreibrechte auf die angebotenen Pfade.
Unter LOS 16 (official) mit su-addon gibt es den Pfad /data/adb/service.d/ neben den anderen beiden genannten auch zur Auswahl. Sollte also (zumindest bei LOS 16) nicht von Magisk abhängen.
Das skript ist erfolgreich unter /system/etc/init.d/ abgelegt worden. Das Telefon ist jedoch kurz drauf eingefroren. Nach einem Neustart ist das skript aber noch da wo es sein soll und friert auch nicht mehr ein.
Ist das richtig? Ich hab die noch nie gewhitelisted und keinerlei Probleme bzgl. DNS gehabt.
(Android 7.1.2 – LineageOS 14.1)
Ich möchte mich ebenfalls docmop anschließen – auch ich habe hier noch nie einen Haken gesetzt. Meinem Verständnis nach betrifft das nur die Apps, die eben Root-Rechte haben oder potentiell bekommen können. Beispielsweise wäre das bei mir (wenn ich in „Magisk“ unter „Superuser“ nachsehe): AdAway, AFWall+, Link2SD, Official TWRP App und Titanium Backup.
Zugang zum Internet gebe ich nur AdAway (sonst gehen die Updates für die Hosts-Datei nicht) und der „Official TWRP App“ (auch wegen den Updates)
Auch AFWall+ selbst gestattet sich bei mir sozusagen selbst keinen Internetzugriff (kein Haken gesetzt, weder bei WLAN noch Mobilfunk) und funktioniert einwandfrei.
Interessant kann auch sein, in AFWall+ mehrere „Profile“ anzulegen (unter ‚Einstellungen‘->’Profile‘). So kann man bspw. auch ein zweites Profil haben, bei dem nur ein einziger Haken bei dem bevorzugten Brower gesetzt ist. Falls man was downloaden will, muss man halt noch den Haken beim Downloadmanager setzen.
Ich möchte mich dieser Frage gerne anschliessen.
Auf LineageOS 16 (oneplus3) habe ich weder bei AFWall+ noch bei NetGuard root erlaubt und es funktionierte trotzdem.
(Zugegeben, ich hatte mit AFWall+ anderweitig so große Probleme dass ich zunächst auf NetGuard umgestiegen bin.)
Das ist korrekt, wenn ihr der Empfehlung im Artikel folgt und den netd deaktiviert. Tut ihr das nicht, dann ist die Freigabe nicht zwingend erforderlich.
Vielen Dank, Mike für den weiteren Teil der Anleitung!
Ich habe leider gleich zu Beginn ein Problem ähnlich wohl zu dem oben von Anonymous:
Mit dem Befehl – ohne oder mit sudo davor –
„gpg –keyserver pgp.mit.edu –recv-keys 0x41e7044e1dba2e89“
erhalte ich die Erromeldung:
„gpg: keyserver receive failed: Kein Schlüsselserver verfügbar“.
Ist sowohl in MXLinux also auch OS X so.
Woran kann das liegen?
Mein kleines Problem mit AfWall+
Ich habe ein älteres Phone und aufgrund des geringen Arbeitsspeichers passiert es ab und an, daß der LowMemoryKiller mir die AfWall+ abschießt.
Der (sehr gute) LOS-Betreuer der Official-Build meines Phones hat netter weise ein Low-RAM Property Patcher, welches er aus Android Go übertragen hat, zur verfügung gestellt, was auch zu einer Besserung geführt hat. Besserung, aber trozdem keine zufriedenstellende Lösung.
Es gibt anscheinend die Möglichkeit, Apps im Speicher vor LowMemoryKiller zu schützen, bzw ihre Priorität zu erhöhen, sodaß sie erst „später“ vom LMR gekillt werden (minfree). Kennt jemand dafür eine Lösung?
Unter android.stackexchange gibt es die Möglichkeit via xposed, was ich aber nicht verwenden möchte…
Zum CaptivePortal:
Es gibt anscheinend die Möglichkeit, einen eigenen CaptivePortal-Server zu betreiben hier
Wäre vielleicht eine Herausforderung, soetwas via Termux auf 127.0.0.1 oder generell irgendwo anders aufzusetzen…
Ich hänge bei Punkt 2.2. Initialer Start. „Initialer Start: Beim Start von AFWall+ wird die App prüfen, ob sie für bestimmte Operationen Root-Rechte erlangen kann. Magisk wird diese Abfrage abfangen und euch die Wahl überlassen, „.
Diese Frage kam bei mir nicht oder ich habe es verpaßt. Jedenfall meldet AFWall+ , er habe keine „Superuser (Root) Rechte“.
Kann Magisk die SU Rechte nachträglich an AFWall+ erteilen? Ich finde nichts dazu…
So geht es nun auch bei mir:
Magisk App
– Einstellungen
— Superuser-Zugriff
=> Nur ADB
Im Dialog wurde aber angezeigt:
=> Apps und ADB
Lösung:
Ich habe im Dialog einmal hin- und her geändert und anschließend die AFWall+ App neu installiert, dann kam nun auch die Frage zu den Rootrechten, wie in 2.2 Initialer Start beschrieben.
Resumee:
Für mich ein kleiner, aber verwirrender, Bug in der Anzeige von Magisk.
In der Magisk-app unter Einstellungen-Su kann man die Berechtigungen konfigurieren.
Für die mit Pie (Captive Portal deaktivieren) installiert euch von F-Droid eine Terminal Emu.
Ja, wenn die App schon mal von Magisk registriert war stimmt das.
Was ich suchte, was eine Möglichkeit in Magisk eine App komplett manuell die SU Rechte zu geben. Ok, ist inzwischen gelöst. Ich habe die AFWall+ App neu installiert und die Rechte wie korrigiert. Siehe oben.
Hallo und frohe Ostern,
ich habe mir ein OnePlus One und nach Mike´s Anleitung, LineageOS (16.0), Magisk (18.1) sowie MagiskManager (7.0) und AFWall+ in der aktuellen Version installiert.
Nun hat alles bis zur Aktivierung AFWall+ alles funktioniert – sprich ohne Fehlermeldungen. Bei der Aktivierung von AFWall+ bekomme ich nachstehende Fehlermeldung:
Fehler:
Es ist kein Root-Zugriff möglich. Um AFWall+ nutzen zu können, benötigen Sie ein gerootetes Gerät.
Wenn das Gerät bereits gerootet ist, stellen Sie bitte sicher, dass AFWall+ Superuser-Rechte gewährt werden.
Kontrolle in Magisk, zeigt mir das AFWall+ aber aktiviert und die Superuser-Rechte besitzt.
Das gleiche Problem besteht auch mit „addonsu“ (arm) von LineageOS.
Auch eine neue Installation hat keinen Erfolg gebracht.
Was kann hier die Ursache sein, gibt es einen Lösungsweg?
Stehe beim Punkt 3.5 Captive Portal Check deaktivieren auf dem Schlauch:
Zuerst heißt es, dass AFWall+ den Check blockiert, was ja im White-List-Modus daraus resultiert, dass der […] CaptivPortalLogin ohne Häkchen-Setzen keinen Internet-Zugang bekommt.
Warum sollte man dann aber zusätzlich noch über das Terminal oder über die Custom-Scripts den Check deaktivieren? Ist es nicht egal, ob dieser nur blockiert oder komplett deaktiviert wird? Was erreiche ich durch die zusätzliche Deaktivierung?
Durch die zusätzliche Deaktivierung verschwindet das X am Symbol und Popup-Meldungen, dass das Internet nicht verfügbar sei bzw. keine Konnektivität hergestellt werden kann.
Vielen Dank für die Antwort. Habe die Deaktivierung nicht über das Terminal, sondern nur über die Custom-Scripts vorgenommen. Man kann sich doch für eine Variante entscheiden? Trotzdem erscheint nach Aktivierung des WLANs für ca. eine Sekunde das x am WLAN-Symbol. Habe ich da etwas übersehen?
Noch etwas zum Thema Captive Portal:
Man kann den Server, über den der Zugang zum Internet geprüft wird, via Terminal ändern: settings put global captive_portal_server example.com
Ich habe mir eine kleine App geschrieben (genau 10 Zeilen Quellcode ;) ), die ich auf einem Server betreibe, die eben jenes „generate_204“ macht, wie es auch bei der gstatic-Seite geschieht. Nur eben ohne etwaiges Logging der eigenen Daten. Das funktioniert super und auch in zugangsbeschränkten WLANs (Hotels o.ä.) gab es bei mir keine Probleme. Ich würde die URL ja öffentlich machen, aber es ist nicht mein eigener Server.
Ich verstehe nicht, warum das bei Lineage absolut keine Priorität genießt bzw. wieso es nirgends öffentliche Server gibt, die einem diesen Mini-Service anbieten. So eine App ist in wenigen Minuten geschrieben und aktiviert.
Du kannst doch den Quellcode der App teilen wenn du magst.
Wenn jemand einen eigenen Server hat, kann er deinen Code nutzen und das Setting darauf ändern. Keine Ahnung in welcher (Skript-)Sprache du die APP geschrieben hast, aber vielleicht läuft diese auch auf einem webspace mit php?
Das hatte ich in Python (Django) geschrieben. Wer mag, darf das gern benutzen.
App-Name: generatetwozerofour
urls.py:
from django.conf.urls import patterns from generatetwozerofour.views import generateemptycontent urlpatterns = patterns('',(r'^', generateemptycontent),)views.py:
from django.http import HttpResponse class HttpResponseNoContent(HttpResponse): status_code = 204 def generateemptycontent(request): return HttpResponseNoContent()Viel Erfolg!
Das lässt sich ohne Skript lösen. Ganz einfach mit nginx. Ich habe das testweise mal eingerichtet. Wer folgende URL einträgt, bei dem sollte der Captive Portal Check positiv ausfallen: captiveportal.kuketz.de
Also:
Wer will kann es auch mit php lösen:
Vielen Dank Mike für die super Anleitungen. Ich hatte schon etwas vorgearbeitet, habe aber erst nach deiner Anleitung verstanden, wie ich in AFWall das Datenleck beim Start beheben kann.
Meine Frage an Mike und in die Runde als Nicht-Nerd:
Es dürfte ein längerer Weg sein in den Scripts so drin zu stecken, dass man sie ohne allzu große Problem nutzen kann.
Bisher sehe ich nur eine Lösung außerhalb des heimischen WLANS – dort werkelt Raspi gemäß Mike’s Anleitung – mit Hilfe von Adaway FB, Google und Co. abzufangen – sozusagen im Vorgriff auf den kommenden Artikel von Mike.
Wovor schützt die AFWall den (Noch?)Nicht-Nerd sozusagen im Basisstadium, außer dass eben verschiedenen Programmen der Webzugriff versperrt wird?
Anders gefragt: Geht mehr eben nur mit tieferem Knowhow zu den Scripts oder gibt es für Scriptbeginners/-greenhorns noch eine Zwischenlösung um ein wenig mehr an der Sicherheitsschraube allgemein bzw. speziell in der AFWall zu drehen?
Ich frage das besonders auch deswegen, weil ich leider unter LOS und trotz F-Droid aus verschiedenen Gründen ein paar GAPPS nutzen muss, für es leider in F-Droid kein Äquivalent gibt.
Ich wäre sehr dankbar für weitere Hinweise.
Hier noch ein kleiner Hinweis:
Ich hatte auf meinem alten Gerät LOS mit CardDav und CalDav in Betrieb und nie Probleme mit der Synchronisierung.
Bei meinem neuen Gerät hingegen konnte ich zwar in (der nun neuen App) Davx5 mein Nextcloud-Konto sehen, jedoch wurden weder Kalender noch Kontakte synchronisiert.
Nach der Anleitung zur Deaktivierung des Captive Portal Checks funktioniert alles prima.
Danke für die Anleitung und die generell tolle Arbeit Mike!!! :)
Bis zum Punkt 4 „CustomScripts: Nur für Nerds!“ habe ich für mein Aquaris X Pro alles der Artikelserie nachvollziehen und einrichten können. Als Nicht-Nerd kann ich ab hier aber nicht weiter folgen und habe deshalb das unschöne Gefühl, das eigentliche Ziel der Artikelserie doch nicht erreichen zu können!?
Oder kommt da noch etwas das diese Abriegelung mit einer App o.ä. erfüllt – weil eigentlich hört sich die erforderliche Funktionalität doch so ähnlich an, wie z.B. Addblock arbeitet: Es gibt eine Liste mit Unerwünschtem und wenn ein Punkt daraus zutrifft, wird es blockiert!?
Wie bereits mehrfach in der Artikelserie genannt wird es noch weiter gehen. Unter anderem auch mit dem Tracking- und Werbeblocker AdAway, der die Lücke schließen sollte, die sich bei dir aufgetan hat.
Hallo,
erst einmal danke für diesen tollen Beitrag!
Ich habe mit dem asn_ipfire Skript nun eine Datei für AFWall+ zum Blocken für Facebook erstellt, so wie auch hier beschrieben.
Die Datei habe ich dann unter ./data/local/ abgelegt.
Die Datei hat die erforderlichen Rechte und lässt sich von AFWall+ ohne Fehler einbinden.
Allerdings ist Facebook über den Browser weiterhin erreichbar. Habe testweise Google mit der gleichen Methode blockiert, allerdings sind danach alle Google-Seiten weiterhin erreichbar. Das Blocken klappt also nicht.
Hat jemand eine Idee woran das liegen könnte?
Die iptables_on und iptables_off Scripts sind doch nur optional, oder brauche ich diese auch, damit das Blocken von Facebook über das Script funktionert?
Nach dem ersten LineageOS-Update ware die ganze Artikelserie wieder weg: Magisk, AFWall, systemless Xposed, XprivacyLua, Adaway.
Offenbar muss man Magisk nach jedem Update neu flashen. Es wäre nett, wenn du darauf hinweisen würdest, und noch besser, das wegautomatisieren. Damit der Datenschutz nicht irgendwann der Bequemlichkeit zum Opfer fällt.
Es wäre nett, wenn du darauf hinweisen würdest, und noch besser, das wegautomatisieren. Damit der Datenschutz nicht irgendwann der Bequemlichkeit zum Opfer fällt.
Unfreiwilig ausprobiert mit LineageOS 15.1 auf Xiaomi Redmi Note 4 (Mido).
Hast du ein Update oder Upgrade (bspw. Sprung von 15.1 auf 16.0) gemacht? Bei einem normalen LOS-Update verschwinden die von dir genannten Kompontenen nicht einfach. Da musst du die Ursache woanders suchen.
Und bitte beim Thema bleiben: AFWall+. Ansonsten im Chat oder Forum vorbeischauen.