NetGuard: Datenverkehr von Android-Apps filtern – Privatsphäre schützen

1. Kein Anruf unter dieser Nummer

NetGuard ist ein mächtiges Werkzeug für Android. Es erlaubt sehr genau festzulegen, wohin bzw. zu welchem Server/Gegenstelle eine App bzw. Android eine Verbindung aufbauen darf. Gerade für datenschutzsensible Nutzer und Kontrollfreaks, die keine (personenbeziehbaren) Daten an Drittparteien wie Tracking- oder Werbeanbieter weitergeben möchten, ist die Nutzung unverzichtbar.

In den vergangenen Jahren hatte ich bereits mehrere Blog- und Microblog-Beiträge zu NetGuard verfasst. Der vorliegende Beitrag zeigt auf, wie der ausgehende Datenverkehr von Apps nach dem Whitelist-Prinzip gefiltert werden kann: Es werden also nur jene Verbindungen von Apps zugelassen, die für die Funktionserbringung notwendig sind. Des Weiteren greife ich das Thema Filterlisten (gegen Tracker und Werbung) auf und erkläre, weshalb Nutzer von GrapheneOS besser (zwei) feste DNS-Server innerhalb NetGuard hinterlegen sollten, um Datenleaks zu vermeiden.

2. NetGuard

Die Android-Firewall NetGuard wird bereits seit 2015 von Marcel Bokhorst entwickelt. Der Quellcode ist auf GitHub für jeden frei einsehbar. Das Besondere an NetGuard: Es erlaubt die ausgehende Filterung/Kontrolle von App- und System-Datenverbindungen, ohne dazu Root-Rechte zu benötigen. Dazu bedient sich NetGuard der VPN-Schnittstelle von Android. Ein- und ausgehende Datenpakete schleust NetGuard durch das VPN. Dies ermöglicht nicht nur die Filterung des Datenverkehrs, sondern auch das Blockieren von Tracking- und Werbedomains bzw. Anbietern auf DNS-Ebene. Der Nachteil: Der Aufbau eines weiteren VPN-Tunnels ist nicht möglich, da die VPN-Schnittstelle bereits von NetGuard verwendet/besetzt wird.

Nachfolgend werde ich nicht jede Facette und Einstellungsmöglichkeit von NetGuard erläutern. Hattet ihr bisher also keine Berührungspunkte mit NetGuard, empfiehlt es sich zunächst den Beitrag »NetGuard Firewall – Android unter Kontrolle Teil4« zu lesen. Dort wird unter anderem ausführlich erklärt, wie NetGuard funktioniert, welche Vor- und Nachteile es bei der Nutzung zu beachten gibt und wie die Inbetriebnahme gelingt.

2.1 Unterschiedliche Versionen

NetGuard ist nicht gleich NetGuard – es existieren unterschiedliche Versionen, die sich in ihrem Funktionsumfang erheblich unterscheiden. Die Unterschiede auf einen Blick:

• Basis-Version: In der Basis-Version, die im Play Store angeboten wird, lassen sich keine Werbung oder Tracker blockieren – dies verstößt nämlich gegen das datengetriebene Geschäftsmodell von Google. Die Basis-Version implementiert daher »nur« die Firewall-Funktionalität.
• Pro-Version: In der Basis-Version ist NetGuard für unsere Bedürfnisse nicht ausreichend, erst die Pro-Version schaltet jene Funktionen frei, die im vorliegenden Beitrag beleuchtet werden. NetGuard bietet unterschiedliche Pro-Funktionen an, die ihr als In-App-Kauf entweder einzeln erwerben könnt oder als Gesamtpaket. Zu den Pro-Funktionen zählen unter anderem die Protokollierung des Netzwerkverkehrs und die feingranulare Filterung von Verbindungen auf IP-Adressebene.
• Ad-Blocking-Version: Das Filtern von Tracking- und Werbedomains verstößt gegen Googles Geschäftsmodell. Die Ad-Blocking-Version von NetGuard kann daher ausschließlich via GitHub oder dem F-Droid-Store bezogen werden.

