Security Linux

Linux Server Hardening Checkliste 2026

Konkrete Härtungsmaßnahmen für Linux-Server: SSH absichern, Firewall richtig konfigurieren, Kernel-Parameter setzen und automatische Updates einrichten – ohne den Überblick zu verlieren.

EH
Emre Hayta
· · 11 Min. Lesezeit
Inhaltsverzeichnis

Warum Hardening in 2026 wichtiger denn je ist

Ein frisch aufgesetzter Ubuntu- oder Debian-Server ist kein sicheres System – er ist ein leerer Rohbau. Die Defaults sind auf maximale Kompatibilität ausgelegt, nicht auf Sicherheit. Shodan und ähnliche Dienste scannen kontinuierlich das gesamte IPv4-Adressraum; ein neuer Server ist oft innerhalb von Minuten im Visier automatisierter Bots.

Die gute Nachricht: Die meisten Angriffe sind opportunistisch. Wer die Basis-Hygiene konsequent umsetzt, ist für den Großteil der automatisierten Angriffe schlicht kein lohnendes Ziel mehr. Diese Checkliste zeigt, was 2026 wirklich zählt – ohne akademischen Overhead, direkt anwendbar.

SSH absichern: die unterschätzte Angriffsfläche

SSH ist die häufigste Einfallspforte – nicht wegen technischer Schwächen im Protokoll, sondern wegen schlechter Konfiguration. Die wichtigsten Stellschrauben in /etc/ssh/sshd_config:

sshd_config
# Passwort-Login deaktivieren – nur Key-Auth erlauben
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

# Root-Login verbieten
PermitRootLogin no

# Nur bestimmte Benutzer erlauben
AllowUsers deploy admin

# Port ändern (Security through Obscurity, aber wirksam gegen Bot-Traffic)
Port 2222

# Leerlauf-Timeouts setzen
ClientAliveInterval 300
ClientAliveCountMax 2

# X11-Forwarding deaktivieren (wenn nicht benötigt)
X11Forwarding no

# MaxAuthTries reduzieren
MaxAuthTries 3

Nach Änderungen immer testen, bevor du die aktuelle Session schließt:

bash
sshd -t && systemctl reload sshd

Fail2Ban als zweite Verteidigungslinie

Fail2Ban erkennt wiederholte fehlgeschlagene Login-Versuche und blockiert die Quell-IP automatisch. Installation und Grundkonfiguration:

bash
apt install fail2ban -y

# /etc/fail2ban/jail.local erstellen
cat > /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port    = 2222
EOF

systemctl enable --now fail2ban

Firewall mit UFW oder nftables

UFW (Uncomplicated Firewall) ist das pragmatische Werkzeug für die meisten Server – einfach, lesbar, ausreichend. Wer mehr Kontrolle braucht, greift zu nftables direkt.

bash
# Standardrichtlinien: alles blockieren, ausgehend erlauben
ufw default deny incoming
ufw default allow outgoing

# Nur benötigte Ports öffnen
ufw allow 2222/tcp   # SSH (angepasster Port)
ufw allow 80/tcp     # HTTP
ufw allow 443/tcp    # HTTPS

# UFW aktivieren
ufw enable
ufw status verbose
Wichtig: Aktiviere UFW erst, nachdem du deinen SSH-Port freigegeben hast – sonst sperrst du dich selbst aus.

Für produktive Umgebungen lohnt sich zusätzlich nftables mit Rate-Limiting, um SYN-Floods abzuwehren:

nftables
# Rate-Limit für neue SSH-Verbindungen (max 5 pro Minute)
nft add rule inet filter input tcp dport 2222 \
  ct state new limit rate 5/minute accept

Brauchst du Unterstützung bei der Umsetzung?

30-Min Call — kostenlos, unverbindlich, konkret.

Termin buchen →

Automatische Sicherheitsupdates

Ungepatchte Systeme sind die häufigste Ursache für erfolgreiche Angriffe. unattended-upgrades sorgt dafür, dass Sicherheits-Patches automatisch eingespielt werden:

bash
apt install unattended-upgrades apt-listchanges -y
dpkg-reconfigure --priority=low unattended-upgrades

Die Konfigurationsdatei /etc/apt/apt.conf.d/50unattended-upgrades erlaubt feingranulare Steuerung:

bash
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

# Automatisch neu starten, wenn Kernel-Update es erfordert (optional)
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

# E-Mail bei Fehlern
Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";

Kernel-Parameter härten mit sysctl

Die Kernel-Parameter steuern viele sicherheitsrelevante Verhaltensweisen des Systems. Eine solide Basiskonfiguration in /etc/sysctl.d/99-hardening.conf:

