lordgurke
Goto Top

Wenn die eigene Domain für Spamversand missbraucht wird und was man dagegen tun kann

back-to-topWieso steht da unsere Domain im Absender? Das kann doch nicht sein!

Die Absenderadresse einer E-Mail kann man genau so leicht fälschen wie den Absender auf einem klassischen Brief. Da die Domains von seriösen Unternehmen in der Regel gute Reputationen haben, werden diese dann hin und wieder von Spammern als Absender verwendet in der Hoffnung, so einfacher durch Spamfilter durch zu kommen oder dass der Absender so seriös wirkt dass infizierte Anhänge geöffnet werden.
Wenn die Spam-Mails tatsächlich nicht vom eigenen Mailserver kommen, kann man erstmal nichts tun um den Versand dieser Mails zu stoppen. Man kann lediglich den anderen, empfangenden Servern helfen zwischen den echten E-Mails mit diesem Absender und den Fälschungen zu unterscheiden.

back-to-topVorher: Sicherstellen, dass man nicht selbst versendet!

Normalerweise wird man selbst darauf ja erst aufmerksam, wenn man mit Bounces ("Backscatter") überworfen wird. Aus genau diesen Bounces sollte aber die IP-Adresse des Servers hervorgehen, der diese E-Mails erzeugt und versendet hat. Wenn das nicht eurer ist, liegt das Problem tatsächlich in gefälschten Absendern. Taucht da die IP-Adresse eures Mailservers auf, helfen euch diese Tipps erstmal nicht weiter und ihr solltet schleunigst euren Mailserver vom Netz nehmen face-wink

back-to-topVariante 1: Billig, einfach, schnelle Lösung, aber ziemlich problembehaftet: SPF

SPF (Sender Policy Framework) ist im Grunde nichts weiter als ein DNS-Eintrag für die eigene Domain, in der hinterlegt wird von welchen E-Mail-Servern aus legitim versendet wird.
Bis auf das Erzeugen des DNS-Eintrags hat man erstmal keinen weiteren Aufwand oder Konfigurationsarbeiten an Mailservern vor sich und man sieht quasi innerhalb kürzester Zeit einen Effekt.

Wenn man selbst einen eigenen Mailserver mit der IP-Adresse 198.51.100.25 betreibt und ausschließlich darüber E-Mails mit der Domain "firma.tld" versendet werden, sieht der SPF-Record beispielsweise so aus:
firma.tld   IN  TXT   "v=spf1 mx ip4:198.51.100.25 -all"  

Damit wird festgelegt...
...dass alle Server, die E-Mails unter der Domain annehmen ("MX") versenden dürfen (empfohlen)
...zusätzlich die IP-Adresse 198.51.100.25 versenden darf
...und der Rest explizit NICHTS unter der Domain versenden darf. (Nicht empfohlen, aber für das Beispiel ist es besser)

Erhält nun ein Mailserver eine E-Mail von der IP 198.51.100.25 und dem Absender "hallmackenreuther@firma.tld" prüft er durch eine DNS-Anfrage auf den TXT-Record unter "firma.tld", ob es einen SPF-Record gibt und wertet ihn aus. In diesem Fall ist unserer IP das Versenden von Mails ja explizit erlaubt, also gibt es dort grünes Licht und die E-Mail darf durch.

Klopft nun stattdessen z.B. der Spammer-Server 203.0.113.123 an und will ebenfalls eine E-Mail von "hallmackenreuther@firma.tld" einliefern wird wieder der DNS-Eintrag geholt und geprüft:
- Steht die IP-Adresse im SPF-Record? Nein, also...
- Ist dieser Server irgendwo in den MX-Records der Domain aufgeführt? Auch nicht, also...
- Greift die Regel am Ende: Nämlich fortjagen ("-all").

