Straßenkampf
tl;dr: Wir stehen am Standort rh-tec (95.143.172.0/24) so massiv unter Beschuss, dass derzeit ein Nullrouting des kompletten IPv4-Netzes den Stand der Dinge darstellt - es ist also aktuell nichts mehr per IPv4 erreichbar. Die Erreichbarkeit per IPv6 ist derzeit weitestgehend unbeeinträchtigt. Gestern wurde zudem die IP von uberspace.de selbst attackiert; das scheint derzeit aber weitestgehend im Griff. Update: Seit ca. 17:35 Uhr kriegen wir wieder Traffic durch; ob die Angreifer nur pausieren oder die Angriffe damit vorbei sind, ist aber nicht einschätzbar. Update 2: Ab ca. 22:45 Uhr gab es nun auch im Netz von uvensys hohen Paketverlust; während die dortige Technikerbereitschaft daran arbeitet, werden offenbar auch auf rh-tec auch wieder Attacken gefahren. Update 3: Seit 22.8. ca. 9:45 Uhr werden wieder IPs in unserem Netz bei Plus.line attackiert; das betrifft nur wenige User-Hosts, aber uberspace.de selbst.
Update 4, 23.08. 9:30 Uhr: Unsere Rechenzentrumsbetreiber an allen drei Standorten erarbeiten mit uns abgestimmte Gegenmaßnahmen, auf die wir hier aber erst mal nicht weiter eingehen möchten, um den Angreifern möglichst wenig Hilfestellung zu geben.
Diesmal geht’s wohl gegen uns
Verteilte Denial-of-Service-Attacken (DDoS) sind leider eine Plage, mit der wir nicht zum ersten Mal zu tun haben. Kleinere Attacken, die man sich für ein paar Dollar irgendwo klicken kann, sind mehr oder weniger an der Tagesordnung und richten auch nur begrenzten Schaden an; oftmals bekommen wir da selbst recht gute Filterungen hin. Manchmal sind Attacken aber auch größer und dann brauchen wir Hilfe. Ein Switch-Port hat 1 GBit/s, ein Port am Router hat 10 GBit/s … und wenn die Attacken noch größer werden, sind wir darauf angewiesen, dass unsere Rechenzentrumsbetreiber hier helfend eingreifen. Das ist heute der Fall. Aber auch deren Mittel sind begrenzt; daraus ergibt sich der Titel dieses Blogposts: DDoS-Attacken sind nichts weiter als ein Straßenkampf um mehr Bandbreite. Wer als Angreifer mehr aufbringen kann als das Opfer zur Verfügung hat oder filtern kann, der hat diesen Kampf gewonnen. Im Moment sind dies die anderen, denn die Bandbreiten, die hier eintreffen, liegen im zweistelligen GBit/s-Bereich.
Oftmals ist nicht erkennbar, gegen wen konkret sich eine Attacke richtet: Trifft eine Flooding-Attacke ein, ist zwar die Ziel-IP offensichtlich, aber da die fragliche IP - typisch für Shared Hosting - durch mehrere User genutzt wird und sich aus Datenpaketen, die einfach nur “die Leitung dichtmachen” sollen, auch keine hilfreichen Informationen entnehmen lassen.
In diesem Fall ist es anders. Einerseits haben wir gestern massive Angriffe auf die IP von uberspace.de verzeichnet, die nicht mit anderen Usern gemeinsam genutzt wird - da ist insofern klar, dass sich die Attacke gegen uns direkt richtet. Zum anderen wird seit heute nacht ca. 2:30 Uhr unser Netzwerk bei rh-tec attackiert, und zwar mit laufend wechselnden Ziel-IPs in unserem dortigen Netz - es wäre insofern nicht plausibel erklärbar, dass sich die Attacke nur gegen einen einzelnen Uberspace richten soll. Wir gehen insofern aus, dass sie uns schaden soll. Was sie auch tut: Wir können aktuell an diesem Standort keine per IPv4 erreichbare Hostingleistung erbringen.
Was kommt da eigentlich rein?
Zu dem Zeitpunkt, als wir den Traffic noch gesehen haben (vor dem Blackholing), zunächst NTP-Reflection:
06:25:24.508066 IP 176.124.144.54.123 > 95.143.172.200.61117: NTPv2, Reserved, length 440
06:25:24.508070 IP 77.76.144.98.123 > 95.143.172.148.39385: NTPv2, Reserved, length 440
06:25:24.508101 IP 92.86.2.190.123 > 95.143.172.200.52185: NTPv2, Reserved, length 440
06:25:24.508103 IP 212.25.98.176.123 > 95.143.172.148.39385: NTPv2, Reserved, length 440
06:25:24.508105 IP 201.57.161.174.123 > 95.143.172.250.30458: NTPv2, Reserved, length 440
06:25:24.508106 IP 109.172.52.118.123 > 95.143.172.200.43091: NTPv2, Reserved, length 440
06:25:24.508108 IP 109.172.52.118.123 > 95.143.172.200.43091: NTPv2, Reserved, length 440
06:25:24.508109 IP 217.100.24.26.123 > 95.143.172.148.39385: NTPv2, Reserved, length 440
06:25:24.508110 IP 217.100.24.26.123 > 95.143.172.148.39385: NTPv2, Reserved, length 440
06:25:24.508112 IP 61.129.131.187.123 > 95.143.172.148.39385: NTPv2, Reserved, length 440`
Im späteren Verlauf dann DNS-Reflection:
09:54:58.743956 IP 202.117.24.24.53 > 95.143.172.148.22363: 49798| 20/0/1 MX stagg.cpsc.gov. 5, MX hormel.cpsc.gov. 5, TXT "v=spf1 ip4:63.74.109.6 ip4:63.74.109.10 ip4:63.74.109.20 mx a:list.cpsc.gov -all", A 63.74.109.2, AAAA 2600:803:240::2, DNSKEY, DNSKEY, DNSKEY, DNSKEY, Type51, RRSIG[|domain]
09:54:58.743958 IP 200.195.62.67.53 > 95.143.172.148.60286: 42559 19/2/1 MX hormel.cpsc.gov. 5, MX stagg.cpsc.gov. 5, RRSIG, RRSIG, TXT "v=spf1 ip4:63.74.109.6 ip4:63.74.109.10 ip4:63.74.109.20 mx a:list.cpsc.gov -all", RRSIG, A 63.74.109.2, RRSIG, AAAA 2600:803:240::2, RRSIG[|domain]
09:54:58.743960 IP 75.110.184.83.53 > 95.143.172.148.34375: 43660| 21/0/0 MX hormel.cpsc.gov. 5, MX stagg.cpsc.gov. 5, TXT "v=spf1 ip4:63.74.109.6 ip4:63.74.109.10 ip4:63.74.109.20 mx a:list.cpsc.gov -all", SOA, RRSIG, RRSIG, RRSIG, RRSIG, RRSIG[|domain]
09:54:58.743967 IP 210.5.151.13.53 > 95.143.172.148.30484: 31046| 23/0/1 RRSIG, DS, DS, DS, DS, MX stagg.cpsc.gov. 5, MX hormel.cpsc.gov. 5, TXT "v=spf1 ip4:63.74.109.6 ip4:63.74.109.10 ip4:63.74.109.20 mx a:list.cpsc.gov -all", A 63.74.109.2, AAAA 2600:803:240::2, DNSKEY, DNSKEY, DNSKEY, DNSKEY[|domain]
09:54:58.743977 IP 210.243.235.66.53 > 95.143.172.148.62919: 31046| 23/0/1 RRSIG, DS, DS, DS, DS, MX hormel.cpsc.gov. 5, MX stagg.cpsc.gov. 5, TXT "v=spf1 ip4:63.74.109.6 ip4:63.74.109.10 ip4:63.74.109.20 mx a:list.cpsc.gov -all", A 63.74.109.2, AAAA 2600:803:240::2, DNSKEY, DNSKEY, DNSKEY, DNSKEY[|domain]
Seit dem Blackholing ist dann nicht mehr erkennbar, was konkret da reinkommt - weil ja nichts mehr reinkommt, also, gar nichts.
Orakelfragen
Es liegt in der Natur der Sache, dass wir in diesem Kontext - primär über Twitter - mit absolut nachvollziehbaren Fragen gelöchert werden: Neben der Frage, warum die eigene Site nicht funktioniert, dürften “Wie lange wird es noch dauern?” und “Wer steckt dahinter?” die nächsten beiden Positionen der Top 3 bekleiden.
Leider gibt es auf beide Fragen keine befriedigenden Antworten. Wir wissen nicht, wer dahinter steckt; wir haben auch keine Drohungen oder gar Zahlungsaufforderungen erhalten. Es würde vermutlich auch nichts ändern, außer potentiell einer theoretischen Strafverfolgbarkeit. Wie lange es noch dauert, ist ebenfalls eine sehr verständliche Frage, die auch uns umtreibt, aber: Es ist nicht so, dass gerade etwas kaputt wäre und repariert werden müsste, wo man irgendwie sagen könnte: Da muss noch eine Platte getauscht werden, dann müssen Backups eingespielt werden, und in n Stunden geht wieder alles. Die ätzende Wahrheit ist: Es wird so lange dauern, wie der Angreifer Lust und Ressourcen hat, gegengerechnet mit möglichen Teil-Lösungen, die rh-tec für uns gebaut bekommt.
Was kann man tun?
Wir möchten in diesem Zusammenhang einmal klarstellen, dass wir uns zwar über die ganzen Tweets freuen, dass wir irgendwas gefiltert bekämen oder dass wir irgendwas in den Griff bekommen hätten (zwischenzeitlich lief nämlich alles für eine Weile wieder, weil die Attacke pausiert war). Euer Lob ehrt uns, aber es gebührt definitiv rh-tec als Rechenzentrum und seiner Technikerbereitschaft, ohne die wir hier schon längst vollkommen aufgeschmissen wären. Wann immer hier dann doch mal ein paar IPv4-Pakete durchkommen, so ist das auf Filterungen und Workarounds von deren Bereitschaftstechnik zurückzuführen, für die wir herzlich Dankeschön sagen wollen.
Wir selbst aber können hier nichts tun, technisch gesehen, außer die Kommunikation mit euch aufrechtzuerhalten und die Kommunikation mit dem Rechenzentrum aufrechtzuerhalten. Die Bandbreite dieser Attacke (es schwirrte hier zwischenzeitlich der Wert von 24 GBit/s durch das Ticket mit dem Rechenzentrum) hat eine Größenordnung, der kaum jemand mehr begegnen kann, der sich nicht speziell für einen solchen Fall gewappnet hat. Rechenzentren, in denen man Racks mietet und Server reinschraubt (so wie wir), sind das in aller Regel nicht: “DDoS-Protection” ist ein Geschäftsfeld für Anbieter, deren Augenmerk darauf liegt, ein globales, verteiles Netz mit enormen Filterkapazitäten zu betreiben, um bestmöglich zu versuchen, guten von bösem Traffic zu unterscheiden und nur den guten zum Ziel durchzulassen. CloudFlare, Akamai, Level 3, Link11, Imperva etc. sind Firmen, die so etwas anbieten. Die Kosten dafür, ein /24 via BGP nicht mehr durch das eigene RZ annoncieren zu lassen, sondern von denen, um den “gewaschenen” Traffic durchzuleiten, sind natürlich stets Verhandlungssache; von einer Region im mittleren vierstelligen Euro-Bereich (monatlich!) kann man allerdings sicherlich ausgehen, ohne allzu sehr daneben zu liegen. Das heißt, nur um da mal eine Relation herzustellen, dass wir mehr für die Filterung des Traffics bezahlen müssten als für den Traffic selbst. Beträge dieser Größenordnung sind für uns jedenfalls derzeit schlicht nicht stemmbar - und selbst ein derart großes DDoS-Filter-Netz aufzubauen ist vollkommen utopisch; dafür sind wir viel zu klein.
Dass wir uns getrieben von Vorfällen wie diesen dennoch nach solchen Lösungen umschauen, dürfte auf der Hand liegen, auch wenn es sich offen gesagt ziemlich falsch anfühlt, eine gute Erreichbarkeit nicht mehr durch “Wir haben viele Peerings mit gut dimensionierten Bandbreiten und haben darunter vor allem auch direkte Peerings zu den Providern, über die der Großteil unserer User zugreift” zu erzielen, sondern mit “Wir geben einem von vielleicht einem Dutzend international relevanter Anbieter megagroßer Filternetze eine stolze Summe Geld, damit er uns vor den Bösen beschützt”: Das hat schon gewisse Züge einer Schutzgelderpressung, womit ich keinesfalls unterstellen möchte, dass die betreffenden Schutzanbieter gleichzeitig auch diejenigen wären, die hinten herum überhaupt erst den Bedarf nach derartigen Lösungen erzeugen; wir gehen da schon davon aus, dass es sich hier in der Breite um seriöse Unternehmen handelt, die sich ausschließlich mit dem Schutz vor Schäden beschäftigen, die andere verantworten. Es gibt hier aber so gesehen noch keine Pro- oder Contra-Entscheidung - und selbst wenn: Die wäre nicht “ad hoc” implementierbar, und wir müssten eben auch schauen, wie wir so etwas finanziert bekämen. Selbstverständlich ist auch für die Branchengrößen im Hosting DDoS-Protection sicherlich nichts, was sich aus der Portokasse finanzieren lässt, aber speziell für einen kleineren Anbieter wie uns wären die Kosten im Verhältnis vermutlich noch schmerzhafter.
Danke!
Wir schätzen sehr, dass uns eurerseits hier durch die Bank weg fast ausschließlich Zuspruch zuteil wird. Das dürfte in dieser Branche alles andere als selbstverständlich sein. Ihr dürft sicher sein, dass ihr damit maßgeblich dazu beitragt, dass wir hier so gut es geht durchhalten und nicht den Kopf verlieren, denn ihr könnt euch sicher vorstellen, dass eine Attacke dieser Größe nicht weniger als “geschäftsbedrohlich” für uns ist - denn machen wir uns nichts vor: Schlichtes Abwarten können wir von niemandem für längere Zeit erwarten; selbst ein privates Blog möchte ja schon gerne irgendwann auch wieder erreichbar sein.
“Es kann der Frömmste nicht in Frieden leben, wenn es dem bösen Nachbarn nicht gefällt”, wie Schiller in “Wilhelm Tell” den Protagonisten so schön sagen lässt. In puncto DDoS trifft das wohl den Nagel auf den Kopf: Das hat dann kaum noch etwas damit zu tun, wie schlau oder robust man seine Infrastruktur gebaut hat, und auch nicht damit, ob man sie ausreichend dimensioniert hat: Wenn es jemand durch Bandbreiten-Überlastungen gezielt darauf anlegt, Schaden anzurichten, kann er das auch tun, denn nicht zuletzt durch Reflection-Attacken sind die Bandbreiten, die Angreifer erzielen können, immens, und dann hilft am Ende nur noch, die Infrastruktur eben jener Dritter zu nutzen, die für die Filterung Systeme aufgebaut haben, die für einen selbst vollkommen unbezahlbar wären. Wir werden sehen, ob sich ein solcher Schritt als unabdingbar oder als vermeidbar herausstellen wird.