Ziel der Übung ist es, einen Raspberry Piso zu konfigurieren, dass er einerseits DNS-Anfragen mittels Pi-Hole filtert und damit Werbung, Spam und Malware unterbindet und andererseits als rekursiver DNS-Resolver agiert, zu diesem Zweck soll Unbound zum Einsatz kommen.
Das Betriebssystem ist standardmäßig auf DHCPv4 eingestellt und bekommt somit von meinem Router eine IPv4-Adresse zugewiesen.
Ich benutze Putty, um mich per SSH auf den Raspberry Pi zu verbinden und melde mich mit den Standard-Zugangsdaten an, bei diesem Image sind das ubuntu/ubuntu. Bei Aufforderung ändere ich das Passwort.
Ich aktualisiere das Betriebssystem mit den beiden Befehlen
sudo apt update
sudo apt upgrade
Benutzer ändern (optional)
Ich möchte einen anderen Benutzernamen verwenden und lege dazu einen neuen Benutzer namens newuser an, dabei vergebe ich ein sicheres Passwort und füge ihn zur Gruppe der Sudoers (Administratoren) hinzu:
Ich öffne eine neue Session in Putty und melde mich mit dem neuen Benutzer an. Nachdem das klappt, beende ich die erste SSH-Session und lösche dann den alten User ubuntu und sein home-Verzeichnis.
sudo userdel -r ubuntu
Netzwerk
Hostnamen ändern (optional)
Ich ändere dazu den Hostnamen mittels hostnamectl und füge dann noch die Einträge 127.0.0.1 dns-vie und ::1 dns-vie zur Datei /etc/hosts hinzu.
Seit Ubuntu 17.10 wird Netplanverwendet. Das heißt, die unter /etc/netplan/ abgelegte Konfigurationsdatei wird gelesen und für die Netzwerkkonfiguration angewendet. Bei diesem Betriebssystem heißt diese Datei 50-cloud-init.yaml und beinhaltet standardmäßig folgendes:
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
eth0:
dhcp4: true
optional: true
version: 2
Ich ändere die Konfiguration entsprechend meiner Wünsche, sie sieht dann in etwa so aus:
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
eth0:
dhcp4: no
dhcp6: no
accept-ra: true
addresses:
- 192.0.2.53/24
- 2001:db8::53/64
gateway4: 192.0.2.1
gateway6: 2001:db8::1
nameservers:
addresses:
- 127.0.0.1
- ::1
version: 2
Ich habe die echten IP-Adressen durch welche, die zu Dokumentationszwecken gedacht sind, ersetzt. 192.0.2.1 bzw. 2001:db8::1 wäre also mein Router.
Laut der Info in der Datei überstehen Änderungen darin keinen Reboot. Ich versuche es und die Einstellungen bleiben sehrwohl erhalten. Zur Sicherheit befolge ich aber trotzdem die Anleitung und erstelle die Datei 99-disable-network-config.cfg und befülle sie danach mit dem Text network: {config: disabled}:
Ich Benenne die Konfigurationsdatei von Netplan dann noch um, damit ich zukünftig erkenne, dass das meine Konfiguration ist und wende anschließen die Änderungen an:
Um ganz, ganz sicher zu gehen, dass alles korrekt übernommen wurde, schalte ich den Raspberry Pi aus, trenne ihn vom Netzteil, starte ihn dann neu und überprüfe die Konfiguration (ja, ich weiß, ist übertrieben):
sudo poweroff
ip a
Pi-Hole
Pi-Hole ist ein DNS-Server mit integrierter Filterung der Anfragen anhand von Blocklists. Das heißt, dass DNS-Anfragen für Domains, die bekannterweise Werbung, Spam oder Malware verbreiten, garnicht weitergeleitet werden.
Installation
Es sei angemerkt, dass die ubuntu-Version 18.04.4 von Pi-hole eigentlich (noch) nicht unterstützt wird, das sollte aber keine großen Probleme machen. Ich lade also Pi-Hole herunter und starte die Installation, dafür reicht folgender Befehl:
sudo curl -sSL https://install.pi-hole.net | bash
Ich wähle zu Anfang immer die Standardeinstellungen.
Bei der Auswahl der Blocklists wähle ich die letzte (HostsFile) ab, da diese nicht mehr zu existieren scheint.
Die nächsten Dialoge werden alle mit <Ok> beantwortet. Ist die Installation dann fertig, erscheint dieser Dialog mit dem initialen Passwort für die Admin-Weboberfläche.
Jetzt ändere ich noch das Passwort auf ein längeres und sichereres:
sudo pihole -a -p
Für den Moment bin ich mit Pi-Hole fertig, sobald Unbound läuft, muss ich hier noch ein paar Änderungen vornehmen
Unbound
Wie eingangs erwähnt, möchte ich Pi-Hole als Werbeblocker und Unbound als DNS-Server benutzen. Hierzu ein kleiner Exkurs, wie DNS im Prinzip funktioniert und warum ich Unbound verwenden möchte:
Angenommen, man tippt die URL https://blog.resch.cloud in seinen Browser, so fragt dieser das Betriebssystem, ob es die Domain kennt, also weiß, was die IP-Adressen dahinter sind. Kennt das Betriebssystem die Adressen nicht, so fragt es den dort eingestellten DNS-Server (z.B. den Router). Kennt auch dieser die Antwort nicht, fragt er den in ihm eingetragenen Server, z.B. Google (8.8.8.8 bzw. 2001:4860:4860::8888) und so weiter und so fort.
Angenommen, niemand kennt bis dahin die Domain, so endet die Anfrage bei einem der Root-Server. Dieser gibt zur Antwort, wer die Top-Level-Domain.cloud verwaltet. Also wird dann dieser Server befragt, und der weiß, welcher Nameserver .resch.cloud verwaltet und dieser kennt dann die ganze Antwort, also die IP-Adressen von blog.resch.cloud.
Der Haken an dieser Sache ist, dass alle diese Server und deren Besitzer dann bescheid wissen, wer wann von wo welche Adressen aufruft.
Unbound ist ein Stück Software, das direkt die Root-Server befragt und damit alle Zwischenschritte überspringt. Somit wissen nur diejenigen über meine Anfragen bescheid, die auch tatsächlich eine Antwort darauf geben können.
Installation
Mit folgendem Befehl lade und installiere ich Unbound. Falls am Ende der Installation ein Fehler auftritt, liegt das wahrscheinlich an der noch fehlenden Konfiguration, was in Kürze behoben wird.
sudo apt install unbound
Konfiguration
Dann lade ich die Liste der Root-Server herunter und verschiebe sie an einen Ort, wo Unbound sie erwartet (diese Liste sollte alle paar Wochen bis Monate aktualisiert werden, weiter unten automatisiere ich diesen Prozess):
Ich erstelle eine Konfigurationsdatei namens pi-hole.conf unter /etc/unbound/unbound.conf.d/ entsprechend dieser Anleitung und passe sie so an, dass Unbound fürs Erste direkt und von überall als DNS-Resolver verwendbar ist (Die letzten vier Zeilen). Die Option do-ip6 bezieht sich lediglich darauf, ob unbound die Root-Server auch per IPv6 kontaktiert, ist also nur sinnvoll, wenn man IPv6-Konnaktivität zum Internet hat. Die Option hat keinen Einfluss darauf, welche Adressfamilien aufgelöst werden!
Die Konfiguration sieht dann in etwa so aus:
server:
# If no logfile is specified, syslog is used
logfile: "/var/log/unbound/unbound.log"
verbosity: 0
port: 5353
do-ip4: yes
do-udp: yes
do-tcp: yes
# May be set to yes if you have IPv6 connectivity
do-ip6: yes
# Use this only when you downloaded the list of primary root servers!
root-hints: "/var/lib/unbound/root.hints"
# Trust glue only if it is within the server's authority
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no
# Reduce EDNS reassembly buffer size.
# Suggested by the unbound man page to reduce fragmentation reassembly problems
edns-buffer-size: 1472
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 1m
# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fc00::/7
private-address: fe80::/10
interface: 0.0.0.0
interface: ::0
access-control: 0.0.0.0/0 allow
access-control: ::/0 allow
Ich starte den Dienst. Falls das fehlschlägt, sind in der Konfiguration wahrscheinlich noch Fehler, die man mit unbound-checkconf finden kann.
sudo service unbound start
Ein kurzer Test auf einer anderen Linux-Maschine zeigt, dass die Namensauflösung funktioniert, am PC funktioniert es jedoch nicht. Wie üblich hat Windows scheinbar ein paar Eigenheiten (Bugs), das stellt aber momentan kein Problem dar.
DNSSEC
DNSSECist ein Mittel, um die Echtheit von DNS-Daten zu gewährleisten.
Eine ausführlichere Erklärung abgeben zu können, möchte ich mir nicht anmaßen, daher folgendes Video:
Abschließend teste ich die Validierung durch DNSSEC mit den folgenden Befehlen. Der erste soll den Status „SERVFAIL“ zurückgeben, der zweite „NOERROR„. Das ganze wiederhole ich per IPv6.
Nachdem Unbound nur auf Anfragen von Pi-Hole antworten soll, passe ich die Konfiguration entsprechend an, indem ich die letzten vie Zeilen mit # auskommentiere und Unbound neu starte.
Jetzt muss Pi-Hole noch seine Anfragen an Unbound richten, daher werde ich die Konfiguration jetzt abschließen.
Konfiguration
Ich rufe die Weboberfläche von Pi-Hole unter http://ip/admin auf und melde mich an.
Unter Settings -> DNS deaktiviere ich alle vorgegebenen Anbieter und trage die IP-Adressen und Ports von Unbound ein, also die localhost-Adressen und den Port 5353.
Die Option Use DNSSEC lasse ich deaktiviert, nachdem das Unbound ohnehin macht.
Die Option Use Conditional Forwarding aktiviere ich und trage ein, dass alle Anfragen an die Domain resch.cloud nicht zu Unbound sondern an meinen Router geleitet werden sollen. Nachdem ich die Domain resch.cloud auch für mein internes Netzwerk verwende, stelle ich so sicher, dass auch diese Anfragen richtig aufgelöst werden können.
Leider funktioniert das in der Weboberfläche von Pi-hole nur für IPv4. Außerdem funktioniert Reverse DNS so nur für IPv4-Adressen in einem /24-Subnetz der angegeben Router-Adresse (hier wäre das 192.0.2.0/24).
Use Conditional Forwarding ändert die Datei /etc/dnsmasq.d/01-pihole.conf. Zusätzliche Konfigurationen kann man unter /etc/dnsmasq.d/ anlegen. Ich erstelle also eine neue Datei:
sudo nano /etc/dnsmasq.d/pihole-custom.conf
Diese befülle ich folgendermaßen an, sodass alle PTR-Anfragen für übliche private Adressbereiche an meinen Router weitergegeben werden (Der Router hat in diesem Beispiel die Adressen 192.0.2.1 und fc00::1):
# Diese Datei ergänzt die von pihole erstellte 01-pihole.conf.
# Folgende Zeile aktiviert die Erreichbarkeit von pihole aus anderen als dem lokalen Netz.
# Siehe dazu 'Ignoring query from non-local network'
# unter https://docs.pi-hole.net/ftldns/dnsmasq_warn/
interface=eth0
# Folgende Zeilen geben den lokalen Router als Server für Reverse-DNS-Abragen für private Adressen an.
rev-server=fc00::/7,fc00::1
rev-server=192.168.0.0/16,192.0.2.1
rev-server=172.16.0.0/12,192.0.2.1
# Folgende Zeile erweitert die Option 'Use conditional forwarding' von der Weboberfläche um die IPv6-Adresse des Routers:
server=/resch.cloud/fc00::1
sudo pihole restartdns
Der Raspberry Pi müsste jetzt aus dem gesamten Netzwerk per IPv4 und IPv6 über den Standardport als DNS-Server nutzbar sein und somit habe ich mein primäres Ziel erreicht.
Die erste Abfrage dauert erwartungsgemäß sehr lange, da sie ja direkt an den ROOT-Server geht. Ab der zweiten Anfrage pro Domain ist die Antwortzeit wieder normal.
Optionale Schritte
Firewall
Mit folgenden Befehlen erlaube ich SSH, DNS, HTTP und HTTPS auf der Firewall und aktiviere diese anschließend. Alles andere wird automatisch blockiert.
Falls ufw noch nicht installiert ist, muss dies vorher noch erledigt werden:
sudo apt install ufw
root-hints automatisch aktualisieren
Um die Liste der ROOT-Nameserver (root-hints) automatisch zu aktualisieren, erstelle ich ein Skript namens root-hints-update.sh mit folgendem Inhalt in meinem home-Verzeichnis.
wget -O root.hints https://www.internic.net/domain/named.root
mv root.hints /var/lib/unbound/
service unbound restart
Jetzt erstelle ich noch einen Crontab-Eintrag (Zeitplan), der das Skript wöchentlich ausführt. Da es mit root-Rechten ausgeführt werden muss, erstelle ich auch den Crontab-Eintrag mit sudo.
Nachdem ich Apache schon etwas kenne und auch aus Interesse möchte ich den mit Pi-Hole mitinstallierten Webserver lighttpd durch Apache ersetzen. Nachdem ich dann auch TLS1.3 verwenden möchte und die letzte offiziell von Ubuntu 18.04.4 unterstützte Apache-Version das noch nicht kann, verwende ich ein alternatives Repository von Ondřej Surý. Dadurch wird derzeit die Apache-Version 2.4.41 installiert.
Edit (5.6.2020): Ab Ubuntu 20.04 ist die Verwendung des alternativen Repository nicht mehr nötig.
Ab Apache 2.4.36 und OpenSSL 1.1.1 wird TLS1.3 unterstützt.
Das www-Verzeichnis von Apache ist gleich wie das von lighttpd, somit muss ich hier nichts ändern. Die Admin-Weboberfläche von Pi-Hole wird jetzt schon von Apache ausgeliefert, ist mangels PHP aber noch etwas kaputt.
Falls PHP noch nicht instelliert ist, muss man das vorher noch machen:
apt install php
Danach müsste die Weboberfläche in Ordnung sein und der alte Webserver lighttpd kann entfernt werden.
sudo apt remove lighttpd
Falls die Weboberfläche noch nicht in Ordnung ist, muss das Apache-Modul PHP noch installiert werden. Es muss der installierten PHP-Version entsprechen, daher frage ich diese ab und installiere dann das Modul.
php -v
sudo apt install libapache2-mod-php7.2
Einige Dinge auf der Weboberfläche funktionieren jetzt wahrscheinlich noch nicht und man erhält die Fehlermeldung „Attempt to write a readonly database„. Das liegt an fehlenden Gruppenzuordnungen, diese erstelle ich mit folgenden Befehlen, dann starte ich Pi-hole und apache neu.
Nachdem ich eine außerordentliche Abneigung gegen HTTP (ohne S) und durchgestrichene Schlösser habe, richte ich einen Domainnamen im Router ein und erstelle ein passendes TLS-Zertifikat in XCA.
Ich exportiere das Zertifikat als .crt und den privaten Schlüssel als .pem und lege beides unter /etc/ssl/ ab. Dazu benutze ich WinSCP. Um den privaten Schlüssel zu schützen, ändere ich die Dateiberechtigung auf -rw——- (600).
sudo chmod 600 /etc/ssl/dns-vie.resch.cloud.pem
Anschließend muss Apache konfiguriert werden. Dazu muss zuerst das Modul SSL aktiviert werden:
sudo a2enmod ssl
Dann wird die Konfiguration des Virtual Hosts angepasst. In meinem Fall gibt es nur einen, daher benutze ich die Standard-Konfigurationsdatei /etc/apache2/sites-enabled/000-default.conf und passe sie folgendemaßen an (alles auskommentierte habe ich hier entfernt):
Erstens leite ich alle Anfragen, die per HTTP kommen, auf den HTTPS-Port um, zweitens gebe ich die Speicherorte des Zertifikats und des privaten Schlüssels an und drittens deaktiviere ich alle alten und unsicheren Protokolle, sodass nur TLS1.2 und TLS1.3 übrig bleiben. Dann starte ich Apache neu und die ganze Sache ist erledigt.
sudo service apache2 restart
Pi-Hole-Update
Hat man lighttpd NICHT durch einen anderen Webserver ersetzt, kann man Pi-Hole mit folgendem Befehl aktualisieren.
sudo pihole -up
In dem hier beschriebenen Fall geht das nicht, weil das Update-Programm lighttpd natürlich nicht finden kann. Daher muss man vor einem Update die Datei /etc/pihole/setupVars.conf bearbeiten und die entsprechende Zeilen fogendermaßen anpassen.
INSTALL_WEB_SERVER=false
LIGHTTPD_ENABLED=false
Auch die Datei /etc/dnsmasq.d/01-pihole.conf muss danach eventuell wie bei der Installation neu editiert werden.
Fazit
Mein Ziel, einen Pi mit Pi-Hole und Unbound aufzusetzen habe ich erreicht. Zusätzlich habe ich in den rund 14 Stunden, die ich brauchte, um mir diese Vorgehensweise zu erarbeiten und zu dokumentieren sehr viel neues Wissen aufgebaut. Eigentlich wäre das ganze innerhalb von ca. 3 Stunden irgendwie funktionsfähig gewesen aber von ordentlich, dokumentiert, lehrreich und nachvollziehbar hätte man dann nicht sprechen können.
Daher habe ich zuerst die einzelnen Komponenten installiert und konfiguriert dafür jeweils immer wieder mit einem frischen Image begonnen.
Anfangs habe ich damit begonnen, zuerst Unbound und erst danach Pi-Hole zu installieren, was mehrfach gescheitert ist, da es während der Installation von Pi-Hole immer wieder Probleme mit der Namensauflösung gab und so Installationsdateien nicht heruntergeladen worden sind.
So konnte ich die Zusammenhänge besser nachvollziehen und verstehen, unsaubere konfigurationen vermeiden und dafür sorgen, dass jeder mit der ausreichenden Motivation anhand dieses Artikels dasselbe Ziel erreichen kann.
Update auf Ubuntu 20.04 (Nachtrag von Juli 2023)
Ja, es ist 2023 und ich mache ein Update von 18.04 auf 20.04 obwohl es schon 22.04 gibt. Lebt damit. Ich bin auch nur ein Mensch. Im Folgenden halte ich mich kurz und protokolliere meine Schritte ohne viel Blabla.
Weboberfläche geht, DNS-Anfragen werden aber noch nicht beantwortet. Pi-hole diagnosis im Webinterface zeigt den Fehler FTL failed to start due to cannot access /etc/dnsmasq.d/lxd: No such file or directory. Eine Google-Suche ergibt folgenden Lösungsweg, der in meinem Fall funktioniert.
sudo rm /etc/dnsmasq.d/lxd
sudo pihole -r
Das schönste Gefühl bei derartigen Sachen ist, wenn man einen Befehl ausführt und Sekunden Später am Handy die Push-Notification vom Monitoring ankommt, dass das der Dienst weider UP ist. Pihole läuft somit wieder.
Wenn du Feedback loswerden möchtest, nutze bitte das Kontaktformular.
Falls dir mein Beitrag weitergeholfen hat, würde ich mich sehr über einen kleinen Kaffee freuen. Oder du nutzt einen meiner Empfehlungslinks und sparst dir damit etwas Geld: Tesla (500€ Rabatt), Hetzner Cloud (20€ Guthaben), Ufodrive (30€ Rabatt). Außerdem habe ich eine Wunschliste bei Amazon.
Related
One Reply to “Raspberry Pi mit Pi-Hole und Unbound DNS-Server”
Kürzlich hatte ich bei einer meiner Unbound-Installationen das Problem, dass die Datei „/var/lib/unbound/root.key“ scheinbar spontan verschwunden ist und sich Unbound somit nicht mehr starten ließ. Die Fehlermeldung lautete unter anderem „error reading auto-trust-anchor-file: /var/lib/unbound/root.key“.
Mit dem Befehl „sudo unbound-anchor“ konnte ich den key neu erstellen und die Installtion lief wieder.
Kürzlich hatte ich bei einer meiner Unbound-Installationen das Problem, dass die Datei „/var/lib/unbound/root.key“ scheinbar spontan verschwunden ist und sich Unbound somit nicht mehr starten ließ. Die Fehlermeldung lautete unter anderem „error reading auto-trust-anchor-file: /var/lib/unbound/root.key“.
Mit dem Befehl „sudo unbound-anchor“ konnte ich den key neu erstellen und die Installtion lief wieder.