Wenn Ihre Seite „nicht viel Traffic zeigt, aber einfach nicht lädt“ — und Ihr Firewall-Protokoll voll mit völlig normal aussehenden HTTP-Anfragen ist — stehen Sie wahrscheinlich vor einem CC-Angriff.
CC-Angriffe (Challenge Collapsar) sind das täuschendste Mitglied der DDoS-Familie. Sie brauchen keine Tbps an Bandbreite. Ein paar hundert infizierte Rechner und ein paar tausend Verbindungen genügen, um eine Seite ohne Anwendungsebenen-Schutz lahmzulegen — und weil nichts auffällig wirkt, verschwendet Ihr Bereitschaftsingenieur vielleicht eine Stunde damit, „die App neu zu starten“, bevor jemand das eigentliche Problem benennt.
Wie ein CC-Angriff funktioniert
Der Name stammt von einem frühen Angriffswerkzeug namens „Challenge Collapsar“. Das Kernprinzip ist brutal einfach:
Fortlaufend die Seiten anfordern, die am meisten Serverressourcen verbrauchen.
Beispiele:
- Such-Endpunkte, die eine langsame
LIKE '%term%'-Abfrage über Millionen von Zeilen ausführen - Berichtsseiten, die Daten mit aufwändigen Joins aggregieren
- Download-Endpunkte, die große Dateien von der Festplatte streamen
- Absende-Endpunkte, die bei jedem Treffer in die Datenbank schreiben
Angreifer nutzen große Pools von Proxy-IPs, um diese Endpunkte gleichzeitig und wiederholt anzusteuern. Jede einzelne Anfrage sieht legitimiert aus — eine gültige Sitzung, ein echter Browser-User-Agent — doch Ihre CPU, der Datenbankverbindungspool und die Backend-Dienste sind innerhalb von Minuten erschöpft. Betrachten Sie einen Such-Endpunkt, der unter Last 400 ms benötigt: Ein anhaltender 200 Anfragen pro Sekunde vom Botnetz belegt den Verbindungspool Ihrer Datenbank, und echte Nutzer erleben Timeouts schon an der Login-Seite, obwohl die gesamte Bandbreite nie 5 MBit/s übersteigt.
Die zentrale Erkenntnis: Ein CC-Angriff zielt auf Ressourcenverbrauch, nicht auf Bandbreite. Deshalb hilft mehr Bandbreite oder eine High-Defense-IP dagegen fast nichts — Ihnen geht nicht die Leitung aus, sondern die Zahl der Anfragen, die Ihre Datenbank beantworten kann.
CC-Angriffe vs. herkömmlicher DDoS
| Dimension | Volumetrischer DDoS | CC-Angriff |
|---|---|---|
| Ebene | L3 / L4 (Netzwerk, Transport) | L7 (Anwendung) |
| Traffic-Umfang | Hunderte GBit/s bis TBit/s | Manchmal nur wenige MBit/s |
| Anfrage-Signatur | Offensichtlich fehlerhafte Pakete | Fast identisch mit echten Nutzern |
| Zielressource | Bandbreite, Verbindungstabelle | CPU, Speicher, Datenbank, Backend |
| Abwehrmethode | Bandbreiten-Reinigung, Ratenbegrenzung | Verhaltensanalyse, Bot-Challenges, präzise Drosselung |
| Erkennbarkeit | Relativ einfach | Extrem schwer |
In einem Satz: Ein volumetrischer DDoS flutet Ihr Haus; ein CC-Angriff schickt Spione hinein, die Ihr Wasser und Ihren Strom aufbrauchen.
Warum CC-Angriffe so schwer zu stoppen sind
Drei Gründe, von denen jeder eine naive Abwehr besiegt:
- Der Traffic ist zu klein, um Alarme auszulösen. Die meisten Überwachungssysteme setzen Schwellenwerte nach Bandbreite. Ein CC-Angriff erreicht Ihren normalen Spitzenwert möglicherweise gar nicht, sodass das „Bandbreite OK“-Dashboard ein falsches Sicherheitsgefühl erzeugt, während die Datenbank schmilzt.
- Die Anfragen sind legitimiert. Angreifer fordern Seiten an, die es wirklich gibt, mit gültigen Parametern und wohlgeformten Headern. Es gibt kein fehlerhaftes Paket, das eine Firewall abweisen könnte.
- Quellen sind verteilt und getarnt. Angreifer mieten echte Residential-Proxy-Pools und imitieren sogar Browser-Cookies und TLS-Fingerprints — einfache IP-Blocklisten versagen völlig, weil die „bösen“ IPs dieselben sind, die Ihre echten Kunden nutzen.
Eine Vier-Schichten-Verteidigungsstrategie
Schicht 1: Ressourcen-Isolation
Stellen Sie zunächst sicher, dass der Angriff nichts Kritisches erreichen kann:
- Trennen Sie ressourcenintensive Endpunkte (Suche, Berichte, Exporte) von Kern-Geschäfts-Endpunkten, idealerweise auf verschiedene Dienstpools, sodass ein Suchsturm die Kasse nicht ausbremsen kann.
- Fügen Sie Caching und vorberechnete Ergebnisse hinzu, damit identische Abfragen eine gecachte Antwort liefern, ohne die Datenbank zu berühren.
- Setzen Sie IP-Concurrency-Grenzen und Endpunkt-Timeouts, um die Kosten für den Angreifer zu erhöhen und den Schaden zu begrenzen.
Schicht 2: Präzise Drosselung und Raten-Baselines
Wenden Sie keine einheitlichen Ratenbegrenzungen an — das beeinträchtigt bei einem Sale nur echte Nutzer. Der richtige Ansatz:
- Legen Sie eine normale Traffic-Baseline pro Endpunkt fest (QPS, Antwortzeit, Anfrage-Signatur-Mix).
- Automatische Degradierung, wenn der Traffic von der Baseline abweicht — Warteschlange, Cache-Auslieferung oder Verifizierung — statt harter Blockierung.
- Wenden Sie strengere Richtlinien speziell auf Login- und Absende-Endpunkte an, wo ein paar hundert Anfragen pro Sekunde tatsächlich schaden.
Schicht 3: Bot-Challenges
Für hochwertige Endpunkte, die geschützt werden müssen, fügen Sie Verifizierungen hinzu, die Botnetze nicht günstig bestehen können:
- JS-Challenges (Clients müssen eine Berechnung ausführen — Residential-Proxy-Pools und Headless-Skripte können sie nur schwer im großen Stil bestehen, was die Kosten pro Anfrage für den Angreifer erhöht).
- Verhaltens-Fingerprinting (TLS-Fingerprint, Anfrage-Rhythmus, Fehlen der menschlichen Mikropausen, die ein echter Browser zeigt).
- CAPTCHA wo nötig, und nur wo nötig.
Der Kompromiss: Verifizierung beeinträchtigt die Nutzererfahrung. Aktivieren Sie sie während Angriffen oder nur auf risikoreichen Endpunkten, nicht seitenweit — sonst besteuern Sie Ihre eigenen Kunden für eine Bedrohung, die gar nicht da ist.
Schicht 4: Professionelle Reinigung mit Experten-Eingriff
CC-Angriffe erfordern in der Regel Echtzeit-Anpassung der Richtlinien, um unterdrückt zu werden — Angreifer beobachten Ihre Regeln und passen sich innerhalb von Minuten an, wechseln User-Agents oder verschieben sich von Suche zu Export-Endpunkten. Ein statisches Regelwerk veraltet schnell. Genau hier verdient ein professioneller Schutzdienst sein Geld.
Die Tiefenreinigungs-Ebene von AwayDDoS modelliert kontinuierlich das Anwendungsebenen-Verhalten, und unsere 7×24-Sicherheitsexperten greifen aktiv ein, um Richtlinien während eines Angriffs anzupassen, statt auf Ihr Ticket zu warten. Details unter Schutzlösungen.
Ein häufiges Missverständnis
„Ich habe ein CDN davor, also bin ich sicher vor CC.“ — Ein CDN mildert einen Teil davon, aber CDN cached nur statische Assets; dynamische Anfragen (die Suche, Logins und API-Aufrufe, die CC-Angriffe tatsächlich anvisieren) gehen direkt an Ihre Origin. Was Sie wirklich brauchen, ist tiefe Anwendungsebenen-Verhaltensanalyse, nicht nur Edge-Caching.
Kernaussagen
Was CC-Angriffe gefährlich macht, ist, dass sie extrem günstig und extrem schwer zu identifizieren sind — ein Residential-Proxy-Abo kostet wenige Dollar am Tag und kann eine ungeschützte Datenbank begraben. Die Abwehr besteht nicht darin, mehr Bandbreite zu kaufen, sondern Tiefe aufzubauen: Ressourcen-Isolation, präzise Drosselung, Bot-Challenges und Experten-Eingriff, die zusammenwirken.
Wenn Ihre Seite das Muster „wenig Traffic, aber dauerhaft unerreichbar“ zeigt, kontaktieren Sie uns jetzt für eine kostenlose Angriffssignatur-Analyse. Neu im Thema? Beginnen Sie mit Was ist ein DDoS-Angriff? Ein vollständiger Einsteigerleitfaden.