An sich ein einfaches Konzept und funktioniert, sofern man alles korrekt konfiguriert.
Alles? Nein, denn SPF sieht nicht vor, dass jemand möglicherweise seine E-Mails von einem Anbieter zu einem anderen WEITERLEITEN will!

back-to-topSPF und Weiterleitungen
Herr Hallmackenreuther versendet nun über den Mailserver seiner Firma (198.51.100.25) eine E-Mail an "lindemann@herrenboutique.tld". Herr Lindemann ist aber im Urlaub auf Island und lässt seine E-Mails weiterleiten, an seine Tochter "tochter@t-offline.de". Und jetzt passiert das hier auf dem Server von T-Offline:

Da kommt jetzt der Mailserver von "herrenboutique.tld" (192.0.2.2) vorbei und möchte eine E-Mail von "hallmackenreuther@firma.tld" an "tochter@t-offline.de" zustellen. Der Server von T-Offline holt sich also den SPF-Record von "domain.tld" und arbeitet ihn ab:

- Steht die IP-Adresse 192.0.2.2 im SPF-Record? Nein.
- Taucht der Server 192.0.2.2 in einem MX-Record von "firma.tld" auf? Nein.
- Also: Fortjagen ("-all").

Schade, damit wird die echte E-Mail vom Herrn Hallmackenreuther abgelehnt face-sad

Dieses Problem kann man möglicherweise in den Griff kriegen, wenn man anstelle von "-all" ein "~all" (mit Tilde) benutzt und damit sagt, dass man eine ambivalente Meinung über andere Server hat. Damit kann man quasi eine Whitelist pflegen um mit seinen echten E-Mails besser durch Spamfilter zu kommen, aber eine echte Dauerlösung ist SPF leider nicht.
Als schnelle Sofortmaßnahme durchaus geeignet, aber lieber sollte man in etwas zukunftssichereres investieren:

Weiterführende Lektüre zu SPF und Test-Tools

back-to-topDKIM + DMARC

D-Mark? Wir haben doch Euro!
Nein, DMARC - die handliche Abkürzung von "Domain-based Message Authentication, Reporting and Conformance".
Zusammen mit DKIM, der "DomainKeys Identified Mail", ist das eine robuste Lösung um echte von gefälschten Mails zu unterscheiden - allerdings bedeutet die Konfiguration dieser Technik je nach Mailserver unterschiedlich viel Aufwand und jemanden, der sich damit auskennt.

back-to-topWas macht man damit denn nun?
Mit DKIM werden die E-Mail-Header kryptographisch signiert.
Will heißen: Jede E-Mail, die Herr Hallmackenreuther über den echten Firmen-Mailserver verschickt, erhält von diesem ein paar zusätzliche unsichtbare Daten, mit denen sich die Echtheit und Integrität der E-Mail-Header (darin stehen z.B. Absender, Empfänger, Datum, Betreff u.s.w.) beweisen lässt.
Der Mailserver schaut sich dafür die Headerdaten an und errechnet darüber eine kryptographische Signatur für die Domain "firma.tld", die nur derjenige erzeugen kann, der den geheimen kryptographischen Schlüssel dafür hat (der auf dem Firmen-Mailserver gespeichert ist). Einen kleinen Teil dieses Schlüssels (der "öffentliche Schlüssel") veröffentlicht man als TXT-Record per DNS.
Dieser öffentliche Schlüssel passt nur zum geheimen, privaten Schlüssel des Mailservers.
Andere Mailserver, an die man E-Mails versendet, können mit der kryptographischen Signatur im E-Mail-Header und dem TXT-Record in der DNS-Zone nachprüfen, ob wirklich der echte Mailserver von "firma.tld" diese Signatur erzeugt hat und ob sie zwischenzeitlich (unerlaubter weise) verändert wurde.
Ist die Signatur in Ordnung wird die E-Mail angenommen, ist sie kaputt oder fehlerhaft prüft der Empfängerserver nach ob es einen DMARC-Record in der DNS-Zone von "firma.tld" gibt.
In diesem DMARC-Record steht drin, was passieren soll wenn die Signatur nicht verifiziert werden kann - z.B. ob die Mail trotzdem als OK angesehen oder direkt abgelehnt werden soll.

