Linux-Server-Härtung: Grundlagen für Produktivsysteme

1. Warum die 80/20-Regel bei Server-Härtung zählt

Server-Härtung wird in vielen Teams als endlose Checkliste missverstanden: hunderte CIS-Benchmark-Punkte, die alle irgendwann abgearbeitet werden sollen. In der Praxis stammt der überwiegende Teil erfolgreicher Kompromittierungen von Linux-Servern jedoch aus einer sehr kleinen Menge an Ursachen: passwortbasiertes SSH mit schwachen oder wiederverwendeten Passwörtern, komplett offene Firewalls ohne Default-Deny, monatelang ungepatchte Pakete mit bekannten CVEs und unnötig viele installierte Dienste, die zusätzliche Angriffsfläche bieten. Wer genau diese vier Punkte konsequent abarbeitet, schließt den Großteil der real ausgenutzten Einfallstore.

Die verbleibenden theoretisch möglichen Härtungsmaßnahmen, etwa SELinux-Enforcing-Modi mit vollständigen Policies, Kernel-Härtung per sysctl bis ins letzte Detail oder komplexe AppArmor-Profile für jeden Dienst, bringen im Verhältnis zum Aufwand deutlich weniger zusätzlichen Schutz. Das heißt nicht, dass diese Maßnahmen wertlos sind, sondern dass sie erst dann sinnvoll sind, wenn die Baseline steht. Dieser Artikel konzentriert sich bewusst auf die Maßnahmen mit dem besten Verhältnis aus Aufwand und Sicherheitsgewinn und zeigt am Ende, wie man erkennt, wenn Härtung nur noch Theater ist.

2. SSH absichern: Key-only-Authentifizierung

Passwort-Authentifizierung über SSH ist die mit Abstand häufigste Eintrittstür für automatisierte Angriffe. Jeder öffentlich erreichbare Server auf Port 22 wird innerhalb weniger Minuten von Bots gescannt, die systematisch gängige Benutzernamen und Passwörter durchprobieren. Der wirksamste einzelne Schritt ist, Passwort-Login vollständig zu deaktivieren und ausschließlich SSH-Keys zu erlauben. Ein privater Schlüssel lässt sich nicht per Brute-Force erraten, während selbst komplexe Passwörter irgendwann durch Wortlisten oder Credential-Stuffing kompromittiert werden können.

Die Umstellung erfolgt in zwei Schritten: zuerst den öffentlichen Schlüssel auf dem Server hinterlegen und testen, dass der Login per Key funktioniert, danach erst Passwort-Login in der SSH-Konfiguration deaktivieren. Diese Reihenfolge ist entscheidend, denn wer die Konfiguration zuerst ändert und sich dann aus Versehen aussperrt, braucht Konsolenzugriff über den Hosting-Provider, um das Problem zu beheben. Zusätzlich lohnt es sich, den SSH-Port von 22 auf einen alternativen Port zu verlegen. Das ist zwar kein echtes Sicherheitsmerkmal, reduziert aber die schiere Menge automatisierter Scan-Versuche in den Logs drastisch.

# Generate a modern Ed25519 key pair on the local machine
ssh-keygen -t ed25519 -C "admin@mironsoft.de" -f ~/.ssh/id_ed25519_server

# Copy the public key to the target server (still using password auth)
ssh-copy-id -i ~/.ssh/id_ed25519_server.pub deploy@203.0.113.10

# Test key-based login before touching sshd_config
ssh -i ~/.ssh/id_ed25519_server deploy@203.0.113.10 "echo key login works"

# Only after the test succeeds: edit /etc/ssh/sshd_config
sudo sed -i \
  -e 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' \
  -e 's/^#\?PubkeyAuthentication.*/PubkeyAuthentication yes/' \
  -e 's/^#\?KbdInteractiveAuthentication.*/KbdInteractiveAuthentication no/' \
  /etc/ssh/sshd_config

# Validate the config syntax before restarting the daemon
sudo sshd -t && sudo systemctl restart sshd

3. Root-Login deaktivieren und Zugriff einschränken

