# DDoS Protection: Den Ansturm im Keim ersticken

TL;DR / Management Summary Ein massiver DDoS-Angriff (Distributed Denial of Service) kann selbst die stärkste Infrastruktur lahmlegen. Während große Attacken auf Provider-Ebene abgewehrt werden müssen, können wir den Linux-Host gegen kleinere Angriffe und “Background Noise” härten. Wir nutzen Rate-Limiting für neue Verbindungen, begrenzen die Anzahl der parallelen Sitzungen pro IP und nutzen Tarpitting, um Scannern die wertvolle Zeit zu stehlen. Ziel ist ein System, das unter Last zwar langsamer wird, aber niemals komplett offline geht.

# 1. Einführung & Architektur

Die Physik des Angriffs.

Ein DDoS-Angriff zielt meist auf drei Ressourcen:

1. Bandbreite: Die Leitung ist voll.
2. CPU/RAM: Die Firewall oder Applikation bricht unter der Last der Paketverarbeitung zusammen.
3. Connection Table: Die Conntrack-Tabelle (Artikel 308) läuft voll.

# Die Verteidigungs-Strategien (Mermaid)

graph TD
    A[Massive Traffic] --> B{Kernel: nftables / iptables}
    B -->|Check 1| C[Rate Limit: max 10 conn/sec]
    B -->|Check 2| D[Conn Limit: max 20 active]
    B -->|Check 3| E[ICMP Limit: No Ping Flood]
    C/D/E -->|Over Limit| F[DROP / REJECT]
    C/D/E -->|Inside Limit| G[Application]

# 2. SYN-Flood Abwehr (TCP)

Halboffene Verbindungen verhindern.

Angreifer senden tausende SYN-Pakete, antworten aber nie auf das ACK des Servers. Die Conntrack-Tabelle füllt sich mit “halboffenen” Verbindungen.

# Die Lösung: SYN Cookies

Aktivieren Sie dieses Kernel-Feature, um Verbindungen ohne Belegung von RAM-Speicher zu validieren:

echo "net.ipv4.tcp_syncookies = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# 3. Rate-Limiting mit nftables

Präzise Drosselung.

Nftables ist deutlich effizienter beim Rate-Limiting als das alte Iptables.

# Beispiel: Neue SSH-Verbindungen begrenzen

# In /etc/nftables.conf
table inet filter {
    chain input {
        # Max 3 neue SSH-Verbindungen pro Minute pro IP
        tcp dport 22 ct state new limit rate over 3/minute drop
        tcp dport 22 ct state new accept
    }
}

# 4. Day-2 Operations: Tarpitting (Die Teergrube)

Angreifer beschäftigen.

Ein DROP ist schnell. Ein TARPIT (nur via Iptables-Extensions) hält die Verbindung künstlich offen, ohne Ressourcen zu verbrauchen, und zwingt den Angreifer zum Warten.

# Connection Limits pro IP

Verhindern Sie, dass ein einzelner Client hunderte Sockets öffnet:

sudo iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 20 -j REJECT --reject-with tcp-reset

# 5. Troubleshooting & “War Stories”

Wenn die Abwehr die Kunden aussperrt.

# Story 1: “Der falsche Alarm beim Office-Proxy”

Symptom: Alle Mitarbeiter eines Kunden können die Webseite gleichzeitig nicht mehr erreichen. Ursache: Das connlimit steht auf 20. Da alle Mitarbeiter über die gleiche öffentliche IP (NAT) kommen, erreichen sie das Limit gemeinsam in Sekunden. Lösung: Setzen Sie höhere Limits für bekannte Quell-Netze oder nutzen Sie dynamische Analyse-Tools, die das Nutzerverhalten (Layer 7) statt nur IPs (Layer 4) bewerten.

# Story 2: “Der Performance-Drop durch Logging”

Symptom: Während einer DDoS-Attacke steigt die Load des Servers auf 500, obwohl die Firewall alle Pakete droppt. Ursache: Die Firewall-Regel hat ein log Statement ohne Rate-Limit. Das Schreiben der Millionen Logzeilen blockiert das System mehr als der Angriff selbst. Lösung: Nutzen Sie Log-Limits (Artikel 311) oder deaktivieren Sie das Logging für Dropped-Pakete während eines Angriffs komplett.

# 6. Fazit & Empfehlung

• Zwiebel-Prinzip: Nutzen Sie eine externe Cloud-Firewall (Cloudflare, Akamai), um die Bandbreite abzufangen. Nutzen Sie nftables auf dem Host für den Schutz der Systemressourcen.
• Kernel: Optimieren Sie den Netzwerk-Stack via sysctl (siehe Artikel 237).
• Wahl: Nutzen Sie nftables Sets (Artikel 309) für Blacklisting, da diese bei tausenden Einträgen performanter sind als Einzelregeln.

# Anhang: Cheatsheet