DNS, Mail, DNSxLists und blutige Amateure

Letzt' habe ich geholfen einen hoffnungslos mit Spam-Angriffen überrannten Mailserver wieder einigermassen produktiv zu bekommen.

spamassassin und clamav mögen ja nette Tools sein und auch einiges an Spam und Viren oder Malware im allgemeinen wegsortieren, ist aber der Rechner an der Grenze seiner Leistungsfähigkeit angekommen, muß man (sollte man eigentlich immer) viel früher anfangen diesen Müll abzuweisen. Dies hat zudem den großen Vorteil, dass man Backscatter vermeidet, weil die Spam-Zombies keine NDNs generieren.

Reputation ist alles

Einer der ersten Schritte, den ich diesbezüglich immer gehe ist, dass ich alle Verbindungen sofort abbrechen lasse, wenn sie von Rechnern kommen, die keinen Eintrag im reverse DNS haben.
Ein anständiger und von verantwortungsvollen Admins verwalteter Mailserver wird einen korrekten Eintrag im DNS haben. Wenn - aus welchen Gründen auch immer - das nicht so ist, dann ist das nicht der Fehler der Empfänger, sondern der der Admins des Versenders und nicht die Empfänger müssen dafür geradestehen und trotzdem versuchen es irgendwie noch hinzubiegen. Dies gilt umso mehr, wenn sie dabei in Kauf nehmen müssten, dass sie auch von 100 Millionen Zombies Mail annehmen, nur weil die Admins der Versender es nicht raffen.
Das hat schon mal 30-50% der Angreifer ausgeschaltet, einen Großteil der Last vom Rechner genommen und bringt connection slots, weil diese Verbindungen nicht mehrere Sekunden oder gar Minuten eine SMTP-Verbindung blockieren.

Verbinden Sie sich mit Ihrem guten Namen

Nachdem alle Verbindungen mit namenlosen Hosts unterbunden sind, sortiert man 08/15 Namen aus (sprich Zombies hinter DSL/broadband, für die der ISP einen Namen eingetragen hat).
Da im allgemeinen der ISP einen Überblick darüber hat wie er die ihm zugeteilten Adressen/Netzbereiche verwendet, ist die Klassifizierung über Namen prinzipiell einer Klassifizierung über reine IP-Adreßbereiche vorzuziehen. Manchmal ist dies auch recht angenehm und schnell gemacht, wenn der ISP bei der Namensgebung mitspielt und eine entsprechende Hierarchie verwendet:

.dynamic.163data.com.cn
.broadband.corbina.ru
.dynamic.jazztel.es
.dsl-dynamic.vsi.ru
.dial.nortenet.pt
.pppoe.avangard-dsl.ru

Hier haben die Admins verstanden, wie DNS funktioniert: hierarchisch und von rechts nach links. Derartige Domains kann man leicht sowohl in lokalen Konfigurationen als auch in DNSBLs konfigurieren und das matching geht schnell und unkompliziert. Natürlich will man nicht nur Blacklists, sondern (z.B. im Falle von greylisting) auch Whitelists haben, und auch hier gibt es positive Beispiele:

.mail.uk.clara.net
.mail.kks.yahoo.co.jp
.mail.interoute.net
.mail.uu.net
.mail.gandi.net

Auf diese Art und Weise kann man mit einem einzelnen Eintrag eine ganze Reihe von Mailservern freischalten. Ja, ACLs nach Namen sind unsicher, es sei denn man verwendet ein "paranoid" setting.

Die "blutigen Amateure"

Neben obigen positiven Beispielen, gibt es auch jede Menge Beispiel dafür, dass offensichtlich die Leute nicht kapiert haben, wie DNS funktioniert. Interessanterweise sind auch jede Menge "Checker-Firmen" darunter, von denen man das eher nicht erwartet. Hier einige Beispiele:

mail-yw0-f147.google.com
mail-bw0-f206.google.com
outbound-mail-49.bluehost.com
mail22.infracom.nl

static-nnn-nnn-nnn-nnn.netcologne.de
ip-95-223-70-58.unitymediagroup.de
ppp-77-234-231-97.dsidata.sk
rev.193.226.199.13.euroweb.hu
host219-46-dynamic.21-87-r.retail.telecomitalia.it

Die haben es alle nicht kapiert. Entweder es gibt gar keine Hierarchie oder sie drehen innerhalb ihrer Domain die Hierarchie um von links nach rechts. Zur Verdeutlichung wollen wir einmal zwei Namen gegenüberstellen:

static-<a>-<b>-<c>-<d>.example.com
sys-<n>.example.com

Beides sind Namen von Rechnern, die Verbindungen per SMTP aufbauen. Das eine ist ein Kundensystem, das Spam verteilt, das andere ein (interner) Mailserver.
An dieser Stelle sollte ich wohl explizit erwähnen, dass dies exemplarisch ist und das erste von hunderten von Beispielen, die ich gefunden habe. Es geht nicht darum irgendwen im speziellen zu "bashen".
Der gemeinsame Domainanteil dieser Hosts ist .example.com. Damit wird das Problem deutlich. Will man nicht mit kompliziertem pattern matching arbeiten, sondern einfache RTL-Hierarchien verwenden, hat man hier verloren. Dies gilt im speziellen auch für DNS{B,W}Lists.

Und bevor jetzt jemand kommt und sagt: "Ich will aber lieber mail22 tippen als h22.mail!" - dann tragt euch doch einen CNAME ein oder verwendet Host und Hostname für die ssh.