Was ihr also braucht: Ihr müsst euch NetGuard von GitHub oder dem F-Droid-Store herunterladen und installieren. Anschließend solltet ihr noch (mindestens) 7,- € investieren bzw. spenden, um die Pro-Funktionen freizuschalten. Diese einmalige Investition schaltet nicht nur alle Pro-Funktionen frei, sondern ermöglicht die Nutzung von NetGuard (inkl. Pro-Funktionen) auf allen Android-Geräten, die ihr privat/selbst besitzt:

You can get all current and future NetGuard pro features (including updates) without Google Play services for the GitHub or F-Droid version by a one time donation of € 0.10 or more. If you donate 7 euros or more, you can activate the pro features on all devices you personally own, else you can activate the pro features one time only.

3. Datenverkehr von Apps filtern

Nach der Inbetriebnahme von NetGuard könnt ihr damit beginnen, den ausgehenden Datenverkehr von Apps zu filtern/kontrollieren. Dies ist insbesondere bei Apps nötig, die im Google Play Store angeboten werden. Diese beinhalten oftmals Werbe- und Trackingbibliotheken, von denen ein unnötiges Risiko für die Sicherheit und den Datenschutz ausgeht. Detailliert erklärt im Beitrag: Wie Tracking in Apps die Sicherheit und den Datenschutz unnötig gefährdet.

Die DB-Navigator-App der Deutschen Bahn beinhaltet laut Exodus Privacy bspw. aktuell sieben Tracker – ein Unding für eine App, die Eigentum des Bundes ist. Nachfolgend demonstriere ich, wie ihr den Datenverkehr der App mit NetGuard auf ein Maß beschränken könnt, mit dem alle notwendigen Funktionen wie Ticketbuchung etc. abgedeckt sind, die Tracker- und Schnüffeldienste aber außen vor bleiben.

3.1 Whitelist-Prinzip

Die Schutzwirkung, die sich mithilfe einer Firewall erreichen lässt, hängt zu einem hohen Grad von einer sachgemäßen Konfiguration ab. Generell werden zwei unterschiedliche Konfigurationsansätze unterschieden:

• Blacklist: Erlaubt ist alles, was nicht ausdrücklich verboten ist
• Whitelist: Verboten ist alles, was nicht ausdrücklich erlaubt ist

Ich empfehle grundsätzlich das Whitelist-Prinzip. Es werden also nur jene Verbindungen nach außen zugelassen, die explizit erlaubt sind – alles andere wird verworfen. Nicht nur bei einer Firewall, sondern auch in anderen Bereichen der IT, ist das Whitelist-Prinzip oftmals dem Blacklist-Prinzip vorzuziehen.

Nachfolgend erläutere ich also, wie man den App-Datenverkehr mit NetGuard nach dem Whitelist-Prinzip filtert. Es werden nur jene Verbindungen erlaubt, die für die Funktionserbringung einer App notwendig sind.

3.2 DB-Navigator

Mit NetGuard lässt sich eine Whitelist (für jede App) erstellen. Diese Whitelist beinhaltet alle Domains bzw. Server, zu denen die DB-Navigator-App eine Verbindung initiieren darf. Alle anderen werden blockiert. Mit NetGuard lässt sich das wie folgt erreichen:

