Security-Hardening für Homelab und VPS: Weniger Hokuspokus, mehr Effekt

Früher war es selbstverständlich: Ein paar Logs durchforsten, ein paar Regex-Muster schreiben, und schon hatte man eine Firewall-Regel, die jeden x-ten Scanversuch blockiert. Fail2ban war der De-facto-Standard – einfach, lokal, und für die meisten Fälle ausreichend. Doch irgendwann merkt man: Diese lokale Logik hat einen entscheidenden Nachteil. Sie reagiert nur auf das, was bereits passiert ist. Und selbst dann oft zu spät.

Heute setze ich auf CrowdSec. Nicht weil es modern klingt, sondern weil es einen fundamentalen Unterschied macht: Es nutzt die kollektive Intelligenz einer globalen Community, um Angriffsversuche zu erkennen – noch bevor sie mein eigenes System erreichen. Das ist kein Marketing-Sprech, sondern ein Paradigmenwechsel. Und gleichzeitig bleibe ich bei den Basics: Firewall-Regeln, die pro Dienst funktionieren, und SSH-Zugang nur mit Schlüsseln. Denn dort liegt der größte Effekt.

Warum CrowdSec die bessere Wahl ist als fail2ban

Fail2ban ist ein solides Werkzeug – solange man akzeptiert, dass es nur das sieht, was lokal passiert. Ein Angreifer probiert eine Liste bekannter Benutzernamen aus? Fail2ban sperrt die IP nach einigen Versuchen. Doch was, wenn dieser Angreifer bereits in dutzenden anderen Systemen versucht hat, einzudringen? Fail2ban erfährt davon erst, wenn die IP bei mir ankommt. Und selbst dann blockiert es sie nur lokal – der nächste Dienst auf meinem Server oder ein anderer Host im Netzwerk bleibt ungeschützt.

CrowdSec löst dieses Problem, indem es die Logs aller Teilnehmer analysiert und verdächtige Muster in Echtzeit an eine zentrale Datenbank sendet. Wenn eine IP in einem System versucht, einen bekannten Exploit auszuführen, wird sie global markiert – und alle CrowdSec-Installationen können diese IP sofort blockieren, bevor sie überhaupt eine Anfrage stellt. Das ist kein theoretisches Szenario: In meinem Homelab habe ich in den letzten Monaten beobachtet, wie IP-Adressen, die zuvor nur bei mir aufgetaucht sind, nach einigen Stunden auch in anderen Systemen weltweit geblockt wurden. Das spart Ressourcen, reduziert die Last auf dem eigenen System und erhöht die Sicherheit dramatisch.

Ein weiterer Vorteil: CrowdSec ist modular aufgebaut. Man kann nicht nur SSH oder Webserver überwachen, sondern auch spezifische Anwendungen wie Nextcloud oder Home Assistant. Und das Beste: Es läuft als Dienst im Hintergrund, ohne dass man ständig manuell eingreifen muss. Fail2ban war immer ein Werkzeug, das man pflegen musste – mit CrowdSec entfällt dieser Wartungsaufwand weitgehend.

Firewall-Regeln pro Dienst: Präzision statt Allzwecklösung

Die Firewall ist die erste Verteidigungslinie. Doch wie oft sieht man, dass Administratoren eine grobe Regel setzen wie „alles von Port 80 bis 443 erlauben“? Das ist so, als würde man die Haustür offenstehen lassen und hoffen, dass die Nachbarn schon aufpassen werden. Stattdessen sollte jede Firewall-Regel einem klaren Zweck dienen – und nichts anderes.

In meinem Setup nutze ich UFW (Uncomplicated Firewall) auf dem VPS und auf den Homelab-Hosts. Doch anders als üblich, habe ich die Regeln nicht nach Ports, sondern nach Diensten strukturiert. Jeder Dienst – ob Reverse Proxy, Datenbank oder API – bekommt seine eigene Regelmenge. Das hat mehrere Vorteile:

