Zentrales Ad-Blocking mit dem Pi-hole - Ein Erfahrungs- und Testbericht

    Auch wenn dies ein Forum zum Thunderbird und nicht zum Thema Browser ist, möchte ich für Interessierte einen Erfahrungsbericht zum zentralen Ad-Blocker Pi-hole abgeben. Die Betonung liegt auf Erfahrungsbericht. Ich erhebe nicht den Anspruch auf eine vollständige Darstellung.

    Zunächst für diejenigen, die diese Software bisher nicht kennen:

    Was ist Pi-hole?

    Pi-hole ist ein Blocker für Werbung, Tracker und bekannte Malware-Seiten. Im Unterschied zu den bekannten Erweiterungen wird Pi-hole jedoch nicht in jedem einzelnen Browser installiert. Vielmehr ist es ein DNS-Proxy, d.h. unerwünschte Werbung und bekannte Seiten mit Schadsoftware werden auf einem Server bei der DNS-Abfrage blockiert.


    Daraus ergibt sich der wesentliche Vorteil gegenüber Ad-Blockern im Browser: Das Blockieren erfolgt zentral für sämtliche Geräte im Netzwerk. Es ist egal, ob man einen PC, ein Tablett, ein Smartphone oder das TV-Gerät benutzt. Es spielt auch keine Rolle, welchen Browser man verwendet. Das Blocken erfolgt für sämtliche Programme, die eine Internetverbindung haben - auf allen Rechnern im Netz, somit auch für den Thunderbird.


    Ebenso ergibt sich daraus auch ein wesentlicher Nachteil: Man benötigt einen eigenen Server. Wie es der Name schon andeutet, genügt bereits ein Raspberry Pi für ca. 50 Euro. Dennoch ist es damit keine Lösung für die breite Masse sondern eher für "Bastler".

    (Soweit mir bekannt, benutzt die Mehrheit der Anwender überhaupt keinen Ad-Blocker.)


    Wir haben das Pi-hole im Bekanntenkreis mit etwas mehr als 20 Benutzern über 4 Monate getestet. Zunächst nur in unserer gemeinsamen Proxyumgebung.

    Bereits nach kurzer Zeit sind die meisten Teilnehmer auch zu einer lokalen Installation übergegangen. Hier nun unsere gesammelten


    Erkenntnisse:


    Ich beginne mit einigen Punkten, über die man sich zunächst bewusst sein sollte.


    • Das Pi-hole funktioniert nur innerhalb des eigenen Netzwerks. Unterwegs benötigt man entweder weiterhin lokale Blocker oder eine VPN-Verbindung in das eigene Netz.
      In unserem Test hatten alle Teilnehmer eine VPN-Verbindung zum Proxy zur Verfügung.
    • Pi-hole filtert ausschließlich über zu abonnierende Listen wie eaysylist usw. . Eigene Algorithmen, über die z.B. uBlock verfügen soll, hat es nicht. Es existiert auch kein graphisches Werkzeug, wie die Pipette, um Elemente manuell z.B. im Browser auszuwählen.
      Der Erfolgsquote hat dies in unserem Test jedoch nicht geschadet.
    • Im Gegensatz zu lokalen Ad-Blockern lässt sich das Pi-hole nicht von jedem Nutzer mit zwei Klicks im Browser deaktivieren. Es erfordert ein paar Klicks und Kenntnisse mehr.
    • Es gibt umfangreiche, auch graphisch aufbereitete, Logs und Statistiken, was zunächst einmal ein großer Vorteil ist.
      Tatsächlich haben wir dadurch teilweise überraschende Erkenntnisse gewonnen, die wir noch genauer untersuchen möchten. Dazu unten mehr.
      Es bedeutet aber auch: Der Admin kann, wie ein Provider, anhand der DNS-Aufufe nachverfolgen, welche Seiten aufgerufen wurden. Das Logging lässt sich deaktivieren, dennoch ergibt sich daraus durchaus ein Privacy-Thema, dessen man sich bewusst sein muss.
    • Installation und Konfiguration sind sehr einfach. Wer allerdings auf dem Server bereits einen Webserver in Betrieb hat, welcher auf dem Standardport 80 lauscht, muss einigen zusätzlichen Aufwand betreiben.

    Demgegenüber haben wir einige Vorteile notiert:


    • Pi-hole lief über die Monate hinweg 7*24 absolut stabil, auch auf den Raspberry Pis. Der Bedarf an Ressourcen ist sehr gering.
    • Sämtliche stationären Rechner haben keinen Ad-Blocker mehr installiert. Insgesamt waren die Rückmeldungen darüber, dass sich niemand mehr um den eigenen Ad-Blocker kümmern musste, sehr positiv.
      Einige der Tester verwenden mehrere Browser, Virtuelle Maschinen usw. Die waren besonders froh.
    • Der Speicherbedarf der Browser sinkt dadurch etwas, was vor allem den Smartphones und Tabletts zugute kommt.
    • Pi-hole und lokale Ad-Blocker können gleichzeitig benutzt werden.
    • Wir haben subjektiv keine Performance-Einbußen feststellen können. Einige hatten diese vorab befürchtet, weil Blocker im Browser zeitlich vor der DNS-Abfrage wirken können und damit einige Millisekunden Latenz ersparen.
    • Das zentrale Blockieren stellt einen zusätzliches Schutz auch für das Gastnetz dar.
      Als Anekdote nebenbei: Einige Gäste im WLAN hatten auf ihren Smartphones keinen Ad-Blocker. Die waren sehr überrascht, plötzlich fast werbefrei zu sein.
    • Die Filterwirkung ist sehr gut, vergleichbar mit der von uBlock. Wir hatten in den Tests zusätzlich zu den Standardlisten lediglich die bekannten easylists installiert.
    • Neben den Filterlisten unterstützt Pi-hole auch eigene White- und Blacklisten inklusive Regular Expressions.
      Eine Familie nutzt das Pi-hole nun auch als Kindersicherung.
    • Pi-hole blockiert prinzipbedingt auch Inhalte in E-Mails und in anderen Apps, sofern diese von Servern stammen, die in den Listen enthalten sind.
    • Pi-hole unterstützt Secure-DNS.
    • Pi-hole kann auch als DHCP-Server benutzt werden.


    Abschließend noch ein paar Zahlen und Erkenntnisse:

    Zuletzt benutze Version: 4.0

    Zeitaufwand für die Installation: Weniger als 30 Minuten, sofern auf dem Server nicht bereits ein anderer Webserver als Lighttpd läuft.
    Wer einen Raspberry Pi benutzt und das Logging nutzen möchte, sollte in Betracht ziehen, /var/log von der SD-Karte (in den RAM) auszulagern. Das würde ich zur Schonung der SD-Karte auch unabhängig vom Pi-hole empfehlen.

    Benutzer: Wir hatten mehr als 20 Teilnehmer im Alter von 14 bis 60+ Jahren mit mehr als 50 Geräten, inklusive TV, Amazon-Sticks, Media Receivern usw. .

    Blockierte Domains: Im Durchschnitt hatten wir täglich rund 20000 DNS-Anfragen pro teilnehmender Familie. Davon wurden rund 18% blockiert. Das entspricht 3600 täglich blockierter DNS-Anfragen pro Familie. Diese hohe Anzahl hat uns überrascht.

    Ressourcen: Der Bedarf an RAM ist minimal. Selbst auf den Raspberries überstieg er bisher nie 50 MB + Cache.
    Die Auslastung der CPU war auf dem großen Server kaum messbar, auf einem Raspberry Pi Modell 3B+ beträgt sie etwa 1,5%.
    Die CPU-Zeit lag bei uns unter 1 min in 24h trotz gelegentlicher Nutzung der graphischen Auswertung.

    Top-Talkers/Requestors: Die Protokolle der Anfragen haben uns an einigen Stellen überrascht. Insbesondere auch Anfragen, die nicht von einem Browser kamen.
    Wir haben die Top-Adressen identifiziert, die blockiert wurden bzw. die überhaupt angefragt wurden.
    Unter den Spitzenreiter befanden sich neben den erwarteten Adressen von Google, Microsoft, Facebook, Amazon, Instagram usw. überraschend auch Telemetrieübertragungen an einen Browser-Hersteller, obwohl im Browser alle Optionen zur Datenerhebung deaktiviert waren.
    Auch eine installierte Erweiterung zum Schutz vor Trackern meldet sich mehrfach am Tag zuhause, auch hier obwohl sämtliche Optionen abgewählt wurden.
    Wir untersuchen das noch etwas genauer. Man kann anhand der Adressen nicht immer den Sinn und Zweck erkennen. Einige offensichtliche, wie z.B. telemetry.hersteller.com haben wir zusätzlich blockiert, bisher ohne Nachteile bemerkt zu haben.

    Aufgrund der oben erwähnten unerwarteten DNS-Anfragen des Browsers, in meinem Fall des Firefox', habe ich mir die Aufzeichnungen im Pi-hole bezüglich der "Phone Home Calls" etwas genauer angeschaut.

    Ich habe feststellen können, dass der Firefox innerhalb einer Woche rund 7500 Mal mit mindestens 25 verschiedenen Mozilla-Adressen Kontakt aufgenommen hat. Damit hatte ich nicht gerechnet.



    Hinzu kommen Anfragen an Dritte, wie Google (für die Blocklist) oder Cisco (für das h264)

    redirector.gvt1.com
    ciscobinary.openh264.org

    sowie evtl. weitere, die ich nicht sofort dem Firefox zuordnen kann. Anfragen, die erkennbar von Erweiterungen stammten, habe ich hier ebenfalls nicht aufgeführt.

    Die Aufzeichnungen stammen von 6 Geräten aus unserem lokalen Netzwerk. Darunter finden sich auch drei wenig benutze Firefox-Installationen unter Android, in denen keine Änderungen an den Einstellungen zur Privatsphäre vorgenommen wurden. Eine Installation entspricht in allem dem Standard.

    Die Liste zeigt nur DNS-Anfragen. Welche Informationen dabei übermittelt wurden und in wie weit sie zur Identifikation genutzt werden könnten, geht daraus nicht hervor.
    Bei manchen der Adressen ergibt sich aus dem Namen, wozu sie benötigt werden, etwa bei den Update-Checks, Pocket, den Kacheln, Tracking Protection oder Sync. Bei vielen erschließt sich mir der Zweck jedoch aus dem Namen allein nicht.

    Die Suche nach weiteren Details ist zeitaufwendig. Unter anderem bin ich auf diese Seite gestoßen:

    https://blog.mozilla.org/data/…suring-search-in-firefox/

    Demnach erfasst Mozilla im Rahmen der Telemetrie Daten über die Suche und plant, künftig auch zu erfassen, wie oft Werbelinks geklickt werden. Das war mir bisher nicht bekannt.

    Hier habe ich aber eine mögliche Erklärung dafür gefunden, weshalb mein Firefox Kontakt mit incoming.telemetry.mozilla.org aufnimmt, obwohl diese Funktion deaktiviert ist:

    Quote


    The Telemetry Coverage measurement will sample a portion of all Firefox clients and report whether telemetry is enabled. This measurement will not include a client identifier and will not be associated with our standard telemetry.



    Mozilla möchte dadurch erfahren, wie viele Benutzer das Senden der Telemetrie abgeschaltet haben.

    Ich möchte bewusst keine Bewertung dieser Beobachtungen vornehmen. Dazu fehlen mir weitere Detailinformation darüber, welche Daten jeweils übertragen werden. Klar ist, dass bestimmte Dienstleistungen wie z.B. Sync oder der Tracking-Schutz solche Verbindungen benötigen.

    Mich hat aber die schiere Anzahl der Adressen wirklich überrascht.

    Sofern es meine Zeit erlaubt, werde ich auf einigen Rechnern andere Browser, insbesondere Chromium, installieren und diesbezüglich beobachten.

    Um zum eigentlich Thema zurückzukommen: Das Pi-hole hat sich neben seinem Hauptzweck als Werbeblocker auch als gutes Instrument erwiesen, um mit einfachen Mitteln festzustellen, welche Programme unbemerkt im Hintergrund Daten übertragen. Es muss nicht gleich der Wire Shark sein.