Wie selbstverständlich akzeptieren es die meisten von uns, im Browser mit Werbung zugeballert zu werden – je nach besuchter Seite mal mehr und mal weniger arg. Und wie selbstverständlich stellen wir unseren Weg durch das Netz anhand unserer leicht nachvollziehbaren DNS-Abfragen an unseren Provider zur Verfügung.
Ende Mai gab es hier den ersten Beitrag rund um Raspberry Pis, also diese Mini-Computer auf der Grundfläche einer Kreditkarte. Dort ging es um den Aufbau eines eigenen NAS für schmales Geld. Auch wenn Raspis sehr vielseitige Geräte sind, möchte ich mich hier nur mit Software-Projekten beschäftigen.
Ein weiterer Beitrag befasste sich mit dem Problem noch etwas genauer und brachte bereits Unbound ins Spiel, womit ein eigener DNS-Server betrieben werden kann. Ganz kurz angerissen wurde dabei auch die Pi-hole – ein Werbeblocker, wie ihn zwar viele bereits im Browser eingebaut haben. Nur ist Pi-hole eine ganze Ecke mehr, nämlich zum Beispiel der Werbeblocker für dein ganzes Netzwerk.
Freilich filtert dir die Pi-hole nicht die Werbung aus deinem Fernseher heraus oder wenn diese in Beiträgen auf YouTube eingebettet sind; dann nämlich ist die Werbung Bestandteil des Streams, welcher nicht zerlegt werden kann. Allerdings werden Werbebanner, Pop-ups und all so ein lästiges Zeugs gesperrt – ja, versenkt regelrecht.
In Kombination mit einer Unbound-Instanz auf dem gleichen Raspberry Pi wird das ein ziemlich pingeliges Duo, welches nebenbei auch noch die Vorarbeit zur Namensauflösung von Docker-Diensten leisten kann – was einen nachgelagerten internen Mini-Reverse-Proxy benötigt. Damit würden sich also Dienste mit einer Adresse wie z. B. 192.168.1.10:4000 dann einfach unter http://dashy.lan ansprechen lassen. Doch der Reihe nach.
Die Hardware-Voraussetzungen
Als Erstes wird ein Raspberry Pi benötigt; ab Version 3 dürfte es in diesem Setup keine Probleme geben. Die interne LAN-Schnittstelle reicht aus, da der Verkehr nicht durch das Gerät durchfließt, sondern diese Instanz bei jedem Vorgang vom LAN in die große weite Welt abgefragt wird.
Eine 4–8 GB große SD-Karte, ein Gehäuse und schon kann es losgehen. Während der Installation werden Tastatur, Maus und Monitor benötigt, danach nicht mehr.
Mit Balena Etcher kannst du das aktuelle Image von Raspberry Pi OS Lite auf die SD-Karte schreiben und den Raspi im Anschluss starten. Notiere bei der Installation unbedingt die Zugangsdaten. Diese sind wichtig für den späteren Zugriff auf das Gerät mittels SSH. Da sich das Gerät in der Regel eine IP-Adresse über deinen Router besorgt (also mittels DHCP), ist diese erst einmal nur dynamisch. Dies müsste noch auf statisch geändert werden (siehe hierzu die Referenz zu deinem Router).
Installation von Pi-hole
Mit folgendem Befehl installierst du nun die eigentliche Pi-hole:
curl -sSL https://install.pi-hole.net | bashDabei wird ein Admin-Passwort generiert, welches sich meist kein Mensch merken kann – auch dieses dringend notieren, es ist der Schlüssel für das Web-Interface. Der Installer fragt allerlei Dinge ab und richtet sich dann final ein.
Das automatisch generierte Passwort kannst du mit diesem Befehl ändern:
sudo pihole setpasswordUnbound hinzufügen
Und so wird Unbound hinzugefügt:
sudo apt install unbound dns-root-data -yIn diesem Beitrag möchte ich die expliziten Konfigurationen nicht weiter angehen, da diese zum einen von Version zu Version unterschiedlich sein können und zum anderen sich auf dein spezifisches Setup beziehen. Sieh dir hierzu bitte die jeweils gültigen Konfigurationen auf den jeweiligen Support-Seiten an.
Was aber immer gleich bleibend ist, ist die Notwendigkeit, die Anzahl der gepufferten Seiten der Pi-hole selbst auf 1 zu setzen. Eine Null ist hier nicht zulässig, und die Standard-Einstellung wäre 1000. Warum das? Du erzwingst damit, dass die Pi-hole jede DNS-Abfrage nur an die Unbound-Instanz sendet und diese nicht selbst auflöst. Letzteres kann dazu führen, dass DNS-Anfragen doch an den Provider gesendet werden. cache-size=1 ist hier die richtige Einstellung dann.
Weiterhin ist es dringend geraten, Unbound selbst auf Port 5335 lauschen zu lassen und den Upstream der Pi-hole auf diese Adresse zeigen zu lassen: Sonst würden beide auf Port 53 (DNS) lauschen, was zu Konflikten führen wird.
Für Unbound liegt die Konfiguration hier:
sudo nano /etc/unbound/unbound.conf.d/pi-hole.confDas „Port“-Feld muss auf 5335 geändert werden.
Ab Pi-hole v6 findest du den Eintrag unter Settings -> DNS. Hier müssen alle Upstream-Server deaktiviert sein (wie Google etc.). Ganz unten bei Custom DNS Servers fügst du dann einfach diesen Abschnitt hinzu: 127.0.0.1#5335. Und schon sind beide Instanzen miteinander verschachtelt.
Router-Konfiguration
Zum Schluss müssen noch die DNS-Einträge am Router selbst geändert werden (z. B. in der FritzBox): In der Regel gibt es hier die Einträge „DNS 1″ und „DNS 2″ oder „Primärer“ und „Sekundärer DNS“ – irgendwie so heißen die, je nach Gerät. In beide Felder trägst du die statische IP-Adresse deiner Pi-hole-Instanz ein. Befinden sich mehrere Router in deinem LAN, so muss dies natürlich dort eingetragen werden, wo der DHCP aktiv ist.
Wer noch einen Schritt weitergehen möchte und an eventuell kompromittierte Dienste oder fremde Geräte im LAN denkt, die eine statische Angabe auf einen DNS-Server haben und somit „raus“ telefonieren wollen: Viele Router können ausgehende Ports über die interne Firewall sperren. Hier richtest du zuallererst die Pi-hole-Instanz als einzige gültige Absender-IP ein, die DNS-Anfragen stellen darf (Port 53 immer offen/weiterleiten für LAN → WAN). Für alle anderen Dienste wird der Port 53 dann explizit gesperrt.
Die Regel für die Freigabe muss jedoch eine höhere Priorität haben als die der Sperre – die Regeln werden der Reihenfolge nach beachtet. Wenn also zuerst die Sperre für alle kommt, darf auch die Pi-hole nicht „raus telefonieren“.
Was passiert nun genau?
Du arbeitest lokal an einem PC in deinem LAN und rufst im Browser eine Webseite wie zum Beispiel diese hier auf. Die Anfrage landet dann bei deiner Pi-hole; dort wird diese mangels Cache direkt weitergeleitet zur Unbound auf dem gleichen Gerät.
Unbound löst nun die DNS-Anfrage selbst auf, prüft dabei jede Stufe der Kette einer Anfrage auf Gültigkeit und gibt den minimal notwendigen Teil in der Anfrage an den nächsten Server bekannt, nicht jedoch die vollständige Information der ganzen Anfrage. Weiterhin wird nicht deine öffentliche IP als Anfragender verwendet, sondern die der lokalen Unbound-Instanz. Mit der kann nur niemand etwas anfangen, also ist dies zum Datensammeln wertlos.
Wie wird nun aber die Werbung „versenkt“?
Nun, jede als Banner etc. eingeblendete Werbung ist eine weitere DNS-Anfrage, und Pi-hole arbeitet mit Blocklisten. Ist hier ein Werbe-Host hinterlegt, wird die Anfrage direkt verworfen. Ist über die Ziel-Adresse nichts bekannt, wird die Anfrage an Unbound weitergeleitet. Die Blocklisten aktualisieren sich selbstständig in einer SQL-Datenbank, in der Regel einmal pro Woche.
Grundsätzlich kann diese ganze Installation auch in Docker-Containern auf einer VM erstellt werden. Mir ist jedoch die Abtrennung auf ein isoliertes Gerät hier die bessere Lösung, um derlei Anfragen nicht komplett über z. B. einen Proxmox-Server laufen zu lassen.
In der Pi-hole-Instanz lassen sich noch allerlei weitere Einstellungen finden und festlegen (siehe hierzu am besten die offizielle Dokumentation). Das Dashboard enthält außerdem Statistiken zur Blockrate und eine Aussage dazu, welche Clients die häufigsten Anfragen stellen und welche am häufigsten geblockt werden.
Unter Settings -> Local DNS Records kannst du lokale Domains auf die entsprechenden IP-Adressen auflösen lassen. Dies ist insbesondere dann sinnvoll, wenn du viele Docker-Container auf verschiedenen Ports laufen hast; da Ports nicht mit einem DNS-Eintrag aufgelöst werden können, kannst du hier auf einen internen Reverse-Proxy verweisen (Traefik, NGINX etc.), welcher dann die Auflösung auf Portnummern vornimmt.
Fazit
Mit recht überschaubarem Aufwand lässt sich eine kleine und sparsame Pi-hole & Unbound-Instanz auf einem Raspberry einrichten und betreiben. Zum einen sichert dies dein lokales Netzwerk besser ab, schützt deine Privatsphäre und sorgt on top noch für die Unterdrückung manch lästiger Werbe-Banner auf vielen Webseiten.
Für weitere Absicherung gegen Ausfall würden sich auch zwei gleiche Instanzen auf zwei Raspberrys realisieren lassen, allerdings ist das Geschmackssache. Wenn der Raspi bei mir hängt, wird dieser einfach neu gestartet. Da hier keine großartige Denkleistung des Prozessors gefordert ist, tut es auch ein älterer Raspi 3 und vor allem nur passiv gekühlt – was dir den kleinen Lüfter mit hoher Drehzahl dann auch erspart.
Wenn du nun also alle Anfragen selbst auflöst, passiert bei deinem Provider Folgendes: Er sieht nach wie vor, dass du anfragst – aber nicht mehr, was du anfragst. Denn genau das geht schließlich nur dich etwas an.
