DNS, Mail, DNSxLists und blutige Amateure

It's a maexotic world ...


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


Kein Name, keine Reputation

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.

Comments

    • Posted byknarf
    • on
    Der sendmail wird paranoid mit:

    FEATURE(`require_rdns')

    Das dumme daran ist nur, dass diese Regel vor einem eventuellen smtp/auth abgearbeitet wird. Der Dialup-User mit kaputtem Reverse-Resolving (konkret passiert mit o2 UMTS, 82.113.121.141) kann somit keine E-Mails mehr einliefern. Auf die Schnelle konnte ich keine Loesung finden.

    Darum habe ich require_rdns wieder abgeschaltet. :-(
    Reply
    • Posted byMaex
    • on
    Enduser sollen eh nicht den SMTP auf Port 25 verwenden, sondern mit einem erzwungenen SMTP AUTH auf Port 587 (submission) einliefern. Ich kenne keinen halbwegs aktuellen Mail client, der das nicht unterstützt.
    Ich habe keine Ahnung, ob und wie sich das im sendmail konfigurieren läßt, aber wenn man diese Konfiguration separieren kann, kannst Du für submission das rDNS ausschalten (haben ja dann SMTP AUTH) und für normale SMTP Verbindungen einschalten.
    Mit qmail ist sowas kein Problem, da der SMTP daemon über den tcpserver gestartet wird und für submission einfach ein zweiter tcpserver mit anderer ACL Konfiguration läuft.
    Reply
    • Posted byWolfgang
    • on
    Ganz nett, aber Ich habe selbst mal (m)eine Spamfilterschaltung beschrieben und den Beitrag unter "Homepage" verlinkt. Hiergreife ich auf mehrere Blacklists zu, die weiter ausfiltern. ...

    Vielleicht setzt man auf die Hilfe andere, statt selbst solche Listen mühsam aufzubauen.
    Reply

Add Comment

Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA