Annahme verweigert Absender-Authentifizierung – die Lösung des Spam-Problems?

Ordnungsmerkmale

erschienen in: <kes> 2004^#3, Seite 19

Zusammenfassung: Welche Methoden rivalisieren bei der zusätzlichen Absender-Authentifizierung zur Spam-Abwehr? Wie wirken sie sich auf die IT-Infrastruktur aus? Ist Spam damit aus der Welt zu schaffen? Diesen Fragen geht der folgende Beitrag nach.

Autor: Von Paul Wood, Gloucester (UK)

Die gängige Gegenwehr gegen den E-Müll sind heute Spam-Filter gepaart mit dezidierten Verhaltensregeln für die Mitarbeiter im Umgang mit E-Mail. Zwar erreichen gut konfigurierte Anti-Spam-Lösungen eine Erfolgsquote von über 95 Prozent. Die Crux für viele IT-Verantwortliche bleibt allerdings nach wie vor das Restrisiko der False-Positives, also fälschlicherweise als Spam klassifizierte, eigentlich aber erwünschte E-Mails. Neue Hoffnung auf Abhilfe schafft das Prinzip der Absender-Authentifizierung: die "Guten" ins Töpfchen, die "Schlechten" müssen draußen bleiben.

Grundsätzlich lassen sich Lösungsansätze zur Absender-Authentifizierung in zwei Kategorien einteilen: clientseitige Kryptographie und serverseitige Authentifizierung. Die Verschlüsselung auf Client-Seite basiert in der Regel auf Ansätzen aus dem Bereich Public Key Infrastructure (PKI) und dient primär der zweifelsfreien Identifizierung einzelner User. Zur Spam-Vermeidung eignen sich solche Lösungen nicht, da die enorme Anzahl der kryptographisch zu prüfenden Zertifikate und Schlüssel – jeweils eines pro Nutzer – zu großen zeitlichen Verzögerungen im Mail-Ablauf führen würde.

Serverseitige Authentifizierungsmechanismen erscheinen hier deutlich vielversprechender, da sie quasi komplementär zur bereits etablierten, typischen E-Mail-Infrastruktur sind und keinerlei Veränderungen am Client erfordern. Sie arbeiten auf Domain-Level, wobei der DNS-Eintrag um zusätzliche Records erweitert wird. Der Grundgedanke dahinter ist bestechend einfach: Wenn Administratoren Mail Exchange (MX) Records veröffentlichen, um die für eingehende Nachrichten zuständigen Mailserver einer Domain öffentlich zu machen, warum soll es dann nicht auch "umgekehrte MX-Records" geben? Diese enthalten eine Liste von Servern, die dazu autorisiert sind, für die jeweilige Domain E-Mails zu versenden.

Die Clients bleiben dabei gänzlich unangetastet, sodass die Pflege der einzelnen User-Identitäten beim zuständigen Administrator liegt, was meist über eine pauschale Autorisierung aller Nutzer des jeweiligen LAN erfolgt. Ist also eine sichere Identifizierung einzelner User erforderlich, so ist serverseitige Authentifizierung nicht die Lösung der Wahl. Geht es jedoch darum, Domain-Spoofing aufzudecken, also den Versuch, Spam unter einem fremden Domain-Namen zu verbreiten, so leistet dieses Prinzip gute Dienste. Drei der zahlreichen derzeit diskutierten Modelle sollen im Folgenden vorgestellt werden.

Pobox.com
Sender Policy Framework

Das Sender Policy Framework (SPF) des US-Internet-Service-Providers Pobox ist die bis dato am weitesten verbreitete Lösung zur Domain-basierten Absender-Authentifizierung [1,2]. SPF funktioniert über die Ergänzung des DNS-Eintrags durch Informationen im DNS-TXT-Format (gem. RFC 1035). Veröffentlicht wird der SPF-Record als Teil des DNS-Objektbaums. Zu seiner Erstellung kann man bequem den SPF Publisher Wizard unter  http://spf.pobox.com/wizard.html verwenden (vgl. Abb. 1).

Abbildung 1: Der SPF Publisher Wizard ermöglicht die einfache Generierung von SPF-Records.

Der Publisher Wizard fragt alle nötigen Informationen schrittweise ab, wobei Domain-Name, IP-Adresse und MX-Server automatisch ermittelt werden und bereits beim Aufrufen des Wizard in der Eingabemaske vermerkt sind. Angaben über Art und Anzahl der autorisierten Outbound-Server, Pointer oder eventuell involvierte Drittanbieter wie ISPs muss der Administrator ergänzen. Der entsprechende einzeilige Code, der dann den DNS-Eintrag ergänzt, wird automatisch generiert.