Das Ganze ist deutlich aufwendiger als die SPF-Lösung, aber dafür ist es hier vollkommen egal von welchen IP-Adressen aus die E-Mail verschickt wird solange die Header intakt und unverändert bleiben - und das ist normalerweise auch bei den verwinkelsten Mailweiterleitungen der Fall.
Ein Spammer kann auch nicht einfach die vorhandene Signatur einer versendeten, echten E-Mail kopieren und für eigene Zwecke missbrauchen - denn er könnte ja den Empfänger oder Betreff nicht verändern ohne dass die DKIM-Signatur kaputtgeht und ungültig wird.

Je nach Mailserver ist das unterschiedlich viel Implementationsaufwand. Zudem braucht es dafür gewisse Grundkenntnisse in Sachen E-Mail, DNS und kryptographischen Signaturen.
Im Zweifel sollte man sich notfalls einen Dienstleister holen, der einem das einmal schön einrichtet und konfiguriert.

Weiterführende Lektüre zu DKIM/DMARC und Test-Tools

Content-Key: 324361

Url: https://administrator.de/contentid/324361

Ausgedruckt am: 19.03.2024 um 11:03 Uhr

Mitglied: the-buccaneer
the-buccaneer 20.12.2016 um 22:52:17 Uhr
Goto Top
danke. ist der text auf deinem mist gewachsen? gut beschrieben. sonst bitte quelle angeben.

schade, dass die spf-implementierung offenbar nicht vorsieht, nur die mailserveradresse des 1. mailservers zu checken. die ist ja auch im falle hallmackenreuther --> lindemann korrekt und steht im header an oberster stelle.

trotzdem informativ. wieder was gelernt.

gruß
buc
Mitglied: LordGurke
LordGurke 21.12.2016 um 00:16:56 Uhr
Goto Top
Danke - ich schreibe meine Texte immer selber. Mit Bedacht und Sarkasmus face-wink
Mitglied: Olfryygt
Olfryygt 21.12.2016 um 10:18:53 Uhr
Goto Top
Interessant, danke dafür face-smile

Zum Thema SPF gab es letztens ein Thema hier, was mit passenden Links gespickt war:
SPF richtig Einstellen

Und da findet man auch einen Link zum Thema, warum -all nicht verwendet werden sollte:
https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-r ...

Vielleicht kannst du das ja brauchen, is imho auf jeden Fall nützliche Info.

Lg
Mitglied: vBurak
vBurak 21.12.2016 um 21:52:21 Uhr
Goto Top
Vielen Dank für die ausführliche Beschreibung!

Jetzt hätte ich aber eine Frage zu "-all":

Wenn das nicht empfohlen wird und auch Weiterleitungen letztendlich nicht zulässt warum sagt Microsoft dass man bei Office 365 einen SPF Eintrag mit "-all" machen soll (https://technet.microsoft.com/de-de/library/mt712724(v=exchg.150).aspx)

Ich habe bei uns nochmal nachgeschaut und hatte damals alle DNS Einstellungen wie es Microsoft vorgibt übernommen. Jetzt sehe ich, dass dort -all eingetragen ist und nicht ~all.
Mitglied: Dani
Dani 21.12.2016 um 22:56:01 Uhr
Goto Top
Moin @vBurak
Wenn das nicht empfohlen wird und auch Weiterleitungen letztendlich nicht zulässt warum sagt Microsoft dass man bei Office 365 einen SPF Eintrag mit "-all" machen soll (https://technet.microsoft.com/de-de/library/mt712724(v=exchg.150).aspx)
naja, solange der Hoster, an den du die Mail weiterleitest, diese SPF-Einträge nicht prüft bzw. umsetzt, hast du kein Problem. Aber sobald z.B. die Mails an gmx.de/web.de geht, wird diese als SPAM markiert bzw. evtl. auch schon abgelehnt. Letztendlich kann die Frage nur Microsoft beantworten.


Gruß,
Dani
Mitglied: LordGurke
LordGurke 22.12.2016 um 21:37:01 Uhr
Goto Top
Zitat von @vBurak:
Wenn das nicht empfohlen wird und auch Weiterleitungen letztendlich nicht zulässt warum sagt Microsoft dass man bei Office 365 einen SPF Eintrag mit "-all" machen soll (https://technet.microsoft.com/de-de/library/mt712724(v=exchg.150).aspx)

Wenn es zu Problemen bei E-Mail-Weiterleitungen kommt und "-all" aktiviert ist, werden die E-Mails abgelehnt, weil du als Verwalter der Absender-Domain festgelegt hast, dass das passieren soll.
Bei ~all legst du fest, dass der Server da selbst eine Meinung zu haben soll und besser basierend auf weiteren Kritieren festlegt ob die Mail nun abgelehnt wird oder nicht. Dieser Eintrag führt also nicht zwingend zur Ablehnung einer E-Mail weil die SPF-Verifikation fehlschlägt, kann aber bei positivem SPF-Test dazu führen, dass deine E-Mails besser bewertet werden.
Der Qualifikator "~all" führt zu einem sogenannten "SOFT-FAIL", bei "-all" wird es ein richtiger "FAIL".

Insgesamt ist das ganze Spamfilter-Thema aber etwas, wo du selbst nur wenig zu beitragen kannst, wie sich ein Remote-Server verhält und was diese bei fehlschlagenden DKIM-/oder SPF-Prüfungen so machen.
Mitglied: vBurak
vBurak 22.12.2016 um 23:09:06 Uhr
Goto Top
@Dani @LordGurke
Danke, gut zu wissen. Ich lass die Einstellung mit "-all" erstmal da wir eh keine Weiterleitung verwenden. Vielleicht macht es für Microsoft auch einfach keinen Sinn, seine Emails an eine externe Mail-Adresse weiterzuleiten vor allem wenn man OWA Zugriff hat. Sehe auf die schnelle auch kein Szenario warum sowas gemacht werden soll.
Mitglied: the-buccaneer
the-buccaneer 24.12.2016 um 01:50:28 Uhr
Goto Top
Sicher sehr legitim und im Einzelfall auch sinnvoll...
Aber: Da wohl 99% allen Spams von gekaperten Rechnern/Accounts/IOT-Dosen ausgeht eher ein Nischenfall...

Was ich mich frage (da ich keinen Mailserver offen im Netz habe) ist, ob die Provider das irgendwie nutzen. Wahrscheinlich nicht, da Komplikationen.

Werde den Eintrag bei meinem "Smarthost" mal spasseshalber setzen. mal sehen, was passiert.

Frohe Weihnachten!
Buc
Mitglied: LordGurke
LordGurke 24.12.2016 um 01:54:32 Uhr
Goto Top
Zitat von @vBurak:
@Dani @LordGurke
Danke, gut zu wissen. Ich lass die Einstellung mit "-all" erstmal da wir eh keine Weiterleitung verwenden. Vielleicht macht es für Microsoft auch einfach keinen Sinn, seine Emails an eine externe Mail-Adresse weiterzuleiten vor allem wenn man OWA Zugriff hat. Sehe auf die schnelle auch kein Szenario warum sowas gemacht werden soll.

Du vielleicht nicht. Das ist aber auch nicht das Problem. Das Problem tritt auf, wenn der EMPFÄNGER, an den du die Mails sendest eine Weiterleitung einrichtet und du als Absender SPF mit Hard-Fail nutzt face-wink
Mitglied: LordGurke
LordGurke 24.12.2016 um 01:57:07 Uhr
Goto Top
Zitat von @the-buccaneer:

Sicher sehr legitim und im Einzelfall auch sinnvoll...
Aber: Da wohl 99% allen Spams von gekaperten Rechnern/Accounts/IOT-Dosen ausgeht eher ein Nischenfall...

Genau das erreicht man doch mit beiden Verfahren - man macht für die Empfänger-Mailserver erkennbar, wenn ein Absender von einem infizierten Kühlschrank versendet wird da entweder (SPF) die IP-Adressen nicht passen oder (DKIM) die DKIM-Signatur ungültigt ist oder fehlt face-wink

Dagegen, dass dein eigener Mailserver aufgemacht und für Spam-Versand missbraucht wird hilft das überhaupt nicht - aber sehr wohl gegen das ziemlich präsente Problem, dass seriöse Domains mit guter Reputation als Absender eingetragen werden und du als Domaineigentümer den Ärger deswegen hast.
Mitglied: LordGurke
LordGurke 24.02.2019 aktualisiert um 20:03:37 Uhr
Goto Top
Nachtrag dazu:
Momentan wird meine private Domain von Dritten missbraucht, um Spam zu versenden.
Ich habe aber nicht nur diese Anleitung niedergeschrieben sondern auch gehandelt und habe demzufolge DMARC-Einträge auf meiner Domain, welche die Ablehnung ungültiger oder fehlender DKIM-Signaturen empfiehlt.

Aufgefallen ist mir der Missbrauch der Domain nicht durch Backscatter (ich bekam wirklich nicht einen einzigen) sondern weil ich auch das DMARC-Reporting aktiviert haben und deshalb einen ganzen Stapel Reports bekommen habe. Diese sehen dann so aus, wie man Ende dieses Beitrags.
Und ich bekam nicht nur einen sondern innerhalb eines Tages um die 30 Reports, die über insgesamt gut 200 Mail-Einlieferungsversuche berichteten. Und wie gesagt: Nicht ein einziger Backscatter! face-smile

Etwas leichter lesbar, wenngleich nicht automatisiert auswertbar, sind "forensiche Reports" wie dieser hier:
A message claiming to be from you has failed the published DMARC
policy for your domain.

  Sender Domain: meinedomain.tld
  Sender IP Address: 190.16.87.6
  Received Date: Sun, 24 Feb 2019 14:10:14 +0100
  SPF Alignment: no
  DKIM Alignment: no
  DMARC Results: Reject

------ This is a copy of the headers that were received before the error
       was detected.

Received: from 6-87-16-190.fibertel.com.ar ([190.16.87.6])
	by mx104.antispamcloud.com with esmtp (Exim 4.89)
	(envelope-from <benutzer@meinedomain.tld>)
	id 1gxtXo-0001Ch-H1
	for matthew@???????????????.co.uk; Sun, 24 Feb 2019 14:10:14 +0100
Message-ID: <004301d4cc29$05027589$75446e85@yxpvya>
From: "matthew@????????????.co.uk" <benutzer@meinedomain.tld>
To: <matthew@??????????.co.uk>
Subject: Earn 500.000 Euro
Date: 24 Feb 2019 05:39:09 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-DKIM-Status: none /  / meinedomain.tld /  /  / 


Die aggregierten Reports, die dann in der Regel einen Zeitraum von mehreren Stunden abdecken, kommen per XML und sind maschinell auswertbar:

<?xml version="1.0" encoding="UTF-8" ?>  
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>16364689978601024564</report_id>
    <date_range>
      <begin>1550880000</begin>
      <end>1550966399</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>meinedomain.tld</domain>
    <adkim>s</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>200.119.218.195</source_ip>
      <count>5</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>meinedomain.tld</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>meinedomain.tld</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>113.182.107.196</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>meinedomain.tld</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>meinedomain.tld</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>192.114.74.103</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>meinedomain.tld</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>meinedomain.tld</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>
</feedback>