Hornetsecurity bietet einen sicheren Schutz gegen Späh- und Schadsoftware in der E-Mail-Authentifizierung durch standardisierte Absenderreputationsverfahren

E-Mails gelten immer noch als das meistgenutzte Medium zur Übertragung von elektronischen Nachrichten. Sie sind kostengünstig, uneingeschränkt in der Verbreitung und bieten die Möglichkeit, Texte und Dateianhänge in Echtzeit zu verschicken bzw. zu empfangen. Doch genau diese Eigenschaften machen die E-Mail-Kommunikation so angreifbar. Cyberkriminelle erweitern stetig ihr Angriffs-Spektrum und entwickeln neue Strategien, um Verteidigungsmechanismen zu überwinden. Die Autorisierung erlaubter Domains durch ein SPF Record in der DNS-Zone reicht also längst nicht mehr aus, um den ankommenden E-Mail-Verkehr erfolgreich gegen Phishing und Spam zu schützen.

Aus diesem Grund wurde der E-Mail-Service von Hornetsecurity um weitere, wichtige Absenderreputationsverfahren im Kampf gegen weitverbreitete Angriffsmuster erweitert. Neben SPF werden Verfahren wie DKIM und DMARC gegen Spam,- Spoofing,- Phishing- und Malware-Attacken sowie gezielte CEO-Fraud Angriffe eingesetzt. Damit folgt Hornetsecurity bereits seit vielen Monaten der aktuellen Empfehlung für die E-Mail-Sicherheit seitens des Bundesamtes für Sicherheit in der Informationstechnik (BSI), sowie der Empfehlung des Bundesverbandes IT-Sicherheit (TeleTrusT) und bietet somit einen hohen Sicherheitsstandard in der E-Mail-Kommunikation.

Mit SPF, DKIM und DMARC sicher gegen Angriffe

Die Authentifizierungsverfahren SPF, DKIM und DMARC wirken im gemeinsamen Verbund als ein sicheres Instrument gegen Angriffe auf die E-Mail-Kommunikation eines Unternehmens. Im Folgenden werden die eingesetzten Standards für Absender- und Empfängerreputation vorgestellt und ihre Funktionsweisen erläutert.

Sender-Policy-Framework (SPF) [RFC 7208]

SPF ist ein Verfahren, mit welchem nicht autorisierte Absenderadressen von Domains erkannt und die Zustellung ihrer Mails verhindert werden kann. Berechtigte Server, die im Namen einer Domain E-Mails verschicken dürfen, werden im sogenannten SPF-Record der DNS-Zone eingetragen. Bei der Zustellung einer E-Mail entnimmt der empfangene Server die Absender-Domain aus dem Envelope-Sender einer E-Mail und überprüft mit einer DNS-Abfrage, ob die Domain im SPF-Record registriert ist. Ist die Domain nicht eingetragen, so ist der Server nicht autorisiert, E-Mails im Namen der Domain zu versenden. E-Mails von nicht autorisierten Servern können beispielsweise als Spam eingestuft werden. Aufgrund unzureichender kryptografischer Sicherheitsmechanismen, die die Authentizität des Senders sicherstellen könnten, sollte SPF nicht per se als Spam- oder Phishingschutz eingesetzt werden. Denn trotz einer erfolgreichen SPF-Authentifizierung kann die Absenderadresse des Envelop-Senders im Feld Body-From verändert und somit die Absenderadresse leicht manipuliert werden.
Sender Policy Framework (SPF)

Domain-Keys-Identified-Mail (DKIM) [RFC 6376]

