Vor zwanzig Jahren veröffentlichte Paul Vixie eine Aufforderung zu Kommentaren zur Ablehnung von MAIL FROM, das die Internet-Gemeinschaft dazu anspornte, mit dem Sender Policy Framework (SPF) eine neue Methode zur Bekämpfung von Spam zu entwickeln. Damals wie heute besteht das Problem darin, dass das Simple Mail Transfer Protocol (SMTP), das für den E-Mail-Versand im Internet verwendet wird, keine Möglichkeit bietet, gefälschte Absenderdomänen zu erkennen.

Bei der Verwendung von SPF können Domäneninhaber jedoch DNS-Einträge veröffentlichen, in denen die IP-Adressen festgelegt sind, die ihren Domänennamen für den E-Mail-Versand verwenden dürfen. Auf der Empfängerseite kann ein E-Mail-Server die SPF-Einträge der scheinbaren Absenderdomäne abfragen, um zu prüfen, ob die IP-Adresse des Absenders berechtigt ist, E-Mails im Namen dieser Domäne zu versenden.

SMTP E-Mail und SPF Übersicht

Leser, die mit den Mechanismen des SMTP-Nachrichtenversands und der Interaktion von SPF mit diesen Mechanismen vertraut sind, werden diesen Abschnitt vielleicht lieber überspringen, obwohl er erfreulich kurz ist.

Stellen Sie sich vor, dass Alice von example.com eine E-Mail-Nachricht an Bob von example.org senden möchte. Ohne SPF würden die E-Mail-Server von Alice und Bob eine SMTP-Konversation wie die folgende abwickeln, die durch die Verwendung von HELO anstelle von EHLO vereinfacht wird, aber die grundlegenden Konstrukte nicht wesentlich verändert: 

Das Senden und Empfangen von Internet-E-Mails (SMTP) läuft seit den frühen 1980er Jahren auf diese Weise ab, hat aber - zumindest nach den Standards des heutigen Internets - ein großes Problem. Im obigen Diagramm könnte sich Chad von example.net genauso gut mit dem SMTP-Server von example.org verbinden, genau die gleiche SMTP-Konversation führen und eine E-Mail-Nachricht, die angeblich von Alice von example.com stammt, an Bob von example.org zustellen lassen. Schlimmer noch, es gäbe nichts, was Bob auf die Täuschung hinweisen würde, außer vielleicht IP-Adressen, die zusammen mit den Hostnamen in den diagnostischen Headern der Nachrichten aufgezeichnet sind (hier nicht gezeigt), aber diese sind für Nicht-Experten nicht leicht zu überprüfen und, je nach E-Mail-Client-Anwendung, oft schwer zugänglich.

In den Anfängen des E-Mail-Spam wurde dies zwar nicht missbraucht, doch als sich das massenhafte Versenden von Spam zu einem etablierten, wenn auch zu Recht verachteten Geschäftsmodell entwickelte, wurden solche E-Mail-Fälschungstechniken weithin eingesetzt, um die Chancen zu erhöhen, dass Spam-Nachrichten gelesen und Inhalte darin geöffnet werden.

Zurück zu dem hypothetischen Chad bei example.net, der diese Nachricht "von" Alice sendet... Das würde zwei Ebenen der Imitation (oder Fälschung) beinhalten, bei denen viele Leute nun der Meinung sind, dass automatisierte, technische Kontrollen durchgeführt werden können oder sollten, um solche gefälschten E-Mail-Nachrichten zu erkennen und zu blockieren. Die erste ist auf der Ebene des SMTP-Umschlags und die zweite auf der Ebene des Nachrichtenkopfes. SPF bietet Überprüfungen auf der Ebene des SMTP-Envelope, und spätere Protokolle zur Fälschungssicherheit und Nachrichtenauthentifizierung wie DKIM und DMARC bieten Überprüfungen auf der Ebene des Headers der Nachricht.

Funktioniert SPF? 

Einer im Jahr 2022 veröffentlichten Studie zufolge hatten rund 32 % der 1,5 Milliarden untersuchten Domänen SPF-Einträge. Von diesen hatten 7,7 % eine ungültige Syntax und 1 % verwendeten den veralteten PTR-Eintrag, der IP-Adressen auf Domänennamen verweist. Die Umsetzung von SPF war also eher langsam und mangelhaft, was zu einer weiteren Frage führen könnte: Wie viele Domänen haben zu "lockere" SPF-Einträge?

Jüngste Untersuchungen haben ergeben, dass allein 264 Organisationen in Australien ausnutzbare IP-Adressen in ihren SPF-Einträgen haben und damit unwissentlich die Voraussetzungen für groß angelegte Spam- und Phishing-Kampagnen schaffen könnten. Ich hatte zwar nichts mit den Ergebnissen dieser Untersuchung zu tun, aber ich hatte vor kurzem selbst mit potenziell gefährlichen E-Mails zu tun, die falsch konfigurierte SPF-Einträge ausnutzten.

