DDoS-Schutzstrategien für dedizierte Infrastruktur

Verstehen, wovor du dich eigentlich schützt

DDoS-Angriffe sind keine einheitliche Bedrohung. Die Kategorie umfasst mehrere unterschiedliche Angriffsvektoren, die verschiedene Abwehrstrategien erfordern:

Volumetrische Angriffe überfluten deine Netzwerkleitung mit Datenverkehr – UDP-Floods, ICMP-Floods, Amplifikationsangriffe über DNS oder NTP. Diese werden in Gbit/s und Mpps (Millionen Pakete pro Sekunde) gemessen. Ein volumetrischer Angriff mit 100 Gbit/s auf einen Server mit 10 Gbit/s-Konnektivität füllt die Leitung einfach, egal wie gut deine Firewall auf Serverebene ist. Um das zu verhindern, muss der Datenverkehr upstream gefiltert werden, bevor er dein Rechenzentrum erreicht.

Protokollangriffe nutzen Schwachstellen im TCP/IP aus – SYN-Floods sind dabei die häufigsten. Diese belasten eher die Kapazität der Verbindungstabelle auf deinem Server als die Bandbreite. Ein anhaltender SYN-Flood kann einen Server lahmlegen, ohne die Netzwerkverbindung zu überlasten.

Angriffe auf Layer 7 (Anwendung) zielen direkt auf deine Anwendung ab. Langsame Angriffe wie Slowloris halten Verbindungen ewig offen und verbrauchen so die Verbindungslimits, ohne viel Datenverkehr zu verursachen. HTTP-Floods schicken Anfragen, die echt aussehen, an ressourcenintensive Anwendungsendpunkte – Seiten mit vielen Datenbanken, Downloads großer Dateien, Suchfunktionen.

Laut dem DDoS-Bedrohungsbericht 2024 Cloudflare haben HTTP-DDoS-Angriffe im Vergleich zum Vorjahr stark zugenommen, wobei Angriffe auf Anwendungsebene jetzt einen großen Teil der gesamten DDoS-Vorfälle ausmachen. Volumetrische Angriffe gibt's immer noch, aber clevere Angreifer zielen immer öfter direkt auf die Anwendungsebene ab, weil sie durch einfaches volumetrisches Scrubbing nicht gestoppt werden können.

Schicht 1: Vorbeugende Maßnahmen (Reinigungszentren)

Bei Volumenangriffen hilft keine noch so gute Konfiguration auf der Serverseite, wenn deine 10-Gbit/s-Verbindung schon mit 40 Gbit/s Angriffsverkehr voll ist. Die Abwehr muss schon vorher passieren, bevor der Datenverkehr deinen Server erreicht.

Sowohl Magic TransitCloudflare als auch AWS Shield Advanced bieten Upstream-Scrubbing-Dienste, die den Datenverkehr filtern, bevor er in deinem Rechenzentrum ankommt. Die Netzwerkkapazität Cloudflareliegt bei über 250 Tbit/s, was bedeutet, dass sie volumetrische Angriffe abfangen können, die die Transitkapazität eines einzelnen Rechenzentrums überfordern würden. Magic Transit kündigt deine IP-Präfixe über BGP an und leitet den gesamten Datenverkehr über die Scrubbing-Infrastruktur Cloudflare, wobei nur sauberer Datenverkehr an deinen Server weitergeleitet wird.

Diese Schicht ist ein Muss für Infrastrukturen, die bei Volumenangriffen immer verfügbar sein müssen. Die folgenden serverseitigen Techniken kümmern sich um Layer-7- und Protokollangriffe, lösen aber nicht das Problem der Bandbreitenerschöpfung.

Das dedizierte ServernetzwerkInMotion Hosting bietet grundlegende DDoS-Abwehr auf Rechenzentrumsebene. Für Umgebungen mit höheren Bedrohungsvolumina sorgt die Einbindung eines CDN- oder Scrubbing-Dienstes vor Ihrer InMotion-Infrastruktur für die erforderliche Upstream-Kapazität, um große Angriffe abzufangen.

Schicht 2: Ratenbegrenzung auf dem Webserver

Nginx Apache können beide die Verbindungsrate begrenzen, um Layer-7-Floods zu stoppen, bevor sie die Ressourcen des Anwendungsservers belasten.

Nginx -Konfiguration für Nginx renzung:

# Zone zum Verfolgen von Anfragen anhand der IP-Adresse festlegen

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r/m;

server {

    Standort /api/ {

        limit_req zone=api_limit burst=10 nodelay;

        limit_req_status 429;

    }

}

Diese Konfiguration begrenzt jede einzelne IP-Adresse auf 30 Anfragen pro Minute an /api/-Endpunkte, mit einer Burst-Zulassung von 10 Anfragen, bevor die Ratenbegrenzung einsetzt. Die Dokumentation zur RatenbegrenzungNginx deckt den kompletten Parametersatz ab. Leg die Raten basierend auf echtem Nutzerverhalten fest – ein authentifizierter Nutzer, der ein Formular abschickt, sollte keine Begrenzung auslösen; ein automatisiertes Skript, das 500 Mal pro Minute einen Endpunkt ansteuert, sollte das schon.

Verbindungsbeschränkung für Slowloris-Angriffe:

limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

server {

    limit_conn conn_limit 20;

    client_body_timeout 10s;

    client_header_timeout 10s;

    send_timeout 10s;

}

Die Timeout-Werte sind echt wichtig. Slowloris schickt HTTP-Header ganz langsam und hält so die Verbindungen offen. Kurze Timeouts brechen diese Verbindungen ab, bevor sie sich ansammeln.

Schicht 3: Firewall-Regeln zur Abwehr von Protokollangriffen

Der Schutz vor SYN-Floods fängt bei Linux mit Einstellungen auf Kernel-Ebene an:

Aktiviere SYN-Cookies, um SYN-Floods zu verarbeiten, ohne die Verbindungstabellen zu überlasten.

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Reduzier die Anzahl der SYN-ACK-Wiederholungen, bevor der Kernel die Verbindung trennt.

echo 2 > /proc/sys/net/ipv4/tcp_syn_retries

# Verkürze die Dauer des TIME_WAIT-Status, um Verbindungen schneller wiederzuverwenden

echo „1 4 2 6 10 15 25 26“ > /proc/sys/net/ipv4/tcp_retries2

# Dauerhaft machen

sysctl -p

Für die Abwehr auf Firewall-Ebene bietet nftables (ersetzt iptables in modernen Linux-Distributionen) eine effiziente Paketfilterung mit minimalem CPU-Overhead:

# Blockiere ungültige TCP-Pakete (die bei SYN-Flood-Angriffen oft vorkommen)

nft add rule inet filter input tcp flags '& (fin|syn|rst|psh|ack|urg) == fin|psh|urg' drop

# Neue Verbindungen begrenzen

nft add rule inet filter input ct state new limit rate 100/second accept

nft add rule inet filter input ct state new drop

Fail2Ban macht das Blockieren von IP-Adressen automatisch anhand von Log-Mustern, was bei wiederholten fehlgeschlagenen Authentifizierungsversuchen oder anhaltenden Anfragen von einzelnen IP-Adressen, die durch Ratenbegrenzer schlüpfen, echt nützlich ist. Fail2Ban checkt deine Nginx, Apache- oder SSH-Logs und fügt automatisch iptables/nftables-Regeln hinzu, wenn bestimmte Schwellenwerte überschritten werden.

Schicht 4: IP-Reputation und Geofilterung

IP-Reputationsfilterung stoppt bekannte bösartige IPs, bevor sie deine Anwendung erreichen. Dienste wie AbuseIPDB haben Datenbanken mit IPs, die schon mal missbraucht wurden. Wenn du diese Sperrlisten in deine Firewall oder WAF einbaust, wird der Datenverkehr von IPs, die schon mal an Angriffen beteiligt waren, abgeblockt.

Geografische Filterung ist schwieriger zu entscheiden. Während eines Angriffs klingt es verlockend, ganze Länder zu blockieren, aber man sollte die Kollateralschäden sorgfältig abwägen. Private IP-Adressen in jedem Land können kompromittiert und als Botnetz-Knotenpunkte genutzt werden, sodass Geoblocking selten einen vollständigen Schutz bietet. Für Anwendungen, die in bestimmten Regionen wirklich keine legitimen Nutzer haben, ist Geofilterung eine sinnvolle erste Schutzmaßnahme.

Die kostenlose Version Cloudflarebietet sowohl IP-Reputationsfilterung als auch Blockierung auf Länderebene, ohne dass man irgendwas auf dem Server einstellen muss.

Schicht 5: Schutz auf Anwendungsebene

Die gezieltesten Layer-7-Angriffe zielen absichtlich auf teure Anwendungsvorgänge ab. Häufige Ziele:

• Suchfunktionen, die Abfragen in Volltextdatenbanken starten
• Login-Endpunkte, die einen bcrypt-Hash-Vergleich brauchen
• Endpunkte für den Download großer Dateien
• WordPress und Admin-Endpunkte, wenn öffentlich zugänglich

Schütze teure Endgeräte mit:

• CAPTCHA-Herausforderungen über Cloudflare oder hCaptcha bei der Anmeldung und Registrierung
• API-Schlüssel oder Authentifizierung auf jedem Endpunkt, der Datenbankabfragen ausführt
• WordPress Absicherung: Deaktivier XML-RPC, wenn du es nicht brauchst (deny all; in Nginx /xmlrpc.php), sperr den Zugriff auf /wp-admin/ per IP-Whitelist, wenn dein Team geografisch zusammenarbeitet.

Reaktion auf Vorfälle: Was tun, wenn ein Angriff läuft?

Wenn du gerade angegriffen wirst, sind die Prioritäten wie folgt:

1. Identifiziere die Art des Angriffs: Überprüfe netstat -an | grep SYN_RECV | wc -l auf SYN-Floods; schau in den Nginx nach HTTP-Flood-Mustern; überprüfe iftop auf volumetrische Angriffe.
2. Aktiviere Cloudflare einen ähnlichen Proxy sofort: Leite den Datenverkehr über einen Scrubbing-Dienst, falls das noch nicht eingerichtet ist. Das ist der schnellste Weg, um das Datenvolumen zu reduzieren.
3. Temporary IP blocks for obvious attack sources: nft add rule inet filter input ip saddr <attack_ip> drop
4. Wende dich an den InMotion-Support: Das APS-Team kann dir bei der Verkehrsanalyse helfen und sich mit dem Netzwerkbetriebszentrum wegen der Filterung im Upstream abstimmen.

Die Teams, die nach DDoS-Angriffen am schnellsten wieder auf die Beine kommen, sind die, die ihren Plan schon vor einem Angriff getestet haben.