© kallejipp, Photocase.com

An der Hochschule Niederrhein realisieren künftige Admins Bausteine einer Spamabwehr, indem sie die Aufmerksamkeit der Viagra-Mafia auf sich ziehen. Heraus kommen standhafte Blocklisten sowie das Wissen, was gegen die Plage hilft.

Ein Projektfach an unserer Hochschule [1] bereitet die Studierenden auf den beruflichen Alltag, auf das Arbeiten im Team und den ganz normalen Wahnsinn vor. Als Teil dieses Wahnsinns sieht das Fach das inflationäre Aufkommen von Spam an, für dessen Bekämpfung verschiedene Methoden existieren. Eine ist die Spam-Blocklist. Zurzeit implementieren und betreiben Studenten der Hochschule eine solche SBL.

Gemäß der Grundidee “Spam mit Spam bekämpfen” richten wir extra IMAP- oder POP-3-Mailkonten ein, die selber keinen Spamschutz besitzen. Als Honeypots sollen sie Spam-Mails einfangen. Um den Spam anzulocken, streuen die Studenten die E-Mail-Adressen der Honeypot-Konten, soweit es irgend geht. Zu diesem Zweck missachten sie alle Regeln zum verantwortungsvollen Umgang mit E-Mail-Adressen und veröffentlichen die Adressen auf eigenen Webseiten, in Social Networks, posten in Test-Newsgroups wie »de.test« und tummeln sich in den dunkelsten Web-Ecken, die sich so finden lassen.

Das Ergebnis ist schon nach kurzer Zeit zufriedenstellend: Die Konten füllen sich mit jeder Menge Spam. Dort einlaufende Mails, so die Aufgabenstellung an die Studenten, soll das Setup zeitnah hinsichtlich ihrer Herkunft (IP-Adresse des absendenden Servers) analysieren und für einen definierten Zeitraum in die Blockliste aufnehmen.

Das Ziel: Empfängt der Mailserver später auf seinen regulären Konten Mails, gleicht er die IP-Adressen der zustellenden Server mit der Blockliste ab. Ist ein Zusteller in der jüngeren Vergangenheit als Spamschleuder in Erscheinung getreten, verweigert er die Annahme der E-Mail (siehe Abbildung 1).

Abbildung 1: Die Aufgabenstellung sieht vor, aus den Spam-Mails der Honeypot-Konten die IP-Adresse des zustellenden Mailservers zu extrahieren und in der Spam-Blockliste abzulegen. Mails, die von einem gelisteten Server kommen, bleiben danach im Filter hängen.

Am Eingang steht gleich die Müllsortier-Anlage

Zu Beginn fragt eine Automatik die IMAP-Konten in regelmäßigen Abständen ab. Aus den Mailheadern extrahieren Routinen die Information, welcher Mailserver den Spam versandt hat. Die relevanten Strings stehen in den »Received«-Zeilen:

Received: from bhixhv (wsip-70-183-106-183.sd.sd.cox.net [70.183.106.183]) by islay.kuehnast.com (Postfix) with ESMTP id B3B1F5D7A3; Tue, 21 Oct 2008 20:17:43 +0200 (CEST)

Hinter der publik gemachten Adresse »islay.kuehnast.com« materialisiert sich einer der Honeypot-Mailserver. Logischerweise ist jeder Host, der ihn mit Mail beliefert, ein Spamversender – oftmals ein Rechner, den die Infektion mit einer Malware zur Drohne eines Botnetzes [2] gemacht hat. Der Name, mit dem sich der Rechner selbst identifiziert, hier »bhixhv«, ist wie in fast jeder Spam-Mail gefälscht.

Der Reverse-Lookup der IP-Adresse, »wsip-70-…« ist nicht interessant, uns reicht die IP. Im Postfix-Log erscheint sie stets in eckigen Klammern und lässt sich deshalb einfach mit einem regulären Ausdruck extrahieren. In derselben Zeile finden wir den Zeitstempel des Mailservers. Er ist relevant für das automatische Verlängern von Einträgen bei Wiederholungstätern oder das automatisierte Entfernen einer IP aus der Liste, wenn in einem definierten Zeitraum kein weiterer Spam von dieser IP einläuft und der Host darum als geläutert gilt.

DNS-Zonen bauen

Technisch gesehen ist die SBL eine DNS-Zone kombiniert mit der DNS-Abfrage, ob ein Server in der SBL enthalten ist oder eben nicht. Darum fügt nun das Setup die ermittelte IP-Adresse zur SBL-Zone unseres DNS hinzu:

183.106.183.70.sbl.hsnr.de IN A 127.0.0.10
IN TXT "Spam from this IP received: 2008-10-21 20.17h"

Da Anfragen an die SBL-Zone per Rückwärtsauflösung (Reverse Lookup) erfolgen, sind die einzelnen Oktette in umgekehrter Reihenfolge eingetragen. Der DNS löst den Namen zur IP »127.0.0.10«-IP auf, das letzte Oktett ».10« im Beispiel ist willkürlich gewählt – Hauptsache größer als die für Loopback reservierte »1«. Unterschiedliche Ziffern an dieser Stelle können als Klassifizierungsmerkmal herhalten, um zum Beispiel auswerten zu können, welcher Honeypot den Eintrag beigesteuert hat.

Der String im TXT-Record landet im Mail-Logfile, wenn der Mailserver aufgrund einer SBL-Anfrage die Annahme einer E-Mail verweigert. Im einfachsten Fall weisen wir unseren Mailserver an, bei einem Treffer auf der SBL die Kommunikation mit dem absendenden Server abzubrechen. Für Postfix sieht die Konfiguration so aus:

smtpd_recipient_restrictions = [Andere_Regeln], reject_rbl_client sbl.hsnr.de, permit

Bei allem Vertrauen in die Arbeitsweise unserer selbst gebauten SBL ist es dennoch keine gute Idee, eine E-Mail allein aufgrund des Listeneintrags abzulehnen.

Mehr Erkenntnisse bitte!

Den umfassenderen Ansatz bieten Werkzeuge wie Policyd-weight [3] für Postfix, die mehrere Kriterien zur Spamerkennung heranziehen. Policyd-weight kann zum Beispiel mehrere SBLs abfragen und auch andere (Header-)Prüfungen durchführen. Aus den Ergebnissen bildet der Policy-Daemon einen Punktwert (Score), vergleicht ihn mit einem konfigurierbaren Schwellenwert und entscheidet, ob die Mail ins Kröpfchen oder Töpfchen gehört.

Listing 1 zeigt eine Policyd-weight-Konfiguration mit drei SBLs. Ist der Schwellenwert beispielsweise auf »8.0« gesetzt, so muss ein Server auf allen drei Listen eingetragen sein, damit Policyd-weight ihn klar als Spammer klassifiziert.

01 ## DNSBL settings
02 @dnsbl_score = (
03 #HOST,                 BAD SCORE,  GOOD SCORE,  LOG NAME
04 'list.dsbl.org'        3.5,        0,           'DSBL_ORG',
05 'ix.dnsbl.manitu.net'  3.5,        0,           'IX_MANITU',
06 'sbl.hsnr.de',         3.5,        0,           'HSNR_DE',
07 );

Alle Waffengattungen

Bei der Implementierung der SBL übrigens ließen wir den Studierenden die freie Wahl der Waffen. Der Variantenreichtum der eingereichten Lösungen entsprach daraufhin auch der alten Weisheit “Zehn Informatiker, elf Lösungen”. Allein bei den Routinen, die die relevanten Daten aus den Honeypot-Mails extrahieren, reicht die Bandbreite von Bash-Skripten über PHP, Dotnet bis C.

Bei den Nameservern hatte Bind 9 wegen seiner einfachen Konfiguration und Plattformvielfalt die Nase vor. Doch auch hier fanden sich Teilnehmer, die volle Kontrolle über den Code haben wollten und sich daran machten, einen Mini-Nameserver mit der gerade notwendigen Funktionalität selbst zu entwickeln.

Im Moment ist das Müllschlucker-Projekt noch nicht ganz abgeschlossen. Was wird den Studenten wohl zum letzten Schritt, Monitoring und Reporting, einfallen? Wir sind ja so gespannt. (jk)