- IT4OWL
- Methode
Methode: so stabilisieren wir eine angegriffene Website
Wir stabilisieren eine angegriffene Website in sieben Schritten, von der vordersten Schicht bis zur Beweissicherung. Zuerst klären wir, ob ein Mengenproblem oder ein teurer Pfad in der Anwendung vorliegt, denn davon hängt ab, welche Maßnahme hilft.
Menge oder teurer Pfad?
Bei einem Mengenproblem schicken viele Anfragen so viele Daten, dass die Leitung oder der Server voll ist. Dagegen hilft ein großes Netz, wie Cloudflare es hat.
Bei einem teuren Pfad ist die Menge klein. Jede Anfrage löst aber im Server viel Arbeit aus. Link11 beschreibt das selbst: Solche Angriffe können auf die „Überlastung von CPU und Datenbanken“ zielen, etwa über Login-Seiten oder „manipulierte Suchanfragen auf dynamischen Webseiten“.1
Ein Beispiel aus unserem dokumentierten Fall: Die stärkste Stunde brachte im Schnitt rund 21 Anfragen pro Sekunde, und die Datenmenge lag nie über 3 Mbit/s. Trotzdem stand die Plattform still, weil jede Anfrage eine neue Filterkombination war und an jedem Zwischenspeicher vorbei bis in die Datenbank lief. Mehr dazu im Fall.
Wir erkennen den Unterschied an drei Messwerten: Bandbreite, Anfragen pro Sekunde und Antwortzeit pro Seite am Server. Sind Bandbreite und Anfragen niedrig, aber der Server ist voll, suchen wir den Pfad.
Die sieben Schritte
- Edge und WAF
Wir sehen uns an, was vor Ihrem Server steht. Bei Cloudflare sind das die DDoS-Regeln, die Web Application Firewall (WAF) und die Ratenbegrenzung. Cloudflares Dokumentation sagt selbst, dass die HTTP-DDoS-Regeln einen Angriff verfehlen können, wenn er „not sufficiently high“ ist oder keine Regel passt.2 Wir setzen daher eigene Regeln auf konkrete Pfade. Den Modus „Under Attack“ nutzen wir mit Vorsicht; er kann zum Beispiel API-Verkehr stören.3
- Origin-Profil
Der Origin ist Ihr eigener Server hinter Cloudflare. Wir prüfen, ob er direkt erreichbar ist. Cloudflare rät, Verkehr zu blockieren, der nicht von Cloudflare-Adressen kommt.4 Dann messen wir: Auslastung, Speicher, offene Verbindungen, Fehler und Neustarts.
- Teure Routen
Aus den Protokollen ermitteln wir, welche Pfade am meisten Zeit und Datenbankarbeit kosten, und welche davon von außen frei aufrufbar sind: Suche, Filter, Login, Warenkorb. Wir sagen nicht vorher, welche es ist, wir messen. Eine Seite ist nicht schon deshalb teuer, weil sie dynamisch ist.
- Cache und Notbetrieb
Was jeder sehen darf, kommt aus dem Zwischenspeicher oder als fertige statische Seite. Für Angriffsformen, die wir erkennen, gibt es einen Notbetrieb: eine einfache Antwort ohne Anwendung und Datenbank. Wir schließen Login, Konto, Warenkorb und Kasse vom Zwischenspeichern aus.5 Wer alles zwischenspeichert, riskiert, dass Besucher Inhalte anderer sehen.6
- Datenbankschutz
Wir begrenzen, wie viel Arbeit eine einzelne Anfrage oder Sitzung der Datenbank aufladen darf, und wie viele Anfragen gleichzeitig warten. Warten unbegrenzt viele, wächst der Speicher, bis der Prozess abbricht. In unserem Fall ist das der wahrscheinlichste Weg zum Absturz; bewiesen ist er nicht.
- Monitoring
Pro Website wacht ein AI Sentry. Er beobachtet Fehlerraten, Antwortzeiten und Neustarts, liest nur und ändert keine Regeln. Im Vorfall arbeiten vier Rollen-Agenten parallel (Edge, Origin, Pfad, Protokoll). Sie dürfen nur lesen, das erzwingt der Token, den Sie ausstellen. Sie schlagen Maßnahmen vor; Magnus Ohle gibt sie frei, die Änderung steht mit Vorher und Nachher im Verlauf. Erkennt die Regel nur die Hälfte, sehen wir den Rest an den Messwerten am Server.
- Beweissicherung
Wir halten Zeitverlauf, Zahlen und Rohdaten fest, bevor sie aus der Aufbewahrungsfrist laufen. Das Ergebnis ist das Evidence Pack.
Warum Erkennen allein nicht reicht
Erkennung versagt manchmal. Im dokumentierten Fall fing die Regel am Edge etwa die Hälfte der Anfragen ab. Die andere Hälfte änderte ihre Merkmale und kam durch. Wir bauen deshalb so, dass die falsch durchgelassene Anfrage kaum noch etwas kostet: Der Server beantwortet sie mit einer fertigen Seite, ohne Anwendung und Datenbank.
Die drei Ebenen
Edge
Menge und bekannte Muster
Cloudflare als vorderste Schicht: DDoS-Regeln, WAF, Ratenbegrenzung.
Origin
Arbeit vor der Anwendung trennen
Ihr Server. Hier trennt man Anfragen, die Arbeit kosten, von solchen, die es nicht tun, bevor die Anwendung beteiligt ist.
App
Was eine Anfrage kostet
Hier entscheidet sich der Preis jeder Anfrage: Budgets, Sitzungen, Zwischenspeicher und Grenzen für wartende Anfragen.
Was bedeutet das für Sie?
Sie müssen nicht wissen, welcher Schritt gerade läuft. Wir dokumentieren, was wir ändern und was es bewirkt hat. Der Preis für den Notfall steht vor dem Start fest: 499 € einmalig, bis 2 Stunden aktive Arbeit, danach 149 € pro Stunde.
Quellen
- Link11: DDoS Protection Buyer's Guide (DE), S. 8. https://www.link11.com/wp-content/uploads/2025/11/link11_ddos_protection_buyers_guide_de.pdf, geprüft am 11.11.2026
- Cloudflare: DDoS-Regeln, Fehlklassifizierung (False Negatives). https://developers.cloudflare.com/ddos-protection/managed-rulesets/http/http-overrides/override-examples/, geprüft am 11.11.2026
- Cloudflare: Security Level und Under Attack mode. https://developers.cloudflare.com/waf/tools/security-level/, geprüft am 11.11.2026
- Cloudflare: Protect your origin server. https://developers.cloudflare.com/fundamentals/security/protect-your-origin-server/, geprüft am 11.11.2026
- Cloudflare: Dynamic content and login issues. https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/, geprüft am 11.11.2026
- Cloudflare: Cache Everything. https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/, geprüft am 11.11.2026