Den Projektordner öffnen
Lege das exportierte Zugriffslog und eine Kopie deiner Servereinstellungen in einen Ordner und öffne diesen Ordner in SmartCode Relay.
Arbeitsabläufe
Layer 7 DDoS protection: vom exportierten Log zum Runbook
03
Eine Verkehrsspitze auf der Seite eines kleinen Shops
Die Seite deines Shops war letzte Nacht langsam. Warum? Eine Kampagne oder eine Layer-7-Flut könnten beides erklären. Du hast ein exportiertes Zugriffslog und eine Kopie deiner Servereinstellungen, und diese Anleitung macht daraus eine Zusammenfassung, den Entwurf einer Ratenbegrenzung und ein Runbook.
Die Anfragen zusammenfassen
Bitte den Agenten, dein Log-Auswertungsskript auszuführen und die Anfragen pro Adresse und pro Pfad in einer CSV-Datei zu speichern.
Die Ratenbegrenzung entwerfen
Lass ihn die Kopie deiner Einstellungen bearbeiten, lies den Diff und führe deinen eigenen Testbefehl auf dieser Kopie aus.
Schreiben und prüfen
Speichere ddos-runbook.txt, lies es Zeile für Zeile und nutze Plan only, um aufzulisten, was noch offen ist, bevor du irgendetwas anwendest.
Beispiel: ein einseitiges Reaktions-Runbook
Schreibe ddos-runbook.txt für die Shop-Seite aus der Log-Zusammenfassung und den Notizen des Anbieters.
- read_file
exports/summary.csvgelesen - http_get
your provider's status pageabgerufen - write_file
ddos-runbook.txtgespeichert - grep
^step ddos-runbook.txt6 Treffer
Warte auf dein OK vor dem nächsten SchrittAblehnenÜbernehmen
ddos-runbook.txt
# ddos-runbook.txt - small shop site
# Owner: site admin
trigger: slow pages and an odd log summary
step 1: check the provider status page
step 2: raise the provider protection level
step 3: review the log summary for top paths
step 4: apply a rate limit, then test it
step 5: keep the origin address private
step 6: record times, rules and who was called
rollback: remove the limit if real visitors are refused
review: update this file after each incidentEs ist Klartext. Jeder Schritt nennt eine Aktion für dich oder deinen Anbieter, keiner enthält einen Angriffsbefehl, und die letzten beiden Zeilen sagen, wie man zurückrollt und wann man prüft.
Zwei weitere Arbeitsabläufe
Schwellenwerte für dein eigenes DDoS-Monitoring festlegen
Schwellenwerte gehören in das Monitoring-System, das du bereits betreibst, und der Agent hilft dir nur bei der Wahl der Zahlen. Er richtet selbst keine Alarme ein. read_file öffnet die Log-Zusammenfassung eines normalen, belebten Tages, grep durchsucht sie nach den wichtigen Pfaden, und write_file speichert eine kurze Notizdatei mit den einzutragenden Werten. Der Umgang mit einem DDoS-Angriff auf eine Website gelingt besser, wenn die Schwellenwerte vor der Nacht aufgeschrieben wurden, in der man sie braucht. Nutze zuerst Plan only, um die Gliederung der Schritte zu lesen, da dieser Modus nichts ausführt, und wechsle dann zu Ask first, damit der Agent die Zusammenfassung lesen und write_file die Notizen speichern kann. Prüfe jede Zahl anhand deiner eigenen Analytics, trage sie selbst ein und beobachte den ersten Alarm genau.
Eine aktive Adresse von vielen unterscheiden
Die Abwehr von DDoS-Verkehr aus verteilten IPs kann nicht darauf beruhen, eine einzelne Adresse zu blockieren, also vergleiche die Zählungen pro Adresse und pro Pfad in deiner Zusammenfassung. Viele kleine Absender summieren sich. Layer-7-DDoS-Schutz stützt sich auf Limits pro Pfad, weil jede Anfrage für sich normal aussieht. Shell führt dein Log-Auswertungsskript erneut aus, damit es nach Pfad gruppiert, und grep durchsucht die neue Zusammenfassung nach den Pfaden, die dich interessieren. Wenn DDoS-Angriffe nicht abreißen und du sie am Server nicht stoppen kannst, sagt das Runbook, wann du den Anbieter anrufst. Prüfe die Zusammenfassung im Modus Ask first und teste jedes neue Limit an einer Kopie.
