März 14, 2024
Leadership vs. Management, wo genau liegen da die Unterschiede? Und was braucht es in beiden Bereichen, um den aktuellen Herausforderungen
In unserem ersten Artikel zum Thema E-Mail Spoofing haben wir das Sender Policy Framework (SPF) und die Methode DomainKeys Identified Mail (DKIM) als Möglichkeiten zur Absicherung von E-Mail Servern vorgestellt. Für die Prüfung der SPF- und DKIM-Funktionen und das Erstellen entsprechender Regeln und Maßnahmen wurde der Domain-based Message Authentification, Reporting and Conformance (DMARC) Standard angesprochen. Diesen Standard erläutern wir in diesem zweiten Artikel genauer. Außerdem gehen wir auf weitere Maßnahmen zur Absicherung deines E-Mail Servers gegen Spam-, Phishing- und Relay-Angriffe ein.
E-Mail ist das meistgenutzte Arbeitswerkzeug in Unternehmen und leider auch das anfälligste. Neben Spam und Phishing sind es oft schädliche Anhänge und Links, die der IT-Abteilung und dem Management schlaflose Nächte bescheren. Die einfachste Möglichkeit, dich vor solchen Problemen zu schützen, ist das vollständige Sperren von Anhängen. Dies würde den Arbeitsfluss in den meisten Unternehmen jedoch zu stark beeinflussen.
Es gibt daher eine andere Lösung: Beim Eingang müssen möglichst alle potenziell schädlichen Mails geblockt oder in Quarantäne geschickt werden, bevor jemand unbedarft auf darin enthaltene Links klicken oder Anhänge herunterladen kann. (Grundsätzlich sollte in deinem Unternehmen für alle gelten: „Think before you click!“)
SPF und DKIM schützen nur, wenn der empfangende E-Mail Server beim Fehlschlag der entsprechenden Prüfungen geeignete Maßnahmen ergreift. Wir zeigen dir, wie du als Domain-Inhaber den Standard für Domain-based Message Authentification, Reporting and Conformance (DMARC) nutzen kannst, um Handlungsempfehlungen für diese Fälle festzulegen.
DMARC ist ein Standard, der auf Initiative mehrerer großer Tech-Firmen (z. B. Google und Microsoft) zur Verhinderung von Spoofing-Attacken entwickelt wurde. Er ergänzt SPF und DKIM um wichtige Verhaltensrichtlinien für den Fall, dass eine Prüfung dieser Records fehlschlägt.
Eine Besonderheit von DMARC ist, dass diese Handlungsempfehlungen nicht vom Empfänger, sondern vom Absender definiert werden. Du als legitimer Domain-Inhaber kannst also präventiv festlegen, was mit Mails passieren soll, die angeblich aus deiner Domain kommen, den SPF/DKIM-Check jedoch nicht bestehen: Sollen sie normal behandelt werden, im Spam Ordner landen oder gänzlich verworfen werden?
Ein weiterer wichtiger Bestandteil von DMARC ist die Möglichkeit, Adressen für den automatischen Empfang von Reports anzugeben. Diese geben eine Einsicht in die Statistik versendeter Mails. So kannst du beispielsweise im Blick halten, wie viele Mails aus deiner Domain in letzter Zeit im Spam Verzeichnis von Empfängern gelandet sind. Dies kann Aufschluss über eine eventuelle Fehlkonfiguration oder schädliche Nutzung deiner Domain geben. Wir empfehlen dir, diese Berichte unter Zuhilfenahme von Tools zur visuellen Aufbereitung regelmäßig zu überprüfen, um auf dem neuesten Stand zu bleiben.
Wie SPF und DKIM arbeitet auch DMARC mit TXT Resource Records im DNS-Server des Absenders und baut auf diesen Einträge auf. Es ist also nicht sonderlich sinnvoll, nur einen DMARC Eintrag allein zu setzen. Innerhalb dieses Records liegt die DMARC Policy, mit welcher der Domain-Inhaber mitteilt, dass Nachrichten von ihm durch SPF und/oder DKIM gesichert sind. Gleichzeitig kann er dem Empfänger durch vordefinierte Regeln eine Empfehlung geben, wie er mit nicht authentifizierten Nachrichten verfahren soll.
Beispielsweise kannst du eine Subdomain „_dmarc“ einrichten und dort den entsprechenden Resource Record setzen. Innerhalb dieses Records kannst du mehrere Werte anlegen. Diese trennst du durch ein Semikolon voneinander. Viele der möglichen Eintragungen sind optional. Lediglich die Protokollversion („v“), sowie die Policy, wie mit Mails der Hauptdomain zu verfahren ist („p“), musst du verpflichtend angeben. Wir empfehlen allerdings dringend, auch die E-Mail-Adresse zum Empfang der Reports („rua“) anzugeben. So kannst du analysieren, welche Mails weggefiltert werden.
Bei der Einführung von DMARC solltest du (ähnlich wie bei der Implementierung von Firewall-Instanzen) behutsam und schrittweise vorgehen. Grundsätzlich besteht die Möglichkeit, den Prozentsatz der Mails, auf die die DMARC Policy angewendet wird, auf 100% zu setzen. Davon raten wir jedoch zu Beginn ab. Für den Anfang ist es vollkommen ausreichend, nur den DMARC Record zu setzen und die „pct“ Variable auf „0“ zu setzen. Das eröffnet die Möglichkeit, DMARC Reports zu empfangen, ohne dass es eine direkte Auswirkung auf die Zustellung der Mails hat.
Sobald du ausreichend Informationen gesammelt hast, kannst du den Prozentsatz allmählich steigern. So wendest du die Policy schrittweise auf mehr Mails an und erhöhst so den Schutz vor Spoofing.
DMARC ist der bis dato erste und einzige Standard, der den „From-Header“ einer Mail auf Validität überprüft. Dies ruft neben der gewünschten Steigerung der Sicherheit jedoch auch unerwünschte Nebeneffekte hervor. Dies liegt daran, dass DMARC sehr strenge Anforderungen setzt. Zum Beispiel muss eine versandte Mail zwangsweise unverändert weitergeleitet werden.
Dies führt beispielsweise bei den üblichen Mailinglisten zu Problemen: Mit DMARC ist es nicht mehr so einfach möglich, den „From-Header“ der Mail auszutauschen. Wenn du dich dafür entscheidest, musst du die DKIM-Signatur mit entfernen. Ansonsten kann der Empfänger diese nicht erfolgreich verifizieren. Je nach Einstellung der Mail-Flow Regeln des empfangenden Servers gehst du dabei wiederum das Risiko ein, dass die Mail aufgrund der fehlenden Signatur gar nicht ankommt.
Im folgenden Abschnitt stellen wir dir die Authenticated Received Chain (ARC) vor, durch die du dieses Problem in den Griff bekommen kannst.
ARC setzt genau am großen Nachteil der Striktheit von DMARC an: Es ermöglicht einem Mail-Relay-Server das Signieren der ursprünglichen Authentifizierung der versendeten E-Mail. Dies gibt dem Empfänger einer Mail die Möglichkeit, den Ursprung der Mail zu verifizieren, ohne die (durch die Weiterleitung ungültigen) SPF- und DKIM-Records in Betracht zu ziehen. Vertrauen spielt hierbei eine große Rolle, da die ARCs gefälscht werden können. Der Empfänger muss also festlegen, ob er den ARC-Signaturen vertraut oder nicht.
Reverse Domain Name System (reverse DNS/ rDNS) Anfragen helfen dem empfangenden E-Mail Server, die Authentizität des Senders zu bestätigen. Dies geschieht folgendermaßen: Vor dem Empfangen des gesamten E-Mail Bodies werden die Header Informationen geprüft. Außerdem wird eine DNS Abfrage mit der Sender-IP und der im HELO Command angegebenen Domain gestellt. Sollte der autoritative DNS Server keinen (passenden) Pointer-Eintrag (PTR Record) für die Sender-IP haben, wird die E-Mail verworfen oder in den Spam-Bereich verschoben.
Über die Sender Restriction kann ein Domain-Inhaber festlegen, welche Nutzer innerhalb seiner Domain E-Mails „nach draußen“, also über die eigene Domain hinaus, versenden dürfen. Am Beispiel von Postfix erklärt kommen hier zwei verschiedene Lookup-Table zum Einsatz: Eine Tabelle, in der alle User mit Beschränkungen aufgeführt werden, und eine weitere, in der alle “lokalen” Domains definiert werden. Möchte ein eingeschränkter Nutzer nun eine Mail an eine Domain versenden, die in der Config nicht als lokal gekennzeichnet wurde, wird er mit einer generischen Meldung abgewiesen.
Wie bereits angesprochen kannst du für deine Domain verschiedene Regelwerke nutzen, die dir den Umgang mit Spam und anderen E-Mails erleichtern. Anschaulich kannst du dir das so vorstellen: Vor deinem Briefkasten steht ein Mitarbeiter, der jeden eingeworfenen Brief anhand eines von dir definierten Regelwerks prüft. Auf dieser Grundlage entscheidet er, ob der Brief wirklich im Briefkasten landen soll oder nicht. Solltest du in letzter Zeit beispielsweise viel nervige Werbung von einer bestimmten Werbeagentur bekommen haben, kannst du beispielsweise sagen: „Alle Briefe, die einen Absender von diesem Firmenstandort haben, kannst du ohne weitere Prüfung in den Müll werfen.“
Genau so funktionieren digitale E-Mail-Transport Regeln. Du kannst, je nachdem welche Appliance oder Anbieter du nutzt, verschiedene Regelwerke aufstellen.
Ein häufiger Trugschluss ist die Annahme, dass das Simple Mail Transfer Protocol (SMTP) ausschließlich auf Port 25 zu Hause ist und nur dieser Port dafür zuständig ist. Dies war in den Anfangszeiten des Internets der Fall. Mittlerweile hat sich das Spektrum jedoch erweitert: Neben Port 25 sind auch die Ports 465 und 587 für die Behandlung von E-Mails zuständig.
Warum ist das für dich von Bedeutung? Je nachdem, welche Ports geöffnet sind und welche Konfigurationen greifen, können E-Mails je nach genutztem Port anders behandelt werden. Folgende Konfiguration wäre beispielsweise möglich: Mails, die dem Server auf Port 587 übergeben werden, durchlaufen vorgegebene Sicherheitsprüfungen. Auf Port 465 können Mails jedoch unbehandelt eingereicht werden.
Dies sind die Besonderheiten aller für SMTP relevanten Ports:
STARTTLS st ein 1999 vorgestelltes Verfahren zum Herstellen einer verschlüsselten Kommunikation mittels Transport Layer Security (TLS). Mittlerweile wird von der Nutzung von STARTTLS abgeraten, da der initiale Kommunikationsaufbau bis zur eigentlichen verschlüsselten Kommunikation im Klartext verläuft. Daher ist er anfällig gegenüber Man-In-The-Middle oder sogenannten „Downgrade“ bzw. „STRIPTLS“ Angriffen. Diese Angriffe setzen voraus, dass sich der Angreifer bereits vor Beginn der eigentlichen Kommunikation erfolgreich als Man-In-The-Middle positioniert hat, um den Aufbau einer gesicherten Verbindung zu unterbinden.
Die empfohlene Alternative ist der direkt gesicherte Verbindungsaufbau via TLS über die vordefinierten Ports. Hierbei wird nicht im Klartext kommuniziert und die Verwendung von TLS ausgehandelt, sondern die Kommunikation beginnt direkt mit dem TLS-Handshake.
Wie genau würde ein Downgrade/STRIPTLS Angriff ablaufen?
Ein Angreifer schaltet sich zwischen eine laufende Kommunikation und beginnt damit, Traffic mitzuschneiden. Sollte der Angreifer eine beginnende SMTP-Kommunikation abfangen können, schnappt er sich das STARTTLS Paket. In diesem teilt der zuständige Mail-Server dir mit, dass er verschlüsselt kommunizieren möchte und ersetzt den Inhalt durch eine beliebige Zeichenkette, die der Client nicht versteht. Der Client kann daraufhin davon ausgehen, dass es sich dabei um eine Option handelt, die er nicht versteht, und fällt auf die Verwendung von Klartext zurück.
Ein Open Relay ist oft ein fehlerhaft konfigurierter SMTP-Server, der das Versenden und Weiterleiten von E-Mails ohne vorherige Authentifizierung ermöglicht. Es gibt zwar Voraussetzungen, die die interne Verwendung von Open Relay erfordern. (Ein typisches Beispiel ist hier die oft genutzte Scan-to-Mail Funktion.) Nach Möglichkeit sollte das Problem jedoch behoben werden, statt eine Lücke als Workaround zu nutzen.
Ein Open Relay ermöglicht es einem Angreifer beispielsweise, über diesen Server E-Mails mit gefälschten Absenderinformationen zu versenden. Leider findet man heute immer noch einige solcher Server.
Wenn ein Open Relay so unsicher ist, warum existiert diese Möglichkeit dann überhaupt?
Wie viele ältere Protokolle (wie z. B. auch DNS) stammt SMTP aus einer Zeit, in der das Internet als solches noch sehr jung und voll von unsicheren Konfigurationen und Standards war. Zielsetzung war es, eine möglichst hohe Verfügbarkeit der Dienste sicherzustellen. Die „normale“ Post versucht auch, Briefe um jeden Preis zuzustellen. Es konnte sich zu dieser Zeit einfach niemand vorstellen, dass SMTP einmal für den Massenversand von Spam genutzt werden würde.
Viele sind mittlerweile auf sichere Konfigurationen und Anbieter umgestiegen, aber einige solcher Legacy-Systeme existieren noch. Die kann man nicht einfach „abklemmen“ und von der Kommunikation ausschließen.
Leadership vs. Management, wo genau liegen da die Unterschiede? Und was braucht es in beiden Bereichen, um den aktuellen Herausforderungen
Sollten Standard-Nutzer in deinem Tenant eine Azure App Registration durchführen dürfen? Die Antwort ist ganz klar “Nein” und dieser Artikel
Die schlechte Nachricht vorweg: In Deutschland gibt es keine zentrale landesweite Notrufnummer für gehackte Unternehmen oder Behörden. Darum ist es