Für einen umfangreicheren E-Mail-Schutz kann SPF mit DKIM sinnvoll ergänzt werden. Hierbei soll vor allem verhindert werden, dass Spoofer an sensible Daten herankommen. Als besonderes Merkmal zur E-Mail-Authentifizierung fügt DKIM eine digitale Signatur mit einer kryptografischen Verschlüsselung (SHA-256) zum Header der E-Mail hinzu. Die Signatur fungiert als eine Art Fingerabdruck und muss beim Entschlüsseln den selben Hash-Wert in der Prüfsumme ergeben, wie vor dem Versand errechnet. Jede noch so kleine Änderung der Daten würde den Hash-Wert verändern und somit auf ein Eingreifen in die Nachricht während des Transports hindeuten.
Für das Entschlüsseln der Signatur sollte bereits ein Schlüsselpaar vorliegen, welches aus einem öffentlichen (public key) und einem geheimen Schlüssel (private key) besteht und zur erfolgreichen Autorisierung des sendenden Servers benötigt wird. Der öffentliche Schlüssel wird analog zum SPF-Eintrag in der DNS-Zone als TXT-Record eingetragen. Der geheime Schlüssel verbleibt ausschließlich auf dem Server, der beim Versand von E-Mails autorisiert wird.
Domain Keys Identified Mail (DKIM)
Beim Autorisierungsverfahren ermittelt der empfangende Server zunächst die Absender-Domain der E-Mail und schaut anschließend nach dem Namen, unter welchem der passende öffentliche Schlüssel in der DNS-Zone der Absender-Domain zu finden ist. Bei einer erfolgreichen Signatur-Prüfung wird sichergestellt, dass der dekodierte Hashwert der ursprünglichen Prüfsumme vor dem Versand entspricht und somit die E-Mail auf dem Transportweg nicht verändert wurde.

Domain-based Message-Authentification, Reporting and Conformance (DMARC) [RFC 7489]

  Eine konsistente Überprüfung der Authentizität von E-Mails kann allein mittels SPF und DKIM nicht sichergestellt werden. Diese Lücke schließt das Prüfverfahren DMARC, welches die Verfahren SPF und DKIM in ihrem gemeinsamen Auftreten zu einem sicheren Prüfprozedere zur Absenderreputation vervollständigt. DMARC stellt sicher, dass die Envelope-Sender-Adresse mit der Body-From-Adresse übereinstimmt. Diese Prüfung ist wichtig, da traditionelle E-Mail-Programme lediglich die Body-From-Informationen einer E-Mail anzeigen und die tatsächlichen Absenderinformationen verborgen bleiben.   Weiterhin stellt DMARC gewisse Richtlinien für die Verfahren SPF und DKIM auf, die im TXT-Record einer DNS-Zone in Form von Anforderungen hinterlegt werden. Diese Richtlinien sind maßgebend für die Anweisungen zum weiteren Verfahren mit empfangenen E-Mails. So muss z. B. für SPF die Überprüfung positiv ausfallen und die Envelope-Sender-Adresse der Domain mit der im SPF-Record hinterlegten Adresse übereinstimmen. Für DKIM wird gefordert, dass die Signatur gültig ist und die genannte Domäne mit der Body-From-Adresse der Mail übereinstimmt.
Domain Based Authentification Reporting and Conformance (DMARC)
  Werden eine oder mehrere Forderungen nicht erfüllt, so schlägt die Überprüfung negativ aus und die E-Mail kann je nach Entscheidungsmatrix in die Quarantäne verlagert (quarantine) oder abgewiesen werden (reject).  

Weiterhin bietet DMARC die Möglichkeit, Berichte* in Formen „Aggregated Reports“ und „Failure Reports“ zu verschicken. Die Berichte können den Domain-Administrator dabei unterstützen, den eigenen E-Mail-Verkehr im Überblick zu behalten und die DNS-Einträge auf syntaktische Korrektheit zu überprüfen. Weiterhin können die Ergebnisse dazu eingesetzt werden, um weitere Systeme zu unterstützen. So kann beispielweise die ZIP-Datei eines zweifelsfrei identifizierten Absenders ohne Weiteres zugestellt werden, während diese bei nicht identifizierten Absendern in Quarantäne wandert oder abgelehnt wird. Auf diese Weise unterstützt Hornetsecurity z. B. das eigene Produkt Content Filter für eine schnelle und sichere Zustellung von E-Mails mit Anhängen.

  *Die Übermittlung der Berichte darf nur unter Beachtung des Bundesdatenschutzgesetztes im Rahmen der Erkennung und Eingrenzung von Spam und Phishing sowie zum Schutz der Telekommunikationsanlagen und unter Wahrung des Verhältnismäßigkeitsgrundsatzes übermittelt werden. Hierbei ist ein Authentifizierungs- und Verifizierungssystem einzusetzen, um einen Missbrauch zu vermeiden.

Weitere Technologien und Verschlüsselungsverfahren im Überblick

  Für die Verbindung mit den Servern ist das sogenannte Domain Name System (DNS) verantwortlich, mit dessen Hilfe sich Hostnamen in IP-Adressen auflösen lassen. Das Senden und Empfangen von Nachrichten an einen oder mehrere Empfänger wird mit dem User Datagram Protocol (UDP) ermöglicht. Eine Verbindung zwischen Absender und Empfänger wird dabei nicht aufgebaut und die Daten werden ohne weitere Kontrollmechanismen an den Empfänger geliefert. Folglich hat auch der Absender keine Möglichkeit festzustellen, ob seine Nachricht erfolgreich angekommen ist. Um das Sicherheitsproblem des veralteten DNS zu beheben, werden unterschiedliche Sicherheitstechniken wie TLS, DNSSEC sowie DANE eingesetzt. Im Bereich der „sicheren E-Mail-Kommunikation“ konnte sich allerdings bis jetzt kein Standard durchsetzen. Der neuste Standard heißt MTA-STS und verspricht E-Mails auf dem Transportweg vor Lauschangriffen und Manipulationen erfolgreich zu schützen.

Transport Layer Security (TLS) [RFC 5246 ]

TLS ist ein weit verbreitetes Verschlüsselungsprotokoll, welches auf Basis des Secure Sockets Layer (SSL) weiterentwickelt und standardisiert wurde. Das TLS-Protokoll dient der Sicherstellung von Vertraulichkeit, Authentizität und Integrität bei der Übertragung von Daten in unsicheren Netzwerken. Das in zwei Ebenen unterteilte TLS-Protokoll ist ein hybrides Verschlüsselungsverfahren, welches sowohl symmetrische als auch asymmetrische Algorithmen nutzt. Das TLS Record Protocol verschlüsselt eine Ende-zu-Ende Verbindung mittels symmetrischer Algorithmen. Das TLS Handshake Protocol baut auf dem TLS Record Protokoll auf und hat die Aufgabe, Sicherheitsparameter zwischen Sender und Empfänger auszuhandeln. Verbindungen zu E-Mail-Servern können über STARTTLS eingeleitet und verschlüsselt werden. TLS wird heutzutage in vielen Anwendungen eingesetzt, in denen Daten, insbesondere Zugangsdaten, PINs und Passwörter sicher übertragen werden können. Hierzu gehören beispielsweise Anwendungen wie E-Commerce, Homebanking und E-Government.

DNSSEC (Domain Name System Security Extensions)

[RFC 4035 ]

DNSSEC ist eine Erweiterung von DNS. Diese prüft die in der DNS-Zone hinterlegten Informationen auf Echtheit und stellt sicher, dass ein Angreifer die DNS-Antworten nicht zu seinen Gunsten manipulieren kann. Mit zwei verschiedenen Schlüsseln und einer entsprechenden Signatur werden die Daten des DNS geschützt. Der Empfänger kann den Absender anhand der verwendeten Signaturen genau verifizieren. Ist die Signatur nicht gültig, blockiert der DNS-Server des Providers die Antwort. DNSSEC lässt sich nicht für jede Domain auflösen und ist deshalb weltweit nur wenig verbreitet.

DNS-based Authentification of Named Entities (DANE) [RFC 6698]

Das Protokoll DANE ist eine weitere Technik, die auf DNSSEC basiert. Diese Technik erweitert den Grundschutz von TLS-Verbindungen um eine kryptografische Verknüpfung von Zertifikaten mit DNS-Namen. Dadurch soll geprüft werden, ob ein E-Mail-Server verschlüsselte Verbindungen aufbauen und authentifizieren kann. Eine Man-in-the-middle-Attacke, bei der die Nachricht zunächst auf den Server eines Angreifers gelangt, soll damit verhindert werden. Der DANE-Eintrag wird in der DNS-Zone unter einem TLSA-Record abgelegt, in welchem unterschiedliche Merkmale der jeweiligen TLS-Verbindung enthalten sind. Diese Merkmale spezifizieren das Zertifikat, welches ein Server erwarten muss, wenn dieser sich mit dem E-Mail-Dienst des jeweiligen E-Mail-Servers verbindet. Für viele Domain-Administratoren ist DANE jedoch nicht implementierbar, da nicht jede Domain per DNSSEC auflösbar ist.

SMTP MTA Strict Transport Security (MTA-STS) [RFC 8461 ]

Die Verbindungen zwischen den Servern sind bislang weitgehend ungeschützt. Damit fehlt ein wichtiger Baustein für eine sichere Transportverschlüsselung. Dieses Problem erkannten offensichtlich auch große Mailhoster wie Google, Microsoft und Verizon Media Company (Yahoo, AOL) sowie 1&1, welche sich an der Entwicklung des neuen MTA-STS -Standards beteiligen. MTA-STS soll das oft nicht realisierbare DANE sowie das weitverbreitete STARTTLS ersetzen, da die Angriffe auf die Verfahren nicht mit absoluter Sicherheit ausgeschlossen werden können. Der neue Standard verspricht einen ähnlich sicheren Standard wie bei DANE, jedoch eine wesentlich leichtere Implementierung als mit DNSSEC. Für die Nutzung des Standards können die Betreiber von E-Mail-Servern eine Policy definieren, die mittels HTTPS [RFC2818] vom sendenden Mail Transfer Agent (MTA) abgerufen werden kann. Die aktuelle Version wird durch einen TXT-Datensatz in der Policy angezeigt. Diese TXT-Datensätze enthalten zusätzlich ein ID-Feld, anhand dessen die sendende MTA die zwischengespeicherte Policy nach Aktualität prüfen kann, ohne dabei eine HTTPS-Verbindung anfordern zu müssen. Um herauszufinden, ob eine Empfängerdomäne MTA-STS implementiert, muss der Sender lediglich einen TXT-Datensatz auflösen und den TXX-Record mit dem Label „_mta-sts“, erkennen (z. B. „_mta-sts.example.com„).  Der wesentliche Unterschied zu DANE und STARTTLS ist, dass die Ergebnisse von DNS-Abfragen in einem Cache gespeichert werden, sodass Manipulationen bei späteren Verbindungsversuchen während der Vorhaltezeit mit sehr hoher Wahrscheinlichkeit aufgedeckt werden.

Fazit – Hornetsecurity bietet höchste E-Mail-Sicherheit

Aktuelle Ereignisse zeigen, dass die weitverbreiteten Sicherheitsprotokolle wie TLS allein keine sicheren Verbindungen zwischen E-Mail-Servern garantieren können. Bisherige Verbesserungen wie DANE und DNSSEC können sich u.a. aufgrund technischer Schwierigkeiten in der Umsetzung weltweit nicht flächendeckend ausdehnen.
Mit den standardisierten Absenderreputationsverfahren wie SPF, DKIM und DMARC bietet der E-Mail-Service von Hornetsecurity einen sicheren Schutz gegen Cyber-Angriffe auf die E-Mail-Kommunikation. Die vom BSI und TeleTrusT empfohlenen Standards zur sicheren E-Mail-Authentifizierung wurden bereits zuvor vollständig implementiert und finden erfolgreich Anwendung in den Hornetsecurity-Produkten wie dem Spam- sowie dem Content-Filter. Für eine sichere E-Mail-Kommunikation ist es sinnvoll auf den zusätzlichen Schutz der Inhaltsverschlüsselung mittels S/MIME (Secure / Multipurpose Internet Mail Extensions) oder PGP (Open Pretty Good Privacy) zu setzen. Die sogenannten PKI-basierten E-Mail-Verschlüsselungen stellen die Vertraulichkeit der übermittelten Nachrichten zwischen Absendern und Empfängern sicher und schützen die transportierten Daten mittels kryptografischer Verschlüsselungsmethoden. Der Hornetsecurity Verschlüsselungsservice bietet diesen Schutz direkt in der Cloud und sichert somit den Transportweg vollständig ab.
Der MTA-STS-Standard ist relativ neu und soll den Transportweg von E-Mails unter Zuhilfenahme bereits bekannter Techniken wie HTTPS besser schützen und Methoden zur Erkennung irregulärer Zugriffe bereitstellen. Die leichte Implementierung sowie die rasche Verbreitung steigern derzeit die Akzeptanz des Standards, dessen Sicherheitspotenzial momentan mehr und mehr Mail-Administratoren begeistert.

Literataur

[1] BSI – Bundesamt für Sicherheit und Technik: „E-Mail-Sicherheit“ In: EMPFEHLUNG: INTERNET-DIENSTLEISTER. [online] https://www.allianz-fuer-cybersicherheit.de (abgerufen am 03.12.2018). [2] ECO – Verband der deutschen Internetwirtschaft e. V.: „Gutachten zur Vereinbarkeit von DMARC mit dem deutschen Recht“. [online] https://www.eco.de/wp-content/blogs.dir/26/files/dmarc_rechtsgutachten.pdf (abgerufen am 03.12.2018) [3] Heise Developer: „Internet-Protokolle, Teil 1: TCP/IP, der Grundstein für Anwendungsprotokolle“. [online] https://www.heise.de/developer/artikel/Internet-Protokolle-Teil-1-TCP-IP-der-Grundstein-fuer-Anwendungsprotokolle-2548919.html?seite=all (abgerufen am 03.12.2018) [4] Heise Security: „Kryptographie in der IT – Empfehlungen zu Verschlüsselung und Verfahren“.[online] https://www.heise.de/security/artikel/Kryptographie-in-der-IT-Empfehlungen-zu-Verschluesselung-und-Verfahren-3221002.html?seite=all (abgerufen am 03.12.2018). [5] IEFF – Internet Engineering Task Force: „Sender Policy Framework (SPF) for Authorizing Use of Domains in Email“, [online] https://tools.ietf.org/html/rfc7208 (abgerufen am 03.12.2018) [6] IEFF – Internet Engineering Task Force: „Domain-based Message Authentication, Reporting, and Conformance (DMARC)“. [online] https://tools.ietf.org/html/rfc7489 (abgerufen am 03.12.2018) [7] IEFF – Internet Engineering Task Force: „DomainKeys Identified Mail (DKIM) Signatures“. [online] https://tools.ietf.org/html/rfc6376 (abgerufen am 03.12.2018) [8] IEFF – Internet Engineering Task Force: „SMTP MTA Strict Transport Security (MTA-STS)“. [online] https://tools.ietf.org/html/rfc8461 (abgerufen am 03.12.2018) [9] Stefan Cink | Net at Work GmbH: „SPF, DKIM, DMARC und DANE: E-Mail-Sicherheit durch geschützte Zustellung“. In: Management und Wissen. [online] https://www.nospamproxy.de/wp-content/uploads/E-Mail-Sicherheit-mit-Absenderreputation-durch-geschuetzte-Zustellung-Stefan-Cink.pdf (abgerufen am 03.12.2018) [10] Sven krohlas | BFK edv-consulting GmbH: „Umverpackung. E-Mails auf dem Transportweg schützen“. [online] https://www.heise.de/select/ix/2018/12/1543727185822371 (abgerufen am 03.12.2018)

Weiterführende Informationen: