Spamhaus DDoS mit DNS Amplification

Spamhaus DDoS mit DNS Amplification

Oliver Kunz
von Oliver Kunz
Lesezeit: 10 Minuten

In der letzten Woche wurde viel über den Angriff auf die in Genf und London lokalisierte Organisation Spamhaus geschrieben. Bei gewissen Schlagzeilen hatte man bereits das Gefühl, die Digitale-Welt geht unter.

Was macht Spamhaus

Spamhaus bietet verschiedene Anti-Spam Blacklist und Whitelist Lösungen an. Es handelt sich um eine international ausgerichtete NPO mit dem Ziel, den Spam-Organisationen das Leben schwer zu machen. In diesem Sinne arbeiten sie auch mit Strafverfolgungsbehörden zusammen und lobbyieren in Regierungen für eine effektive Gesetzessprechung. Gemäss eigenen angaben sind Sie verantwortlich für einen Grossteil des zurückgehaltenen Spams und schützen über 1.7 Mia. Mailboxen.

Wer sind die Gegenspieler

Die Gegenspieler von Spamhaus sind die verantwortlichen der unerwünschten Post. Wir können uns diese als verschiedene Organisationen vorstellen, welche als Interesse haben, so viele Spam-Nachrichten wie möglich in den Mailboxen zu deponieren. Mit jeder erfolgreich deponierten E-Mail können Sie ihren Marktwert, den Marktwert des Produktes und dessen Absatz steigern. Es ist davon auszugehen, dass sie zum wesentlichen auch (oder nur) durch den Produktabsatz finanziert werden. Eine Organisation wie Spamhaus schmälert ihren Gewinn.

Aber nicht nur Spam-Organsisationen landen auf der Blacklist von Anti-Spam Anbietern. Es kann durchaus auch vorkommen, dass Domains und Mailserver von Organisationen auf einer Blacklist landen. Beispielsweise kann dies passieren, wenn ein Unternehmen regelmässige Newsletter im grossen Stil versendet und dies auch an E-Mailadressen, welche über keine Mailbox mehr verfügen. Für Mailhoster sind diese E-Mails lästig. Können sie Mails nicht an eine Mailbox weiterleiten, handelt es sich für sie um Spam. Wird dies an einen Blacklist-Verwalter weitergeleitet, landet man auf einer Blacklist.

Ein anderer, nicht unerheblicher Weg auf eine Blacklist ist der Einkauf von Mailadress-Listen. Beinhaltet diese eine Honeypot-Adresse landet man in der Regel direkt in der Blackliste. Unschön dabei ist, jeder der diese Blacklist verwendet, flaggt diese E-Mail als Spam oder im schlimmsten Fall leitet sie gar nicht in die Mailbox weiter.

Die Problematik und Kritik hinter solchen Blacklists ist, dass es sich im eigentlichen Sinn um ein Zensursystem handelt. Gemäss einem Statement von Spamhaus, haben auch sie selbstverständlich die gesetzlichen Rahmenbedingungen einzuhalten und gegenüber ihren Kunden Rechenschaft abzulegen. Diese würden ungewollte Blockaden kaum im grösseren Stil und über eine längere Zeit goutieren.

Attacke auf Spamhaus

Dies war nicht die erste Attacke, welcher Spamhaus ausgesetzt war (bzw. ist). In 2003 wurde bereits ein grösserer DDoS-Angriff lanciert. Betroffen waren auch andere Anti-Spam Anbieter. Spamhaus hatte diesen Angriff gemäss einem Statement auf ihrer Website relativ unbeschadet überstanden.

Für eine Organisation wie Spamhaus gilt, sie sind ständig einem Angriff oder dem hohen Potential ausgesetzt, dies gehört zu ihrem Business dazu. Umso bemerkenswerter ist die Aufmerksamkeit, die diesem jüngsten Angriff beigemessen wird.

Der Angriff begann am 18. März 2013. Das Spamhaus-Team wandte sich an CloudFlare (ein CDN Anbieter), da ihre Internetanbindung bald überlastet und die Systeme somit offline waren. Durch das Einschalten von CloudFlare kamen die Services von Spamhaus bald wieder online. CloudFlare veröffentlichte daraufhin verschiedene Informationen zum Angriff in ihrem Blog. Die Abbildung 1 stammt von einem System von CloudFlare und stellt das Verkehrsvolumen dar, welches sie über alle Kunden feststellen. Es ist also nicht der gesamte Traffic der Spamhaus-Attacke zuzuschreiben.

CloudFlare registriert ein enorm hohes Datenvolumen (Abbildung 1, Quelle: blog.cloudflare.com)

Angriffe auf Netzinfrastruktur (Abbildung 2, Quelle: blog.cloudflare.com)

Auswirkungen

Aus dem Angriff hat man sicher einiges gelernt. Einerseits, welches Potential in einer DNS Amplification Attack steckt. Andererseits, wie man reagieren und was man verbessern kann.

Das Internet kollabierte jedoch nicht. Ich habe auch von niemandem in der Schweiz gehört, der eine signifikante Verlangsamung des Netzes bemerkt hatte. Die Abbildung 2 zeigt, dass es am London Internet Exchange (LINX) zu einem Drop im Traffic kam, der auf die Attacke zurückführbar wäre. Auswirkungen hatten also vor allem jene, welche über den LINX routen. Anhand der Grafik würde ich dies aber nicht als dramatisch bezeichnen.

