1. Firewall
Wer sein Android-Smartphone »selbstbestimmt« nutzt bzw. die Datenhoheit behalten möchte, der muss zwingend eine Firewall einsetzen. 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.
Persönlich nutze ich unter Android für die Kontrolle ausgehender Datenverbindungen die Firewall AFWall+. Wer sein Gerät gerootet hat, der wird vermutlich ebenso auf diese Firewall zurückgreifen. In vergangenen Beiträgen bin ich bereits auf die allgemeine Konfiguration der AFWall+ eingegangen. Im vorliegenden Beitrag möchte ich meine persönlichen Einstellungen inklusive meines Custom-Scripts vorstellen – und euch damit sozusagen wieder einen Blick hinter die Kulissen gewähren.
Mit dem Beitrag komme ich nun endlich dem Wunsch vieler Leser nach, die mich per E-Mail oder im Chatraum schon vielfach nach meiner ganz persönlichen Nutzung von AFWall+ gefragt haben.
2. AFWall+: Der Türvorsteher für Android
Bevor ich euch meine Einstellungen, Konfiguration und Custom-Script vorstelle, werde ich kurz ein paar Zeilen zu AFWall+ schreiben – für alle, die die Firewall und deren Einsatzzweck noch nicht kennen.
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/LTE, 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. Denn nicht nur Apps sind äußert »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 besser auf Apps auf 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. Wer technisch versiert ist, der wechselt bspw. auf das Custom-ROM LineageOS – und installiert anschließend keine Google Apps »Wanze« auf seinem System.
Es gibt also gute Gründe für den Einsatz einer Firewall auf einem Android-System. Persönlich setze ich AFWall+ ein, nutze aber weit mehr als die Basis-Funktionalität. Wer sein Android-Gerät hingegen nicht rooten kann oder eine benutzerfreundliche Alternative zu AFWall+ sucht, der sollte einen Blick auf NetGuard werfen – diese Firewall werde ich demnächst in der Artikelserie »Android unter Kontrolle« ausführlich vorstellen.
Hinweis
Wer sich einmal einen Eindruck davon verschaffen möchte, was sich so manche in den Stores angebotene Apps hinter unserem »Rücken« erlauben, der kann gerne mal einen Blick auf meine App-Rezensionen auf mobilsicher.de werfen. Während herkömmliche App-Rezensionen meist Funktionalität oder Nutzen einer App beleuchten, liegt der Fokus bei den von mir veröffentlichten Rezensionen bewusst darauf aufzuzeigen, was sich bei einer App-Nutzung, unsichtbar, im Hintergrund des Smartphones so alles abspielt.3. AFWall+: Mein Setup
Als Custom-ROM nutze ich aktuell LineageOS 14.1 (mit aktuellen Sicherheitsupdates) in Kombination mit dem F-Droid Store. Vom Angebot der in F-Droid verfügbaren FOSS-Apps profitieren insbesondere kritische Anwender, die Wert auf freie und quelloffene Anwendungen legen. Apps aus dem Google Play Store oder aus anderen Quellen nutze ich nicht.
Angesichts dieses Setups drängt sich die Frage auf, ob der ausgehende Datenverkehr durch eine Firewall überhaupt kontrolliert / reglementiert werden muss. Man könnte an dieser Stelle nämlich auch argumentieren, dass sowohl die FOSS-Apps aus F-Droid, als auch LineageOS nicht ungefragt sensible Daten übermitteln. Das wäre allerdings zu kurz gedacht, denn auch wenn diese Annahme stimmt, dann möchte ich nur ungern auf die Custom-Scripts von AFWall+ verzichten, mit der ich weiteren Einfluss auf die Kommunikation meines Geräts nehmen kann.
3.1 Grundkonfiguration
Bevor eines meiner Geräte das erste Mal Verbindung mit der »Außenwelt« aufnimmt, installiere ich AFWall+ (Version 2.9.6.1) und weiche wie folgt von der Standardkonfiguration unter den »Einstellungen« ab:
- Benutzeroberfläche
- APP-UID anzeigen: Check
- Regel/Verbindung
- Aktive Regeln: Check (sollte eigentlich gesetzt sein und ist nur eine Erinnerung für mich)
- VPN-Steuerung: Check
- IPv6 blockieren: Check
- Sprachen/Erweiterungen
- Sprache: German
3.2 Regelwerk
In der Spalte über den Apps sind die verschiedenen Netzwerk-Interfaces erkennbar, die es euch ermöglichen, Apps entsprechend der Verbindungsart (WiFi, mobile Datenverbindung über 2G/3G/LTE, Roaming, VPN oder LAN) 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 VPN-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 ich auch genauso beibehalte und jedem empfehlen kann. Alle Apps die ein Häkchen haben, dürfen demnach eine Verbindung mit dem Internet bzw. nach »außen« aufbauen. Bei mir sieht das dann so aus:
Je nach App und Anwendungszweck dürfen die installierten Apps über die unterschiedlichen Interfaces kommunizieren. DAVdroid kann bspw. keine Datenverbindung aufbauen, wenn die mobilen Daten aktiv sind. Das würde auch gar keinen Sinn machen, denn die Baikal-Gegenstelle mit allen Terminen und Kontakten befindet sich im internen bzw. privaten (Haus-)Netzwerk und lässt sich nur über das WLAN- oder VPN-Interface erreichen – also bspw. auch dann, wenn die mobilen Daten aktiv sind, aber eine VPN-Verbindung nach Hause aufgebaut ist.
Hinweis
Das Häkchen bei »(Root) – Apps mit Root-Rechten« wird unter anderem für die DNS-Namensauflösung benötigt, da ich den netd Deamon unter den Einstellungen deaktiviert habe. Durch diese kleine und unscheinbare Funktionsänderung erreicht ihr, dass alle DNS-Anfragen über die »(Root) – Apps mit Root-Rechten« versendet werden und somit die AFWall+ die DNS-Anfragen den entsprechenden Apps zuordnen kann. Andernfalls lassen sich DNS-Requests einer App nicht sauber zuordnen und Datenmitschnitte mit PCAPdroid sind wenig aussagekräftig.3.3 Custom-Script
Erfahrene Anwender können über Custom-Scripts der AFWall+ den vollen Funktionsumfang der iptables Firewall ansteuern. Ihr solltet diese Funktion allerdings nur dann nutzen, wenn ihr den Umgang mit iptables beherrscht. Ein falscher Umgang mit iptables bzw. den Custom-Scripts kann euer Smartphone für sämtliche Netzwerkverbindungen von jetzt auf gleich komplett sperren.
Update
18.10.2018: AFWall+ ist noch nicht offiziell mit Android 8 (Oreo) kompatibel. Das nachfolgende Custom-Script ist leider nicht lauffähig. Vorläufig gibt es aber eine modifizierte Fassung, die mit Android Oreo kompatibel ist.Anbei mein Startup- und Shutdown-Skript für mein Smartphone:
## iptables_on.sh ## AFWall+ Custom-Script & some tweaks ## Mike Kuketz ## www.kuketz-blog.de ## Changes: 15.01.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 (Connect to http://clients3.google.com via UID 1000) 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 #################### # Purge/Flush # #################### # All 'afwall' rules/chains gets flushed automatically, before the custom script is executed # Flush/Purge all rules except OUTPUT $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 #################### # 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 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 ##################### # Incoming Traffic # ##################### # Allow ICMP packets $IPTABLES -A INPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT $IPTABLES -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT $IPTABLES -A INPUT -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT # 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
Unterstütze den Blog mit einem Dauerauftrag!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
3.4 Custom-Scripts Addons
Über die Option »Skript festlegen« binde ich noch weitere Skripts ein bzw. nehme auf dem Tablet noch weitere Einstellungen vor, die ich kurz erläutern möchte. Unter anderem blockiere ich mit Hilfe des ASN-Skripts alle ausgehenden Verbindungen zu Google und Facebook:
bash asn_ipfire.sh --afwall "Google Facebook"
Den Output des Skripts binde ich jeweils als eigenständiges Skript unter »Skripte festlegen« ein:
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 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
Auf dem Tablet kommen noch spezielle Regelsätze dazu, um den Verkehr von bestimmten Apps sauber über Orbot zu routen:
# Enable Apps to access Orbot $IPTABLES -A "afwall" -d 127.0.0.1 -p tcp --dport 9040 -j ACCEPT $IPTABLES -A "afwall" -d 127.0.0.1 -p udp --dport 5400 -j ACCEPT # Newpipe » org.schabi.newpipe NEWPIPE_UID=`dumpsys package org.schabi.newpipe | grep userId= | cut -d= -f2 - | cut -d' ' -f1 -` $IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner $NEWPIPE_UID -j DNAT --to-destination 127.0.0.1:9040 $IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner $NEWPIPE_UID -j DNAT --to-destination 127.0.0.1:5400 # Android Media Server (Default UID: 1013) $IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner 1013 -j DNAT --to-destination 127.0.0.1:9040 $IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner 1013 -j DNAT --to-destination 127.0.0.1:5400 # VLC » org.videolan.vlc VLC_UID=`dumpsys package org.videolan.vlc | grep userId= | cut -d= -f2 - | cut -d' ' -f1 -` $IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner $VLC_UID -j DNAT --to-destination 127.0.0.1:9040 $IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner $VLC_UID -j DNAT --to-destination 127.0.0.1:5400
Hinweis
Weitere Informationen und Tipps, wie ihr Apps über Orbot routet, könnt ihr dem Beitrag »Android: Apps über Orbot routen« entnehmen.4. Fazit
Vertrauen ist gut – Kontrolle ist besser. Daher benutze ich auch auf meinem Android-System in Kombination mit den F-Droid Apps stets die AFWall+. Aber erst die Custom-Scripts und die zusätzlichen kleinen Tweaks, wie zum Beispiel das Umleiten aller (mobilen) DNS-Anfragen an den Anbieter meines Vertrauens, machen die AFWall+ so wertvoll. Versierte Anwender könnten vermutlich auch vollständig auf das iptables Frontend verzichten, aber man muss sich nicht wirklich jeglichem Komfort berauben.
Ich hoffe dieser kleine Einblick bietet euch neue Informationen und Anreize, um euch selbst nochmal mit euren AFWall+ Einstellungen und insbesondere den Custom-Scripts zu befassen. Persönlich möchte ich den »Android-Türvorsteher« jedenfalls nicht mehr missen.
Ü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+: Digitaler Türvorsteher – Take back control! Teil4
F-Droid und AFWall+ – Android ohne Google?! Teil4
Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test
ASN-Skript: Datensammler haben ausgeschnüffelt – IPFire Teil3
Linux Systemhärtung Basis – Linux härten Teil2
58 Ergänzungen zu “AFWall+: Wie ich persönlich die Android-Firewall nutze”
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.
Muss root dauerhaft eingestellt sein? Oder kann die Firewall mit root konfiguriert und anschließend die su-Rechte wieder entzogen werden?
AFwall+ benötigt Root dauerhaft. Als Alternative ohne Root: NetGuard.
Leider sind solche Apps komplett nutzlos, sobald Tethering ins Spiel kommt.
Das kann ich so nicht bestätigen. Bei mir funktioniert Tethering einwandfrei. Sollte es bei dir nicht funktionieren, dann mach doch bitte ein Issue auf GitHub auf.
Hallo Mike!
Eines wüsste ich zu gern und zwar welches Smartphone benutzt du?
Ich bin aktuell am überlegen, welches Gerät ich mir für LineageOS kaufen soll. Es ist leider nicht ganz einfach, weil meines Wissens nach verliert man außer bei Google Phones und OnePlus überall die Garantie!
Bei uns in Gebrauch sind:
– Moto G (von 2013)
– Moto G4 Plus (von 2016)
– Nexus 7 (2012)
Dazu noch einige Testgeräte.
Hallo Mike,
da Du ja hier nicht nur Profis ansprichst, würde ich mir eine Erklärung wünschen, wie man aus (D)einer Textdatei ein Custom-Script erstellt (unter Linux). Ich habe schon mehrere Anleitungen probiert, aber leider hat es bei mir noch nie funktioniert, so dass ich vermute, dass mein Script keines ist.
Hallo Carla,
ja, das ist richtig – ich spreche mit einigen Texten nicht nur Profis an. Mit diesem ist es vielleicht etwas anders. Das ist ein Blick hinter die Kulissen, bei dem Durchschnittsnutzer vermutlich schnell »abgehängt« werden. Insofern solltest du das Custom-Script besser nicht kopieren, sondern dich zunächst mit den Grundlagen von iptables beschäftigen.
Hallo Mike, Hallo an Alle,
wenn ich iptables_on.sh verwende, funktioniert WLAN Hotspot nicht.
Welche Zeilen müsste ich auskommentieren, damit es funktioniert?
Vielen Dank an Alle hier für die wertvollen Beiträge!
Wenn du die Custom Script Zeilen nicht verstehst, dann solltest du sie besser nicht 1:1 kopieren und verwenden. Ein Tipp von mir: Befasse dich zunächst mit den iptables Grundlagen.
Weiterhin gibt es in AFWall+ unter den Regelsätzen folgende Zeile: Tethering) – DHCP+DNS-Dienste – Vielleicht versuchst du es mal damit und ohne Custom-Script.
Danke für die schnelle Antwort!
In der von Dir verlinkten Grundlagenquelle steht: „….ist es sinnvoll, wenn detaillierte Kenntnisse zum Thema Netzwerke (Topologien, Routing, QoS, Nat, Ports) als auch Grundlagen des Kernels vorhanden sind….“
Kann mir das jemand noch einfacher beibringen? Vielleicht direkt auf Android / Lineage bezogen?
Kannst Du Deine Tipps zu AFWall+ am besten noch in Verbindung mit Orbot noch einsteigerfreundlicher schreiben?
Du hattest schon mal kurz dazu was geschrieben (Orbot und AFWall+). Allerdings alles sehr kompliziert –> nattern und so…
Liebe Grüße
Du wirst um grundlegende Netzwerktechnik nicht herumkommen.
Gibt unzählige Bücher und Artikel zur Materie.
Es bringt auch nichts Grundlagen auf Lineage/Afwall zu beziehen. Es sind immer die gleichen Grundlagen. Es hat überhaupt keinen Sinn Grundlagen 1000-fach zu wiederholen.
Auch die Zeilen zum Transparent Proxying über Orbot sind leicht zu verstehen wenn die Grundlagen geläufig sind.
Sollte man [-11] (Kernel) – Linux Kernel erlauben oder nicht? Oder ist das egal?
Ich nutze AFWall+ seit knapp zwei Jahren und hatte den Kernel immer blockiert. Funktioniert soweit alles problemlos.
Hey Mike,
so wie es aussieht, blockierst du den Linux Kernel auch. Was ich schon immer fragen wollte… Wieso sehe ich im Network Log, dass sich des öfteren Verbindungen von Google, Apple, Facebook, Cloudflare, SoftLayer und andere auf meinem Kernel ankommen?
Wenn ich den Kernel nicht blockiere, antwortet dieser auch, also es werden Pakete zurück gesendet. Auf dem Smartphone sind keine Anwendungen installiert die mit solchen Konzernen kommunizieren wollen. Funktionieren die GSM Funkmasten wie Hubs und ich bekomme auch Pakete von anderen Teilnehmern, sind die Pakete falsch geroutet oder ist es einfach so, weil das Smartphone am Internet hängt?
Du verwendest außerdem LOS 14.1. AFWall besitzt die Funktion „Start-Datenleck beheben“ was aber bei LOS 14 nicht geht. Wie umgehst du das Problem? Schon Init.d Light getestet ?
Danke
Zitat aus dem Artikel F-Droid und AFWall+ – Android ohne Google?! Teil4:
Weiter zu deiner Frage:
Gar nicht. Während dem Start werden keine Pakete übermittelt – jedenfalls bei meinem (App-)Setup nicht.
Danke für die Antwort.
Das mit TCP-Retransmissions ist mir bekannt. Wie ich aber schon schrieb. Ich habe keine solche Anwendungen die mit Apple oder Facebook, etc… kommunizieren. Wieso kommen solche Pakete trotzdem auf dem Linux Kernel an ?
Wenn ich das Datenleck nicht beheben würde, würde der Kernel antworten.
Eventuell vom Browser?
Hallo Mike,
der Browser wird auf dem Smartphone nicht verwendet. Diese unerwünschten eingehenden Verbindungen kommen meistens dann rein, wenn Mobilfunkdaten angeschaltet werden oder wenn ich reise oder mich in einer Stadt aufhalte. Sind solche Verbindungen bei anderen noch nicht vorgekommen/aufgefallen? Wird mein Smartphone explizit getrackt?
Danke
Ehrlich gesagt kann ich das nicht zuordnen. Irgendetwas auf deinem Gerät muss die Verbindungen aber ja aufbauen. Du solltest mal einen Datenmitschnitt über ein externes Device machen – falls du weißt wie das geht. Oder den gesamten Traffic über einen Proxy schleifen und dann schauen, wodurch das verursacht wird.
Nabend, könntest Du ausführlicher die Scripte beschreiben? Ich habe da ein Paar Probleme. Das wäre sicher auch für andere Leser wichtig!
Wie Mike schon sagte wer nicht versteht was im custom-script steht sollte sich erst mal mit den Grundlagen befassen.
Leider taucht bei mir »(Root) – Apps mit Root-Rechten« überhaupt nicht auf (gerootetes LineageOS auf OnePlus One) und somit findet überhaupt keine Namensauflösung statt nachdem ich netd deaktiviert habe. Gilt es noch etwas zu installieren neben dem offiziellen Root.zip von LOS?
Das ist eine Standard-Regel und muss da sein. Würde mich schwer wundern, wenn die tatsächlich nicht da ist. Vielleicht heißt sie etwas anders?
Anscheinend hatte ich es einfach überlesen, denn heute fand ich die Zeile. Vielen Dank für den Beitrag.
danke für den informativen Beitrag. Mich würde interessieren welche System Apps unbedingt Internet Zugriff benötigen.
Ich habe auf menem System (Custom Rom) folgende erlaubt:
– Kernel-Root-NTP-Tethering-VPN-AndroidSystem(1000)-Download-PacProcessor-ProxyHandler.
In Abhängigkeit von deiner Rom kommen sicher noch weitere/andere dazu. Bei Telefon,SMS weiss ich nicht, ob hier eine Einstellung überhaupt Sinn macht.
»Unbedingt« keine. Eine gute Idee ist aber sicherlich der Update-Prozess deines Systems, um über aktuelle Updates informiert zu sein. Ich habe das bei LOS 14.1 allerdings nicht freigeschaltet, da ich meine Updates manuell durchführe. Schau mal in diesem Beitrag F-Droid und AFWall+ – Android ohne Google?! Teil4 unter Ziffer 4.5 – da gibt es noch ein paar Hinweise.
Bitte nicht NetGuard empfehlen. Das sended fleißig Daten zum Entwickler zurück.
Lieber DNS66 aus F-Droid. Ist um einiges besser und man braucht keine Pro-Version.
Übrigens ist Root keine gute Idee, wie wieder einmal folgendes zeigt: „https://www.heise.de/security/meldung/ClkScrew-Geheime-Schluessel-mit-der-Brechstange-aus-der-ARM-Trustzone-auslesen-3841424.html“
Ich kenne die Problematik von NetGuard – bei Non-Root Geräten gibt es allerdings keine bessere Firewall. DNS66 ist keine Firewall, sondern eine Art Blocker auf DNS-Ebene, ähnlich dem Pi-Hole.
Entgegen weitläufiger Meinung ist ein gerootetes Gerät nicht zwangsläufig »unsicherer«, als ein Non-Root. Der Unterschied zu Non-Root ist hauptsächlich: Die Verantwortung des Nutzers steigt, sich keinen »Mist« zu installieren bzw. sorgsam mit seinem Gerät umzugehen. Gleiches trifft im Endeffekt aber auch auf Non-Root Geräte zu.
Und nun zurück zum Topic: AFWall+
Hallo Mike,
installiert du bei LineageOS selbst die Sicherheitsupdates? Und wenn ja wie?
Danke
Ich nehme jeden Monat das aktuelle Nightly Build für mein Gerät und spiele es einfach inklusive aller neuen Sicherheitsupdates auf: https://download.lineageos.org/falcon
Hallo Mike, im White-List Modus bekomme ich Radiodroid nicht zum Laufen, obwohl ich der App alle Zugänge erlaube… Habe keine extra Scripte aktiv. Eine Idee woran das liegen könnte? Vielen Dank
Versuche es mal mit der Freigabe des »Media Servers«.
Media server: Der Media-Server ist eine klassische »Helper-App«. Erst durch das Whitelisting dieser App, können Apps Video- und Audioinhalte wiedergegeben werden.
Hallo Mike,
vielen Dank für Deine Antwort. Leider hat dies auch nicht geholfen…
VG albis
Hallo,
gibt es eine effektive Möglichkeit Customscripts in Afwall+ zu debuggen?
Über AFWall+ klappt das nicht. Da musst du ins Terminal (Terminal Emulator / Termux) und dein Skript von dort aus laden. Da werden dir dann Hinweise und Fehler direkt im Terminal ausgegeben.
Hey Mike,
AFWall+ / eine Firewall App hatte ich früher auch im Einsatz, allerdings komplett überflüssig wenn man das xposed framwork in Kombination mit xPrivacy benutzt.
Lese oder schaue dir das ein oder andere Video über xPrivacy an. Einmal in Betrieb wirst du darauf nie wieder verzichten wollen, da es komplett alle permissions abfängt / abfrägt.
Viele grüße
Ich kenne XPrivacy in- und auswendig: XPrivacy – Android ohne Google?! Teil6
Die Nutzung kann ich aber nicht mehr empfehlen, da Marcel die Entwicklung eingestellt hat. Ich mache es so.
Und das XPosed Framework steht auch noch nicht offiziell für Android 7, geschweige denn 8 zur Verfügung.
in Bezug auf das „offizielle“ (rovo89) XPosed Framework.
rovo89 hat mit der Entwicklung zeitlich Schwierigkeiten und stößt an seine Grenzen, allerdings ist (z.B. mit Magisk) ein xPosed Framework / SKD 25 gegeben welches auch super funktioniert. xPrivacy läuft bei mir seitdem ohne Probleme.
Auf die Apps in F-Droid würde ich mich nicht verlassen, mein xPrivacy schlägt bei der ein oder anderen App dennoch sehr häufig Alarm für Rechteabfragen die nicht aufgeführt waren…
xPrivacy wurde von Marcel zwar bisher nicht weiter entwickelt, ändert aber nichts an der Funktionalität. Ich sehe um ehrlich zu sein keinen Grund xPrivacy nicht weiterhin in Kombi mit F-Droid laufen zu lassen.
Ist mir alles bekannt. ;-)
Nur ein paar Hinweise und dann beenden wir die Diskussion hier, weil das Topic AFWall+ ist:
– Nur weil eine App eine Information über eine Berechtigung abfragt, bedeutet das nicht, dass sie diese auch versendet. Kurz: Nein, die meisten F-Droid Apps die ich getestet habe versenden keine sensiblen Informationen. Und übrigens: Die Rechteabfragen werden oftmals falsch interpretiert. Unter einigen Berechtigungen sammeln sich weitere, die Android nicht weiter auflistet. Schau mal hier: Das Android Berechtigungsmodell: Ein perfides Konstrukt
– XPrivacy kann man bis maximal Android 6 einsetzen aufgrund neuer APIs und Abfragen in 7+ – Ich bekomme für Android 6 kein Custom-ROM mit aktuellen Security Patches. Jedenfalls gilt das für mein Gerät und für viele andere vermutlich auch.
– Du kannst ja XPrivacy gerne weiter nutzen. Es ist ein tolles Tool. Nur eben »nur« bis Android 6.x. Wenn du für dein Gerät noch Patches bekommst, dann ist das ja okay.
Hinweis: Android: XPrivacy ist bis maximal Android 6 nutzbar.
Ich hätte hier eine Frage:
Ich verwende auf meinem Android 5 (Galaxy S5) seit Jahren sogenannte Firewall ohne Root Rechte (heisst genau so). Kann da jemand sagen wie sicher/unsicher das Ding ist?
Bring das was? Sendet die meine Daten an den Server der Entwickler des Programmes?
Vielen Dank im Voraus
Michael
Bitte die Suchfunktion des Blogs benutzen: Firewall ohne Root
Mich würde interessieren, ob es eine Möglichkeit gibt, im CustomScript geblockte IP Adressen für einzelne Apps dann doch freizuschalten.
Also nehmen wir mal an, ich möchte Google Maps nutzen und die Google IP Adressen ausschließlich für die Google Maps App freigeben. Der Rest des Systems bzw. alle anderen Apps sollen keine Verbindung zu Google herstellen dürfen.
Wie kann man da eine Ausnahmeregel im CustomScript erstellen?
Google maps im custom erlauben und erst im Anschluss die google IPs blocken.
Die erste zutreffende Regel wird immer angewendet.
Ok, ich vermute mal die Ausnahmeregel müsste dann in etwa so aussehen:
$IPTABLES -A „afwall“ -d IPADRESSE -m owner –uid-owner UIDNUMMER -j ACCEPT
Wie sieht es mit dem Häkchen in Afwall aus? Im Moment gehe ich von folgender Logik aus:
Häkchen bei Google Maps gesetzt:
Es werden alle Verbindungen erlaubt. d.h. theoretisch auch IP Adressen, die nicht Google gehören. Die Ausnahme im CustomScript gewährleistet Verbindungen zu Google.
Häkchen bei Google Maps nicht gesetzt:
Verbindungen sind grundsätzlich geblockt. Nur die Ausnahmen im CustomScript werden berücksichtigt.
Korrigiert mich bitte, wenn ich bei irgendetwas falsch liege.
Das mit den Häckchen läuft aus meiner Erfahrung etwas anders. Wenn ich im Custom Script Google IPs blocke können auch per Häkchen erlaubte Apps nicht auf den Google Adressraum zugreifen.
Ich gehe davon aus dass die Regeln per Häckchen quasi hinter den Custom Rules eingefügt werden. Das führt dazu dass das entsprechende Paket zuerst auf die Regel blocke Google trifft.
Daher müsstest du die UID vor dem Blocken des Google Adressraums zulassen und erst dann die Google IPs blocken -> daher ist dies nur über das Custom Script möglich.
Deine erwähnte Regel sieht auf den ersten Blick richtig aus.
Hallo Mike,
Kurze Frage zu den Google IP’s. Ich möchte nur den Playstore und Google Cloud Messaging (microG) benutzen und alles andere von Google blocken. Wie filtere ich das jetzt? GCM und den Playstore über die UID im Script zuzulassen, wie Anonymous es vorschlägt, erscheint mir zu undifferenziert, da sich die apps dann immernoch zu beliebigen anderen ip’s verbinden können, wenn ich das richtig verstehe. Also wie stelle ich das nun an?
OT: Mit xprivacy war das alles so easy. Das fragte immer für jeden host/ip ob ich die Verbindung zulassen möchte. Wird echt Zeit das rovo89 das xposed framework fertig bekommt und sich dann vielleicht ein anderer Entwickler für xprivacy findet. Hätte ich die Skills, würde ich mich der Sache annehmen. Aber Sicherheit/Datenschutz scheint bei xda nicht wirklich ein Thema zu sein. Alles voll die google Fanboys. :D
Du kannst beim Zulassen zusätzlich zur UID auch noch die IP Adresse bzw den Bereich in der Regel spezifizieren.
Xposed ist mittlerweile fertig aber Xprivacy ist nicht ready für Nougat bzw Oreo
Ich hatte über längere Zeit AFWall+ auf LineageOS installiert, hatte aber Probleme mit dem leak beim booten und diversen Abbrüchen aufgrund der Energiesparfunktion (lässt sich beheben) und dem lowmemorykiller
Wer AFWall+ auf LineageOS installiert hat, sollte noch folgendes beachten, vor allem auf älteren Geräten:
-Wer den internen Speicher mit einer SDKarte („mixed mode“ oder komplett) erweitert hat, sollte nach der Installation die App undebingt auf den internen Speicher verschieben (über Einstellungen – Apps – AFWall+ – Speicher – Genutzter Speicher „Ändern“ – Interner gemeinsamer Speicher auswählen). Das hat den Vorteil, dass die App früher geladen wird. Bei meinem älteren und langsameren Phone hat das dazu geführt, dass die App nicht mehr von der Opt-out Einstellung der Energiesparfunktion berücksichtigt wurde.
-AFWall+ von der Akkuleistungsoptimierung ausschliessen:
Über Einstellungen – Akku – rechts oben „die drei Punkte“ – Akku-Leistungsoptimierung – Nicht optimiert zu alle Apps umschalten – AFWall+ zu „nicht optimieren“ umschalten.
Hallo Mike,
eine Frage noch:
Woher beziehst Du die Google-IPs für die Sperrliste? Ich habe nur ‚ $ dig TXT +short ‚ -scripte gefunden, wie z.B. das hier: https://gist.github.com/n0531m/f3714f6ad6ef738a3b0a
Wobei alle „unvollständig“ sind.
Blog lesen. ;-)
Direktlink: ASN_IPFire_Script
Moin,
bei deinem custom script habe ich noch eine Änderung für mich vorgenommen:
192.168.x.x ist natürlich die entsprechende IP-Adresse des Raspberry Pis im Netzwerk. So habe ich in allen WLANs immer noch das werbeblockende Pi-Hole zwischen mir und dem Netz. Allerdings nur sinnvoll, wenn man in WLANs, die nicht das eigene sind, grundsätzlich über VPN zum Heimnetz verbindet. Bei mobilem Internet benutze ich kein VPN, daher dort der direkte Weg zum DNS der Digitalcourage
Gruß
Hallo Max,
habe hier ein ähnliches Setup für die separate Behandlung des DNS für WLAN und Mobile. Allerdings funktioniert dein Vorschlag bei mir nicht und es wird weiterhin der über DHCP vorgegebene DNS-Server verwendet.
Ich vermute, dass das an der Auswertungsreihenfolge des Custom Scripts und der AFWall-Regeln liegen könnte. Bei mir funktioniert momentan nur die Auswahl der Netzwerkschnittstelle direkt in der OUTPUT-Chain:
Ich habe auch verschiedene geringe Modifikationen mit der Chain „afwall“ in meinem Custom Script probiert und damit auch keine Änderung des DNS-Servers erreicht.
Gruß Tom
Hi,
bin vom Fairphone 1 aufs Fairphone 2 mit FP Open umgestiegen und auch AFWALL+ wieder installiert. Habe jetzt bei jedem WLAN die Meldung „Verbunden, kein Internet“ obwohl die Verbinung zu funktionieren schein. Kann das an einer Einstellung in AFWALL+ liegen?
Liegt vermutlich daran: Android: Captive Portal Check Änderung
Hallo Mike,
bei der gemeinsamen Nutzung von AFWall und Orbot für Apps wie Newpipe gibt es offenbar noch ein Problem mit DNS-Anfragen.
Testweise habe ich ausschließlich Orbot in AFWall auf die Whitelist gesetzt und das Customscript mit den Ergänzungen für Orbot und Newpipe übernommen.
Wenn ich damit Newpipe ohne Transparent Proxy sowie ohne den VPN-App-Modus nutzen möchte, dann funktioniert das nicht.
Laut AFWall-Log erhält der Root-Prozess (UID: 0) DNS-Anfragen, die natürlich blockiert werden.
Nach dem Setzen der notwendigen Freigabe wird die DNS-Anfrage schließlich zugelassen und Newpipe kann normal verwendet werden.
Der restliche Traffic von Newpipe läuft über Tor, weshalb ich davon ausgehe, dass das Customscript grundsätzlich angewendet wird, bloß eben nicht richtig für DNS-Anfragen.
Das ist natürlich ärgerlich.
Apps wie F-Droid oder Orfox, die Support für Tor selbst schon mitbringen und deshalb keine Ergänzung im Customscript brauchen, leiten bei mir immer ihren gesamten Traffic über Tor.
Vielleicht kann das der eine oder andere bei sich überprüfen und hier nochmal drauf antworten.