DDoS-Schutz und Paketfilterung

Kurze Zusammenfassung

DDoS-Angriffe gibt es in drei Klassen: L3/L4 volumetric (verstopfen den Kanal/die Hardware), state-exhaustion (erschöpfen die Statustabellen/CPU auf Balancern/Firewalls) und L7 (erzeugen „plausible“ Anforderungen an die Anwendung). Effektive Verteidigung ist in mehreren Schichten aufgebaut: Netzwerkmaßnahmen am Perimeter, Filterung/Scrabbing außerhalb Ihres Netzwerks, Schutz auf Balancern/Proxys und Anwendungen sowie Betriebsverfahren mit messbaren SLOs.

Bedrohungslandschaft

Volumetric (UDP/ICMP flood, die Amplifikation DNS/NTP/SSDP/CLDAP/Memcached): das Ziel - den Kanal und die Häfen einzuschlagen.
TCP state-exhaustion (SYN/ACK flood, TCP fragmentation, Verbindungen „auf halber Höhe“): conntrack/listeners erschöpfen.
L7 HTTP (S )/WebSocket/GraphQL flood, cache-busting, „slow“ requests: eat CPU/IO applications and cache layer.
Reflection/Amplification: Verwendung offener Reflektoren/Amplifier mit IP-Source-Substitution.
Teppichbombe: Verteilung des Datenverkehrs auf viele IPs/Präfixe, wodurch die Punktfilterung erschwert wird.

Grundlegende Netzwerkmaßnahmen (vor Angriffen)

1. Anti-Spoofing: uRPF/BCP38 an der Grenze; Drop ausgehende Pakete mit fremden Quellen.
2. ACL auf Edge/PE: Verbot unerwünschter Protokolle/Ports; separate Listen für das mgmt-Segment.
3. CoPP (Control Plane Policing): Policing zum Router (BGP, OSPF, SSH, SNMP).
4. Rate-Limits/Policing an den Ports: bps/PPS für „laute“ Klassen, Burst-Setups.
5. Lastverteilung: Anycast für öffentliche IP, Georasseve; CDN/WAAP für statisch und zwischengespeichert.
6. RPKI/ROA + strikter BGP-Import: Reduziert das Risiko von Hijack/Traffic-Umleitungen.
7. Oberflächenreduzierung: Minimieren Sie veröffentlichte Dienste, schließen Sie den „rohen“ Ursprung hinter dem Proxy.

Schnelle Reaktion beim Angriff: Vernetzte Hebel

RTBH (Remote Triggered Blackhole): BGP-Community für Route Null/32 (oder/128) Opfer.
BGP Flowspec: Schnelle Verbreitung von L3/L4-Regeln (src/dst/port/TCP flags) auf PE/edge.
Scrubbing-Center/Anti-DDoS-Anbieter: GRE/VRF-Tunnel oder direkter Upstream; Filterung, dann „sauberer“ Verkehr zu Ihnen.
Anycast-antiDDoS: Aufspaltung des Flusses durch Anwesenheit, Lokalisierung von Schäden.
CDN/Edge-Cache: schirmt Herkunft ab, gibt L7-Limits und „Challenge“ -Mechanismen.

Host- und L4-Schutz

SYN-Cookies/SYNPROXY: Halten Sie den Status nicht bis zur Bestätigung des Clients.

Linux: `sysctl net. ipv4. tcp_syncookies=1' oder „SYNPROXY“ auf dem Eingangsregler.

• Moderieren Sie' nf _ conntrack _ max' vernünftig, indem Sie hashsize erhöhen;
• Verkürzen Sie die Timeouts für „halboffene“ und inaktive Zustände.
• eBPF/XDP: Early Drop auf NIC (PPS-Schutz), Filterung nach Signaturen/Geschwindigkeit zum Kern.
• nftables/iptables: PPS-Limits, Verwerfen von „verdächtigen“ Flags, connlimit.
• UDP-Hardening: wenn der Dienst UDP - Drop an der Grenze nicht verwendet; wenn verwendet - Quellen/Ports einschränken.

nft table inet filter {
sets {
bad_ports { type inet_service; elements = { 19, 1900, 11211 } } # chargen/SSDP/memcached
}
chains {
input {
type filter hook input priority 0; policy drop;
ct state established,related accept ip saddr 127. 0. 0. 0/8 drop ip6 saddr::1/128 drop

limit new TCP tcp flags & (syn    ack) == syn limit rate 200/second burst 400 accept tcp flags & (syn    ack) == syn drop

deny bad UDP ports udp dport @ bad _ ports drop

ICMP rate-limit icmp type echo-request limit rate 50/second burst 100 accept icmpv6 type echo-request limit rate 50/second burst 100 accept
}
}
}

bash iptables -t raw -A PREROUTING -p tcp --syn -j CT --notrack iptables -A INPUT -p tcp -m tcp --syn -m hashlimit --hashlimit 100/second --hashlimit-burst 200 --hashlimit-mode srcip --hashlimit-name syns -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 iptables -A INPUT -m state --state INVALID -j DROP

L7-Schutz (kurz)

WAAP/WAF: Positives Modell auf kritischen Pfaden, Rate-Limits, Challenge/JS, Behavioral Scoring.
Caching/statisches Offload: Wir reduzieren Anfragen auf Origin; Schutz gegen Cache-Busting (Normalisierung/schwarze Parameterlisten).
GraphQL-Limiter: 'maxDepth', 'maxCost', Verbot der Introspektion in der Produktion.
BFF-Muster: dünne Client-Token, schwere Logik/Grenzen auf dem Server.
Idempotenz und Warteschlangen: Verhindern Sie lawinenartige Wiederholungen beim Abbau.

Telemetrie und Erkennung

Netzwerk-Streams: NetFlow/sFlow/IPFIX (pps, Top-Talker, Protokolle/Ports/ASN).
Passive L7-Sensoren: Balancer-/Proxy-Protokolle (nginx/envoy), p95/99-Metriken, Fehlerrate.
Basisschwellen: „unerwartetes PPS/CPU-Wachstum am Rand“, „SYN-RECV-Anstieg“, „UDP unerwidert“.
Signaturen/Verhalten: IP/ASN/JA3-Frequenzen, 4xx/5xx-Bursts, User-Agent-Anomalien.
Visualisierung: einzelne Dashboards L3/L4/L7; Verkehrskarte nach Geo/ASN; Zeit bis RTBH/Flowspec ausgelöst wird.

SLO/SLI und Alerting

• „MTTD von DDoS-Anomalien ≤ 60 Sekunden, MTTM (Aktivierung von RTBH/Flowspec) ≤ 3 Minuten“.
• "p95 Latenz über Edge ≤ 50 ms außerhalb von Angriffen; bei einem Angriff ≤ 200 ms unter Mitigation".
• „Der Anteil des verworfenen schädlichen Verkehrs ≥ 99 Prozent, während ≥ 98 Prozent legitim bleiben“.

• PPS/CPU/IRQ der Netzknoten> Schwelle;
• SYN-RECV/half-open > X;
• Wachstum von 5xx/latency bei öffentlichen Endpunkten;
• Prozentsatz der Challenge/Deny bei WAF> Schwelle (FP-Risiko).

Architektonische Verteidigungsmuster

1. Tiered Defense: Edge (ACL/CoPP) → Scrubbing/Anycast → L7-Proxy/WAAP → Anwendung.
2. Traffic Diversion: BGP-Community für den Umzug zum Scrabbing, GRE-Beckhole für die Tauchzeit.
3. Stateless Edge: maximal stateless-Filterung bis conntrack; stateful - näher an der Anwendung.
4. eBPF/XDP First: Frühe Drops (nach JA3/Ports/Geschwindigkeit) bis zum Kernel.
5. Golden Paths: Separate IPs/Domains für kritische APIs, um nicht das Ganze „abzureißen“.

Betriebsabläufe und Vorfälle

Runbooks: Wer und unter welchen Metriken RTBH/Flowspec/Scrabbing aktiviert, wie man Anycast/Pools schaltet.
Schwarze Listen und TTL: ein kurzfristiger Block, um nicht zu „übertreiben“; automatische Re-Test-Quellen.
Mitteilungen: Meldungsvorlagen an Anbieter/Partner/Anbieter; Kommunikationskanal außerhalb der angegriffenen Domäne.
Post-Incident: Bericht mit Zeitleiste (T0... Tn), „was hat funktioniert/nicht“, Aktualisierung des Testverzeichnisses.
Übung: regelmäßige Spieletage: RTBH-Trockenlauf, Verlust der Anycast-Region, Saturation des Links, „langsame“ Angriffe.

Linux/Balancer Tuning (Sampling)

bash
TCP sysctl -w net. ipv4. tcp_max_syn_backlog=4096 sysctl -w net. ipv4. tcp_syncookies=1 sysctl -w net. ipv4. tcp_fin_timeout=15 sysctl -w net. ipv4. tcp_tw_reuse=1

Conntrack (if enabled)
sysctl -w net. netfilter. nf_conntrack_max=1048576 sysctl -w net. netfilter. nf_conntrack_tcp_timeout_syn_recv=30 sysctl -w net. netfilter. nf_conntrack_udp_timeout=15

NIC/IRQ ethtool -G eth0 rx 4096 tx 4096

Häufige Fehler

Halten Sie den gesamten Datenverkehr über die stateful-Firewall an der Kante → Erschöpfung conntrack. Machen Sie stateless, wo Sie können.
Später RTBH/Flowspec → Kanal bereits „auf Null“. Automatisieren Sie Schwellen und Inklusion.
Eine IP/eine Front für „nur“ → keine Isolation blast radius. Trennen Sie Domains/IPs und Kontingente.
Zero Cache → Jeder L7-Aufruf schlägt den Ursprung; Aktivieren Sie Caching und Parameternormalisierung.
Blind Country Lock/ASN ohne Legitanalyse - schneidet die Konversion; Verwenden Sie nuancierte Regeln/Herausforderungen.
Zu aggressive Limits → massive FP in der Spitze des Geschäfts.

Roadmap für die Implementierung

1. Oberflächenbewertung: IP/Präfix/Port/Protokoll Inventar, kritische Pfadkarte.
2. Netzhygiene: Anti-Spoofing, ACL, CoPP, RPKI/ROA, Verzicht auf überflüssige UDP-Dienste.
3. Verkehrsumleitung: Vertrag mit dem Scrabbing-Anbieter, Anycast/CDN, BGP communities.
4. Edge-Tuning: stateless-Filterung, SYNPROXY/eBPF, vernünftige Conntrack-Timeouts.
5. L7/WAAP: positives Modell, Limits/Herausforderungen, Cache.
6. Beobachtbarkeit: NetFlow/sFlow, L3/L4/L7 Dashboards, Alerts, SLO.
7. Automatisierung: RTBH/Flowspec-Tasten, IaC für Regeln, kanarische Config-Layouts.
8. Übungen und RCA: regelmäßige Tests, Aktualisierung der Playbooks.

Features für iGaming/Fintech

Peak Events (Turniere, Promotions, Matches): Capacity/Limits planen, Caches aufwärmen, Pre-Warming CDNs.
Zahlungsintegrationen: dedizierte IPs/Domains, priorisierte Kanäle über Anti-DDoS-Anbieter, mTLS zu PSP, strenge Grenzen für kritische Endpunkte.
Anti-Betrug/Bot-Kontrolle: Verhaltens-Scoring und menschliche Herausforderungen auf Registrierung/Login/Promo-Codes.
UX und Conversion: Verwenden Sie bei aggressiver Verteidigung Grace-Listen für VIP/Partner, Soft Degradation (Cache/Readonly).
Rechtliche Anforderungen: Transparenz der Protokolle, Speicherung der Telemetrie, Debugging der Auswirkungen der Maßnahmen auf Time-to-Wallet und Umsatzmetriken.

Beispiele: Flowspec und RTBH (konzeptionell)

route 203. 0. 113. 10/32 blackhole set community 65535:666 announce to upstream

match destination 203. 0. 113. 0/24 protocol = udp destination-port {19,1900}
then rate-limit 1000

FAQ

WAF löst DDoS?
Teilweise für L7. Gegen L3/L4 und volumetric sind Scrabbing-/Anycast-/Netzwerkmaßnahmen erforderlich.

Sind SYN-Cookies ausreichend?
Dies ist ein grundlegender Schutz gegen SYN-Flut, aber ohne Netzwerklimits und Scrabbing kann der Kanal immer noch getroffen werden.

Muss ich ICMP deaktivieren?
Nein. Bessere Rate-Limit und nur gefährliche Typen, ICMP ist nützlich für Diagnose/PMTU.

Wird ein GRE-Tunnel mit Scrabbing keine Latenz hinzufügen?
Ja, aber in der Regel zulässig. Kompensieren Sie mit dem Cache und der genauen Route zum nächsten PoP.

Summe

Zuverlässiger DDoS-Schutz ist eine mehrstufige Architektur: Netzwerkhygiene (Anti-Spoofing/ACL/CoPP), schnelle Verkehrsumleitung (RTBH/Flowspec/Scrubbing/Anycast), Host- und L7-Mechanismen (SYNPROXY, eBPF/XDP, WAAP), plus Telemetrie, SLO und gut funktionierende Playbooks. Dieser Ansatz minimiert Ausfallzeiten, hält Kanäle am Leben und hält Geschäftsmetriken auch unter dem Druck verteilter Angriffe.