DNS Amplification Attack

Eine Amplification Attack zielt darauf ab, mit der eingesetzten Bandbreite eine höhere Bandbreite beim Angriffsziel zu belegen. Als Beispiel nehmen wir an, der Angreifer A kontrolliert ein Botnet mit einem Upstream von 1Gbit/s und möchte aber Verkehr grösser als 1Gbit/s generieren um B zu attackieren. A handelt nach dem Maximalprinzip der Betriebswirtschaftslehre. Sein Ziel: Mit seinen Mitteln möchte er den Output maximieren.

Kriterien

Wie im vorliegenden Fall kann man zwei Kriterien für eine erfolgreiche Amplification Attack identifizieren:

Public DNS-Server

Normalerweise konfiguriert ein ISP seinen DNS-Server so, dass nur Zugriffe aus seinem eigenen Netz beantwortet werden. Es gibt jedoch genügend DNS-Server, welche diese Einschränkung nicht kennen. Sei es da bei der Konfiguration Fehler gemacht wurden, oder dass der Betreiber dies bewusst zulassen möchte. Das Open DNS Resolver Project sammelte über 27 Millionen offene DNS-Server. A nutzt nun diese public (offenen) DNS-Server und sendet vielen von ihnen Anfragen mit einer gespooften Quelladresse von B. Die DNS-Server senden ihre Antwort daraufhin an B zurück und füllen die verfügbare Bandbreite aus.

DNSSEC

Amplification Attacken sind eigentlich nichts Neues. Was jedoch neu ist, ist die Effizienzsteigerung durch die Verwendung von DNS. Dies ist wohl nicht zuletzt der sicherheitsrelevanten Erweiterung DNSSEC zu verdanken. Durch die Verwendung von DNSSEC wurden neue Record Types definiert RRSIG (Resource Record Signature) und DNSKEY beide Enthalten Base64 encodierte Informationen, welche um einiges grösser sind, als die ursprünglichen DNS Records. Je mehr DNSSEC Informationen eine Zone enthält, desto grösser werden die Responses sein. In unserem Beispiel möchte daher A Zonen mit möglichst vielen und vor allem DNSSEC relevanten Einträgen erhalten.

Mögliche Lösung

Amplification Attacken, die seit den 90er Jahren existieren, wird es wohl auch weiterhin geben. Das Problem dahinter ist simpel. Gewisse Protokolle erfüllen einfach die oben genannten Kriterien und sie auf TCP umzustellen würde einen enormer Overhead bedeuten. Konkret auf DNS Amplification bezogen gibt es durchaus einen Ansatz, um gegen diese Vorzugehen.

Es ist kaum vorstellbar, dass die verfügbaren offenen DNS-Server alle diese Funktionalität aufweisen sollten. Vielmehr handelt es sich dabei wohl um Fehlkonfigurationen des DNS-Servers. Aus welchem Grund sollte der DNS-Server einer Firma Anfragen aus fremden Netzwerken verarbeiten? CloudFlare veröffentlichte in einem Blogpost eine Liste mit den von Ihnen am meist gesehenen öffentlichen DNS-Resolvern und einem Konfigurationshinweis für ISC BIND, um diese zu schliessen. Würden also die DNS-Server Betreiber ihre Konfiguration weniger offen gestalten, wäre ein erster und effektiver Schritt gemacht. In Zukunft könnte ein Angreifer nicht mehr auf die DNS Infrastruktur zurückgreifen.

Fazit

Der Vorfall bei Spamhaus hat gezeigt, dass mit der richtigen Methode effizient eine DDoS-Attacke ausgeführt werden kann, ohne ein teures, grosses Botnet zu unterhalten. Der Vorfall hat aber auch gezeigt, dass die Infrastruktur und vor allem die Betreiber einen solchen Angriff ohne grössere Probleme abwenden können.

Dass DDoS Attacken in diesem Ausmass möglich sind, verdanken wir wohl nicht zuletzt der laschen Konfiguration der DNS-Server. Es gibt Lösungen, um das Problem einzudämmen und den Angreiffern in ihren Mitteln zu beschränken. Wir dürfen aber nicht vergessen, dass das Abschalten von Public DNS-Servern auch zu einem Problem führen kann. Der Benutzer ist nicht mehr frei in der Wahl seines DNS-Servers und muss sich auf jenen seines Netzbetreibers verlassen. Fallen diese aus, kann er keine Domainnamen mehr auflösen. In der Regel betreiben die Netzbetreiber diese redundant, was das Risiko des Totalausfalls miniert. Durch das Management des DNS-Servers kann aber auch kontrolliert werden, was die entsprechenden Benutzer seines Dienstes auflösen können. Demzufolge wäre eine Internet-Zensur leichter durchzusetzen.

Über den Autor

Oliver Kunz

Oliver Kunz ist seit 2010 im Bereich der Informationssicherheit aktiv. Hauptsächlich setzt er sich mit Incident Response, Computerforensik und der Sicherheit von mobilen Geräten auseinander.

Links

Sie wollen die Awareness Ihrer Benutzer prüfen?

Lassen Sie durch uns einen Social Engineering Test durchführen!

×
TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Vertrauen und KI

Vertrauen und KI

Marisa Tschopp

Datenverschlüsselung in der Cloud

Datenverschlüsselung in der Cloud

Tomaso Vasella

Cyber Threat Intelligence

Cyber Threat Intelligence

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv