Linux-Server absichern: Ein systematischer Ansatz

Server Hardening wird oft als Checkliste behandelt: SSH-Port ändern, Root-Login deaktivieren, Firewall einrichten, fertig. Das Problem: Checklisten veralten. Angreifer nicht. Dieser Artikel beschreibt einen systematischen Ansatz, der unabhängig von der Distribution funktioniert.

Das Prinzip: Angriffsfläche minimieren

Jeder laufende Dienst, jeder offene Port, jede installierte Software ist ein potenzieller Angriffsvektor. Der erste Schritt beim Härten ist nicht das Hinzufügen von Sicherheitsmaßnahmen — sondern das Entfernen von allem, was nicht gebraucht wird.

Phase 1: Bestandsaufnahme

Bevor du härtest, musst du wissen, was läuft. Klingt trivial, wird aber überraschend oft übersprungen.

# Alle lauschenden Dienste anzeigen
ss -tlnp

# Installierte Pakete auflisten (Debian/Ubuntu)
dpkg --get-selections | grep -v deinstall | wc -l

# Aktive systemd-Units
systemctl list-units --type=service --state=running

Die Frage bei jedem Eintrag: Brauche ich das? Wenn die Antwort nicht eindeutig ja ist, deaktivieren oder deinstallieren.

Phase 2: Netzwerk-Ebene

Die Firewall ist die erste Verteidigungslinie. Aber eine Firewall allein ist kein Sicherheitskonzept — sie ist ein Werkzeug.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;

    # Established/related connections
    ct state established,related accept

    # Loopback
    iif lo accept

    # ICMP (begrenzt)
    ip protocol icmp limit rate 5/second accept
    ip6 nexthdr icmpv6 limit rate 5/second accept

    # SSH (nur von bestimmtem Subnetz)
    tcp dport 22 ip saddr 10.0.0.0/8 accept

    # HTTP/HTTPS
    tcp dport { 80, 443 } accept

    # Alles andere loggen und verwerfen
    log prefix "nftables-drop: " limit rate 5/minute
    drop
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
  }

  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Phase 3: Authentifizierung

SSH ist der häufigste Angriffsvektor auf Linux-Server. Die Konfiguration sollte restriktiv sein:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy
ClientAliveInterval 300
ClientAliveCountMax 2

Passwort-basierte Authentifizierung hat auf Servern nichts verloren. Punkt. Ed25519-Keys sind der aktuelle Standard — kleiner und schneller als RSA, bei mindestens gleichwertiger Sicherheit.

Phase 4: Monitoring und Auditing

Härtung ohne Monitoring ist wie ein Schloss ohne Alarmanlage. Du merkst erst, dass etwas schiefgelaufen ist, wenn es zu spät ist.

Die Minimalausstattung:

1. auditd für Systemaufrufe und Dateizugriffe
2. fail2ban für automatische IP-Sperren bei Brute-Force
3. Zentrales Logging — Logs auf dem kompromittierten Server selbst sind wertlos

# /etc/audit/rules.d/hardening.rules
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/ssh/sshd_config -p wa -k sshd
-w /etc/sudoers -p wa -k sudoers
-a always,exit -F arch=b64 -S execve -k exec

Phase 5: Automatisierung

Manuelle Härtung skaliert nicht. Was nicht automatisiert ist, wird vergessen — spätestens beim nächsten Server.

Ansible, Puppet oder Chef sind hier die Werkzeuge der Wahl. Der Vorteil: Die Konfiguration ist versioniert, reproduzierbar und auditierbar. Wenn jemand fragt “Warum ist dieser Port offen?”, zeigt ein git blame auf dem Playbook die Antwort.

Fazit

Server Hardening ist kein einmaliger Akt, sondern ein Prozess. Die Bedrohungslandschaft ändert sich, neue CVEs werden veröffentlicht, Anforderungen verschieben sich. Ein guter Ansatz ist einer, der sich an diese Veränderungen anpassen lässt — nicht einer, der die längste Checkliste hat.