Linux-Server härten: Checkliste mit Befehlen

Einen Linux-Server härten heißt, seine Angriffsfläche gezielt zu verkleinern: nicht benötigte Dienste abschalten, Zugänge auf Schlüssel und wenige Personen beschränken, nur die nötigen Ports öffnen, Sicherheitsupdates automatisch einspielen und unsichere Kernel- und Dateisystem-Voreinstellungen korrigieren. Die meisten Maßnahmen lassen sich mit Bordmitteln umsetzen und mit Werkzeugen wie Lynis und einem Portscan von außen überprüfen. Entscheidend ist, dass die Härtung dokumentiert und dauerhaft gehalten wird, statt nur einmal bei der Installation zu passieren.

Standardinstallationen sind auf Kompatibilität ausgelegt, nicht auf minimale Angriffsfläche. Sobald ein Server eine öffentliche IP-Adresse hat, wird er von automatisierten Scannern gefunden und auf schwache Zugänge abgeklopft. Dieser Beitrag zeigt eine praxistaugliche Reihenfolge für Debian- und Ubuntu-Systeme, die sich sinngemäß auf andere Distributionen übertragen lässt.

Was gehört zur Härtung eines Linux-Servers und was nicht?

Härtung betrifft die Betriebssystemebene: Dienste, Benutzer, Netzwerkzugriffe, Kernel-Einstellungen, Dateisysteme und Protokollierung. Sie ist die Grundlage, auf der Anwendungen sicher laufen können.

Sie ersetzt aber weder Backups noch Monitoring noch die Pflege der Anwendungen selbst. Ein perfekt gehärteter Server mit einer veralteten Webanwendung bleibt angreifbar. Betrachten Sie Härtung deshalb als eine Schicht unter mehreren, nicht als Gesamtlösung.

Vor dem Härten: Rolle des Servers festhalten

Härtung ohne klares Ziel führt entweder zu Lücken oder zu Einstellungen, die die Anwendung lahmlegen. Halten Sie vorab schriftlich fest:

Welche Dienste muss der Server nach außen anbieten (zum Beispiel HTTPS, SMTP)?
Wer administriert ihn, und von welchen Netzen oder IP-Adressen aus?
Welche internen Verbindungen braucht er (Datenbank, Backup-Ziel, Monitoring)?
Welche Daten liegen darauf, und wie schutzbedürftig sind sie?

Sorgen Sie außerdem für einen Notzugang, bevor Sie SSH oder die Firewall anfassen: eine Konsole über das Kundenportal des Anbieters oder ein Rescue-System. Ein Snapshot vor Beginn erspart im Zweifel viel Zeit.

Linux-Server härten: Die Checkliste in zehn Schritten

Laufende Dienste und installierte Pakete auf das Nötige reduzieren.
Sicherheitsupdates automatisch einspielen lassen.
Benutzer und sudo-Rechte bereinigen.
SSH auf Schlüssel umstellen und Root-Login verbieten.
Host-Firewall mit Default-Deny aktivieren.
Brute-Force-Versuche automatisch bremsen.
Kernel-Parameter für Netzwerk und Informationsschutz setzen.
Dateisysteme mit restriktiven Mount-Optionen einbinden und SUID-Dateien prüfen.
Protokollierung und Auditing für sicherheitsrelevante Dateien einrichten.
Ergebnis prüfen, dokumentieren und regelmäßig wiederholen.

1. Dienste und Pakete reduzieren

Jeder lauschende Dienst ist ein möglicher Einstiegspunkt. Verschaffen Sie sich zuerst einen Überblick, welche Ports offen sind und welche Dienste laufen:

ss -tulpn
systemctl list-units --type=service --state=running

Alles, was für die definierte Rolle nicht gebraucht wird, deaktivieren oder deinstallieren Sie, etwa einen mitinstallierten Druckdienst oder einen Mailserver, der nur lokal Systemmeldungen verschicken soll. Dienste, die nur intern erreichbar sein müssen, binden Sie an 127.0.0.1 statt an alle Schnittstellen.

2. Sicherheitsupdates automatisieren

Sicherheitsupdates für das Betriebssystem sollten nicht von manueller Aufmerksamkeit abhängen. Unter Debian und Ubuntu übernimmt das unattended-upgrades, unter RHEL-Derivaten dnf-automatic:

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Beschränken Sie die automatischen Updates auf die Sicherheitsquellen und planen Sie Neustarts für Kernel-Updates bewusst ein. Ob ein Neustart aussteht, zeigt unter Debian und Ubuntu die Datei /var/run/reboot-required.

3. Benutzer und sudo-Rechte bereinigen

Prüfen Sie, welche Konten eine Login-Shell haben und wer zur Gruppe sudo oder wheel gehört. Gemeinsam genutzte Admin-Konten sollten durch persönliche Konten ersetzt werden, damit nachvollziehbar bleibt, wer was getan hat. Wie Sie Zugänge im Team strukturieren und beim Ausscheiden sauber entziehen, beschreibt der Beitrag zu SSH-Keys, Rollen und Offboarding im Team.

