Ein Gerät mit einer kritischen Aufgabe
Angefangen hat es mit dem Vokabeltrainer, der von unterwegs unter einer richtigen Adresse erreichbar sein sollte, mit gültigem Zertifikat. Dabei wurde mir klar, was auf dem kleinen Rechner eigentlich schon lief: Pi-hole beantwortet die Namensauflösung aller Geräte im Haus, die FRITZ!Box verteilt ihn per DHCP als DNS-Server. Der Werbefilter ist dabei nur die Zugabe. Wichtiger ist, dass hier ein zentraler Infrastrukturdienst läuft.
Nach dem Umzug vom alten Raspberry Pi 3 auf einen Pi 5 mit SSD habe ich nachgezählt, ob kein Gerät abgehängt wurde: In 24 Stunden kamen 65.805 Anfragen von 32 Geräten aus beiden Teilnetzen, 9.430 davon gefiltert. Die Zahlen stammen aus einer Abfrage auf die Datenbank des DNS-Dienstes, nicht aus der Oberfläche. Den alten Pi habe ich als Rückweg unangetastet in den Schrank gelegt.
Webserver mit eigener Domain
nginx liefert drei Websites unter eigener Domain aus, mit Let's-Encrypt-Zertifikaten, die sich selbst erneuern. Drei Regeln stecken dahinter, die man leicht übersieht:
- Drei Serverblöcke statt einer Umleitung. Eine einfache Regel „alles auf HTTPS“ hätte das Heimnetz kaputtgemacht: Wer den Pi über seine IP aufruft, landet sonst bei einer Zertifikatswarnung, denn das Zertifikat gilt für den Namen, nicht für die Adresse.
- Fremde Namen bekommen nichts. Anfragen ohne passenden Hostnamen beendet nginx ohne Antwort.
- Der Prüfpfad für Let's Encrypt bleibt offen, auch nach der Umstellung auf HTTPS. Sonst scheitert die automatische Verlängerung nach drei Monaten, und zwar still.
Für den CCNA-Trainer erkennt eine eigene Regel 49 KI-Crawler, SEO-Werkzeuge und Scanner am User-Agent und sperrt sie aus. Anlass war ein Crawler, der den ganzen Fragenkatalog abgeholt hatte. Ein Browser bekommt die Seite weiter, ebenso Werkzeuge wie curl, mit denen ich selbst nach dem Hochladen prüfe.
Sicherheitsupdates: automatisch, aber nicht überall
Das realistische Risiko für einen Server am Internet ist nicht der Scanner, der WordPress-Pfade abklopft. Es ist eine ungepatchte Lücke in einer der Komponenten, während genau danach automatisiert gesucht wird. Deshalb kommen die Sicherheitsupdates der Distribution automatisch. Neu gestartet wird von Hand, nach Entscheidung und nicht nach Zeitplan. Ein Kernel, der im Hintergrund wechselt und beim nächsten Start nicht hochkommt, wäre auf dem Gerät mit dem zentralen DNS ein schlechter Tausch.
Zugriffsstatistik ohne Einwilligungsbanner
Für die Statistik habe ich mich gegen die üblichen Werkzeuge entschieden, die per JavaScript im Browser messen. Stattdessen wertet GoAccess stündlich die Serverprotokolle aus. Das kommt ohne Cookies und ohne Banner aus, ändert nichts an den Seiten und zählt auch Besucher, die JavaScript blockieren. Das sind hier die meisten, denn der Großteil der Zugriffe stammt von automatischen Scannern. Die Auswertung führt einen eigenen Bestand, weil die Protokolle nach zwei Wochen gelöscht werden. Sonst gäbe es nie mehr als zwei Wochen Historie.
Was noch darauf läuft
Suchmaschine
SearXNG im Docker-Container, nur im Heimnetz. Meine lokalen KI-Assistenten suchen darüber im Web, ohne Konto bei einem Anbieter.
Lichtsteuerung
Ein Node.js-Dienst, der beim Booten startet und sich nach einem Absturz selbst neu startet.
Zugang für KI-Assistenten
Ein eigener Benutzer ohne root, nur mit Schlüssel. Er darf Logs lesen und drei Web-Ordner pflegen, vor jedem Überschreiben entsteht eine Sicherung.
Weil inzwischen mehrere Wege Dateien auf den Pi bringen, prüft ein Abgleich vor jedem Hochladen, ob dort jemand am vorgesehenen Weg vorbei etwas geändert hat. Erst dann wird überschrieben.
Was schiefging und was ich daraus geändert habe
- Der Filter meldete „aktiv“ und filterte nichts. Nach einer Migration hatte der Dienst seine Datenbank in der falschen Reihenfolge geöffnet. Sichtbar wurde das nur, weil ich dieselbe Abfrage zusätzlich gegen die alte, noch laufende Maschine gestellt habe. Seitdem lasse ich bei Migrationen den Vorgänger stehen, bis der Nachfolger gegen ihn geprüft ist.
- Ein Indiz, das nichts unterscheidet. Ob die Domain per DynDNS nachgeführt wird, wollte ich an der kurzen Gültigkeitsdauer des DNS-Eintrags ablesen. Später zeigte sich: Dieselbe Dauer hatte auch ein garantiert fester Eintrag. Ein Indiz taugt nur, wenn es zwischen den beiden Möglichkeiten trennen kann. Jetzt gibt es ein kleines Prüfskript, das die echte öffentliche Adresse mit dem DNS-Eintrag vergleicht. Gegengeprüft habe ich es mit einer bewusst falschen Domain, sonst wäre nicht belegt, dass es eine Abweichung überhaupt bemerkt.
- Strom weg mitten im Betrieb. Das Protokoll endete ohne Herunterfahren, fünf Minuten später startete der Pi neu. Ursache war ein getauschter Powerline-Adapter, an dessen Steckdose der Pi hängt. Seitdem gilt: vorher sauber herunterfahren. Erkennen lässt sich so etwas daran, dass am Ende des vorherigen Bootprotokolls die Meldungen zum Herunterfahren fehlen.
Die Serverkonfiguration liegt nur auf dem Pi, Git sieht sie nicht. Ein Skript holt nginx-Dateien, Prüfskripte und eine Übersicht über Ports, Zertifikate und Zeitpläne auf meinen Rechner, danach wird committet. Private Schlüssel bleiben außen vor.
Technik
| Teil | Womit |
|---|---|
| Gerät | Raspberry Pi 5 mit 8 GB RAM, Debian 13, Start von einer USB-SSD statt SD-Karte, nur per Kabel im Netz |
| DNS | Pi-hole 6 mit vier Filterlisten, wöchentlich aktualisiert |
| Web | nginx, certbot mit automatischer Erneuerung, eigene Zugriffsprotokolle je Seite |
| Domain | bei Strato, nachgeführt per DynDNS über die FRITZ!Box, weitere Namen als CNAME |
| Container | Docker nur für SearXNG |