Die erste Stunde auf einem neuen Linux Dedicated Server: eine Checkliste zur Härtung

Zuerst die Antwort: die Checkliste

Acht Schritte, ungefähr in der Reihenfolge, in der Sie sie erledigen sollten. Jeder dauert ein paar Minuten; die ganze Liste passt bequem in Ihre erste Stunde auf der Maschine:

1. Erstellen Sie einen Nicht-Root-Admin-Benutzer mit sudo; loggen Sie sich nicht mehr als root ein.
2. Stellen Sie SSH auf ausschließlich Schlüssel um und härten Sie sshd_config.
3. Richten Sie eine Default-Deny-Firewall-Baseline ein: SSH und Ihre Dienste erlauben, den Rest droppen.
4. Aktivieren Sie automatische Sicherheitsupdates.
5. Installieren Sie fail2ban, um Adressen zu sperren, die bei der Authentifizierung scheitern.
6. Prüfen Sie, ob die Zeitsynchronisation aktiv ist.
7. Prüfen Sie, was lauscht und entfernen oder binden Sie alles intern, was nicht öffentlich sein sollte.
8. Machen Sie Logs persistent und überfliegen Sie sie einmal.

Alles auf dieser Liste verteidigt gegen das tatsächliche Day-one-Bedrohungsmodell eines mit dem Internet verbundenen Servers: automatisiertes, wahlloses Scannen und Credential Stuffing. Die Honeypot-Forschung von Unit 42 fand exponierte Dienste, die innerhalb von Minuten nach dem Livegang angegriffen wurden, und 80 % der Honeypots waren innerhalb von 24 Stunden kompromittiert: Den Scannern ist es egal, wer Sie sind, nur dass Sie geantwortet haben. Es folgen die Details, Distribution für Distribution.

Schritt 1: ein Nicht-Root-Benutzer mit sudo

Dauerhaft als root zu arbeiten bedeutet, dass jeder Tippfehler mit vollen Rechten ausgeführt wird und jeder Dienst, den Sie falsch konfigurieren, standardmäßig den maximalen Blast Radius hat. Zwei Minuten:

adduser deploy
usermod -aG sudo deploy      # Debian/Ubuntu
usermod -aG wheel deploy     # RHEL/AlmaLinux/Rocky

Kopieren Sie Ihren SSH-Schlüssel zum neuen Benutzer (ssh-copy-id [email protected], oder fügen Sie ihn in ~/.ssh/authorized_keys ein), bestätigen Sie, dass Sie sich einloggen und sudo -i ausführen können, und fahren Sie erst dann mit dem Absichern von SSH fort. Reihenfolge ist entscheidend: Deaktivieren Sie niemals eine Tür, bevor die neue nachweislich aufgeht.

Schritt 2: SSH (nur Schlüssel, root gesperrt)

Passwort-Authentifizierung ist genau das, worauf die scannenden Botnetze setzen. Schalten Sie sie ab:

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Validieren und neu laden. sshd -t prüft die Syntax der Konfiguration, sodass ein Tippfehler SSH nicht mit sich reißen kann:

sshd -t && systemctl reload ssh    # 'sshd' on the RHEL family

Halten Sie Ihre aktuelle Sitzung offen und bestätigen Sie, dass eine neue Verbindung funktioniert, bevor Sie sich abmelden. Diese Gewohnheit (die neue Tür testen, während die alte noch offen ist) ist der Unterschied zwischen Härtung und Selbstaussperrung. (Geht doch einmal etwas schief, rettet Sie Out-of-Band-Konsolenzugriff; mehr dazu am Ende.)

Wissenswertes:

• Moderne Distributionen liefern vernünftige SSH-Krypto-Standardeinstellungen; Sie müssen Cipher-Listen nicht mehr von Hand pflegen.
• PermitRootLogin prohibit-password (root nur per Schlüssel) ist eine vertretbare Alternative zu no, wenn Ihr Tooling tatsächlich Root-Anmeldungen benötigt; bevorzugen Sie no plus sudo, wenn Sie die Wahl haben.
• Bei aktuellen Ubuntu-Releases ist sshd Socket-aktiviert (ssh.socket), was meist keine Rolle spielt, bis Sie den Port ändern, dann aber sehr wohl. Das bringt uns zu:
• Den SSH-Port zu ändern ist Rauschreduzierung, keine Sicherheit. Es reduziert Log-Spam von den dümmsten Scannern; es bremst keinen Angreifer mit einem Portscanner. Tun Sie es für ruhigere Logs, wenn Sie möchten, niemals anstelle von Schlüsseln.

