DDOS-Attacke Teil III – Auswirkung und Abhilfe


Letzter Teil der DDOS-Story:

wie gut hat der böse Plan funktioniert und was konnten wir dagegen tun?

Selbstverständlich haben wir unsere Spamfilter nicht abschalten müssen! 🙂 Trotzdem hat die Attacke für etwas Aufregung gesorgt.

Es zeigte sich ein seltsames Bild auf den SecuMail-Servern:
Kaum Maildurchsatz, ein größer immer werdender Mail-Stau aber nahezu keine Last.
Erst nach einigem Grübeln und einem sehr nützlichem Tool namens TCP-Dump, war es uns dann gelungen die Ursache fest zu stellen:
Die Maschinen langweilten sich untätig, während sie vergeblich auf DNS-Antworten der russischen Fake-Domains warteten.
Nach sehr kurzer Zeit waren alle SecuMail-Prozesse auf diese Weise mit „nichts tun“ beschäftigt, so dass kaum noch eMails ausgeliefert werden konnten.


Kann denn eine DNS-Abfrage den kompletten Betrieb aufhalten?

Nein, so einfach ist das nicht möglich. Aber Kleinvieh macht auch Mist und erst recht haufenweise davon!
Was passierte also genau:

Beim Versuch, alle im Mail-Text enthaltenen Linkurls per DNS aufzulösen, haben die SecuMail Prozesse
nie eine Antwort erhalten und nach ca. 3 Sekunden aufgegeben. Wenn jedoch nicht einmal Fehlermeldungen von DNS-Server zurück kommen, wird dieser als „unerreichbar“ eingestuft und anschließend das Glück beim nächsten, im System eingetragenen DNS-Server versucht, was in diesem Falle natürlich ebenfalls keine Aussichten auf Erfolg haben konnte.
In der Regel sind auf unseren Servern drei DNS-Server eingetragen.

~~~
http://keineantwort.russischedomain.ru
http://auchkeineantwort.russischedomain.ru
http://nieantwort.andere-russischedomain.ru
http://stumm.andere-russischedomain.ru
http://sagkeinwort.andere-russischedomain.ru

~~~

Nach Adam Riese wären das insgesamt:
(durchschnittlich) fünf Link-URLs im Text (siehe oben), für die jeweils drei Nameserver mindestens drei Sekunden lang auf DNS-Antworten warten.
Macht ganze 45 Sekunden Wartezeit pro Mail (!). Damit wäre der langsame Maildurchsatz bei geringer Last erklärt.

Wie haben wir dieses Ungemach bekämpft?
Als erste Sofortmaßnahme haben wir die Anzahl der eingetragenen DNS-Server auf einen reduziert und damit die Wartezeit pro Mail
deutlich reduzieren können. Danach wurde es schwieriger weitere Maßnahmen zu finden. Blacklists oder manuelle Domain-Einträge auf unserem DNS-Server scheideten wegen der großen Anzahl an Einträgen, die nötig gewesen wären, aus. Den „Url-Resolver“ komplett zu deaktivieren kam für uns nicht in Frage, da er als wichtiger Bestandteil der Spam-Erkennung kaum entbehrlich ist.

Die Lösung heißt „negative caching“.
Dabei sollen die Ergebnisse der DNS-Abfragen einfach zwischen gespeichert werden, so dass pro Link-Url nur genau einmal abgefragt werden muss. Leider zeigte sich dabei, dass unsere Nameserver (Bind) trotz aktiviertem negative caching nicht in der Lage waren, durch Timeout abgebrochene Anfragen zu cachen. Das chaching funktioniert nur für regulär erhaltene DNS-Antworten, nicht aber, wenn der DNS-Server nicht antwortet.
Es gibt da auf Linux Systemen jedoch noch einen unscheinbaren Dienst namens nscd (Name Service Caching Daemon), welcher bisher kaum jemals unsere Aufmerksamkeit erregt hatte. Und dieser ist auch in der Lage sich eine zeitlang zu merken, ob ein Server überhaupt antwortet. Weil die Menge der im Text verlinkten Urls nicht unendlich groß sein kann, haben sich selbige nach kurzer Zeit fast vollständig in den NSCD-Caches eingefunden und damit einen Scanvorgang in normaler Geschwindigkeit ermöglicht.

Wenig später waren alle eMails in der Warteschlange abgearbeitet. Abgesehen von der verzögerten Auslieferung haben unsere Kunden nichts von alledem mitbekommen.

Fazit:
Die Bekämpfung von Spam bleibt ein mühsames „Katz und Maus Spiel“.
Mit einem flexiblen und offenen Filter-System in der eigenen Hand, das man zeitig anpassen und erweitern kann, ist man allerdings gut für den Kampf gerüstet.

Viele Grüße
Hannes Wilhelm

DDOS-Attacke Teil II – Funktionsweise und Motivation


Zweiter Teil der DDOS-Story:

Wie hat es funktioniert und wofür machen sich die Spamer nur all die Mühe?

Diese Spam-Attacke kam sogar mehrfach „verteilt“ daher:
Unzählige unerwünschte eMails wurden in üblicher Spam Manier an zahlreiche Adressen unserer Kunden versandt. Klar, dass dabei sowohl Absender-Adressen, als auch die IP-Adressen der Absender, ständig wechselten, um ein leichtes Ausfiltern durch SecuMail an dieser Stelle zu verhindern. Bis hierher sollte sich die Angelegenheit noch nicht weiter vom Alltag eines Spamfilters unterscheiden. Außergewöhnlich war allerdings der Inhalt der eMails:
Neben ein paar Zeilen Random-Text enthielt dieser nämlich eine Reihe von HTML-Links, deren Urls auf seltsame Domains zeigten. Diese Urls waren stets nach folgendem Strickmuster aufgebaut: x743h.russische-domain.ru, wobei „x743h“ als scheinbar zufällige Zeichenkombination den unzähligen russischen Domains, angehängt wurde. Natürlich tauchte dabei kaum eine Kombination mehr als einmal auf, was die manuelle Filterung praktisch ausschließt.

Der böse Plan hinter all dem sah vor, dass die Nameserver, auf welchen die russischen Domains gehostet wurden, so eingestellt waren, dass Anfragen auf Sublevel-Domains nie beantwortet wurden. Das bedeutet wiederum, dass jede Anfrage in einem DNS-Timeout endet. Ein guter Spamfilter untersucht jedoch alle Links, die er im eMail-Text findet und prüft, ob diese im DNS aufgelöst werden können oder ob es sich um bekannte Spam-Urls handelt.
Ziel des Plans war also, dass die Filterserver während der Untersuchung der eMails extrem viele DNS-Abfragen tätigen müssen, um sie dabei auch noch möglichst lange hinhalten zu können. Die extreme Häufigkeit dieser Wartezeiten sollte dann für einen Stillstand der eMail-Verarbeitung sorgen.
Auf derartige Ausfälle bei der eMail Zustellung reagieren Administratoren dann in der Regel mit dem kleineren Übel, nämlich mit dem Abschalten der Spam-Filter Funktion. Und damit hätte der Spamer freie und ungebremste Fahrt, direkt in die Postfächer der Adressaten – unserer Kunden!

Ob und wie dieser Plan zum Erfolg führte, erfahren Sie im dritten Teil.

Viele Grüße

Hannes Wilhelm

DDOS – SecuMail und die Distributed-Denial-of-Service-Attacke


Teil I

Anfang Juni dieses Jahres wurden die SecuMail Server – so wie vermutlich alle schlaueren Spamfilter – Opfer einer DDOS Attacke.
Wenngleich sich der entstandene Schaden im Fall SecuMail auf lediglich wenige Stunden mit stark verzögerter Auslieferungszeit beschränkt hat, ist es doch ein interessanter und erwähnenswerter Fall.

Weil ich Ihnen nicht zu viel Stoff auf einmal zumuten möchte, kommt die ganze Story auf drei Einträge verteilt in den „Vernetzte-Welt-Cast“. Dies ist der erste Teil.

Was ist eine DDOS-Attacke überhaupt?
Bei einer sog. Distributed-Denial-Of-Service Attacke (zu deutsch: Verteilter Dienst-Verweigerungs Angriff) wird ein Dienst im Internet von einer Vielzahl anderer, im Netz verteilter Rechner zeitlich koordiniert, mit derart vielen und oder aufwändig zu bearbeitenden Anfragen belastet, so dass er deren Abarbeitung nicht mehr bewältigen kann und damit zwangsläufig auch reguläre Anfragen nicht mehr beantwortet werden können. Auf diese Weise können böse Häcker nahezu beliebige Webpräsenzen oder Web-Dienste zeitweise vom Netz nehmen. Einen einfachen Schutz gibt es nicht.

Genau so etwas ist mit unserem Antispam-Service SecuMail versucht worden.

In den kommenden beiden Teilen beschreibe ich die Funktionsweise und Motivation des Angriffes bzw. die Auswirkung und Gegenmaßnahmen.

Viele Grüße
und bis bald

Hannes Wilhelm