GMail.com-Spam

Anfang September haben mich die Kollegen von NoSpamProxy über einige interessante Entdeckungen beim der Spamabwehr informiert, über die wir diskutiert haben und kein allzu gutes Licht auf den GMail-Dienst wirft. Google hat ja durchaus schon Herausforderungen mit Google Meet Spam und Google Drive (Siehe Phishing mit Consent-Anforderung).

Das Problem betrifft analog auch Domains wie hotmail.com, web.de, gmx.net, outlook.com, t-online.de aber gmail.com ist aktuell wohl viel beliebter bei den Spammern, da sie auf einen Vertrauensvorschuss hoffen dürften.

Statistiken

NoSpamProxy ist ein kommerzieller Service, um u.a. Spam, Phishing, Viren aus ihrem Postfach fern zu halten und können Sie selbst hosten oder als Cloud Service einkaufen. Eine gute Abwehr arbeitet im Team zusammen, weswegen wir auch Dienste wie 32Guards entwickelt haben, damit sich die vielen NoSpamProxy-Instanzen gegenseitig über unerwünschte Nachrichten abgleichen können. Diesen Datentopf und auch Statistiken auf den Instanzen werdet das Response Team bei NoSpamProxy kontinuierlich aus, um neue Tricks und Angriffsmuster der Absender zu erkennen und Gegenmaßnahmen zu optimieren. Und hier fiel "Gmail.com" gleich bei mehreren Kunden besonders negativ auf:

Bei zwei Kunden war "gmail.com" schon im Beriech 30%+ während ein anderer Kunde nur relativ wenig von GMail belastet war aber dafür viele andere "Freemailer" auf der Top20 der abgelehnten Mails vertreten war.

SPF und DMARC

Nun wissen zumindest die Leser der MSXFAQ, dass ich meine eigene Domain doch bitte per SPF und idealerweise noch per DMARC-Policy schützen kann. Hier noch mal in Kurzform:

  • SPF
    Damit kann ich die IP-Adressen veröffentlichen, die im Namen meiner E-Mail-Domain verwenden dürfen. Diesen Eintrag sollte jeder Firma veröffentlichen und mit einem "-all" anderen Adressen den Versand verbieten. Wenn nur ihre Mailserver Emails senden und empfängt, sollte dieser Eintrag in ihrer DNS-Zone funktionieren.
@  TXT "v=spf1 MX -all"
  • DMARC
    Eine Firma sollte aber auch einen DMARC-Eintrag setzen, weil der dann gefordert werden kann, dass nicht nur der MAIL FROM sondern auch den Header-From überprüft wird. Ein strenger Eintrag wäre:
_dmarc  TXT "v=DMARC1; p=reject"
  • DKIM
    Etwas fortgeschrittener ist dann die Umsetzung von DKIM, da hierzu sowohl ein Schlüssel im DNS bereit gestellt werden muss und der Mailserver die Mails DKIM-Signiert. Der Vorteil ist dann aber, dass alle Empfänger zu jeder Zeit prüfen können, ob die Mail verändert wurde. Dies ist keine SMIME/PGP Signierung oder Verschlüsselung.

Schon allein mit SPF und DMARC erschweren Sie es Spammern, in ihrem guten Namen zu senden aber könnten auch Umleitungen und Mailinglisten erschweren. Daher sollten Sie auch DKIM umsetzen, wen ihr Mailserver dies kann. Die Einrichtung für Exchange Online finden Sie auf DKIM mit Office 365

Spammer und andere böse Jungs können dann zwar noch versuchen, sich mit ihrer Domäne auszugeben, aber jeder halbwegs gute Empfänger lehnt die Mail ab. Dies hilft aber nicht gegen "ähnlich" geschrieben Domains.

Sie können nun mal die große Provider hinsichtlich ihres SPF und DMARC-Eintrags prüfen mit:

NSLOOKUP -q=TXT <domain>
NSLOOKUP -q=TXT _dmarc.<domain>

