🏠 Linux-Infrastruktur im Eigenbetrieb
Zwei Debian-Server (Raspberry Pi 4) im 24/7-Betrieb. Ziel: Dienste sicher aus dem Internet erreichbar machen, ohne einen einzigen Port am Router zu öffnen – und den Betrieb so absichern, dass ein Ausfall auffällt und sich beheben lässt. Diese Website läuft auf dieser Infrastruktur.
Aufbau
- Dienste: Webserver (nginx), Passwort-Manager (Vaultwarden), DNS-Filter (AdGuard Home), Datei-Freigabe, Monitoring (Uptime Kuma, Netdata) – alle als Docker-Container, verwaltet mit Compose und Portainer.
- Erreichbarkeit: Veröffentlichung über Cloudflare Tunnel (Zero Trust) statt Portweiterleitung; Fernwartung über Tailscale mit Subnet-Router ins Heimnetz.
- Zweiter Server: übernimmt Monitoring und nimmt die Backups des ersten Servers entgegen.
Sicherheit
- SSH nur mit Schlüssel, Passwort- und Root-Login abgeschaltet; fail2ban gegen Brute-Force.
- TLS ≥ 1.2, HSTS und Security-Header inkl. Content-Security-Policy für die Website.
- Öffentlich erreichbarer Container ohne Root-Rechte, mit schreibgeschütztem Dateisystem und Prozesslimit.
- Geheimnisse (API-Tokens) getrennt von Skripten in Dateien, die nur der Dienst-Benutzer lesen kann.
Backup & Monitoring
- Bash-Skript per Cron: konsistenter Datenbank-Snapshot, Archiv der Nutzdaten plus Systemarchiv (Konfiguration, Crontabs, Container-Inventar).
- Der Zweitserver holt die Archive über einen nur lesenden rsync-Zugang ab, prüft ihre Integrität und rotiert alte Stände.
- Meldung bei Erfolg oder Fehler per Messenger; Uptime Kuma schlägt Alarm, wenn ein Backup ganz ausbleibt.
- Tägliche Netzwerk-Inventarisierung mit nmap/ndiff – neue Geräte oder offene Ports werden gemeldet.
Gelernt
Eine Sicherheitsprüfung der eigenen Infrastruktur zeigte u. a. einen öffentlich erreichbaren Dienst mit zu weiten Rechten, Backup-Dateien im Web-Verzeichnis und eine Datenbank in einem flüchtigen Docker-Volume. Alles behoben, dokumentiert und ins Backup-Konzept übernommen – seitdem prüfe ich Änderungen gezielt von außen nach.