Hin und wieder bekomme ich mit, das „gespoofte“ E-Mails, also E-Mails wo eine falsche Identität vorgetäuscht wird, durch die bekannten Security Lösungen wie SpamAssassin, Hornetsecurtiy (in der Standardkonfiguration), Sophos, Mimecast usw. durchgehen. Das Problem ist aber eher ein Konfigurationsproblem und weniger ein Problem der Securitylösungen an sich. Ich versuch das Thema hier relativ überschaubar zu erläutern.
Das Problem bei SPF
Das SPF (Sender Policy Framework) ist nach RFC 7208 wie folgt definiert:
This document defines a protocol by which domain owners may authorize hosts to use their domain name in the "MAIL FROM" or "HELO" identity. Compliant domain holders publish Sender Policy Framework (SPF) records specifying which hosts are permitted to use their names, and compliant mail receivers use the published SPF records to test the authorization of sending Mail Transfer Agents (MTAs) using a given "HELO" or "MAIL FROM" identity during a mail transaction.Das bedeutet im SPF Eintrag trägt man die Server ein die in Namen der eigenen Domain E-Mails verschicken dürfen. Der SPF-Check prüft nach „Envelope From/Mail From/Return Path“ aber NICHT nach „Header From“. Also vereinfacht: der SPF Check prüft nach dem technischen From/Von und nicht das, was im E-Mail-Header „frei“ definiert werden kann. Der „Header From“ kann leicht modifiziert werden.
Hier mal ein Beispiel einer „manipulierten“ E-Mail:
Der technische Absender (Envelope From/Mail From/Return Path) ist: webserver1@gehacktedomain8754.de
Authentication-Results: mx-gate105-hz1.security.maffert.net 1;
spf=none reason=mailfrom (ip=103.122.85.34, headerfrom=maffert.net)
smtp.mailfrom=gehacktedomain8754.de smtp.helo=gehacktedomain8754.de;
dmarc=none action=none header.from=maffert.net disposition=none
Received: from ip103-122-85-34.webserverxzy51.de (103.122.85.34) by mx-gate105-hz1.security.maffert.net;
Thu, 14 Dec 2023 15:13:43 +0100
Received: by gehacktedomain8754.de (Postfix, from userid 1011)
id 9501B159B; Thu, 14 Dec 2023 14:13:24 +0000 (UTC)
To: dennis.maffi@maffert.net
Subject: Wichtige Personalanpassung
Date: Thu, 14 Dec 2023 14:13:24 +0000
From: Tobi Maffi <tobi.maffi@maffert.net>
Message-ID: <8249cf696b8d58f3e9fdeb7b184902e6@trallafittiserver.de>
X-Priority: 3
X-Mailer: PHPMailer [version 1.73]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/html; charset="UTF-8"
X-antispameurope-Connect: ip103-122-85-34.webserverxzy51.de[103.122.85.34],TLS=1;EMIG=0
X-antispameurope-REASON:NOREASON:HO-WL
X-antispameurope-SPFRESULT: NONE
X-antispameurope-Spamstatus:CLEAN
X-antispameurope-Virusscan:CLEAN
X-antispameurope-date: 1702563211
X-antispameurope-orig-host:ip103-122-85-34.webserverxzy51.de
X-antispameurope-orig-ip:103.122.85.34
X-antispameurope-recipient: dennis.maffi@maffert.net
X-antispameurope-sender: webserver1@gehacktedomain8754.de
X-antispameurope:INCOMING: Schlussendlich erkennt man hier (in Fett dargestellt) das der Envelope From/Mail From/Return Path geprüft wird und nicht die gespoofte (gefälschte) E-Mail Adresse.
Bei dem SPF Problem hilft DMARC:
DMARC (RFC 7489) ermöglicht es dem Absender, Richtlinien zu definieren, wie die Empfänger Nachrichten behandeln sollen, bei denen der „Header From“ nicht mit dem „Envelope From/Mail From/Return Path“ übereinstimmt, der SPF dementsprechend nicht passt oder wenn man keine gültige DKIM-Signatur vorweisen kann.
Wie z.B. solch ein Eintrag aussehen kann: v=DMARC1; p=quarantine; pct=100; adkim=r; aspf=r
Hiermit wird durch das „r“ bzw. „s“ sichergestellt, das wenn etwas nicht passt, die E-Mails abgelehnt / in die Qurantäne verschoben werden. Ich hab das hier nochmal etwas genauer beschrieben: https://www.maffert.net/dmarc-was-bedeutet-spf-dkim-not-aligned-ausrichtung/
