1. Ausgeschnüffelt
Datensammlern wie Google, Facebook und Co. begegnet man laut der Studie »Online Tracking: A 1-million-site Measurement and Analysisauf« auf fast jeder Webseite. Insbesondere Google ist mit über 80% Verbreitung schon fast mit einem »Krebsgeschwür« vergleichbar. Hintergrund dieser hohen Verbreitung ist meist die Bequemlichkeit von Seitenbetreibern, die externe Ressourcen wie JavaScript oder Schriftarten gerne über Drittanbieter einbinden.
Um Datensammlern wie Google oder Facebook zu entgehen, gibt es unterschiedliche Möglichkeiten. Die meisten von euch verwenden vermutlich einen Adblocker wie uBlock Origin oder einen Pi-Hole, um Tracker wie Google Analytics oder den Facebook Like-Button zu blockieren. Eine weitere, äußerst effektive Methode ist das Blockieren von IP-Adressbereichen, auf der Basis von AS-Nummern, wie im Beitrag Google und Facebook IP-Adressen blockieren aufgezeigt.
Im dritten Teil der IPFire-Artikelserie möchte ich euch ein Skript vorstellen, mit dem sich ganze IP-Adressbereiche von Datensammlern blockieren lassen. Bonus: Das Skript lässt sich ebenfalls in Kombination mit iptables auf einem GNU/Linux-Rechner oder der AFWall+ auf Android anwenden. Es ist daher nicht nur für IPFire-User von Interesse.
- Hardware und Netzwerkaufbau – IPFire Teil1
- DNS-Adblocker Skript für IPFire – IPFire Teil2
- ASN-Skript: Datensammler haben ausgeschnüffelt – IPFire Teil3
- Windows unter Kontrolle – IPFire Teil4
2. Das Problem: Einbindung externer Ressourcen
Den Grund, weshalb wir zur »Holzhammermethode« greifen und ganze IP-Adressblöcke von Anbietern wie Google oder Facebook sperren, möchte ich nachfolgend kurz am Beispiel von Webseiten skizzieren. Wer keinen Wert auf das »Warum« legt, der kann auch gleich zu Ziffer 3 springen.
Das Einbinden externer Ressourcen auf Webseiten verfolgt meist unterschiedliche Ziele. Für viele Webseitenbetreiber ist es schlichtweg »bequem« eine JavaScript-Bibliothek von einer externen Quelle einzubetten, als sich selbst die Mühe zu machen, die für die Funktionalität der Webseite benötigen Ressourcen selbst zu hosten. Insbesondere Webentwicklern wird die Erstellung und Anpassung von Webseiten, durch die Verwendung von vorgefertigten JavaScript-Bibliotheken und entsprechende Frameworks, erleichtert. Zu den bekanntesten Vertretern zählen jQuery, AngularJS oder die MooTools. Auch in diesem Fall werden die notwendigen JavaScript-Bibliotheken, meist aus Bequemlichkeit, über die jeweiligen Frameworks von Drittquellen eingebunden.
Angesichts dieser zunehmend angewandten Praxis, scheint den Webseitenbetreibern nicht bewusst zu sein, welches Risiko, für Sicherheit und Privatsphäre, mit der Einbindung externer Ressourcen einhergeht. Laut der Studie »Exposing the Hidden Web: An Analysis of Third-Party HTTP Requests on One Million Websites« zählen die folgenden extern eingebunden Ressourcen zu den am häufigsten verwendeten:
- JavaScript: JavaScript ist eine Skriptsprache, die es erlaubt HTML-Dokumente während der Anzeige im Browser dynamisch zu verändern, Benutzerinteraktionen auszuwerten oder neue Inhalte nachzuladen. Zu den typischen Anwendungsgebieten von JavaScript zählen unter anderem die Datenvalidierung von Formulareingaben, Anzeige von Dialogfenstern oder die Anzeige von Suchvorschlägen während der Eingabe. JavaScript ist nicht per se unsicher, wird aber immer wieder kontrovers diskutiert, da die meisten der bekannt gewordenen Sicherheitslücken in Browsern oftmals eng mit JavaScript verknüpft sind. Leider wurde und wird JavaScript zunehmend für das Fingerprinting von Nutzern »missbraucht«, das ein seitenübergreifenden Tracking ermöglicht. In der Studie »(Cross-)Browser Fingerprinting via OS and Hardware Level Features« wird aufgezeigt, dass sich über bestimmte Merkmale wie die verwendete Bildschirmauflösung, Farbtiefe, im Browser installierter Plugins oder Schriftarten, Besucher zu 99,24 % wiedererkennen lassen / seitenübergreifend Tracken.
- Bilder: Insbesondere Bilder werden häufig von Drittseiten zur Auslieferung von Werbung eingebunden oder als »unsichtbare« Web-Bugs missbraucht, die gerne im Bereich des Online-Marketing zum Einsatz kommen, um den Besucher einer Webseite zu tracken.
- Schriften: Moderne Browser unterstützen heute das Nachladen von Schriftarten von Webseiten oder Drittquellen, meist mit dem Ziel, browser- und betriebssystemübergreifend ein einheitliches Aussehen zu erreichen. Aus Bequemlichkeit werden diese Schriften allerdings meist nicht von der aufgerufenen Webseite ausgeliefert, sondern von Drittanbietern (Google Fonts) eingebunden.
Welche Risiken, insbesondere mit der externen Einbindung von JavaScript, für die Sicherheit und die Privatsphäre eines Webseitenbesuchers einhergeht, möchte ich kurz aufzeigen.
2.1 Externes JavaScript: Ein »Autsch« für Sicherheit und Privatsphäre
Die Einbindung von (externem) JavaScript verfolgt meist unterschiedliche Ziele. Zu den häufigsten Anwendungsszenarien zählen mitunter das User-Tracking und die Auslieferung von Werbung. Insbesondere die Möglichkeit des »seitenübergreifenden Trackings« hat sich dadurch verbreitet, dass Webseitenbetreiber die Erfassung und Auswertung ihrer Besucher nicht mehr selbst durchführen (wollen), sondern auf externe Dienstleister zurückgreifen, die ihnen diese Arbeit »abnehmen«. Das »Outsourcing« der Besucheranalyse macht es allerdings vielfach notwendig, dass ein Webseitenbetreiber externe JavaScript-Bibliotheken einbindet, die das Besucherverhalten erfassen und analysieren.
Die Einbindung dieser externen Ressourcen ist für den Webseitenbetreiber meist bequem und mit wenig Aufwand verbunden, weshalb sich diese Praxis allgemein durchgesetzt hat. Ein weiterer Vorteil externer Tracking-Anbieter stellt die meist kostenlose Nutzung für einen Webseitenbetreiber dar, der im Gegenzug mit den Daten seiner Besucher »bezahlt«. Durch die Einbindung externer Dienstleister in eine Webseite geht ein Webseitenbetreiber allerdings eine »Vertrauensbeziehung« ein, ohne sich womöglich mit der daraus resultierenden Tracking-Problematik bzw. der Aufzeichnung sensibler Informationen durch Dritte ausreichend auseinandergesetzt zu haben.
Aber nicht nur hinsichtlich der Privatsphäre kann die Einbettung von »fremdem« JavaScript-Code negative Auswirkungen haben, sondern sowohl auf die Verfügbarkeit, als auch auf die Sicherheit des Webseitenbetreibers und insbesondere seiner Besucher:
- Verfügbarkeit: Angenommen ein Seitenbetreiber hat einen Bilder-Slider in seine Webseite über die Domain »example.de/slider.js« eingebunden. Falls nun die Domain, über die das JavaScript eingebunden wird, aus irgendwelchen Gründen nicht erreichbar ist, wird die Einbindung des Bilder-Sliders fehlschlagen. Als Folge ist die Webseite für einen Besucher möglicherweise nicht benutzbar, da über die Einbindung des externen JavaScripts wichtige Funktionen abgebildet werden. Das Einbinden kann sich allerdings nicht nur auf die Benutzbarkeit negativ auswirken, sondern ebenfalls auf die Geschwindigkeit des Seitenaufbaus. Jede Ressource, die von einer externen Domain / Quelle nachgeladen wird, bedeutet, dass der Browser eine Verbindung initiiert und die Ressource von dort »abholt«. Dieser Vorgang ist vergleichsweise langsamer, als wenn der Seitenbetreiber die Ressource bzw. das JavaScript lokal von seinem Webserver anbieten würde.
- Sicherheit: Weitaus gravierendere Folgen, insbesondere für die Sicherheit eines Besuchers, können allerdings dadurch entstehen, wenn sich ein Webseitenbetreiber »blind« auf den Drittanbieter verlässt. Man sollte sich vor Augen führen, dass der Betreiber von »example.de« jederzeit Änderungen an der JavaScript-Datei vornehmen kann oder möglicherweise »gehackt« wird. Eine böswillige Veränderung von JavaScript-Code kann unter anderem dazu »missbraucht« werden, um Cookies aus dem Kontext einer Webseite zu stehlen oder die Login-Daten (Benutzernamen & Passwort) abzugreifen. Für diesen Vorgang benötigt ein Angreifer noch nicht einmal Zugang zur Webseite des Betreibers, sondern einzig zum JavaScript, das er entweder selbst kontrolliert oder entsprechend beim Drittanbieter modifiziert hat. Fatal ist, dass der Webseitenbetreiber von dieser Veränderung meist nichts »mitbekommt« und somit eine »Vertrauensbeziehung« zum Anbieter eingeht, die insbesondere seinen Besuchern extrem Schaden kann.
Webseitenbetreiber, denen die Sicherheit und Privatsphäre ihrer Besucher am Herzen liegt, sollten daher prüfen, ob die Einbindung von externen JavaScript-Ressourcen zwingend erforderlich ist oder ob die Einbindung auch lokal über die eigene Domain erfolgen kann.
Hinweis
Wer prüfen möchte, welche externen Inhalte bzw. Ressourcen Webseiten einbinden, der kann dies mit Webbkoll tun.2.2 Weitere Gedanken zur Thematik
Dieser kurze »Ausflug« sollte euch für die Problematik sensibilisieren, weshalb es durchaus sinnvoll sein kann, komplette IP-Adressbereiche von Anbietern zu blockieren, die es insbesondere mit der Privatsphäre eines Nutzers nicht sehr genau nehmen bzw. daraus sogar Kapital schlagen. Genauer gesagt möchten wir verhindern, dass externe Ressourcen von Anbietern wie Google oder Facebook auf Webseiten oder innerhalb von Apps nachgeladen werden, die dafür bekannt sind, das Nutzerverhalten zu tracken.
Das komplette Sperren von IP-Adressblöcken zählt gewiss zur »Holzhammermethode«, die dazu führen kann und auch wird, dass Webseiten nicht mehr funktionieren oder Smartphone-Apps den Dienst versagen. Ihr solltet daher bereit sein, Webseiten, die nicht mehr funktionieren, bspw. über den Tor-Browser aufzurufen und euch Apps zu suchen, die bspw. auch ohne das Nachladen von Google-Bibliotheken problemlos funktionieren. Solche Apps könnt ihr insbesondere im F-Droid Store finden. Wie ihr komplett ohne Google auskommt könnt ihr im Beitrag »Tschüss Datenkrake: Ein Leben ohne Google« nachlesen.
Hinweis
In einem gesonderten Beitrag werde ich demnächst aufzeigen, welche weiteren Risiken für Sicherheit und Privatsphäre mit der Einbindung externer Ressourcen einhergeht. Ein Beitrag, der sicherlich nicht nur für Nutzer von Interesse sein dürfte, sondern insbesondere für Webseitenbetreiber, die sich Gedanken um eine sicheren und datenschutzfreundlichen Webauftritt machen.3. ASN-Skript: Die Holzhammermethode
Mitte April diesen Jahres habe ich mir ein Bash-Skript gebastelt, dass auf Basis von ASN-Informationen iptables Blocking-Regeln (IPv4) für ausgewählte Unternehmen generiert. Nach ein paar Anpassungen veröffentlichte ich das Skript anschließend für IPFire-User. Seither sind ein paar Monate vergangen und ein Leser (maloe) aus dem Kuketz-Blog XMPP-Konferenzraum hat das ursprüngliche Skript weiter angepasst, optimiert und verbessert. Er hat aus dem Skript sozusagen ein »Schweizer-Taschenmesser« gemacht, mit dem es möglich ist, Blocking-Regeln für die IPFire, iptables und die AFWall+ zu generieren.
Seit Juli 2017 hat das Skript ein online zu Hause auf NotABug bekommen. Wer in Zukunft also bspw. Fehler findet, Verbesserungsvorschläge einreichen möchte oder ein Problem melden möchte, der findet dort eine entsprechende Anlaufstelle.
3.1 Was macht dieses Skript nun?
Das Ziel unseres Skripts ist die automatische Generierung von IP-basierten Blocking-Regeln für Unternehmen, mit denen ihr nicht in »Berührung« kommen wollt. Die Frage ist nun, wie man eine möglichst vollständige Liste aller IP-Adressblöcke bekommt, die zu einem Unternehmen wie Google oder Facebook gehören. Typischerweise haben ISPs, aber auch große internationale Unternehmen, eigene AS-Nummern (ASN). Hinter solch einem autonomen System (AS) verbirgt sich eine Ansammlung von IP-Netzen, welche bspw. über das interne Routing-Protokoll (IGP) miteinander verbunden sind. Internationale Unternehmen wie Google oder Facebook haben ihre eigenen ASNs, wo im Idealfall alle zugehörigen IP-Netze registriert sind.
Das Skript holt sich also auf Basis von ASN-Informationen automatisiert alle zu Google oder Facebook gehörigen IP-Adressblöcke und erstellt daraus Netzwerkobjekte und Gruppen, die sich anschließend in der IPFire GUI als Blocking-Regeln (Verweigern (REJECT)) einbinden lassen. Über entsprechende Optionsparameter des Skripts lassen sich allerdings nicht nur Blocking-Regeln für die IPFire erzeugen, sondern ebenfalls für iptables oder AFWall+.
Als Quelle für die ASN-Informationen nutzt das Skript unterschiedliche Ressourcen, die sich auch erweitern lassen:
- Registrierte ASN: Um alle ASN abzufragen, die von einem Unternehmen registriert wurden, eignet sich der Online-Dienst CIDR-Report (Beispiel Facebook)
- IP-Adressblöcke zu einem ASN: Zu jedem ASN lassen sich dann, bspw. über RIPEstat, die dazugehörigen IP-Adressblöcke ausgeben
Dieser Vorgang wird vom Skript automatisch für alle jene Unternehmen ausgeführt, die ihr dem Skript als Parameter übergebt. Allerdings funktioniert das nur für Unternehmen, die eine gewisse Größe haben und international tätig sind. Ihr werdet also nicht für jedes Unternehmen Blocking-Regeln erzeugen können.
Hinweis
In der aktuellen Version des Skripts werden ausschließlich Blocking-Regeln für IPv4-Adressen generiert. Über IPv6 könnten demnach weiterhin Verbindungen zu Google oder Facebook initiiert werden. Solltet ihr das Skript also nutzen wollen, ist es sinnvoll, IPv6 in eurem Betriebssystem oder Router zu deaktivieren.3.1 IPFire
Die Installation bzw. die Nutzung des Skripts auf der IPFire ist denkbar einfach und binnen weniger Minuten erledigt. Loggt euch zunächst mittels SSH auf eure IPFire ein und führt anschließend folgende Befehle aus:
cd ~ curl -O https://notabug.org/maloe/ASN_IPFire_Script/raw/master/asn_ipfire.sh chmod 755 asn_ipfire.sh
Ruft anschließend die Hilfefunktion auf, um euch alle Parameter anzeigen zu lassen, die vom Skript unterstützt werden:
bash asn_ipfire.sh --help
Ausgabe der Hilfe:
Usage: asn_ipfire.sh [OPTION] [COMPANYs | -f FILE]
Add or remove networks to IPFire firewall Groups: Networks & Host Groups
Options:
-a, --add Add new company networks
-r, --remove Remove company networks from customnetworks & customgroups
COMPANY='ALL' to remove all entries done by this script
-f, --file FILE Get company list from FILE
-l, --list List entries done by this script
--renumber Renumber lines of customnetworks & customgroups files
-h, --help Show this help
Create special output files (Non-IPFire-Mode):
--network Create FILE 'network_list.txt' with networks
--network_raw dito, but networks not consolidated
--asn Create FILE 'asn_list.txt' with ASNs only
--iptable Create FILE 'iptable_rules.txt' with iptable rules
--afwall Create FILE 'afwall_rules.txt' with afwall rules
COMPANY to be one or more company names, put into double quotes ('"')
Multi company names can be comma or space separated
usage example: asn_ipfire.sh -a "CompanyA,CompanyB,CompanyC"
asn_ipfire.sh --asn "CompanyA,CompanyB,CompanyC"
FILE = name of a file, containing one or more company names.
Company names to be separated by space or line feeds.
usage example: asn_ipfire.sh -u -f company.lst
asn_ipfire.sh --network -f company.lst
Notes:
Company names are handled case insensitive.
Only entries made by asn_ipfire.sh are updated or removed.
These entries are recognized by the 'Remark'-column in IPFire.
Mit folgendem Aufruf generiert ihr Netzwerkobjekte und Gruppen, für die Unternehmen Google, Facebook, Twitter, Oracle und Acxiom, die sich anschließend in der IPFire GUI als Blocking-Regeln (Verweigern (REJECT)) einbinden lassen:
bash /root/asn_ipfire.sh --add "Google,Facebook,Twitter,Oracle,Acxiom"
Insbesondere Google, Facebook, Twitter und Oracle zählen zu den Unternehmen, die laut der Studie »Online Tracking: A 1-million-site Measurement and Analysis« auf mehr als 10% der Webseiten vertreten sind. Präziser:
- Google: Auf über 80% aller untersuchten Webseiten
- Facebook: Auf knapp 40% aller untersuchten Webseiten
- Twitter: Auf knapp 20% aller untersuchten Webseiten
- Oracle: Auf über 10% aller untersuchten Webseiten
Persönlich habe ich keine Berührungspunkte mit diesen Unternehmen, möchte also keine Services in Anspruch nehmen und möchte im Gegenzug auch nicht, dass diese Unternehmen Daten von mir erhalten. Das kann ich natürlich nur eingeschränkt kontrollieren – eben über die Blockade jeglicher IP-Adressen, die zu den Unternehmen gehören.
Öffnet nach der Ausführung des Skripts die GUI der IPFire und navigiert dort unter »Firewall -> Firewallgruppen -> Netzwerke«. In der nachfolgenden Abbildung könnt ihr sehen, dass die IP-Adressblöcke der Unternehmen bereits als Netzwerkobjekte angelegt sind:
Analog fasst das Skript jedes Unternehmen (alle IP-Adressblöcke) als Gruppe unter »Firewall -> Firewallgruppen -> Netzwerk-/Hostgruppen« zusammen:
Das Skript erledigt sozusagen die »Vorarbeit« und legt sowohl Netzwerkobjekte, als auch Gruppen an, die ihr dann nach belieben in eure Regelsätze einbauen könnt. Damit jeglicher Kontakt von euren Geräten / Netzen zu Google, Facebook, Twitter, Oracle und Acxiom unterbunden wird, könnt ihr folgende Regelsätze anlegen:
Wie ihr auf der Abbildung erkennen könnt, sind die Blocking-Regeln gleich am Anfang des Regelwerks gesetzt und werden als erstes abgearbeitet. Bei einem Treffer bekommt euer Client dann ein REJECT (Ablehnen) von der IPFire übermittelt, was für den Client bedeutet, dass das Ziel nicht erreichbar ist. Solch eine REJECT-Regel könnt ihr folgendermaßen unter »Firewall -> Firewallregeln -> Neue Regel erstellen« anlegen:
- Quelle: Wählt dort die entsprechenden Hosts, Gruppen oder Netze, denen ihr den Zugriff auf Unternehmen wie Google nicht erlauben wollt
- Ziel: Wählt dort das Unternehmen aus, das ihr blockieren möchtet. Das Skript hat bereits eine Gruppe (pro Unternehmen) angelegt, die ihr für diesen Zweck auswählen könnt
- Protokoll: Dort wählt ihr »Alle« und selektiert »Verweigern (REJECT)«
- Weitere Einstellungen: Damit ihr die Regel nicht ganz nach oben schieben müsst, könnt ihr als Regelposition die »1« vermerken und anschließend auf »Hinzufügen« klicken
Wenn ihr anschließend in einem Browser die Adresse »www.google.de« oder »www.facebook.com« aufruft, wird euch der Browser melden, dass die Adresse / Host nicht erreichbar ist. Mission accomplished!
Die IP-Adressblöcke sollten über das Skript regelmäßig aktualisiert werden. Über fcrontab könnt ihr das Updateverhalten auf der IPFire steuern:
fcrontab -e
Legt dort einen neuen Eintrag an, um bspw. jeden Tag um 23:35 Uhr das Skript auszuführen:
# 23 Uhr # Update ASN network information 45 23 * * * bash /root/asn_ipfire.sh --add "Google,Facebook,Twitter,Oracle,Acxiom" > /dev/null 2>&1
Das war es schon. Auf Wunsch könnt ihr weitere Unternehmen hinzufügen, entfernen oder über die »Remove-Funktion« auch alles wieder rückgängig machen:
bash /root/asn_ipfire.sh --remove ALL
3.2 iptables
Mit Hilfe des Skripts lassen sich nicht nur Netzwerkobjekte und Gruppen für die IPFire generieren, sondern auch Regelsätze, die ihr überall dort verwendet könnt, wo eine iptables-Firewall werkelt. Über einen zusätzlichen Parameter »–iptable« werden die Blocking-Regelsätze direkt in eine Text-Datei geschrieben, die ihr anschließend in eure iptables einbinden könnt. Am Beispiel von Facebook werde ich das kurz darstellen:
bash asn_ipfire.sh --iptable "Facebook"
Das Skript generiert anschließend entsprechende Blocking-Regeln und schreibt diese in die Datei »iptable_rules.txt«:
Company: Facebook /sbin/iptables -A OUTPUT -d 31.13.24.0/21 -j REJECT /sbin/iptables -A OUTPUT -d 31.13.64.0/18 -j REJECT /sbin/iptables -A OUTPUT -d 45.64.40.0/22 -j REJECT /sbin/iptables -A OUTPUT -d 66.220.144.0/20 -j REJECT /sbin/iptables -A OUTPUT -d 69.63.176.0/20 -j REJECT /sbin/iptables -A OUTPUT -d 69.171.224.0/19 -j REJECT /sbin/iptables -A OUTPUT -d 74.119.76.0/22 -j REJECT /sbin/iptables -A OUTPUT -d 103.4.96.0/22 -j REJECT /sbin/iptables -A OUTPUT -d 157.240.0.0/17 -j REJECT
Die Datei könnt ihr anschließend in euer bestehendes iptables Firewallregelwerk einbinden. Fortan werden jegliche Verbindungen zu Facebook und den dort gehosteten Diensten blockiert.
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.3 AFWall+
Das Skript kann allerdings nicht nur Blocking-Regeln für iptables erzeugen, sondern auch für die beliebte Android Firewall AFWall+. Voraussetzung für die Generierung der Regeln ist ein Bash-Interpreter, der bei jedem GNU/Linux-System zum Standard zählt. Auch unter MacOS solltet ihr das Skript ohne Probleme ausführen können. Viele Android-User nutzen womöglich allerdings als Hauptsystem Windows und können das Skript nicht direkt ausführen und sich die Regeln erzeugen lassen. Unter Windows ist die Installation von Cygwin notwendig, um das Bash-Skript auszuführen. Ab Windows 10 benötigt ihr Cygwin nicht mehr und könnt Bash-Skripts direkt über die Kommandozeile ausführen.
Über einen zusätzlichen Parameter »–afwall« werden die Blocking-Regelsätze direkt in eine Text-Datei geschrieben, die ihr anschließend in eure AFWall+ einbinden könnt. Am Beispiel von Facebook werde ich das kurz darstellen:
bash asn_ipfire.sh --afwall "Facebook"
Das Skript generiert anschließend entsprechende Blocking-Regeln und schreibt diese in die Datei »afwall_rules.txt«:
## Company: 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
Die Blocking-Regeln könnt ihr dann in euer bestehendes CustomScript der AFWall+ integrieren. Fortan werden jegliche Verbindungen zu Facebook und den dort gehosteten Diensten blockiert.
4. Fazit
Ungewollte Verbindungen zu Google, Facebook und Co. während des Surfens im Internet oder der Nutzung einer App gehören mit dem ASN-Skript der Vergangenheit an. Diese Holzhammermethode ist vielleicht nicht besonders elegant und auch reichlich brachial, aber auch ziemlich effektiv. Allerdings werdet ihr in der Praxis feststellen, dass etliche Seiten nicht mehr einwandfrei funktionieren, da sie externe Ressourcen (bspw. Google APIs, Fonts, JavaScript, etc.) über Drittanbieter eingebunden haben. Da bleibt euch nur der Workaround über den Tor-Browser oder das Browser-Plugin Decentraleyes.
Wunder kann das Skript aber natürlich keine vollbringen. Es verhindert lediglich, dass eure Geräte eine Verbindung mit Unternehmen aufnehmen, die ihr aus irgendwelchen Gründen ablehnt. Wenn jemand allerdings eure Adresse in seinem Smartphone speichert und sein Adressbuch anschließend mit Google synchronisiert, dann landen eure Daten wiederum bei einem Datensammler. Vor diesem leichtsinnigen Umgang mit euren Daten seid ihr natürlich nicht gefeit.
Bildquellen:
Dog: Freepik from www.flaticon.com is licensed by CC 3.0 BY
Ü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
AFWall+: Wie ich persönlich die Android-Firewall nutze
F-Droid und AFWall+ – Android ohne Google?! Teil4
Hardware und Netzwerkaufbau – IPFire Teil1
DNS-Adblocker Skript für IPFire – IPFire Teil2
18 Ergänzungen zu “ASN-Skript: Datensammler haben ausgeschnüffelt – IPFire Teil3”
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.
Ich danke – mal wieder – für diesen informativen Bericht!
Auf „https://mailbox.org/anmelden“ steht seit Längerem u.a.:
Übrigens: ReCaptcha hilft Google beim Identifizieren u.a. von ansonsten nicht lesbaren Fotos von Hausnummern etc. Das war jedenfalls mal so.
Meine Frage ist aber: Kann es sein, dass sein, dass Mailbox.org hier zuviel Google-Begeisterung zeigt?
Schließlich wird Google das Recht eingeräumt in meinem Browser deren JavaScript-Datei auszuführen. Ohne die Erlaubnis von meiner Seite („NoScript“-FF-Addon), funktioniert es nicht.
Wenn ich also aber erlaube, kann Google evtl. sogar mein Login und Passwort auslesen, was ich ja auf derselben Seite eintrage?
Jedenfalls erfährt Google meine IP zum Zeitpunkt xy und kann evtl. sogar einen Fingerprint machen?
Egal, auch schon mit der IP und einer nachfolgenden Google-Suche oder gar einem Eingelogged-Sein in einem Googledienst bin ich durch identifizierbar, obwohl ich gerade eine besonders geschützte Emailadresse anlegen will?
Danke.
Ja, Mailbox.org ist sich dieser Problematik schon sehr, sehr lange sehr, sehr bewusst …. ;-)
Ja, weil homberfc Noscript benutzt, das leider keine seiten- bzw. domain-spezifischen Regeln erlaubt (es sei denn, man bastelt sich solche sehr umständlich in ABE).
Mike, ein interessanter Artikel, wieder etwas dazu gelernt. Allerdings schreibst du ja selbst von einer Holzhammermethode. Das sehe ich auch so, da das Gleiche erheblich einfacher und gleichzeitig flexibler mit dem Dynamischen Filtern in uBlock Origin und/oder den domain-spezifischen Geltungsbereichen in uMatrix zu erreichen ist und gleichzeitig leicht Ausnahmen zu definieren sind.
Ja, aber vergiss nicht: Nur im Browser-Kontext!
Es gibt neben dem Browser allerdings noch weitere Geräte / Anwendungszwecke, bei denen man kein Browser-Addon nutzen kann. Smart-TV, Smartphone-Apps und weitere Geräte mit Internetanbindung im Haushalt. Hier helfen dann Dinge wie der Pi-hole oder eben das vorgestellte ASN-Skript.
Aber klar: Das ist die Holzhammermethode für die ganz harten. ;-)
Um zu sehen, auf welchen Wegen und was eine Webseite nachlädt, ist dieses Tool hilfreich:
https://urlquery.net/
Gruß Wolf
Oder Webbkoll.
Hi Herr Kuketz, wie immer ein Wachmacher-Artikel, danke!
Aber was ist mit den Personen, die keinen „Holzhammer“ verwenden können, also die 99% Schwachen unter uns (wie ich ;)
Können die Addons „Decentraleyes“ und „Requestpolicy“ die Schnüfflerei ein wenig begrenzen, weil besonders letzteres IP-Verbindungen z.B. nach Google/Facebook für jede einzelne Seite regeln kann?
Gruß RedBlue
Der »Durchschnittsnutzer« fährt mit einer Kombination aus Pi-hole, uBlock Origin und diesen Addons für Firefox ganz gut. Daneben ist auch noch Decentraleyes zu erwähnen.
Wer spurenarm im Internet surfen möchte, der sollte einen Blick auf die Artikelserie »Not my data!« werfen.
Hi, ich habe mal eine generelle Frage zu der Thematik: Ich habe schon oft gelesen das individuelle Whitelists das Tracking quasi vereinfachen. Also ist doch das blockieren auf Netzebene schlecht, weil so alle Geräte im gleichen Netz getrackt werden können?
Das ist übrigens auch ein Grund weshalb Tor AdBlocker nicht integriert.
Ist halt die Frage wer das Tracken übernehmen soll, falls Google und Co. keine Daten mehr bekommt. ;-)
Beim Tor-Browser wird es insbesondere deshalb gemacht, um den Fingerprint des Tor-Browsers möglichst identisch zu halten. Wenn Filterlisten hinzukommen, dann besteht die Gefahr, dass Anwender dort eigene einpflegen, veraltete nutzen oder Änderungen vornehmen. Das würde den Fingerprint verändert, sobald JavaScript ins Spiel kommt.
Super! Danke für diesen Artikel. Als Normaluser steigt man allerdings bald aus, da alles sehr technisch erscheint. Hast Du die Kontakte, dass sich einer erbarmt und ein plattformübergreifendes Tool schreibt, mit dem per GUI gesteuert werden kann? Dann würde ich auch damit arbeiten können.
Hi Caroline,
hier auf dem Blog sind eben viele Themenbereiche vertreten. Dieser Beitrag richtet sich eher an die Nerds bzw. Kontrollfanatiker, die mit GNU/Linux bzw. iptables arbeiten. Der Durchschnittsnutzer sollte eher Addons wie uBlock Origin oder den Pi-hole einsetzen und von solchen Methoden eher absehen – da geht am Ende mehr schief, als das es einen Nutzen bringt.
Wie kann man mit uBlock Origin Google und Facebook komplett aussperren? Bin auch kein Nerd und wäre auch an einem Tool interessiert, das alles kann, was einem Nichtnerd die Möglichkeinen einräumt, die im Blog genannt werden. Dafür würde ich auch Geld ausgeben. Scheint eine Marktlücke zu sein. Was sollte es können: Windows und Android schnüffelsicher. Zwickmühle zwischen Orboteinstellungen und AFWall+, IPTables, DNS Einstellungen lösen, Scripte wie hier beschrieben per GUI einstellbar, gute Idee Caroline.
So was wäre bei Computer**ld-Leserniveau ein Bestseller. Könnte z.B. tech. eng. „Maul“ heißen =“schwerer Holzhammer“. Oder „Halts M.“ :-)
Wenn du uBlock Origin so wie hier vorgestellt einstellst, dann wird das meiste von Google blockiert und Facebook eigentlich komplett. Weiterhin hilfreich, aber erstmal schwer zu bedienen: uMatrix.
Ein Tool, wie ihr euch das wünscht, wird es vermutlich nie geben. ;-)
Hallo zusammen, ich bekomme beim Ausführen unter Debian immer folgende Fehlermeldung und die .txt ist im Anschluss leer.
Hat jemand eine Idee?
Dir fehlt offensichtlich curl:
Vielen Dank für den interessanten Beitrag vom Typ „Holzhammer“!
Beim Ausperren von Google bin ich gleich in eine Falle getappt, die evtl. auch Andere trifft:
– Android Smartphones (auch solche ohne Google-Dienste-Framework) prüfen die Internet-Connectivität einer WLAN Verbindung durch den Aufruf einer speziellen Seite (von Google…), die den Status-Code 204 zurückliefert.
– Blockiert man nun im Heimnetz zentral alle Google-IPs, so schlägt dieser Aufruf fehl. Android erkennt dies und wechselt automatisch auf die mobile Datenverbindung. Damit sind alle Sicherheitsmechanismen auf der IPFire umgangen :-(
Lösungsmöglichkeiten:
– Deaktivieren der mobilen Datenverbindung
– Umleiten der Anfrage an einer eigenen Server (ziemliche Trickserei)
Geht es evtl. auch einfacher?
Gibt es: Android: Captive Portal Check deaktivieren