DevOps 10 Min Lesezeit

Linux Server Härtung 2026 – Die komplette Checkliste

Warum Linux-Härtung 2026 kein optionales Projekt mehr ist

Wer heute einen Server mit öffentlicher IPv4-Adresse ins Netz stellt, hat im Schnitt unter fünf Minuten bis zum ersten automatisierten SSH-Bruteforce-Versuch. Die Shadowserver Foundation zählt auf stark exponierten /24-Netzen regelmäßig 20.000 bis 60.000 Login-Versuche pro Tag und Host. Das ist kein gezielter Angriff, das ist Grundrauschen – und es trifft jeden, der Port 22 offen lässt.

Parallel verschiebt sich die Bedrohungslage: Ransomware-Gruppen wie Akira und LockBit haben 2025/2026 ihre Linux-Varianten deutlich ausgebaut. Betroffen sind nicht mehr nur ESXi-Hosts, sondern zunehmend NAS-Systeme, Backup-Server und CI-Runner. Der Einstieg läuft fast immer über dieselben drei Wege: schwache SSH-Credentials, ungepatchte Dienste oder fehlkonfigurierte Container mit Zugriff auf den Docker-Socket.

Die wirtschaftliche Rechnung ist brutal. Gartner beziffert die durchschnittlichen Kosten einer Server-Downtime mit rund 5.000 Euro pro Minute. Ein gehackter Webserver, der 6 Stunden offline ist, kostet dich also theoretisch 1,8 Millionen Euro – realistisch für KMU eher 15.000 bis 80.000 Euro inklusive Forensik, Wiederherstellung und Kundenvertrauen.

Dazu kommt der regulatorische Druck: Seit Oktober 2024 greift die NIS2-Richtlinie in deutsches Recht. Betroffen sind deutlich mehr Unternehmen als landläufig angenommen – Schwellenwerte liegen bei 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz. Wer betroffen ist, muss technische Maßnahmen dokumentieren. Eine Härtungs-Checkliste ist damit nicht nur Security, sondern Compliance-Artefakt.

Schritt 1: Baseline – Inventar und Angriffsfläche erfassen

Härtung ohne Bestandsaufnahme ist Blindflug. Bevor du irgendetwas änderst, dokumentierst du den Ist-Zustand. Sonst kannst du nach einem Vorfall nicht sagen, was sich wann verändert hat – und du weißt nicht, welche Dienste du beim Absichern zerschießt.

# Lauschende Ports inklusive Prozess
ss -tulpn

# Alle laufenden Dienste
systemctl list-units --type=service --state=running

# Installierte Pakete zählen
dpkg -l | grep -c ^ii   # Debian/Ubuntu
rpm -qa | wc -l         # RHEL/Rocky/Alma

# Offene Dateien mit Netzwerkbezug
lsof -i -P -n | grep LISTEN

Zusätzlich scannst du den Host von außen. Ein internes ss zeigt dir nicht, was eine Cloud-Firewall oder ein vorgelagerter Load Balancer durchlässt. Nutze nmap -sS -Pn --top-ports 1000 deine.ip von einem anderen Server aus oder einen externen Portscanner.

Prüfpunkt	Soll-Zustand	Häufige Abweichung
Offene Ports	max. 3–5	12+ durch Testdienste
SSH-Passwortlogin	deaktiviert	aktiv auf 80 % der VPS
Root-Login per SSH	deaktiviert	aktiv auf 60 %
Automatische Updates	aktiv	inaktiv auf 70 %
Firewall	Default Deny	keine oder nur ufw-Default

Ergebnis dieser Phase: eine Liste mit jedem Dienst, jedem Port und jedem verantwortlichen Paket. Alles, was nicht gebraucht wird, fliegt raus. Jeder entfernte Dienst ist ein Problem, das du nie patchen musst.

Schritt 2: SSH-Härtung – der größte Einzelhebel

SSH ist der wichtigste Dienst auf deinem Server und gleichzeitig der meistangegriffene. Die gute Nachricht: Mit einer sauberen Konfiguration eliminierst du über 95 Prozent aller realen Kompromittierungswege in einem Schritt. Lege die Konfiguration in einem Drop-in ab, statt /etc/ssh/sshd_config direkt zu editieren – so überleben deine Änderungen Distributions-Updates.