Einige Provider haben bei SPF noch ein "~all", was gleichbedeutend ist mit "Alle Anderen dürfen auch". Meine Interpretation: "Der Mail-Administrator dieser Domain weiß überhaupt nicht nicht, welche Server mit seiner Domain versenden". Das Problem ist nicht nur bei kleinen Firmen vorhanden, sondern durchaus ein Problem großer Mailversender.

Domains (Sep 2022) SPF DMARC

gmail.com

-all

p=none

hotmail.com

-all

p=none

outlook.com

-all

p=none

163.com

-all

p=none

web.de

-all

p=none

gmx.net

-all

p=none

t-online.de

Keine Policy!

Keine Policy!

telekom.de

Keine Policy

p=none

Viel schlimmer ist aber, dass viele große Provider, und dazu zählt auch "GMAIL.COM" über eine DMARC-Policy die eventuell strengere SPF-Vorgabe außer Kraft setzen:

Hinweis: Eine DMARC-Policy "p=none" überstimmt das "-all" bei SPF

Vergessen wir dabei aber auch nicht die großen Webhosting-Provider in Deutschland, die Millionen Kunden mit Webseiten haben aber ihre eigene Domain zur Kundenkommunikation, z.B. Rechnungen aber auch Warnungen nutzten und sehr wenig dagegen tun, dass ihre Kunden durch Phishing angreifbar sind. Als Angreifer freue ich, wenn ich die Domain eines Kunden oder sein Webhosting so gekapert habe. Das muss auch nicht sein.

Domains (Sep 2022) SPF DMARC

ionos.de

~all

p=none

1und1.de

-all

p=none

strato.de

Keine Policy

p=reject

hetzner.com

-all

keine Policy

hosteurope.de

-all

keine Policy

ovh.de

-all

p=none

all-inkl.com

~all

keine Policy

Fragen Sie mich bitte nicht, was Strato.de macht. Ein Reject, wenn DKIM nicht passt, kann ich ja noch verstehen aber wo ist der SPF-Record?

Für einen empfangenen Mailserver bedeutete diese Anweisung, dass er die Mail nicht anhand der IP-Adresse oder unpassendem Domainname im Absender ablehnen sollte. Andere Versender von Massenmails machen das deutlich besser.

"Gute Domains" (Sep 2022) SPF DMARC

amazon.com

-all

p=quarantine

aol.com

~all

p=reject

dhl.de

~all

p=reject

bsi.bund.de

-all

p=reject

google.com

~all

p=reject

vodafone.com

~all

p=reject

vodafone.de

-all

p=quarantine

Amazon listet seine IP-Adressen auf und Empfänger, die nur SPF verstehen, weisen alles andere ab während die DMARC-kompatiblen Systeme solche Mails annehmen und in die Quarantäne ablegen. AOL und DHL sind bei SPF etwas freizügiger aber die DMARC-Policy überstimmt den SPF-Eintrag. Dass Google es besser weiß, zeigen sie bei ihrer eigenen Domain "google.com" welches zwar auch nur ein SPF:~all hat aber die DMARC-Policy ein p=reject vorgibt. Das BSI ist mustergültig, welches beide Einstellungen sehr streng eingerichtet hat.

Fehlverhalten

Wir haben nun gelernt, dass allein anhand der IP-Adresse und der Absenderdomain bei GMAIL.COM-Absendern der Empfänger die Mail eigentlich nicht ablehnen darf. Aber NoSpamProxy prüft natürlich mehr Eigenschaften als nur einen MAIL FROM mit SPF.

Die erste und dritte Zeile zeigt, wie dumm eigentlich Spammers sind, denn die Zieladresse sollte schon zu der Firma gehören, die man versucht zu erreichen. Ansonsten wäre das ja ein "offenes Relay".

Aber vielleicht ist das auch genau der Angriffsvektor: Die Gegenseite versucht sich als "gmail.com" auszugeben und einen "gefundenen" Mailserver auf Port 25 zu missbrauchen.

