Fernwartung Download starten

Linux-Server-Härtung: 15-Minuten-Checkliste

LinuxSecurityHardeningServer
Linux-Server-Härtung: 15-Minuten-Checkliste

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.confapply_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:

IT-Beratung gewünscht?

Kontaktieren Sie uns für eine unverbindliche Beratung zu Proxmox, OPNsense, TrueNAS und mehr.

Jetzt Kontakt aufnehmen