Die Überprüfung, ob eine eingehende E-Mail tatsächlich von der im Header angegebenen Domain stammt, erfolgt anhand des Sender Envelope, auch Return Path genannt: Über den "ptr"-Mechanismus wird die Pointer-Response verifiziert, um so den Hostnamen des Absender-Clients zu ermitteln. Stimmt die Domain nicht mit dem Header überein, so handelt es sich um eine gespoofte Nachricht, die folglich abgewiesen wird. Um den Verlust wichtiger Nachrichten von nicht SPF-registrierten Absender-Domains zu vermeiden, bietet SPF zusätzlich eine so genannte Best-Guess-Funktion: Das System gibt dann vor, die betreffende Domain hätte sich mit "a/24 mx/24 ptr" registriert und soll so mit großer Wahrscheinlichkeit gefälschte Absender-Adressen aufdecken. AOL evaluiert derzeit die Möglichkeit, Authentifizierung per Sender Policy Framework einzusetzen. Besonders interessant: Pobox verfolgt einen konsequenten Open-Source-Ansatz.

Die Crux von SPF: Die Verifizierung der PTR-Response macht das Umleiten von E-Mails unter Beibehaltung des ursprünglichen Absenders unmöglich, da solches Forwarding auch den Envelope-Sender des ursprünglichen Absenders übernimmt. Wenn nun otto@secumedia.de den Versuch unternimmt, eine Nachricht von susi@messagelabs.de an eine dritte Person weiterzuleiten, so prallen im Postfach dieser Person Absender otto@secumedia.de und Host messagelabs.de aufeinander – und die E-Mail fällt durch das SPF-Raster. Um also sowohl von den Vorteilen des Sender Policy Framework als auch der ganzen Bandbreite an Mail-Funktionalität profitieren zu können, ist MTA-Remailing statt Forwarding erforderlich – ein Vorgang, bei dem der Envelope Sender angepasst wird. Pobox arbeitet derzeit fieberhaft an einem so genannten Sender Rewriting Scheme (SRS), um dieses Problem zu lösen. Zur Überbrückung stehen unter  http://spf.pobox.com hilfreiche Tipps zur Verfügung. Positiv ist zu werten, dass SPF mit der Best-Guess-Funktion keinen reinen Schwarz-Weiß-Ansatz fährt, wobei zu evaluieren bleibt, wie effizient dieser Mechanismus tatsächlich arbeitet.

Microsoft Caller ID

Auch Microsoft hat einen Vorschlag zur Absender-Authentifizierung [3,4]. Caller ID ist das Herzstück der von Bill Gates auf der diesjährigen RSA Conference vorgestellten Coordinated Spam Reduction Initiative (CSRI). Die Authentifizierung erfolgt dabei ebenfalls basierend auf zusätzlichen DNS-Records (hier im XML-Format), die Domain-Namen und IP-Adresse der für ausgehende E-Mails zuständigen Server umfassen. Sind hier Drittanbieter wie beispielsweise ISPs involviert, so ist laut Microsoft der Domain-Name ausreichend, um diesen Dienstleister als autorisierten "Outbound Mail Server" für die betreffende Domain zu qualifizieren. Im Optimalfall hat der Provider seine Caller ID ebenfalls veröffentlicht.

<ep xmlns='http://mx.net/1' testing='true'> 
  <out> 
    <m> 
      <a>192.168.0.101</a> 
    </m> 
  </out> 
</ep>

Ein kurzes Beispiel soll in Abbildung 2 das erforderliche Prozedere veranschaulichen: Die umgebenden <ep>-Tags signalisieren, dass es sich hier um ein so genanntes E-Mail Policy Document handelt. Der Namespace Identifier http://ms.net/1 ist unveränderlich und gibt an, dass dieses E-Mail Policy Document der ersten Version der Caller-ID-Spezifikation entspricht. Sind die Outbound-Server noch nicht zweifelsfrei identifiziert, so empfiehlt Microsoft das Attribut "testing". In diesem Fall reagieren die Empfänger-Systeme so, als wäre keine Caller ID für die Absender-Domain veröffentlicht. Konsequenterweise führt das allerdings auch dazu, dass die Nachricht von strikt nach Caller-ID-Kriterien arbeitenden Empfänger-Servern abgewiesen wird.

<out> fungiert als Container für Policies, die abgehende E-Mails betreffen. Der entsprechende Gegenpart für eingehende Nachrichten spielt für Caller ID keine Rolle. Der untergeordnete Container <m> enthält die Kerninformation, also die zum E-Mail-Versand autorisierten Server der entsprechenden Domain, wobei <a> die zugehörige IP-Adresse angibt. Unterschiedliche Szenarien – von identischen Servern für eingehende und ausgehende Nachrichten bis hin zu Subdomains – für Outbound Server sind im entsprechenden Leitfaden [4] detailliert durchgespielt.

Die Veröffentlichung des E-Mail Policy Document erfolgt in Form eines DNS Text Record mithilfe der üblichen Administrations-Tools, wobei sich Caller ID einer speziellen Subdomain _ep bedient, um so Verwechslungen mit anderen TXT-Records ausschließen zu können. Die Domain example.com würde also entsprechend als _ep.example.com registriert werden. Microsofts hauseigener E-Mail-Dienst Hotmail veröffentlicht die IP-Adressen seiner Server bereits via Caller ID und plant, ab dem Sommer auch eingehende Nachrichten dahingehend zu überprüfen.