Ein offenes Relay im Internet ist natürlich per Se eine schlechte Idee und wenn ihr eigener Mailserver je in die Verlegenheit kommen würde, dann landet ihre IP-Adresse sehr schnell auf einer Blacklist und ihre Versand wird auch trotz SPF, DKIM und DMARC für einige Zeit zum Erliegen kommen.

Würde aber GMAIL eine Liste der gültigen IP-Adressen veröffentlichen und alle anderen Absender per SPF gleich disqualifizieren, dann würde selbst ein offenes Relay seine Schadmail nicht loswerden. Es wäre für den Angreifer viel unattraktiver, die Absenderdomain "GMAIL.COM" zu verwenden.

Das offene Relay würde dann natürlich jede Menge "Unzustellbarkeiten" erzeugen und an den angeblichen GMAIL.COM-Absender zurück melden. Ein SPF=-all  oder DMARC:p=reject auf der GMAIL.COM für dem offenen Relay natürlich nicht wirklich helfen. Angreifer nutzen dann einfach andere Adressen.

Aber das ist ein gutes Beispiel, dass er strenge Einsatz von SPF/DMARC heute eigentlich Pflicht sein sollte.

Interessanterweise sind bei Spammern, die sich als "Hotmail.com" ausgeben, viel weniger Mail so falsch adressiert, bzw. als Open Relay Versuch zu bewerten.

Passende Mail

Wenn also tausende Mails als "*@gmail.com" in der Welt unterwegs sind und von Spammern über offenen Relays versendet werden, dann schaue ich doch mal in mein Testpostfach ohne Spamfilter. Und siehe da: Auch hier finde ich eine Mail eines vorgeblichen "gmail.com"-Absenders:

Wenn ich mit den verkürzten Header anschaue, dann sehen Sie, das die Mail von einem PC über einen Mailserver zu meinem Mailserver gelaufen ist

Received: from mi028.mc1.hosteurope.de ([80.237.138.227]) by
 mx.kundenserver.de (mxeue012 [212.227.15.41]) with ESMTPS (Nemesis) id
 1Ma1PY-1oq19O3QTU-00VvD8 for <spameater@msxfaq.de>; Mon, 05 Sep 2022 11:52:30
 +0200
Received: from [175.123.17.181] (helo=xmailserver.test)
	by mx0.webpack.hosteurope.de (mi028) with esmtp (Exim)
	id 1oV8mK-0000BM-J5
	for spameater@msxfaq.de; Mon, 05 Sep 2022 11:52:30 +0200
Received: from Isidoro-PC.home ([185.237.102.234]:50710)
	by xmailserver.test with [XMail 1.27 ESMTP Server]
	id <S18C2ACB> for <spameater@msxfaq.de> from <thomasmichaelclaus737@gmail.com>;
	Thu, 7 Jul 2022 06:54:36 +0900
Reply-To: <thomasmichaelclaus7@gmail.com>
From: <thomasmichaelclaus737@gmail.com>
To: "Recipients" <thomasmichaelclaus737@gmail.com>
Subject: =?iso-8859-1?Q?Abschlie=DFende_Mitteilung_f=FCr..?=
Date: Wed, 6 Jul 2022 23:53:44 +0200
Message-ID: <E1oV8mK-0000BM-J5@mi028.mc1.hosteurope.de>

Der Message Header Analyzer von Microsoft auf https://mha.azurewebsites.net/ kann die Ausgaben auch schön als Tabelle aufbereiten:

Eingeliefert wurde er von einem PC (185.237.102.234), der laut https://ipinfo.io/AS31404/185.237.102.0/24 zu Lycatel, Spanien verortet wird, während das offene Relay (175.123.17.181) ein virtueller Server bei einem Provider "SK Broadband Co Ltd" in Süd Korea (https://ipinfo.io/AS55615/175.123.17.0/24) steht. Dort war die Mail aber über 60 Tage rumgelegen, ehe der Mailserver seine Queue wohl wieder weiter abgearbeitet hat.