4. SSH absichern

SSH ist auf fast jedem Server der wichtigste Administrationszugang und damit das bevorzugte Ziel automatisierter Angriffe. Legen Sie eigene Einstellungen in einer separaten Datei ab, damit Paketupdates sie nicht überschreiben:

# /etc/ssh/sshd_config.d/10-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowTcpForwarding no
AllowGroups ssh-users

Testen Sie die Konfiguration mit sshd -t, laden Sie den Dienst neu und lassen Sie die bestehende Sitzung offen, bis eine zweite Anmeldung mit Schlüssel erfolgreich war. So sperren Sie sich bei einem Tippfehler nicht aus.

5. Host-Firewall mit Default-Deny

Die Host-Firewall folgt dem Prinzip Default-Deny: Eingehender Verkehr wird verworfen, sofern er nicht ausdrücklich erlaubt ist. Ein minimales Beispiel mit nftables für einen Webserver, dessen SSH-Zugang nur aus einem Firmennetz erreichbar ist:

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    ct state invalid drop
    iif lo accept
    tcp dport 22 ip saddr 203.0.113.0/24 accept
    tcp dport { 80, 443 } accept
    icmp type echo-request limit rate 5/second accept
    icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert, echo-request } accept
  }
}

Die Host-Firewall schützt den einzelnen Server. Wie Sie darüber hinaus Netze trennen und Regeln zwischen Systemen sinnvoll gestalten, lesen Sie im Beitrag über Netzsegmentierung und Firewallregeln.

6. Brute-Force-Versuche bremsen

Auch mit Schlüssel-Login füllen fehlgeschlagene Anmeldeversuche die Logs. Fail2ban sperrt auffällige Adressen für eine gewisse Zeit:

# /etc/fail2ban/jail.local
[sshd]
enabled  = true
maxretry = 5
findtime = 10m
bantime  = 1h

Die Werte sind ein Ausgangspunkt. Tragen Sie eigene Admin-Netze über ignoreip ein, damit Ihr Team sich nicht selbst aussperrt.

7. Kernel-Parameter setzen

Einige Kernel-Voreinstellungen sind auf Kompatibilität ausgelegt. Für einen Server, der nicht als Router arbeitet, sind restriktivere Werte sinnvoll:

# /etc/sysctl.d/90-hardening.conf
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
fs.protected_symlinks = 1
fs.protected_hardlinks = 1

Mit sysctl --system werden die Werte aktiv. Betreibt der Server Container oder VPN-Tunnel, prüfen Sie vorher, ob Weiterleitung oder Redirects dort benötigt werden.

8. Dateisysteme und SUID-Dateien

Verzeichnisse, in die jeder schreiben darf, sind ein beliebter Ablageort für Schadcode. Binden Sie /tmp mit einschränkenden Optionen ein:

# /etc/fstab
tmpfs  /tmp  tmpfs  defaults,nodev,nosuid,noexec  0 0

Manche Installationsskripte führen Dateien aus /tmp aus und scheitern dann. Das ist kein Grund, die Option wegzulassen, sondern ein Hinweis, für solche Fälle ein eigenes Arbeitsverzeichnis zu verwenden. Prüfen Sie zusätzlich, welche Programme mit SUID-Bit laufen:

find / -xdev -perm -4000 -type f 2>/dev/null

Unbekannte Einträge in dieser Liste sollten Sie klären, bevor Sie sie entfernen.

9. Protokollierung und Auditing

Härtung bringt wenig, wenn Änderungen unbemerkt bleiben. Mit auditd lassen sich Zugriffe auf sicherheitsrelevante Dateien protokollieren:

# /etc/audit/rules.d/hardening.rules
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/ssh/sshd_config -p wa -k sshd
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity

Diese Protokolle sollten den Server verlassen und an einem zentralen Ort landen, denn ein Angreifer mit Root-Rechten kann lokale Logs löschen.

10. Prüfen und dokumentieren

Der letzte Schritt ist der, der am häufigsten fehlt: Halten Sie fest, welche Einstellungen Sie gesetzt haben und warum. Abweichungen von einer Empfehlung sind legitim, sollten aber begründet sein, damit sie beim nächsten Audit nicht als Fehler auffallen.

Härtung überprüfen: Lynis und der Blick von außen

Ob Ihre Maßnahmen greifen, prüfen Sie aus zwei Richtungen. Von innen liefert Lynis eine Bestandsaufnahme mit konkreten Hinweisen:

lynis audit system

Lynis gibt einen Härtungsindex und eine Liste von Vorschlägen aus. Der Index eignet sich zum Vergleich über die Zeit, nicht als absolutes Gütesiegel. Arbeiten Sie die Vorschläge nach Relevanz für Ihre Serverrolle ab, nicht stur von oben nach unten.