Schritt 3: die Firewall-Baseline

Debian und Ubuntu werden ganz ohne Firewall-Regeln ausgeliefert. Jeder Listener ist ab dem Start weltweit erreichbar. Die Baseline dauert fünf Minuten: Default-Deny für eingehenden Verkehr, established Traffic erlauben, SSH und Ihre tatsächlichen Dienste auf die Allowlist setzen, und ICMP richtig behandeln (nicht pauschal blockieren, das bricht Path-MTU-Discovery und IPv6).

Wir haben das vollständige, kommentierte Regelwerk in einem eigenen Leitfaden ausgearbeitet, sinnvolle Standard-Firewall-Regeln für einen Linux-Server, mit derselben Policy in nativem nftables, ufw und firewalld, plus der Mechanik zur Vermeidung von Aussperrungen. Wenn Sie nur einem Link aus dieser Checkliste folgen, dann diesem. (Unentschlossen zwischen den Regel-Syntaxen? iptables vs nftables.)

Die Ein-Zeilen-Zusammenfassung pro Familie: ufw auf Ubuntu, firewall-cmd auf RHEL/Alma/Rocky, natives nftables auf Debian. Aktivieren, 22 plus Ihre Dienst-Ports erlauben, den Rest verweigern, für beide Adressfamilien.

Schritt 4: automatische Sicherheitsupdates

Die Mehrheit der Kompromittierungen in der Praxis nutzt Schwachstellen aus, für die bereits Patches verfügbar waren. Ein Server, der sich selbst patcht, schließt dieses Zeitfenster, ohne dass Sie beim Frühstück Advisories lesen müssen:

# Debian/Ubuntu — installed and on by default on Ubuntu Server; verify:
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# RHEL/AlmaLinux/Rocky — security-only automatic updates:
dnf install dnf-automatic
# set upgrade_type = security in /etc/dnf/automatic.conf, then:
systemctl enable --now dnf-automatic.timer

Beschränken Sie es auf Sicherheitsupdates (beide Standardeinstellungen oben tun das bereits), damit unbeaufsichtigte Läufe Sie nicht mit größeren Versionssprüngen überraschen. Kernel-Updates brauchen weiterhin einen Neustart, um wirksam zu werden. Schauen Sie gelegentlich vorbei oder planen Sie Neustarts ein; unattended-upgrades kann kontrollierte automatische Neustarts durchführen, wenn Ihre Workload das verträgt.

Schritt 5: fail2ban (Sperren auf Basis von Beweisen)

Das Rate Limit Ihrer Firewall drosselt Verbindungsversuche blind; fail2ban liest das Authentifizierungslog und sperrt Adressen, die tatsächlich scheitern, ein evidenzbasiertes Blockieren, das sowohl die Firewall als auch die reine Schlüssel-Authentifizierung ergänzt:

apt install fail2ban    # dnf install fail2ban (needs the EPEL repository on RHEL-family)

Die mitgelieferten Standardeinstellungen aktivieren die SSH-Jail, und die ist die, auf die es ankommt. Eine Anpassung, die sich lohnt, in /etc/fail2ban/jail.local: Fügen Sie Ihre eigenen Management-IPs zu ignoreip hinzu, damit ein vertippter Schlüssel auf Ihrer Seite Sie nicht sperren kann.

Ist fail2ban notwendig, sobald Passwörter deaktiviert sind? Strenggenommen nein: reine Schlüssel-Authentifizierung fällt nicht auf Brute-Force herein. Es verdient sich seinen Platz trotzdem: Es reduziert Log-Rauschen deutlich, deckt die anderen Dienste ab, die Sie später hinzufügen (Mail, Panels, Datenbanken mit Auth-Logs), und dämpft die CPU-Kosten aggressiver Scanner.

Schritt 6: Zeitsynchronisation

Unsexy und essenziell: TLS-Zertifikatsvalidierung, Datenbankreplikation, Log-Korrelation während eines Vorfalls und geplante Jobs hängen alle still von der korrekten Zeit ab. Jede moderne Distribution liefert einen NTP-Client; prüfen Sie nur, ob er tatsächlich synchronisiert ist:

timedatectl    # look for "System clock synchronized: yes" and "NTP service: active"

Debian/Ubuntu nutzen standardmäßig systemd-timesyncd; die RHEL-Familie nutzt chrony. Beides ist für einen Server in Ordnung; am ersten Tag gibt es nichts zu tunen, außer das yes zu bestätigen.

Schritt 7: Ihre Listener prüfen

Machen Sie jetzt die Allowlist der Firewall ehrlich, indem Sie herausfinden, was tatsächlich lauscht:

ss -tlnp    # TCP listeners; add -u for UDP

Lesen Sie die Ausgabe mit drei Fragen: Weiß ich, was das ist? Muss es aus dem Internet erreichbar sein? Steht es bewusst auf meiner Firewall-Allowlist? Typische Funde auf einer frischen Maschine sind harmlos (sshd, systemd-resolved auf 127.0.0.53), aber das ist die Gewohnheit, die die Datenbank erwischt, die nach dem Deploy im nächsten Monat an 0.0.0.0 gebunden ist. Alles, was nur intern sein soll, sollte an 127.0.0.1 oder eine private Netzwerkadresse gebunden sein, nicht nur gefirewallt: zwei Schichten schlagen eine.

Wenn Sie Docker einsetzen: veröffentlichte Container-Ports umgehen ufw vollständig: -p 8080:80 ist unabhängig von Ihren Regeln mit dem Internet verbunden. Binden Sie an localhost (-p 127.0.0.1:8080:80) oder nutzen Sie die DOCKER-USER-Chain; Details im Firewall-Leitfaden.

Schritt 8: persistente Logs, einmal überfliegen

Auf manchen Distributionen liegt das systemd-Journal nur im Speicher und verschwindet beim Neustart, genau dann, wenn Sie es bräuchten. Machen Sie es persistent:

mkdir -p /var/log/journal && systemctl restart systemd-journald

Verbringen Sie danach zwei Minuten damit, journalctl -p warning -b zu überfliegen, damit Sie wissen, wie "normal" auf dieser Maschine aussieht; Incident Response beginnt bei einer Baseline. Binden Sie die Maschine in Ihr vorhandenes Monitoring ein (und sei es nur ein einfacher Uptime-/Disk-Alert); die erste Stunde muss nur dafür sorgen, dass die Logs erhalten bleiben und jemand benachrichtigt wird, wenn die Maschine sich daneben benimmt.

Das Cheatsheet nach Distributionsfamilie

Welche Familie Sie überhaupt einsetzen, ist eine eigene Entscheidung; unser Leitfaden zu Linux-Distributionen behandelt das.

Womit Sie sich in der ersten Stunde NICHT aufhalten sollten

Ein ehrlicher Härtungsleitfaden sagt auch, wo der abnehmende Grenzertrag beginnt:

• Port Knocking und Single Packet Authorization. Unterhaltsam, obskur und im Betrieb fragil; Schlüssel + fail2ban haben diesen Kampf bereits gewonnen.
• SELinux oder AppArmor deaktivieren, um eine App zu "reparieren". Das Gegenteil von Härtung. Lassen Sie SELinux auf enforcing / AppArmor aktiviert; wenn etwas kaputtgeht, reparieren Sie die Policy (oder die Labels der App), nicht das Framework.
• Tiefgehende Kernel-/sysctl-Härtungstouren. Über SYN Cookies hinaus (standardmäßig bereits aktiv) und das, was Ihr Firewall-Leitfaden einstellt, ist sysctl-Tuning am ersten Tag Cargo-Kult. Machen Sie es später, mit einem Benchmark und einem Grund.
• Antivirus- und Rootkit-Scanner. Auf einem frischen Linux-Server mit einem einzigen Zweck verbrauchen diese vor allem RAM und produzieren False Positives. Compliance-Vorgaben ausgenommen, lassen Sie sie heute weg.
• CIS-Benchmark-Läufe. Wertvoll für Flotten und Audits, Overkill für die erste Stunde. Die Checkliste oben deckt die Schnittmenge aus "hoher Wirkung" und "geringem Aufwand" ab; formale Benchmarks können mit wachsender Reife kommen.

Das Muster: Härtung in der ersten Stunde bedeutet, die Türen zu schließen, die Bots tatsächlich ausprobieren, und sich dann der Arbeit zu widmen, für die Sie den Server gekauft haben.

Häufig gestellte Fragen

Lohnt es sich, den SSH-Port zu ändern?

Zur Reduzierung von Log-Rauschen: ein wenig; als Sicherheitsmaßnahme: nein. Ungezielte Botnetze hämmern meist auf Port 22, daher macht das Verschieben von sshd Ihre Logs ruhiger, aber jeder Angreifer, dem es wichtig ist, führt einen Portscan aus und findet ihn in Sekunden, und nicht standardmäßige Ports erschweren Tooling und Firewalls. Wenn Sie ihn trotzdem verschieben, behandeln Sie es als bequeme Ergänzung zusätzlich zu Key-only-Authentifizierung und fail2ban, niemals als Ersatz dafür.

Brauche ich fail2ban noch, wenn die Passwort-Authentifizierung deaktiviert ist?

Brauchen: nein, Brute-Force schlägt keinen Schlüssel, den es nicht erraten kann. Wollen: wahrscheinlich schon. fail2ban hält Auth-Logs lesbar, indem es das endlose Hintergrundrauschen von Scannern sperrt, erweitert dasselbe evidenzbasierte Sperren auf Dienste, die Sie später hinzufügen, und senkt die Ressourcenkosten des Gescanntwerdens. Das sind fünf Minuten Einrichtung für einen dauerhaft ruhigeren Server; die meisten Administratoren halten das für einen guten Tausch.

Sollte ich die Root-Anmeldung vollständig deaktivieren?

Setzen Sie PermitRootLogin no und nutzen Sie sudo von einem benannten Benutzer aus: Das ist die richtige Standardeinstellung, und sie gibt Ihnen Zuordenbarkeit (welcher Schlüssel hat was getan) plus eine zweite Hürde für Angreifer. Die Ausnahme ist Automatisierung, die tatsächlich direkten Root-Zugriff benötigt; dort ist PermitRootLogin prohibit-password (nur Schlüssel, niemals Passwörter) akzeptabel. Was auf einem mit dem Internet verbundenen Server nie vertretbar ist, ist root mit Passwort-Anmeldung.

Wie unterscheidet sich ein Dedicated Server von einem VPS bei der Härtung?

Die Checkliste ist identisch; die Unterschiede liegen an den Rändern. Auf einem Dedicated Server gehört Ihnen der gesamte Stack, es gibt also keinen Provider-Agenten in Ihrem Betriebssystem und keine Nachbarn, mit denen Sie sich den Kernel teilen; die Kehrseite ist, dass die Wiederherstellung in Ihrer eigenen Verantwortung liegt, wodurch zwei Dinge wichtiger werden: Out-of-Band-Konsolenzugriff (für den Fall, dass eine Firewall- oder sshd-Änderung schiefgeht) und der Netzwerkrand-Schutz vor Ihrem Port. Prüfen Sie, ob Ihr Provider beides bietet, bevor Sie eines davon brauchen.

Deployment auf Serverside

Härtung beginnt vor Ihrem ersten SSH-Login: Auf unseren Dedicated Servern sitzen immer aktive DDoS-Mitigation und eine Self-Service-Edge-Firewall upstream von Ihrem Port (sodass Nicht-Dienst-Verkehr gedroppt werden kann, bevor er überhaupt die Maschine erreicht, die Sie gerade härten), und der inbegriffene KVM-over-IP-Konsolenzugriff bedeutet, dass eine missglückte sshd- oder Firewall-Änderung ein Zwei-Minuten-Fix ist statt einer Aussperrung. Provisionieren Sie Ubuntu, Debian, AlmaLinux/Rocky oder RHEL in unter einer Minute auf ASN 55285 und arbeiten Sie diese Checkliste von oben nach unten durch.

Vertiefen Sie das Thema mit den begleitenden Leitfäden: sinnvolle Standard-Firewall-Regeln, iptables vs nftables, und (für den Tag, an dem die Scanner Freunde mitbringen) DDoS-Angriffe erklärt.