• Sichtbarkeit: Wenn eine Regel plötzlich blockiert wird, weiß ich sofort, welcher Dienst betroffen ist. Kein Herumstochern im Dunkeln mehr.
• Flexibilität: Ich kann Regeln leicht anpassen, ohne dass andere Dienste beeinflusst werden. Brauche ich für einen Test kurzzeitig mehr Zugriff? Kein Problem – eine Regel anpassen, und schon ist alles wie vorher.
• Sicherheit: Wenn ein Dienst kompromittiert wird, ist der Schaden begrenzt. Ein Angreifer kann nicht einfach lateral zum nächsten Dienst springen, nur weil beide auf dem gleichen Port laufen.

Ein konkretes Beispiel: Mein Reverse Proxy leitet Anfragen an verschiedene interne Dienste weiter. Früher hatte ich eine Regel, die alle eingehenden Verbindungen auf Port 443 erlaubte. Heute habe ich pro Dienst eine eigene Regel, die nur die tatsächlich benötigten Ports und Protokolle durchlässt. Das reduziert die Angriffsfläche enorm – und macht es gleichzeitig einfacher, Logs zu analysieren, wenn doch mal etwas schiefgeht.

SSH nur mit Schlüsseln: Der Klassiker, der immer noch underrated ist

SSH mit Passwort zu nutzen, ist wie einen Safe mit einem simplen Zahlenschloss zu sichern. Es funktioniert – aber nur, bis jemand die Kombination errät oder die Tür aufbricht. Und das passiert schneller, als viele denken. Selbst wenn man starke Passwörter verwendet, sind diese irgendwann anfällig für Brute-Force-Angriffe oder Credential-Stuffing.

Deshalb nutze ich seit Jahren nur noch SSH mit Schlüsseln. Keine Ausnahmen. Keine halbherzigen Workarounds. Und das hat mehrere Gründe:

• Kein Passwort = kein Angriffsvektor: Selbst wenn jemand die SSH-Ports scannt, kann er ohne gültigen Schlüssel nichts anrichten. Passwort-basierte Logins sind dagegen ein gefundenes Fressen für Bots.
• Zusätzliche Sicherheitsschicht: Selbst wenn ein Schlüssel kompromittiert wird, kann man ihn schnell widerrufen und durch einen neuen ersetzen. Bei Passwörtern ist das deutlich umständlicher.
• Komfort: Ja, es ist etwas umständlicher in der Einrichtung. Aber sobald es läuft, ist es deutlich bequemer als Passwörter – besonders mit Tools wie SSH-Agent oder Hardware-Keys.

Ein weiterer Punkt: Root-Login über SSH ist bei mir komplett deaktiviert. Wenn ich administrative Aufgaben erledigen muss, logge ich mich als normaler Benutzer ein und nutze sudo. Das ist ein weiterer klassischer Ratschlag, der oft ignoriert wird – aber einen enormen Sicherheitsgewinn bringt. Denn selbst wenn jemand einen Schlüssel stiehlt, kann er damit nicht direkt als Root agieren.

Zero Trust für das Homelab: Warum Perimeter keine Lösung mehr ist

Das Konzept des „Perimeters“ stammt aus einer Zeit, in der Netzwerke klar abgegrenzt waren und Angriffe von außen kamen. Heute ist diese Vorstellung längst überholt. In meinem Homelab gibt es nicht mehr „innen“ und „außen“ – sondern nur noch vertrauenswürdige und nicht vertrauenswürdige Komponenten. Und das beginnt schon bei der Authentifizierung.

Mein Passwortmanager Perun ist ein gutes Beispiel dafür. Er speichert nicht nur Passwörter, sondern auch sensible Daten wie API-Schlüssel und Zertifikate – und das alles verschlüsselt und ohne Cloud-Anbindung. Jeder Zugriff erfordert eine zweite Authentifizierungsstufe, und selbst dann wird nur das Notwendigste preisgegeben. Das ist Zero-Trust-Prinzip im Kleinen: Vertraue nichts, verifiziere alles.

Doch Zero Trust endet nicht bei der Authentifizierung. Es geht auch um die Kommunikation zwischen den Diensten. In meinem Setup läuft alles in einem privaten Netzwerk, aber selbst dort gelten strenge Regeln. Ein Dienst darf nur mit genau den anderen Diensten kommunizieren, die er wirklich braucht. Keine „vage“ Erlaubnis, kein „irgendwie wird das schon funktionieren“. Jede Verbindung wird explizit definiert – und alles andere wird blockiert. Das ist kein Overkill, sondern eine Grundvoraussetzung für ein sicheres System.

