Ein frisch installierter Linux-Server ist standardmäßig brauchbar — aber nicht gehärtet. Wer ihn unverändert ins Internet stellt, läuft mit Default-SSH-Konfiguration, ohne Firewall, ohne automatische Sicherheitsupdates und mit root als realem Account. Das ist 2026 nicht akzeptabel, auch nicht für interne Server.
Die gute Nachricht: Die wichtigsten Härtungsschritte lassen sich in ca. 15 Minuten umsetzen. Diese Checkliste deckt zehn Bereiche ab — pro Schritt der wichtigste Befehl oder Config-Snippet. Wer tiefer einsteigen will, findet bei uns den ausführlicheren Artikel Linux-Server-Hardening: Maßnahmen mit weiterführenden Details.
Die Checkliste passt für Debian 12/13, Ubuntu 24.04/26.04 LTS und Rocky/RHEL 9. Befehle ggf. an die Distribution anpassen.
1. SSH-Härtung — der wichtigste Punkt
SSH ist die häufigste Angriffsfläche. In /etc/ssh/sshd_config oder besser einer Datei unter /etc/ssh/sshd_config.d/99-hardening.conf:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers admin1 admin2
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
Voraussetzung: SSH-Public-Key des Admin-Users ist in ~/.ssh/authorized_keys deponiert. Danach systemctl restart sshd. Wichtig: Aktuelle SSH-Session offen lassen, mit zweiter SSH-Session den Login testen, bevor die erste geschlossen wird.
Ergänzend: Fail2ban als Basis-Schutz gegen Brute-Force aktivieren — siehe unsere Templates Linux Fail2ban: Jail-Templates für KMU.
2. Automatische Sicherheitsupdates
Auf Debian/Ubuntu:
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
In /etc/apt/apt.conf.d/50unattended-upgrades sicherstellen, dass security-Updates aktiv sind. Auf Rocky/RHEL:
dnf install dnf-automatic
systemctl enable --now dnf-automatic.timer
Konfiguration in /etc/dnf/automatic.conf — apply_updates = yes setzen, mindestens für Security-Updates.
3. Firewall: ufw oder nftables
Minimalste sinnvolle ufw-Konfiguration:
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment 'SSH'
ufw enable
Weitere Ports nur dann freigeben, wenn der Server sie tatsächlich anbietet (z.B. 80/443 für Web). Auf Rocky/RHEL nutzt man stattdessen firewalld; das Prinzip ist identisch.
Wer nftables direkt konfigurieren will, hat mehr Kontrolle — für die meisten KMU-Server reicht ufw als Wrapper.
4. Auditing — was passiert auf dem System?
Auditing-Light: journald zentralisieren reicht für viele KMU. Wer mehr will, nimmt auditd:
apt install auditd
Wichtigste Default-Regeln für KMU in /etc/audit/rules.d/hardening.rules:
-w /etc/passwd -p wa -k user-modify
-w /etc/shadow -p wa -k credential-modify
-w /etc/ssh/sshd_config -p wa -k ssh-config
-w /var/log/lastlog -p wa -k logins
-a always,exit -F arch=b64 -S execve -F euid=0 -k root-exec
Dann augenrules --load. Ausgaben werden mit ausearch und aureport ausgewertet. Für zentrale Auswertung Logs an Loki/Grafana weiterleiten — siehe Schritt 9.
5. Sudo statt root — NOPASSWD eng begrenzt
Root-Login direkt sollte tabu sein (siehe SSH-Härtung). Stattdessen sudo:
usermod -aG sudo admin1
In /etc/sudoers.d/admin1:
admin1 ALL=(ALL) ALL
Wenn NOPASSWD nötig ist (für Automation), nur für spezifische Befehle, nicht generell:
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp
Niemals deploy ALL=(ALL) NOPASSWD: ALL — das ist effektiv ein Root-Account ohne Authentifizierung.
6. System-Limits — Schutz vor Fork-Bombs und Ressourcen-Ausschuss
In /etc/security/limits.d/hardening.conf:
* hard nproc 10000
* hard nofile 65536
* soft nofile 32768
* hard core 0
hard nproc begrenzt Prozesse pro User, hard core deaktiviert Core-Dumps (verhindert, dass sensible Speicherinhalte auf Disk landen). Für DBMS, Java-Server u.ä. eigene Service-Limits anpassen.
7. Useless Services ausschalten
Auf einem Server-Image laufen oft Services, die nicht gebraucht werden. Anzeigen mit:
systemctl list-unit-files --state=enabled --type=service
Typische Kandidaten zum Maskieren (nicht nur deaktivieren — Maskieren verhindert Wieder-Aktivierung versehentlich):
systemctl mask bluetooth.service
systemctl mask cups.service
systemctl mask avahi-daemon.service
Vor dem Maskieren prüfen, ob der Service wirklich nicht gebraucht wird (z.B. CUPS auf Print-Server natürlich aktiv lassen).
8. Zeit-Synchronisation: chrony statt ntpd
Korrekte Zeit ist Grundlage für Logs, Auditing, Kerberos, TLS-Zertifikate. chrony ist 2026 der Standard:
apt install chrony
systemctl enable --now chrony
In /etc/chrony/chrony.conf gesicherte Quellen verwenden — z.B. den PTB (Physikalisch-Technische Bundesanstalt) für deutsche Server:
server ptbtime1.ptb.de iburst
server ptbtime2.ptb.de iburst
server ptbtime3.ptb.de iburst
Status prüfen mit chronyc tracking und chronyc sources -v.
9. Logging zentralisieren
Lokale Logs sind im Ernstfall nicht vertrauenswürdig — Angreifer können sie löschen. Zentralisierung ist Pflicht. Variante mit rsyslog/journald nach Loki:
In /etc/systemd/journald.conf:
ForwardToSyslog=yes
Dann rsyslog/promtail/vector zum Loki-Server. Wer keinen Loki-Stack hat, kann auch mit einem zentralen syslog-Server (klassisch via UDP/TCP-514 oder besser RELP) arbeiten. Siehe unseren ausführlichen Praxisartikel Grafana, Prometheus, Loki: Self-Hosted-Stack.
Für KMU-Schnellstart: jeder Server liefert seine Logs an einen zentralen Loki-Container, Grafana zeigt sie an. 30 Minuten Setup, jahrelanger Nutzen.
10. Kernel-Härtung via sysctl
In /etc/sysctl.d/99-hardening.conf ein bewährtes Snippet:
# IP-Stack
net.ipv4.tcp_syncookies=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.all.log_martians=1
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.all.accept_redirects=0
# Address Space Layout Randomization
kernel.randomize_va_space=2
# Verbergen von Pointer-Adressen in /proc
kernel.kptr_restrict=2
# Restriktion auf dmesg
kernel.dmesg_restrict=1
# YAMA ptrace-Schutz
kernel.yama.ptrace_scope=1
Aktivieren mit sysctl --system. Jeder Wert hat einen Zweck — wer ihn versteht, kann gezielt deaktivieren, falls Anwendungen Probleme melden.
Bonus: Boot-Loader und Disk-Encryption
Über die 15-Minuten-Liste hinaus sinnvoll, aber nicht im Schnellpaket:
- GRUB-Passwort setzen (verhindert Manipulation am Boot-Loader)
- LUKS-Verschlüsselung auf System-Partitionen für Hardware-Diebstahl-Resilience
- Secure Boot aktivieren, wenn UEFI vorhanden ist
- SELinux / AppArmor im Enforcing-Modus belassen (Default auf RHEL/Rocky/Ubuntu)
Das sind eher 60-Minuten-Themen — wichtig für Produktion, aber nicht für die schnelle Erst-Härtung.
Was diese Checkliste NICHT ersetzt
Ehrlich gesagt: Hardening ist nie “fertig”. Diese 15-Minuten-Liste deckt die Basics ab. Was darüber hinaus mindestens noch sein muss:
- Reguläres Vulnerability-Scanning (z.B. mit Lynis als Quick-Audit)
- Patch-Management-Prozess dokumentiert (siehe auch Cyberversicherung 2026)
- Backup des Servers (
/etc, Datenbanken, Application-Data) - Monitoring der wichtigsten Indikatoren (CPU, RAM, Disk, Login-Anomalien)
- Incident-Response-Plan, was bei Verdacht auf Kompromittierung zu tun ist
Wer Lynis einmal laufen lässt (apt install lynis && lynis audit system), bekommt einen Score und konkrete weitere Empfehlungen — ein guter Startpunkt für Phase 2.
Fazit
Zehn Schritte, ca. 15 Minuten pro Server — und ein frisch installierter Linux-Server ist signifikant härter als der Default. Die Liste ist kein “Maximum-Security-Konzept”, sondern das Minimum, das 2026 jeder produktive Server haben sollte. Jeder Schritt ist erklärbar, jeder Befehl in Standard-Distributionen verfügbar, kein Voodoo.
Für tiefergehende Härtung — SELinux-Customisierung, Kernel-Live-Patching, Compliance-konforme Härtung nach CIS-Benchmarks — gibt es weitere Tools und Konzepte. Aber die Basis sind die zehn Punkte oben. Wer sie konsequent für jeden neuen Server umsetzt, hat einen erheblichen Sicherheitsgewinn gegenüber Default-Installationen.
DATAZONE automatisiert diese Härtung über Ansible-Rollen — neue Server kommen mit kompletter Härtungs-Liste online, reproduzierbar und dokumentiert. Auf Anfrage.
Mehr zu diesen Themen:
Weitere Artikel
Samba als Active Directory: Windows-Domäne ablösen
Windows Server AD durch Samba 4 AD-DC ersetzen: DNS mit BIND9, Replikation, Gruppenrichtlinien-Grenzen und Koexistenz während der Migration.
Bash vs. Ansible: Wann sich der Sprung lohnt
Bash-Skripte oder Ansible fuer Ihre Serverautomation? Ab wann sich Idempotenz, Inventory und Playbook-Reuse fuer wachsende Linux-Umgebungen wirklich rechnen.
systemd-networkd vs. NetworkManager: Wann was auf Servern
systemd-networkd oder NetworkManager auf Linux-Servern? Vergleich der Netzwerkstacks mit Bridge-, VLAN- und Migrations-Beispielen für Proxmox, KVM und Container.