Du hast Rate Limiting aktiviert, blockierst IPs, die zu viele Anfragen senden, und trotzdem geht dein Server in die Knie, sobald ein echter Angriff kommt. Das liegt nicht daran, dass Rate Limiting nicht funktioniert — es löst nur ein anderes Problem als das, das dich gerade angreift.
Was IP-basiertes Rate Limiting gut kann
Anfragen pro IP zu zählen und diejenige zu blockieren, die einen Schwellenwert überschreitet, funktioniert hervorragend gegen einen einzelnen Angreifer: jemanden mit einem Brute-Force-Skript gegen dein Login oder einen aggressiven Scraper von einer einzigen Maschine. In diesem Fall löst das Sperren dieser einen IP das Problem sofort.
Warum es gegen einen echten DDoS versagt
Ein Botnetz ist keine IP, sondern Tausende
Ein verteilter Denial-of-Service-Angriff (DDoS) sendet seinen Traffic nicht von einer einzigen Quelle — er verteilt ihn auf Hunderte oder Tausende verschiedener Maschinen, jede mit relativ wenigen Anfragen. Wenn deine Regel lautet “nach 50 Anfragen pro Minute von derselben IP blockieren”, erreicht ein gut verteiltes Botnetz diesen Schwellenwert bei keiner einzelnen IP jemals — obwohl die Gesamtsumme deinen Server lahmlegt.
Jede neue IP startet ihren Zähler bei null
Selbst wenn du jede IP sofort blockierst, sobald sie die Grenze überschreitet, fügt der Angreifer einfach immer neue hinzu. IP-basiertes Rate Limiting ist dafür gebaut, einen einzelnen Missbraucher zu stoppen — nicht zu erkennen, dass der gesamte Traffic der Website durch einen koordinierten Angriff explodiert ist.
Was ein speziell dafür gebauter Modus anders macht
Globalen Traffic zählen, nicht nach Quelle
Statt jede IP einzeln zu überwachen, misst dieser Ansatz, wie viele Anfragen die Website insgesamt in einem kurzen Zeitfenster erhält. Übersteigt diese Gesamtzahl das Normale für deine Website, wird eine Reaktion ausgelöst — ohne vorher herausfinden zu müssen, welche der Tausenden IPs “die Schuldige” ist, weil es keine einzelne gibt.
Eine leichte Herausforderung statt eines abstürzenden Servers
Wenn das globale Volumen explodiert, wird statt jeder einzelnen Anfrage, WordPress vollständig auszuführen (mit Datenbankabfrage, Plugin-Laden und allem), eine kleine Herausforderung ausgespielt — eine, die ein normaler Browser sofort löst, die aber den Großteil des automatisierten Traffics stoppt, bevor er echte Serverressourcen verbraucht.
Was diese Art von Schutz nicht ersetzt
Man sollte ehrlich über die Grenzen sein: Diese Schicht ist dafür gebaut, die normalen Seiten der Website vor einem massiven Traffic-Anstieg zu schützen — nicht dafür, Formulare, Zahlungen oder die API allein abzusichern. Diese Bereiche brauchen ihren eigenen, dedizierten Schutz, gerade weil man einen echten Kauf nicht mitten im Vorgang mit einer Herausforderung unterbrechen möchte.
Häufig gestellte Fragen
Ist IP-basiertes Rate Limiting dann überhaupt noch nützlich?
Ja, es bleibt wertvoll gegen Brute-Force-Angriffe, aggressives Scraping oder Missbrauch von einer einzelnen Quelle — es ist nur nicht das richtige Werkzeug gegen einen auf Tausende IPs verteilten Angriff.
Brauche ich beides gleichzeitig?
Sie ergänzen sich: IP-basiertes Rate Limiting deckt individuellen Missbrauch ab, und eine globale Traffic-Schicht deckt das Szenario ab, in dem keine einzelne IP auffällt, aber die Gesamtsumme der Website schon.
Kann ein DDoS-Angriff jedes WordPress ohne dedizierten Schutz lahmlegen?
Ja — ohne eine Schicht, die das Gesamtvolumen misst, verarbeitet WordPress jede Anfrage einzeln (inklusive Datenbank), und ein ausreichend hohes Volumen erschöpft die Serverressourcen, selbst wenn jede einzelne Anfrage für sich harmlos aussieht.