Ein weiterer Aspekt: Updates. Viele Angriffe nutzen bekannte Schwachstellen in veralteter Software aus. Deshalb setze ich auf automatische Updates für alle kritischen Dienste – aber nur, wenn sie sicher und getestet sind. Bei selbstgehosteten Lösungen wie Home Assistant oder Postiz (meinem Social-Media-Planungstool) bedeutet das, dass ich die Updates zunächst in einer Testumgebung ausprobiere, bevor sie in die Produktion gehen. Das ist kein Luxus, sondern eine Notwendigkeit.

Praktische Umsetzung: So sieht mein Setup aus

Auch wenn ich keine konkreten IP-Adressen oder Hostnamen nennen kann, will ich zeigen, wie die genannten Maßnahmen konkret aussehen. Mein Setup basiert auf drei Säulen:

• CrowdSec: Installiert auf allen Hosts – VPS und Homelab-Hardware. Es läuft im Hintergrund und blockt bekannte Angriffs-IPs automatisch. Die Konfiguration ist minimal: Man installiert das Paket, startet den Dienst und lässt es machen. Die Community-Datenbank übernimmt den Rest.
• UFW: Die Firewall ist pro Dienst konfiguriert. Jeder Dienst bekommt seine eigene Regelmenge, die nur die benötigten Ports und Protokolle zulässt. Beispiel: Mein Reverse Proxy bekommt eine Regel für HTTPS, aber keine für SSH. Ein Datenbankdienst bekommt nur Zugriff von der Anwendungsebene, nicht vom öffentlichen Internet.
• SSH: Nur Schlüssel-basiert, Root-Login deaktiviert. Zusätzlich nutze ich fail2ban für die SSH-Ports – nicht als primäre Abwehr, sondern als zusätzliche Sicherheitsschicht für den Fall, dass jemand doch versucht, Passwörter zu knacken. Aber ehrlich gesagt: Seitdem ich SSH nur noch mit Schlüsseln nutze, sehe ich kaum noch Angriffsversuche auf diesen Port.
• Zero Trust: Jeder Dienst läuft in einem eigenen Netzwerksegment oder mit eigenen Firewall-Regeln. Kommunikation zwischen Diensten ist strikt eingeschränkt. Und alle sensiblen Daten – ob Passwörter, Zertifikate oder API-Schlüssel – werden in Perun gespeichert und nur bei Bedarf freigegeben.

Ein letzter Tipp: Dokumentation. Auch wenn es verlockend ist, alles im Kopf zu behalten – irgendwann vergisst man Details. Ich halte meine Firewall-Regeln und CrowdSec-Konfiguration in einem privaten Git-Repository fest. So weiß ich jederzeit, was wo zugelassen ist – und kann Änderungen nachvollziehen.

Fazit

Security ist kein Zustand, den man einmal erreicht und dann vergisst. Es ist ein Prozess – und die besten Maßnahmen sind die, die man nicht ständig anpassen muss. CrowdSec statt fail2ban, Firewall-Regeln pro Dienst, SSH nur mit Schlüsseln: Das sind keine revolutionären Ideen, aber sie haben den größten Effekt, weil sie grundlegend und nachhaltig sind.

Fail2ban war gut, solange man lokale Logik als ausreichend betrachtete. Doch die Bedrohungslage hat sich geändert. Heute braucht man globale Intelligenz, um Angriffe zu erkennen – und lokale Präzision, um sie abzuwehren. Und genau das liefern CrowdSec und eine gut durchdachte Firewall-Strategie.

Die Basics bleiben wichtig: SSH mit Schlüsseln, Root-Login deaktiviert, Dienste isoliert. Diese Maßnahmen kosten kaum Zeit, haben aber den größten Impact. Alles andere – ob Reverse Proxy, Passwortmanager oder Zero-Trust-Prinzipien – sind nur die Kirschen auf dem Sahnehäubchen.

Und wenn ich eines gelernt habe, dann dies: Die größten Sicherheitslücken sind nicht die, die man nicht kennt – sondern die, die man ignoriert.