Ein Kundenhost wurde von einer DDOS-Attacke getroffen, etwa 50Mbps. Der Uplink war nahezu saturiert, mit ~80% packet loss war SSH noch so graaade eben möglich.
Interessant: Nach einer ersten schnellen iptables DROP regel „stieg“ die Bandbreite auf 90%. Im ersten Moment wirkt das seltsam, ist aber logisch: Wenn eine interne Paketverarbeitung nicht mehr der Flaschenhals ist, trifft es den nächsten Engpass.
Aus gegebenem Anlass, tldr;: man kann ddos nicht auf seinem Host filtern. Sobald die Host-Firewall erreicht wurde, ist das Paket ja schon durch die Leitung geflogen … (da hilft es auch nicht, die schnellen Admins anzurifen).
Mehr Details zu „how to ddos“ und „how to mitigate“
Ein Server (Socket, Application, Whatever) kann den Empfang eines Pakets durch den darunterliegenden Kernel nicht verhindern. Jegliche Filterung innerhalb eines Betriebssystems erfolgt erst, nachdem der Kernel das Paket bereits komplett empfangen und (ggf) zusammengebaut hat. Dieser kann das Paket dann zwar verwerfen, zum Beispiel um eine Verarbeitung durch eine Applikation zu verhindern, aber nicht den Empfang „nachträglich“ verhindern. Und ja, auch so ein Kernel braucht für Filteraktionen Rechenleistung – viele Pakete = viel CPU.
Anders ausgedrückt: Bis ein Host von dem Paket erfährt, ist die Kapazität der physischen Anbindung bereits erschöpft. Die Ressource „Bandbreite“ wurde schon verbraucht, sobald der vorgelagerte Router das Paket an seinem Ethernet-Port (physisch oder virtuell) ausgibt. Sobald sich das Paket im Netzwerk befindet, erreicht es unweigerlich den Buffer der Ethernet-Schnittstelle des Ziels – und löst dort Interrupts (mit Rechenzeitverbauch) aus. Das ist ein [D]DOS.
Und was macht man jetzt?
Die einzige Möglichkeit, ddos auf einen Host (Kernel) zu verhindern, besteht darin, die Filterung vorgelagert durchzuführen. Firewall, Router, Netfilter, Burstfilter, CDN oder whatever.
Es wird noch besser: Wenn die Anzahl der Packets die Uplink-Kapazität des ISPs überlastet, muss die Filterung noch weiter vorgelagert werden. Idealerweise durch Umleitung des gesamten Datenverkehrs über einen externen DDoS-Protection-Service.
Ist das nicht ohne weiteres möglich, muss diese „Umleitung“ via DNS passieren. Man kann seine Domain(s) auf einen dritten Filter-Proxy oder ein CDN umleiten, das den DDoS Traffic abfängt. Cloudflare macht dabei einen guten Job, es gibt aber auch viele andere. Einzig auf „seine“ original IP muss man dann etwas aufpassen, denn wird diese bekannt, umgeht der Angreifer die Schutzmaßnahme kurzerhand.
Ende gut?
In diesem Fall ist alles wieder gut. Die Applikationen auf dem Host konnten alle geschützt werden und ein „Notfall“ Anruf beim ISP war erfolgreich. Dieser hat kurzerhand die Regeln auf dem Kernrouter geändert, die das Weiterleiten der (glücklicherweise gut „identifizierbaren“) Pakete verhinderte. Außerdem wurde eine Firewall „dazubestellt“.
Lieber ein kleiner und kompetenter ISP als ein Hyperscaler der am Ende noch für den Traffic eine Rechnung geschrieben hätte …