• Zunächst muss in NetGuard über Einstellungen -> Erweiterte Optionen die Protokollfunktion [Internetzugriff protokollieren] aktiviert werden
• Die App selbst bekommt in NetGuard zunächst keinen Zugriff über das WLAN oder mobile Netz
• Anschließend wird die App gestartet. Diese versucht nun Verbindungen zu initiieren – aufgrund der Filterung durch NetGuard wird dies nicht funktionieren
• Dank der aktivierten Logging-Funktion werden allerdings alle Verbindungen aufgezeichnet, die die App versucht hat, zu initiieren
• Nun muss man entscheiden, welche Domains innerhalb NetGuard erlaubt werden – also wohin die DB-Navigator-App eine Verbindung aufbauen darf. Das erfordert Erfahrung, Ausprobieren, Herantasten und Geduld. Abgesehen von der Karten-Funktion (via Google Maps) benötigt die App genau neun Verbindungen, um den vollen Funktionsumfang zu erfüllen:
  • accounts.bahn.de
  • reiseauskunft.bahn.de
  • cms.services-bahn.de
  • www.bahn.de
  • www.img-bahn.de
  • fahrkarten.bahn.de
  • mobile.bahn.de
  • verbundshop.bahn.de
  • ps.bahn.de
• Die restlichen Domains, die die App aufruft, sind Tracking und Analytics – also nichts, was man wirklich benötigt

Anbei noch ein Screenshot, wie man innerhalb NetGuard eine Domain freigibt:

Anfangs ist es gar nicht so einfach, zu entscheiden, welche Domains tatsächlich/wirklich notwendig sind, damit die App funktioniert. Anbei ein paar Tipps:

• Domainnamen: Achtet bei den Verbindungen auf den Domainnamen, den die App kontaktiert. Im Fall des DB-Navigators, sind Verbindungen zu Domains wie accounts.bahn.de oder reiseauskunft.bahn.de zu erwarten, da dies Subdomains von bahn.de sind. Die bahn.de-Domain gehört der Deutschen Bahn, es ist daher wahrscheinlich, dass die App zu dieser (Sub-)Domain Verbindungen initiiert. Lautet die Domain hingegen tracking.bahn.de solltet ihr diese zunächst einmal nicht erlauben und ausprobieren, ob die App dennoch funktioniert.
• Ausprobieren: Ihr solltet restriktiv vorgehen. Gebt nur solche Domains frei, die für die Funktionserbringung notwendig sind. Das ist nicht immer auf den ersten Blick ersichtlich und häufig braucht es einige Anläufe bzw. Zeit, bis die Whitelist für eine App vollständig ist. Häufig tauchen Verbindungsanfragen bzw. Domains nicht unmittelbar nach dem Start der App auf, sondern erst dann, wenn eine bestimmte Aktion/Funktion innerhalb der App ausgelöst wird.
• Split-Screen: Damit ihr live nachverfolgen könnt, welche Domains eine App abfragt, könnt ihr den Android Split-Screen verwenden. Dabei wird der Bildschirm unter zwei Apps aufgeteilt. In der einen Ansicht startet ihr NetGuard und öffnet die Detailansicht der App, die ihr Filtern/Konfigurieren wollt. In der zweiten Bildschirmhälfte ruft ihr die App auf. Ihr könnt dann innerhalb NetGuard unmittelbar nachverfolgen, welche Domain(s) eine App anfragt, wenn ihr eine bestimmte Aktion auslöst:

4. Filterlisten

Wie bereits unter Ziffer 2.1 aufgezeigt, bietet NetGuard ebenfalls die Möglichkeit Tracking- und Werbedomains bzw. weitere »schädliche« Domains zu blockieren. Da dazu immer mal wieder Fragen auftauchen, nachfolgend ein paar Tipps dazu:

