Artikel zum Thema E-Mail-Sicherheit in Sonderbeilage der “iX”

In der TeleTrusT-Heise-Sonderbeilage der aktuellen Ausgabe der Zeitschrift "iX" zum Thema "Sicherheit und Datenschutz" wurde ein Artikel von Stefan Cink veröffentlicht. In dem Artikel "Absender, auf die man sich verlassen kann - Standards zur Senderidentifikation sorgen für mehr Sicherheit im E-Mail-Verkehr" thematisiert der Produktmanager von NoSpamProxy die Bedeutung der Absender Reputation für eine sichere und effiziente E-Mail-Kommunikation. Hier geht's zur Sonderbeilage Absender, auf die man sich verlassen kann Standards zur Senderidentifikation sorgen für mehr Sicherheit im E-Mail-Verkehr Für Sicherheit und Effizienz in der Mailkommunikation stellt die Nutzung von DMARC & Co einen Meilenstein dar. Denn die Bewertung der Reputation des Absenders ist ein verlässliches Instrument im Kampf gegen stetig steigende Mengen an Spam und immer perfider werdende Angriffsszenarien mit Malware. Namhafte Akteure wie beispielsweise 1&1, Paypal und Microsoft setzen Standards zur Senderidentifikation bereits ein, der Bundesverband IT-Sicherheit e. V. TeleTrusT empfiehlt sie und sogar vermeintlich eher langsam arbeitende Behörden bieten sie ihren Kommunikationspartnern an. Auch international tut sich dazu einiges – die britische Digital-Services-Behörde hat beispielsweise die Verwendung von DMARC ab dem 1. Oktober 2016 verbindlich für alle Behörden in Großbritannien eingeführt. Die britische Steuerbehörde HMRC berichtet darüber hinaus von durchschlagenden Erfolgen bei der Bekämpfung von Spoofing-Attacken im Namen der HMRC seit der Einführung von DMARC. SPF, DKIM und DMARC Die automatische Absenderidentifikation ermöglicht es dem empfangenden Server, eindeutig festzustellen, ob eine Mail auch tatsächlich von dem Absender kommt, von dem sie zu stammen vorgibt. Außerdem kann er feststellen, ob der einliefernde Server autorisiert ist, im Namen der absendenden Domain E-Mails zuzustellen. Möglich wird dies durch spezielle Methoden, die als Standardinstrumentarium für E-Mail-Security immer mehr Verbreitung finden. Sie sind unter den Abkürzungen SPF (Sender Policy Framework), DKIM (Domain Keys Identified Mail) sowie DMARC (Domain-based Messaging, Authentication, Reporting and Conformance) bekannt und bauen aufeinander auf. Bei der Einführung dieser Technologien gilt es, zwei Aspekte zu berücksichtigen: Zum einen müssen die entsprechenden SPF-, DKIM-, und DMARC-Informationen für die eigenen Domains veröffentlicht und damit den externen Kommunikationspartnern zur Verfügung gestellt werden. So erhält der Kommunikationspartner überhaupt erst die Möglichkeit, zweifelsfrei festzustellen, dass die E-Mail tatsächlich vom korrekten Absender kommt. Nicht zu unterschätzen ist jedoch auch die massive Senkung des Reputationsrisikos für die eigenen Domains und damit des gesamten Unternehmens oder der Behörde. Der zweite Aspekt betrifft die Empfängerseite. Hier muss eine Software zum Einsatz kommen, welche die genannten Informationen abfragen und korrekt umsetzen kann. Umschlag vs. Briefkopf Zum besseren Verständnis ist es zwingend erforderlich, zunächst den Unterschied zwischen dem sogenannten „Envelope Sender“ und dem „Body-from“-Absender einer E-Mail zu kennen. Als Envelope Sender wird die E-Mail-Adresse bezeichnet, die während eines SMTP-Handshakes übergeben wird. Die Bezeichnung Envelope ist in Anlehnung an den Briefumschlag gewählt. Wie bei der traditionellen Briefpost ist nur das, was auf dem Umschlag steht, für den Transport ausschlaggebend. Und wie bei der Briefpost wird der Absender auf dem Umschlag (der Envelope Sender) informiert, wenn seine Nachricht nicht zustellbar war – unabhängig davon, welcher Absender in der Nachricht selbst (Body from) genannt wird. Die Absenderinformation in Form des Body from ist zum einen im Body, genauer gesagt im Header der E-Mail, enthalten und beinhaltet neben der E-Mail-Adresse in der Regel noch weitere Informationen zum Absender, wie etwa Vor- und Nachname oder den Namen des Postfachs. E-Mail-Programme zeigen üblicherweise nur den Body from an. So werden E-Mails im Posteingang des Empfängers beispielsweise als gesendet von „Max Mustermann“ und nicht von „max.mustermann@musterfirma.de“ angezeigt. Domain-Autorisierung Im Sender Policy Framework (SPF) gibt der Inhaber einer Domain im Domain Name System (DNS) an, welche Server autorisiert sind, E-Mails im Namen der eigenen Domain zu versenden. Dazu erstellt er in der entsprechenden DNS-Zone einen sogenannten SPF-Record. Technisch gesehen handelt es sich hierbei um einen TXT-Record, dessen Syntax in der RFC7208 exakt spezifiziert ist. Bei der Zustellung einer E-Mail entnimmt der empfangende Server die Absender-Domain aus dem Envelope Sender einer E-Mail. Anschließend wird im Rahmen einer DNS-Abfrage ermittelt, ob für die Domain ein SPF-Record existiert. Diese Prüfung wird optional zusätzlich für den Host-Eintrag des Absenders (EHLO-Client-ID) durchgeführt. Taucht die IP-Adresse oder der FQDN (Fully Qualified Domain Name) des einliefernden Servers nicht im SPF-Record auf, ist er für den Versand von E-Mails im Namen dieser Domain auch nicht autorisiert. Zusätzliche Kryptografie Im Falle von Domain Keys Identified Mail (DKIM) wird ebenfalls ein TXTRecord in Form einer RFC-normierten Syntax in der DNS-Zone der zu schützenden Domain erstellt. Zusätzlich kommt bei DKIM mit dem PublicKey-Verfahren eine kryptografische Komponente zum Tragen. Im Unterschied zu SPF wird bei DKIM die Absender-Domain aus dem Body from der E-Mail untersucht Vor der Erstellung des Records wird ein Schlüsselpaar, bestehend aus einem öffentlichen und einem privaten Schlüssel gebildet. Der öffentliche Schlüssel wird in Kombination mit anderen Informationen als DKIM-Record in der DNS-Zone hinterlegt. Der private Schlüssel verbleibt ausschließlich auf dem Server, der für den Versand autorisiert werden soll. Mithilfe des privaten Schlüssels erzeugt der absendende Server für jede ausgehende E-Mail eine kryptografische Signatur, die sowohl Teile des Headers als auch den Inhalt der E-Mail umfasst. Idealerweise verfügt der Server über jeweils einen anderen Schlüssel für jede Domain, für die er E-Mails versenden soll. Die erzeugte DKIM-Signatur wird als X-Header-Wert in den Header der jeweiligen E-Mail geschrieben. Der empfangende Server einer DKIM-geschützten E-Mail ermittelt dazu zunächst die Absender-Domain der E-Mail, gefolgt vom sogenannten Selektor. Der Selektor ist fester Bestandteil einer DKIM-Signatur und gibt an, unter welchem Namen der passende öffentliche Schlüssel in der DNS-Zone der Absender- Domain zu finden ist. Nachdem er den öffentlichen Schlüssel heruntergeladen hat, wird im Rahmen eines kryptografischen Vorgangs die Signatur geprüft. Schlägt diese Prüfung fehl, liegt entweder der falsche öffentliche Schlüssel vor, oder die E-Mail wurde unterwegs verändert. Die DKIM-Signatur stellt somit zwei Dinge sicher: Zum einen weiß der empfangende Server, dass die E-Mail samt Inhalt auf dem Transportweg nicht verändert worden ist. Zum anderen weiß er, dass der Inhaber der im Header angegebenen Absender-Domain den Server autorisiert hat. Im Unterschied zu kryptografischen Signaturen mittels S/MIME oder PGP sieht der Empfänger einer E-Mail die DKIM-Signatur nicht. Es ist ein rein serverbasiertes Verfahren. Erst wenn man sich den Header einer E-Mail anzeigen lässt, wird die DKIM-Signatur sichtbar. Kontrolle durch Reporting Weder SPF noch DKIM geben dem empfangenden Server klare Anweisungen, was mit E-Mails passieren soll, die die SPF- und DKIM-Prüfung nicht bestanden haben. Diese Lücke schließt DMARC (Domain-based Message Authentication, Reporting and Conformance). DMARC ergänzt die SPF- und DKIM-Prüfungen um das sogenannte Alignment. Es stellt sicher, dass die Envelope-Sender-Adresse mit der Body-from-Adresse übereinstimmt. Diese Prüfung ist deshalb wichtig, weil die gängigsten E-Mail-Programme lediglich die Body-from-Informationen einer E-Mail anzeigen und der Empfänger somit leicht getäuscht werden kann. Genau diesen Umstand machen sich beispielsweise Angreifer zunutze, die einem Unternehmen mit der Chef-Betrugsmasche, die häufig auch CEO-Fraud genannt wird, Schaden zufügen wollen. Eine weitere Besonderheit von DMARC ist die Berichtsfunktion. Sie sorgt dafür, dass der Inhaber einer Domain regelmäßig darüber informiert wird, welche Server in seinem Namen E-Mails versendet haben und ob die Prüfung beim Empfänger erfolgreich war oder nicht. So bekommt er nicht nur einen guten Überblick über seine im Internet versendeten E-Mails, sondern auch wertvolle Informationen, ob seine SPF- und DKIM-Einträge vollständig und syntaktisch korrekt sind. FÜNF SOFORTTIPPS FÜR UNTERNEHMEN Aktuell kann jedem Unternehmen nur geraten werden, folgende fünf kostenfreie und einfache Sofortmaßnahmen durchzuführen: 1. Die Konfiguration der eigenen Mail-Infrastruktur mit kostenlosen Tools wie ssl-tools.net und mxtoolbox.com testen. 2. Sofern noch nicht vorhanden, SPF-/DKIM- und DMARC Records einrichten. 3. TLS (Transport Layer Security) bei der Kommunikation mit bekannten Partnern erzwingen, wo dies möglich ist. 4. DANE (DNS-based Authentication of Named Entities) nutzen. 5. Prüfen, ob der Hersteller der eingesetzten Mail-SecurityLösung DANE nutzt, und – falls dies nicht der Fall ist – solche Funktionen aktiv einfordern bzw. alternative Produkte in Betracht ziehen. Um DMARC zu aktivieren, hinterlegt der Inhaber einer Domain eine DMARC-Richtlinie in seiner DNS-Zone. Wie bei SPF und DKIM auch, wird die DMARC-Richtlinie in einem RFC-normierten TXT-Record gespeichert. Sie beinhaltet die Information, welche Prüfungen vom Empfänger gemacht werden müssen (SPF und/oder DKIM). Zusätzlich wird festgelegt, wie sich der Empfänger verhalten soll, wenn die Prüfungen fehlschlagen. Annehmen, in Quarantäne stecken oder Abweisen sind die möglichen Aktionen. Darüber hinaus werden in der DMARC-Richtlinie diejenigen E-Mail-Adressen hinterlegt, an die Berichte geschickt werden sollen. Diese werden von allen Servern im Internet erstellt, die DMARC beim E-Mail-Empfang unterstützen und auch E-Mails von der jeweiligen Domain erhalten haben. Die Berichterstattung erfolgt dann täglich. Richtiger Einsatz und Risiken Ein alleiniger Einsatz von SPF-Records für den Schutz der eigenen Domain und bei der Prüfung eingehender E-Mails ist nur bedingt hilfreich. Er birgt sogar gewisse Risiken. Auf den Schutz der eigenen Domain bezogen bedeutet der alleinige Einsatz von SPF, dass der E-Mail-Administrator fortlaufend Änderungen seiner Infrastruktur im Auge behalten muss, um so die Aktualität des SPF-Records sicherzustellen. Dies beinhaltet nicht nur die E-Mail-Server als solche, die für den Versand zuständig sind, sondern auch die dazugehörigen IP-Adressen. Bei der Betrachtung müssen auch Server berücksichtigt werden, die womöglich nicht im eigenen Netzwerk stehen. Das gilt vor allem für den Versand von Newslettern. Eine flächendeckende Überwachung dieser Infrastruktur ist nur schwer möglich und so kann es schnell zu Lücken in den SPF-Records kommen, die im schlimmsten Fall dazu führen, dass E-Mails vom Kommunikationspartner nicht angenommen werden. Gute Newsletter-Versanddienste kann man übrigens daran erkennen, dass Sie nicht nur Unterstützung bei der Pflege der SPF-Records anbieten, sondern vielmehr den Versand über eigens für diesen Dienst eingerichtete Subdomains empfehlen oder gar verlangen. Die Abweisung einer E-Mail lediglich aufgrund einer fehlgeschlagenen SPF-Prüfung ist ebenfalls riskant. Die E-Mail könnte gegebenenfalls weitergeleitet, oder über eine Mailingliste verschickt worden sein. Beide Szenarien führen zu Fehlern bei der SPF-Prüfung weil der weiterleitende Server in der Regel nicht im SPF-Record der ursprünglichen AbsenderDomain gelistet ist. Weitergeleitete Nachrichten Letzteres wird beispielsweise durch den Einsatz von DKIM entschärft. Beim ursprünglichen Versand der E-Mail wird sie um eine DKIM-Signatur angereichert, die im Header der E-Mail verankert ist. Vorausgesetzt, sie wird von den im weiteren Verlauf beteiligten Relay-Servern nicht entfernt, kann sie vom Zielserver erfolgreich geprüft werden. Im Szenario „Weiterleitung einer E-Mail“ würde der empfangende Server feststellen, dass die SPF-Prüfung zwar fehlschlägt, die E-Mail aber über eine gültige DKIM-Signatur verfügt. Der Einsatz von DKIM ist dabei relativ risikoarm. Bei der Erstellung der DKIM-Signatur muss lediglich darauf geachtet werden, dass die E-Mail danach nicht mehr verändert werden darf. Etwaige Disclaimer oder einfache Signaturen müssen im Vorfeld an die E-Mail angehängt werden. Anderenfalls würde die Signatur brechen. Idealerweise wird deshalb die DKIM-Signatur vom letzten Mail Transfer Agent (MTA) in der eigenen E-Mail-Kette aufgebracht. Wenn DKIM-Signaturen beim Empfang von E-Mails geprüft werden sollen, sollte dies so früh wie möglich geschehen – idealerweise auf dem ersten MTA in der E-Mail-Kette. Viele Systeme belassen nach der Prüfung die Signatur im Header der E-Mail, damit sie später gegebenenfalls noch einmal geprüft werden kann. Diese Vorgehensweise ist auch durchaus empfehlenswert. Eindeutige Domain-Zuordnung Wie oben bereits angedeutet, lassen die Ergebnisse der SPF- und DKIMPrüfung immer noch die Frage nach dem Willen des Absenders offen. Diese Informationslücke wird mit einer DMARC-Richtlinie geschlossen. In dieser erklärt der Absender zweifelsfrei, wie und mit welchen Technologien seine ausgehenden E-Mails geschützt sein müssen und wie im Fehlerfall mit den E-Mails umzugehen ist. Des Weiteren kann der DomainInhaber über die Ergebnisse der Prüfung informiert werden. DMARC erfordert aber auch, dass die Domain im Envelope Sender mit der Domain im Body from übereinstimmt. Dies soll sicherstellen, dass der Empfänger sicher sein kann, dass alle durchgeführten Prüfungen für die Domain erfolgten, die er in seinem E-Mail-Programm angezeigt bekommt. Angreifern Paroli bieten Ein Angriff im Namen von Paypal könnte beispielsweise folgender - maßen aussehen: Im Body from wird Paypal als Absender angezeigt, während im Envelope Sender eine gänzlich andere Domain angegeben wird. Unbedarfte Benutzer klicken deshalb eher auf einen Link in der E-Mail oder öffnen eine harmlos erscheinende Anlage. Paypal hat seine Domains jedoch mit einem DMARC-Record geschützt, um Missbrauch einzudämmen. Wenn das empfangende E-Mail-Gateway diese wertvollen Informationen aber nicht auswertet, bleiben sie nutzlos. Dieses Beispiel zeigt eindrucksvoll, wie wichtig die Prüfung der Absender-Domain im Rahmen eines intelligenten E-Mail-Managements geworden ist. Anders als die oft verwendeten pattern- oder sandboxbasierten Verfahren, unterliegen die Absenderreputationsverfahren nicht dem viel zitierten Hase-und-Igel-Wettlauf zwischen Angreifern und Sicherheitssoftware. Die Prüfung erfolgt zudem in Echtzeit und ermöglicht so eine zeitnahe Zustellung der E-Mail. Wer also weder selbst in Fallen tappen noch seinen guten Ruf aufs Spiel setzen will, sollte möglichst rasch sein E-Mail-Management auf den neuesten Stand bringen.

Artikel zum Thema E-Mail-Sicherheit in Sonderbeilage der “iX”

NoSpamProxy

Partner

Kategorien

Letzte News