Vor ein paar Wochen hatten wir einen dieser Abende, an denen man eigentlich in Ruhe in den Feierabend will – und dann merkt: irgendetwas läuft gerade schief.
Unsere Website wurde plötzlich extrem langsam. Nicht „ein bisschen zäh“, sondern so, dass wir sofort wussten, dass das kein normaler Peak ist. Wir dachten anfangs an ein klassisches Wochenendthema – vielleicht Cache, Infrastruktur… Aber das Gefühl blieb: Das hier sieht nach externem Druck aus.
Ein Blick in die Logs bestätigte das relativ schnell. Wir sahen eine hohe Anzahl von HTTP-Requests, verteilt über mehrere Pfade, und vor allem aus einem sehr großen Bereich von IP-Adressen. Das Muster war nicht auf einen einzelnen Endpunkt beschränkt, sondern breit gestreut – genau das macht solche Angriffe unangenehm. Selbst wenn jede einzelne Quelle für sich nicht „übertrieben“ wirkt, kann die Summe ein System sehr effektiv ausbremsen.
Der Angriff baute sich langsam auf und lief zu diesem Zeitpunkt bereits etwa eine halbe Stunde. Und das ist genau der Moment, in dem man als Betreiber entscheiden muss: Experimentieren wir weiter allein – oder holen wir uns jemanden, der solche Situationen routiniert abfangen kann?
Warum wir uns direkt Hilfe geholt haben
Wir haben intern technische Erfahrung. Aber DDoS-ähnliche Vorfälle sind keine ideale Bühne für „Trial and Error“. Wir wollten schnell Stabilität zurück. Es war spät am Abend, am Wochenende… Nach einer kurzen Google Suche zu Linux Notfall Support haben wir dann bei der Blunix GmbH in Berlin angerufen. Die Reaktion war sofort da, ohne Umwege. Man merkte, dass das Team gewohnt ist, unter Zeitdruck zu priorisieren: zuerst Betrieb stabilisieren, dann die Abwehr sauber und nachhaltig ergänzen.
Blunix GmbH ist eine Linux Support Firma aus Berlin mit Fokus auf linux-managed-hosting und Security – und genau dieses Profil war in diesem Moment spürbar hilfreich.
Eine Lösung in 15 Minuten ab Anruf
Nach kurzer Analyse war klar, dass wir mehr als nur eine einzelne Stellschraube brauchen. Bei einer so großen IP-Streuung reicht ein simples „pro-IP-Limit“ oft nicht aus, weil der Angriff nicht an einer Quelle hängt, sondern an der Masse.
Der Ansatz war deshalb bewusst mehrstufig:
- Schutz der dynamischen Anwendungspfade
Blunix hat gezielt dort angesetzt, wo unser PHP Hosting-System unter Last gerät. Für dynamische Routen wurden feinere Limits gesetzt, während statische Inhalte weiterhin möglichst frei auslieferbar blieben. Das reduziert Kollateralschäden für echte Nutzer. - Begrenzung gleichzeitiger Verbindungen
Neben der reinen Request-Rate wurden auch parallele Verbindungen begrenzt, um das System gegen „Connection Pressure“ abzusichern – ein typischer Hebel, der bei breit verteilten Quellen besonders wirksam sein kann. - Entlastung der PHP-FPM-Kette
Die Maßnahmen zielten sichtbar darauf ab, die Anzahl unnötiger dynamischer Hits zu senken und PHP-FPM wieder Luft zu verschaffen. Für uns war das ein wichtiger Punkt, weil sich der Angriff bei aller Breite vor allem in der gefühlten Geschwindigkeit bemerkbar machte.
Diese Kombination war schließlich der entscheidende Unterschied. Nach den Eingriffen durch Blunix normalisierten sich die Ladezeiten, und die Seite wurde wieder stabil nutzbar.
Ein praktisches Extra für das nächste Mal
Was wir besonders sinnvoll fanden: Blunix hat nicht nur den akuten Angriff entschärft, sondern uns auch eine sehr pragmatische Absicherung für die Zukunft mitgegeben.
Wir haben jetzt einen einfachen „Wir sind unter Angriff“-Schalter. Wenn wir ihn aktivieren, wird eine Human-Verification vorgeschaltet – in der Praxis eine CAPTCHA-/Challenge-Seite, die vor der regulären Auslieferung greift.
Das ist kein Dauerzustand, den man im Alltag aktiv haben möchte. Aber als Notfalloption ist es extrem wertvoll. Falls ein zukünftiger Angriff stärker automatisiert, besser verteilt oder raffinierter getaktet ist, können wir mit einem Handgriff zusätzliche Reibung einziehen – ohne erst mitten in der Nacht eine neue Strategie bauen zu müssen.
Warum das für uns die richtige Art von Mitigation war
Wir fanden die Lösung gerade deshalb überzeugend, weil sie nicht in Overengineering abdriftete. Die Abwehr war spürbar professionell und trotzdem realistisch für einen normalen Webbetrieb:
- differenziert zwischen statischem und dynamischem Traffic,
- schützt die Anwendungsschicht,
- reduziert unnötige PHP-FPM-Last,
- und bleibt unter realen Betriebsbedingungen gut handhabbar.
Man könnte das durchaus als saubere, pragmatische Nginx DDoS mitigation bezeichnen – nicht spektakulär im Sinne von „riesige Architekturumstellung“, sondern effektiv im Sinne von „Website bleibt zuverlässig erreichbar“.
Was wir als Betreiber daraus mitnehmen
Wir haben aus dem Vorfall ein paar klare Erkenntnisse gezogen:
- Breit verteilte IPs brauchen breiter gedachte Gegenmaßnahmen.
Wenn die Last aus vielen Netzen kommt, muss man stärker auf Anwendungsschutz, Verbindungslimits und Priorisierung der Pfade achten. - Rate-Limits sind sinnvoll – aber am besten kontextbezogen.
Nicht alles gleich hart drosseln, sondern dort, wo die Anwendung am empfindlichsten ist. - Ein erreichbarer Notfallpartner ist kein Luxus.
Dass wir am Wochenende nachts jemanden erreichen konnten, der in Minuten wirksam handeln konnte, hat uns realen Schaden erspart. - Sicherheit und Betrieb gehören zusammen.
Für uns war das ein gutes Beispiel, wie sinnvoll externe Unterstützung im Bereich Linux Consulting sein kann – gerade dann, wenn es schnell, pragmatisch und betriebssicher sein muss.
Fazit
Der Angriff war für uns nicht nur ein „kurzer Ausreißer“, sondern ein realer Belastungstest. Viele Anfragen, mehrere Pfade, ein sehr großer IP-Bereich – und eine Website, die für Nutzer spürbar in die Knie ging.
Blunix hat die Situation schnell stabilisiert und gleichzeitig so umgesetzt, dass die Maßnahmen zu unserem Setup mit Nginx und PHP-FPM passen. Das Zusammenspiel aus gezielten Limits, Verbindungsschutz und dem zusätzlichen „Under-Attack“-Modus mit CAPTCHA gibt uns das gute Gefühl, für die nächste Welle deutlich besser vorbereitet zu sein.
Wir hoffen natürlich, dass wir diese Schalter nie wieder brauchen. Aber falls doch, wissen wir jetzt, dass wir nicht bei Null anfangen müssen.