• NetGuard verarbeitet Standard-Listen im TXT-Format. Bitte verwendet keine Listen in anderen Formaten wie bspw. RAW (*.bin Dateien)
• Für NetGuard macht es vom Akkuverbrauch als auch von der Performance keinen Unterschied, ob man Blocklisten mit wenigen oder vielen Einträgen verwendet. Alle Domains werden nach dem Einlesen in einer Hash-Table abgelegt.
• Als Blocklisten empfehle ich entweder die StevenBlack-Hostfile oder die EnergizedProtection-Liste in der Variante/Pack »Blu«.
• Es ist nicht möglich, für einzelne Apps eine Ausnahme zu erstellen. Wird eine Domain geblockt, dann gilt das für alle Apps. Ein Ausweg ist nur die Blockliste zu bearbeiten bzw. eine andere zu wählen.
• Innerhalb von NetGuard könnt ihr sehen, wenn eine Werbe- bzw. Trackingdomain blockiert wird. Das funktioniert über das Hamburger-Menü -> Protokoll anzeigen. Haltet dort Ausschau nach Verbindungen mit dem Typ qtype 1 und qtype 28.
• Die Ad-Block-Liste aktualisiert sich leider nicht automatisch, dies müsst ihr hin und wieder manuell anstoßen.

Das Filtern mit NetGuard funktioniert. Allerdings sollte man sich vor Augen führen, dass NetGuard in erster Linie eine Firewall ist, die den ausgehenden Datenverkehr von Apps filtern kann. Daher ist das Filtern/Blockieren von Domains auf die Basisfunktionalität beschränkt. Es gibt also weder die Möglichkeit, manuell Ausnahmen zu definieren, noch mehrere Filterlisten einzulesen oder einzelne Apps vom Blocking auszunehmen.

Und noch eine Anmerkung von Marcel Bokhorst (Entwickler von NetGuard):

A block list is always a best effort because marketing companies obviously do not contribute to it.

This means that block lists are not perfect and can block addresses that shouldn’t be blocked. Larger hosts files will result in a higher risk of falsely blocked addresses and are therefore not necessarily better, on the contrary.

Steven Black’s host file is IMHO a good compromise between several factors and therefore this is used as default for NetGuard. False blocks are rare with the hosts file, but occasionally happen.

4.1 Problem: Wildcard-Domain-Blocking

Im Beitrag »Wie DNS-Blocking mit speziellen Domains leicht umgangen werden kann« hatte ich auf ein Problem mit (Sub-)Domains hingewiesen, die von Tracking-Anbietern an ihre Kunden vergeben werden. Kurz zusammengefasst:

Blocking von Werbe- und Tracking-Domains auf DNS-Ebene wird immer schwieriger. Anbieter von Tracking-Lösungen vergeben ihren Kunden schon eigene Subdomains, die so in den Blocklisten nicht verzeichnet sind. Beispiel DB Navigator:

• deutschebahn.sc.omtrdc.net (Adobe Analytics)
• zn0lxkzethotizctx-bahn.siteintercept.qualtrics.com (Qualtrics)

Es existieren zwar Filterlisten, die auch Domains wie deutschebahn.sc.omtrdc.net (Adobe Analytics) oder zn0lxkzethotizctx-bahn.siteintercept.qualtrics.com (Qualtrics) beinhalten, diese sind aber meist riesig und führen nicht selten zu Overblocking. Das bedeutet: Es werden fälschlicherweise Domains gefiltert, die für die Funktionalität einer App/Website erforderlich sind. Außerdem wird es niemals eine Filterliste geben, die alle individuellen Subdomains eines Tracking-Anbieters kennen wird. Also bspw.:

• zn0lxkzethotizctx-bahn.siteintercept.qualtrics.com
• zn0u4uhkzxfoylle1-vmware.siteintercept.qualtrics.com
• zn1amgis3tmt5gckb-dropbox.siteintercept.qualtrics.com
• zn3rhju8vo76txc85-microsoft.siteintercept.qualtrics.com
• zn8chvercsgzwyi8z-sony.siteintercept.qualtrics.com
• […]

Ich hatte dann für Adblock (OpenWrt), RethinkDNS (Android), AdGuard (iOS) und Pi-hole Lösungen für das Problem skizziert, die allerdings nicht mit NetGuard kompatibel sind. NetGuard unterstützt schlichtweg kein Wildcard-Domain-Blocking:

wildcards are not supported due to performance and battery usage reasons