Direkter Root-Login über SSH ist aus zwei Gründen riskant: erstens ist der Benutzername root auf praktisch jedem Linux-System identisch, was ihn zum bevorzugten Ziel automatisierter Angriffe macht, zweitens fehlt bei direktem Root-Zugriff jede Nachvollziehbarkeit, welcher Administrator welchen Befehl ausgeführt hat. Die Einstellung PermitRootLogin no in /etc/ssh/sshd_config zwingt jeden Administrator, sich zunächst mit einem persönlichen Konto anzumelden und erst danach per sudo auf Root-Rechte zu eskalieren. Jeder privilegierte Befehl landet dadurch mit Benutzernamen und Zeitstempel in /var/log/auth.log.

Ergänzend sollte der SSH-Zugriff auf die tatsächlich benötigten Benutzer und, wo möglich, auf bekannte IP-Bereiche eingeschränkt werden. Die Direktive AllowUsers deploy admin in der SSH-Konfiguration verhindert, dass ein neu angelegter Systembenutzer versehentlich SSH-Zugriff erhält. Für Umgebungen mit festen Büro- oder VPN-IP-Adressen lässt sich der Zugriff zusätzlich über die Firewall auf diese Adressbereiche begrenzen. Wichtig dabei: immer eine zweite offene Session oder einen Notfallzugang über die Provider-Konsole bereithalten, bevor solche einschränkenden Regeln aktiv geschaltet werden.

# /etc/ssh/sshd_config - production hardening baseline

# Disable direct root login entirely
PermitRootLogin no

# Key-only authentication (set up in section 2)
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no

# Restrict SSH to specific system users
AllowUsers deploy admin

# Reduce noise from automated scanners
Port 2222

# Disconnect idle sessions after 10 minutes
ClientAliveInterval 300
ClientAliveCountMax 2

# Limit authentication attempts per connection
MaxAuthTries 3
LoginGraceTime 20

4. Firewall Default-Deny mit UFW

Eine Firewall mit Default-Deny-Politik bedeutet, dass grundsätzlich jeder eingehende Datenverkehr blockiert wird, sofern er nicht explizit erlaubt wurde. Das ist der genaue Gegensatz zu einer häufig anzutreffenden Praxis, bei der alle Ports offen bleiben und nur einzelne bekannte Bedrohungen gesperrt werden. Auf Ubuntu- und Debian-Systemen bietet ufw (Uncomplicated Firewall) eine einfache Oberfläche über iptables beziehungsweise nftables, die sich in wenigen Befehlen auf eine sichere Grundkonfiguration bringen lässt.

Die Grundregel lautet: eingehenden Verkehr per Default blockieren, ausgehenden Verkehr per Default erlauben, und danach gezielt nur die Ports öffnen, die tatsächlich gebraucht werden, typischerweise SSH auf dem gewählten Port, HTTP und HTTPS für einen Webserver sowie gegebenenfalls ein Monitoring-Port aus einem eingeschränkten IP-Bereich. Jede zusätzlich geöffnete Regel sollte begründet und dokumentiert sein, denn jede offene Regel ist potenzielle Angriffsfläche. Vor der Aktivierung von ufw enable ist es essenziell, die SSH-Regel bereits gesetzt zu haben, sonst sperrt man sich selbst aus dem System aus.

# Set the default policy first: deny inbound, allow outbound
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH on the custom port BEFORE enabling the firewall
sudo ufw allow 2222/tcp comment 'SSH admin access'

# Allow web traffic for the reverse proxy
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Restrict a monitoring port to a known IP range
sudo ufw allow from 198.51.100.0/24 to any port 9100 comment 'Prometheus node_exporter'

# Enable the firewall (confirms the SSH rule is active first!)
sudo ufw enable

# Review the active ruleset with numbered entries
sudo ufw status numbered

5. Automatische Sicherheitsupdates einrichten

Ein großer Teil der erfolgreichen Server-Kompromittierungen nutzt Schwachstellen aus, für die längst ein Patch existiert. Das Zeitfenster zwischen Veröffentlichung eines CVE und dem ersten automatisierten Exploit-Versuch beträgt oft nur wenige Tage, während manuelle Update-Routinen in der Praxis Wochen oder Monate dauern können. Auf Debian- und Ubuntu-Systemen löst das Paket unattended-upgrades dieses Problem, indem es sicherheitsrelevante Paketaktualisierungen automatisch und ohne manuellen Eingriff einspielt, während funktionale Feature-Updates weiterhin manuell freigegeben werden können.