Von außen zeigt ein Portscan von einem fremden Netz aus, was ein Angreifer tatsächlich sieht:

nmap -Pn -p- server.example.de

Offene Ports, die nicht in Ihrer Rollenbeschreibung stehen, sind ein klarer Handlungsauftrag. Scannen Sie nur Systeme, für die Sie verantwortlich sind.

Typische Fehler beim Härten

Aussperren: SSH- oder Firewall-Änderungen ohne offene Zweitsitzung und ohne Konsolenzugang.
Kopierte Konfigurationen: Einstellungen aus Anleitungen übernehmen, ohne zu prüfen, ob sie zur eigenen Distribution und Version passen.
Kosmetik statt Wirkung: den SSH-Port verlegen, aber Passwort-Logins erlauben.
Einmalaktion: beim Aufsetzen sorgfältig härten und danach nie wieder prüfen.
Keine Dokumentation: Der Nachfolger weiß nicht, warum /tmp mit noexec gemountet ist, und entfernt es beim ersten Problem.

Wie bleibt die Härtung dauerhaft erhalten?

Server verändern sich: Pakete kommen hinzu, jemand öffnet zur Fehlersuche einen Port und vergisst ihn, ein Update bringt neue Standardwerte mit. Diese schleichende Konfigurationsdrift macht eine gute Erstkonfiguration mit der Zeit wertlos.

Härtung ist kein einmaliges Projekt, sondern ein Sollzustand, der dokumentiert, regelmäßig automatisch geprüft und nach jeder Abweichung wiederhergestellt wird.

In der Praxis bewährt sich, die Härtungseinstellungen als Dateien in einem Versionsverwaltungssystem abzulegen und per Konfigurationsmanagement auszurollen. Dann ist jeder neue Server von Anfang an gehärtet, und Abweichungen werden beim nächsten Lauf korrigiert. Wann sich dieser Aufwand lohnt und wie Sie klein anfangen, beschreibt der Beitrag zu Infrastructure as Code im Serverbetrieb. Ergänzend sollte Lynis in festen Abständen laufen und der Portscan von außen nach jeder größeren Änderung wiederholt werden.

Selbst härten oder betreuen lassen?

Die Schritte oben sind mit Linux-Grundkenntnissen umsetzbar. Der eigentliche Aufwand liegt im Dauerbetrieb: Updates verfolgen, Abweichungen erkennen, Prüfungen wiederholen und bei Änderungen der Anwendung die Regeln anpassen. Ob Ihr Team das neben dem Tagesgeschäft verlässlich leisten kann, ist die eigentliche Entscheidungsfrage.

Wer die Härtung abgeben möchte, kann einen Dienstleister damit beauftragen. Bei NETARO beispielsweise sind die Cloud Server in Frankfurt als Standard-Variante mit Root-Zugriff buchbar, bei der Sie selbst härten, oder als Managed-Variante, bei der Härtung, Updates, Backups und 24/7-Monitoring zum Betrieb gehören. Was ein solcher betreuter Serverbetrieb umfasst, sollten Sie in jedem Fall mit der eigenen Checkliste abgleichen, unabhängig vom Anbieter.

FAQ

Wie oft sollte man einen Linux-Server auf seine Härtung prüfen?

Ein automatischer Lauf von Lynis oder einem vergleichbaren Werkzeug in festen Abständen, etwa monatlich, ist ein guter Ausgangspunkt. Zusätzlich sollten Sie nach jeder größeren Änderung, einem Distributions-Upgrade oder dem Aufspielen neuer Anwendungen prüfen.

Reicht es, den SSH-Port zu ändern?

Nein. Ein anderer Port reduziert lediglich das Rauschen in den Logs, weil weniger automatisierte Scanner ihn finden. Schutz bieten erst Schlüssel-Login, verbotener Root-Login, eingeschränkte Quellnetze und eine Sperre bei wiederholten Fehlversuchen.

Gibt es einen anerkannten Standard für die Härtung von Linux-Servern?

Verbreitete Orientierung bieten die CIS Benchmarks für einzelne Distributionen und der Baustein SYS.1.3 Server unter Linux und Unix im IT-Grundschutz des BSI. Beide sollten Sie an die Rolle Ihres Servers anpassen, statt jede Empfehlung ungeprüft zu übernehmen.

Kann Härtung meine Anwendungen beeinträchtigen?

Ja, wenn Einstellungen ohne Kenntnis der Anwendung gesetzt werden, etwa noexec auf einem Verzeichnis, aus dem Skripte gestartet werden, oder eine Firewall-Regel, die eine interne Verbindung blockiert. Härten Sie deshalb schrittweise, testen Sie nach jedem Schritt und dokumentieren Sie bewusste Ausnahmen.

Linux-Server härten: Checkliste in zehn Schritten mit Befehlen und Konfigurationsbeispielen