Die Wahl von XML könnte sich in diesem Fall als problematisch erweisen. Mail-Server müssen mit einem XML-Parser ausgerüstet sein, um die Authentifizierung via Caller ID bewerkstelligen zu können. Das führt besonders bei hohem Nachrichtenaufkommen zu Performance-Einbußen, da das Überprüfen eingehender E-Mails deutlich mehr Zeit in Anspruch nimmt als dies bei TXT-Records der Fall wäre. Bei kleineren DNS-Servern droht unter Umständen sogar Absturzgefahr. Microsofts Lösungsansatz: Upgrade auf neuere und schnellere Versionen der hauseigenen Server-Software. Die Tatsache, dass Microsoft zudem ein Patent auf Caller ID hat, könnte sich spätestens dann als kostspielig erweisen, wenn die Erhebung von Lizenzgebühren in Erwägung gezogen wird. Ein Open-Source-Ansatz steht derzeit nicht zur Debatte.

Yahoo! DomainKeys

Bei Yahoo! Mail zerbricht man sich derzeit die Köpfe über Domain-Keys als Anwort auf die Bestrebungen der Konkurrenz. Dieser Ansatz ist zwischen clientseitiger Kryptographie und serverseitigen DNS-Lösungen anzusiedeln. Dabei enthält der Header einer ausgehenden E-Mail eine Signatur, die allerdings nicht vom Client, sondern vom Server hinzugefügt wird. Auf Empfängerseite lässt sich dann über den entsprechenden Public Key, der wiederum per DNS erhältlich sein soll, die Authentizität der im Header angegebenen Domain zweifelsfrei identifizieren. DomainKeys muss allerdings durch eine Art Policy Framework, wie beispielsweise SPF oder Caller ID, ergänzt werden, um gesicherte Informationen darüber zu haben, ob eine bestimmte Domain bei jeder Transaktion DomainKeys verwendet oder nicht. Um die Verbreitung von DomainKeys möglichst schnell voranzutreiben, fährt Yahoo! Mail einen Open-Source-Ansatz. Wann Yahoo!-Kunden allerdings mit der Implementierung der hauseigenen Lösung rechnen können, ist bis dato noch unklar.

Yahoo lässt Interessierte derzeit noch ziemlich im Regen stehen. Die Tatsache, dass kaum Veröffentlichungen zum Thema DomainKeys existieren, legt die Vermutung nahe, dass die Lösung weit weniger ausgereift ist als die Alternativen in diesem Bereich. Der Einsatz kryptographischer Methoden könnte sich zudem als problematisch in puncto Performance entpuppen und darüber hinaus das System auch relativ fragil machen. So erfordern beispielsweise bestimmte Gateway-Typen, unter anderem Mailing-Listen, das Umschreiben von Nachrichten, was letztendlich dazu führt, dass die DomainKeys-Signatur ihre Gültigkeit verlieren würde.

Ausweiskontrolle statt Alarmanlage?

Adressen-Spoofing gehört mittlerweile zum "guten" Ton in der Spammer-Community. Absender-Authentifizierung ist definitiv die geeignete Methode, um diese betrügerische Praxis zu vereiteln. Kommt Spam von autorisierten Domains, so können diese leicht identifiziert und durch herkömmliche Blacklists herausgefiltert werden.

Falsch wäre nun allerdings die Schlussfolgerung, dass eine Kombination aus Absender-Authentifizierung und konsequentem Blacklisting die Postfächer künftig sauber halten könnte. Die Erfahrung zeigt, dass Spammer äußerst wendig sind und immer wieder neue Schlupflöcher finden. Registrierte "Wegwerf-Domains" sind nur eine denkbare Möglichkeit.

Bezeichnenderweise warnt selbst Pobox Administratoren vor einer zweiten wahrscheinlichen Variante: Hijacking von autorisierten Domains, die dann als Spam-Relay fungieren können. Die SPF-Company rät zu einer Limitierung des Mail-Ausgangs, was allerdings in der Praxis zum einen detailliertes Wissen über das zu erwartende legitime Mail-Aufkommen voraussetzt und zum anderen einen erhöhten Administrationsaufwand verursacht.

Findige Geschäftsleute unter den "E-Müllern" betreiben zudem bereits heute eine Art von "legalem" Netz aus Spam-Relays, indem sie Nutzer von Always-On-Internetverbindungen im WWW zum Verkauf von nicht genutzter Online-Zeit aufrufen, beispielsweise unter  www.VirtualMDA.com.

Die Trickkiste der Spammer scheint ein Fass ohne Boden zu sein. Selbst wenn wir also davon ausgehen, dass die verschiedenen Ansätze zur serverseitigen Absender-Authentifizierung in absehbarer Zeit den Kinderschuhen entwachsen sind und sich eventuell sogar ein einheitlicher Standard herauskristallisieren könnte, so können diese Mechanismen immer nur eine Ergänzung zu bereits etablierten Anti-Spam-Lösungen sein. Die bloße Existenz von Personalausweisen ersetzt auch keine Alarmanlage.

Paul Wood ist Chief Information Security Analyst bei MessageLabs.

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2004^#3, Seite 19