Wichtig ist die richtige Konfiguration: nur die Security-Repositories für automatische Updates aktivieren, nicht das komplette Repository, da sonst auch funktionale Änderungen ungeprüft in die Produktivumgebung gelangen können. Ein automatischer Neustart sollte nur für definierte Wartungsfenster aktiviert werden, etwa nachts um drei Uhr, und niemals sofort nach einem Kernel-Update, wenn gerade Lastspitzen auftreten. Die Installation erfolgt mit sudo apt install -y unattended-upgrades apt-listchanges gefolgt von sudo dpkg-reconfigure --priority=low unattended-upgrades, die eigentliche Feinsteuerung findet danach in der Konfigurationsdatei statt. E-Mail-Benachrichtigungen über eingespielte Updates schaffen zusätzlich Transparenz, ohne dass jemand täglich manuell prüfen muss, was aktualisiert wurde.

// /etc/apt/apt.conf.d/50unattended-upgrades (excerpt)
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESMApps:${distro_codename}-apps-security";
};

// Only reboot automatically inside a defined maintenance window
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

// Send a mail summary after every run
Unattended-Upgrade::Mail "admin@mironsoft.de";
Unattended-Upgrade::MailReport "on-change";

// Remove unused dependencies automatically
Unattended-Upgrade::Remove-Unused-Dependencies "true";

6. Minimale Paketinstallation und Angriffsfläche

Jedes installierte Paket, jeder laufende Dienst und jeder offene Port ist potenzielle Angriffsfläche, unabhängig davon, ob der Dienst tatsächlich genutzt wird. Viele Server-Images bringen von Haus aus Software mit, die auf einem reinen Anwendungsserver niemand braucht: einen vollständigen Mail-Transport-Agent, grafische Bibliotheken, Compiler-Toolchains oder Print-Dienste. Jedes dieser Pakete kann eigene Sicherheitslücken enthalten, die ohne aktive Nutzung trotzdem gepatcht werden müssen und im schlimmsten Fall als Einstiegspunkt für eine Rechteausweitung dienen.

Die Faustregel lautet: nur installieren, was für die konkrete Funktion des Servers tatsächlich gebraucht wird. Ein reiner Webserver braucht keinen X-Server, keinen lokalen Mail-Daemon für eingehende Mails und in der Regel keine Entwicklungs-Header-Pakete im Produktivsystem. Mit apt-mark showmanual lassen sich explizit installierte Pakete auflisten, sudo apt autoremove --purge entfernt verwaiste Abhängigkeiten, und sudo ss -tulpn zeigt jeden lauschenden Port mit dem zugehörigen Prozess. Ebenso wichtig ist die regelmäßige Prüfung laufender Dienste mit systemctl list-units --type=service --state=running, um Dienste zu identifizieren, die niemand mehr braucht, aber weiterhin einen Port offenhalten, etwa mit sudo systemctl disable --now cups.service.

7. Brute-Force-Schutz mit fail2ban

Selbst mit deaktivierter Passwort-Authentifizierung erzeugen automatisierte Scan-Bots weiterhin Rauschen in den Logs, indem sie fortlaufend Verbindungsversuche starten. fail2ban ergänzt die bisherigen Maßnahmen, indem es Logdateien wie /var/log/auth.log überwacht und IP-Adressen nach einer definierten Anzahl fehlgeschlagener Versuche automatisch für eine bestimmte Zeit per Firewall-Regel sperrt. Das reduziert nicht nur die Angriffsfläche, sondern auch die Menge an Log-Rauschen, die ein Administrator täglich durchsehen müsste.

Die Standardkonfiguration überwacht bereits den SSH-Dienst, lässt sich aber problemlos auf weitere Dienste wie Nginx, WordPress-Login-Formulare oder Mail-Server erweitern. Wichtig ist eine sinnvolle Balance bei den Schwellenwerten: zu aggressive Einstellungen sperren gelegentlich auch legitime Nutzer aus, die sich einmal vertippt haben, während zu großzügige Einstellungen den Schutz wirkungslos machen. Eine Ignorierliste für die eigene Büro- oder VPN-IP verhindert, dass sich Administratoren selbst aussperren.

# /etc/fail2ban/jail.local
[DEFAULT]
# Never lock out the office/VPN network
ignoreip = 127.0.0.1/8 198.51.100.0/24