Die Lösung für NetGuard ist daher simpel: Apps müssen nach dem Whitelist-Prinzip gefiltert werden. Wie unter Ziffer 3 aufgezeigt, ermöglicht dies eine feingranulare Filterung des ausgehenden Datenverkehrs. Sobald bspw. die beiden Domains:

• deutschebahn.sc.omtrdc.net (Adobe Analytics)
• zn0lxkzethotizctx-bahn.siteintercept.qualtrics.com (Qualtrics)

vom DB Navigator aufgerufen werden, blockt NetGuard diese Verbindungsversuche einfach weg.

4.2 Filterlisten-Skript

Persönlich kombiniere ich gerne die Filterliste StevenBlack-Hostfile (Unified hosts + fakenews + gambling + porn + social) und die EnergizedProtection-Liste in der Variante/Pack »Blu«. Zusätzlich ergänze ich dann noch die Android-Tracking-List vom Pi-hole-Projekt. Wie bereits aufgezeigt, verarbeitet NetGuard allerdings nicht mehr als eine Filterliste. Für mich ist die Lösung daher ein kleines Skript, das die Filterlisten für mich abruft, bereinigt und miteinander kombiniert. Anschließend lege ich die Filterliste dann auf meinen Webserver und trage die URL in NetGuard ein. Über doppelte bzw. mehrfache Domains müsst ihr euch übrigens keine Gedanken machen:

When NetGuard imports the hosts file, it automatically discards any duplicates entries, so duplicate entries are not a problem and have no performance impact after the file is imported

Nachfolgend das (Bash-)Skript, das ihr gerne an eure Bedürfnisse anpassen könnt:

#!/bin/bash
## Auto update NetGuard blocklist

# Download blocklists
curl -s https://raw.githubusercontent.com/StevenBlack/hosts/master/alternates/fakenews-gambling-porn-social/hosts > netguard_steven_complete
curl -s https://raw.githubusercontent.com/hagezi/dns-blocklists/main/hosts/light.txt > netguard_hagezi_light
curl -s https://raw.githubusercontent.com/AdguardTeam/AdguardFilters/master/SpywareFilter/sections/mobile.txt > netguard_adguard_mobile

# Convert 'netguard_adguard_mobile' blocklist for NetGuard
grep '^||' netguard_adguard_mobile | sed -e 's/.*||//' | sed 's/\^.*//' | sed 's/\/.*//' | sed 's/:.*//' | sed 's/^/0.0.0.0 /' > netguard_adguard_mobile_clean

# Combine blocklists
cat netguard_steven_complete netguard_hagezi_light netguard_adguard_mobile_clean netguard_custom > netguard_blocklist

# Remove domains from blocklist (overblocking) 
# sed -i '/0.0.0.0 example.com/d' netguard_blocklist

# Copy blocklist to webserver folder
cp netguard_blocklist /var/www/sites/mydomain.de

5. Probleme und Workarounds

5.1 Keine Filterung/Logging

Wie den Lesern des Blogs bekannt sein dürfte, prüfe ich regelmäßig den Datenverkehr von Apps. Dabei sind mir einige Unregelmäßigkeiten in Kombination mit NetGuard aufgefallen. Trotz aktivierter Datenverkehr-Filtern-Funktion innerhalb NetGuard, kam es während den Prüfungen regelmäßig vor, dass Domains nicht blockiert bzw. von NetGuard gar nicht erfasst wurden. Ein Beispiel: Beim Aufruf der heise-App wird ein Cookie-Consent-Banner eingeblendet:

Die Frage ist nun, von welcher Adresse dieses Banner nachgeladen wird. Es sind die zwei folgenden Adressen:

• cdn.privacy-mgmt.com
• notice.sp-prod.net

Innerhalb NetGuard sind für die heise-App allerdings nur drei Domains auf der Whitelist:

• www.heise.de
• api.heise.de
• heise.cloudimg.io

