Linux Server Hardening: Die wichtigsten Sicherheitsmaßnahmen

Ein frisch installierter Linux-Server ist nicht automatisch sicher. Standard-Konfigurationen sind auf Kompatibilität optimiert, nicht auf Sicherheit. SSH mit Passwort-Login, offene Ports, fehlende Firewall, veraltete Pakete — jeder dieser Punkte ist ein potentielles Einfallstor. Server Hardening schließt diese Lücken systematisch. Die folgenden Maßnahmen gelten für Debian und Ubuntu, lassen sich aber auf jede Linux-Distribution übertragen.

1. SSH absichern

SSH ist der häufigste Angriffsvektor auf Linux-Server. Ein aus dem Internet erreichbarer SSH-Dienst wird innerhalb von Minuten automatisiert angegriffen.

Passwort-Login deaktivieren

Ausschließlich SSH-Key-Authentifizierung zulassen (/etc/ssh/sshd_config):

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM no

Root-Login verbieten

PermitRootLogin no

Stattdessen einen normalen Benutzer mit sudo-Rechten verwenden.

SSH-Port ändern (optional)

Port 2222

Ändert nicht die Sicherheit, reduziert aber automatisierte Brute-Force-Versuche um >95 %. Script-Kiddies scannen primär Port 22.

Weitere SSH-Härtungen

MaxAuthTries 3
LoginGraceTime 30
AllowUsers admin deploy
ClientAliveInterval 300
ClientAliveCountMax 2

Nach Änderungen: systemctl restart sshd

2. Firewall konfigurieren

Jeder Server sollte eine lokale Firewall betreiben — auch wenn eine Netzwerk-Firewall (OPNsense) vorgeschaltet ist. Defense-in-Depth.

UFW (Uncomplicated Firewall)

# Alles blockieren, nur explizit Erlaubtes durchlassen
ufw default deny incoming
ufw default allow outgoing

# SSH erlauben
ufw allow 2222/tcp

# Webserver (falls nötig)
ufw allow 80/tcp
ufw allow 443/tcp

# Aktivieren
ufw enable

Alternativ: nftables

Für komplexere Regelwerke bietet nftables (Nachfolger von iptables) mehr Flexibilität:

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif lo accept
        ct state established,related accept
        tcp dport 2222 accept
        tcp dport { 80, 443 } accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

3. Automatische Sicherheitsupdates

Ungepatchte Software ist das häufigste Einfallstor. Sicherheitsupdates sollten automatisch installiert werden.

unattended-upgrades (Debian/Ubuntu)

apt install unattended-upgrades
dpkg-reconfigure unattended-upgrades

In /etc/apt/apt.conf.d/50unattended-upgrades sicherstellen:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Mail "admin@example.com";

Wichtig: Automatic-Reboot auf false setzen — Kernel-Updates erfordern einen Reboot, der im Betrieb koordiniert werden sollte. Nicht-Kernel-Updates werden sofort wirksam.

4. Benutzer und Rechte

Prinzip der minimalen Rechte

• Kein Dienst sollte als root laufen (Ausnahme: Dienste die privilegierte Ports <1024 benötigen — dafür cap_net_bind_service verwenden)
• Jeder Dienst bekommt einen eigenen Benutzer (www-data, postgres, prometheus)
• sudo-Zugriff nur für Administratoren, nicht für Dienst-Accounts

sudo konfigurieren

# Benutzer zur sudo-Gruppe hinzufügen
usermod -aG sudo admin

# sudo-Timeout verkürzen (Standard: 15 Min)
# In /etc/sudoers.d/timeout:
Defaults timestamp_timeout=5

Unnötige Benutzer deaktivieren

Standard-Installationen enthalten oft Benutzer die nicht benötigt werden:

# Shell auf nologin setzen
usermod -s /usr/sbin/nologin games
usermod -s /usr/sbin/nologin news
usermod -s /usr/sbin/nologin uucp

5. Dienste minimieren

Jeder laufende Dienst vergrößert die Angriffsfläche. Nur installieren und aktivieren, was benötigt wird.

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

# Nicht benötigte Dienste deaktivieren
systemctl disable --now cups
systemctl disable --now avahi-daemon
systemctl disable --now bluetooth

Typisch unnötig auf Servern: cups (Drucken), avahi-daemon (mDNS/Bonjour), bluetooth, ModemManager.

6. Kernel-Härtung mit sysctl

Kernel-Parameter in /etc/sysctl.d/99-hardening.conf:

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

# ICMP-Redirect ablehnen (verhindert MITM)
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
net.ipv6.conf.all.accept_source_route = 0

# IP Forwarding nur wenn nötig (Router/Gateway)
net.ipv4.ip_forward = 0

# Reverse Path Filter (Anti-Spoofing)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Kernel-Adressen in /proc verstecken
kernel.kptr_restrict = 2

