Notfallplan bei DDoS-Angriff: was wirklich drinstehen muss
Es ist 3:40 Uhr nachts. Ihr Monitoring schlägt an, weil die Antwortzeiten Ihrer Website von 180 Millisekunden auf über vier Sekunden springen, und der Traffic steigt innerhalb von zwei Minuten von durchschnittlich 400 auf 12.000 Anfragen pro Sekunde. Wer jetzt erst anfängt zu überlegen, wen er anruft, hat schon verloren. Genau dafür gibt es einen Notfallplan bei DDoS-Angriff.
Ich habe einen solchen Plan nicht am Reißbrett entworfen, sondern nach einem Vorfall, bei dem wir 40 Minuten lang im Blindflug unterwegs waren. Was ich daraus gelernt habe, steht in diesem Artikel. Kein Lehrbuch, sondern das, was tatsächlich funktioniert.
Wichtige Erkenntnisse
- Ein Notfallplan ist kein Dokument, das im Sharepoint verstaubt, sondern eine geübte Abfolge von Schritten mit klaren Entscheidungsbefugnissen.
- Die ersten 30 Minuten entscheiden über den Schaden. Wer hier improvisiert, verliert Zeit und Geld.
- Ohne Baseline-Werte Ihres normalen Traffics können Sie einen Angriff nicht von einer legitimen Lastspitze unterscheiden.
- Technische Gegenmaßnahmen (Scrubbing, BGP FlowSpec, Blackholing) gehören in den Plan, nicht in eine separate Wiki-Seite.
- Rechtliche Pflichten – Meldung an das BSI bei kritischen Infrastrukturen, Datenschutzmeldungen – sind Teil des Plans, nicht ein Anhang.
- Ein Plan ohne Nachbereitung ist nach dem zweiten Angriff wertlos.
Wie erstelle ich einen Notfallplan?
Ehrlich gesagt: Die meisten Pläne, die ich gesehen habe, scheitern nicht an fehlendem Inhalt, sondern daran, dass niemand weiß, wer im Ernstfall was entscheiden darf. Ein Notfallplan ist zuerst ein Rollen- und Eskalationsdokument und erst danach eine technische Anleitung.
Schritt 1: Rollen und Entscheidungsbefugnisse festlegen
Benennen Sie konkret eine Person als Incident Commander. Diese Rolle koordiniert, trifft Entscheidungen und kommuniziert – sie administriert nicht gleichzeitig den Server. Das ist der häufigste Fehler: Die technisch fähigste Person steckt mitten in der Mitigation und kann deshalb nicht steuern.
- Incident Commander (Entscheidung, Kommunikation)
- Technischer Lead (Mitigation, Abstimmung mit Provider)
- Ansprechpartner für Geschäftsführung
- Kommunikation (Kunden, Presse, Statusseite)
Schritt 2: Baseline-Werte dokumentieren
Ohne einen Normalzustand können Sie keinen Ausreißer erkennen. Erfassen Sie über mindestens zwei Wochen Ihre typischen Werte: Bandbreite, Pakete pro Sekunde, gleichzeitige Verbindungen, Antwortzeit Ihrer kritischen Endpunkte. Notieren Sie auch die Tages- und Wochenschwankungen.
Bei uns lagen die Werte nachts bei rund 90 Anfragen pro Sekunde. Als die 12.000 kamen, war die Sache klar. Hätte ich diese Zahl nicht gekannt, hätte ich eine Viertelstunde mit Analysieren verloren.
Schritt 3: 24/7-Kontakte hinterlegen
Sie brauchen erreichbare Nummern, die auch nachts funktionieren – nicht die allgemeine Support-Hotline Ihres Providers. Konkret:
- Ihr Internet-Provider oder Upstream, mit Eskalationsnummer
- Ihr Mitigation-Dienstleister, falls Sie einen haben
- Ihr Rechenzentrumsbetreiber
- Interne Entscheider, die Budget freigeben dürfen
- Rechtliche Beratung
Testen Sie diese Nummern. Wirklich. Ich habe eine Nummer aus dem Plan angerufen und landete in einer Warteschleife für allgemeine Vertragsfragen.
Schritt 4: Schwellenwerte definieren
Ein Plan muss sagen, ab wann gehandelt wird. Beispiel aus unserer Praxis: Übersteigt der Traffic die dreifache Baseline für mehr als zwei Minuten, wird der Incident Commander alarmiert. Übersteigt er das Zehnfache, wird sofort der Mitigation-Dienstleister aktiviert, ohne weitere Rücksprache. Solche Regeln nehmen Entscheidungen aus der Panikphase heraus.
Welche Gegenmaßnahmen gibt es gegen DDoS-Angriffe?
Die Maßnahmen greifen auf unterschiedlichen Ebenen. Wichtig ist die Reihenfolge – wer alle gleichzeitig startet, macht mehr kaputt als der Angriff selbst.
Technische Gegenmaßnahmen
| Maßnahme | Wirkung | Typischer Einsatzpunkt |
|---|---|---|
| Scrubbing | Schädlichen Verkehr herausfiltern, legitimen durchlassen | Ab spürbarer Überlastung |
| BGP FlowSpec | Verkehr nach definierten Mustern gezielt verwerfen | Wenn Muster erkennbar sind |
| Remote Triggered Black Hole | Verkehr zu einem Ziel komplett verwerfen | Als letztes Mittel – Ziel ist dann nicht erreichbar |
| Rate Limiting | Anfragen pro Quelle begrenzen | Bei volumetrisch kleinen, aber zielgerichteten Angriffen |
Das Blackholing ist die brutale Option: Sie retten damit das Netz, opfern aber das angegriffene Ziel. Wer das nicht explizit im Plan regelt, diskutiert im Ernstfall darüber, während die Dienste sterben.
Organisatorische Maßnahmen
Der BSI-Standard 200-4 zum Notfallmanagement und die ISO 22301 zum Business Continuity Management geben den Rahmen. Beide verlangen im Kern dasselbe: ein Verfahren, das den Notfall auslöst, Zuständigkeiten regelt und einen Wiederanlauf beschreibt. Die Struktur in fünf Phasen – Vorbereitung, Erkennung, Bewältigung, Wiederherstellung, Nachbereitung – passt für DDoS genauso wie für einen Stromausfall.
Gibt es eine Vorlage für einen IT-Notfallplan im Falle eines Cyberangriffs?
Ja, aber seien Sie vorsichtig mit fertigen Musterdokumenten. Ich habe Vorlagen von Kammern und aus Handbüchern zum Informationssicherheits-Managementsystem durchgearbeitet – die meisten sind zu generisch. Eine Vorlage hilft Ihnen bei der Struktur, nicht beim Inhalt. Ihre Schwellenwerte, Ihre Kontakte, Ihre Systeme kann kein Muster liefern.
Mindeststruktur einer brauchbaren Vorlage
- Deckblatt mit Version, Datum, Freigabe
- Geltungsbereich: welche Systeme sind abgedeckt
- Rollen und Vertretungen
- Auslösekriterien mit konkreten Schwellenwerten
- Kontaktliste, geprüft und datiert
- Maßnahmenkatalog nach Angriffsart
- Kommunikationsvorlagen für Kunden und Behörden
- Nachbereitung mit Vorlage für den Abschlussbericht
Ich nutze für Kritik von Kollegen immer dieselbe Regel: Ein Plan ist gut, wenn jemand, der nicht am Projekt beteiligt war, ihn nach zehn Minuten Lesen anwenden könnte. Falls nicht, ist er zu abstrakt.
Gibt es eine Vorlage für einen Notfallalarmplan?
Ein Alarmplan ist etwas anderes als ein Notfallplan. Der Alarmplan regelt nur, wer bei welchem Signal wie informiert wird. Er ist der Teil, der zuerst ausgelöst wird, noch bevor irgendjemand mit der Mitigation beginnt.
So sieht eine funktionierende Alarmkette aus
Erste Stufe: automatisches Monitoring erkennt die Abweichung und schickt eine SMS an den Bereitschaftsdienst. Zweite Stufe: der Bereitschaftsdienst bestätigt innerhalb von fünf Minuten, sonst wird die nächste Person alarmiert. Dritte Stufe: der Incident Commander zieht die Eskalationsliste. Eine Notfallkarte im Scheckkartenformat – physisch, ausgedruckt – hat sich bei uns bewährt, weil im Stress niemand ein Wiki öffnet.
Kostenlose Vorlagen für Notfallkarten und Verhaltensanweisungen bekommen Sie bei vielen Handelskammern und auf den Seiten der Bundesbehörden. Prüfen Sie aber jede Vorlage gegen Ihre eigene Realität, bevor Sie sie übernehmen.
Die ersten 30 Minuten: was wirklich zählt
Hier kommt der Teil, den die meisten Pläne auslassen. Eine konkrete Abfolge:
- T+0 bis T+2: Alarm bestätigen, Incident Commander benennen, Kommunikationskanal öffnen (nicht E-Mail, das kann selbst betroffen sein).
- T+2 bis T+5: Angriffsart grob einordnen – volumetrisch, protokollbasiert oder auf Anwendungsebene. Baseline mit den aktuellen Werten vergleichen.
- T+5 bis T+10: Provider oder Mitigation-Dienstleister aktivieren. Statusseite informieren.
- T+10 bis T+20: Erste Mitigation greift oder nicht. Falls nicht, nächste Stufe hochschalten.
- T+20 bis T+30: Lage stabilisieren, entscheiden, ob Kunden und Behörden informiert werden müssen.
Der rechtliche Teil wird oft vergessen: Bei kritischen Infrastrukturen greifen Meldepflichten, und wenn personenbezogene Daten betroffen sein könnten, laufen Fristen zur Meldung an die Aufsichtsbehörde. Diese Fristen sind kurz. Wer erst nach drei Tagen überlegt, ob er melden muss, hat ein Problem.
Warum die Nachbereitung über den nächsten Angriff entscheidet
Nach dem Angriff kommt der unangenehme Teil. Kein Plan überlebt den ersten echten Vorfall unverändert. Setzen Sie innerhalb einer Woche eine Nachbesprechung an, solange die Erinnerung frisch ist. Drei Fragen:
- Was hat funktioniert, was nicht – und zwar konkret, nicht „die Kommunikation“
- Welche Schwellenwerte waren zu hoch oder zu niedrig
- Welche Kontakte waren nicht erreichbar
Bei uns kam heraus, dass die Kontaktliste für den Provider veraltet war. Ein Anruf hätte die Mitigation um 15 Minuten verkürzt. 15 Minuten sind bei einem DDoS oft die Differenz zwischen „Website langsam“ und „Website nicht erreichbar“.
Die beste Vorlage ersetzt keine Übung. Nehmen Sie sich zweimal im Jahr eine Stunde, spielen Sie einen Angriff durch und schreiben Sie danach die Änderungen in den Plan. Andernfalls haben Sie ein Dokument, aber keinen Notfallplan.
