DDoS (Distributed Denial of Service)

Als Opfer: Du merkst, dass deine Webseite down ist. Die Logs zeigen Millionen Requests pro Sekunde. Du kannst es alleine kaum stoppen (deine Internetleitung ist physikalisch voll). Du brauchst einen großen Bruder: Cloudflare oder Akamai. Die haben riesige "Waschstraßen" (Scrubbing Center). Sie nehmen den Traffic an, filtern den Müll raus, und leiten nur die echten Kunden zu dir weiter.

1. Layer 3/4 Attacken (Volumetrisch)

Ziel: Leitung verstopfen.

• UDP Flood: Müll-Pakete.
• SYN Flood: Hacker sendet tausende TCP-Start-Anfragen, antwortet aber nie. Der Server wartet auf jede Antwort und verbraucht RAM (Connection Table voll).
• Amplification (DNS/NTP): Hacker sendet kleine Anfrage an offenen DNS-Server ("Gib mir alles"), aber fälscht die Absender-Adresse (Spoofing) auf deine IP. Der DNS-Server sendet die riesige Antwort an dich. Faktor 1:50.

2. Layer 7 Attacken (Applikation)

Ziel: CPU/RAM verbrauchen. Viel schlauer. Wenig Bandbreite nötig.

• HTTP Flood: Bots rufen immer die CPU-intensivste Seite auf (/search?q=a oder /pdf-generate).
• Slowloris: Der Angreifer sendet einen HTTP-Request extrem langsam. "G...E...T... /...". Er hält die Verbindung minutenlang offen. Der Webserver wartet höflich. Mit 100 Verbindungen belegt der Hacker alle Slots des Servers.

3. Botnetze (Mirai)

Woher kommen die 100.000 PCs? Oft IoT-Geräte. Webcams, Toaster, Router mit Standard-Passwort ("admin/admin"). Das Mirai-Botnet scannte das Internet nach offenen Telnet-Ports und kaperte Millionen Geräte für DDoS-Angriffe.

1. BGP Anycast und das Auskontern von Volumetrie

Wenn ein russisches Botnet mit 2 Terabit pro Sekunde (Tbps) auf eine Frankfurter IP eintrifft, nutzt Firewalls am Backend nichts mehr. Der Router des Gebäudes verglüht. Die einzige Verteidigung ist BGP Anycast (Die Magie hinter Cloudflare). Eine IP (z.B. 1.1.1.1) wird dabei nicht an einen Server gebunden. Cloudflare verkündet via BGP im globalen Internet: "Jedes von unseren 200 Rechenzentren weltweit bearbeitet 1.1.1.1!". Startet das Botnet, routet der globale Backbone den Angriff nicht an einen Ort. Die russischen Bots landen im russischen Cloudflare RZ. Die US Bots landen im US RZ. Der Angriff wird durch die Netzwerk-Geo-Mathematik völlig zersplittert ("Anycasted Sinkholing"). Jedes lokales RZ hat plötzlich statt 2000 Gbps nur läppische 10 Gbps zu filtern.

2. Web Application Firewall (WAF) bei Layer-7 Attacks

Ein fieser HTTP Slow-Read (oder L7 Flood mit gefälschten Headern) verbraucht extrem wenig Netzwerk-Leistung. Hier scheitert Anycast, man taucht ein in das Header-Profiling in Echtzeit (via WAF). Die WAF zerbricht den Header (oft in Nginx mit lua-Erweiterungen evaluiert): "Senden diese 100 HTTP-Requests immer den gleichen manipulierten User-Agent ('Java/1.8.0')? Besuchen sie Seiten-Pfade, ohne das CSS/JS hinterher zuladen (Accept-Language manipuliert)?". Erkennt die WAF eine winzige Abweichung zur Non-Bot-Normal-Norm, verhängt sie im Sekundentakt auf tausende IP-Ranges CAPTCHA-Challenges oder wirft HTTP 403 Forbidden (DROP im iptables-Level), bevor die CPU des Zielservers index.php auch nur starten kann.

3. UDP Amplification (Memcached Faktor 51,000x)

Das furchtbarste Beispiel der Geschichte war 2018 der Angriff auf GitHub (1.3 Tbps). Er basierte auf Memcached Amplification. Memcached ist ein simpler Open-Source Cache, oft fehlerhaft ungeschützt offen auf Port 11211 betrieben, das UDP Nutzt. UDP ist ("Fire and Forget") state-less und erfordert keinen 3-Way-Handshake. Der Angreifer fälscht seine Absender-IP in die von GitHub (Spoofing). Er schickte an 10.000 fremde, ungeschützte Memcached Server weltweit einen winzigen 15-Byte-Request: "Schick mir mal alle deine Cachedaten stats." Memcached reagiert auf UDP blind. Es sendet ein gigantisches Response-Paket von 750 Kilobyte. Faktor 51.000x! Der Angreifer investiert 1 MB Upload am Heim-Laptop, und die nichtsahnenden Memcached Server schmeißen 51 GB an Daten in der gleichen Sekunde blind auf GitHubs Tür.