sysctl
# IP-Forwarding deaktivieren (außer auf Router/Gateway)
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# SYN-Flood-Schutz
net.ipv4.tcp_syncookies = 1

# ICMP-Redirects ignorieren
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Source-Routing deaktivieren
net.ipv4.conf.all.accept_source_route = 0

# Martian Packets loggen
net.ipv4.conf.all.log_martians = 1

# ASLR aktivieren (meist default, aber explizit setzen)
kernel.randomize_va_space = 2

# Core Dumps einschränken
fs.suid_dumpable = 0
bash
# Parameter sofort laden
sysctl --system

Benutzerverwaltung und Rechteminimierung

Das Prinzip der minimalen Rechte ist einfach: Jeder Dienst und jeder Benutzer erhält nur die Rechte, die er tatsächlich braucht. In der Praxis bedeutet das:

  • Kein direkter Root-Login. Stattdessen sudo für privilegierte Aktionen nutzen.
  • Dedizierte Service-Accounts. Nginx, Postgres, Node.js – jeder Dienst läuft unter eigenem Benutzer ohne Login-Shell.
  • Sudo-Konfiguration prüfen. NOPASSWD nur dort, wo es wirklich nötig ist.
bash
# Benutzer ohne Login-Shell für Dienste anlegen
useradd --system --no-create-home --shell /bin/false myservice

# Sudo-Berechtigungen auflisten
sudo -l -U username

# Accounts mit UID 0 (root-equivalent) finden
awk -F: '($3 == 0) {print}' /etc/passwd

# Leere Passwörter finden
awk -F: '($2 == "") {print}' /etc/shadow

Monitoring und Audit-Logging

Härtung ohne Logging ist blind. auditd protokolliert sicherheitsrelevante Ereignisse auf Kernel-Ebene:

bash
apt install auditd audispd-plugins -y
systemctl enable --now auditd

# Wichtige Audit-Regeln in /etc/audit/rules.d/hardening.rules
cat > /etc/audit/rules.d/hardening.rules << 'EOF'
# Änderungen an Benutzern und Gruppen
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers

# SSH-Konfiguration überwachen
-w /etc/ssh/sshd_config -p wa -k sshd

# Privilegierte Befehle
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
EOF

augenrules --load

Ergänzend lohnt sich logwatch für tägliche Zusammenfassungen per E-Mail sowie rkhunter oder chkrootkit für periodische Rootkit-Scans:

bash
apt install rkhunter -y
rkhunter --update
rkhunter --check --sk   # --sk = skip key press

# Als Cron-Job täglich ausführen
echo "0 3 * * * root rkhunter --check --sk --quiet" \
  > /etc/cron.d/rkhunter-daily

Die Kurzcheckliste zum Abhaken

Eine schnelle Übersicht für den Einsatz als Runbook oder Post-Deploy-Check:

  • ☐ SSH: Passwort-Auth deaktiviert, Root-Login verboten, Port geändert
  • ☐ Fail2Ban installiert und konfiguriert
  • ☐ UFW aktiviert, nur benötigte Ports offen
  • unattended-upgrades aktiv für Security-Patches
  • ☐ sysctl-Hardening-Parameter gesetzt
  • ☐ Kein unnötiger Dienst aktiv (systemctl list-units --type=service)
  • ☐ Alle Benutzer mit gültigem Account überprüft
  • ☐ auditd installiert und Basisregeln geladen
  • ☐ rkhunter oder AIDE für Integritätsprüfung eingerichtet
  • ☐ Firewall-Regeln dokumentiert und versioniert (z.B. in Git)
Tipp: Automatisiere diese Checkliste mit Ansible. Eine idempotente Rolle, die du nach jedem Server-Setup einspielst, ist langfristig wertvoller als manuelle Konfiguration. Ein Beispiel dafür findest du im Artikel Ansible Automation für Linux Server.

Hardening ist kein einmaliges Projekt – es ist ein kontinuierlicher Prozess. Neue CVEs, geänderte Anforderungen und wachsende Infrastruktur erfordern regelmäßige Überprüfungen. Wer diese Checkliste als Baseline einsetzt und sie in seinen Deploy-Prozess integriert, ist für den Großteil der realen Bedrohungen gut gewappnet.

EH
Emre Hayta
IT-Consultant & Infrastructure Automation

Ich helfe KMUs und Tech-Teams dabei, ihre Infrastruktur zu automatisieren, abzusichern und skalierbar zu machen – mit Ansible, Terraform und pragmatischen Lösungen ohne Overhead.

Weitere Artikel