Einen DDoS-Angriff auf Ihrem VPS überstehen

Es gibt zwei Momente, in denen man lernt, wie DDoS-Abwehr tatsächlich funktioniert. Der erste ist ruhig, beim Kauf, wenn man eine Feature-Liste liest, auf der „DDoS-Schutz inklusive“ steht, und stillschweigend annimmt, dieser Satz decke alles ab. Der zweite ist um drei Uhr morgens, wenn die Seite nicht mehr erreichbar ist, die Graphen auf eine Weise falsch aussehen, die keinen Sinn ergibt, und dieser inkludierte Schutz — korrekterweise und wie vorgesehen — überhaupt nichts tut.

Beide Momente betreffen dasselbe Produkt und dieselbe Wahrheit: Ein Hosting-Anbieter filtert die Angriffe, die als rohes Datenvolumen ankommen, weil er die Leitung besitzt, über die diese Pakete laufen, und Sie nicht. Er kann die Angriffe nicht filtern, die als gewöhnlich aussehende Anfragen ankommen, weil sie aus Sicht des Netzwerks gewöhnlich aussehende Anfragen sind. Diese Grenze — zwischen der Flut, die Ihr Host abfängt, und der Flut, die Sie selbst überstehen müssen — ist das eigentliche Thema. Alles Folgende dreht sich darum, herauszufinden, auf welcher Seite dieser Grenze Sie stehen, und was auf jeder der beiden zu tun ist.

Zwei verschiedene Angriffe, die sich einen Namen teilen

„DDoS“ ist ein einziges Wort für zwei Probleme, die außer dem Ergebnis fast nichts gemeinsam haben. Sie werden an unterschiedlichen Stellen, von unterschiedlichen Personen, mit unterschiedlichen Werkzeugen gestoppt — und diese Verwechslung ist der Grund, warum so viel Abwehraufwand in der falschen Schicht landet.

Lesen Sie die letzten beiden Zeilen noch einmal, denn sie enthalten den entscheidenden praktischen Punkt. Ist die Schnittstelle gesättigt, hilft nichts, was Sie auf dem Server eintippen: Die Pakete haben den Port bereits verbraucht, und der Einzige, der sie verwerfen kann, ist derjenige, dem der Router upstream gehört. Ist die Schnittstelle ruhig, aber die Seite trotzdem nicht erreichbar, gilt das Gegenteil — Ihr Host sieht nichts Falsches, weil auf seiner Schicht tatsächlich nichts falsch ist, und die Lösung liegt vollständig bei Ihnen.

Was „DDoS-Schutz inklusive“ tatsächlich bedeutet

Schutz auf Netzwerkebene ist real, wertvoll und wird fast immer falsch verstanden. Wenn ein Anbieter mit Filterung auf Schicht 3 und 4 wirbt, ist gemeint: Sein Netzwerk überwacht den Datenverkehr zu Ihrer Adresse, und sobald eine Flut erkannt wird, leitet es den Verkehr durch Scrubbing-Hardware um, die den bösartigen Anteil verwirft und weiterleitet, was legitim aussieht. Das geschieht ohne Support-Ticket und meist, ohne dass Sie mehr als einen kurzen Ausschlag bemerken.

Dieser eine Satz leistet viel, es lohnt sich also, genauer aufzuschlüsseln, was er abdeckt und was nicht:

• Es deckt die Angriffe ab, die Sie allein nicht überstehen können. Eine 200-Gbps-Amplification-Flut gegen einen Server mit einem 1-Gbps-Port ist kein Konfigurationsproblem. Es ist Arithmetik. Upstream-Scrubbing ist die einzige Antwort, die es dafür gibt.
• Es kennt Ihre Anwendung nicht. Der Filter weiß nicht, welche Ihrer URLs teuer sind, welche Besucher angemeldet sind, oder dass eine Anfrage an Ihren Such-Endpunkt vierhundertmal so viel kostet wie eine Anfrage nach Ihrem Logo.
• Es reagiert auf einen Schwellenwert, nicht auf Ihr Leid. Die Erkennung löst anhand des Datenvolumens aus. Ein Angriff, der diesen Schwellenwert nie überschreitet, löst nie etwas aus — ganz gleich, wie gründlich er Ihre Seite bereits lahmgelegt hat.
• In Extremfällen kann es die Adresse kurzzeitig per Null-Routing vom Netz nehmen. Jedes Netzwerk hat eine Obergrenze. Bedroht ein Angriff gemeinsam genutzte Infrastruktur, kann die Adresse für eine Weile abgeschaltet werden — das ist Standardpraxis, überall üblich, und man sollte davon wissen, bevor es passiert, nicht erst währenddessen.

Zuerst: Ist es überhaupt ein Angriff?

Ein erstaunlich großer Anteil vermeintlicher DDoS-Vorfälle ist in Wirklichkeit etwas anderes im falschen Mantel, und die Abhilfen sind nicht austauschbar. Bevor Sie irgendetwas per Rate Limiting drosseln, nehmen Sie sich zwei Minuten Zeit, um die Hochstapler auszuschließen — eine Fehldiagnose kostet Sie hier eine Stunde und gelegentlich Ihre echten Nutzer.

• Sie sind plötzlich populär geworden. Ein Link auf einem großen Aggregator erzeugt ein Verkehrsmuster, das genau wie eine Schicht-7-Flut aussieht — nur dass die Referrer echt sind und die Anfragen Seiten gelten, die ein Mensch tatsächlich sehen möchte. Das ist ein Kapazitätsproblem mit einer erfreulichen Ursache; es per Rate Limiting zu drosseln, ist Selbstschädigung.
• Ein Crawler hat seine Manieren verloren. Aggressive Scraper und KI-Trainingsbots können einen kleinen Server mühelos überrennen. Der User-Agent verrät sich meist selbst, und die Lösung ist robots.txt plus ein gezieltes Limit, kein allgemeines.
• Sie haben selbst etwas kaputt gemacht. Ein Deployment, das Caching deaktiviert hat, ein außer Kontrolle geratener Cronjob, eine Datenbank, die einen Index verloren hat — all das zeigt sich als „plötzliche Last, kein erkennbarer Grund“. Fällt der Zeitpunkt mit einer eigenen Änderung zusammen, glauben Sie der Änderung.
• Ihr eigenes Monitoring ist die Flut. Selten, peinlich, und deutlich häufiger, als irgendjemand zugibt. Eine Health-Check-Schleife, die ohne Backoff wiederholt, kann eine wirklich beeindruckende Anfragerate erzeugen.

Die entscheidende Frage ist einfach: Will der Datenverkehr etwas? Echte Last — selbst wenn sie feindselig aussieht — hat eine Form. Sie trifft Seiten, die existieren, folgt Links, lädt Assets und kommt aus einer plausiblen Streuung von Netzwerken. Ein Angriff macht sich diese Mühe meist nicht.

Den Angriff direkt am Server ablesen

Sie brauchen kein Dashboard, um einzuordnen, was gerade passiert. Vier Befehle, der Reihe nach ausgeführt, verraten Ihnen in unter einer Minute, in welcher Schicht Sie gerade kämpfen — und das zu wissen, bestimmt alles, was Sie als Nächstes tun.

Ist die Leitung voll? Beobachten Sie die Schnittstellenzähler. Klebt der Durchsatz nahe an der Obergrenze des Ports, stecken Sie in einem volumetrischen Angriff, und Ihre Aufgabe ist ein Support-Ticket, keine Konfigurationsänderung:

• vnstat -tr 10 — durchschnittlicher Durchsatz über zehn Sekunden, der schnellste ehrliche Messwert für Sättigung.
• cat /proc/net/dev zweimal, im Abstand einer Sekunde — Paket- und Byte-Deltas pro Schnittstelle, ohne zusätzliches Tooling.

Ist es eine SYN-Flut? Halboffene Verbindungen stapeln sich im Zustand SYN-RECV. Eine Handvoll ist normal, Tausende nicht:

