12. Sicherheitsüberlegungen

Dieser Abschnitt behandelt DMARC-spezifische Sicherheitsüberlegungen.

12.1. Authentifizierungsmethoden

DMARC basiert auf SPF und DKIM. Die Sicherheit von DMARC hängt daher von der Sicherheit dieser zugrunde liegenden Mechanismen ab. Implementierer sollten mit den Sicherheitsüberlegungen sowohl von SPF [SPF] als auch von DKIM [DKIM] vertraut sein.

Wichtige Punkte:

1. SPF-Sicherheit: SPF kann umgangen werden, wenn ein Angreifer E-Mails über einen im SPF-Eintrag autorisierten Server senden kann.

2. DKIM-Sicherheit: DKIM-Signaturen können gefälscht werden, wenn der Signaturschlüssel kompromittiert wird. Schlüsselverwaltung ist kritisch.

3. Kombinierte Sicherheit: DMARCs Anforderung an Identifier Alignment bietet eine stärkere Authentifizierung als SPF oder DKIM allein.

12.2. Angriffe auf Berichts-URIs

Ein Angreifer könnte versuchen, Mail-Empfänger dazu zu bringen, große Mengen von Berichten an die Adresse eines Opfers zu senden, indem er:

1. Einen DMARC-Eintrag für eine Domain unter der Kontrolle des Angreifers mit der Adresse des Opfers in den "rua"- oder "ruf"-Tags veröffentlicht.

2. Große Mengen nicht authentifizierter E-Mails sendet, die behaupten, von dieser Domain zu stammen.

Der in Abschnitt 7.1 beschriebene Verifizierungsmechanismus verhindert diesen Angriff, indem er verlangt, dass externe Berichtsziele die Berichtsbeziehung explizit autorisieren.

Zusätzlich sollten Mail-Empfänger:

• Ratenbegrenzung bei der Berichtserstellung implementieren
• Auf ungewöhnliche Berichtsmuster überwachen
• Abmeldeanfragen von Berichtsempfängern respektieren

12.3. DNS-Sicherheit

DMARC verlässt sich stark auf DNS für die Richtlinienverteilung. DNS-Sicherheitsüberlegungen umfassen:

1. DNS-Spoofing: Ein Angreifer, der DNS-Antworten fälschen kann, könnte:

   • Eine falsche DMARC-Richtlinie bereitstellen
   • Berichte an eine vom Angreifer kontrollierte Adresse umleiten
   • Denial of Service verursachen, indem Richtlinieneinträge entfernt werden

2. DNSSEC: Die Verwendung von DNSSEC kann DNS-Spoofing-Risiken mindern. Implementierer sollten erwägen, DNSSEC für Domains bereitzustellen, die DMARC-Richtlinien veröffentlichen.

3. Cache-Poisoning: DNS-Cache-Poisoning könnte dazu führen, dass falsche DMARC-Richtlinien zwischengespeichert und angewendet werden.

12.4. Display-Name-Angriffe

DMARC schützt nicht vor Angriffen auf den Display-Name-Teil des RFC5322.From-Feldes. Ein Angreifer kann einen Display-Namen verwenden, der vertrauenswürdig erscheint, während er eine andere Domain in der Adresse verwendet:

From: "Vertrauenswürdige Bank" <[email protected]>

Benutzer sehen möglicherweise nur "Vertrauenswürdige Bank" und bemerken die tatsächliche sendende Domain nicht. Diese Einschränkung wird in Abschnitt 2.2 ausdrücklich als außerhalb des Geltungsbereichs vermerkt.

Benutzerschulung und MUA-Verbesserungen (wie das deutliche Anzeigen der tatsächlichen E-Mail-Adresse) sind erforderlich, um diese Bedrohung anzugehen.

12.5. Externe Berichtsadressen

Wenn DMARC-Berichte an externe Adressen gesendet werden (Adressen bei anderen Domains als der, über die berichtet wird), gelten mehrere Sicherheitsüberlegungen:

1. Datenoffenlegung: Berichte enthalten Informationen über die E-Mail-Infrastruktur und Verkehrsmuster der Domain. Diese Informationen könnten für Angreifer wertvoll sein.

2. Vertrauen in Dritte: Domain-Besitzer müssen Drittanbieter-Berichtsempfängern vertrauen, dass sie:

   • Berichtsdaten sicher handhaben
   • Die Informationen nicht missbrauchen
   • Geltende Datenschutzbestimmungen einhalten

3. Verifizierung: Der Verifizierungsmechanismus in Abschnitt 7.1 stellt sicher, dass externe Ziele autorisiert sind, aber Domain-Besitzer sollten dennoch sorgfältig überlegen, welche Informationen sie teilen.

12.6. Sichere Protokolle

Während DMARC selbst die Verwendung bestimmter sicherer Protokolle nicht vorschreibt, sollten Implementierer Folgendes berücksichtigen:

1. DNSSEC: Wie in Abschnitt 12.3 erwähnt, kann DNSSEC vor DNS-Spoofing-Angriffen schützen.

2. TLS für Berichte: Bei der Versendung von Berichten per E-Mail schützt die Verwendung von STARTTLS oder anderen Verschlüsselungsmechanismen den Berichtsinhalt während der Übertragung.

3. HTTPS für Berichts-URIs: Wenn zukünftige Erweiterungen HTTPS-URIs für die Berichtszustellung zulassen, sollte TLS zum Schutz der Berichtsdaten verwendet werden.

4. Sichere Schlüsselspeicherung: DKIM-Private-Keys müssen sicher gespeichert werden, um eine Kompromittierung zu verhindern.

---