Hier gibt’s nichts zum Abfischen
E-Mail-Sicherheit: Mit technischen Vorkehrungen können Unternehmen vermeiden, dass Kriminelle in ihrem Namen betrügerische E-Mails versenden.


Immer wieder warnen Behörden, Institutionen und Unternehmen vor betrügerischen E-Mails, die Kriminelle in ihrem Namen versenden. Oft sind diese Nachrichten mit angehängten „Fake-Rechnungen“ versehen. Die Empfänger werden zu Überweisungen im Namen der vermeintlichen Absender aufgefordert. In den letzten Monaten stieg die Anzahl derartiger Fälle rasant an und es ist davon auszugehen, dass der entstandene Schaden enorm ist.
Doch warum fallen Internet-Nutzer immer noch auf diese Betrugsmaschen herein? Sollte nicht längst ein Bewusstsein für solche Angriffe vorhanden sein? In den letzten Jahren gab es zahlreiche Aufklärungskampagnen zu diesem Thema. Eine der Kernbotschaften dieser Kampagnen ist immer dieselbe: „Achten Sie auf die Absender-Adresse der empfangenen E-Mail!“ Doch genau an dieser Stelle setzen in letzter Zeit die Angreifer nun vermehrt an: Sie versenden ihre E-Mails nicht mehr (massenhaft) einfach über kryptisch aussehende E-Mail-Adressen, die damit leicht als betrügerische Mails erkennbar sind. Sondern sie versenden diese Nachrichten mit den „echten“ E-Mail-Adressen der vermeintlichen Sender – beispielsweise mit der Absenderadresse „@nuernberg.de“, um einen Absender der Stadt Nürnberg vorzugaukeln. Die Empfehlung der Stadt Nürnberg, die Absenderadresse bei den empfangenen E-Mails mit den Fake-Rechnungen zu prüfen, lief damit ins Leere.
Doch wie ist es überhaupt möglich, dass Mails mit einer scheinbar echten Mail-Adresse versandt werden? Dies liegt an der Beschaffenheit des Übertragungs-Protokolls, das der E-Mail-Kommunikation zugrunde liegt und das keinerlei Sicherheit bietet. Damit ist es u. a. auch sehr einfach möglich, die Absenderadressen von E-Mails zu fälschen und damit im Namen von Unternehmen oder Behörden E-Mails zu versenden. Dies macht es für die Empfänger nahezu unmöglich, diese Nachrichten als gefälscht zu erkennen. Es ist vielmehr erstaunlich, dass Angreifer erst jetzt diese Schwachstelle vermehrt ausnutzen, wo dieses Problem doch seit Jahrzehnten besteht.
Ist die Situation damit hoffnungslos? Keineswegs. Seit Jahren gibt es technische Maßnahmen, die das sogenannte E-Mail-Spoofing (also den Versand von E-Mails im Namen der eigenen Organisation) wirksam verhindern.
SPF: Das Sender Policy Framework (SPF) erlaubt es dem Inhaber einer Domain (z. B. „nuernberg.de“), im Domain Name System (DNS) einen Eintrag zu hinterlegen. In diesem wird festgehalten, von welchem E-Mail-Server aus E-Mails „im Namen der Stadt Nürnberg“ (also mit der Endung @nuernberg.de) versendet werden dürfen. Diese Festlegung basiert auf IP-Adressen. Geprüft wird beim Empfang einer E-Mail: Der empfangende E-Mail-Server „sieht“, dass eine E-Mail vermeintlich von nuernberg.de eingeht. Er prüft dann, ob nuernberg.de einen SPF-Eintrag im DNS hinterlegt hat. Ist dies der Fall, prüft der Mail-Server, ob die IP-Adresse aus dem Eintrag mit jener des E-Mail-Servers übereinstimmt, der die E-Mail gerade einliefert. Stimmen die IP-Adressen nicht überein, handelt es sich um eine E-Mail mit gefälschtem Absender und der E-Mail-Server kann sie direkt verwerfen, sodass sie dem Empfänger nicht zugestellt wird. Voraussetzung ist allerdings, dass der Inhaber der Domain @nuernberg.de dies in der sogenannten „hardfail“-Policy im SPF-Eintrag festgelegt hat.
DKIM: Das „Domain Keys Identified Mail“-Protokoll (DKIM) stellt einen weiteren Baustein dar, um die Authentizität in der E-Mail-Kommunikation sicherzustellen. Der sendende E-Mail-Server signiert dabei ausgehende E-Mails mit seinem privaten Schlüssel. Der zugehörige öffentliche Schlüssel wird wiederum im DNS abgelegt. Geprüft wird auch bei DKIM wieder beim empfangenden E-Mail-Server: Dieser prüft, ob die Signatur der eingehenden E-Mail gültig ist, d. h. ob sie tatsächlich vom behaupteten E-Mail-Server stammt und ob sie auf dem Transportweg manipuliert wurde. Den öffentlichen Schlüssel, der zur Prüfung nötig ist, besorgt sich der empfangende E-Mail-Server aus dem DNS. Stimmt die Signatur nicht, kann die E-Mail direkt verworfen werden.
DMARC: Die „Domain-based Message Authentication, Reporting and Conformance“-Spezifikation baut auf SPF und DKIM auf. Sie erlaubt dem Inhaber einer Domain, im DNS einen Eintrag zu hinterlegen, der festlegt, wie ein empfangener E-Mail-Server reagieren soll, wenn die SPF- und/oder DKIM-Prüfung bei einer eingehenden E-Mail fehlschlägt. Erhält der eingehende E-Mail-Server also beispielsweise eine E-Mail, die vermeintlich von nuernberg.de stammt und bei der eine oder beide Prüfungen (SPF/DKIM) fehlgeschlagen sind, erkennt er am Eintrag aus dem DNS von nuernberg.de, wie er die E-Mail behandeln soll. Hat die Stadt Nürnberg korrekterweise einen „reject“-Eintrag im DNS hinterlegt, wird der empfangende E-Mail-Server die gefälschte E-Mail automatisch verwerfen.
Technische Möglichkeiten oft nicht genutzt
Diese Verfahren sind längst Stand der Technik und sollten von Unternehmen und Behörden umgesetzt werden. Doch in der Praxis zeigt sich, dass es noch großen Nachholbedarf gibt. Immerhin hat eine aktuelle Analyse von 4 000 E-Mail-Servern von deutschen Gesundheitseinrichtungen ergeben, dass erfreulicherweise bereits 80 Prozent der Arztpraxen und Krankenhäuser einen SPF-Eintrag im DNS hinterlegt haben (Studie der Forschungsgruppe von Prof. Dr. Ronald Petrlic an der TH Nürnberg). Aber lediglich knapp ein Viertel aller untersuchten E-Mail-Server hat eine wirksame „hardfail“-Policy im Einsatz, die tatsächlich vor Spoofing-Mails schützt. Noch schlechter sieht es bei DMARC aus: Lediglich ein Viertel der untersuchten Mail-Server hat überhaupt einen DMARC-Eintrag hinterlegt und nur acht Prozent haben eine wirksame „reject“-Policy (detaillierten Ergebnisse unter www.mail-sicherheit.jetzt).
E-Mail-Provider machen Druck
Die großen E-Mail-Provider machen Ernst und fordern von sendenden E-Mail-Servern die Implementierung der genannten Maßnahmen. Bereits seit Anfang 2024 müssen E-Mail-Server, die E-Mails an Gmail- oder Yahoo-Konten senden, SPF oder DKIM implementieren. Für „Großversender“, die mehr als 5 000 E-Mails pro Tag an Gmail- oder Yahoo-Konten senden, gelten schärfere Regeln: Diese müssen SPF und DKIM implementieren und einen DMARC-Eintrag gesetzt haben. Diese Umstellung führte letztes Jahr bereits dazu, dass Unternehmen Probleme mit der Zustellbarkeit ihrer Mails hatten. Betroffen war beispielsweise der Heise-Verlag, der von Google als „Spam-Schleuder“ eingestuft wurde und einen Monat lang keine E-Mails mehr an Gmail-Konten senden konnte.
Nun hat auch Microsoft nachgezogen und angekündigt, dass ab 5. Mai 2025 ähnliche Anforderungen für sendende E-Mail-Server gelten, die E-Mails an Microsoft-Konten senden. Auch wenn die Anforderungen der großen Mail-Provider noch nicht ganz so streng sind – so werden beispielsweise keine Vorgaben zu den konkreten Policies gegeben – so ist dies ein Schritt in die richtige Richtung. Gefälschte E-Mails sind das Einfallstor Nummer eins für Phishing und Ransomware. Deshalb stellt die Umsetzung der Maßnahmen einen wichtigen Baustein zum Schutz aller dar. Es ist davon auszugehen, dass die Mail-Provider die Anforderungen in naher Zukunft weiter verschärfen werden und schärfere Policy-Vorgaben machen werden.
Unternehmen sollten also handeln und die Spoofing-Schutzmaßnahmen zügig umsetzen. Sonst riskieren sie bei weiteren Verschärfungen der E-Mail-Provider Probleme mit der Zustellbarkeit. Potenzielle Empfänger sollten wirksam vor gefälschten E-Mails geschützt werden. Nicht zu unterschätzen ist auch der Reputationsschaden durch Spoofing-Mails: Eine öffentlichkeitswirksame Warnung vor Fake-Mails, die im Namen des eigenen Unternehmens im Umlauf sind, möchte man sich vielleicht lieber ersparen.
Prof. Dr. Ronald Petrlic hat die Professur Informationssicherheit an der TH Nürnberg inne. Daneben ist er Inhaber der Petrlic Consulting GmbH und berät Unternehmen zu Fragen der Informationssicherheit und des Datenschutzes. Der Artikel basiert auf einem Vortrag bei einem IHK-Webinar zur E-Mail-Sicherheit (www.datensicherheit.digital).
Autor: Prof. Dr. Ronald Petrlic
Webcode: N1540