• ss -s — die Zusammenfassungszeile, Verbindungszahlen nach Zustand auf einen Blick.
• ss -tn state syn-recv | wc -l — die konkrete Zahl, auf die es ankommt.

Ist es Schicht 7? Ist die Bandbreite unauffällig, aber alles langsam, zählen Sie die Anfragen pro Client in Ihrem Access-Log. Eine einzelne Adresse mit zehntausenden Treffern ist ein Amateur; hunderttausend Adressen mit je drei Treffern sind der Ernstfall:

• tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30
• Tauschen Sie $1 gegen $7, um stattdessen die angefragten Pfade zu ranken. Dominiert ein teurer Endpunkt, haben Sie das Ziel gefunden — und die halbe Lösung gleich mit.

Was genau ist erschöpft? Die Load Average allein sagt wenig aus. Suchen Sie nach der konkreten Obergrenze, an die Sie gestoßen sind: alle PHP-FPM-Kindprozesse beschäftigt, Datenbankverbindungen am Limit, Dateideskriptoren erschöpft, oder Worker, die im Zustand D auf die Festplatte warten. Diese Obergrenze — nicht der Datenverkehr — hat die Seite lahmgelegt, und sie anzuheben ist oft schneller, als überhaupt irgendetwas zu filtern.

Die ersten zehn Minuten

Unter Druck greifen Menschen zum größten verfügbaren Hebel, und der größte Hebel ist meist der falsche. Das ist die Reihenfolge, die den Schaden begrenzt, ungefähr vom schnellsten und sichersten Schritt an:

1. Erst einordnen, dann handeln. Gesättigte Schnittstelle bedeutet volumetrisch; ruhige Schnittstelle mit beschäftigten Workern bedeutet Schicht 7. Dreißig Sekunden hier investiert bewahren Sie davor, eine Stunde lang die falsche Schicht zu reparieren.
2. Ist es volumetrisch, eröffnen Sie sofort ein Ticket und geben Sie die Zieladresse, die Startzeit und Ihre Schnittstellenzähler an. Hören Sie dann auf, auf dem Server herumzukonfigurieren — von innen lässt sich das nicht beheben.
3. Ist es Schicht 7, cachen Sie zuerst. Aggressives Full-Page-Caching für anonyme Besucher einzuschalten ist der mit Abstand schnellste Weg, einen Ausfall in ein Achselzucken zu verwandeln, und die einzige Maßnahme, die auch gegen echten Datenverkehr hilft.
4. Dann per Rate Limiting begrenzen — zuerst den anvisierten Endpunkt, danach alles andere. Beginnen Sie zurückhaltend. Ein Limit, das die eigenen Nutzer aussperrt, ist eine selbst zugefügte Fortsetzung des Angriffs.
5. Blockieren Sie nur das Eindeutige. Ein Dutzend Adressen mit je hunderttausend Anfragen, ein offensichtlich gefälschter User-Agent, ein Land, in dem Sie keine Nutzer haben. Widerstehen Sie dem Drang, unter Beschuss ausgefeilte Regeln zu schreiben — nächsten Monat werden Sie sich nicht mehr an sie erinnern.
6. Werfen Sie Last bewusst ab, wenn nötig. Eine statische „Wartungsseite“ an nicht authentifizierte Besucher auszuliefern, hält die Maschine am Leben, hält Ihre API oben und verschafft Ihnen Zeit zum Nachdenken. Selbst zu entscheiden, was geopfert wird, ist besser, als es entscheiden zu lassen.
7. Notieren Sie, was Sie getan haben. Jede temporäre Regel, die Sie hinzugefügt haben, ist eine Landmine für Ihr zukünftiges Ich. Die Regeln, die geholfen haben, werden dauerhaft; der Rest fliegt morgen wieder raus.

Rate Limits, die halten, und der Fehler, den alle machen

Rate Limiting ist das wichtigste Instrument für Schicht 7, und nginx erledigt es gut mit zwei Direktiven, die zwei wirklich unterschiedliche Probleme lösen. limit_req begrenzt die Rate der Anfragen — wie oft ein Client fragen darf. limit_conn begrenzt die Nebenläufigkeit — wie viele Verbindungen ein Client gleichzeitig offen halten darf. Fluten brauchen das Erste; Slowloris-Angriffe, die Tausende fast untätige Verbindungen offen halten, um Ihren Worker-Pool zu erschöpfen, brauchen das Zweite. Setzen Sie nur eines davon ein, sind Sie nur gegen die halbe Bedrohung abgesichert.

Drei Details entscheiden, ob ein Limit wirklich wirkt oder nur dekorativ ist:

• Nutzen Sie einen Burst, und nutzen Sie nodelay. Echte Browser kommen stoßweise — ein einzelner Seitenaufruf löst ein Dutzend nahezu gleichzeitiger Asset-Anfragen aus. Ein Limit ohne Spielraum drosselt echte Besucher, während ein Angreifer, der sich knapp unter dem Schwellenwert hält, ungehindert durchkommt.
• Begrenzen Sie teure Endpunkte separat. Ihre Suchseite, das Login-Formular, das Passwort-Reset und jeder Endpunkt, der in die Datenbank schreibt, verdienen ein deutlich engeres Budget als Ihre statischen Assets. Angreifer finden diese, ohne es darauf anzulegen, weil genau sie wehtun.
• Liefern Sie 429, nicht 503. Der Statuscode signalisiert wohlerzogenen Clients und Suchmaschinen, dass hier gedrosselt wird und kein Fehler vorliegt — und verhindert, dass aus einem schlechten Nachmittag auch noch ein Ranking-Problem wird.

Caching ist die günstigste Abwehrmaßnahme, die Sie je einsetzen werden

Ein Rate Limit weist Arbeit ab. Ein Cache lässt die Arbeit gar nicht erst entstehen. Für alles, was ein anonymer Besucher zu sehen bekommt, verändert Full-Page-Caching die Ökonomie des gesamten Angriffs: Eine Anfrage, die sonst einen Datenbank-Roundtrip, ein Template-Rendering und einen PHP-Worker gekostet hätte, wird zu einem in Mikrosekunden gemessenen Dateizugriff. Derselbe Server, der bei vierhundert dynamischen Anfragen pro Sekunde zusammengebrochen ist, bedient zehntausende gecachte Anfragen, ohne es zu bemerken.

Worauf es ankommt, wenn Sie es im Ernstfall einschalten:

• Cachen Sie nur für anonyme Besucher. Umgehen Sie den Cache bei einem Session-Cookie. Die Seite eines angemeldeten Nutzers einem anderen auszuliefern, ist ein weit schlimmerer Vorfall als der Ausfall, den Sie gerade beheben wollten.
• Liefern Sie absichtlich veraltete Inhalte aus. Die nginx-Direktive proxy_cache_use_stale mit updating error timeout sorgt dafür, dass Besucher bei einem kämpfenden Backend eine leicht veraltete Seite statt eines Fehlers bekommen. Während eines Angriffs ist das der Unterschied zwischen einer Seite, die intakt wirkt, und einer, die tot aussieht.
• Fassen Sie doppelte Cache-Misses zusammen. proxy_cache_lock sorgt dafür, dass tausend gleichzeitige Anfragen an dieselbe ungecachte Seite eine einzige Backend-Anfrage erzeugen, nicht tausend. Ohne das durchdringt ein Cache-Busting-Angriff den Cache ungebremst und trifft Ihre Datenbank mit voller Wucht.
• Entschärfen Sie Cache-Busting-Query-Strings. Der Standardtrick besteht darin, ? und einen Zufallswert anzuhängen, sodass jede Anfrage ein eindeutiger Schlüssel ist und dauerhaft am Cache vorbeigeht. Normalisieren Sie Ihren Cache-Key so, dass er Query-Parameter ignoriert, die Ihre Anwendung gar nicht tatsächlich nutzt.

Hier gibt es eine angenehme Asymmetrie, die es sich zu verinnerlichen lohnt: Jede Stunde, die Sie in Caching investieren, macht die Seite auch an ihrem besten Tag schneller, günstiger im Betrieb und besser darin, den eigenen Erfolg zu überstehen. Kaum eine andere Verteidigungslinie zahlt eine Dividende, wenn gar nichts schiefläuft.

Die Obergrenzen, die darüber entscheiden, ob Sie in die Knie gehen

Die meisten Server sterben nicht, weil ihnen die CPU ausgeht. Sie sterben, weil sie an eine unsichtbare Obergrenze stoßen, die niemand bewusst gesetzt hat — einen Standardwert aus einem Jahrzehnt zuvor, der auf Hardware sinnvoll war, die heute niemand mehr benutzt. Unter Angriff bricht in der Praxis zuerst Folgendes:

• Anwendungs-Worker. PHP-FPMs pm.max_children, die Zahl Ihrer Python-Worker, die Größe Ihres Node-Clusters. Das ist das eigentliche Nebenläufigkeitslimit Ihrer Seite. Sind alle beschäftigt, reiht sich jeder weitere Besucher ein, und die Seite ist down, egal wie untätig die CPU aussieht. Erhöhen Sie den Wert nur so weit, wie der Arbeitsspeicher es zulässt — Swapping ist schlimmer als Warten in der Warteschlange.
• Die Accept-Queue. net.core.somaxconn und Ihr Listen-Backlog bestimmen, wie viele Verbindungen auf ihre Annahme warten dürfen. Ein zu kleiner Backlog macht aus einem überstehbaren Burst abgelehnte Verbindungen.
• SYN-Cookies. net.ipv4.tcp_syncookies erlaubt es dem Kernel, auf eine SYN-Flut zu antworten, ohne Zustand für Verbindungen zu reservieren, die nie zustande kommen. Moderne Kernel aktivieren das standardmäßig; prüfen Sie es nach, statt es anzunehmen — es kostet nichts und bewahrt Sie vor der häufigsten Flut überhaupt.
• Dateideskriptoren. Jede Verbindung ist ein Deskriptor. Das Standardlimit nofile liegt häufig niedriger als die Zahl der Verbindungen, die Sie bedienen wollen, und die Fehlerart — Accepts schlagen fehl, während alles andere gesund aussieht — ist um drei Uhr morgens wirklich verwirrend.
• Datenbankverbindungen. Die Worker-Zahl zu erhöhen, ohne den Connection Pool mit anzuheben, verschiebt die Warteschlange nur an eine schwerer sichtbare Stelle. Diese beiden Werte müssen gemeinsam angepasst werden.

Stellen Sie diese Werte an einem ruhigen Tag ein, nicht während eines Vorfalls. Der Sinn, sie zu kennen, ist: Wenn die Seite zusammenbricht, können Sie die Obergrenze benennen, an die sie gestoßen ist, statt zu raten — und eine benannte Obergrenze ist eine, die sich beheben lässt.

Etwas vor den Ursprung setzen

Alles bisher Genannte spielt sich auf dem Server ab. Der nächste Schritt ist die Entscheidung, ob der Server überhaupt das sein soll, was den Datenverkehr empfängt. Es gibt drei ehrliche Optionen, und die richtige Antwort hängt weit mehr davon ab, was Sie hosten, als davon, was Sie sich leisten können.

Der selbst betriebene Frontknoten verdient mehr Aufmerksamkeit, als er üblicherweise bekommt — besonders für alle, die Offshore-Hosting aus Gründen gewählt haben, für die ein großes CDN wenig Verständnis hätte. Das Muster ist unglamourös: günstige Proxy-Knoten davor, ein Ursprung, dessen Firewall nur Verbindungen von diesen Knoten akzeptiert, DNS-Einträge, die auf die Fronten zeigen. Wird eine Front angegriffen, ersetzen Sie sie binnen Minuten durch eine neue Adresse, und der Ursprung merkt nichts davon. Die vollständige Version dieser Architektur — einschließlich der sechs Wege, auf denen eine Ursprungsadresse trotzdem leckt — ist das Thema unseres Leitfadens Ursprungsserver-IP verbergen.

Ein verborgener Ursprung ist mehr wert als jeder Filter

Man sollte es unumwunden aussprechen, denn es kehrt die übliche Prioritätenordnung um: Die günstigste DDoS-Abwehr, die Ihnen zur Verfügung steht, ist eine Adresse, die der Angreifer nicht hat. Filterung ist das, was Sie tun, wenn das bereits gescheitert ist.

Das ist wichtiger, als es klingt, denn Ursprungsadressen lecken ständig und leise. Historische DNS-Einträge von vor dem Proxy überdauern die Umstellung um Jahre. Mail, die direkt von der Anwendung verschickt wird, trägt die Adresse in ihren Headern. Ein TLS-Zertifikat, das auf die rohe Adresse ausgestellt wurde, wird dauerhaft in Certificate-Transparency-Logs veröffentlicht. Eine Fehlerseite, eine Weiterleitung oder eine obskure Subdomain, die nie geproxt wurde, verraten sie ebenfalls. Haben Sie ein CDN vor einen Server gesetzt, der früher direkt exponiert war, gehen Sie davon aus, dass die alte Adresse bekannt ist, bis Sie sie geändert haben.

Hardware und Standort so wählen, dass Angriffe langweilig bleiben

Ein Teil davon wird entschieden, bevor überhaupt ein Angriff stattfindet — in dem Moment, in dem Sie einen Tarif auswählen. Drei Eigenschaften zählen weit mehr, als das Datenblatt vermuten lässt:

• Unbegrenzte Bandbreite. Bei einem Tarif mit Datenlimit ist ein Angriff nicht nur ein Ausfall — er ist auch eine Rechnung. Datenverkehr, um den Sie nie gebeten haben und den Sie nicht ablehnen konnten, zählt trotzdem gegen Ihr Kontingent. Unbegrenzter Transfer verwandelt ein finanzielles Risiko in ein rein technisches — eine deutlich angenehmere Art von Problem.
• Ob der Port Ihnen allein gehört. Auf einem geteilten virtualisierten Host kann ein angegriffener Nachbar Sie in Mitleidenschaft ziehen, und Ihre eigene Schutzobergrenze ist eine gemeinsam genutzte. Dedizierte Hardware mit eigenem Port beseitigt beide Effekte. Für ein Projekt, das mit feindseliger Aufmerksamkeit rechnet, ist das der klarste Grund, von einem VPS aufzusteigen — mehr als Kerne oder RAM.
• Wo das Netzwerk sitzt. Ein gut angebundenes europäisches Netzwerk mit echter Transitkapazität absorbiert eine Flut, an der ein schlecht gepeertes Netzwerk scheitert, und die Jurisdiktion, die Sie aus rechtlichen Gründen gewählt haben, hat auch netzwerktechnische Eigenschaften. Es lohnt sich, bei der Wahl aus den verfügbaren Standorten beides zu prüfen.

Es gibt außerdem ein Größenargument, das leise für Einfachheit spricht. Eine statische Seite hinter einem Cache auf einem bescheidenen Server ist außerordentlich schwer lahmzulegen; derselbe Inhalt auf einem schwergewichtigen CMS mit ungecachtem Such-Endpunkt kann von einer einzigen entschlossenen Person mit einem Skript zerschlagen werden. Weniger Dynamisches zu haben ist selbst schon eine Abwehrmaßnahme, und sie ist kostenlos. Lebt Ihr Projekt wirklich unter anhaltender Last, behandeln unsere Hinweise zu High-Traffic-Hosting die Dimensionierungsseite derselben Frage.

Fünf Dinge, die Sie nicht tun sollten

Die Fehlermuster hier sind konsistent genug, um sie aufzulisten, und jedes davon hat schon einmal jemanden ein Wochenende gekostet:

• Nullrouten Sie sich nicht selbst. Die eigene Adresse zu blackholen, beendet den Angriff auf die denkbar wörtlichste Art — niemand erreicht Sie mehr, auch Ihre Nutzer nicht. Das ist ein letztes Mittel Ihres Anbieters, keine Maßnahme, die Sie freiwillig ergreifen.
• Behandeln Sie fail2ban nicht als DDoS-Schutz. Es ist ein gutes Werkzeug gegen Brute-Force-Versuche von wenigen Adressen. Gegen eine verteilte Flut reagiert es in Minuten auf etwas, das in Sekunden eintrifft, und ein Regelwerk, das Tausende Adressen sperrt, kann in der Firewall-Verarbeitung mehr kosten, als der Angriff Sie gekostet hat.
• Zahlen Sie kein Lösegeld. Die überwältigende Mehrheit der Erpresser-E-Mails, die einen verheerenden Angriff androhen, stammt von Leuten ohne jede Fähigkeit, die Tausende identische Nachrichten verschicken. Die kleine Minderheit, die tatsächlich liefern könnte, kommt wieder — weil Sie bewiesen haben, dass Sie zahlen.
• Schlagen Sie nicht zurück. Das ist praktisch überall illegal, und die Quellen sind kompromittierte Dritte. Sie würden Opfer angreifen — und das noch von einer Adresse aus, die eindeutig Ihnen gehört.
• Migrieren Sie nicht in Panik. Den Host mitten im Angriff zu wechseln bedeutet, dass die neue Adresse binnen Minuten öffentlich ist und Sie über keine funktionierende Konfiguration verfügen. Erst stabilisieren, später bewusst umziehen — und wenn Sie umziehen, gibt es unseren Leitfaden zur Migration ohne Ausfallzeit genau deshalb, damit der Umzug nicht zum zweiten Vorfall wird.

Die Kurzfassung

Ohne die Begründung passt das Arbeitsmodell in acht Zeilen:

1. Erst einordnen. Gesättigte Schnittstelle bedeutet volumetrisch und liegt bei Ihrem Host. Ruhige Schnittstelle mit erschöpften Workern bedeutet Schicht 7 und liegt bei Ihnen.
2. Bei volumetrisch: Ticket eröffnen mit Adresse, Zeitstempel und Ihren Zählerständen — und danach den Server nicht mehr anfassen.
3. Aggressiv für anonyme Besucher cachen, unter Stress veraltete Inhalte ausliefern und doppelte Cache-Misses zusammenfassen. Das ist die wirkungsvollste Änderung, die Sie vornehmen können.
4. Per Rate Limiting nach Anfragerate und nach Nebenläufigkeit begrenzen, am engsten bei den teuersten Endpunkten, und 429 zurückliefern.
5. Die Real-IP-Konfiguration vor allem anderen korrigieren, sonst ist jedes Limit pro Client hinter einem Proxy entweder wirkungslos oder katastrophal.
6. Ihre Obergrenzen kennen — Worker, Backlog, Deskriptoren, Datenbankverbindungen — und sie bewusst an einem ruhigen Tag anheben.
7. Die Ursprungsadresse geheim halten und per Firewall auf Ihre Frontknoten beschränken. Das ist mehr wert als alle Filter zusammen.
8. Unbegrenzte Bandbreite kaufen, damit Datenverkehr, um den Sie nie gebeten haben, nie auch noch zu einer Rechnung wird.

Nichts davon macht Sie unangreifbar, und wer Unangreifbarkeit verkauft, verkauft etwas anderes. Was es bewirkt, ist, Sie aus der Gruppe herauszuholen, die von einem gelangweilten Teenager offline genommen wird, und in die Gruppe zu versetzen, die echte Ressourcen und echte Absicht erfordert, um gestört zu werden — was für die überwältigende Mehrheit der Projekte von echter Sicherheit nicht zu unterscheiden ist. Der Rest ist dieselbe unglamouröse Arbeit, die einen Server auch sonst überall gut macht: am ersten Tag gehärtet, am schlimmsten Tag wiederherstellbar, und betrieben an einem Ort, der Ihren Datenverkehr als Ihre eigene Angelegenheit behandelt.