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