Checkliste Linux-Server-Härtung
Checkliste Linux-Server-Härtung für Ubuntu, Debian und RHEL-Systeme: SSH, Benutzer, Firewall, Updates, Dienste, Logging und Backups vor dem Produktivstart.
- Typischer Rhythmus pro neuem Server
- Die Checkliste 5 Abschnitte, 23 Punkte
- Variablen
{{hostname}}
Diese Checkliste ist für die Einrichtung eines neuen Linux-Servers gedacht, bevor er aus dem Internet erreichbar ist oder echte Daten enthält. Sie deckt die praktische Grundabsicherung für Ubuntu, Debian und Systeme der RHEL-Familie ab (etwa Rocky Linux, AlmaLinux). Sie ist kein vollständiger Benchmark wie die CIS Benchmarks, schließt aber die Lücken, nach denen Angreifer zuerst suchen. Wer Server per Code baut (etwa Ansible, cloud-init, Packer), prüft damit einmal das Image und danach eine Stichprobe neuer Server.
Wer verantwortlich ist
Wer den Server aufsetzt, ist für den Durchlauf verantwortlich. Eine zweite Person prüft das Ergebnis stichprobenartig, am besten indem sie versucht, sich auf den Wegen anzumelden, die nicht mehr funktionieren sollten. Den Durchlauf wiederholen, wenn ein Server neu aufgebaut wird oder eine andere Rolle bekommt.
Typische Fehler
- Sich selbst aussperren. Beim Ändern von SSH- oder Firewall-Einstellungen eine zweite SSH-Sitzung offen halten und eine neue Anmeldung testen, bevor die alte geschlossen wird. Den Zugang zur Konsole des Anbieters kennen.
- Firewall aktiv, aber Docker umgeht sie. Docker schreibt eigene iptables-Regeln, sodass veröffentlichte Container-Ports trotz ufw oder firewalld erreichbar sein können. An localhost binden oder gezielt filtern.
- Einmal gehärtet, danach schleichend aufgeweicht. Manuelle Änderungen untergraben die Grundabsicherung mit der Zeit. Einstellungen wo möglich ins Konfigurationsmanagement übernehmen.
- Logs nur auf dem Server. Ein Angreifer mit root-Rechten kann lokale Logs löschen. Logs an einen anderen Ort senden.
Jeder Durchlauf in Runbook hält fest, wer welchen Host wann gehärtet hat, ein nützlicher Nachweis bei einem Sicherheitsaudit.
Die Checkliste: Linux-Server härten: {{hostname}}
Konten und SSH
-
Persönliche Benutzerkonten für alle Admins angelegt, keine geteilten Logins
-
SSH-Schlüsselanmeldung funktioniert für jedes Admin-Konto
-
SSH-Passwortanmeldung deaktiviert
In sshd_config: PasswordAuthentication no und KbdInteractiveAuthentication no. Auch die Dateien in /etc/ssh/sshd_config.d/ prüfen, da Cloud-Images dort Passwörter oft wieder aktivieren. Mit sshd -T kontrollieren und eine neue Sitzung testen, bevor die alte geschlossen wird.
-
Direkte root-Anmeldung über SSH deaktiviert (PermitRootLogin no)
-
sudo-Rechte auf die Personen beschränkt, die sie brauchen
-
SSH auf VPN, Bastion-Host oder bekannte IP-Bereiche beschränkt optional
Netzwerk
-
Host-Firewall aktiv, eingehender Verkehr standardmäßig verweigert (z. B. ufw, firewalld, nftables)
-
Nur benötigte Ports offen, von außen per Portscan geprüft
Mit ss -tlnp auf dem Server abgleichen. Alles Unerwartete, das auf 0.0.0.0 lauscht, braucht eine Begründung.
-
Veröffentlichte Container-Ports an localhost gebunden oder gezielt gefiltert optional
-
Schutz vor Brute-Force-Angriffen auf erreichbare Dienste, z. B. fail2ban oder Rate Limiting beim Anbieter optional
Updates und Software
-
Alle Pakete aktualisiert und Server mit dem aktuellen Kernel neu gestartet
-
Automatische Sicherheitsupdates aktiviert (z. B. unattended-upgrades, dnf-automatic)
-
Nicht benötigte Dienste und Pakete deaktiviert oder entfernt
-
Nur vertrauenswürdige Paketquellen eingerichtet
Systemeinstellungen
-
Zeitsynchronisation aktiv und Zeitzone gesetzt
-
Dateirechte sensibler Dateien geprüft: SSH-Schlüssel, Secrets der Anwendung, /etc/shadow
-
Mandatory Access Control aktiv gelassen: AppArmor unter Ubuntu/Debian, SELinux im Modus enforcing bei RHEL-Systemen
-
Festplattenverschlüsselung für Server mit sensiblen Daten aktiviert optional
Logging, Monitoring und Backup
-
Logs an einen zentralen Ort außerhalb des Servers gesendet
-
Authentifizierungslogs nach der Einrichtung auf fehlgeschlagene und erfolgreiche Anmeldungen geprüft
-
Server ins Monitoring und Alerting aufgenommen
-
Backups für Daten und Konfiguration eingerichtet und eine Wiederherstellung getestet
-
Server mit verantwortlicher Person und Zweck im Inventar erfasst
Checkliste als Markdown
Häufige Fragen
Was bedeutet Server-Härtung?
Server-Härtung heißt, die Angriffsfläche eines Servers zu verkleinern: Unnötiges entfernen, Zugänge einschränken, Software aktuell halten und sicherstellen, dass ein Einbruch bemerkt würde. Sie senkt das Risiko, beseitigt es aber nicht, und muss nach der Einrichtung gepflegt werden.
Funktioniert die Checkliste auch für Ubuntu?
Ja. Die Punkte gelten für Ubuntu, Debian und Distributionen der RHEL-Familie. Nur die Werkzeuge unterscheiden sich, zum Beispiel ufw und AppArmor unter Ubuntu gegenüber firewalld und SELinux unter Rocky Linux oder AlmaLinux. Die genauen Befehle Ihres Teams als Notizen in der Vorlage ergänzen.
Sollte man stattdessen die CIS Benchmarks verwenden?
Die CIS Benchmarks sind ausführliche, weit verbreitete Härtungsleitfäden und lohnen sich, wenn eine formale Grundlage oder ein Prüfnachweis gegen einen veröffentlichten Standard nötig ist. Diese Checkliste deckt das Wesentliche für kleine Teams ab. Viele Teams beginnen hier und führen mit dem Wachstum einen Benchmark ein, oft mit einem automatischen Scanner. Für Deutschland bietet auch das IT-Grundschutz-Kompendium des BSI Bausteine zur Absicherung von Linux-Servern.
Aktualisiert