# Ban duration and lookback window
bantime  = 3600
findtime = 600
maxretry = 4

[sshd]
enabled  = true
port     = 2222
filter   = sshd
logpath  = /var/log/auth.log
backend  = systemd

8. Härtungs-Theater erkennen und vermeiden

Härtungs-Theater beschreibt Maßnahmen, die auf einer Checkliste gut aussehen, aber kaum echten Sicherheitsgewinn bringen und dabei den Betrieb spürbar erschweren. Ein klassisches Beispiel ist das komplette Deaktivieren von ICMP-Echo-Requests, weil "Ping ein Sicherheitsrisiko sei". In der Praxis erschwert das nur die eigene Fehlersuche bei Netzwerkproblemen, während ein entschlossener Angreifer den Server trotzdem über offene TCP-Ports findet. Ähnlich verhält es sich mit dem ständigen Ändern des SSH-Ports als vermeintliche Haupt-Sicherheitsmaßnahme: Es reduziert Log-Rauschen, ersetzt aber unter keinen Umständen echte Authentifizierungssicherheit.

Ein weiteres Muster ist das Aktivieren komplexer Kernel-Parameter oder SELinux-Policies ohne Verständnis der Auswirkungen, oft mit dem Ergebnis, dass legitime Anwendungen unerklärlich fehlschlagen und Administratoren die Schutzmaßnahme aus Frustration wieder komplett deaktivieren, wodurch am Ende weniger Sicherheit als vorher besteht. Die bessere Strategie ist, jede Härtungsmaßnahme an der Frage zu messen: Welches konkrete Angriffsszenario wird dadurch verhindert, und steht der Aufwand in einem sinnvollen Verhältnis zu diesem Nutzen? Maßnahmen, die diese Frage nicht klar beantworten können, verdienen zusätzliche Prüfung, bevor sie produktiv geschaltet werden.

9. Maßnahmen im Vergleich: Aufwand gegen Wirkung

Nicht jede Härtungsmaßnahme bringt das gleiche Verhältnis aus Implementierungsaufwand und tatsächlichem Sicherheitsgewinn. Die folgende Tabelle stellt häufig empfohlene Maßnahmen ihrem tatsächlichen Nutzen für ein typisches Produktivsystem gegenüber und hilft dabei, Prioritäten sinnvoll zu setzen, statt Zeit in Maßnahmen mit geringem Grenznutzen zu investieren.

Die Tabelle macht deutlich, dass die vier Basismaßnahmen aus den Abschnitten 2 bis 5 den größten Sicherheitsgewinn pro investierter Stunde bringen. Erst wenn diese Baseline steht und stabil läuft, lohnt sich die Investition in aufwendigere Maßnahmen wie vollständige SELinux-Policies oder detaillierte Audit-Regeln mit auditd. Wer die Reihenfolge umdreht, verbringt Zeit mit komplexer Konfiguration, während die eigentliche Eintrittstür, ein offener Passwort-Login, weiterhin unverschlossen bleibt.

10. Zusammenfassung

Eine solide Linux-Server-Härtung für Produktivsysteme braucht keine hundert Checklisten-Punkte, sondern vier konsequent umgesetzte Basismaßnahmen: SSH ausschließlich per Key-only-Authentifizierung, Root-Login deaktiviert und Zugriff auf benötigte Benutzer beschränkt, eine Firewall mit Default-Deny-Politik, die nur explizit gebrauchte Ports öffnet, und automatische Sicherheitsupdates über unattended-upgrades. Ergänzend reduziert eine minimale Paketinstallation die Angriffsfläche zusätzlich, und fail2ban dämpft automatisiertes Scan-Rauschen.

Der entscheidende Punkt ist die Reihenfolge: erst die Baseline stabil etablieren, dann über aufwendigere Maßnahmen wie vollständige SELinux-Policies oder Audit-Frameworks nachdenken. Wer stattdessen sofort in komplexe Härtungs-Theater-Maßnahmen wie das Blockieren von ICMP investiert, wiegt sich in falscher Sicherheit, während die eigentliche Eintrittstür offen bleibt. Jede Maßnahme sollte an einem klaren Angriffsszenario gemessen werden, nicht an einer generischen Checkliste.

11. FAQ: Linux-Server-Härtung für Produktivsysteme