Was bei einem DDoS-Ereignis passiert

Es wird nichts eingeschaltet

Es gibt keinen Schalter. Das Waschen läuft permanent vor jeder Website, von vier Terabit pro Sekunde an den kleineren Standorten bis zu zwölf am größten, und die Entscheidung, ein Paket zu verwerfen, wird in Hardware an der Kante auf dem Weg nach innen getroffen. Die ersten dreißig Sekunden eines Angriffs werden daher genau so gefiltert wie die letzten dreißig, was bei keinem System der Fall ist, das einen Angriff erkennen, ein Präfix umleiten und auf die Verbreitung der Ankündigung warten muss.

Was Sie von innen sehen

Normalerweise überhaupt nichts. Reflektiertes UDP, eine SYN-Flut, eine Reihe verstärkter DNS-Antworten: Ein volumetrischer Angriff jeglicher Form wird vorgelagert verworfen und erreicht Ihren Port nie. Das Diagramm im Panel zeigt es. Ihre Interface-Zähler nicht.

Was Sie erreichen kann, ist alles, was von echtem Verkehr nicht zu unterscheiden ist: ein langsamer HTTP-Flood, ein Strom von Anfragen an Ihren teuersten Endpunkt, ein Credential-Stuffing-Lauf. Layer 7 ist der Ort, an dem die Kante ohne Kenntnis Ihrer Anwendung nicht helfen kann, wofür das DDoS-Pro-Add-on existiert: benutzerdefinierte Signaturen, Ratenlimits pro Pfad und eine Person, die während des Geschehens mit Ihnen daran schreibt.

Prüfen Sie zuerst Ihre eigenen Grenzen, bevor Sie Schlüsse ziehen

Gut die Hälfte der uns gemeldeten Angriffe ist eine volle Conntrack-Tabelle oder eine überlaufende Listen-Warteschlange unter gewöhnlichem Montagsverkehr.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
nstat -az TcpExtListenOverflows TcpExtSyncookiesSent
ss -s
journalctl -k --since "15 min ago" | tail -50

nf_conntrack: table full, dropping packet im Kernel-Log ist Ihre Firewall, die über sich selbst spricht, nicht das Netzwerk, das einen Angriff meldet.

Was wir tun

Die Erkennung ist flussbasiert und pro Ziel. Ein Signaturtreffer verwirft den passenden Verkehr innerhalb von Sekunden und lässt den Rest Ihres Verkehrs in Ruhe. Wenn das Volumen das überschreitet, was eine Website aufnehmen kann, was selten vorkommt und schon vorgekommen ist, wird die Zieladresse für ein angegebenes Zeitfenster vollständig gefiltert, anstatt die Website für alle darauf zu verschlechtern. Sie erhalten eine E-Mail, die das Fenster nennt, und es wird in Minuten gemessen.

Angriffsverkehr wird nie auf die faire Nutzung angerechnet. Es ist nicht Ihr Verkehr, und Sie haben nicht darum gebeten.

Was wir Ihnen danach mitteilen können

Vektor, Spitzenbitrate, Spitzenpaketrate, Dauer und die grobe Geografie der Quellen. Das ist, was Flusszähler speichern.

Was wir nicht aushändigen können, ist ein Paketmitschnitt, weil es keinen gibt. Wir zeichnen den Verkehr, der Ihre Instanz durchquert, nicht auf, und diese Richtlinie hat keine Ausnahme, die sich selbst einschaltet, wenn der Verkehr feindselig wird. Die Details finden Sie unter was wir protokollieren. Leute empfinden das gelegentlich mitten im Vorfall als frustrierend, und es ist dieselbe Eigenschaft, die den Rest der Richtlinie wertvoll macht.

Was Sie nicht tun sollten

• Ändern Sie nicht die Adresse. Der Angriff folgt ihr innerhalb einer Minute, und jetzt ist auch Ihr DNS falsch.
• Starten Sie nicht neu. Eine neu startende Instanz ist eine langsamere Instanz, keine gefilterte.
• Fügen Sie nicht in Panik eine tausendzeilige nftables-Regelsatz ein. Alles, was Sie auf der Instanz verwerfen, hat bereits den teuren Teil des Netzwerks überquert.
• Prüfen Sie zuerst /status. Wenn die Website selbst einen Vorfall hat, wird er dort veröffentlicht, bevor Ihr Ticket geschrieben wird.

Öffnen Sie das Ticket trotzdem

Instanz-ID, Zeitstempel mit Zeitzone, was das Symptom tatsächlich war und ob der Dienst von einem zweiten Netzwerk aus erreichbar war. Die mittlere erste Antwortzeit beträgt elf Minuten zu jeder Stunde des Tages, und während eines laufenden Ereignisses kommt die Antwort von jemandem, der bereits das Diagramm beobachtet.