© photocase.com

Der Überfall eines Spam-Netzes reißt Magazin-Autor Charly Kühnast jäh aus einer sehr sinnvollen Tätigkeit. Sein separater Antispam-Server, der dem Mailserver vorgeschaltet ist, erweist sich als nötiger Luxus.

Ein sonniger Dienstag im Mai. Ich tippe gerade an meiner Sysadmin-Kolumne fürs Linux-Magazin. Es ist etwa 14 Uhr, als ich Seitenblick auf den Monitor riskiere, der ständig die Last- und Trafficdaten meiner wichtigsten Server anzeigt: Dort steigt die Reject-Linie auf dem Mailgraphen des Spamfilters sprunghaft in die Höhe (siehe Abbildung 1). Die Kolumne muss warten.

Abbildung 1: Die Reject-Linie auf dem Mailgraphen des Spamfilters steigt sprunghaft in die Höhe – der Angriff einer kleinen Spam-Armee.

Rejects – der Server lehnt also die Annahme einer großen Menge Mails bereits in einem frühen Stadium des SMTP-Dialogs ab. Ich vermute eine Spam-Welle mit stümperhaft gefälschten Envelopes. Das ist keine Seltenheit: Auf jede erwünschte E-Mail, die bei mir eingeht, kommen zwei Spam-Mails. Trotzdem verbinde ich mich per SSH auf den Spamfilter – der läuft auf einer extra Maschine – und staune nicht schlecht: Ich finde 140 parallele SMTP-Verbindungen vor, Tendenz steigend. Das ist etwa zehnmal mehr als der normale Pegel.

Ungewöhnlich auch, dass der Server die einlaufenden Verbindungen umgehend wieder vor die Tür setzt. Meine entfachte Neugier treibt mich ins Logfile. Wie erwartet kommt jede Mail aus einer anderen Quelle. Die IP-Adressen gehören zu zwei Dritteln Dialup-Providern aus dem europäischen Raum, der Rest grüßt aus den USA und Brasilien. Die Rechner nennen brav ihren vollqualifizierten Namen im »HELO« und scheinen damit nicht einmal zu lügen – das ist ungewöhnlich. Gefälschte HELOs sind bei Spam nämlich der Normalfall.

Die Täter sind selbst Opfer

Ich schnappe mir Nmap und scanne ein paar Ports. Außerdem lasse ich Nmap mit »–osscan-guess« herausfinden, welches Betriebssystem auf den Spam- schleudern läuft. Mich interessiert, ob es sich um offene Relays, gekaperte oder kaputt konfigurierte Mailserver, exploitete Webserver oder einfach um Trojaner-verseuchte Privat-PCs handelt. Nmaps Antwort ist eindeutig: Letzteres. Die untersuchten Maschinen sind sämtlich PCs unter Windows XP, keine ist als Mail- oder Webserver konfiguriert – ich mache also gerade Bekanntschaft mit einem Botnet.

Ein Botnet ist ein Verbund autarker Rechner, die eines gemeinsam haben: Eine Schadsoftware hat sie infiziert, die alle Rechner von zentraler Stelle aus fernsteuert. Die Rechner in einem Botnet werden oft Leafbots oder Zombies genannt. Jeder einzeln relativ harmlos, geraten sie als Masse zur gefährlichen Waffe. Das Botnet, mit dem ich es gerade zu tun habe, scheint zum Glück nur etwa 200 Rechner zu umfassen.

Werbe-Unterbrechung

Zum Weiterschreiben des Linux-Magazin-Manuskripts komme ich trotzdem nicht, denn gerade erhöht sich die Frequenz der eintreffenden Mails. Weil ich die Anzahl gleichzeitiger SMTP-Prozesse limitiert habe, besteht jetzt die Gefahr, dass erwünschte Mails verzögert werden, weil gerade kein Prozess zur Verarbeitung frei ist. Ein Blick auf die Systemauslastung: Der Spamfilter hat noch reichlich Reserven. Ich hebe das Limit auf. Das Botnet gibt alles: Wenige Minuten später liegen 580 parallele SMTP-Verbindungen an (Abbildung 2).

Abbildung 2: Nachdem das SMTP-Limit aufgehoben ist, laufen die Angreifer gegen den Server sturm. »loadavg« ist aber nur um 0,3 – alles in Ordnung.

Ganz und gar nicht in Ordnung ist der sich offenbarende Umstand, dass diese Dinger meinen Greylister überwinden. Das steht in krassem Gegensatz zu meiner bisherigen Erfahrung mit Botnets. Beim Greylisting lehnt der Server eine eingehende Mail zunächst immer mit einem temporären Fehler (»450 please try later«) ab. Beim zweiten Zustellversuch akzeptiert er die Mail dann [1].

Hintergrund: Spambots besitzen normalerweise keine Warteschlange, in die nicht zustellbare Mails temporär wandern, um später ein zweites Mal auf die Reise zu gehen. Offensichtlich ist Greylisting aber inzwischen so verbreitet, dass Spammer sich Gedanken darüber machen, wie diese Hürde zu überwinden ist. Listing 1 zeigt, wie sich das bei mir auswirkt. In Zeile 1 des Logfile-Auszugs verbindet sich ein Bot mit meinem Server. In der dritten Zeile sehe ich an »greylist=update«, dass es bereits der zweite Verbindungsversuch des Bot ist, nachdem mein Server den ersten mit einem temporären Fehler abgelehnt hat.

Recipient Address Verification

Der natürlich beliebig fälschbare Envelope-Sender ist immer der gleiche, nämlich »<>«, also der Null-Sender. Diese Absenderadresse hat für Spammer den Vorteil, dass jeder RFC-konform konfigurierte Mailserver diese Adresse akzeptiert. Außerdem ist eine Reihe von Antispam-Maßnahmen, die auf der Prüfung der Absenderadresse basieren, etwa SAV (Sender Address Verification), beim Null-Sender nutzlos.

Beinahe noch interessanter sind die Empfängeradressen der verteilten Spam-Mails: Sie existieren nämlich nicht, sondern stammen aus dem Vokabular eines ausgestorbenen koptischen Dialekts oder, geringfügig wahrscheinlicher, eines Zufallsgenerators. Hier liegt der Grund, warum der Spamfilter die Mails bereits in den Orkus jagt, noch bevor der SMTP-Dialog beim »DATA«-Kommando angekommen ist. Er führt nämlich eine Empfängerprüfung durch (Recipient Address Verification), das Gegenstück zur erwähnten SAV.

Das Prinzip dieser Empfängerprüfung ist einfach: Wenn der einliefernde Server die Empfängeradresse im »RCPT TO:« preisgibt, schaut der Spamfilter zunächst nach, wohin die Mail zugestellt werden soll, nämlich auf meinen Mailserver (»mail.kuehnast.com« in Zeile 5 von Listing 1). Er baut dorthin einen SMTP-Dialog auf und checkt, welche Antwort er nach dem »RCPT TO:« erhält. Bei meinen Bot-Spielkameraden ist es »user unknown«. Daraufhin lehnt der Spamfilter den weiteren Dialog mit dem Spammer ab (Zeile 7) – das sind die massenhaften Rejects, die ich im Mailgraphen gesehen habe.

01 May 12 04:16:07 spamfilter2 postfix/smtpd[32629]: connect from hcm-ms-185.vnn.vn[203.162.4.185]
02 ...
03 May 12 04:16:07 spamfilter2 policyd: rcpt=598727, greylist=update, host=203.162.4.185 (hcm-ms-185.vnn.vn), from=<>, to=shaynsimo@kuehnast.com, size=5228
04 ...
05 May 12 04:16:07 spamfilter2 postfix/smtpd[29010]: NOQUEUE: reject: RCPT from hcm-ms-185.vnn.vn[203.162.4.185]: 550 <shaynsimo@kuehnast.com>: Recipient address rejected: unverified address: host mail.kuehnast.com[80.190.243.62] said: 550 <shaynsimo@kuehnast.com>:no such user (in reply to RCPT TO command);  from=<> to=<shaynsimo@kuehnast.com> proto=ESMTP helo=<HCM-MS-185.vnn.vn>
06 ...
07 May 12 04:16:07 spamfilter2 postfix/smtpd[32629]: disconnect from hcm-ms-185.vnn.vn[203.162.4.185]

Jetzt wird mir auch klar, warum der Spamfilter noch relativ entspannt ist, obwohl er nach wie vor deutlich über 500 SMTP-Prozesse verkraften muss: Fast keiner dieser Prozesse liefert tatsächlich eine Mail ein, die Empfängerprüfung blockt sie alle schon weit vorher ab. Würde ich, wie noch vor einem Jahr, alle Mails ohne Empfängerprüfung direkt durch Spamassassin pumpen, hätte der Spamfilter heute angesichts der schieren Menge eingehender Mails mit Sicherheit schon Pupillenstillstand. Daher mein Rat an Mailserver-Admins: Recipient Address Verification macht das Leben ereignisärmer.

Abfangjäger von Format

Ich fange ein paar der eingehenden Spam-Mails ab, weil ich jetzt endlich wissen will, was mir da seit Stunden mit solcher Vehemenz in den Spamfilter drückt. Erwartet hatte ich ein wenig Blabla nebst angehängtem Trojaner, vielleicht als Gif oder PDF getarnt. Oder die übliche Werbung für Erektionshilfen, Partydrogen oder Brustvergrößerungen (Bierbauchverkleinerungen waren zu meiner Enttäuschung nie dabei). Was ich finde, ist aber nur Ascii-Schrott.

Das lässt zwei Schlüsse zu: Entweder der Spammer will mich einfach nur ärgern oder er hat Mime nicht verstanden. Ich tippe auf Letzteres und spiele mit dem Gedanken, die Buchstabensuppe durch einen Base64-Decoder zu drehen. Aber so genau will ich gar nicht wissen, was Viagra diese Woche kostet. Ich wende mich lieber wieder dem Log zu und schaue mir an, wie die Mails am Spamfilter abtropfen. Das Manuskript kann ich ja abends fertig schreiben. (jk)