Bereits bei der Zustellung einer E-Mail kann der Admin an mehreren Stellen ansetzen, um Spam zu stoppen. Im besten Fall kann der Mail-Server dabei sicherstellen, dass schon die Kontaktaufnahme fehlschlägt. Im schlechtesten Fall wird die Mail erst als Spam erkannt, wenn sie schon vollständig auf dem Server angekommen ist. Alle Fälle haben aber dennoch das gleiche Resultat: Die Störenfriede gelangen erst gar nicht in die Postfächer der Empfänger.
Allerdings haben verschiedene der zur Verfügung stehenden Maßnahmen auch ihre Nachteile und Seiteneffekte. Ist die Konfiguration des Servers zu streng, landen wahrscheinlich auch legitime Mails im Filter. Das soll natürlich nicht passieren – der Server-Administrator muss seine Reaktionen gut abwägen. Letztlich ist es sicherlich besser, dass ein paar nicht legitime Mails den Server ungefiltert passieren, als dass die User des Mail-Dienstes unter nicht zugestellter Post leiden.
In diesem Workshop wollen wir Ihnen zeigen, welche Mittel Sie der wachsenden Spam-Flut entgegensetzen können. Die im Folgenden vorgestellten Maßnahmen sind nicht alle ohne weiteres einem bestimmten Stadium des Mail-Transfers zuzuordnen. In einer flexiblen und gut angepassten Konfiguration kann die gleiche Prüfmaßnahme durchaus verschiedene Stadien überwachen.
Die Verbindungsaufnahme
Damit eine Mail an einen Mail-Server zugestellt werden kann, horcht dieser auf einem Port und wartet auf eingehende Verbindungen. Will ein entfernter Host eine Mail zustellen, verbindet er sich mit dem Mail-Server über diesen Port.
Nachdem die Verbindung hergestellt wurde, meldet sich der entfernte Host beim Mail-Server mit dem HELO-Kommando. Dabei wird als Parameter im Allgemeinen der Rechnername des entfernten Hosts übergeben. Also etwa „HELO mail.tecchannel.de“. Zu diesem Zeitpunkt stehen also zwei Informationen zur Verfügung. Die IP-Adresse des entfernten Rechners und der angegebene Name.
Daraufhin verwendet der sendende Rechner das MAIL-Kommando. Dieses gibt genauere Informationen darüber, wer der angebliche Absender und wer der gewünschte Empfänger der Mail ist.
Ist das geklärt, wird der Inhalt der Mail übertragen, und der entfernte Rechner beendet die Verbindung zum lokalen Mail-Server. Dem liegen nun alle Informationen über die E-Mail vor. Vor der Zustellung in ein Postfach wird die E-Mail noch nach weiteren Kriterien untersucht.
PTR-Record Lookup bei Verbindungsaufnahme
Direkt bei der Verbindungsaufnahme kann der lokale Mail-Server den PTR-Record des entfernten Rechners mit einem Reverse Lookup prüfen. Wenn die eingehende Adresse zu keinem PTR-Eintrag passt, wäre das Beenden der Verbindung eine Option. Allerdings ist es so, dass dieser Fall relativ häufig auftritt. Beispielsweise versenden oft Rechner E-Mails, die gar nicht zur Domain des eigentlichen Senders gehören.
Liefert der Reverse Lookup also einen Fehler, ist es besser, einen entsprechenden Eintrag im Header der Mail anzulegen und auf diesen Umstand hinzuweisen: Im Mail-Client des Empfängers können dann regelbasierte Mechanismen verwendet werden, um derartige Mails gegebenenfalls auszufiltern.
IP-Sperre und Schwarze Listen
Einige sehr hartnäckige Mail Transfer Agents (MTA) versuchen oft, E-Mails zuzustellen, die man definitiv nicht annehmen möchte. Dabei kann es sich zum Beispiel um bekannte Mail-Server von Marketing-Firmen handeln.
Ist sichergestellt, dass es sich bei diesem unerwünschten MTA um einen mit einer festen IP-Adresse handelt, so können Sie die Rechner gezielt auf Basis der IP-Adresse blockieren. Der Aufbau der Verbindung kommt also gar nicht zustande.
Ähnlich wie die Unterdrückung bekannter IP-Adressen funktioniert auch das Unterdrücken von Verbindungen auf Basis von Blacklist-Servern. Der wesentliche Unterschied ist dabei der, dass die Information über unerwünschte IP-Adressen nicht aus einer Liste des Mail-Administrators stammt, sondern eben aus einem Blacklist-Server.
Blacklist-Server – Chancen und Risiken
Technisch funktioniert dies so, dass der lokale Mail-Server eine DNS-Anfrage mit der IP-Adresse des entfernten Hosts an einen Blacklist-Server sendet. Ist der entfernte Host dem Blacklist-Server bekannt, so handelt es sich um einen unerwünschten Rechner. Passende Verzeichnisse bietet beispielsweise ORDB.org, eine Datenbank aus bekannten Mail-Servern mit Open-Relay – also Servern, die Mails ungeprüft weiterleiten. Andere solche Server werden von Spamhaus.org und Spamcop.net betrieben.
Das Problem bei Blacklist-Servern besteht darin, dass dort leicht einmal ein Server als Spammer eingetragen wird, der eigentlich keiner ist. Letztlich kann dort jedermann beliebige Rechner als Spammer anzeigen – mit dem Resultat, dass ein striktes Blockieren von Rechnern aus Schwarzen Listen fast mit Sicherheit zum Verlust von legitimen Mails führt. Wenn Sie Rechner aus gängigen BL-Servern blockieren, dann werden Sie über kurz oder lang beispielsweise keine Mails von T-Online mehr annehmen, denn deren Mail-Server landen regelmäßig in den Schwarzen Listen. Am Empfang der Mails von T-Online-Kunden kommt man in Deutschland aber meist nicht vorbei.
Sinnvoller als das Blocken der Server ist es daher, einen per Blacklist identifizierten Server im Header der E-Mail speziell zu markieren. Dadurch können zusätzliche Filtermaßnahmen greifen und die E-Mail als möglichen Spam kennzeichnen.
Blocken auf Basis von HELO/Mail
Zu Beginn des Austausches gibt der sendende Server seinen Namen während des HELO-Kommandos bekannt. Allerdings gelten hier keinerlei feste Regeln, in der Praxis ist der übergebene Name tatsächlich oft der Name (oder die Domain) des Servers, teilweise aber nicht. Der Mail-Administrator hat hier zwei Optionen:
Zum einen kann er eine Liste von HELO-Texten mitführen, die zu klar bekannten unerwünschten Hosts gehören. Meldet sich ein Host mit diesem HELO-Text, wird die Verbindung sofort abgebrochen. Hier treten aber dieselben Probleme wie bei der IP-basierten Filterung auf. In eine solche Liste gehören nur solche Hosts, deren HELO-Parameter ganz sicher eindeutig sind.
Zum anderen kann ein Lookup auf die HELO-Domain nicht schaden: Das Resultat des Lookups sollte für eine spätere Auswertung protokolliert werden. Im Zuge dieser Auswertung wird es dann einfacher, neue unerwünschte Hosts zu den bekannten unerwünschten hinzuzufügen. Gleiches gilt für die Auswertung der Absenderdomäne aus dem MAIL-Kommando.
Greylisting - Verzögerte Zustellung
Beim Greylisting-Verfahren wird davon ausgegangen, dass gängige Spammer nur jeweils einen Zustellversuch für eine gegebene Adresse unternehmen. Normale MTAs hingegen unternehmen beim temporären Fehlschlagen eines Zustellversuchs einen weiteren. Beim ersten Zustellversuch mit Greylisting merkt sich der lokale Mail-Server die IP-Adresse des entfernten Hosts, die Absenderadresse und die E-Mail-Adresse des Empfängers. Dann antwortet er mit einer Fehlermeldung, aus der hervorgeht, dass die Mail momentan nicht angenommen werden kann - dass das aber später wieder der Fall sein wird. Meldet sich der Host dann später erneut mit den gleichen Informationen über Absender und Empfänger, so wird die Mail direkt durchgelassen.
Das Verfahren hat zwei Nachteile. E-Mails sollten auf Grund der Folgezustellversuche in der Theorie nicht verloren gehen können – in der Praxis passiert dies aber dennoch. Der Grund dafür ist der, dass eben bei weitem nicht alle Mail Transfer Agents auch tatsächlich Folgeversuche unternehmen. Das kann an einer (Fehl)Konfiguration des MTA oder an einer technisch falschen Implementierung liegen.
Ob dies bei einem gegebenen System tatsächlich auftritt, hängt in erster Linie davon ab, welche anderen Mail-Server mit dem lokalen System kommunizieren wollen. Bevor man das Greylisting dauerhaft einsetzt, sollte also eine ausgiebige Testphase vorausgehen.
Der zweite Nachteil ist der, dass E-Mails länger unterwegs sind. Wann der nächste Zustellversuch stattfindet, ist ausschließlich vom Versender abhängig. Gängig ist zwar ein Rahmen von 15 Minuten, allerdings kann es auch massiv davon abweichen. Die Mail-Zustellung wird also möglicherweise erheblich verlangsamt.
Tarpitting - Zähe Verbindungen
Mit einer Teergrube (Tarpit) verlangsamt der Mail-Admin die Verbindung für einen entfernten Host absichtlich. Die Überlegung dahinter ist, dass Spammer häufig versuchen, ihre Mails an mehrere Empfänger auf dem gleichen Server zuzustellen. Das Tarpitting wird dann so konfiguriert, dass es nur eine bestimmte Anzahl an Empfängern (RCPT) zulässt.
Gibt es darüber hinaus Zustellversuche, wird die Reaktionszeit des lokalen Mail-Servers herabgeschraubt. Dadurch müssen Spam-Versender also warten, bis er weitere Mails abschicken kann. Das Ziel dabei ist, dass die Versender von selbst die Verbindung abbrechen. Mit Tarpitting lässt sich Spam effektiv bekämpfen und gleichzeitig noch Kapazität des Spammers binden.
Ein ähnliches Verfahren ist das „IP Screening“. Dabei wird für eine gegebene IP-Adresse die Zahl der nicht zustellbaren Mails gezählt. Spammer versenden Mails gern an völlig willkürliche Adressen einer Domain. So werden zum Beispiel einfach alle gängigen Vornamen ausprobiert. Mit IP-Screening kann die Verbindung nach einer gewissen Menge unbekannter Empfänger beendet werden. Die IP-Adresse des Senders kann dann zum Beispiel dem Tarpit oder einer Liste von (zumindest für eine gewisse Zeit) blockierten IPs hinzugefügt werden.
Heuristischer Spam-Filter
Diese Filter basieren auf Regeln, auf deren Basis die eingehenden E-Mails untersucht werden. Eine solche Regel kann beispielsweise nach einem bestimmten Wort oder einer Kombination von Buchstaben und Wörtern suchen. Für jede Regel, die erfüllt wird, werden dabei Punkte vergeben. Natürlich gibt es auch Regeln, die zu einem Punkteabzug führen können. E-Mails, die einen gewissen Punktestand überschreiten, gelten als Spam. Die Methode erfordert allerdings Feintuning. Setzt man die Anzahl benötigter Punkte zu niedrig an, erhält man viele falsche Positive - ist der Wert zu hoch, so gelangen viele Spam-Mails durch den Filter.
Am besten geht man bei heuristischen Spam-Filtern so vor, dass man sich für einen mittleren Punktewert für die Spam-Erkennung entschließt und derart erkannte Mails dann entsprechend klar als Spam markiert. Das kann zum Beispiel durch ein Einsortieren der Mail in ein entsprechend markiertes IMAP-Postfach stattfinden, durch eine Änderung der Subject-Zeile oder einen passenden Vermerk im Mail-Header. Die letzten beiden Vorgehensweisen geben dann dem Mail-Client eine Möglichkeit, die Mail beim Empfänger regelbasiert zu sortieren.
Bayesische Filter
Bei der Bayesischen Klassifizierung handelt es sich um einen statistischen Prozess, der E-Mails automatisiert als Spam erkennen kann. Der Filter ist in der Lage, den Prozentsatz der Wahrscheinlichkeit, dass es sich bei einer E-Mail um Spam handelt, festzustellen. Bayesische Filter untersuchen dazu zunächst einen möglichst großen Satz an Dateien, von denen bekannt ist, ob es sich um Spam oder legitime Mail handelt. Diese Mails werden anhand bestimmter Charakteristika statistisch ausgewertet.
Bayesische Filter sind lernfähig, können also ihre statistische Auswertung ständig an die aktuellen Anforderungen anpassen. Erkennt ein Filter eine Mail falsch und wird diese vom Anwender zur manuellen Korrektur verwendet, so verbessert das im Laufe der Zeit die Treffergenauigkeit des Filters. Damit passt sich der Filter an die individuelle E-Mail-Nutzung eines einzelnen Nutzers an. Derzeit bietet eine Kombination aus Bayesischem und heuristischem Filter den besten Schutz vor Spam-Mails.
Content-Filter – Nur im Client sinnvoll
Content-Filter kategorisieren E-Mails anhand bestimmter Begriffe, die in der Datei vorkommen. Allerdings verlangen solche Filter nach einer intensiven Pflege: Sie erzeugen die meisten falschen Positivmeldungen. Gleichzeitig sind sie von Spammern extrem einfach zu umgehen.
Bestes Beispiel ist das Filtern nach dem Begriff „Sex“: Spammer steigen einfach auf „sex“ um, aber der normale Nutzer erhält keine Mails mehr, in denen beispielsweise die bekannte Vorabendserie „Sex and the City“ vorkommt. Content-Filter sollten Sie maximal direkt auf den Clients einsetzen.
HashCash – Rechenleistung als E-Mail-Porto
Bei HashCash handelt es sich um eine Ergänzung zu anderen Spam-Filter-Maßnahmen. Die Idee ist, dass eine ausgehende Mail mit einer zusätzlichen Header-Zeile versehen wird. Diese Header-Zeile enthält den HashCash-Wert. Die Berechnung dieses Werts dauert einen gewissen Zeitraum – nicht so lange, dass es sich störend auf den Versand normaler Nachrichten auswirkt, aber sehr störend für einen Spammer, der so viele E-Mails wie möglich so schnell wie möglich versenden will. HashCash ist also eine Art elektronisches Porto, das in Form von Rechenzeit des Mail-Servers beglichen wird.
Die Überlegung ist nun die, dass Spammer den Aufwand der Hash-Berechnung scheuen werden und Nachrichten ohne HashCash-Header versenden. Besitzt eine eingehende Nachricht diesen Header, handelt es sich mit großer Sicherheit nicht um Spam. Diesen Punkt können dann etwa heuristische Filter einfach berücksichtigen. Dazu muss der Mail-Server, bei dem die Mail eingeht, aber etwas mehr tun, als nur das Vorhandensein des Headers zu prüfen. HashCash funktioniert nur dann, wenn die Authentizität des Headers auf dem eingehenden Mail-Server auch überprüft wird.
Der Einsatz hat keinerlei negative Auswirkungen auf Mail. Beim Versenden von Mail sollte der Mail-Admin daher sicherstellen, dass HashCash-Header generiert werden. So kann sich beispielsweise die weit verbreitete AntiSpam-Engine SpamAssassin darauf einstellen. Diese berücksichtigt das Vorkommen von HashCash-Werten in Mail-Headern bereits seit geraumer Zeit.
SPF – Das Sender Policy Framework
Beim Sender Policy Framework (SPF) handelt es sich um einen Mechanismus, mit dem ein Mail-Server verifizieren kann, ob der versendende Mail-Server autorisiert ist, für die beim MAIL-Kommando angegebene Absenderadresse Mails zu versenden.
Dazu müssen Mail-Administratoren SPF-Records im DNS publizieren. Diese enthalten Angaben darüber, von welchen IP-Adressen Mail für eine gegebene Domain versendet werden darf. Falls Spammer falsche Absenderadressen verwenden, lassen sie sich auf diese Weise leicht ausfindig machen. Sobald der versendende MTA per MAIL-Kommando den Absender angibt, kann der empfangende Mail-Server per SPF-Lookup überprüfen, ob seine Gegenstelle überhaupt die Berechtigung hat, Mails für diese Domäne zu versenden.
Anlaufprobleme
Dabei gibt es aber ein kleines Problem: Damit dies verlässlich funktioniert, müssen möglichst SPF-Records für möglichst viele Domänen vorliegen. Bei großen Anbietern wie Hotmail, eBay oder der Postbank ist das auch der Fall. Andere Anbieter, wie beispielsweise T-Online, haben dies bisher nicht getan.
Das bedeutet aber, dass der SPF-Mechanismus nur teilweise greift. Doch auch mit dem momentan noch eingeschränkten Nutzen ist die Verwendung von SPF auf dem eigenen Mail-Server vorteilhaft. Je mehr Server-Betreiber SPF-Records publizieren, desto dünner wird die Luft für Spammer, die unter falschem Namen auftreten.
DomainKeys - SPF von Yahoo
Bei DomainKeys (auch: DomainKeys Identified Mail, DKIM) handelt es sich um einen Mechanismus von Yahoo, der einen über SPF hinausgehenden Schutz bietet. Dazu erzeugt der Betreiber eines MTA ein private/public Schlüsselpaar. Der öffentliche Teil des Schlüssels wird anschließend im DNS publiziert. Dadurch können empfangende Mail-Server den öffentlichen Schlüssel eines Servers mit DKIM leicht ermitteln.
Der versendende Server signiert nun ausgehende Mails mit seinem privaten Schlüssel. Die Signatur wird dazu einfach im Mail-Header untergebracht. Der empfangende Mail-Server verwendet nun seinerseits den öffentlichen Schlüssel, um anhand der Signatur des „From“-Headers zu entscheiden, ob der versendende Server für den Versand von Mails für die „From“-Domain autorisiert ist. Damit ist in etwa das Gleiche sichergestellt wie mit dem SPF: Der Versand von Mails mit falschen Absenderadressen ist nur noch an Server möglich, die DomainKeys nicht überprüfen – oder dann, wenn die zugehörige Domain keine DomainKeys publiziert hat.
Darüber hinaus bietet DomainKeys aber noch einen weiteren Schutz. Mit dem Verfahren wird nämlich nicht nur der From-Header der Mail signiert, sondern auch der komplette Körper der Mail. Dadurch kann der empfangende Mail-Server sicherstellen, dass der Inhalt der Mail im Verlaufe des Transports nicht verändert wurde.
Fazit
Spam wird auch in Zukunft einen Großteil des weltweiten E-Mail-Verkehrs ausmachen. Zu einfach und zu billig ist es für den Spammer, eine Werbeflut per Mail zu starten. Und selbst wenn nur ein Bruchteil der Angeschriebenen auf die Angebote antwortet, hat es sich bereits gelohnt. Problematisch ist auch, dass immer mehr Phishing-Angriffe als Massen-Mails verschickt werden.
Die von uns vorgestellten Methoden sind dabei sicher nicht das Allheilmittel, um Spam für immer zu stoppen. Aber sie binden kostbare Ressourcen und Rechenzeit des Spammers. Dadurch wird es für ihn teurer, seine Angriffe flächendeckend durchzuführen. Ebenso wichtig wie technische Maßnahmen ist die Benutzerschulung. Wenn die User wissen, wie sie Spam vermeiden können, etwa durch temporäre E-Mail-Accounts, wie sie beispielsweise SpamGourmet anbietet, dann nehmen auch die täglich auftreffenden Müllnachrichten ab. (Thomas Wölfer, tecChannel.de/tö)