# /etc/ssh/sshd_config.d/99-hardening.conf
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
PermitEmptyPasswords no
MaxAuthTries 3
MaxSessions 4
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers deploy admin
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
UseDNS no
LogLevel VERBOSE

# Nur moderne Algorithmen
KexAlgorithms curve25519-sha256,[email protected],[email protected]
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]

Vor dem Neustart immer validieren: sshd -t. Erst wenn das ohne Fehler durchläuft, systemctl reload sshd. Halte eine zweite Root-Session offen, während du testest – sonst sperrst du dich im Zweifel selbst aus.

Für Schlüssel gilt: Ed25519 statt RSA. ssh-keygen -t ed25519 -a 100 -C "admin@hostazar" erzeugt einen schnellen, kurzen und gegen Offline-Angriffe gehärteten Schlüssel. RSA-2048 ist 2026 nur noch aus Kompatibilitätsgründen akzeptabel, RSA-4096 ist unnötig langsam. Private Keys gehören auf die Workstation, geschützt mit Passphrase und ssh-agent – niemals auf den Server.

Die Diskussion um einen alternativen SSH-Port: Sicherheitstechnisch bringt sie fast nichts, weil Portscanner in Sekunden alle 65.535 Ports prüfen. Praktisch reduziert sie das Log-Rauschen aber um 80 bis 95 Prozent, was Fail2ban-Bans und echte Auffälligkeiten sichtbar macht. Wenn du einen Port änderst, dann dokumentiere ihn im Runbook – sonst sucht das Team beim Incident.

Schritt 3: Benutzer, sudo und Rechteverwaltung

Root-Logins per SSH sind deaktiviert, aber der Root-Account existiert weiter. Prüfe zuerst, ob es unerwartete UID-0-Konten gibt: awk -F: '($3 == 0) {print $1}' /etc/passwd. Es darf ausschließlich root erscheinen. Jeder weitere Treffer ist ein potenzieller Backdoor-Account.

Für administrative Arbeit legst du benannte Accounts an und arbeitest über sudo. Named Accounts sind Pflicht für Auditierbarkeit – bei einem Vorfall willst du wissen, wer was getan hat, nicht nur dass „root“ es war.

adduser deploy
usermod -aG sudo deploy

# Passwort-Alterung erzwingen
chage -M 90 -W 14 deploy

# sudoers sicher editieren
visudo -f /etc/sudoers.d/deploy

In der sudoers-Datei gilt: kein NOPASSWD für interaktive Nutzer. Ein gestohlener SSH-Key wird damit sofort zur Root-Shell. Wenn du Automatisierung brauchst, nutze eng begrenzte Kommandos: deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx statt ALL=(ALL) NOPASSWD: ALL.

Weitere Basismaßnahmen: passwd -l auf alle nicht benötigten System-Accounts, chmod 640 /etc/shadow, chmod 644 /etc/passwd, umask 027 in /etc/profile und /etc/login.defs. Suche nach verwaisten Dateien mit find / -xdev $ -nouser -o -nogroup $ -print – die sind oft Überbleibsel gelöschter Accounts und ein klassisches Persistenz-Versteck.

Schritt 4: Firewall mit nftables und Fail2ban

Die Firewall-Philosophie lautet Default Deny: alles verboten, was nicht explizit erlaubt ist. Unter Debian 12 und Ubuntu 24.04 ist nftables der Standard-Backend. UFW ist ein akzeptabler Wrapper für kleine Setups, aber für Server mit mehreren Interfaces oder Docker nimmst du nftables direkt.

# /etc/nftables.conf
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    ip protocol icmp icmp type { echo-request } limit rate 5/second accept
    tcp dport { 22, 80, 443 } ct state new limit rate 20/minute accept
    log prefix "nft-drop: " limit rate 10/minute
  }
  chain forward { type filter hook forward priority 0; policy drop; }
  chain output { type filter hook output priority 0; policy accept; }
}

Fail2ban ergänzt das um verhaltensbasierte Sperren. Standardwerte sind zu lasch: bantime = 600 bedeutet, dass ein Angreifer nach 10 Minuten weitermachen darf. Setze bantime.increment = true mit factor = 2 und maxtime = 604800 (7 Tage) – wiederholte Verstöße führen dann zu exponentiell längeren Sperren.

# /etc/fail2ban/jail.local
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 3
bantime.increment = true
bantime.factor    = 2
bantime.maxtime   = 604800
banaction = nftables-multiport
ignoreip  = 127.0.0.1/8 ::1 203.0.113.0/24

[sshd]
enabled = true
mode    = aggressive

Prüfe den Status mit fail2ban-client status sshd. Auf stark angegriffenen Hosts sind 200 bis 800 aktive Bans normal. Als moderne Alternative lohnt sich CrowdSec: Es teilt Reputationsdaten über eine Community-API und blockt bekannte Angreifer-IPs, bevor sie überhaupt deinen SSH-Port erreichen. Der Agent ist kostenlos, ein zentrales Blocklist-Abo kostet rund 20 Euro pro Monat für kleinere Flotten.

Schritt 5: Kernel-Härtung über sysctl

Der Linux-Kernel bringt dutzende Sicherheitsfeatures, die per Default aus Kompatibilitätsgründen deaktiviert sind. Über sysctl aktivierst du sie zentral. Die Datei gehört nach /etc/sysctl.d/99-hardening.conf, aktiviert wird sie mit sysctl --system.

# Netzwerk-Härtung
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.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_syncookies = 1
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_redirects = 0

# Kernel-Selbstschutz
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.yama.ptrace_scope = 2
kernel.unprivileged_bpf_disabled = 1
kernel.kexec_load_disabled = 1
kernel.randomize_va_space = 2

# Dateisystem-Schutz
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
fs.suid_dumpable = 0

Besonders kernel.yama.ptrace_scope = 2 ist wirkungsvoll: Damit kann kein Prozess mehr einen fremden Prozess debuggen, was das Auslesen von Zugangsdaten aus laufenden Diensten massiv erschwert. kernel.kptr_restrict = 2 verhindert, dass Kernel-Adressen in /proc sichtbar sind – wichtig für die Umgehung von KASLR.

Achtung bei net.ipv6.conf.all.accept_ra = 0: Auf Servern mit SLAAC-Adressierung bricht damit die Konnektivität. Prüfe vorher, ob IPv6 statisch konfiguriert ist. Und fs.protected_regular kann bei manchen Legacy-Anwendungen mit unsauberen Temp-Dateien Fehler verursachen – teste auf einem Staging-Host.

Schritt 6: Automatische Updates und Patch-Management

Ungepatchte Dienste sind nach schwachen Credentials der zweithäufigste Eintrittsvektor. Die Lösung ist Automatisierung, aber mit Verstand: Sicherheitsupdates automatisch, Feature-Updates manuell, Kernel-Reboots geplant.

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

In /etc/apt/apt.conf.d/50unattended-upgrades setzt du die Origins auf security und ESM, aktivierst Unattended-Upgrade::Remove-Unused-Dependencies "true" und – wichtig – Automatic-Reboot "true" mit Automatic-Reboot-Time "03:30". Ohne Reboot läuft dein Server nach einem Kernel-Update weiter mit dem verwundbaren alten Kernel.

Für Umgebungen, in denen Reboots nicht möglich sind, gibt es Livepatch-Lösungen. Canonical Ubuntu Pro ist für bis zu 5 Maschinen kostenlos, Enterprise-Tarife starten bei rund 500 US-Dollar pro Jahr für 50 Server. KernelCare von CloudLinux kostet etwa 4 bis 6 Euro pro Server und Monat und patcht Kernel-Livepath für die gängigen Distributionen. Bei einem 10-Server-Setup reden wir also über 40 bis 60 Euro monatlich – günstiger als eine einzige Stunde Downtime.

Ergänzend: needrestart im Modus l (list) informieren lassen, welche Dienste nach Library-Updates neu gestartet werden müssen. Und ein monatliches Wartungsfenster für die Dinge, die Automatik nicht erledigt: Distribution-Upgrades, Datenbank-Major-Versionen, Zertifikatsrotation.

Schritt 7: Auditd, Logging und Monitoring

