Über die Webseite Gemeinsames Registerportal der Länder haben Unternehmen u.a. die Möglichkeit, eine Online-Abfrage des eigenen Handelsregisterauszuges anzufragen und zusenden zu lassen. Diese Dienstleistung ist gebührenpflichtig.
Nach der Abfrage des Handelsregisterauszuges im Juli 2020 fand Anfang August 2020 eine E-Mail mit der Absenderadresse gebuehrennachweis@handelsregsiter.de ihren Weg in den Posteingang meines Postfaches. Auf der Webseite des Registerportals wird auf die Warnhinweise der Landesjustizverwaltungen und des Bundesministeriums der Justiz hingewiesen. Dieser Hinweis war Grund genug, doch einmal einen ausführlichen Blick auf die E-Mail des Gebührennachweises zu werfen. Dieser Hinweis wird in der E-Mail sogar noch einmal wiederholt.
Die allgemeine und die technische Bewertung der E-Mail mit Dateianhang des Gebührennachweises als PDF-Datei war sehr ernüchternd. Ich wurde sofort an die problematischen E-Mail-Nachrichten im Zusammenhang mit der NRW Soforthilfe erinnert. Denn auch im Fall des Registerportals werden die E-Mail-Nachrichten von Systemen der IT.NRW versendet.
Bereits in der Übersicht des Posteingangs zeigte sich die E-Mail verhaltensauffällig. Die Absenderadresse der E-Mail-Nachricht verfügt über keinerlei Klartextnamen. Die Anzeige der E-Mail-Adresse alamierte mich sofort. Der Betrefftext der Nachricht förderte mein Misstrauen nur. Das Registerportal sendet anscheinend keine Einzelnachweise, sondern monatliche Zusammenfassungen.
Ein weiterer Punkt ist, dass es sich um eine technische Nachricht handelt, auf die man als Empfänger nicht direkt anworten soll. Solch ein Vorgehen ist für Empfänger in der Regel nicht nachvollziehbar und, aus meiner Sicht, heutzutage ebenfalls ein Indikator für eine E-Mail-Nachricht zweifelhafter Herkunft.
Anwender, die solch eine Nachricht erhalten, haben keinerlei Möglichkeit, die Integrität der Nachricht oder die Gültigkeit des Absenders zu überprüfen.
Der Blick in die technischen Informationen der E-Mail-Nachricht und die Prüfung wichtiger Basis-Sicherheitsfunktionen für die E-Mail-Kommunikationen zeigen eklatante Lücken auf, die heutzutage mit einfachen Mitteln vermeidbar sind.
Der erste Blick richtet sich immer auf die Kopfinformationen einer E-Mail-Nachricht. Wie schon im Falle der E-Mail-Nachrichten zur NRW Soforthilfe werden die Namen und IP-Adressen interner Systeme nicht aus den Kopfinformationen entfernt. Das Verhalten bei der Zustellung der E-Mail ändert sich durch das Entfernen der internen Topologieinformationen nicht. Jedoch stellen diese Informationen ein Sicherheitsrisiko dar. Potentielle Angreifer erhalten ausreichend Informationen über die Namensschema und IP-Adressen interner Systeme.
Das Entfernen interner Topologieinformationen ist bereits seit Jahren Stand der Technik, wird in diesem Fall jedoch nicht angewandt.
Nach der Auswertung der E-Mail-Kopfinformationen ist die Prüfung des DNS-Eintrages für den oder die E-Mail-Server der Domäne handesregister.de an der Reihe. Ich verwende hierzu immer die Werkzeuge der Webseite MX Toolbox.
Aus den Kopfinformationen können wir ablesen, dass das versendende System auf den Namen sbmail.it.nrw.de konfiguriert ist. Der Name wird vom öffentlichen Name Server auf die IP-Adresse 93.184.132.24 aufgelöst.
Die Prüfung des MX DNS-Eintrages ergibt leider andere Informationen.
Der Empfang von Nachrichten für die Domäne handelsregister.de erfolgt über den Namen postamt.it.nrw.de, der auf die IP-Adresse 93.184.132.233 aufgelöst wird. Dies stellt für E-Mail-Server die Nachrichten an Empfänger dieser Domäne senden, kein Problem dar. Für E-Mail-Server, die Nachrichten von handelsregister.de empfangen, ist dies jedoch problematisch.
Einer der Standardprüfungen, die E-Mail-Server beim Empfang einer Nachricht durchführen, ist die Prüfung, ob die einliefernde IP-Adresse mit der IP-Adressauflösung des MX-Eintrages übereinstimmt. Wenn dies, wie in diesem Fall, nicht zutrifft, erhöht dies automatisch der Wahrlichkeit, dass es sich um eine Spam-Nachricht handelt. Je mehr Absenderprüfungen fehlschlagen, desto höher ist die Wahrscheinlichkeit.
Die Tatsache, dass unterschiedliche System für den Versand und für den Empfang von E-Mail-Nachrichten verwendet werden, ist nicht ungewöhnlich. Um solch eine Konfiguration anderen E-Mail-Servern bekanntzumachen, gibt es eine technische Lösung; das Sender Policy Framework.
Das Sender Policy Framework (SPF) unterstützt die Möglichkeit, gültige Systeme für den Versand von E-Mail-Nachrichten einer einzelnen Domäne zu definieren. HIerzu wird in der DNS-Zone ein sog. SPF-Eintrag hinterlegt, der sowohl Namen als auch IP-Adressen gültiger Systeme enthalten kann. Zusätzlich ist es möglich, Referenzen auf SPF-Einträge anderer Domänen einzutragen, wenn diese ebenfalls E-Mail-Nachrichten für die Domäne versenden.
Die Domäne handelsrgister.de existiert kein SPF-Eintrag in der externen DNS-Zone.
Dies bedeutet, dass keine gültigen Systeme für den Versand von E-Mail-Nachrichten definiert sind. Empfangende Systeme haben keine Möglichkeit zur Prüfung und nehmen somit E-Mail-Nachrichten von beliebigen Systemen aus dem Internet entgegen. Dies stellt ein enormes Sicherheitsrisiko dar und kann als fahrlässige Fehlkonfiguration eingestuft werden.
Das Fehlen des SPF-Eintrages wird beim Empfang einer Nachricht von modernen Systemen als Verstoß gegen Industriestandards bewertet und führt automatisch zu einer Erhöhung der Spam-Wahrscheinlichkeit.
DKIM - Integrität der E-Mail-Kopfinformationen
Selbst wenn keine SPF-Informationen vorliegen, können in einer E-Mail die Empfänger- und Absenderinformationen abgesichert werden. Hierzu steht die Funktion DomainKeys Identified Mail (DKIM) zu Verfügung. Hierbei erfolgt eine Signierung dieser und andere Informationen der E-Mail. Das empfangende System hat die Möglichkeit, eine DKIM-signierte E-Mail-Nachricht mit Hilfe des DKIM-Eintrages in der DNS-Zone der sendenden Domäne zu prüfen.
Hierdurch wird sichergestellt, dass die Nachricht von einem System signiert wurde, dass über den privaten DKIM-Schlüssel verfügt. Absender ohne Zugriff auf den privaten Schlüssel haben keine Möglichkeit, solch eine Signierung durchzuführen.
E-Mail-Nachrichten der Domäne handelsregister.de werden nicht durch eine DKIM-Signierung geschützt. Somit haben empfangende Systeme keinerlei Möglichkeit, die Gültigkeit einer E-Mail-Nachricht der Domäne handelsregister.de zu prüfen.
Um den MIßbrauch von E-Mail-Nachrichten einzuschränken, wurde die Funktion DMARC (Domain-based Message Authentication, Reporting and Conformance) entwickelt. DMARC kann ergänzend zu SPF und DKIM eingesetzt werden. Auch DMARC wird über einen DNS-Eintrag in der Absender-Domäne definiert. Ein DMARC-Eintrag gibt dem empfangenden System Informationen, wie mit einer E-Mail zu verfahren ist, wenn die Validierung von SPF und DKIM fehlschlägt. Zusätzlich kann in einem DMARC-Eintrag festgelegt werden, an welche E-Mail-Adresse Benachrichtigungen über fehlerhafte E-Mail-Nachrichten gesendet werden sollen. Als Betreiber einer Domäne erhalte ich so Informationen, welche System in Internet meine Domäne als Absenderdomäne verwenden.
Da weder DKIM-, noch SPF-Einträge für die Domäne handelsregister.de vorhanden sind, fehlt auch ein DMARC-Eintrag.
Gerade im Hinblick auf die Sensibilität der Informationen, die über diese Domäne versendet werden, ist die Implementierung aller drei Schutzfunktionen drigend angeraten.
Ob eine Verschlüsselung der E-Mail-Nachricht an sich notwendig ist, kann man diskutieren. Sowohl Nachricht als auch der PDF-Dateianhang waren nicht verschlüsselt. Eine S/MIME Signierung der Nachricht, als Mindestmaß zur Sicherstellung der Integtrität des Absender, fehlte ebenfalls.
Das sendende System sbmail.it.nrw.de ist nicht für eigehende Verbindungen aus dem Internet konfiguriert. Die Prüfung des MX-Endpunktes für handelsregister.de offenbahrte die bereits bekannten TLS-Schwächen.
Der Test des TLS-Endpunkte erfolgte mit dem TLS-Scanner von ImmuniWeb.
Die schlechte Beurteilung hat mehrere Gründe:
TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA TLS_DH_anon_WITH_SEED_CBC_SHA TLS_ECDH_anon_WITH_RC4_128_SHA TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 TLS_DH_anon_WITH_AES_128_GCM_SHA256 TLS_DH_anon_WITH_AES_256_GCM_SHA384
Auch in diesem Fall ist es nicht möglich, ein postives Fazit zu ziehen. Im Vergleich zur Problematik der E-Mail-Nachrichten zur NRW Soforthilfe handelt es sich hier um E-Mail-Nachrichten, die zu einer bundesweit bereitgestellen Diensleistung gehören. Die Bundesländer und der Bund, die diese Dienstleistung in Anspruch nehmen, tun gut daran, sich für eine Verbesserung der Sicherheit im Umgang mit E-Mail-Nachrichten einzusetzen.
Die Möglichkeiten zur Verbesserung gliedern sich in zwei Bereiche.
SPF, DKIM und DMARC sind Industriestandards. Dass diese Funktionen nicht zum Schutz von E-Mail-Nachrichten verwendet werden, ist grob fahrlässig.
Im Hinblick auf eine eGovernment-Infrastruktur und ein Vertrauen in eine sichere (E-Mail-)Kommunikation besteht bei IT.NRW noch Nachholbedarf. Die aktuelle Konfiguration öffnet Tür und Tor für Betrüger und ist geradezu eine Einladung zum Versand von Phishing- und Malware-Nachrichten. Unternehmen, die Nachrichten von solchen Domänen empfangen, können sich nur durch eine explizite Abweisung der E-Mail-Nachrichten schützen. Andere Lösungsansätze führen immer manuellen Anpassungen auf der Empfängerseite und zu einem erhöhten Aufwand beim Betrieb einer sicheren IT-Infrastruktur.
Der Handlunsbedarf liegt eindeutig auf Seiten von IT.NRW.
Das E-Mail-Sicherheitsgateway NoSpamProxy untertützt die Anbindung an die De-Mail-Infrastruktur. Mit Hilfe von De-Mail ist eine gesetzlich geregelte Zustellung von rechtlich relevanten E-Mail-Nachrichten möglich. MIt Hilfe von NoSpamProxy kann Ihr Unternehmen E-Mail-Nachrichten mit De-Mail-Empfängern austauschen, ganz unabhängig davon, ob Ihre E-Mail-Server in der internen IT-Infrastruktur betrieben werden oder als SaaS-Dienst wie z.B. Office 365. In meinem Beispiel befinden sich alle Postfächer in Exchange Online.
Die Anbindung von De-Mail und Office 365 über das E-Mail-Gateway wird im nachfolgenden Schaubild deutlich.
Die zur Anbindung an Office 365 erforderlichen Komponenten, wie z.B: Azure AD Connect, sind im Diagramm nicht dargestellt, um die Übersichtlichkeit zu gewährleisten.
Das E-Mail-Gatewaysystem wird in diesem Beispiel auf einer Hyper-V-Plattform betrieben. Da die De-Mail-Zertifikate auf einer Smardcard gespeichert sind und der Betrieb des Gateways unbeaufsichtigt erfolgen soll, muss die Smartcard über einen zertifizierten Kartenleser permanent eingebunden werden. Entsprechende Smartcard-Lesegeräte sind als USB-Geräte erhältlich. Beim Erwerb einer De-Mail-Signaturkarte erhalten Sie einen passenden Kartenleser.
Die Verbindung des physikalischen Smartcard-Lesegerätes zum virtualisierten Betriebssystem erfolgt mit Hilfe eines USB-Servers. Für diesen USB-Server wird auf dem virtualisierten Betriebssystem eine Treiber-Software installiert, die einen virtualisierten USB-Port bereitstellt. Über diesen vUSB-Port ist anschließend das Smartcard-Lesegerät mit dem Betriebssystem verbunden. Zusätzlich werden noch die passenden Treiber und die Verwaltungssoftware für das De-Mail-Zertifikat benötigt.
Das folgende Schaubild verdeutlicht die technische Anbindung des Smartcard-Lesegerätes mit einem virtualisierten Betriebssystem.
System-Komponenten
Software-Komponenten
Die Anbindung an De-Mail erfolgt immer auf einem NoSpamProxy-System mit installierter Gateway-Rolle. Ob es sich um ein reines Gateway-System handelt oder aber um ein System mit installierte Intranet- und Gateway-Rolle ist unerheblich. In der nachfolgenden Beschreibung gehe ich davon aus, dass die NoSpamProxy Gateway-Software bereits installiert ist und die Nutzung von De-Mail lizensiert ist.
Installieren Sie zuerst den USB-Server und richten Sie das Smartcard-Lesegerät im Windows Server Betriebssystem ein. Die in diesem Artikel beschriebenen Schritte und zu installierenden Komponenten gelten für Windows Server 2012R2 und Windows Server 2016 identisch. Für Windows Server 2019 liegen noch keine Erfahrungen vor.
An diesem Punkt haben Sie das Smartcard-Lesegerät über den USB-Server und den virtuellen USB-Treiber der USB-Umlenkung mit dem Windows Server Betriebssystem verbunden. Bei jedem Neustart des Betriebssystems wird das Lesegerät automatisch verbunden.
Für die folgenden Installationsschritte und die Einbindung des De-Mail-Zertifikates ist es erforderlich, dass Sie eine Konsolenverbindung zum virtualisierten Betriebssystem herstellen. Die Einbindung des Smartcard-Zertifikates innerhalb einer RDP-Sitzung auf dem Windows Server nicht möglich, da dies durch den Windows Smartcard-Treiber aktiv verhindert. Sie erkennen dies daran, dass es beim Start des TCOS-CardManagers zu folgender Fehlermeldung kommt.
In einer VMware Hypervisor-Plattform ist der Zugriff über eine Konsolensitzung kein Problem. Wenn Sie aber Hyper-V als Hypervisor-Plattform einsetzen, müssen Sie auf die folgenden Einstellung des Hyper-V-Hostsystems achten.
Die Funktion "Erweiterten Situngsmodus zulassen" muss ausgeschaltet sein. Wenn diese Funktion eingeschaltet ist, werden alle Sitzungen durch das Gast-Betriebssystem als RDP-Sitzungen wahrgenommen. Dies führt automatisch dazu, dass der beschriebene Zugriff auf die Smartcard-Blibliotheken unterbunden wird. Diese Funktion muss nur für den Zeitraum der Konfiguration der De-Mail-Zertifikate in Windows Server ausgeschaltet sein bzw. immer dann, wenn Sie mit dem TCOS CardManager arbeiten müssen.
Folgende Schritte sind notwendig, um die TCOS-Smartcard und die De-Mail-Zertifikate zu integrieren:
Der die TCOS-Softwarekomponenten sind so programmiert, dass die De-Mail-Zertifikate beim ersten Zugriff auf die Signaturkarte in den lokalen Zertifikatsspeicher des angemeldeten Benutzers kopiert werden. Dieser Zertifikatsspeicher ist für installierte Softwarelösungen gänzlich ungeeignet. Die Zertifkate müssen in den Zertifikatsspeicher des Computers verschoben werden. Hierbei hilft Ihnen das Tool CertificatePromoter.exe, das Sie vom Net at Work-Support erhalten können.
Nachdem nun die De-Mail-Zertifikate im richtigen Zertifikatsspeicher abgelegt sind, muss der Zugriff auf die Zertifikate und die privaten Schlüssel konfiguriert werden. Die hierzu erforderlichen Schritte habe ich im Artikel "Zugriff auf privaten SSL-Schlüssel konfigurieren" beschrieben. Führen Sie die dort beschriebenen Schritte für die drei verschobenen De-Mail-Zertifikate durch.
Damit sind alle Voraussetzungen für eine funktionierende Anbindung des E-Mail-Security Gateways NoSpamProxy an De-Mail abgeschlossen. Die Konfiguration erfolgt in der NoSpamProxy MMC-Verwaltungsoberfläche im Menüpunkt Connected systems. Sie können entweder einen Telekom De-Mail-Connector oder einen Mentana-Claimsoft De-Mail-Connector hinzufügen.
Wenn alle Einstellungen und Konfiguration korrekt durchgeführt wurden, wird in der NoSpamProxy MMC-Verwaltungsoberfläche nach kurzer Zeit die Anzahl der zur Verfügung stehenden De-Mail-Domänen angezeigt. Diese Information wurde durch NoSpamProxy vom De-Mail-Gateway abgefragt und ist daher ein Beleg für die funktionierende Verbindung.
Ab diesem Punkt können Sie mit den weiteren Benutzer-Konfigurationen für De-Mail, entsprechend der NoSpamProxy Anleitung fortfahren.
Sollte es doch zu Problemen bei der Verbindung zum De-Mail-Gateway kommen, prüfen Sie bitte die folgenden Punkte:
Damit erschöpfen sich auch schon die allgemeinen Möglichkeiten zum Troubleshooting der De-Mail-Anbindung. In den meisten Fällen liegt ein Problem beim Verbindungsaufbau vor. Dies ist entweder die HTTPS-Strecke selbst oder aber die Aushandlung der TLS-Verschlüsselung (Handshake). Die Analyse des TLS-Handshake erfordert die Installation eines Werkzeuges zur Netzwerkanalyse, wie z.B. Wireshark oder Microsoft Message Analyzer.
# Prüfung der TLS-CipherSuite # Wird kein Ergebnis zurückgegeben, muss die CipherSuite aktiviert werden (Get-TlsCipherSuite) | Where-Object {$_.Name -eq 'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384'} # Alphabetische Auflistung der konfigurierten TLS-CipherSuites des OS Get-TlsCipherSuite | Sort-Object Name | FT Name # Aktivierung der CipherSuite Enable-TlsCipherSuite -Name TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 # Auflistung der aktivierten elliptischen Kurven # Wird die Kurve NistP521 nicht aufgeführt, muss sie aktiviert werden Get-TlsEccCurve # Aktivierung der ECC Kurve NistP521 Enable-TlsEccCurve NistP521 # Alle Änderungen an den TLS-Einstelliunge erfordern einen Neustart des Servers
Ich wünsche viel Spaß mit dem NoSpamProxy E-Mail-Sicherheitsgateway und De-Mail.
Im ersten Blog-Artikel dieser Miniserie wurde allgemein das Thema E-Mail Verschlüsselung und E-Mail Sicherheit besprochen. In diesem Artikel wird die Verschlüsselung des Übertragungsweges mit TLS genauer betrachtet.
E-Mail Sicherheit besteht nicht nur aus der Sicherung des Übertragungsweges zwischen den beteiligten Systemen, sondern auch aus der optionalen Verschlüsselung bzw. Signierung der Nachricht selber. Die Verschlüsselung des Übertragungsweges ist aber die Grundvoraussetzung für eine sichere Kommunikation und seit 1999 Stand der Technik.
Bei der Sicherung des Übertragungsweges erfolgt zwischen zwei Servern mit Hilfe der Transport Layer Security (TLS). TLS ist das Nachfolgeprotokoll des Secure Socket Layer (SSL) Protokolls und wird gegenwärtig in der Version 1.2 eingesetzt. Hierbei handelt es sich um ein zertifikatsbasiertes Protokoll, das zur Sicherung von unterschiedlichen TCP Protokollen verwendet wird. Hierzu zählen u.a. POP3, IMAP, SIP, SMTP, HTTP oder LDAP.
Die grundsätzliche Implementierung des TLS Protokolls und aller Protokolleinstellungen ist Teil des Server-Betriebssystems (Windows Server) und nicht der verwendeten E-Mail Software. Ausgeführte Konfigurationen wirken sich somit auf alle Applikationen auf dem Server aus. Der vierte Blog-Artikel dieser Reihe beschreibt die Konfiguration und die Auswirkungen im detaillierter.
Bei der Verwendung von TLS ist nur die Kommunikation zwischen zwei Servern (Sender und Empfänger) verschlüsselt. In den jeweiligen Unternehmensnetzen ist es möglich, dass die Übertragung zwischen anderen beteiligten Systemen unverschlüsselt erfolgt. Von einer unverschlüsselten Kommunikation, also ohne Verwendung von TLS, ist auch innerhalb eines Unternehmensnetzwerkes dringend abzuraten.
Einfache Darstellung der TLS Kommunikation zwischen zwei E-Mail Systemen:
Diese einfache Darstellung lässt sich beliebig in seiner Komplexität erweitern. Im nachfolgenden Beispiel wird gezeigt, dass auf der Sender-Seite eine interne Lösung zur Anti-Malware Erkennung betrieben wird, während auf der Empfänger-Seite eine Cloud-basierte Lösung im Einsatz ist.
Im vorstehenden Beispiel können Sie als Sender nur die Verbindung zwischen der Anti-Malware Lösung und dem Cloud-Anbieter überwachen und prüfen. Den Status und die Konfiguration zwischen dem Services des Cloud-Anbieters und dem E-Mail Server des Empfänger können Sie nicht kontrollieren.
Auch wenn alle Verbindungen "TLS verwenden", so können die verwendeten Verschlüsselungsmechanismen (Cipher Suite, Hashes, Signature) für jede der TLS Verbindungen unterschiedlich sein. Somit ist auch jede der Verbindungen unterschiedlich "sicher".
In der Grundkonfiguration führt TLS nur Grundprüfungen der verwendeten Zertifikate durch. Hierzu gehört u.a., ob das Zertifikat zeitlich noch gültig ist. Eine Überprüfung, ob das Zertifikat vielleicht zwischenzeitlich zurückgezogen wurde und daher ungültig ist, gilt bereits als erweiterte Prüfung. Solch eine erweiterte Prüfung ist Aufgabe der eingesetzten E-Mail Software.
Das TLS Protokoll selber ist anfällig für Man-In-The-Middle Angriffe und wird daher als nicht 100% sicher eingestuft. Hintergrund ist, dass es zweifelhafte Zertifizierungsstellen gibt, die Zertifikate ohne genaue Prüfung herausgeben. Hierdurch können sich unberechtigte Dritte als jemand anderes ausgeben (siehe Linkliste). Das Risiko lässt sich nur dadurch minimieren, indem auf den eigenen Systemen die fragwürdige Zertifizierungsstellen deaktiviert werden.
Gerade die unterschiedlichen Konfigurationen der TLS Sicherheit führen im täglichen Betrieb immer wieder zu Problemen. Wenn ein Server mit einer "zu sicheren" Konfiguration betrieben wird, kann es zu "Verständigungsproblemen" mit einem Server auf der anderen Seite kommen. Ist der empfangende Verbindungsendpunkt nun so konfiguriert, dass TLS erforderlich ist, so kommt keine Verbindung Zustande und die Nachricht kann nicht zugestellt werden. Ist wiederum TLS als optional konfiguriert, so wird die Nachricht on TLS Verschlüsselung übertragen. Hieraus ergibt sich die Notwendigkeit, zwei unterschiedliche Endpunkte zu betreiben:
Interne Systeme - das unbekannte Risiko
Interne Applikationen und Systeme stellen ein großes Risiko dar, wenn sie nicht in der Lage sind, unternehmenskritische Kommunikation mit Hilfe von TLS Verschlüsselung zu einem internen E-Mail Server zu übertragen. Noch kritischer ist die Situation, wenn interne Applikationen oder Systeme direkt mit Systemen außerhalb des Unternehmensnetzwerkes kommunizieren und nicht über Verschlüsselungsfunktionen verfügen. Als beispielhafte interne Applikationen oder Systeme seien genannt:
Es wird deutlich, dass das Thema E-Mail Sicherheit nicht isoliert betrachtet werden kann, sondern vielmehr mit einer ganzheitlichen Betrachtung der gesamten IT-Landschaft einhergeht.
Ein Serversystem mit einer aktuellen E-Mail Software und aktiviertem TLS zu betreiben reicht nicht aus, um die E-Mail Sicherheit für ein Unternehmen zu gewährleisten. Neben den rein technischen Aspekten zur sicheren Konfiguration der TLS Implementierung müssen auch organisatorische Aspekte zur Kommunikation mit Partnerunternehmen geklärt und festgeschrieben werden.
Technik ist ein Hilfsmittel zur Sicherstellung der Sicherheit. Sie befreit nicht von einer sorgsamen Planung und Dokumentation (auch zur Auditzwecken) der E-Mail Umgebung.
Um die Sicherheit der Kommunikation zu Erhöhen, können Nachrichten nicht nur sicher übertragen, sondern digital signiert und/oder verschlüsselt werden. Hierzu stehen die Technologien S/MIME oder PGP zur Verfügung. Im nächsten Blog-Artikel befassen wir uns mit diesen beiden Technologien.
Haben Sie Fragen rund um das Thema E-Mail Verschlüsselung und E-Mail Sicherheit? Kontaktieren Sie uns unter: emailsecurity@granikos.eu.
Es gibt zahlreiche Gründe, warum externe Dienstanbieter E-Mails unter Verwendung einer E-Mail-Dömane eines Kunden senden. Beispielhafte Anwendungsfälle sind z.B.:
Die Nutzung einer E-Mail Domäne, die ein Unternehmen bereits in Verwendung hat, birgt Risiken. Bei der Nutzung durch einen Marketing-Dienstleister, der hauptsächlich E-Mail-Nachrichten an externe Empfänger sendet, treten die Probleme noch nicht so deutlich hervor. Werden jedoch Dienste in Anspruch genommen, die eine Zustellung von E-Mail-Nachrichten an interne Mitarbeiter notwendig machen, kommt es zu Problemen.
Eine der einfachsten Funktionen im Rahmen des E-Mail-Grundschutzes ist die Abweisung von E-Mails, die eine eigene Domäne (Accepted oder Owned Domain) als Absender verwenden.
Das nachfolgende Schaubild verdeutlicht die Situation.
Das Unternehmen in diesem Beispiel nutzt die E-Mail Domäne varunagroup.de als primäre E-Mail-Domäne. Der Dienstanbieter nutzt die Adresse news@varunagroup.de als Absenderadresse. E-Mail-Nachrichten an externe Empfänger können meist problemlos zugestellt werden, insofern der SPF-Eintrag des Dienstanbieters in der externen DNS-Zone varunagroup.de eingetragen ist. Die E-Mail-Sicherheitslösung am Gateway verweigert jedoch die Annahme von E-Mail-Nachrichten an interne Empfänger, da nur interne Systeme unter der Domäne varunagroup.de senden dürfen.
Am E-Mail-Gateway können natürlich Ausnahmen konfiguriert werden. Diese sind aber von Natur aus aufwändig in der Wartung und und sehr fehleranfällig.
Das Problem kann durch Nutzung von Subdomänen einfach und elegant gelöst werden.
Externe Dienstleister nutzen für den Versand von E-Mail-Nachrichten anstatt der Domäne varunagroup.de die neu konfigurierte Subdomäne email.varunagroup.de. In der zur DNS-Zone der Subdomäne werden der zugehörige SPF-Eintrag des Dienstleisters und alle erforderlichen DKIM-Einträge verwaltet.
Das nachfolgende Schaubild verdeutlicht den Unterschied zum ersten Schaubild.
Das Unternehmen nutzt weiterhin die Domäne varunagroup.de als primäre E-Mail-Domäne. Für externe Dienstanbieter wurde aber die Subdomäne email.varunagroup.de eingerichtet. Somit versendet der externe Dienstanbieter in diesem Beispiel E-Mail-Nachrichten mit der Absenderadresse news@email.varunagroup.de. Für externe Empfänger ändert sich hierdurch nichts. Für das E-Mail-Sicherheitsgateway des Unternehmens ändert sich aber alles. Die Absenderdomäne email.varunagroup.de ist ist eine vollwertige externe Domäne, die durch SPF und DKIM abgesichert wurde und entspricht keiner internen Domäne. Alle E-Mail-Nachrichten des Dienstanbieters werden angenommen und an interne Empfänger zugestellt.
Bei Bedarf kann für jeden externen Dienstanbieter eine separate Subdomäne konfiguriert werden. Dieses Vorgehen ist ein wenig aufwendiger, bietet jedoch ein verbesserte Kontrolle der DNS-Konfiguration.
Die nachfolgenden Präsentationen verdeutlichen die Problemstellung und die Lösungsmöglichkeiten.
Richten Sie für externe Dienstanbieter, die unter Ihrer E-Mail-Domäne Nachrichten versenden sollen, immer Subdomänen ein. Für Unternehmen, die Office 365 und Exchange Online nutzen, ist die Empfehlung mit der beschriebenen Subdomänen-Konfiguration zu arbeiten. Ansonsten wird Exchange Online Protection (EOP) E-Mails von externen Dienstanbietern abweisen.
Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.
Sie denken über einen vollständigen Wechsel zu Microsoft 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.
Sie möchten mehr über Exchange Server 2019 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop. Bis dahin, werfen Sie doch einen Blick in das Microsoft Exchange Server 2019: Das Handbuch für Administratoren.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu
Foto von Miguel Á. Padriñán von Pexels.
In den vorherigen Blog-Artikeln wurde allgemein über die Herausforderungen beim Thema E-Mail Sicherheit, die Möglichkeiten der TLS Übertragungsverschlüsselung und der E-Mail Signierung und Verschlüsselung mit S/MIME gesprochen.
In diesem Blog-Artikel werden die Verschlüsselungskomponenten beschrieben, die sowohl für die Sicherung des Übertragungskanals, als auch für die Nachrichtenverschlüsselung verwendet werden. Der Schwerpunkt des Artikels liegt auf der Security Provider Implementierung von Microsoft.
Secure Channel ist das Security Support Provider Interface (SSPI) von Microsoft und wird von den unterschiedlichen Betriebssystemen bei Authentifizierungsvorgängen und bei verschlüsselter Kommunikation verwendet. Die unterstützen Verschlüsselungsalgorithmen variieren sehr stark, je nach Version des verwendeten Betriebssystems.
Eine sog. Cipher Suite beschreibt ein Sammlung von kryptografischen Algorithmen, die zur Schlüsselerstellung, Schlüsselaustausch und zur Verbindungsherstellung verwendet werden. Im Regelfall verwenden Softwarekomponenten auf Windowssystemen (Client und Server) die SCHANNEL Konfigurationen zur Verschlüsselung und Abwicklung der Kommunikation.
Jede zur Verfügung stehende Cipher Suite beschreibt eine festgelegte Kombination von
Die von Windows Server 2012R2 unterstützten Cipher Suites sind:
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
SSL_CK_RC4_128_EXPORT40_MD5
SSL_CK_DES_64_CBC_WITH_MD5
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521
Diese Suites werden zwar unterstützt, stehen aber nach einer Standardinstallation des Betriebssystems nicht zur Verfügung. Hierzu muss die SCHANNEL Konfiguration per Registry angepasst werden. Mehr dazu im Abschnitt "SCHANNEL Konfiguration".
Der Aufbau einer TLS Verbindung gliedert sich in 4 Schritte:
In der nachfolgenden Beschreibung entspricht der Client dem sendenden (Verbindung aufbauenden) System und der Server dem empfangenden System.
Hinweis: Bei der Konfiguration der Cipher Suites Reihenfolge sollte darauf geachtet werden, dass zwar zuerst Suites mit PFS konfiguriert werden, jedoch ein Fallback ohne PFS ebenfalls angeboten wird.
Die Cipher Suite Reihenfolge legt fest, welche Suite zuerst und welche zuletzt verwendet werden soll.
In der Windows Systemregistrierung die zur Verfügungen stehenden Cipher Suites nach einer Basis Installation nicht konfiguriert. Der nachfolgende Screenshot zeigt den Registrierungsschlüssel SCHANNEL.
Einzig die zur Verfügung stehenden Protokolle (SSL/TLS) sind konfiguriert.
Die verfügbaren Cipher Suites und die eigentliche Reihenfolge der Suites werden in zwei unterschiedlichen Registrierungsschlüsseln konfiguriert.
Verfügbare Cipher Suites: HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002
Reihenfolge der Cipher Suites: HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
Hinweis: Der Registrierungsschlüssel für die Liste der Cipher Suites ist begrenzt auf 1023 Zeichen.
HINWEIS: Die direkte und eventuell fehlerhafte Anpassung der Windows Registry kann zur Instabilität des Betriebssystems führen. Die nachfolgende Beschreibung erfolgt nach bestem Wissen. Jedoch können wir keine Haftung für eventuelle Schäden übernehmen.
Die Konfiguration der Cipher Suites erfolgt im nachfolgenden Beispiel unter Verwendung des Tools IIS Crypto.
IIS Crypto ist ein Hilfsmittel, um die Konfiguration in der Windows Registry einfacher zu gestalten. Jedoch muss man bei Einsatz bedenken, dass beim Start des Programmes nicht die tatsächlich vorhandene Konfiguration der Systemregistrierung ausgelesen und angezeigt wird, sondern vielmehr die Standardkonfiguration von IIS Crypto.
IIS Crypto bietet vorkonfigurierte Konfigurationen für:
Nach der Anpassung der Cipher Suite Konfiguration (im nachfolgenden Beispiel die Best Practices Konfiguration), sind die neuen Schlüssel und Parameter in der Systemregistrierung vorhanden.
Je nach Typ (Protokoll oder Cipher Komponente) werden zur Aktivierung bzw. Deaktivierung folgende Schlüssel verwendet:
Eine Beschreibung zur manuellen Konfiguration der Systemregistrierung finden Sie bei Microsoft hier: http://support2.microsoft.com/default.aspx?scid=kb;EN-US;245030
Wenn eine besonderen Anforderungen an die Absicherung der Server-Kommunikation mit externen Systemen besteht, was eigentlich immer der Fall ist, muss eine zusätzlich Konfiguration des Secure Channel Providers erfolgen. Im Normallfall kann die einheitlich über Gruppenrichtlinien erfolgen. Verwenden Sie aber Systeme, die keine Mitgliedsserver einer Domäne sind, so müssen diese Systemen manuell über die Systemregistrierung oder durch Verwendung der lokalen Sicherheitsrichtlinie erfolgen.
Die Konfiguration des Secure Channel hat eine direkte Auswirkung auf die TLS Verschlüsselung aller TCP Protokolle. Durch die unterschiedlichen Implementierungen bei unterschiedlichen Betriebssystemen müssen die Anpassungen mit Bedacht durchgeführt werden.
Sollte es Gründe geben, dass Sie eine FIPS- oder PCI-konforme Konfiguration vornehmen müssen, gibt es allerdings keine Alternative zur Umsetzung der Vorgaben.
Über das Desaster der Antragstellung für die NRW Soforthilfe 2020 wurde schon viel geschrieben und konnte den Eindruck gewinnen, dass Maßnahmen zum Schutz der Kommunikation und gegen weitere Betrugsversuche unternommen werden. Augenscheinlich hatte man nur die Antragstellung über das Online-Formular im Blick. Die dazugehörige E-Mail-Kommunikation der Bezirksregierung Köln war und ist aktuell nicht Bestandteil grundlegender Schutzmaßnahmen.
Das folgende Beispiel einer empfangenen E-Mail der Bezirksregierung Köln mit dem Absender Corona-Soforthilfe@bezreg-koeln.nrw.de habe ich zum Anlass genommen, mir die Konfiguration der Absenderdomäne einmal genauer anzuschauen. Die Ergebnisse sind beängstigend.
Ausgangspunkt der Recherche ist die empfange E-Mail-Nachricht. In dieser sind alle benötigten Informationen enthalten.
Eine E-Mail-Nachricht besteht, wie ein klassicher Brief, aus zwei Teilen. Zum einen gibt es den Umschlag, der alle Zustellinformationen, enthält, und als Zweites den Inhalt, der die lesbaren Informationen und vielleicht auch Dateianhänge für dem Empfänger bereithält.
Für eine genauere Betrachtung der E-Mail-Zustellung sind die Informationen des Umschlages, die sog. Kopfinformationen, von großem Interesse. Ich habe diese Informationen mit Hilfe des Message Header Analyzers von Microsoft in ein besser lesbares Format gebracht. Der nachfolgende Screen zeigt die wichtigsten Kopfinformationen der E-Mail:
Besonders interessant sind die rot umrandeten Zeilen 1 - 10. Diese Zeilen geben uns Aufschluss über alle beteiligten internen Systeme der IT.NRW, die als zentraler IT-Dienstleister für die Bezierksregierung Köln tätig ist. Die unkenntlich gemachten Textstellen beinhalten Informatioen über:
Als eine der einfachsten Schutzfunktionen für E-Mail-Nachrichten, die an externe Empfänger gesendet werden, werden die Informationen interner Systeme aus dem Kopfinformationen der E-Mail entfernt. Hierdurch wird sichergestellt, dass keine Informationen über interne Computeradressen oder -name nach aussen gelangen. Diese Informationen lassen u.U. Rückschlüsse zu, die eine möglichen Hackerangriff begünstigen können. Moderne E-Mail-Systeme entfernen solche Informationen mit Hilfe einer Header-Firewall aus einer E-Mail.
Idealerweise hätten die Kopfinformationen mit dem grünumrandeten Eintrag aus Zeile 11 begonnen. Das dort als Submitting Host eingetragene System ist das für die externe Zustellung verantwortliche System.
Die Informationen der Zeilen 1 -10 gehören nicht in eine externe E-Mail.
Nach einem Blick auf die Kopfinformationen der E-Mail geht es mit einer Prüfung der technischen Einstellungen für die E-Mail-Kommunikation der Absenderdomäne bezreg-koeln.nrw.de weiter.
Die einfachste Prüfung einer Absenderdomäne ist die Überprüfung auf E-Mail-Systeme für den Empfang von E-Mail-Nachrichten. In den meisten Fällen sind die diese Systeme auch für den Versand von Nachrichten zuständig. Wenn eine Domäne auch E-Mail-Nachrichten empfängt, muss sie über mindestens einen speziellen DNS-Eintrag verfügen. Mit Hilfe eines DNS-Eintrages vom Typ MX wird festgelegt, welche Systeme E-Mail-Nachrichten von anderen Absendern empfangen.
Der folgende Screenshot zeigt das Ergebnis der Überprüfung der MX-Einträge vom 6. Mai 2020.
Für die Domäne bezreg-koeln.nrw.de werden zwei Systeme mit unterschiedlicher Präferenz (Pref-Spalte) aufgeführt. Das System mit Präferenz 60 hat gegenüber dem zweiten System die höhere Priorität und wird daher bevorzugt von zustellenden Systemen angesprochen. Sollte das System nicht antworten, erfolgt ein Zustellversuch an das zweite System mit Präferenz 80.
Ein besonderes Augenmerk gilt den IP-Adressen der Systeme. In den Kopfinformationen der E-Mail hatte das sendende System die Adresse 93.184.128.152. Diese Adresse gehört zu keinem beiden aufgeführten Systeme. Damit ist klar, dass es noch weitere E-Mail-Systeme gibt, die augenscheinlich nur für den Versand verwendet werden. Aber dazu im nächsten Abschnitt mehr.
Eine weitere wichtige Information wird uns von MXToolbox ebenfalls mitgeteilt. Die Domäne verfügt über keinen DMARC-Eintrag. Was das ist und warum es gut ist, solch einen Eintrag vorzuhalten, erkläre ich weiter unten.
MX-Einträge sind für die E-Mail-Kommunikation existenziell. Neben diesem Eintragstyp gibt es noch weitere, die eine E-Mail-Kommunikation sicherer machen können. Kommen wir daher zur IP-Adresse des sendenden Systems zurück.
Ein System, das E-Mail-Nachrichten empfängt, verfügt über keinerlei Informationen, welche Systeme für den Versand einer Domäne berechtigt sind. Als Eigentümer einer Domäne kann ich mit Hilfe eines SPF-Eintrages definieren, welchen Systemen es explizit erlaubt ist, für meine Domäne E-Mail-Nachrichten zu versenden.
Der folgende Screenshot zeigt das Ergebnis der SPF-Prüfung für die Domäne bezreg-koeln.nrw.de vom 6. Mai 2020.
Es ist kein SPF-Eintrag vorhanden. Empfangende E-Mail-Systeme haben keine Möglichkeit zur Überprüfung des sendenden Systems. MIt dem Fehlen dieses Eintrages wird der Versand von betrügerischen E-Mail-Nachrichten begünstigt, wenn nicht sogar wissentlich in Kauf genommen.
Das Vorhandensein eines SPF-Eintrages stellt keinen vollständigen Schutz dar. Dazu bedarf es noch weiterer Maßnahmen. Jedoch ist die Nutzung eines SPF-Eintrages seit Jahren Stand der Technik.
Moderne E-Mail-Systeme und Anti-Spam-/Anti-Mailware-Lösungen bewerten das Nichtvorhandensein eines SPF-Eintrages immerhin mit einer Erhöhung der Spam-Wahrscheinlichkeit. Dies kann u.U. dazu führen dass Nachrichten der Bezirksregierung Köln nicht im Posteingang, sondern im Junk-E-Ordner landen.
Es gibt auch Positives zu berichten.
Der Name eines E-Mail-Systems ist nicht das einzige Merkmal, auf das ein empfangendes System achtet. Im Normalfall wird ein Computername zu einer numerischen Conmputeradresse aufgelöst. Es gibt aber auch das genaue Gegenteil, die sog. Rückwärtsauflösung. Das empfangende System versucht hierbei die numerische Computeradresse zu einem Namen aufzulösen. Dies erfolgt mit Hilfe eines sog. PTR-Eintrages, der im DNS des Internet-Leitungsanbieters erfolgt. Ist diese Auflösung erfolgreich und der gefundende Name entspricht dem Computernamen der Verbindung, gilt die Identität des Systems als einfach bestätigt.
Der folgende Screenshot zeigt die Ergebnis für die IP-Adressen der beiden MX-Einträge.
Beide System verfügen über einen zum Computernamen passenden PTR-Eintrag.
Als Abschluss der aktiven Tests erfolgte eine Prüfung der E-Mail-Verbindung zu einem der beiden Systeme mit MX-Eintrag. HIer gibt es wenig Auffälliges zu berichten.
Die Nutzung von HTML-Tags (<br />) in einem Server-Banner ist unüblich und eher hinderlich. E-Mail-Server erwarten eine klare Kennung des Status und des Computernamens. In diesem Fall wird der Status 220 und der Name relay1v.it.nrw.de gleich zweimal in einer Textzeile zurückgegeben. Es wird sicherlich Systeme geben, die dies als nicht protkollkonformes Format bewerten.
Der folgende Screenshot zeigt das Ergebnis des SMTP-Tests.
Der E-Mail-Server unterstützt verschlüsselte Verbindungen und lässt, wie die Liste der unterstützten Befehle zeigt, weitere E-Mail-Befehle erst nach dem Aufbau einer verschlüsselten Verbindung zu. Ob die Unterstützung des ETRN Befehls zeitgemäß ist, kann man diskutieren. Es wird sicherlich technische Anforderungen auf Seiten der IT.NRW geben, die dies erfordern.
Es fehlen allerdings zwei wichtige Komponenten, um E-Mail-Nachrichten der Domäne bezreg-koeln.nrw.de sicherer zu machen. DMARC und DKIM.
Die zu Anfang besproche Prüfung der MX-Einträge hat gezeigt, dass kein DMARC-Eintrag vorhanden ist. Ein DMARC-Eintrag legt für eine Domäne, in diesem Fall wäre es für bezreg-koeln.nrw.de, fest, ob und wenn ja welche Informationen ein empfangender E-Mail-Server über E-Mails dieser Domäne sammeln soll. Hierdurch ist es möglich, Fehlerberichte zu erhalten und so festzustellen, welche unberechigten Systeme im Internet E-Mail-Nachrichten im Namen der Bezirksregierung Köln versenden. Solch ein Eintrag fehlt vollständig.
DMARC ist aber nur im Zusammenspiel mit SPF- und DKIM-Einträgen sinnvoll. Die Funktion und die Wichtigkeit eines SPF-Eintrages habe ich schon besprochen. Kommen wir zu DKIM.
Die Aufgabe von DKIM ist Sicherstellung einer vertrauensvollen E-Mail-Zustellung. Diese Sicherstellung bezieht sich auf den E-Mail-Umschlag. Das empfangende System erkennt, dass der E-Mail-Umschlag mit Hilfe einer DKIM-Signierung gesichert wurde. Hierzu hat das Absendersystem Umschlagsinformationen mit einem Schlüssel, der nur auf dem Absendersystem exisitert, signiert. Das Empfangssystem findet den öffentlichen Schlüssel wiederum als besonderen DNS-Eintrag. Mit diesem Schlüssel können nun die Signaturinformation aufgelöst und anschließend überprüft werden. Hierdurch wird die Integrität des Absendersystems für die Domäne sichergestellt.
DKIM selbst ist kein neuer Standard für die Sicherung von E-Mail-Nachrichten. Alle großen E-Mail-Anbieter prüfen eingehenden E-Mail-Nachrichten auf DKIM-Signaturen.
Dies ist kein Ersatz für eine mögliche und auch notwendige Verschlüsselung des E-Mail-Inhaltes. Der im Übrigen ebenfalls nicht stattfindet.
Kommen wir zum Abschluss noch zur Verbindungsverschlüsselung.
Der folgende Screenshot zeigt das Ergebnis der Verschlüsselungsfunktionen im Hinblick auf gängige Industriestandards.
Das Ergegbis ist in amerikanischer Notenstufe (A-F) dargestellt, wobei ein A einer Schulnote 1 entspricht. Mehr muss nicht gesagt werden.
Der Hauptgrund für die schlechte Note liegt darin, dass die E-Mail-Systeme alte und unsichere Verbindungsprotokolle und Verschlüsselungstechnologien unterstützen. Diese unsicheren Protokolle und Verschlüsselungen sollten im Jahr 2020 nicht mehr aktiv sein.
Die aktuelle Konfiguration der E-Mail-Umgebung der Bezirksregierung Köln und anderer Behörden, die diese IT-Plattform nutzen, kann durch Betrüger ausgenutzt werden. Einfachste Konfigurationen für sichere E-Mail-Kommunikation, die seit Jahren Stand der Technik sind, finden keine Anwendung. Hier wird, meiner Einschätzung nach, grobfahrlässig gehandelt. Betrügerische E-Mail-Nachrichten können ohne Probleme im Namen der Bezirksregierung Köln versendet werden.
In der Pflicht ist nicht nur die Bezirksregierung Köln, sondern vielmehr der Landesbetrieb IT.NRW, der als zentraler IT-Dienstleister für zahlreiche Behörden und Dienststellen auftritt. Hier muss etwas passieren, um Bürger für betrügerischen E-Mail-Nachrichten, nicht nur im Zusammenhang der NRW Soforthilfe, zu schützen. Alle Behörden und Dienststellen in NRW, die auf eine sichere E-Mail-Kommunikation mit Bürgern und Unternehmen vertrauen und hierzu die Dienstleistungen der IT.NRW in Anspruch nehmen, sollten die für sie gültigen Einstellungen dringend überprüfen lassen.
E-Mail-Nachrichten der NRW Soforthilfe 2020 werden als Klartext versendet, obwohl sie persönliche Informationen enthalten und somit einem besonderen Schutzbedürfnis unterliegen. Der Einsatz einer sog. Gateway-basierten E-Mail-Verschlüsselung kann hier schnell und einfach Abhilfe schaffen. Ebenso ist die Implementierung von SPF, DKIM und DMARC Pflicht.
Ich wünsche mir, dass IT.NRW die Absicherung der E-Mail-Kommunikation ernster nimmt und ihrer Verantwortung, auch als Vorbildfunktion, nachkommt. In der heutigen Zeit vertrauen Bürger auf die IT-Sicherheit, die propagiert wird. Im Rahmen der NRW-Soforthilfe hat dieses Vertrauen sehr gelitten.
Ohne eine Verbessung der E-Mail-Sicherheit, ist dem Betrug weiterhin Tür und Tor geöffnet.
Um die Antwort direkt vorwegzunehmen, De-Mail ist keine Erfolgsgeschichte.
Mir stellt sich allerdings immer wieder die Frage, warum De-Mail keine Erfolgsgeschichte geworden ist. Die ursprüngliche Idee, verschlüsselte E-Mail-Nachrichten für jeden Bürger zu ermöglichen, um damit die Digitalisierung von Bürgerdiensten voranzutreiben war gut. Im Rückblick auf den Entstehungsprozess und das daraus resultierende De-Mail-Gesetz vom 28. April 2011 kann man nur festhalten, dass eine gute Idee den Kernproblemen im Umgang mit (IT-)Technologie in Deutschland geopfert wurde.
Als Kernprobleme sind insbesondere zu nennen:
Der Anspruch von De-Mail ist, dass jede verwendete E-Mail-Adresse eine verifizierte E-Mail-Adresse ist. Der Nutzer einer solchen E-Mail-Adresse ist somit eineindeutig identifizierbar. Dies gilt für Privatpersonen mit einer persönlichen E-Mail-Adresse ebenso wie für Firmen mit Unternehmens-Adressen für Dienste und Mitarbeiter. Dies steht im direkten Gegensatz zu herkömmlichen E-Mail-Adressen.
Die Ausarbeitung der De-Mail-Infrastruktur erfolgte in einem Elfenbeinturm und das Ergebnis war, im Hinblick auf die einfache Nutzung durch den Bürger, desaströs. Für Unternehmen wiederum war und ist die Anbindung an die De-Mail-Infrastruktur immer noch ein Drama. Die De-Mail-Anbindung von Behörden und deren Erreichbarkeit über eine De-Mail-Adresse ist ähnlich schlecht.
Für die Bundesverwaltung ist die Einführung und Nutzung von De-Mail verpflichtend über das E-Government-Gesetz geregelt. Die Einführung sollte zum 1. Quartal 2016 abgeschlossen sein1. Mit wem möchte die Bundesverwaltung über De-Mail kommunizieren? Die Realität sieht anders aus. Anstatt eine etablierte Lösung zu verwenden, erfolgt die bundesweite E-Mail-Kommunikation über das Netz des Bundes, in dem eine Verschlüsselung des Übertragungsweges (TLS SMTP) als ausreichend betrachtet wird. Eine einheitliche Nachrichtenverschlüsselung für die Kommunikation zwischen Behörden ist nicht verpflichtend geregelt.
In den Ländern und Kommunen sieht es nicht besser aus. De-Mail findet schlichtweg nicht statt.
Die immer angeführten Vorteile und möglichen Einsparpotentiale gegenüber der klassischen Briefpost wurden und werden ignoriert. Vergessen Sie nicht, dass das De-Mail-Gesetz die rechtliche Gleichstellung einer De-Mail-Zustellung mit der klassischen Briefpost regelt. Dies ist übrigens auch der Grund, warum die Post seinerzeit als De-Mail-Anbieter ausgestiegen ist.
Aber war da nicht noch eine andere besondere Lösung zum Austausch von besonders schützenswerten E-Mail-Nachrichten? Sie erinnern sich bestimmt an die andere deutsche Erfolgsgeschichte: Das besondere elektronische Anwaltspostfach (beA).
Ich habe mich von Anfang an gefragt, warum die Kommunikation zwischen Anwaltskanzleien und Gerichten nicht per De-Mail erfolgt. Sicher wird nun jemand darauf hinweisen, dass die technische Implementierung der De-Mail-Intrastruktur dem Anspruch zum Schutz der anwaltlichen Daten gerecht wird. Dies ist, aus meiner Sicht, ein fadenscheiniges Argument, da eine technische Anpassung möglich gewesen wäre. De-Mail wäre auf jeden Fall sicherer als die klassische Fallback-Lösung für termingerechte Zustellung an Gerichte, die Fax-Übertragung.
Gerade im Hinblick auf die Zustellung von anwaltlichen E-Mail-Nachrichten an Gerichte möchte ich eine Erfahrung mit Ihnen teilen. In mindestens einem Bundesland erfolgt die E-Mail-Kommunikation zwischen Kanzleien und Gerichten klassisch per SMTP über das Internet. Als Absicherung ist auch hier die Transportverschlüsselung ausreichend, solange eine E-Mail-Nachricht nach technischem Eingang unverändert in das Richter-Postfach zugestellt wird. Eine Nachrichtenverschlüsselung ist nicht erforderlich. Eine Nachrichtenverschlüsselung wird als zu kompliziert erachtet.
Bei der Einführung von De-Mail war besonders wichtig, dass keine De-Mail-Pflicht für die Kommunikation von Bürgern mit Behörden eingeführt wurde. Mit dem Verzicht auf eine De-Mail-Pflicht hätte man sich De-Mail auch sparen können. Eine freiwillige De-Mail-Registrierung haben nur wenige Bürger durchgeführt, nicht zuletzt auch wegen des aufwendigen Prozesses zur Prüfung der Identität. Die strengen Anforderungen zur Prüfung der Identität für De-Mail sind dem BSI anzulasten. Die Eröffnung eines neuen Bankkontos per Video-Ident ist erheblich einfacher.
Aber war da nicht noch etwas?
Was ist mit der inzwischen verpflichtend aktivierten Online-Ausweisfunktion des neuen Personalausweises (eID)?
In der Anfangsphase der Einführung des neuen Personalausweises war die Aktivierung der Online-Ausweisfunktion freiwillig. Völlig unerwartet hat sich gezeigt, dass die Mehrheit der Bürger an der Nutzung dieser Funktion kein Interesse hat. Inzwischen ist die Aktivierung dieser Funktion verpflichtend und soll dazu beitragen, dass wir mehr Bürgerdienste online nutzen. Leider hat die Bundesregierung dabei vergessen, dass die Aktivierung der Online-Ausweisfunktion nicht ausreicht. Jeder Bürger, der diese Funktion nutzen möchte, benötigt entweder ein passendes eID-Lesegerät für den PC/Mac oder aber eine spezielle App für das Mobiltelefon.
Wäre es mit der verpflichtenden Aktivierung der Online-Ausweisfunktion nicht ein genialer Schachzug gewesen, jedem Ausweisinhaber auch eine De-Mail-Adresse zu geben, falls noch keine vorhanden ist? Eine einfachere Prüfung der Identität kann ich mir nicht vorstellen.
So bleibt für den Bürger der fahle Beigeschmack, dass alle Bestrebungen hinsichtlich eGovernment unkoordiniert nebeneinander existieren und eine sinnvolle Integration gar nicht gewollt ist.
Welche einfachen Möglichkeiten gibt es nun, wenn Sie, als Bürger oder Unternehmen, E-Mail-Nachrichten verschlüsseln möchten und De-Mail keine Option ist?
Das kommt ganz darauf an, mit wem Sie kommunizieren möchten.
Die sicherste Methode ist die Verschlüsselung mit Hilfe eines Zertifikates, einem sog. S/MIME-Zertifikat. Solche Zertifikate sind meist kostenpflichtig und es bedarf einiger Kenntnis. um diese richtig ausstellen zu lassen und in der eigenen E-Mail-Software zu integrieren. Daher ist diese Methode auch bei Privatanwender selten in Nutzung. Für Unternehmen besteht die Möglichkeit, die E-Mail-Verschlüsselung mit Hilfe eines Gateways zu realisieren. Eine E-Mail-Verschlüsselung ist jedoch nur möglich, wenn sowohl Absender und Empfänger über ein gültiges Zertifikat verfügen. Der entscheidende Vorteil ist natürlich, dass die Möglichkeit für Absender und Empfänger weltweit zur Verfügung steht.
Office 365 bietet Ihnen die Möglichkeit, mit Hilfe der Office 365 Message Encryption (OME), E-Mail-Nachrichten zu verschlüsseln und diese an Empfänger zu senden, die nicht über ein S/MIME-Zertifikat verfügen. Um diese Funktion zu nutzen, benötigen Sie als Unternehmen natürlich ein Office 365/Microsoft 365 Abonnement. Für Privatpersonen ist diese Funktion auch Bestandteil von Office 365 Personal bzw. Office 365 Home. Die Benutzererfahrung als Empfänger einer OME-geschützten Nachricht ist allerdings gewöhnungsbedürftig.
Ist PGP eine Option? Nein.
PGP ist eine fälschungsanfällige Verschlüsselungslösung, die ihre Zeit hatte. Als IT-affiner Anwender ist eine PGP-Integration möglich. Für den Normalanwender ist sie, ebenso wie S/MIME, leider viel zu komplex. Im Gegensatz zur Nutzung von S/MIME erfordert PGP immer die INstallation von zusätzlichen Softwarekomponenten, die oft nur unzureichend in Standard-Mail-Clients integriert sind.
E-Mail-Nachrichten unverschlüsselt zu senden ist grob fahrlässig, insbesondere für Unternehmen (Stichwort: DSGVO). Die technischen Anforderungen an E-Mail-Verschlüsselung sind für Privatpersonen oftmals zu komplex. De-Mail könnte uns hier zwar helfen, ist aber wegen der fehlenden Unterstützung durch Behörden und Unternehmen in Deutschland keine Option. Leider.
Prüfen Sie bei Ihrem E-Mail-Anbieter, ob für Ihr persönliches E-Mail-Konto eine Möglichkeit zur E-Mail-Verschlüsselung zur Verfügung steht.
Als Unternehmen ist eine E-Mail-Verschlüssung alternativlos. Es gibt zahlreiche Lösungen am Markt, mit denen Sie eine Gateway-basierte Verschlüssung zum Schutz persönlicher Daten und Unternehmensinformations umsetzen können.
Wenn Ihr Unternehmen bisher keine De-Mail-Schnittstelle hat, denken Sie sich einmal darüber nach, solch eine Schnittstelle einzurichten.
Der größte Teil der De-Mail-Kommunikation ist übrigens Maschine-zu-Maschine-Kommunikation. Unternehmen tauschen auf diesem Weg, rechtlich abgesichert, automatisch zu verarbeitende Daten zwischen Softwaresystemen aus.
Verschlüsseln Sie Ihre E-Mail-Nachrichten. Wenn Sie bisher Ihre E-Mail-Nachrichten nicht verschlüsseln, fangen Sie noch heute damit an.