[Netzwelt] Massiver DDoS auf DynDNS

Seit nunmehr rund 8 Stunden läuft ein groß angelegter DDoS-Angriff auf die Infrastruktur des DNS-Dienstleisters DynDNS.

Von der Attacke betroffen sind neben Github und Amazon inzwischen auch Dienste wie PayPal, Netflix, Spotify, Twitter und das Playstation Network. Der erste Angriff auf die Infrastruktur begann laut DynDNS gegen 11:10 UTC und wurde gegen 13:20 UTC abgewehrt. Seit 15:52 UTC läuft nun ein zweiter, offensichtlich noch größerer, Angriff auf die DNS-Infrastruktur des Dienstleisters.

Brian Krebs, der vor kurzer Zeit mit einer ähnlich heftigen DDoS-Attacke konfrontiert wurde, vermutet, dass der Angriff im Zusammenhang mit einem Vortrag über DDoS-Attacken von Doug Madory, einem DYN-Mitarbeiter, steht. Krebs vermutet außerdem, dass die Attacke erneut von einem IoT-Botnet, dem Mirai-Botnet, ausgeht.

Der Angriff stört aktuell die Erreichbarkeit vieler Dienste auf globaler Ebene. Eine Besserung oder Lösung des Problems ist aktuell offenbar nicht in Sicht.

 

[theSplit]

Mal eine Frage, kann man derartigen Angriffen von IoT Geräten mit fixen IPs nicht einfach entgegenwirken, glaube ich.

Laut dem verlinkten Mirai Release wird der Code nur in den Speicher von IoT Geräten geladen und kann nach Plug out, Plug in wieder alles (bis zur neuen Infizierung) normal in Betrieb genommen werden.

Jetzt frage ich mich aber warum dies so ein Problem ist.... wenn 1000 Anfragen von einer IP kommen, sagen wir innerhalb von 10 Minuten - auf eine DNS Adresse, wäre dies doch ein Zeichen das jemand darauf "hämmert", oder nicht?
Dann könnte man doch Anfragen dieser IP gar nicht mehr beantworten und die Pakete einfach "droppen", nicht² und die Anfrage einfach ins Leere laufen lassen?

Oder es muß sich Knoten/Sender X als solcher identifizieren und als "berechtigt" für die "Befeuerung" authentifizieren, alle 100 Anfragen, dann wird diese und die folgenden nicht geblockt. IoT Geräte haben ja keine Intelligenz im eigentlichen Sinne, oder? - So das man diese auch nicht künstlich solche "Anfragen" anwenden lassen kann, würde ich jetzt einfach mal vermuten.

Geht so etwas nicht?

 

[Gelöschtes Mitglied 1550]

Ich denke, dass das etwas zu einfach gedacht ist - mangels Erfahrung mit solchen Größenordnungen. Laut der ersten Analyse des Angriffs vom Betroffenen selbst, handelte es sich nicht nur um "ein paar" IP-Adressen, die geblockt werden müssen.

At this point we know this was a sophisticated, highly distributed attack involving 10s of millions of IP addresses.

Die IP-Adressen müssen entsprechend auch zuerst akzeptiert, analysiert und dann weitergeleitet oder verworfen werden - ich behaupte einfach mal, dass dafür kein einfacher Managed Switch reicht, der das übernimmt. Je nachdem, wie viele Geräte mit eindeutigen IP-Adressen das sind, die da angreifen, benötigt das schon einiges an Bandbreite und Rechenleistung.

Brian Krebs hat nach der Attacke auf seinen Blog, die bei ~620 Gbit/s lag und vor der Akamai "kapituliert" hat (aus Kostengründen, sie haben Krebs den Schutz kostenlos angeboten, was nicht mehr zu finanzieren war), geschätzt, dass ein DDoS-Schutz, der seinen Blog vor solchen Attacken schützen könnte, rund 200.000 USD im Jahr kosten würde.

In an interview with The Boston Globe, Akamai executives said the attack — if sustained — likely would have cost the company millions of dollars. In the hours and days following my site going offline, I spoke with multiple DDoS mitigation firms. One offered to host KrebsOnSecurity for two weeks at no charge, but after that they said the same kind of protection I had under Akamai would cost between $150,000 and $200,000 per year.

Kurz: das sind einfach keine Attacken, die wir bisher kannten und sie kamen dank Internet of Shit ziemlich flott auf solche Größenordnungen - die Anti-DDoS-Anbieter sind da, würde ich behaupten, einfach nicht hinterher gekommen.

Laut dem verlinkten Mirai Release wird der Code nur in den Speicher von IoT Geräten geladen und kann nach Plug out, Plug in wieder alles (bis zur neuen Infizierung) normal in Betrieb genommen werden.

