Manche Dinge passen einfach richtig gut zusammen, bei anderen Kombinationen ist das Resultat eher erschreckend. So ähnlich verhält es sich, wenn SPF-Einträge auf Spear-Phishing treffen. Im guten Sinne. Für viele sind die Nuancen einer scheinbar profanen Angelegenheit wie SPF DNS-Einträge ein trockenes, wenn nicht unsagbar langweiliges Thema. Diese Einträge verfügen allerdings über eine Eigenschaft, die ihnen selbst in Führungsetagen Aufmerksamkeit garantiert: Sie sind eines der wahrscheinlichsten Ziele für eine Spear-Phishing-Attacke.
SPF-Einträge können aber deutlich mehr als „nur“ Führungskräfte vor Spear-Phishing bewahren. Einige Beispiele:
Diese Vorteile sollte man immer im Hinterkopf haben wenn man tiefer in das „Wie“ und „Warum“ dieser Art von DNS-Einträgen einsteigen will.
Das Sender Policy Framework, kurz SPF, ist ein Anti-Spam-System, das auf der bestehenden DNS- und E-Mail-Infrastruktur aufsetzt.
Spammer imitieren Domains, so dass es so aussieht, als handele es sich etwa um ein Angebot von Amazon oder einer anderen legitimen Domain. Klickt man sich allerdings durch das angebliche Angebot, werden Kreditkartendaten abgezogen oder Zahlungsanweisungen ausgelöst.
Ein SPF-Eintrag legt fest, welchen IP-Adressen es gestattet ist E-Mails von einer bestimmten Domain aus zu versenden. Das klingt erst mal simpler als es eigentlich ist. Denn nicht selten nutzen Unternehmen verschiedene E-Mail Service Provider für unterschiedliche Zwecke.
Das sind etwa:
Was die Sache zusätzlich komplizierter macht: Wenn eine Firma einen Namen verwendet wie SafeEmailSender hält sie nichts davon ab, eine Domain mit dem Namen wookie-fighter.com zu unterhalten, von der ebenfalls E-Mails verschickt werden.
Strikte SPF-Regeln erlauben es, genau zu überwachen, wer E-Mails im Namen dieser Domain versenden kann. Oder umgekehrt: wer im Unternehmen darf E-Mails von dieser Domain aus verschicken?
Unter Phishing versteht man den massenhaften Versand von E-Mails aus einer illegitimen Quelle. Wobei die E-Mails von einem rechtmäßigen Sender zu kommen scheinen beziehungsweise vorgeben, dass es sich um eine legitime Quelle handelt.
Zu den Unternehmen deren Mailings am häufigsten kopiert werden gehören Banken, Kreditkartenunternehmen und Dienstleister, die finanzielle Transaktionen abwickeln, wie etwa Paypal. Aus Sicht eines Angreifers geht es darum, die Unternehmensseiten und E-Mails so exakt wie möglich zu imitieren. Es gilt also überzeugend vorzutäuschen, dass es sich um eine legitime Quelle handelt (und es nicht so aussieht als kämen die Mails von einer ahnungslosen, Malware-verseuchten Windows XP-Box). Durch die vielen erfolgreichen Datenschutzverletzungen der vergangenen Jahre wissen Angreifer inzwischen deutlich mehr über ihr potenzielles Ziel als das früher der Fall war. Eine Folge davon ist es, dass Phishing-Mails immer „echter“ wirken.
Spear-Phishing hat prinzipiell dasselbe Ziel wie andere Phishing-Kampagnen auch, nämlich das Opfer glauben zu machen, es erhalte eine legitime E-Mail auf die es dann entsprechend reagiert. Bei Spear-Phishing ändert sich allerdings die Zielgruppe. Sie ist der Schlüssel für diese Form des Phishing-Angriffs. Ein gutes und nahezu kanonisches Beispiel ist eine Spear-Phishing-Attacke auf einen Mitarbeiter von Snapchat im Februar dieses Jahres:
http://money.cnn.com/2016/02/29/technology/snapchat-phishing-scam/
Alle DNS-Einträge sind „Records“, typischerweise steht A für die Domain selbst, CNAME steht für die Webseite und MX-Einträge steuern, wohin der E-Mail-Traffic geleitet werden soll.
Ein SPF-Eintrag ist das, was die SPF-Regel enthält. Das bloße Vorhandensein von SPF sichert erst Mal gar nichts. Man kann sich das wie ein offenes Vorhängeschloss vorstellen. Es ist in der Lage etwas zu abzusichern, nur was und wie ist zunächst im wahrsten Sinne des Wortes offen.
DNS ist von einigen ziemlich klugen Leuten entwickelt worden und in mancher Hinsicht erweist sich die Konzeption nachgerade als weise. Zumindest waren die Schöpfer vorausschauend genug zu ahnen, dass die Skalierung von DNS herausfordernd werden würde, wenn es nicht mehr um einige Dutzend Rechner geht, sondern um die Millionen von Computern. Damit DNS dieser Entwicklung standhält, wurde der TXT Record „erfunden“.
Diese Einträge eignen sich für ganz unterschiedliche DNS-Zwecke. Damit lässt sich beispielsweise sicherstellen, dass jemand eine Domain innehat, von der er SSL-verschlüsselte E-Mails versenden kann. Und künstlerisch betrachtet eignen sie sich für ein Selbstporträt in ASCII https://isc.sans.edu/forums/diary/Odd+DNS+TXT+Record+Anybody+Seen+This+Before/20283/ …
Es überrascht also nicht besonders, das TXT-Einträge eine Rolle spielen, wenn man innerhalb von DNS auf der Suche nach neuen Funktionalitäten ist. Neben den künstlerischen Ambitionen haben TXT Records nämlich sehr viel praktische Relevanz. Anstatt einer fruchtlosen Suche nach einem „SPF DNS Record Type“ im Dropdown-Menü des bevorzugten DNS-Dienstes wählt man TXT aus und fügt die betreffende Regel ein.
Im Wesentlichen besteht ein SPF-Eintrag aus zwei Komponenten einem optionalen Qualifikator und einem sogenannten Mechanismus.
Der Mechanismus: ergibt für eine gegebene Situation (IP-Adresse) entweder einen Treffer oder keinen Treffer. Der erste Mechanismus, der einen Treffer ergibt, bestimmt das Ergebnis der gesamten Auswertung des SPF-Records.
Der Qualifikator definiert, welche Aktionen daraus folgen, wenn der Mechanismus einen Treffer ergibt.
Ein SPF-Mechanismus ist nichts anderes als eine Gruppe von IP-Adressen. Die Nuancen wie genau eine Gruppe definiert wird, unterscheidet sich je nach dem welcher Typ eines Mechanismus eingesetzt wird. Die grundlegende Frage ist aber immer dieselbe: Gehören die IP-Adressen, von denen aus E-Mails versendet werden, zu einer der Gruppen oder nicht?
Ein SPF-Mechanismus hat dazu keine „Meinung“. Wenn IP-Adresse und Mechanismus einen Treffer ergeben, sagt das noch nichts darüber aus, ob das „gut“ oder „schlecht“ ist – es ist lediglich ausgesagt, dass es sich um einen Treffer handelt. Mit diesem Wissen lassen sich dann Befehle schreiben, mit denen man das Ergebnis anschließend auswerten kann.
Es gibt vier unterschiedliche Typen von SPF-Mechanismen. Das sind:
DIRECT IP/IP-MECHANISMEN
Gibt es einen Match zwischen der IP-Adresse des Clients und einer Adresse in der angegebenen Range?
ip4 and ip6
DNS RECORD-MECHANISMEN
Gibt es einen Treffer zwischen der aufgelösten IP-Adresse des Clients mit ein oder mehreren Domain-Einträgen?
a, mx, and ptr
DOMAIN-MECHANISMEN
Ergibt die IP-Adresse des Clients einen Treffer mit einer der SPF-Regeln dieser ANDEREN Domain? Ist das etwas, das sich typischerweise beobachten lässt, bei E-Mail-Diensten, die beispielsweise über automatisierte E-Mail-Suites für Marketingzwecke versenden oder bei transaktionellen E-Mail-Systemen?
include and exists
CATCH ALL-MECHANISMUS
Die IP-Adresse des Clients ergibt mit keiner der anderen Regeln einen Treffer
all
Es gibt vier verschiedene SPF Qualifier Typen, die mit den SPF-Mechanismen zusammenarbeiten.
+ die Direktive definiert autorisierte Sender; dies ist der Standard, d. h. ist kein Qualifikator angegeben, so wird + angenommen; wenn die Client IP mit dem Mechanismus einen Treffer ergibt (IP Matching Group) ist es dieser Domain erlaubt E-Mails zu verschicken.
Beispiel: v=spf1 +a
Es besagt “Wenn diese IP-Adresse jeglichen DNS-Eintrag für diese Domain auflöst und mit der IP-Adresse des Clients einen Treffer ergibt, dann dürfen von dieser Domain aus E-Mails verschickt werden”.
- die Direktive definiert nicht autorisierte Sender; wenn die IP-Adresse des Clients mit dem folgenden Mechanismus einen Treffer ergibt, ist es nicht gestattet E-Mails zu versenden.
~ die Direktive definiert nicht autorisierte Sender, der Empfänger soll diesen Fehler aber großzügig behandeln; dieser Qualifikator ist für Testzwecke gedacht; wenn die IP-Adresse des Clients mit einem der folgenden Mechanismen einer Treffer ergibt, ist es gestattet E-Mails zu versenden. Sie ist aber als potenziell verdächtig einzustufen. Der sogenannte „SoftFail-Qualifikator“ wird häufig genutzt, wenn SPF-Regeln erstmalig implementiert werden. Es ist dann insgesamt weniger wahrscheinlich legitime E-Mails versehentlich als Spam zu qualifizieren, der über die eigene Domain verteilt wird.
In der Produktion gibt es ein typisches Qualifikator-Mechanismus-Paar, das bei den vorherigen Regeln einen positiven Match gestattet: ~all.
? Neutral. Die Direktive definiert Sender, über deren Legitimität nichts ausgesagt werden soll; der Sender muss akzeptiert werden. Es handelt sich weder um eine positive noch um eine negative Bewertung.
In allen anderen Fällen markiert “+” eine legitime E-Mail der betreffenden Domain; die übrigen Qualifikatoren kann man als eine Art Hinweis für die Spam-Kalkulation des Inbound-E-Mail-Servers betrachten:
| + | Das ist eine unserer E-Mails |
|---|---|
| ? | Vielleicht eine unserer E-Mails? |
| ~ | Ziemlich sicher keine unserer E-Mails |
| – | Sicher keine unserer E-Mails |
Der Schlüssel ist es innerhalb der DNS die Time to Live (TTL) Settings entsprechend anzupassen. Eine gute Richtschnur wie man DNS Einträge am besten hinzufügt oder ändert ist der Definitive Guide to DNS TTL Settings (liegt nur in englischer Sprache vor).
SPF-Einträge werden innerhalb der Records von links nach rechts bewertet. Gibt es innerhalb einer Gruppe von Mechanismen einen Treffer, wird sofort eine Aktion des Qualifikators ausgelöst und in Zukunft ergeben die Regeln keine Treffer mehr. Generell sollten sämtliche Bezeichnungen von IP-Adressen und Domains enthalten sein, includes und dann der all Mechanismus. Diese Vorgehensweise deckt grob sämtliche Anwendungsfälle ab, bis die Regeln aufgestellt sind, was einige Zeit in Anspruch nimmt.
Es ist wichtig im Kopf zu behalten, dass es – egal wohin E-Mails verschickt werden – letztendlich der Empfänger-Server ist, der den SPF-Eintrag liest. Wenn Sie also eine E-Mail an abaigail@example.com schicken, dann ist es der example.com Mail-Server, der den SPF Record for example.com liest, die versendende IP-Adresse mit den Regeln vergleicht und der dann entscheidet, ob die E-Mail dem betreffenden Adressaten zugestellt wird oder nicht.
Spam und das Nachahmen legitimer Seiten und Mails sind ein Problem, das so alt ist wie das Internet selbst. Warum sich also für SPF und nicht für einen der verschiedenen anderen Standards entscheiden (die vor SPF da waren)? Im Gegensatz zu vielen anderen Sicherheitslösungen ist SPF einigermaßen schnell aufzusetzen und dabei nicht abhängig von den Inhalten der jeweiligen E-Mails. Eine E-Mail-Nachricht, die einen 15MB großen Videoanhang enthält, lässt sich genauso schnell qualifizieren wie eine E-Mail, die nur aus einem Satz besteht. Das liegt daran, dass nur die Header der E-Mails überprüft werden.
Etliche der früheren Standards verlassen sich auf die Fähigkeit den Inhalt einer E-Mail kryptographisch zu unterzeichnen. Das macht den Gebrauch im besten Falle sperrig und umständlich, im schlimmsten Fall wird daraus ein Vektor für eine potenzielle Denial of Service (DDoS)-Attacke.
Unter OSX und Linux lässt sich mithilfe des Dig-Befehls eine Liste der TXT-Einträge für die jeweilige Domain erstellen, dort wo sich die SPF-Listen befinden:
dig -t txt example.com +short
Unter Windows kann man das mit dem NSLookup Utility tun:
Nslookup.exe =q=TXT example.com
Ich empfehle die SPF-Einträge für microsoft.com nachzuschlagen. So lassen sich die verschiedenen eingeschlossenen SPF Domains sehr leicht herausfinden ebenso wie ihre Berechtigung über hotmail.com E-Mails in ihrem Namen zu versenden.
(Quelle sonstige: https://de.wikipedia.org/wiki/Sender_Policy_Framework)