Diese drei Domains genügen, um die Inhalte/Artikel innerhalb der heise-App aufzurufen bzw. darzustellen. Nach einem Austausch mit Marcel konnte das Problem dann eingegrenzt werden. Es betrifft GrapheneOS, vermutlich aber auch andere Android Custom-ROMs bzw. Android-Versionen. Das Problem kurz zusammengefasst: Android routet DNS-Anfragen teilweise am VPN vorbei. Was genau die Ursache für dieses Verhalten ist, konnten wir leider nicht herausfinden. Fakt ist: GrapheneOS routet DNS-Anfragen teilweise am VPN vorbei. Und genau das passiert bspw. mit der Domain cdn.privacy-mgmt.com, beim Start/Aufruf der heise-App. Die DNS-Anfrage wird nicht durch das NetGuard-VPN geleitet. Als Folge wird die IP-Adresse aufgelöst und der Cookie-Consent-Banner wird nachgeladen – obwohl die Adresse nicht auf der Whitelist steht bzw. freigegeben wurde. Dadurch können also Datenleaks entstehen bzw. Apps bauen Verbindungen auf, die so vom Nutzer nicht freigegeben bzw. beabsichtigt sind.

Das Problem fiel mir allerdings erst auf, als ich mit meinem mobilen Endgerät das heimische WiFi verlassen habe und die mobile Datenverbindung des Providers zum Surfen genutzt habe. Im heimischen WiFi werden alle DNS-Anfragen zusätzlich von Adblock (OpenWrt) gefiltert. Das bedeutet: Innerhalb des heimischen WiFi wurde die Domain cdn.privacy-mgmt.com von einer Blockliste »herausgefischt« und der Cookie-Consent-Banner konnte nicht geladen werden. Im mobilen Netz hingegen entfällt diese Filterung und man ist einzig auf die Datenverkehr-Filtern-Funktion und das Ad-Blocking von NetGuard angewiesen. Das funktioniert generell auch zuverlässig – nur eben dann nicht, wenn Android DNS-Anfragen am VPN vorbeischleust.

Um dieses Problem zu beheben, gibt es aktuell nur eine Lösung: Ihr müsst innerhalb NetGuard unter Einstellungen -> Erweiterte Optionen die IP-Adresse von zwei VPN-DNS-Server hinterlegen bzw. eintragen, die über den Port 53 erreichbar sind (keine DoT- oder DoH-Adressen). Beispielhaft sind nachfolgend die IPv6-Adressen der quad9 DNS-Server eingetragen:

Tipp: Hinterlegt dort zwei DNS-Server mit ihrer IPv6-Adresse. Bei der Verwendung von IPv4-Adressen konnte ich im mobilen Netz der Telekom (Congstar) beobachten, dass die Umsetzung von DNS-Name in IP-Adresse deutlich länger dauert. Damit die IPv6-Adressen der DNS-Server aus eurem Heimnetz erreichbar sind, muss dieses IPv6-fähig sein. Empfehlenswerte DNS-Server findet ihr in der Empfehlungsecke – wählt euch dort zwei aus, die über Port 53 (also unverschlüsselt) erreichbar sind.

Diese Umstellung bzw. Hinterlegung von DNS-Servern ist natürlich nicht unproblematisch. Diese beiden Einträge gelten nämlich für WiFi als auch das mobile Netz gleichermaßen. Die beiden hinterlegten DNS-Server müssen also sowohl aus dem heimischen WiFi-Netz als auch dem mobilen Netz eures Providers erreichbar sein. NetGuard bietet aktuell nämlich keine Möglichkeit, für die unterschiedlichen Interfaces (WiFi/Network) separate DNS-Server zu hinterlegen. Notgedrungen bedeutet das daher: Auf die DNS-Auflösung bzw. -Filterung in eurem Heimnetz (bspw. durch einen Pi-hole) müsst ihr leider verzichten. Insgesamt ist das aber verschmerzbar, da NetGuard selbst auf DNS-Ebene filtern kann.

5.2 Zusätzliches VPN

Mit NetGuard lässt sich feingranular steuern, wohin Apps (Daten-)Verbindungen aufbauen dürfen. Der Preis dafür: Damit NetGuard den gesamten Datenverkehr vom System bzw. den Apps einsehen kann, muss dieser durch ein VPN geschleust werden. Auf nicht gerooteten Geräten besteht ansonsten keine Möglichkeit, dass NetGuard den Datenverkehr einstehen kann. Der Nachteil: Der Aufbau eines weiteren VPN-Tunnels ist nicht möglich, da die VPN-Schnittstelle bereits von NetGuard verwendet wird. Dennoch kommt häufig die Frage auf, ob es denn nicht dennoch möglich ist, ein weiteres VPN zu schalten. Die Kurzantwort: Theoretisch schon, in der Praxis nicht.

Dazu die FAQ von NetGuard – (2) Can I use another VPN application while using NetGuard?:

If the VPN application is using the VPN service, then no, because NetGuard needs to use this service. Android allows only one application at a time to use this service.

NetGuard is a firewall application, so there is no intention to add VPN support. However, NetGuard supports a SOCKS5 proxy to chain VPN applications.

Leider gibt es keine mir bekannte VPN-App, die einen SOCKS5-Proxy unterstützt. Bevor der systemeigene Android-VPN-Dienst existierte, unterstützten nahezu alle VPN-Anwendungen einen SOCKS-Proxy – heute leider nicht mehr. Alle VPN-Apps nutzen den VPN-Service von Android und unterliegen damit der Beschränkung, die nur Google aufheben könnte.

Man kann NetGuard allerdings mit dem Tor-Netzwerk kombinieren. Wie sinnvoll das im Einzelfall ist, muss jeder für sich selbst entscheiden. Generell ist davon eher abzuraten. Dennoch möchte ich kurz aufzeigen, wie der Datenfluss in Kombination mit einem SOCKS5-Proxy aussieht:

Datensendende App-> Android VPN-Dienst -> NetGuard -> SOCKS5-Proxy -> Internet

Ohne den SOCKS5-Proxy ist der Datenfluss wie folgt:

Datensendende App-> Android VPN-Dienst -> NetGuard -> Internet

5.3 Google voreingestellt

Unter Einstellungen -> Erweiterte Optionen sollte der NetGuard Verbindungstest angepasst werden. Standardmäßig prüft NetGuard auf eine bestehende Internetverbindung über die Adresse www.google.com:

Validate at: www.google.com

Ihr könnt dort bspw. die Adresse captiveportal.kuketz.de hinterlegen.

6. Fazit

NetGuard ermöglicht die Filterung von ausgehendem Datenverkehr. Gerade für Apps, die aus dem Google Play Store stammen, ist dies eine unverzichtbare Funktion für alle datenschutzsensiblen Nutzer und Kontrollfreaks, die keine (personenbeziehbaren) Daten an Drittparteien wie Tracking- oder Werbeanbieter weitergeben möchten. Wer NetGuard dann mal ein paar Tage genutzt hat, der wird vermutlich erstaunt/erschrocken darüber sein, wie viele unnötige und rechtswidrige Datenverbindungen von Apps initiiert werden.

Nehmt euch doch mal die Zeit und prüft, welche Tracker- und Werbemodule eure verwendeten Apps integriert haben. Das geht ganz einfach mit Exodus Privacy. Kopiert von einer App einfach die URL aus dem Play Store in das Suchfeld und klickt auf Perform analysis. Der DB Navigator hat bspw. 7 Tracker integriert.

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡

Ähnliche Beiträge

2. November 2017

NetGuard Firewall – Android unter Kontrolle Teil4

Mit der No-Root Firewall NetGuard lassen sich Tracking- und Werbeanbieter gezielt filtern.