Ohne Logs gibt es keine Forensik. Standard-Logging auf einem Linux-Server reicht für einen echten Incident nicht aus, weil viele Aktionen schlicht nicht protokolliert werden. auditd schließt diese Lücke.

apt install auditd audispd-plugins

# /etc/audit/rules.d/hardening.rules
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /etc/ssh/sshd_config -p wa -k sshd
-w /root/.ssh -p wa -k ssh_keys
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_cmds
-a always,exit -F arch=b64 -S init_module,finit_module -k modules

Diese Regeln melden jede Änderung an Identitäts- und Rechtekonfiguration sowie jedes ausgeführte Root-Kommando. Das ist die Grundlage, um nach einem Vorfall eine Timeline zu bauen. Logs gehören persistent gespeichert – Storage=persistent in /etc/systemd/journald.conf – und per rsyslog oder Promtail an einen zentralen Logserver geschickt, den ein Angreifer nicht erreicht.

Für Monitoring hat sich der Stack Prometheus + node_exporter + Grafana etabliert. Wichtige Alerts: unerwarteter SSH-Login von neuer IP, plötzlicher CPU-Spike über 90 Prozent für mehr als 10 Minuten (Miner), ausgehende Verbindungen auf untypische Ports, Änderungen an /etc/passwd. Wer es einfacher will: Uptime Kuma für Erreichbarkeit, Netdata für Systemmetriken, beides kostenlos selbst gehostet.

Ein oft vergessener Punkt: ausgehender Traffic. Die meisten Härtungen betrachten nur eingehende Verbindungen. Ein kompromittierter Host, der nach außen auf einen C2-Server telefoniert, fällt damit nicht auf. Mindestens ein Alerting auf neue ausgehende Verbindungen zu unbekannten IPs gehört in jedes Setup.

Schritt 8: Dateisystem-Härtung und Integritätsprüfung

Mount-Optionen sind ein unterschätzter Hebel. Verzeichnisse, in denen ohnehin keine Binaries liegen sollten, mountest du mit noexec, nosuid und nodev. Ein Angreifer, der ein Skript nach /tmp schreibt, kann es dann nicht ausführen.

# /etc/fstab
tmpfs   /tmp      tmpfs   defaults,noatime,nosuid,nodev,noexec,size=2G,mode=1777  0 0
tmpfs   /dev/shm  tmpfs   defaults,noatime,nosuid,nodev,noexec,size=1G,mode=1777  0 0
/var/tmp  ext4    defaults,noatime,nosuid,nodev,noexec  0 2

Für Dateiintegrität nutzt du AIDE oder Tripwire. AIDE erstellt eine Datenbank mit Hashes aller relevanten Dateien und meldet Abweichungen. Nach der Installation initialisierst du die Datenbank und lässt danach täglich per Cron prüfen.

apt install aide
aideinit
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
# Täglicher Check um 04:15
echo "15 4 * * * root /usr/bin/aide.wrapper --check" > /etc/cron.d/aide

Für vertrauliche Daten auf dem Server – Kundendatenbanken, Backups, Secrets – gehört eine Verschlüsselung dazu. LUKS2 mit Argon2id als Key-Derivation ist 2026 Standard: cryptsetup luksFormat --type luks2 --pbkdf argon2id /dev/nvme0n1p3. Bei Cloud-VPS ohne Remote-KVM bedeutet das allerdings, dass du die Passphrase beim Boot manuell eingeben musst oder einen Network-Bound-Disk-Mechanismus brauchst. Plane das vorher.

Ergänzend: chmod 700 /root, chmod 750 /home/deploy, keine world-writable Dateien (find / -xdev -type f -perm -0002 -print), und chattr +i auf kritische Konfigurationsdateien wie /etc/resolv.conf oder /etc/hosts, wenn diese nicht dynamisch geändert werden.

Schritt 9: Container- und Docker-Härtung

Container sind kein Sicherheitsgewinn per se. Ein Container mit gemountetem Docker-Socket ist faktisch Root auf dem Host – -v /var/run/docker.sock:/var/run/docker.sock ist die gefährlichste Zeile in den meisten Compose-Dateien. Wenn ein Container unbedingt Docker steuern muss, nutze einen Socket-Proxy wie tecnativa/docker-socket-proxy mit explizit erlaubten Endpunkten.

docker run -d \
  --read-only \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt no-new-privileges:true \
  --security-opt seccomp=/etc/docker/seccomp-default.json \
  --pids-limit 200 \
  --memory 512m --cpus 1.0 \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  myapp:1.4.2

Die wichtigsten Regeln: kein --privileged, kein Root-User im Container (im Dockerfile USER 10001), kein latest-Tag in Produktion, Read-only Root-Filesystem wo möglich. Scanne Images regelmäßig mit trivy image myapp:1.4.2 – bei einem typischen Node.js- oder Python-Image findest du dabei regelmäßig 40 bis 120 CVEs, davon 3 bis 10 mit hohem Schweregrad.

Für Kubernetes gilt: Pod Security Standards auf restricted setzen, NetworkPolicies als Default Deny, RBAC mit minimalen Rechten, keine hostPath-Volumes. Tools wie kube-bench prüfen den Cluster gegen den CIS Kubernetes Benchmark, Falco erkennt Laufzeit-Anomalien wie Shell-Spawns in Containern.

Schritt 10: CIS-Benchmark, Lynis und Compliance-Nachweis

Am Ende willst du messen, ob deine Härtung wirkt. Der De-facto-Standard ist der CIS Benchmark für deine Distribution. Für Debian 12 und Ubuntu 24.04 LTS gibt es fertige Profile.

# Lynis – schneller Überblick
apt install lynis
lynis audit system
# Ergebnis: Hardening Index, Zielwert >= 85

# OpenSCAP gegen CIS-Profil
apt install libopenscap8 ssg-debderived
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis \
  --results scan.xml --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-debian12-ds.xml

Ein Lynis Hardening Index von 85+ gilt als solide, 90+ als gut gehärtet. Werte über 95 sind auf Produktionsservern mit Anwendungsanforderungen selten erreichbar – und auch nicht nötig. Wichtiger als die Zahl ist die Trendkurve: Nach jedem Quartal sollte der Wert gleich bleiben oder steigen, nicht fallen.

Framework	Relevanz	Aufwand Erstabnahme
CIS Level 1	Basis für alle	4–8 Stunden pro Host
CIS Level 2	Hochsicherheitsumgebungen	2–4 Tage pro Host
BSI IT-Grundschutz	Deutsche Behörden/KMU	Wochen (organisatorisch)
NIS2	wesentliche/wichtige Einrichtungen	laufender Prozess
ISO 27001	Kundenanforderung	3–9 Monate gesamt

Für NIS2 konkret relevant: Art. 21 fordert technische und organisatorische Maßnahmen inklusive Risikoanalyse, Incident-Management, Business Continuity und Schwachstellenmanagement. Deine Härtungs-Checkliste mit Datum, Verantwortlichem und Scan-Ergebnis ist genau der Nachweis, den ein Auditor sehen will.

Schritt 11: Notfallplan, Backups und Incident Response

Härtung reduziert die Wahrscheinlichkeit eines Vorfalls, eliminiert sie aber nicht. Deshalb brauchst du einen Plan für den Fall der Fälle. Die Regel lautet 3-2-1-1-0: 3 Kopien, 2 Medien, 1 offsite, 1 offline/immutable, 0 Fehler bei der Wiederherstellung.

# restic-Backup mit S3-Backend
restic -r s3:s3.eu-central-003.backblazeb2.com/hostazar-backup \
  backup /etc /home /var/www --exclude-caches

# Snapshots aufbewahren
restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune

# Wiederherstellung testen – mindestens quartalsweise
restic restore latest --target /mnt/restore-test

Backblaze B2 kostet rund 6 US-Dollar pro TB und Monat, Hetzner Storage Box startet bei 3,81 Euro monatlich für 1 TB. Bei einem 50-GB-Backup sind das also unter 2 Euro im Monat – lächerlich wenig für die Versicherung gegen Datenverlust. Wichtig: Der Backup-Server darf nicht mit demselben SSH-Key erreichbar sein wie der Produktivserver. Nutze eigene Credentials mit Write-Only-Rechten.