Mittlerweile scheint der Server aber zumindest keine neuen Verbindungen mit fremden Empfängern anzunehmen.

XMailServer ist eine Windows Software, bei der die kompilierte EXE im ZIP-Archiv ein Dateidatum vom 2010 hat und die TLS- Verschlüsselung auf "OpenSSL 0.9.8l 5 Nov 2009" basiert. Zumindest war der Server nicht per RDP direkt erreichbar. Ein richtiger Trost ist das dennoch nicht.

Freemail, TLS und Relay

Mit all den Informationen könnte man als Spamabwehr natürlich wieder weitere Erkennungsmöglichkeiten herleiten, z.B.

  • TLS und kein TLS
    Die meisten Freemailer verschlüsseln schon ihre Verbindung per STARTTLS. Wenn ein Spamfilter einmal gelernt hat, dass eine Domain per TLS sendet, dann könnte Sie ja unterschlüsselte Verbindungen zumindest strenger bewerten. Wenn viele Verbindungen per TLS mit dem gleichen Zertifikat oder der gleichen Root oder sogar eine "Trusted Root" kommen, dann dürfte eine Ablehnung von Verbindungen ohne TLS oder mit einem SelfSigned-Cert nur wenig FalsePositive haben.
  • Open Relay Erkennung
    Auch wenn ein Absender keinen SPF-Record veröffentlicht, so sollten sie bei ausreichend vielen Mails ja schon ein par "Hotspots" ergeben, d.h. Subnetze, Provider oder Geo-Regionen, die von dem Absender genutzt werden. Umgekehrt sollte es auffallen, wenn eine IP-Adresse eines OpenRelays mit unterschiedlichsten From-Adressen den eigenen Spamfilter belagert. Das mag bei einem einzelnen Spamfilter noch nicht auffällig sein, aber mehrere Spamjäger können sich ja durchaus zusammentun und damit sehr schnell solche offenen Relays erkennen.
  • Freemailer und BGP
    Die besonders großen Freemailer haben sogar ein eigenes Autonomomes BGP-Netzwerk (AS). Wenn Sie schon nicht selbst ihre Mailserver veröffentlichen, könnte ein Spamfilter zumindest die Verbindungen mit Strafpunkten versehen, die aus anderen Netzwerken kommen. Der Host "www.gmail.com" löst bei mir auf 142.250.74.197 auf, was zum "AS15169  ·  Google LLC" (https://ipinfo.io/AS15169/142.250.0.0/15-142.250.74.0/23) führt, was seinerseits ein Teilnetz von "NET-142-250-0-0-1" mit den Addresen von 142.250.0.0 - 142.251.255.255 ist.

Aber das sind alles nur weitere Schutzfunktionen, die nicht das Grundproblem angehen.

Einschätzung

Das Grundproblem der gesamten GMAIL-Spam-Thematik ist die fehlende Kooperation von Google Mail mit den Best Practices für einen professionellen Mailserverbetrieb. Ich bin sicher, dass Google als Inhaber von GMAIL.COM sehr gut ihre ausgehenden Mailserver und die damit verbundenen IP-Adressen kennen. Ich habe kein Verständnis dafür, das Google hier nicht umsetzt, was sie selbst propagieren und beschreiben.

Ich rufe daher GMAIL zu: Aktiviert bitte SPF:-all und DMARC:p=reject.
Und die gleiche Forderung stelle ich natürlich auch an die anderen Nachzügler wie 163.com, outlook.com, hotmail.com, t-online.de

Es ist kein Service, wenn eure Free-Mailer-Kunden mit ihrer Addresse auch unter Umgehung eurer Server ohne Authentifizierung Mails per SMTP versenden könnten, nur weil Spamfilter keine SPF/DMARC-Beschränkungen auswerten dürfen. Umgekehrt werden die Spamfilter eher eure Domains als "minderwertig" einstufen.

Weitere Links