3. März 2022

Pi-hole, AdAway, NetGuard und Co.: Wie DNS-Blocking mit speziellen Domains leicht umgangen werden kann

Mein Toot über individuelle bzw. für Tracking-Kunden zugeschnittene Domains hat Verwirrung und Besorgnis hervorgerufen: Blocking von Werbe- und Tracking-Domains auf DNS-Ebene…

11. April 2022

DB Navigator: Datenschutz fällt heute aus – App-Check Teil1

Die Analyse des DB Navigators offenbart eklatante Verstöße gegen die DSGVO und das TTDSG. Ist das Vorsatz oder Unfähigkeit?

1. Oktober 2021

AdGuard Pro: Tracking und Werbung unter iOS unterbinden

AdGuard Pro kann der Auslieferung von (schädlicher) Werbung und dem Abfluss von persönlichen Daten an zweifelhafte Drittanbieter einen Riegel vorschieben.

5. Oktober 2021

DB Navigator: Ein Fall für die Datenschutz-Aufsichtsbehörde

Der zweite Test der App-Aktionswochen befasst sich mit der Android- und iOS-App DB Navigator (Version 21.06.p04.00/21.06.15). DB Navigator ist eine…

Weitere Themen

AndroidAuditAutonomieBackupBezahlenBrowserCloudDatenschutzDatensendeverhaltenDigitalpolitikDSGVOE-MailFirewallHackingHärteniOSKuketz-BlogLinuxmacOSMessengerOpenWrtPasswortPentestRaspberryPiRechtSicherheitslückeSicherheitsmaßnahmeTorTrackingTTDSGÜberwachungVerschlüsselungWindowsWordPressXMPP

---

Diskussion

4 Ergänzungen zu “NetGuard: Datenverkehr von Android-Apps filtern – Privatsphäre schützen”

1. qwielax sagt:

   14. März 2022 um 21:16 Uhr

   Kurze Ergänzung zum Thema Split Screen für neuere Android Versionen (die oben verlinkte Anleitung stimmt dort nicht mehr):

   In der Übersicht der geöffnet Apps auf das runde App-Symbol drücken und dort Split Screen auswählen.

   Habe selber gerade ein Weilchen gebraucht bis ich es endlich gefunden habe. Vielleicht hilft es ja anderen, die die Funktion auch noch nicht kannten.

2. toystory sagt:

   17. März 2022 um 09:26 Uhr

   Für manche, aber nicht alle dieser individuellen Subdomains erwischt man über CNAME Auflösung den darunter liegenden Host und kann sie dennoch blocken.
   Leider sind manche Seiten schon weiter und lösen die Tracking Subdomain schon direkt in die IP-Adresse auf
   data-X.beispiel.de ist dann kein Alias mehr für tracking.relay.iocnt.net sondern nur noch ein normaler A record.
   Da würde man es nur erkennen weil das TLS Zertifikat für einen Tracking Host auch gültig ist.
   Es wird schwierig bleiben.

   • JobcenterTycoon sagt:

     18. März 2022 um 22:20 Uhr

     Manche packen die tracking Subdomain auch hinter eine reverse Proxy wie Cloudflare damit man die nicht so schnell finden und blockieren kann. Als IP Adresse taucht dann logischerweise nur die Proxy IP Adresse auf die von tausenden anderen Diensten auch verwendet wird daher ist IP blocking auch nicht immer sinnvoll.

3. feraal sagt:

   20. März 2022 um 18:53 Uhr

   Ich möchte auf Punkt 51 der FAQ hinweisen. Der Punkt ist m. E. etwas kryptisch, bedeutet aber, dass für manche LineageOS Versionen (z. B. klte, 18.1) die IP-Filterung nicht funktioniert, was man im Zweifelsfall erst nach der Freischaltung der entsprechenden Pro-Funktion feststellt.

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-Forum

Abschließ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.