Eine seriöse Domain oder ein gemeinsam genutzter Sendedienst kann Teil eines missbräuchlichen Nachrichtenpfads werden. Die sinnvolle Frage ist nicht, ob die Infrastruktur grundsätzlich vertrauenswürdig ist. Es geht darum, ob diese bestimmte Nachricht berechtigt war, die authentifizierte Identität zu verwenden. Authentifizierung und Geschäftsautorisierung beantworten unterschiedliche Fragen.
Definieren Sie die wiederverwendete Autorität
Ein kompromittiertes Postfach sendet möglicherweise über die normale authentifizierte Route. Eine zu weit gefasste Netzwerkautorisierung kann eine unbeabsichtigte Quelle zulassen. Ein Relay kann eine Nachricht signieren, nachdem er sie aufgrund einer nicht ausreichend spezifischen Zulassungsregel akzeptiert hat. Diese Mechanismen haben unterschiedliche Besitzer und Abhilfemaßnahmen. Fassen Sie sie nicht zu einer einzigen unerklärlichen Behauptung der Rufschädigung zusammen.
Die ursprüngliche BreakSPF-Forschung untersucht Freizügigkeit SPF Konfigurationen und gemeinsam genutzte Infrastruktur. Sein Bedrohungsmodell macht den Zugriff auf das Quellnetzwerk zu einer zentralen Voraussetzung. Das ist eine Einsatzgrenze und kein Beweis dafür, dass ein Angreifer welche fälschen kann DKIM Signatur. BreakSPF-Papier, Abschnitt III. Betrachten Sie die Messungen des Papiers als historische Forschung und nicht als aktuelle Bestandsaufnahme gefährdeter Dienste.
Erstellen Sie ein präzises Bedrohungsmodell
Schreiben Sie die geschützte Domäne, die authentifizierte Kennung, den zulässigen Quellensatz, die Angreiferfähigkeit und die Empfängerentscheidung separat. Im hier begrenzten Szenario autorisiert brand.test 192.0.2.0/24 für SPF . Der genehmigte Antrag verwendet 192.0.2.10 , während ein hypothetischer unbeabsichtigter Mieter von 192.0.2.99 stammen kann. Beide Adressen liegen im veröffentlichten Bereich. Ob ein solcher Mieterzugang in einer realen Dienstleistung besteht, bedarf eines gesonderten Nachweises.
SPF überprüft die Quellautorisierung auf seine ausgewertete Identität. Es identifiziert nicht den Menschen hinter einer gemeinsamen IP. Wenn die übergebene SPF Identität auch mit der Autorendomäne übereinstimmt, kann dieser Pfad die Anforderungen erfüllen DMARC ohne DKIM. RFC 7208 Und RFC 9989. Eine erfolgreiche Auswertung kann daher aufdecken, dass zu viel Autorität erteilt wurde, anstatt dass ein Empfänger die Pass-Regel ignoriert hat.
Vergleichen Sie drei schriftliche Autorisierungsfälle
Annehmen, sichtbar von alerts@brand.test , nicht leer POST VON bounce@brand.test , keine DKIM Signatur und eine ansonsten zulässige DMARC Bewertung. Vergleichen Sie hypothetisch SPF Einträge v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- Genehmigte Quelle 192.0.2.10 : in beiden Netzwerkpräfixen enthalten; SPF besteht brand.test und stimmt mit ihm überein, sodass die illustrative Botschaft in beiden Fällen DMARC besteht.
- Unbeabsichtigte Quelle 192.0.2.99 : in /24 enthalten, aber nicht in /32; SPF gilt nur unter dem breiten Rekord. Ohne DKIM Signatur lautet das festgelegte DMARC Ergebnis „Bestanden“ unter /24 und „Fehler“ unter /32.
- Externe Quelle 198.51.100.10 : von keinem Präfix enthalten; -all SPF Erträge schlagen in beiden Fällen fehl. Ohne DKIM Signatur ist das festgelegte DMARC Ergebnis in beiden Fällen fehlgeschlagen.
Dies sind geschriebene Präfix-Mitgliedschaften und Ausrichtung Abzüge, kein laufender SPF Parser, DNS Beobachtung oder Reproduktion von BreakSPF. Die Quellcodeverwaltung wird vorausgesetzt, nicht demonstriert. Es wurden keine externen Nachrichten oder Live-Dienste getestet. Die protokollübergreifende Technik des Artikels liegt außerhalb dieses Lehrbeispiels.
Ein einzelner Passing-Alignment-Mechanismus kann die DMARC Passbedingung einer Nachricht erfüllen. Dadurch ist eine reine SPF-Bereitstellung nicht ausreichend: RFC9989 Abschnitt 7.4 erfordert gültiges DKIM für die Veröffentlichung von Domänen p=rejectund Abschnitt 8 befasst sich mit der vollständigen Teilnahme. Hierbei handelt es sich um separate Bereitstellungsaufgaben, nicht um ein zusätzliches Pass-Gate pro Nachricht.
Legen Sie die Verantwortlichkeitsgrenze fest
Bevor Sie einen echten SPF Eintrag eingrenzen, führen Sie eine Bestandsaufnahme aller legitimen Absender durch und befolgen Sie die vom Anbieter unterstützte Konfiguration. Eine dedizierte Quelle ist nur dann sinnvoll, wenn sie tatsächlich exklusiv ist und gepflegt wird. Bestätigen Sie, dass der Versanddienst Kunden an ihre zulässigen Identitäten bindet. Überprüfen Sie DKIM Konfiguration und entfernen Sie veraltete Berechtigungen durch Änderungskontrolle.
Überwachen Sie routenspezifische Ausfälle nach der Änderung, bewahren Sie einen Wiederherstellungsplan auf und dokumentieren Sie unbekannte Absender. Ersetzen Sie einen breiten Datensatz nicht durch eine vermutete IP-Liste aus diesem Beispiel. Die Lektion besteht darin, die Autorisierung mit dem tatsächlichen Dienstbesitz in Einklang zu bringen und nicht, Demonstrations DNS in die Produktion zu kopieren.