Ausgehender Spamschutz

Ohne Schutz gegen Spam und Malware können Sie heute keinen Mailserver mehr betreiben. Viele Firmen denken dabei aber primär an den Schutz beim Empfang von eingehende Mails und wenige an Nachrichten, die sie selbst versenden.

Weckruf

Diesmal war es vermutlich nur ein gekaperter PC eines Minigolf-Vereins oder zumindest das T-Online-Konto. Ob das nun ein schwaches Kennwort war, oder die Zugangsdaten auf einem Post-It unter der Tastatur hingen oder doch eine Malware aus dem lokalen Kennwortspeicher des Mailprogramme die Anmeldedaten ausgelesen hat, werde wir wohl nicht herausfinden. Auf jeden Fall hat es die folgende Mail in eines meiner Testpostfächer geschafft:

Der Inhalt der Mail ist natürlich so überzogen, das es schon als Realsatire durchgehen könnte, Der BND als Logo über dem Text "Justizministerium" und zugleich noch Amtsgericht und dann der Präsident des BKA, die mir per Mail einen Haftbefehl übermitteln und eine Antwort an eine GMAIL.COM-Adresse erwarten. Das ist so schief, dass der reale Absender eine Eignung zum Schreiben von Spam-Mails bitte ärztlich überprüfen lassen sollte.

Spamfilter beim Versender

Solche plumpe Versuche werden bei viel weniger Empfängern verfangen, als andere deutlich ausgefeiltere Nachrichten. Vielleicht legt es der Absender ja aber genau darauf an, nur die leicht zu übertölpenden Empfänger zu erwischen. Ich habe mir daher mal den Header angeschaut und es gibt zwei Dinge, die unstimmig sind.

Received: from fwd72.aul.t-online.de (fwd72.aul.t-online.de [10.223.144.98])
	by mailout02.t-online.de (Postfix) with SMTP id 9B89816E23;
	Tue, 21 Nov 2023 00:08:07 +0100 (CET)
Received: from mailout02.t-online.de ([194.25.134.17]) by mx.kundenserver.de
 (mxeue003 [212.227.15.41]) with ESMTPS (Nemesis) id 1MK5qY-1qltql3RCI-00YWdB
 for <honeypot023@msxfaq.de>; Tue, 21 Nov 2023 00:08:53 +0100
Received: from [212.227.15.41] ([212.227.15.41]) by mx.kundenserver.de
 (mxeue003 [212.227.15.41]) with ESMTPS (Nemesis) id 1MPZUg-1qic473WnC-00QpWr
 for <honeypot023@msxfaq.de>; Tue, 21 Nov 2023 00:08:53 +0100
Received: from 172.20.102.121:43778 by spica24.mgt.mul.t-online.de:8080; Tue, 21 Nov 2023 00:07:55 +0100 (CET)
Received: from 159.242.234.28:1452 by cmpweb28.aul.t-online.de with HTTP/1.1 (Lisa V7-6-7-2.0 on API V5-53-2-0); Tue, 21 Nov 23 00:07:55 +0100
Received: from spica24.mgt.mul.t-online.de ([172.20.102.120]) by fwd72.aul.t-online.de
	with esmtp id 1r5DMx-1ZMgfA0; Tue, 21 Nov 2023 00:07:56 +0100
Return-Receipt-To: "Bundeskriminalamtes" <minigolf.xxxxxxx@t-online.de>
Reply-To: <yugte@magenta.de>
From: "Bundeskriminalamtes" <minigolf.xxxxxxx@t-online.de>
To: <dester@t-online.de>
Subject: Anklageschrift gegen Ihre Person
Date: Tue, 21 Nov 2023 00:07:55 +0100
Message-ID: <1700521675066.276915.9d29694e47650c6424c81f5dfe4b190488f30d25@spica.telekom.de>
MIME-Version: 1.0
X-Priority: 2
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook 16.0
Authentication-Results: kundenserver.de; dkim=none
X-Spam-Flag: NO
Disposition-Notification-To: <minigolf.xxxxxx@t-online.de>

Es fällt auf den ersten Blick nicht auf, aber die oberste "Received:"-Zeile kann nicht stimmen. Sie kann nicht vor der zweiten Zeile kommen, die den Übergang der Mail von T-Online zu Kundenserver kennzeichnet. Damit passen dann auch die Zeiten nicht mehr, was beide Header Analysatoren verwirrt:


Quelle: https://mha.azurewebsites.net/


Quelle: https://mxtoolbox.com/Public/Tools/EmailHeaders.aspx

Erst wenn ich die Header mal anhand der Uhrzeit und den IP-Adressabfolge sortiere, passt das Bild

Interessant ist aber, dass MXTOOLBOX die IP-Adressen von zwei Zwischenstationen schon auf einer einfachen Blacklist findet. Das einliefernde System mit der IP-Adresse "159.242.234.28" gehört interessanterweise zu AVAST, die eigentlich Malware erkennen sollten.

Ich vermute mal, dass hier ein "VPN-Kunde" von Avast deren Dienste genutzt haben, um seinen Zugriff auf einen T-Online Webserver zu verschleiern, mit dem er dann dank geklauter Zugangsdaten diese Mail versendet hat.

Allerdings ist diese IP-Adresse als "schlecht" gelistet und jeder halbwegs aktuell konfigurierte Spamfilter würde die Verbindung blockieren. T-Online kann dies aktuell nicht es sich um einen "authentifizierten Benutzer", und damit einen zahlenden Kunden, handelt. Hier steht der Provider immer in der Zwickmühle, wie er mit solchen Verbindungen umgeht.

Dennoch könnte hier sowohl der ausgehende Spamfilter bei T-Online als auch der eingehende Spamfilter bei IONOS durchaus etwas pfiffiger sein. Ich vermute schon, dass über den Zugang nicht nur eine Mails sondern eine ganze Menge versendet wurden. Und so etwas kann ein Hoster schon erkennen und zumindest drosseln.

T-Online SPF-Fehlanzeige

Allerdings frage ich mich manchmal schon, wie ein großer Provider wie T-Online seine Domains immer noch nicht entsprechend schützt. Es gibt in der Mail keine DKIM-Signatur aber auch keinen DMARC Eintrag. Der SPF-Eintrag hat mit einem ~all den schlimmsten Wert, nämlich "wertlos"

Der Server "mailout02.t-online.de ([194.25.134.17])" ist allerdings durch den SPF-Record erfasst und hat damit ein SPF=PASS generiert. Die Einstellung hätte in dem Fall nicht geholfen die Mail abzulehnen.

IP-Blacklist

Wer aber keinen effektiven Schutz gegen Versand von Werbung über seine Mailserver umsetzt, kann natürlich auch schnell auf entsprechenden schwarzen Listen landen, und dann alle Absender bestrafen.


https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a194.25.134.17

Die "T-online"-Domain wird meist von Privatkunden oder kleinen Gewerbetriebe genutzt, die immer noch nicht verstanden haben, dass eine eigene Domain vielleicht die bessere Wahl wäre. Wenn dann der eigene Provider mit seinen wenigen im SPF-Record gelisteten IP-Adressen (ca. 26 Stück) plötzlich geblockt wird, dann könnte das ein Problem werden. Allerdings ist hier wieder zu befürchten, dass entsprechend große Provider sich untereinander vertrauen und statischen Allow-Listen solche dynamischen Blocklisten unterbinden. Welcher mittlere und kleinere Provider möchte sich vorwerfen lassen, dass er Mails von dem großen "rosa Riesen" zu unrecht ablehnen würde.

Der eigene Mailserver

Wenn Sie einen eigenen Mailserver mit ihrer eigenen Domain betreiben, dann sollten Sie jetzt einfach mal überlegen, wie sie mit so einer Situation umgehen würden.

  • Darf bei ihnen jeder interne Clients einfach so "ins Internet" senden ...
    ...oder ist dies zumindest aus "authentifizierte Benutzer" beschränkt?
  • Wie sicher ist dabei die Anmeldung.
    In der Cloud ist MFA und Conditional Access mittlerweile quasi Standard aber wie gut sind ihre Anwender beim Thema Credentials Phishing aufgestellt?
  • Überwachen Sie die Anzahl und Größe der pro Zeiteinheit versendeten Mails?
    Solche Daten sollten Sie mit ihrer Monitoring-Software anhand des Messagetrackings oder Performance Counter erfassen
  • Erfassen oder beschränken Sie die Nachrichtenrate vielleicht nach Absenderpostfach oder Mailadresse?
    Mal abgesehen von Weihnachtsrundschreiben und Geburtstagsglückwünschen bewegen sich die pro Mitarbeiter gesendeten und empfangenen Mails in einem Korridor. Wir ein Konto durch einen Spammer gekapert, dann fällt dies durch einen starken Anstieg der versendeten Mail auf.

Ich hoffe, sie können nun noch ruhig schlafen.

Exchange Online hat solche Grenzen übrigens schon fest eingebaut. Exchange OnPremises kann sehr limitiert den Versand von Benutzern über eine SMTP-Einlieferung kontrollieren aber nicht über Outlook/OWA/ActiveSync

Zusammenfassung

Die Situation ist vertrackt. Als Provider möchte man seine eigenen authentifizierten Kunden nicht blockieren aber muss auf der anderen Seite schon verhindern, dass die eigenen Mailserver nicht auf schwarzen Listen landen. Nicht jeder hat den Vorteil zu den XXL-Anbietern wie GMail, Outlook.com, Yahoo zu gehören, denen der ein oder andere einen Vorteil einräumen wird. Das größte Risiko sind in dem Fall gekaperte Postfächer, die mit legitimen Absenderadressen mit gedrosselter Leistung ihren Werbemüll versenden, so dass Sie möglichst lange unentdeckt bleiben. Microsoft 365 hat dieses Risiko durch MultiFaktor-Anmeldung und Drosselung des Versands auf 30 Mails/Minute relativ gut im Griff. Andere Dienstleister haben ähnlich Regelungen. Dennoch kommen natürlich immer mal wieder ein paar Mails durch.

Exchange Online hat einige Grenzen Drosseln aber bei Exchange OnPremises sind die Möglichkeiten sehr stark beschränkt. Hier müssen Sie eigentlich in den Versandweg mit Zusatzprodukten den Nachrichtenfluss überwachen und ggfls. reglementieren.

Weitere Links