Linux-Server-Hardening für kleine Teams: Die praktische Basis

Ein Linux-Server kann ruhig wirken und trotzdem nur einen Fehler vom nächsten Problem entfernt sein. Beim Hardening geht es nicht darum, ein exotisches System zu bauen. Es geht darum, einfache Angriffswege zu schließen, Änderungen sichtbar zu machen und eine Wiederherstellung möglich zu halten.

Diese Basis sollte stehen, bevor ein Server echten Kundendatenverkehr verarbeitet.

1. Mit der Zugriffskontrolle beginnen

Viele Vorfälle beginnen mit Zugängen, die zu weitreichend, zu alt oder zu leicht zu erraten sind.

Die Mindestbasis:

• Passwort-Anmeldungen für SSH deaktivieren und nur Schlüssel verwenden
• direkte Root-Anmeldungen deaktivieren
• persönliche Benutzerkonten statt gemeinsamer Admin-Konten einsetzen
• Admin-Benutzer einer kontrollierten sudo-Gruppe zuordnen
• ungenutzte Benutzer und alte Schlüssel entfernen
• MFA nutzen, wenn die umgebende Plattform dies unterstützt

Gutes SSH-Hardening ist unspektakulär. Genau das ist der Zweck. Niemand sollte sich mit einem alten Passwort von einem vergessenen Laptop anmelden können.

2. Alles schließen, was nicht gebraucht wird

Ein Server sollte Dienste nicht allein deshalb veröffentlichen, weil ein Paket sie installiert hat.

Lauschende Ports lassen sich so prüfen:

ss -tulpn

Danach gilt eine einfache Regel: Nur notwendige öffentliche Dienste sind aus dem Internet erreichbar. Alles andere bleibt lokal, privat oder blockiert.

Typische öffentliche Ports:

• 80 und 443 für Web-Traffic
• 22 nur, wenn SSH öffentlich erreichbar sein muss, möglichst auf IP oder VPN begrenzt
• Anwendungsports nur hinter einem Reverse-Proxy

3. Updates mit Wartungsfenster einspielen

Automatische Updates sind nützlich, aber Produktivserver brauchen einen Plan. Kernel-Updates, Datenbankpakete und Runtime-Upgrades können die Verfügbarkeit beeinflussen.

Ein sinnvoller Update-Ablauf umfasst:

• schnelle Installation von Sicherheitsupdates
• regelmäßige Wartungsfenster für riskantere Updates
• Erfassung notwendiger Neustarts
• Rollback-Hinweise für kritische Dienste
• eine verantwortliche Person, die das Ergebnis prüft

Der gefährliche Zustand lautet nicht "manuelle Updates". Gefährlich ist, wenn niemand weiß, ob Updates überhaupt stattfinden.

4. Grundlegenden Laufzeitschutz ergänzen

Hardening reduziert die Angriffsfläche. Laufzeitschutz hilft, wenn trotzdem etwas den Server erreicht.

Nützliche Schutzmaßnahmen:

• Host-Firewall nach dem Default-Deny-Prinzip
• CrowdSec oder vergleichbare verhaltensbasierte Blockierung
• Fail2ban als einfacher Brute-Force-Schutz, wenn es zum System passt
• Reverse-Proxy mit solider TLS-Konfiguration
• Rate Limits für sensible Endpunkte

Diese Maßnahmen dürfen normale Nutzer nicht aussperren. Konservativ starten, beobachten und anschließend gezielt verschärfen.

5. Relevante Ereignisse protokollieren

Wenn ein Server kompromittiert wurde, machen fehlende Logs aus einem technischen Problem ein Ratespiel.

Mindestens erfasst werden sollten:

• Authentifizierungsprotokolle
• sudo-Aktivitäten
• Zugriffs- und Fehlerlogs des Webservers
• Anwendungsfehler
• Signale zu Systemressourcen
• Security-Warnungen aus Wazuh, CrowdSec oder vergleichbaren Werkzeugen

Logs sollten den Server verlassen oder zumindest an eine zentrale Stelle übertragen werden. Kontrolliert ein Angreifer die einzige Kopie, ist der Beweiswert gering.

6. Backups sind erst nach einem Restore-Test fertig

Ein Backup-Job, der nie wiederhergestellt wurde, ist eine Hoffnung und noch kein Wiederherstellungsplan.

Für jeden wichtigen Dienst sollte dokumentiert sein:

• was gesichert wird
• wo die Sicherung liegt
• wie oft sie läuft
• wie lange sie aufbewahrt wird
• wer sie wiederherstellen kann
• wann der letzte Restore-Test erfolgreich war

Kleine Teams brauchen keine schwerfälligen Enterprise-Prozesse. Sie brauchen den Nachweis, dass die Wiederherstellung funktioniert.

7. Überwachen, bevor sich Nutzer beschweren

Monitoring sollte drei Fragen beantworten:

1. Ist der Server erreichbar?
2. Funktioniert der Dienst?
3. Verändern sich Security-Signale?

Ein praktischer Stack kann Zabbix für Infrastrukturmetriken, Wazuh für Security-Ereignisse auf dem Host und CrowdSec für Signale zu feindlichem Traffic enthalten. Die konkrete Werkzeugwahl ist weniger wichtig als die Abdeckung und Qualität der Alarme.

Eine einfache Checkliste für den Produktivstart

Vor dem Start sollte Folgendes bestätigt sein:

• [ ] Nur SSH-Schlüssel, Root-Anmeldung deaktiviert
• [ ] Firewall erlaubt ausschließlich notwendige Ports
• [ ] Updates sind geplant und einer Person zugeordnet
• [ ] Backups laufen und der Restore wurde getestet
• [ ] Logs werden zentral gesammelt
• [ ] Monitoring prüft den Zustand des Dienstes
• [ ] Security-Alarme erreichen eine verantwortliche Person
• [ ] Administrative Zugänge sind dokumentiert

Fazit

Hardening ist keine einmalige Einrichtung. Es ist eine Betriebsroutine. Der sicherste Server ist der, bei dem Zugänge, Updates, Monitoring und Wiederherstellung laufend geprüft werden und nicht erst nach einem Ausfall.

Fehlt dem Team die Zeit für diese Routine, ist laufender Betrieb meist günstiger als die Aufräumarbeiten nach einem Notfall.