Für Incident Response gehört ein einseitiges Runbook in jeden Server-Ordner: Wer wird informiert? Wie wird der Host isoliert (Netzwerk trennen, nicht herunterfahren – RAM-Forensik)? Wo liegen die Logs? Wer hat Zugriff auf welche Credentials? Und ganz wichtig: eine Liste aller Zugangsdaten, die nach einem Kompromittierungsverdacht rotiert werden müssen. Bei einem echten Vorfall ist die Rotation von 30 Credentials unter Zeitdruck die Hölle – vorbereitet dauert sie 45 Minuten.

Ein letzter, oft ignorierter Punkt: Snapshot vor jeder Änderung. Bei virtuellen Servern (Hetzner Cloud, Netcup, AWS) kostet ein Snapshot Cent-Beträge und rettet dich, wenn ein Härtungsschritt einen Dienst zerlegt. Der Ablauf lautet immer: Snapshot → Änderung → Test → 24 Stunden beobachten → Snapshot löschen.

FAQ

Wie lange dauert eine vollständige Linux-Server-Härtung?

Für einen einzelnen Host mit Standarddiensten (SSH, Webserver, Datenbank) rechnest du mit 3 bis 6 Stunden für die Ersteinrichtung inklusive Tests. Der Aufwand für Automatisierung lohnt sich ab etwa 5 Servern: Mit Ansible-Rollen wie dev-sec/ansible-collection-hardening bringst du einen neuen Host in 15 bis 20 Minuten auf dasselbe Niveau. Plane danach laufend 1 bis 2 Stunden pro Monat für Patch-Reviews, Scan-Auswertung und Log-Kontrolle ein.

Reicht UFW oder brauche ich zwingend nftables?

UFW ist unter der Haube selbst nftables und für einfache Setups mit wenigen Ports völlig ausreichend – ufw default deny incoming plus explizite Allows deckt 90 Prozent der Fälle ab. Zu nftables direkt wechselst du, wenn du mehrere Interfaces, Docker-Netzwerke, Rate-Limits oder eigenes Logging brauchst. Docker umgeht UFW-Regeln übrigens standardmäßig, weil es eigene iptables-Ketten schreibt – das ist einer der häufigsten Fehler in gehärteten Setups.

Ist ein anderer SSH-Port sinnvoll oder reine Sicherheitstheater?

Als Sicherheitsmaßnahme ist es Theater, weil Portscanner alle Ports in Sekunden finden. Als Betriebsmaßnahme ist es sinnvoll: Auf einem Host mit Port 22 siehst du 20.000 bis 60.000 fehlgeschlagene Logins pro Tag, auf einem alternativen Port sind es 50 bis 300. Das reduziert Log-Volumen, Fail2ban-Last und macht echte Angriffe sichtbar. Wichtiger als der Port sind aber Key-only-Auth, PermitRootLogin no und ein aktuelles OpenSSH.

Was kostet professionelle Server-Härtung im Vergleich zum Selbstmachen?

Ein externer Penetrationstest für einen einzelnen Host liegt bei 1.500 bis 4.000 Euro. Managed-Security-Anbieter verlangen für Server-Hardening-as-a-Service typischerweise 30 bis 80 Euro pro Host und Monat. Dem gegenüber stehen 3 bis 6 Stunden Eigenarbeit plus 1 bis 2 Stunden monatlich – bei einem internen Stundensatz von 70 Euro sind das rund 300 Euro initial und 100 Euro monatlich. Für Teams mit Linux-Erfahrung ist die Eigenlösung fast immer günstiger, für Teams ohne DevOps-Kapazität ist Managed Security die rationalere Wahl.

Muss ich nach der Härtung noch etwas tun, oder ist der Server dann sicher?

Ein gehärteter Server ist nicht „sicher“, sondern „deutlich schwerer angreifbar“. Die Härtung ist ein Zustand, der verfällt: Neue Dienste öffnen Ports, Updates ändern Defaults, Mitarbeiter wechseln. Deshalb brauchst du einen Zyklus – monatlich Lynis oder OpenSCAP laufen lassen, quartalsweise die Checkliste durchgehen, jährlich einen externen Scan oder Pentest. Wer die Härtung einmal macht und dann nie wieder hinschaut, hat nach 12 Monaten einen ähnlich angreifbaren Server wie vorher.