Gefälschte Mail im Posteingang

Kürzlich erhielt ich eine E-Mail, die angeblich von der französischen Versicherungsgesellschaft Prudence Créole stammte, aber alle Merkmale von Spam und Spoofing aufwies:

 

Obwohl ich weiß, dass es trivial ist, die Absenderadresse im Header einer E-Mail zu fälschen, war meine Neugierde geweckt, als ich die vollständigen E-Mail-Header untersuchte und feststellte, dass die Domäne im SMTP-Envelope MAIL FROM: reply@prudencecreole.com die SPF-Prüfung bestanden hatte:

Also habe ich mir den SPF-Eintrag der Domäne prudencecreole.com angesehen:

Das ist ein riesiger Block von IPv4-Adressen! 178.33.104.0/2 enthält 25 % des IPv4-Adressraums und reicht von 128.0.0.0 bis 191.255.255.255. Über eine Milliarde IP-Adressen sind als Absender für den Domänennamen von Prudence Creole zugelassen - ein Paradies für Spammer.

Um sicherzugehen, dass ich mir nichts vormachte, richtete ich zu Hause einen E-Mail-Server ein, bekam von meinem Internet-Provider eine zufällige, aber zulässige IP-Adresse zugewiesen und schickte mir selbst eine E-Mail mit der falschen Adresse prudencecreole.com:  

Erfolg! 

Zu allem Überfluss überprüfte ich den SPF-Eintrag einer Domäne aus einer anderen Spam-E-Mail in meinem Posteingang, die wildvoyager.com nachahmte:

Und siehe da, der 0.0.0.0/0-Block ermöglicht es dem gesamten IPv4-Adressraum, der aus über vier Milliarden Adressen besteht, die SPF-Prüfung zu bestehen, während er sich als Wild Voyager ausgibt.

Nach diesem Experiment habe ich Prudence Créole und Wild Voyager über ihre falsch konfigurierten SPF-Einträge informiert. Prudence Créole hat die SPF-Einträge vor der Veröffentlichung dieses Artikels aktualisiert.

Überlegungen und Lehren

Die Erstellung eines SPF-Eintrags für Ihre Domäne ist kein Todesstoß gegen Spammer. Wenn SPF jedoch sicher konfiguriert ist, kann die Verwendung von SPF viele Versuche vereiteln, wie die, die in meinem Posteingang ankommen. Die vielleicht größte Hürde, die einer sofortigen, breiteren Nutzung und strengeren Anwendung von SPF im Wege steht, ist die Zustellbarkeit von E-Mails. Zum SPF-Spiel gehören zwei, denn sowohl Absender als auch Empfänger müssen ihre E-Mail-Sicherheitsrichtlinien aufeinander abstimmen, falls E-Mails aufgrund zu strenger Regeln auf beiden Seiten nicht zugestellt werden können.

In Anbetracht der potenziellen Risiken und Schäden durch Spammer, die Ihre Domäne fälschen, können Sie jedoch die folgenden Ratschläge befolgen:

  • Erstellen Sie einen SPF-Eintrag für alle Ihre HELO/EHLO-Identitäten, falls SPF-Verifier der Empfehlung in RFC 7208 folgen, um diese zu prüfen.
  • Es ist besser, den "all"-Mechanismus mit den Qualifizierungszeichen "-" oder "~" zu verwenden als mit dem Qualifizierungszeichen "?", da letzteres jedem erlaubt, Ihre Domäne zu fälschen.
  • Richten Sie für jede Domain und Subdomain, die Sie besitzen und die niemals E-Mails generieren sollten oder im Domainnamen-Teil der Befehle HELO/EHLO oder MAIL FROM: auftauchen sollen, eine "Drop-All"-Regel (v=spf1 -all) ein.
  • Als Richtlinie sollten Sie sicherstellen, dass Ihre SPF-Einträge klein sind, vorzugsweise bis zu 512 Bytes, um zu verhindern, dass sie unbemerkt von einigen SPF-Verifiern ignoriert werden.
  • Stellen Sie sicher, dass Sie nur eine begrenzte und vertrauenswürdige Gruppe von IP-Adressen in Ihren SPF-Einträgen zulassen.

Die weit verbreitete Verwendung von SMTP für den E-Mail-Versand hat eine IT-Kultur geschaffen, die sich auf die zuverlässige und effiziente Übertragung von E-Mails konzentriert, anstatt auf die Sicherheit und den Schutz der Privatsphäre. Die Umstellung auf eine sicherheitsorientierte Kultur mag ein langsamer Prozess sein. Aber die Aussicht auf Erfolg im Kampf gegen einen der Plagegeister des Internets - Spam - sollte die Anstrengung wert sein.

 

Haben Sie Fragen und Anregungen zu diesem, anderen oder zukünftigen Themen, die Sie gern betrachtet sehen wollen? Dann nutzen Sie gern die Kommentarfunktion unter diesem Artikel oder nutzen unser Kontaktformular!