DDOS: Massiver Angriff auf dyn.com beeinträchtigt Github, Twitter, Spotify, Reddit, Amazon und viele mehr
Der DDOS-Angriff betraf große Teile in der USA, Deutschland war wohl nicht davon betroffen.
Aktuell ist die Störung behoben, aber der Blogger Brian Krebs schreibt, dass in den vergangenen Tagen bei zahlreichen Webseitenbetreibern Drohmails eingegangen seien, die Bitcoin einforderten und andernfalls mit einem DDOS-Angriff drohten.
Na super.
Hier die Status-Seite bei dyn.com:
https://www.dynstatus.com
Update: Hier eine Karte mit den DDOS-Beeinträchtigungen zwischen dem 20. und 21.10.2016 in den USA vom Provider Level3
http://www.golem.de/news/ddos-massiver-angriff-auf-dyndns-beeintraechti ...
Aktuell ist die Störung behoben, aber der Blogger Brian Krebs schreibt, dass in den vergangenen Tagen bei zahlreichen Webseitenbetreibern Drohmails eingegangen seien, die Bitcoin einforderten und andernfalls mit einem DDOS-Angriff drohten.
Na super.
Hier die Status-Seite bei dyn.com:
https://www.dynstatus.com
Update: Hier eine Karte mit den DDOS-Beeinträchtigungen zwischen dem 20. und 21.10.2016 in den USA vom Provider Level3
http://www.golem.de/news/ddos-massiver-angriff-auf-dyndns-beeintraechti ...
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 318715
Url: https://administrator.de/forum/ddos-massiver-angriff-auf-dyn-com-beeintraechtigt-github-twitter-spotify-reddit-amazon-und-viele-mehr-318715.html
Ausgedruckt am: 04.04.2025 um 01:04 Uhr
5 Kommentare
Neuester Kommentar
Abend,
Eine der witzigen Dinge an diesem Abend: https://twitter.com/degree9io/status/789590071049490432
Heute hatte das Internet in jedem Fall mal wieder Spaß ;) und naja, dass Deutschland nicht betroffen war, würde ich so nicht sagen. Nur eben nicht so massiv ;)
Es gibt einfach gute Gründe diverse alternative Infrastruktur herumstehen zu haben. Erschreckend ist eigentlich, dass so viele Dienste dann doch auf so wenig DNS angewiesen sind. Ich hätte zumindest erwartet, dass bei Anbietern wie GitHub oder Twitter mehr als ein Dienstleister den Kopf für DNS hinhält und somit nur jeder X Request untergeht. Dem ist ja scheinbar nicht so. Und selbst Amazon... Als einer der größten Cloudanbieter. Ist mir irgendwie nicht ganz verständlich warum diese so stark von Dyn abhängen sollen. Zumal zumindest für Amazon die Skalierung der Dienste nun wirklich kein Problem darstellen sollte.
Gruß
Chris
Eine der witzigen Dinge an diesem Abend: https://twitter.com/degree9io/status/789590071049490432
Heute hatte das Internet in jedem Fall mal wieder Spaß ;) und naja, dass Deutschland nicht betroffen war, würde ich so nicht sagen. Nur eben nicht so massiv ;)
Es gibt einfach gute Gründe diverse alternative Infrastruktur herumstehen zu haben. Erschreckend ist eigentlich, dass so viele Dienste dann doch auf so wenig DNS angewiesen sind. Ich hätte zumindest erwartet, dass bei Anbietern wie GitHub oder Twitter mehr als ein Dienstleister den Kopf für DNS hinhält und somit nur jeder X Request untergeht. Dem ist ja scheinbar nicht so. Und selbst Amazon... Als einer der größten Cloudanbieter. Ist mir irgendwie nicht ganz verständlich warum diese so stark von Dyn abhängen sollen. Zumal zumindest für Amazon die Skalierung der Dienste nun wirklich kein Problem darstellen sollte.
Gruß
Chris
Amazon hat immerhin zusätzliche DNS-Server zu denen von Dyn:
Aber - und jetzt kommt etwas was man vielleicht zukünftig im Hinterkopf behalten will - während mein eigener DNS-Resolver zu Hause auf der Firewall, die der Telekom und die Resolver in den Rechenzentren meiner Server weiterhin problemlos die betroffenen Zonen wie amazon.de oder twitter.com auflösen konnten, bekam ich von dem Google-DNS 8.8.8.8 erstaunlich häufig nur noch SERVFAIL zurück.
Das liegt eventuell an der Strategie von Google, möglichst wenig Queries für abgelaufene Einträge zu verwenden statt schrotflintenartig Anfragen an alle verknüpften Nameserver zu schicken und die schnellsten Antworten zu nehmen.
Google minimiert damit zwar den Angriffsvektor für Cache-Poisoning, aber die Zuverlässigkeit des Resolvers sinkt dabei tragischerweise auch.
Und ich persönlich finde, dass zufällige Source-IPs, zufällige Source-Ports, zufälliges Casing und zufällige Query-IDs in Kombination bereits effektiv genug gegen Cache-Poisoning wirken
;; ANSWER SECTION:
amazon.de. 600 IN NS ns1.p31.dynect.net.
amazon.de. 600 IN NS ns4.p31.dynect.net.
amazon.de. 600 IN NS ns2.p31.dynect.net.
amazon.de. 600 IN NS pdns6.ultradns.co.uk.
amazon.de. 600 IN NS pdns1.ultradns.net.
amazon.de. 600 IN NS ns3.p31.dynect.net.
Aber - und jetzt kommt etwas was man vielleicht zukünftig im Hinterkopf behalten will - während mein eigener DNS-Resolver zu Hause auf der Firewall, die der Telekom und die Resolver in den Rechenzentren meiner Server weiterhin problemlos die betroffenen Zonen wie amazon.de oder twitter.com auflösen konnten, bekam ich von dem Google-DNS 8.8.8.8 erstaunlich häufig nur noch SERVFAIL zurück.
Das liegt eventuell an der Strategie von Google, möglichst wenig Queries für abgelaufene Einträge zu verwenden statt schrotflintenartig Anfragen an alle verknüpften Nameserver zu schicken und die schnellsten Antworten zu nehmen.
Google minimiert damit zwar den Angriffsvektor für Cache-Poisoning, aber die Zuverlässigkeit des Resolvers sinkt dabei tragischerweise auch.
Und ich persönlich finde, dass zufällige Source-IPs, zufällige Source-Ports, zufälliges Casing und zufällige Query-IDs in Kombination bereits effektiv genug gegen Cache-Poisoning wirken