Wie ich meinen Homeserver wirklich abgesichert habe

Es gibt diesen Moment, wenn man einen eigenen Server betreibt und alles „läuft“. Nextcloud synchronisiert, Paperless archiviert Dokumente, Docker-Container schnurren leise vor sich hin. Man lehnt sich zurück und denkt: passt.

Und dann startet man aus Neugier einen externen Nmap-Scan.

Dieser eine Moment verändert alles. Denn plötzlich sieht man den eigenen Server aus der Perspektive des Internets. Nicht aus der gewohnten Admin-Sicht, sondern so, wie ihn Bots, Scanner und automatisierte Angriffe sehen. Und das Internet schaut ständig.

Der ehrliche Blick von außen

Der Scan zeigte nichts Dramatisches – aber auch nichts, das man ignorieren sollte. SSH war offen. DNS reagierte. Web natürlich auch. Alles funktional korrekt. Aber die entscheidende Frage war nicht: „Ist das falsch?“ sondern: „Ist das wirklich nötig?“

Security beginnt nicht mit Panik. Sie beginnt mit Klarheit.

WireGuard – die wichtigste Entscheidung

Der größte Hebel war am Ende nicht irgendein Tool, sondern eine strukturelle Entscheidung: SSH gehört nicht ins öffentliche Internet.

Stattdessen wurde WireGuard zur Grundlage der Administration. Kein direkter Zugriff mehr von außen. Kein offener Port 22 für die Welt. Wer administrieren will, geht durch das VPN. Punkt.

Das fühlt sich nicht nur besser an – es ist es auch. Die Angriffsfläche schrumpft sofort drastisch. Brute-Force-Versuche? Praktisch irrelevant. Der Server existiert für das Internet weiterhin, aber seine Administration ist nicht mehr sichtbar.

Firewall heißt nicht nur „Port offen oder zu“

Mit UFW wurde die Logik klar formuliert: Alles, was nicht ausdrücklich erlaubt ist, ist verboten. HTTP und HTTPS bleiben offen – sie müssen es sein. WireGuard ebenso. Aber SSH nur noch im LAN und im VPN-Netz. DNS ebenfalls.

Interessant wurde es bei Docker. Docker arbeitet mit eigenen iptables-Regeln, und genau hier merkt man, wie komplex moderne Server-Architektur ist. Eine Firewall-Regel reicht nicht, wenn darunter noch ein anderes Subsystem eigene Regeln setzt. Also wurde auch die DOCKER-USER-Chain bewusst geprüft und kontrolliert.

Sicherheit ist kein einzelner Schalter. Sie ist ein Zusammenspiel.

DNS – das stille Risiko

DNS ist unscheinbar. Man denkt selten darüber nach. Aber ein offener Resolver kann missbraucht werden. Also wurde Unbound so konfiguriert, dass er ausschließlich lokal lauscht. Pi-hole greift intern darauf zu. Von außen kommt nichts mehr durch.

Ein tcpdump auf dem WAN-Interface bestätigte das: Keine externen DNS-Anfragen. Kein Open Resolver. Das war ein kleiner, aber wichtiger Sieg.

Die Sache mit den Security Headern

Ein eher technisches, aber typisches Problem: doppelte HTTP-Security-Header. Apache setzt welche, Django setzt welche, vielleicht noch ein Plugin – am Ende kommen widersprüchliche Werte zurück.

Die Lösung war simpel, aber konsequent: Alles entfernen. Zentral neu definieren. Einmal. Klar. Einheitlich.

Solche Details wirken klein. Aber sie zeigen, ob ein System bewusst konfiguriert wurde oder einfach gewachsen ist.

Fail2Ban – wenn jemand doch anklopft

Selbst mit VPN, Firewall und restriktiven Regeln gibt es immer noch Login-Versuche. Bots probieren es trotzdem. Fail2Ban sorgt dafür, dass solche Versuche nicht folgenlos bleiben.

Mehrere Fehlversuche? IP wird gesperrt. Automatisch. Für Stunden oder Tage. Das ist keine Panikreaktion – das ist Hygiene.

Fail2Ban ist kein Ersatz für saubere Architektur. Aber es ist ein hervorragender Wächter.

Proxmox Firewall – Sicherheit auf einer weiteren Ebene

Der vielleicht wichtigste Schritt war am Ende die zusätzliche Absicherung direkt auf Hypervisor-Ebene. Die Proxmox-Firewall filtert bereits, bevor eine VM überhaupt angesprochen wird.

Das bedeutet: Selbst wenn in einer VM etwas falsch konfiguriert wäre, existiert eine vorgelagerte Schutzschicht. Sicherheit in Ebenen – genau so sollte es sein.

WAN → Proxmox → VM → Dienst. Jede Schicht kann blockieren.

Ein kurzer Ausflug zur Performance

Zwischendurch wurde das Internet über WireGuard plötzlich langsamer. Kein Sicherheitsproblem – sondern eine MTU-Frage. Auch das gehört dazu: Härtung darf Performance nicht ruinieren. Security muss praktikabel bleiben.

Was am Ende wirklich entstanden ist

Es war kein einzelner Fix. Kein heroischer „Sicherheits-Moment“. Sondern eine Reihe von Entscheidungen, die zusammen ein Konzept ergeben:

Administration läuft nur über VPN. DNS ist strikt intern. Firewall-Regeln sind klar. Docker wird kontrolliert. HTTP-Header sind konsistent. Fail2Ban reagiert dynamisch. Und die Proxmox-Firewall sorgt für eine zusätzliche Schutzschicht.

Das ist keine militärische Absicherung. Aber es ist eine bewusste.

Warum das wichtig ist

Ein Homeserver ist kein Spielzeug. Er speichert Daten, Dokumente, Projekte. Vielleicht Familienfotos. Vielleicht Kundendaten. Vielleicht Ideen.

Man betreibt ihn aus Leidenschaft – aber man trägt Verantwortung dafür.

Und genau deshalb fühlt sich dieser Zustand jetzt anders an. Ruhiger. Klarer. Bewusster.

Sicherheit ist kein Zustand. Sie ist Architektur.