Jo, das ist in der aktuellen Version wohl so - die Frage ist allerdings, ob und wie viele Besitzer solcher Geräte die Infizierung und damit die Teilnahme am Botnet überhaupt mitbekommen haben; ich glaube nicht, dass das wirklich viele Leute waren.

Davon ab bleibt die Lücke natürlich weiterhin offen - turning it off and on again und Mirai ist wieder drauf und feuert lustig weiter.

 

[theSplit]

Mal anders gefragt, wenn du da etwas insights hast, was wären Gegenmaßnahmen die man zum Beispiel auf:
1) Webserver
2) Netzwerkknoten die Anfrage ja Routen könnten oder auch nicht.... (Reichenweiten von Paketen innerhalb von Netzwerkregionen bestimmter Geräte? / Lebenszeit von Paketen?)
3) Router (Echoing, PING-Response....?)

anwenden könnte um derartiges zu verhinden?

Reicht es nicht wenn ein Gerät sich Tod stellt und einfach eingehende Anfragen nicht bearbeitet so lange diese nicht mit einer besonderen zufälligen, 30 Sekunden, gültigen Schlüsselsequenz zusammen gesendet wird?

Ist vielleicht etwas naiv, aber würde mich man interessieren wie man etwas sonst "dumm" genug aber für Wartung/Nutzung erreichbar halten kann, ohne das sich das Gerät outet bzw. blind ein Echo wirft.... bzw. was auch nicht so einfach zu faken ist, vielleicht ein Request der mit einem Zeitstempel belastet ist und einer Schlüsselsequenz, welcher durch die Timestamp rückgeneriert werden kann um etwas aufzuschließen? Oder so etwas....

 

[JohnDoe]

Wir sehen jetzt auch die politische Diskussion die das z.B. hier in Deutschland auslöst... oh wait. Wir müssen leider noch warten, bis das ein oder andere Wasserkraftwerk o.ä. seinen Dienst einstellt. Oder Belgien. "Drüben" juckt halt immer noch niemanden, Internet ist immer noch Neuland 'gehört mir (Deutschland) nicht, hab ich nichts mit zu tun', bis auf einmal im eigenen Sandkasten einer weint.

Auch wenn öffentlich nicht so viel darüber diskutiert wird, so wird das Thema an den entsprechenden Stellen (z.B. BSI) durchaus ernst genommen und genau beobachtet beziehungsweise gerade überlegt, was man den politischen Entscheidungsträgern als Brocken hinwerfen könnte, damit da eine sinnvolle Diskussion mit eventuell sogar brauchbaren politischen oder regulatorischen Lösungen entstehen kann.

Davon ab bleibt die Lücke natürlich weiterhin offen - turning it off and on again und Mirai ist wieder drauf und feuert lustig weiter.

Ich bekomme beruflich ein bisschen was mit in der Hinsicht - momentaner Stand ist 23 Sekunden, bis es zu einer Neuinfektion kommt. Regelmässige Neustarts sind also, leider, reichlich witzlos.

-- ZUSAMMENGEKÜRZT --

Alle deine Ideen setzen voraus, dass diese Schutzmechanismen implementiert sind. Und das sind sie nicht. Sicherheit war bei der Entwicklung des Internet-of-Shit leider, leider, leider niemals ein Kriterium, welches beachtet wurde.

Weil du filtern auf Netzwerklevel angesprochen hast, etwas in der Art gibt es eigentlich schon, siehe BCP38. Das Problem ist leider nur, dass das - vor allem von kleineren Providern oder Unternehmen mit eigenen Netzblöcken - nur sehr langsam implementiert wird.

 

[theSplit]

Weil du filtern auf Netzwerklevel angesprochen hast, etwas in der Art gibt es eigentlich schon, siehe BCP38. Das Problem ist leider nur, dass das - vor allem von kleineren Providern oder Unternehmen mit eigenen Netzblöcken - nur sehr langsam implementiert wird.

Wäre jetzt meine spontane Idee gewesen - ich halte das nicht für Perfekt

Aber zumindest wäre das ein Ansatz, auch wenn das Internet durch Lebenszeiten von Paketen, innerhalb des Adressraumes eingeschränkt wäre und sich nur auf den eigenen "Paketraum" beschränken könnte" - aber das Routing muß dem dann ja nicht mehr folge leisten, sprechen wir hier von Knoten die den Traffic weiterleiten.

Ich wüßte, als Entwickler, auch spontan nicht wie ich derartige Richtlinien implementieren muß. Das ist schon Low-Level - und alle sind es API und Lib Nutzer (dazu gehöre ich leider auch)...
Warum auch das Rad neu erfinden, ist ja eh schon "alles" da. Sicherheit, Integrität oder was auch immer, warum auch? Kostet nur Zeit, Nerven und Ressourcen.