Wer in Ihrem Namen mailt
Eine Phishing-Mail mit Ihrer Absenderadresse trifft nicht Sie, sondern Ihre Kunden, Partner und Bewerber. Ob das möglich ist, entscheiden ein paar DNS-Einträge. Warum der häufigste Fehler nicht das fehlende DMARC ist, sondern ein vorhandenes, das nur zuschaut, und was isidaten jetzt je Domain prüft.
Eine Phishing-Mail mit Ihrer Absenderadresse trifft nicht Ihre Infrastruktur. Sie trifft Ihre Kunden, Ihre Partner und Ihre Bewerber, und beschädigt einen Ruf, an dem Sie jahrelang gearbeitet haben. Das Unangenehme daran: Ob jemand Ihre Domain in den Absender schreiben kann, entscheidet nicht Ihre Firewall, sondern eine Handvoll DNS-Einträge, die niemand täglich anschaut.
Drei Einträge, drei Aufgaben
SPF legt fest, welche Server für Ihre Domain senden dürfen. DKIM signiert ausgehende Mails, sodass sich Manipulation erkennen lässt. Und DMARC verbindet beides: Es sagt dem empfangenden Mailserver, was er tun soll, wenn eine Mail durch die Prüfung fällt. Erst dieser dritte Eintrag macht aus den ersten beiden eine Durchsetzung.
Der häufigste Fehler ist ein DMARC, das nur zuschaut
Genau hier liegt der Fallstrick. Viele Organisationen haben einen DMARC-Eintrag und halten das Thema damit für erledigt. Steht dort aber die Policy „p=none", passiert im Ernstfall nichts: Der Empfänger wird lediglich gebeten, Berichte zu schicken. Gefälschte Mails werden trotzdem zugestellt. „p=none" ist als Beobachtungsphase gedacht, um vor der Verschärfung zu sehen, wer alles legitim in Ihrem Namen sendet. Als Dauerzustand ist es ein Schutz, der nur so aussieht. Durchgesetzt wird erst ab „p=quarantine" oder „p=reject".
Was isidaten jetzt je Domain prüft
Das Attack Surface Management prüft die Domain-Sicherheit ab sofort als eigenen Bereich: SPF, DKIM, DMARC, dazu DNSSEC, CAA, MTA-STS, TLS-RPT und ein DNSBL-Abgleich. Bewertet wird nicht nur, ob ein Eintrag existiert, sondern ob er trägt: ein DMARC auf „p=none" erscheint als Warnung, ein DKIM-Selektor mit leerem Schlüssel als widerrufen, ein zu kurzer RSA-Schlüssel als Mangel. Die Prüfung läuft genau einmal je registrierbarer Domain statt einmal je Subdomain, was dieselben Befunde nicht mehr dutzendfach aufbläht. Und wenn eine Prüfung technisch nicht möglich ist, etwa weil kein DKIM-Selektor bekannt ist, wird sie als nicht verfügbar geführt statt als Fehler. Ein Falsch-Positiv im Sicherheitsbericht kostet mehr Vertrauen, als es Erkenntnis bringt.
Mehr dazu zeigt die Modulseite zum Attack Surface Management. Warum Phishing-Abwehr nicht bei der Technik endet, war hier schon einmal Thema.
Fragen zu dieser Neuerung?
Sprechen Sie mit uns – wir zeigen Ihnen die Funktion gern in einer Demo.