# dmesg nur für root
kernel.dmesg_restrict = 1

# Core-Dumps deaktivieren
fs.suid_dumpable = 0

Aktivieren: sysctl --system

7. Dateisystem absichern

Temporäre Verzeichnisse

/tmp und /var/tmp mit noexec mounten — verhindert die Ausführung von Malware aus temporären Verzeichnissen:

In /etc/fstab:

tmpfs /tmp tmpfs defaults,nosuid,nodev,noexec 0 0

Wichtige Verzeichnisse schützen

# Cron-Zugriff einschränken
chmod 700 /etc/cron.d
chmod 700 /etc/cron.daily
chmod 700 /etc/cron.hourly

# SSH-Konfiguration schützen
chmod 600 /etc/ssh/sshd_config
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

8. Logging und Auditierung

Zentrale Logs mit journald

Sicherstellen dass Logs persistent sind:

# /etc/systemd/journald.conf
Storage=persistent
MaxRetentionSec=90day

Auditd für kritische Aktionen

apt install auditd

# Beispiel-Regeln in /etc/audit/rules.d/hardening.rules:
# SSH-Config-Änderungen überwachen
-w /etc/ssh/sshd_config -p wa -k sshd_config
# Benutzer-/Gruppenverwaltung überwachen
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/group -p wa -k group_changes
# sudo-Nutzung überwachen
-w /var/log/auth.log -p wa -k auth_log

Log-Weiterleitung

Logs an einen zentralen Syslog-Server oder SIEM weiterleiten:

• Verhindert dass ein Angreifer lokale Logs manipuliert
• Ermöglicht Korrelation über mehrere Server
• DATAZONE Control kann Logs zentral aggregieren

9. fail2ban gegen Brute Force

fail2ban überwacht Log-Dateien und sperrt IP-Adressen nach zu vielen fehlgeschlagenen Login-Versuchen:

apt install fail2ban

Konfiguration in /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3

[sshd]
enabled = true
port = 2222

Nach 3 fehlgeschlagenen SSH-Logins innerhalb von 10 Minuten wird die IP für 1 Stunde gesperrt.

10. Verschlüsselung

Disk-Verschlüsselung mit LUKS

Für Server mit physischem Zugangsrisiko (Colocation, Remote-Standorte):

# Partition verschlüsseln (bei Installation oder nachträglich)
cryptsetup luksFormat /dev/sda2
cryptsetup open /dev/sda2 crypt-root

TLS für alle Dienste

Jeder Netzwerk-Dienst sollte verschlüsselt kommunizieren:

• Webserver: HTTPS mit Let’s Encrypt
• Datenbank: TLS-Verbindungen erzwingen
• E-Mail: STARTTLS / SMTPS
• Monitoring: HTTPS für Dashboards

Hardening-Checkliste

Maßnahme	Priorität	Status
SSH: Key-Only, kein Root-Login	Kritisch	☐
Lokale Firewall (ufw/nftables)	Kritisch	☐
Automatische Sicherheitsupdates	Kritisch	☐
Unnötige Dienste deaktivieren	Hoch	☐
Benutzer-Rechte minimieren	Hoch	☐
sysctl-Kernel-Härtung	Hoch	☐
fail2ban für SSH	Hoch	☐
/tmp mit noexec mounten	Mittel	☐
auditd für Änderungsüberwachung	Mittel	☐
Disk-Verschlüsselung (LUKS)	Mittel	☐

Häufig gestellte Fragen

Reicht SSH-Key-Authentifizierung als einzige Maßnahme?

Nein — SSH-Keys sichern nur den Zugang, nicht den Server selbst. Ein kompromittierter Dienst (Webserver, Datenbank) kann den Server auch ohne SSH-Zugang gefährden. Alle Maßnahmen zusammen bilden ein Defense-in-Depth-Konzept.

Welche Maßnahme hat den größten Effekt?

SSH-Hardening und automatische Updates zusammen eliminieren >90 % der häufigsten Angriffsvektoren. Diese beiden Maßnahmen sollten auf jedem Server als erstes umgesetzt werden.

Wie prüfe ich ob mein Server gehärtet ist?

Tools wie Lynis (apt install lynis && lynis audit system) analysieren die Server-Konfiguration und geben konkrete Empfehlungen. CIS-Benchmarks bieten detaillierte Checklisten für jede Distribution.

Kann DATAZONE Control das Hardening automatisieren?

Ja — über Script-Ausführung kann DATAZONE Control Hardening-Maßnahmen auf allen verwalteten Servern gleichzeitig ausrollen und den Compliance-Status regelmäßig prüfen.

---

Sie möchten Ihre Linux-Server professionell absichern? Kontaktieren Sie uns — wir führen ein Security-Audit durch und implementieren die passenden Hardening-Maßnahmen.