Wer im Internet surft, wird von Trackern verfolgt und mit Werbung zugepflastert. Der Werbeflut stehen Nutzer zum Glück nicht schutzlos gegenüber. Denn neben Browser-Plug-ins helfen auch netzwerkbasierte DNS-Blocker wie PiHole vor unerwünschten Inhalten. Wir beschreiben dessen Funktionsweise und Konfiguration und wo Sie an wirkungsvolle Blacklists kommen.
Eine Folge der preisgekrönten TV-Serie Futurama stellt das Internet als Metaverse dar, in dem Werbebanner die Avatare der Nutzer wie Raubvögel attackieren: "The Internet! My God! It's full of ads!" Auch ohne Metaverse werden Internetsurfer heute von Trackern und Cookies verfolgt und mit unerwünschter Werbung zugepflastert. Doch die Nutzer stehen dieser Werbeflut nicht schutzlos gegenüber. Es gibt diverse Methoden, sich der Verfolgung durch Werbetreibende zu entziehen, Tracker zu verwirren und unerwünschte Inhalte aus Webseiten fernzuhalten. Wir stellen mithilfe des freien PiHole ein paar wirkungsvolle Ansätze vor, die auf Server-, Netzwerk- und Clientebene vor unerwünschten Content schützen und damit auch gleich die Bedrohung durch Phishing minimieren.
Proxy-Filter mit Problemen
In den frühen 2000ern war der Proxy-Filter die beste Methode, um sich vor unerwünschten Inhalten und Bedrohungen durch Viren und Trojaner aus dem Internet zu schützen. Clients fordern dabei den Inhalt einer Website nicht direkt aus dem Internet an, sondern übergeben den Request an einen zentralen Proxy-Server wie Squid. Dieser ruft dann die Inhalte ab, speichert Teile davon in einem lokalen Cache und liefert die Informationen zurück an den Browser. In Zeiten mit begrenzten Bandbreiten waren Proxies vor allem wegen ihrer Cache-Funktion beliebt, da sie dadurch weniger Daten über die langsamen Internetverbindungen abrufen mussten. Plug-ins wie Squidguard blockierten dabei unerwünschte Inhalte auf Proxy-Ebene, während andere Erweiterungen den Inhalt von Webseiten direkt inspizierten und auf Malware prüften.
Doch den Proxies wurde durch ein wichtiges Sicherheitsfeature die Arbeit erschwert: HTTPS. Verschlüsselte Protokolle muss ein Proxy-Server unverändert durchreichen und kann daher deren Inhalte nicht filtern. Es sei denn, er bricht die Verschlüsselung auf. Besonders bei großen Unternehmen kommt diese Methode (SSL Bump) nach wie vor zum Einsatz: Der Proxy-Server terminiert dabei die SSL-Verbindung der aufgerufenen Webseite, inspiziert, filtert und cached den entschlüsselten Inhalt. Für die Kommunikation zum Clientbrowser verschlüsselt der Proxy die Daten dann wieder, nutzt dazu aber sein eigenes Zertifikat. Für so ein Szenario muss der Administrator die Konfiguration aller Browser im LAN modifizieren, sodass diese das Zertifikat des Proxies für alle URLs akzeptieren.
Eine Folge der preisgekrönten TV-Serie Futurama stellt das Internet als Metaverse dar, in dem Werbebanner die Avatare der Nutzer wie Raubvögel attackieren: "The Internet! My God! It's full of ads!" Auch ohne Metaverse werden Internetsurfer heute von Trackern und Cookies verfolgt und mit unerwünschter Werbung zugepflastert. Doch die Nutzer stehen dieser Werbeflut nicht schutzlos gegenüber. Es gibt diverse Methoden, sich der Verfolgung durch Werbetreibende zu entziehen, Tracker zu verwirren und unerwünschte Inhalte aus Webseiten fernzuhalten. Wir stellen mithilfe des freien PiHole ein paar wirkungsvolle Ansätze vor, die auf Server-, Netzwerk- und Clientebene vor unerwünschten Content schützen und damit auch gleich die Bedrohung durch Phishing minimieren.
Proxy-Filter mit Problemen
In den frühen 2000ern war der Proxy-Filter die beste Methode, um sich vor unerwünschten Inhalten und Bedrohungen durch Viren und Trojaner aus dem Internet zu schützen. Clients fordern dabei den Inhalt einer Website nicht direkt aus dem Internet an, sondern übergeben den Request an einen zentralen Proxy-Server wie Squid. Dieser ruft dann die Inhalte ab, speichert Teile davon in einem lokalen Cache und liefert die Informationen zurück an den Browser. In Zeiten mit begrenzten Bandbreiten waren Proxies vor allem wegen ihrer Cache-Funktion beliebt, da sie dadurch weniger Daten über die langsamen Internetverbindungen abrufen mussten. Plug-ins wie Squidguard blockierten dabei unerwünschte Inhalte auf Proxy-Ebene, während andere Erweiterungen den Inhalt von Webseiten direkt inspizierten und auf Malware prüften.
Doch den Proxies wurde durch ein wichtiges Sicherheitsfeature die Arbeit erschwert: HTTPS. Verschlüsselte Protokolle muss ein Proxy-Server unverändert durchreichen und kann daher deren Inhalte nicht filtern. Es sei denn, er bricht die Verschlüsselung auf. Besonders bei großen Unternehmen kommt diese Methode (SSL Bump) nach wie vor zum Einsatz: Der Proxy-Server terminiert dabei die SSL-Verbindung der aufgerufenen Webseite, inspiziert, filtert und cached den entschlüsselten Inhalt. Für die Kommunikation zum Clientbrowser verschlüsselt der Proxy die Daten dann wieder, nutzt dazu aber sein eigenes Zertifikat. Für so ein Szenario muss der Administrator die Konfiguration aller Browser im LAN modifizieren, sodass diese das Zertifikat des Proxies für alle URLs akzeptieren.
Das größte Problem eines Proxy-Filters ist dabei kein technisches, sondern ein rechtliches: Er arbeitet als Man-in-the-Middle-Attacke und entschlüsselt dabei die komplette Internetkommunikation aller Nutzer. Sobald sich ein Anwender auf seinem Firmen-PC also bei privaten Diensten wie Homebanking, Shopping oder Social Media anmeldet, entschlüsselt und speichert der Firmen-Proxy private Daten wie Passwörter oder Inhalte des Shopping-Carts. Ein solcher Eingriff in die Privatsphäre der Nutzer ist nicht zulässig. Der Arbeitgeber benötigt mit so einem Filter eine passende, vom Betriebsrat abgesegnete und von allen Mitarbeitern unterschriebene Betriebsvereinbarung, die beispielsweise die private Nutzung von Firmen-PCs generell ausschließt. Ebenso möglich wären passende Filter, die Zugänge zu Diensten wie Banking, Shopping und Social Media komplett sperren.
Als Alternative könnte das Unternehmen ein separates, ungefiltertes WLAN ohne Verbindung zum Firmennetzwerk für die privaten Geräte der Nutzer bereitstellen. Außerdem können moderne Filter-Proxies wie Squid neben dem reinen "Bumping" der SSL-Verbindungen auch eine regelbasierte Weiterleitung (Peek and Slice) einsetzen. Eine Regelsammlung entscheidet dabei, welche Verbindung vom Proxy aufgebrochen und untersucht und welche ohne Entschlüsselung direkt zum Client getunnelt wird. Das wiederum würde es erlauben, den privaten Traffic von Nutzern unangetastet durchzureichen. Mit so einem Setup ist der Proxy als Schutzmaßnahme allerdings wirkungslos. Auf die genaue Beschreibung eines Squid-Setups mit Bump, Peek & Slice verzichten wir daher in diesem Artikel und widmen uns lieber einer rechtlich weit weniger problematischen Lösung.
Nicht bestellt, nicht abgeholt
Eine andere Methode, um unerwünschte Inhalte fernzuhalten, filtert nicht die zurückkommenden Pakete aus dem Internet, sondern die ausgehenden Anfragen. Beim Blick auf den HTML-Code einer Webseite mit Werbung fällt schnell auf, dass die Werbebanner gar nicht vom angesprochenen Zielserver selbst stammen. Vielmehr betten die Seiten sogenannte HTML-Include-Links zu den Diensten der Werbetreibenden ein, ebenso wie Tracking-Cookies, die auf diese Werbeanbieter verweisen. Diese Deep-Links zeigen nicht auf IP-Adressen, sondern auf die DNS-Namen der entsprechenden Betreiber oder Unterdomänen.
Das heißt, dass der Browser des Nutzers selbst aktiv diese Banner und Tracker anfordert – nachdem er die DNS-Adresse des eingebetteten Links aufgelöst hat. Und genau hier setzt das DNS-Filtering an: Es nutzt Blacklists für unerwünschte URLs und weigert sich, die IP-Adressen dieser URLs an den Client auszuliefern. Statt einer IP-Adresse gibt der Filter-DNS einfach 0.0.0.0 zurück. Der Browser fordert die integrierte URL daher gar nicht erst aus dem Internet an. Der Platz des Werbebanners bleibt leer und die Tracker erhalten keine Rückmeldung vom Client. Aber aufgepasst: Damit die DNS-Filterung funktioniert, müssen die Clients und deren Browser die vorgegebene DNS-Auflösung des Netzwerks verwenden und dürfen nicht eigene DNS-Server und -Methoden einsetzen.
Im laufenden Betrieb filtert PiHole DNS-Anfragen nach unerwünschten URLs und blendet damit Werbeinhalte und Tracker aus.
PiHole als DNS-Filter
Einer der populärsten DNS-Filter ist PiHole. Wie der Name vermuten lässt, startete das Werkzeug anfangs als Software für den Raspberry Pi. PiHole läuft aber auf allen anderen Plattformen zuverlässig und ausreichend schnell, selbst wenn es in einem größeren Netzwerk zum Einsatz kommt.
Manch IT-Verantwortlicher schreckt jedoch vor der Nutzung zurück, da er seinen bereits bestehenden DNS-Server nicht ersetzen und dessen Konfiguration zu PiHole übertragen will. Das ist besonders dann der Fall, wenn der bestehende DNS-Server lokale Adressen und Dienste wie Kerberos auflöst und vielleicht noch integriert mit dem DHCP-Dienst arbeitet. Da das DNS-Protokoll jedoch keine Probleme mit Proxy-Forwarding hat, braucht ein PiHole-Setup den bestehenden Dienst gar nicht zu ersetzen, sondern arbeitet als eine Art Overlay – in unserem Workshopbeispiel sogar gleich auf derselben Maschine.
Unser Setup beispielsweise setzt einen bestehenden Dnsmasq-Server auf dem Applikationsserver mit RHEL 8 ein. Der Dienst versorgt das LAN via DHCP mit IP-Adressen, erlaubt physischen und virtuellen Systemen, via PXE über das Netz zu starten, und löst Namen der lokalen Domäne auf. Der Dnsmasq-Dienst nutzt dabei bevorzugt den öffentlichen Quad9-Service 9.9.9.9 als Upstream-DNS. Anders als Googles offener DNS-Service auf 8.8.8.8 protokolliert Quad9 nicht alle eingehenden DNS-Anfragen samt Quell-IP-Adressen.
Zusätzlich zum Dnsmasq-Dienst betreibt der Applikationsserver nun auch PiHole, und zwar in einem Podman-Container. Prinzipiell gibt es zwei Optionen, um zwei DNS-Server auf der gleichen Maschine zu betreiben: Läuft PiHole in einem Container ohne eine eigene IP-Adresse, muss der bestehende Dnsmasq-Dienst auf einen anderen Port als 53 ausweichen. Alternativ lassen Sie den PiHole-Container auf einem Bridge-Netzwerk und damit mit einer eigenen IP-Adresse arbeiten. Für den Workshop nutzen wir den zweiten Ansatz, da unser Applikationsserver ohnehin eine ganze Reihe anderer Podman-Container mit eigenen IP-Adressen verwendet.
Network Bridge erstellen
Im ersten Schritt brauchen wir also eine Network-Bridge auf dem LAN-Adapter des Linux-Servers, der später den PiHole-Container betreiben soll. In der Regel ist das die Bridge "br0", die auch die statische IP-Adresse des physischen Applikationsservers beherbergt. Wer den primären LAN-Adapter eines Servers bridgen möchte, muss das in der Regel bei laufendem Netzwerk tun. Das kann natürlich schiefgehen und den Server einfach vom LAN abhängen. Mit einem kleinen Skript und dem NetworkManager von Linux klappt diese Aufgabe jedoch recht problemlos. So lässt sich sogar die LAN-Konfiguration eines entfernten Cloudservers bridgen, während der Administrator über genau diese Verbindung per SSH darauf geschaltet ist.
Während der Systeminstallation erstellt der NetworkManager in der Regel ein logisches Netzwerk mit dem Namen des darunterliegenden physischen Adapters oder einer Bezeichnung wie "Wired 1". Die mit dem Befehl nmcli connection show angezeigte UUID übertragen Sie nun in das im Listing 1 abgedruckte Bash-Skript "bridge-lan.sh", zusammen mit der statischen IP-Adresse der Bridge und den weiteren LAN-Parametern. In unserem Workshop ist das die IP-Adresse 192.168.2.12 für den Applikationsserver und 192.168.12.1 für den Router. Als DNS-Adresse geben Sie den Server selbst an, da dieser aktuell noch als einziger DNS tätig ist.
Machen Sie das Skript ausführbar und starten es. Es löscht zuerst die alte Verbindung, konfiguriert die Bridge und nimmt sie abschließend in Betrieb. Nach wenigen Sekunden können Sie den Server über die Bridge ansprechen. Auf diese Bridge packen Sie im nächsten Schritt ein Container-Netzwerk, das Podman später für den PiHole-Container und andere verwenden kann.
Podman verwaltet seine Netzwerke im Verzeichnis "/etc/cni/net.d/". Um ein Bridge-Network für die Bridge "br0" zu erstellen, generieren Sie eine entsprechende Conflist – siehe unser Beispiel "pub_net.conflist" im Listing 2. Jetzt können Sie Container auf dem Netzwerk "pub_net" mit eigenen IP-Adressen starten.
Mit der passenden Bridge und dem Podman-Netzwerk dafür definieren Sie den PiHole-Container nun als systemd-Dienst, sodass er bei einem Neustart des Applikationsservers automatisch hochfahren kann – siehe Listing-Kasten 3. In unserem Beispielaufbau bekommt der PiHole-Container die IP-Adresse 192.168.2.2 und eine dazu passende MAC-Adresse, die sich aus dem bei KVM-VMs üblichen Vendor-String "52:54" und der IP-Adresse im Hexadezimalformat "C0:A8:02:02" zusammensetzt.
Zu guter Letzt erstellen Sie unter "/var/ pods/pihole" die beiden Verzeichnisse "etc" und "dnsmasq", in die PiHole gleich die Konfigurationsdateien platzieren wird. Jetzt starten Sie den Container via systemd mit systemctl start pihole. Der erste Aufruf legt zunächst die benötigten Konfigurationsdateien und Verzeichnisstrukturen an, bevor der PiHole-DNS seine Arbeit aufnimmt. Um den PiHole-Dienst via Web-UI administrieren zu können, setzen Sie erst einmal ein Administrator-Passwort. Dazu klinken Sie sich auf dem Podman-Host in den laufenden Container ein:
podman exec -it pihole /bin/bash
Im darauf folgenden Prompt tippen Sie das Admin-Kommando pihole -a -p ein, um ein neues Admin-Passwort zu setzen. Dann starten Sie das Webinterface im Browser Ihres Clients, in unserem Fall also auf "http://192.168.2.2", und melden sich mit dem zuvor vergebenen Passwort an. Gehen Sie in das Menü "Settings" und dort in den Tab "DNS". In der Grundkonfiguration setzt PiHole den Google-DNS-Server als Upstream ein. Schalten Sie den Google-Server in der Upstream-Liste aus und tragen im Dialog auf der rechten Seite den internen DNS-Server ein, für diesen Workshop also "192.168.2.12#53". Jetzt kann PiHole sowohl interne als auch externe Namen auflösen. Wenn alles läuft, aktivieren Sie mit systemctl enable pihole den Autostart für den PiHole-Dienst.
Welche Domains PiHole filtert, sehen Sie im Tab "Adlist". Hier ist eine Standardliste mit etwa 160.000 Domains vorgegeben. Weitere Filterlisten finden Sie auf [1], wobei die Liste "YouTube_ads_pi-hole" sehr zu empfehlen ist. Listen fügen Sie einfach über deren URL hinzu. PiHole aktualisiert sie automatisch einmal pro Woche. Möchten Sie ein manuelles Update anstoßen, finden Sie die Option "Update Gravity" im Menü "Tools".
Im Tab "Domains" fügen Sie einzelne eigene Einträge oder RegEx-Selektionen zur White- oder Blacklist hinzu. Der Basisfilter beispielsweise schneidet Amazon-Geräte in ihrem LAN von deren Metrikkollektoren (device-metrics-us-2. amazon.com) ab. Das beeinträchtigt die Funktion von Alexa & Co und kann zu verlangsamten Reaktionen dieser Geräte führen. Wer das nicht möchte, müsste diese Domain explizit freigeben.
Als Podman-Container kann PiHole prinzipiell auf jedem Rechner und in jeder VM laufen, die über einen gebridgten LAN-Adapter verfügt. Mit der festgelegten MAC- und IP-Adresse in der systemd-Unit startet der Container dabei unabhängig vom Host-System stets mit den gleichen Netzwerkparametern. Im laufenden Betrieb nimmt PiHole kaum Änderungen am zugrundeliegenden Dateisystem vor.
Sie können daher mit Bordmitteln regelmäßig und relativ simpel die beiden Verzeichnisse des PiHole-Setups auf ein Backuplaufwerk oder einen zweiten Host kopieren, zum Beispiel mit rsync. Es ist zudem möglich, die PiHole-Daten auf einem NFS-Share abzulegen, sodass mehrere Hosts darauf Zugriff haben.
DNS- und DHCP-Dienst anpassen
Damit PiHole optimal mit der bestehenden DNS/DHCP-Konfiguration zusammenarbeitet, bedarf es einiger Änderungen an den bestehenden Einstellungen. Zunächst müssen Sie die DHCP-Option 6 (DNS-Server) in ihrem DHCP-Service auf den PiHole-Server umstellen. Bei Dnsmasq sieht die Option dann so aus:
dhcp-option=6,192.168.2.2
Ebenso kann Dnsmasq andere DNS-Server als Forwarder verwenden als den Host, auf dem es läuft. Listen Sie alle gewünschten DNS-Server in einer Datei "/etc/nameservers.conf" nach folgendem Schema auf:
nameserver 9.9.9.9
nameserver 1.1.1.1
nameserver 149.112.112.112
nameserver 1.0.0.1
und geben Sie diese Liste in ihrer eigenen Datei "dnsmasq.conf" an:
resolv-file=/etc/nameservers.conf
Jetzt könnte der darunterliegende Host selbst ebenfalls den PiHole-Server für die Namensauflösung verwenden, braucht aber zwingend einen Secondary DNS. Wenn Sie den PiHole-Container neu starten, muss der Host dazu in der Lage sein, die Docker-URL der Registry aufzulösen. Daher darf sich der Host nicht allein auf den PiHole-Server verlassen.
Rechtliche Grauzone vermeiden
Anders als ein Proxy-Filter greift die Filterung mittels PiHole nicht direkt in die Datenpakete der Nutzer ein. Dennoch loggt PiHole die DNS-Aufrufe der Systeme. Ein Administrator könnte daher mit Hilfe der PiHole-Logs und der DHCP-Leases des darunter liegenden Dnsmasq genau ermitteln, wann welcher Nutzer welche DNS-Anfrage abgesetzt hat. Über die MAC-Adresse lässt sich die Anfrage bis zum Arbeitsplatzrechner zurückverfolgen. Um diesen Weg zu erschweren, helfen kurze Lease-Zeiten des DHCP-Segments. Geben Sie eine Zeit von beispielsweise vier Stunden als Lease Time an, müssen Clients alle vier Stunden ihre IP-Adresse vom DHCP-Server neu anfordern. Der Client versucht dabei in der Regel, die bereits bestehende IP zu erneuern und weiterzuverwenden. Schalten die Nutzer ihre Arbeitsstationen jedoch über Nacht ab, besteht eine hohe Chance, dass Sie am Morgen des nächsten Tages eine andere Adresse erhalten. Der Administrator kann daher nur für die Zeit eines IP-Leases eine Anfrage sicher zur Quelle zurückverfolgen.
Finish im Browser
Mit dem DNS-basierten PiHole entfernen Sie bereits einen großen Teil der unerwünschten Inhalte aus dem Datenstrom. Jedoch verbleiben einige Inhalte, wenn sich diese vor dem Filter verbergen können oder sie tatsächlich in die originale Quell-URL eingebunden sind. Um die letzten verbliebenen Tracker und Ads loszuwerden, hilft nur noch ein Browser-Plug-in. Aus der Masse der verfügbaren Add-ons picken wir an dieser Stelle zwei heraus: Ghostery and AdNauseam.
Ghostery gehört zu den populärsten und zuverlässigsten Ad-Filtern. Neben dem reinen Plug-in für Chrome und Firefox gibt es Ghostery zudem als fertigen Browser, basierend auf den Chrome-Quelldateien. Darüber gelangt Ghostery auch auf Smartphones und Tablets. Es macht dabei einen großen Unterschied, ob Sie YouTube-Videos auf ihrem Handy in der passenden (ungefilterten) App oder über die reguläre YouTube-Webseite innerhalb des gefilterten Ghostery-Browsers für Android oder iOS anzusehen.
AdNauseam fügt der reinen Filterfunktion noch das besondere Extra hinzu: Zwar zeigt der Filter die eingebetteten Banner nicht im Browser an, jedoch klickt das Plug-in im Hintergrund auf alle Werbelinks. Werbetreibende versuchen, den Anwendern persönlich zugeschnittene Anzeigen zu präsentieren. Das heißt nichts anderes, als dass die Werber ein Profil zu ihrem Surfverhalten erstellen, indem sie analysieren, welche Art von Werbung Nutzer anklicken. AdNauseam verwässert Ihr Profil, denn wenn Sie scheinbar an allen Themen von Sportwetten über Glückspiel bis hin zum Abführmittel Interesse zeigen, kann der Werbetreibende gar kein persönlich angepasstes Profil erstellen.
Dieser Filter empfiehlt sich daher, wenn Sie für ihren Browser bereits Profile erstellt haben und Sie immer wieder mit den gleichen Werbethemen konfrontiert sind. Allerdings ist das Tool umstritten, denn oft müssen die Werbekunden für Bannerklicks bezahlen — wobei Sie als Nutzer dann den bezahlten Inhalt nicht zu Gesicht bekommen. Google hat AdNauseam daher aus dem Chrome-Store entfernt und Sie müssten das Plug-in als Chrome-Nutzer manuell einrichten. Für Firefox gibt es den automatischen Installer nach wie vor.
Fazit
Wenn Sie genug von der Werbeflut im Internet haben und nicht von Trackern verfolgt werden möchten, steht Ihnen die Kombination aus DNS-Blackhole und Browser-Plug-in wirkungsvoll zur Seite. Als Nebeneffekt können Tools wie PiHole auch Phishing-Attacken abwehren, da viele der bekannten Phishing-URLs bereits in den Blacklists stehen. Ghostery als etabliertes Add-on entfernt dann noch die Überbleibsel dessen, was PiHole nicht abwehren kann.