21
Exchange Online - spoofing paradise - wie verhindern?!?
Hi zusammen,
wir nutzen rein den Exchange Online von Microsoft, ohne eine On-Premise Exchange.
nachdem wir vermehrt Phisingmails erhalten die als Absender die korrekten Adressen aus der Führungsebene enthielten, suchen wir nach Optionen, um solche Mails so gut es geht zu vermeiden.
Zum Test habe ich folgenden PS-Script getestet:
Das funktioniert nicht nur von der static-WAN-IP des Unternehmens, sondern auch von anderen Source-IPs.
Ist das Normal, das jeder wie er will ohne Authentifizierung Mails über jeden tenants versenden kann??? kostenloses Spoofing-Feature für alle Gauner!?
Vom On-Premise Exchange kenne ich, dass man dort Transportregeln definieren kann, die "anonyme user" anfragen nicht zulassen.
Kann man das nicht auch am Exchange Online einrichten?
Ja, ich habe den SPF-Eintrag als TXT-Record beim Provider mit der Unternehmens WAN-IP gesetzt.
Einerseits verhindert dass aber nicht dass solche spoofing-Mails vom Server angenommen werden und in Umlauf geraten (meiner Meinung nach ist der Schutz viel zu spät angesetzt)
Andererseits: Es werden sowieso nicht alle Mails aus dem Unternehmensnetzwerk gesendet. Mitarbeiter sind auf Geschäftsreise oder arbeiten im HomeOffice. Deren Source-IP ist dann natürlch NICHT im SPF Record.
Wenn dann noch eine Regel auf dem Exchange Online gesetzt wird, das Mails mit spf-fail besonders behandelt werden, passiert das auch mit den "echte" Mails, die nicht aus dem Unternehmensnetzwerk gesendet werden, oder sehe ich das falsch?
Und wie andere Unternehmen mit spf-fails umgehen, kann man schonmal garnicht beeinflussen. Also ist doch die einzige Konsequenz, dass man erreichen muss, dass smtp-server solche unauthorisierten Anfragen garnicht erst verabeitet.
Ich kann mir nur vorstellen dass ich komplett falsch liege und hoffe von euch ein bisschen Klarheit erhalte und mein Wissen/Verständnis erweitern kann.
beste Grüße
dave
wir nutzen rein den Exchange Online von Microsoft, ohne eine On-Premise Exchange.
nachdem wir vermehrt Phisingmails erhalten die als Absender die korrekten Adressen aus der Führungsebene enthielten, suchen wir nach Optionen, um solche Mails so gut es geht zu vermeiden.
Zum Test habe ich folgenden PS-Script getestet:
$mailParams = @{
SmtpServer = tenant.mail.protection.outlook.com'
Port = '25'
UseSSL = $false
From = 'bill.gates@tenant.com'
To = 'anyone@anywhere.com'
Subject = "Direct Send $(Get-Date -Format g)"
Body = 'What is going on?'
}
Send-MailMessage @mailParamsDas funktioniert nicht nur von der static-WAN-IP des Unternehmens, sondern auch von anderen Source-IPs.
Ist das Normal, das jeder wie er will ohne Authentifizierung Mails über jeden tenants versenden kann??? kostenloses Spoofing-Feature für alle Gauner!?
Vom On-Premise Exchange kenne ich, dass man dort Transportregeln definieren kann, die "anonyme user" anfragen nicht zulassen.
Kann man das nicht auch am Exchange Online einrichten?
Ja, ich habe den SPF-Eintrag als TXT-Record beim Provider mit der Unternehmens WAN-IP gesetzt.
Einerseits verhindert dass aber nicht dass solche spoofing-Mails vom Server angenommen werden und in Umlauf geraten (meiner Meinung nach ist der Schutz viel zu spät angesetzt)
Andererseits: Es werden sowieso nicht alle Mails aus dem Unternehmensnetzwerk gesendet. Mitarbeiter sind auf Geschäftsreise oder arbeiten im HomeOffice. Deren Source-IP ist dann natürlch NICHT im SPF Record.
Wenn dann noch eine Regel auf dem Exchange Online gesetzt wird, das Mails mit spf-fail besonders behandelt werden, passiert das auch mit den "echte" Mails, die nicht aus dem Unternehmensnetzwerk gesendet werden, oder sehe ich das falsch?
Und wie andere Unternehmen mit spf-fails umgehen, kann man schonmal garnicht beeinflussen. Also ist doch die einzige Konsequenz, dass man erreichen muss, dass smtp-server solche unauthorisierten Anfragen garnicht erst verabeitet.
Ich kann mir nur vorstellen dass ich komplett falsch liege und hoffe von euch ein bisschen Klarheit erhalte und mein Wissen/Verständnis erweitern kann.
beste Grüße
dave
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 630126
Url: https://administrator.de/forum/exchange-online-spoofing-paradise-wie-verhindern-630126.html
Ausgedruckt am: 12.04.2025 um 06:04 Uhr
21 Kommentare
Neuester Kommentar
Aehm, interne Mails werden auch nicht über SMTP Port 25 gesendet, sondern über MAPI oder Active Sync authentifiziert - es sei denn ihr habe Scanner, die darüber senden wollen.
Den SPF Eintrag interessiert deinen eigener Online Exchange Server gar nicht. Dieser Eintrag ist nur vorhanden, dass die "fremden" Empänger Eurer Emails prüfen können ob es wirklich von Eurem Exchange Server kommt. Eure Emails kommen erst einmal eben über MAPI oder Active Sync zum Eurem Online Exchange Server und von dort aus werden sie zu fremden Empfängern versendet. Es ist also egal wo bzw hinter welcher IP sich der Mitarbeiter befindet.
Exchange Online hat doch auch einen Exchange Control Panel mit Spam Einstellungen und Empfangs- und Sendeconnectoren. Da musst du suchen...
Den SPF Eintrag interessiert deinen eigener Online Exchange Server gar nicht. Dieser Eintrag ist nur vorhanden, dass die "fremden" Empänger Eurer Emails prüfen können ob es wirklich von Eurem Exchange Server kommt. Eure Emails kommen erst einmal eben über MAPI oder Active Sync zum Eurem Online Exchange Server und von dort aus werden sie zu fremden Empfängern versendet. Es ist also egal wo bzw hinter welcher IP sich der Mitarbeiter befindet.
Exchange Online hat doch auch einen Exchange Control Panel mit Spam Einstellungen und Empfangs- und Sendeconnectoren. Da musst du suchen...
Du musst die SPF prüfung in der Exchange Online Anti Spam Richtlinie anschalten! Ich glaube die ist standardmäßig aus.
Dort kannst du auch noch viel mehr einstellen wie Spam Bewertungen etc. pp.
Dort kannst du auch noch viel mehr einstellen wie Spam Bewertungen etc. pp.
Danke NordicMike,
- dass die Clients laut tollem MS-Artikel "modernen Authentifizierungsmethoden" verwenden ist mir klar, aber den soppfer interessiert das nicht wenn Port 25 wie ein offenes Scheunentor winkt.
- Im eMail-Header sehe ich als Source-IP die Adresse des Clients, nicht des Exchange Online Servers.
Aber es stimmt das echt Mails (zb aus Outlook) die von ausserhalb des Unternehmensnetzwerks gesendet werden, zumindest keinen spf fail Eintrag im Header enthalten.
Greift SPF nur bei bestimmte Protokollen?
- Exchange Online hat "Connectoren" die den empfangs und sende connectoren entsprechen sollen, allerdings sucht man dort solche Einstellungen vergebens.
- dass die Clients laut tollem MS-Artikel "modernen Authentifizierungsmethoden" verwenden ist mir klar, aber den soppfer interessiert das nicht wenn Port 25 wie ein offenes Scheunentor winkt.
- Im eMail-Header sehe ich als Source-IP die Adresse des Clients, nicht des Exchange Online Servers.
Aber es stimmt das echt Mails (zb aus Outlook) die von ausserhalb des Unternehmensnetzwerks gesendet werden, zumindest keinen spf fail Eintrag im Header enthalten.
Greift SPF nur bei bestimmte Protokollen?
- Exchange Online hat "Connectoren" die den empfangs und sende connectoren entsprechen sollen, allerdings sucht man dort solche Einstellungen vergebens.
@Ex0r2k16:
Danke für den Hinweis, an dieser Stelle ist mein SPAM-Schutz schon sehr stark konfiguriert, inklusive aktiver SPF-Prüfung - die aber leider nicht greift, wenn im Header ein spf-fail enthalten ist. - den grund dafür kann ich mir auch nicht erklären.
Danke für den Hinweis, an dieser Stelle ist mein SPAM-Schutz schon sehr stark konfiguriert, inklusive aktiver SPF-Prüfung - die aber leider nicht greift, wenn im Header ein spf-fail enthalten ist. - den grund dafür kann ich mir auch nicht erklären.
Hi
Wenn Ihr intern kein SMTP Relaying macht, dann braucht ihr da nix, ansonsten muss das entweder auf eure IP eingeschränkt werden und\oder ein entsprchender Dienst im Internen Netz aufgesetzt und genutzt werde, der die Mails von den Druckern, irgendwelchen Mail-versendenden Servern etc entgegennimmt und diese dann an Exchange-Online übergibt.
SPF prüft nur ob der sendende Server überhaupt im Namen der entsprechenden Domain senden darf.
Behebe deinen SPF und kontrolliere deine Connectoren.
Wenn ihr Intern Geräte habt die per SMTP mit dem Exchange reden, dann musst du entweder einen Connector haben der eure externe IP zulässt und die Clients dann direkt mit EO reden lässt, oder besser, du setzt einen internen Relay auf der die Mails übergibt und sich ordentlich mit einem Zertifikat authentifiziert
Ist das Normal, das jeder wie er will ohne Authentifizierung Mails über jeden tenants versenden kann??? kostenloses Spoofing-Feature für alle Gauner!?
Was denkst du denn? Nein natürlich nicht.Vom On-Premise Exchange kenne ich, dass man dort Transportregeln definieren kann, die "anonyme user" anfragen nicht zulassen.
Kann man das nicht auch am Exchange Online einrichten?
Connectoren nennt sich das und ihr habt wahrscheinlich einen der vom grossen weiten Netz einfach alles zulässt.Kann man das nicht auch am Exchange Online einrichten?
Wenn Ihr intern kein SMTP Relaying macht, dann braucht ihr da nix, ansonsten muss das entweder auf eure IP eingeschränkt werden und\oder ein entsprchender Dienst im Internen Netz aufgesetzt und genutzt werde, der die Mails von den Druckern, irgendwelchen Mail-versendenden Servern etc entgegennimmt und diese dann an Exchange-Online übergibt.
Ja, ich habe den SPF-Eintrag als TXT-Record beim Provider mit der Unternehmens WAN-IP gesetzt.
Warum, wenn ihr keinen internen SMTP habt? Da muss - nach dem was du bisher gesagt hast - nur der EOP Eintrag rein.Andererseits: Es werden sowieso nicht alle Mails aus dem Unternehmensnetzwerk gesendet. Mitarbeiter sind auf Geschäftsreise oder arbeiten im HomeOffice. Deren Source-IP ist dann natürlch NICHT im SPF Record.
Du hast glaube ich SPF nicht verstanden. Da geht es nicht um den Client der was schickt, sondern um die Kommunikation der SMTP Server untereinander. Deine Clients kommen da authentifiziert über ActiveSync\MAPI rein.SPF prüft nur ob der sendende Server überhaupt im Namen der entsprechenden Domain senden darf.
Wenn dann noch eine Regel auf dem Exchange Online gesetzt wird, das Mails mit spf-fail besonders behandelt werden, passiert das auch mit den "echte" Mails, die nicht aus dem Unternehmensnetzwerk gesendet werden, oder sehe ich das falsch?
Siehst du falsch. Wie schon geschrieben haben die Clients dabei keine Aktien im Spiel und es ist egal von welcher IP der Client seine Mail an den Server übergibt. Der darf das, weil er sich authentifiziert hat.Und wie andere Unternehmen mit spf-fails umgehen, kann man schonmal garnicht beeinflussen.
Interessiert dich auch nur bedingt. Du willst ja nur das niemand sich als DU ausgeben kann, oder als deine Firma.Also ist doch die einzige Konsequenz, dass man erreichen muss, dass smtp-server solche unauthorisierten Anfragen garnicht erst verabeitet.
Korrekt. Und dafür gibt's authentifizierung für den Client und SPF, DKIM und DMARK für die ServerIch kann mir nur vorstellen dass ich komplett falsch liege
Jupp Behebe deinen SPF und kontrolliere deine Connectoren.
Wenn ihr Intern Geräte habt die per SMTP mit dem Exchange reden, dann musst du entweder einen Connector haben der eure externe IP zulässt und die Clients dann direkt mit EO reden lässt, oder besser, du setzt einen internen Relay auf der die Mails übergibt und sich ordentlich mit einem Zertifikat authentifiziert
Noch ein Beispiel zum Verständnis von SPF:
Wenn "du" eine Email an info@administrator.de schickst, überprüft der Mail Server von administrator.de deinen SPF Eintrag und vergleicht es mit dem Exchange Server, der ihm die Email geschickt hat. Wenn die Email von einem anderen Exchange Server kam, bricht er sofort ab. Wenn du gar keinen SPF Eintrag hast, muss er die Email durchlassen, weil er nicht prüfen kann ob sie vom richtigen Server kommt. Ob du mit Deinem Endgerät dabei im internen Netz warst oder unterwegs, ist für administrator.de nicht mehr relevant.
Somit hat dein SPF Eintrag keine Auswirkung auf "deinen" Spamschutz, aber eine Auswirkung auf den Spamschutz vom Mailserver von administrator.de. Es reicht also, wenn in Deinem SPF Text nur die Adressen des Online Exchange Servers existieren, Deine WAN IP interessiert damit niemanden mehr. Üblicher weise gehen die Email immer per SMTP (Port 25, 587, 465) zu fremden Servern, somit ist der SPF Eintrag nur auf das SMTP Protokoll begrenzt.
Dein Server bzw dein Spamschutz wird "deinen" SPF Eintrag also niemals auslesen, nur immer die anderen...
Wenn "du" eine Email an info@administrator.de schickst, überprüft der Mail Server von administrator.de deinen SPF Eintrag und vergleicht es mit dem Exchange Server, der ihm die Email geschickt hat. Wenn die Email von einem anderen Exchange Server kam, bricht er sofort ab. Wenn du gar keinen SPF Eintrag hast, muss er die Email durchlassen, weil er nicht prüfen kann ob sie vom richtigen Server kommt. Ob du mit Deinem Endgerät dabei im internen Netz warst oder unterwegs, ist für administrator.de nicht mehr relevant.
Somit hat dein SPF Eintrag keine Auswirkung auf "deinen" Spamschutz, aber eine Auswirkung auf den Spamschutz vom Mailserver von administrator.de. Es reicht also, wenn in Deinem SPF Text nur die Adressen des Online Exchange Servers existieren, Deine WAN IP interessiert damit niemanden mehr. Üblicher weise gehen die Email immer per SMTP (Port 25, 587, 465) zu fremden Servern, somit ist der SPF Eintrag nur auf das SMTP Protokoll begrenzt.
Dein Server bzw dein Spamschutz wird "deinen" SPF Eintrag also niemals auslesen, nur immer die anderen...
@SeaStorm:
besten Dank für deine Erläuterung, in der Tat waren mir die Zusammenhänge so nicht so klar und du hast mich defintiv weiter gebracht.
Dann ist also dieses kurze Script aus dem ersten post als "Server-zu-Server" kommunikation zu betrachten? Da hier keine Authentifizierung im Sinne von Clientkommunikation erforderlich ist?
Und im eMail Header der erzeugten Mail ist auch der spf fail aufgeführt (was ja dafür spricht, dass die SPF kontrolle greift) ...nur leider interessiert es den Exchange Online SpamFilter (trotz aktivem SPF Schutz) und den Outlook-Client recht wenig und stellt die Mail gnadenlos zu.
Wir haben tatsächlich einen internen SMTP-Relay-Server.
Im Exchange Online ist nur ein Connector aktiv der "Von Unternehmens-WAN-IP ZU Office365" konfiguriert ist.
Also sollte das script von einer anderen WAN-IP doch nicht in der Lage sein, eine mail zu verschicken, was es jedoch tut!?
besten Dank für deine Erläuterung, in der Tat waren mir die Zusammenhänge so nicht so klar und du hast mich defintiv weiter gebracht.
Dann ist also dieses kurze Script aus dem ersten post als "Server-zu-Server" kommunikation zu betrachten? Da hier keine Authentifizierung im Sinne von Clientkommunikation erforderlich ist?
Und im eMail Header der erzeugten Mail ist auch der spf fail aufgeführt (was ja dafür spricht, dass die SPF kontrolle greift) ...nur leider interessiert es den Exchange Online SpamFilter (trotz aktivem SPF Schutz) und den Outlook-Client recht wenig und stellt die Mail gnadenlos zu.
Wir haben tatsächlich einen internen SMTP-Relay-Server.
Im Exchange Online ist nur ein Connector aktiv der "Von Unternehmens-WAN-IP ZU Office365" konfiguriert ist.
Also sollte das script von einer anderen WAN-IP doch nicht in der Lage sein, eine mail zu verschicken, was es jedoch tut!?
Zitat von @glad0s:
@SeaStorm:
Dann ist also dieses kurze Script aus dem ersten post als "Server-zu-Server" kommunikation zu betrachten? Da hier keine Authentifizierung im Sinne von Clientkommunikation erforderlich ist?
Wenn du hier mails versenden willst, muss eine Authentifizierung erfolgen, weil dein Server ja sonst nicht weiss wer du bist und ob du senden darfst. Wenn du ohne authentifizierung senden darfst, dann kommst du entweder von einer IP die das ohne Auth darf, oder der Server ist entsprechend falsch eingestellt.@SeaStorm:
Dann ist also dieses kurze Script aus dem ersten post als "Server-zu-Server" kommunikation zu betrachten? Da hier keine Authentifizierung im Sinne von Clientkommunikation erforderlich ist?
Wenn du eine mail zustellen willst (also das was ein anderer Mailserver macht), dann braucht es natürlich keine Authentifizierung, aber dein Server sollte diverse Dinge wie SPF, reverse-DNS usw prüfen um den eingehenden Server zu validieren.
Und im eMail Header der erzeugten Mail ist auch der spf fail aufgeführt (was ja dafür spricht, dass die SPF kontrolle greift)
Das heisst das der sendende laut SPF Eintrag nicht hätte senden dürfen...nur leider interessiert es den Exchange Online SpamFilter (trotz aktivem SPF Schutz)
Hier gibt es 2 Dinge: SPF Fail gibt es als Soft und als Hard Fail. Softfail ist quasi eine Empfehlung. Wenn der SPF Check failed, dann erhöht der empfänger meistens nur das Spam-Rating. Das kann man also auch gleich sein lassen.Sinniger ist also das Hard-Fail. Wenn das im SPF Record steht, dann ist das die Anweisung "Wenn der SPF Check fehlschlägt, dann schmeiss die Mail weg!".
EO hat allerdings eine Option um auch das zu ignorieren. Von gammeligen Dienstleistern wird das gerne mal eingestellt, weil man dann weniger "Probleme" mit abgelehnten Mails hat. Schau mal unter
https://protection.office.com/antispam -> Standard-Spamfilterrichtlinie -> Bearbeiten -> Spameigenschaften -> Als Spam markieren -> SPF-Eintrag schwerer Fehler
Das muss an ein, genau wie "Bedingte Absender-ID-Filterung" darunter
Aber dazu muss dann auch der SPF-Eintrag von euch stimmen, sonst bekommen eure Kunden auch keine Mails mehr von euch
Wir haben tatsächlich einen internen SMTP-Relay-Server.
Im Exchange Online ist nur ein Connector aktiv der "Von Unternehmens-WAN-IP ZU Office365" konfiguriert ist.
Also sollte das script von einer anderen WAN-IP doch nicht in der Lage sein, eine mail zu verschicken, was es jedoch tut!?
Prüfe mal den Mailheader wer denn der tasächliche Absender war. Nicht das die Mail von intern kommt
Wenn du hier mails versenden willst, muss eine Authentifizierung erfolgen, weil dein Server ja sonst nicht weiss wer du bist und ob du senden darfst. Wenn du ohne authentifizierung senden darfst, dann kommst du entweder von einer IP die das ohne Auth darf, oder der Server ist entsprechend falsch eingestellt.
Wenn du eine mail zustellen willst (also das was ein anderer Mailserver macht), dann braucht es natürlich keine Authentifizierung, aber dein Server sollte diverse Dinge wie SPF, reverse-DNS usw prüfen um den eingehenden Server zu validieren.
Wenn du eine mail zustellen willst (also das was ein anderer Mailserver macht), dann braucht es natürlich keine Authentifizierung, aber dein Server sollte diverse Dinge wie SPF, reverse-DNS usw prüfen um den eingehenden Server zu validieren.
Hier meine Tests:
Ich lasse das script hinter der zugelassenen WAN-IP laufen -> mail kommt an und im Header der erzeugten Mail is alles in ordnung da steht "Authentication-Results: spf=pass (sender IP is xxx.xx.xxx.xxx)" wobei die IP die WAN-IP der Firma ist, die auch im Connector enthalten ist, und im SPF EIntrag steht
Ich mache von der Firma eine VPN Verbindung zu einem anderen Standort auf und lasse das script laufen -> mail kommt an und im Header der erzeugten Mail steht "Authentication-Results: spf=fail (sender IP is yy.yyy.yyy.yyy)" wobei die IP die WAN-IP vom VPN standort ist.
Hier gibt es 2 Dinge: SPF Fail gibt es als Soft und als Hard Fail. Softfail ist quasi eine Empfehlung. Wenn der SPF Check failed, dann erhöht der empfänger meistens nur das Spam-Rating. Das kann man also auch gleich sein lassen.
Sinniger ist also das Hard-Fail. Wenn das im SPF Record steht, dann ist das die Anweisung "Wenn der SPF Check fehlschlägt, dann schmeiss die Mail weg!".
Sinniger ist also das Hard-Fail. Wenn das im SPF Record steht, dann ist das die Anweisung "Wenn der SPF Check fehlschlägt, dann schmeiss die Mail weg!".
Der SPF EIntrag sieht so aus: DOMAIN.com 300 IN TXT "v=spf1 ip4:xxx.xx.xxx.xxx include:spf.protection.outlook.com -all" ..sollte also ein hardfail sein!?
EO hat allerdings eine Option um auch das zu ignorieren. Von gammeligen Dienstleistern wird das gerne mal eingestellt, weil man dann weniger "Probleme" mit abgelehnten Mails hat. Schau mal unter
https://protection.office.com/antispam -> Standard-Spamfilterrichtlinie -> Bearbeiten -> Spameigenschaften -> Als Spam markieren -> SPF-Eintrag schwerer Fehler
Das muss an ein, genau wie "Bedingte Absender-ID-Filterung" darunter
https://protection.office.com/antispam -> Standard-Spamfilterrichtlinie -> Bearbeiten -> Spameigenschaften -> Als Spam markieren -> SPF-Eintrag schwerer Fehler
Das muss an ein, genau wie "Bedingte Absender-ID-Filterung" darunter
Da ist es etwas interessanter. ich habe die Default AntispamFilter Regel, die ist auf Priorität "niedrigste" und dort sind diese beiden Einträge deaktiviert.
Dann habe ich aber noch eine zweite Regel "Strong" mit der Priorität "0" darüber, in der sind beide Einträge aktiviert.
Wird Strong tatsächlich ignoriert weil default schon greift!??
Aber dazu muss dann auch der SPF-Eintrag von euch stimmen, sonst bekommen eure Kunden auch keine Mails mehr von euch
s.o. sollte passen.
Und der ist so eingestellt das der nur von eurer IP die Verbindung zulässt? Und sonst gibt's keinen anderen Connector?
exakt, hier ist definitiv nur diese eine WAN-IP zugelassen.
Prüfe mal den Mailheader wer denn der tasächliche Absender war. Nicht das die Mail von intern kommt
s.o. sind also unterschiedliche absender IPs.
Der SPF EIntrag sieht so aus: DOMAIN.com 300 IN TXT "v=spf1 ip4:xxx.xx.xxx.xxx include:spf.protection.outlook.com -all" ..sollte also ein hardfail sein!?
JaDa ist es etwas interessanter. ich habe die Default AntispamFilter Regel, die ist auf Priorität "niedrigste" und dort sind diese beiden Einträge deaktiviert.
Dann habe ich aber noch eine zweite Regel "Strong" mit der Priorität "0" darüber, in der sind beide Einträge aktiviert.
Wird Strong tatsächlich ignoriert weil default schon greift!??
Ignoriert wohl nicht. Es kommt hier vermutlich auf die Details an. Hier kannst du ja diverse "Bedingungen" Einstellen auf wen die Regel gilt. Nur von gewissen Absenderdomänen usw. Ich vermute mal das deine STRONG hier entsprechend eingeschränkt wirkt und deshalb auf die default-Regel zurückgegriffen wirdDann habe ich aber noch eine zweite Regel "Strong" mit der Priorität "0" darüber, in der sind beide Einträge aktiviert.
Wird Strong tatsächlich ignoriert weil default schon greift!??
IMHO gehören die beiden genannten Einträge aber auf der default Richtlinie aktiviert.
Ich bin mir da grad ziemlich sicher... schalte das an und du bist deine SPF Probleme los.
Und dann kümmerst du dich noch um DKIM und DMARC ;)
Danke @SeaStorm, du hast mir wirklich enorm weiter geholfen.
Klar, die Postfächer bekomme ich damit dann geschützt und noch stärker wenn DKIM und DMARC implementiert werden.
Aber: Mein Tanent SMTP-Server ist weiterhin in der Lage, unauthorisiert spoof zu versenden.
ich habe jetzt noch von zwei weiteren WAN-IPs den test gemacht, und der Server schickt die wirklich weiter...
Die EO connectors hab ich schon zig mal gecheckt, da gibt es nur einen und der hat nur unsere WAN-IP als quelle zugelassen. ...mir fällt echt nichtmehr ein was man noch tun kann.
Kann man keine authentifizierung für Anfragen zum versand aktivieren?
Klar, die Postfächer bekomme ich damit dann geschützt und noch stärker wenn DKIM und DMARC implementiert werden.
Aber: Mein Tanent SMTP-Server ist weiterhin in der Lage, unauthorisiert spoof zu versenden.
ich habe jetzt noch von zwei weiteren WAN-IPs den test gemacht, und der Server schickt die wirklich weiter...
Die EO connectors hab ich schon zig mal gecheckt, da gibt es nur einen und der hat nur unsere WAN-IP als quelle zugelassen. ...mir fällt echt nichtmehr ein was man noch tun kann.
Kann man keine authentifizierung für Anfragen zum versand aktivieren?
Aber: Mein Tanent SMTP-Server ist weiterhin in der Lage,
Sprichst du da von einem Exchange Server? Das ist doch der oben erwähnte SMTP Proxy, oder? Vermutlich ein Linux Rechner?
Ich meine den Exchange Online, mit dem send-MailMessage Befehl spreche ich direkt die smtp-server Adresse von meinem tenant an.
Der send-MailMessage befehl geht:
- ohne authentifizierung
- egal von welcher öffentlichen-IP. (nur static muss sie sein, da viele Provider Mailversand von dynmaic-IPs mittlerweile als kompromittierte Systeme ansehen und das generell blocken)
- egal wie der absender heißt (egal ob dazu ein Postfach exitiert oder nicht)
- egal ob empfänger intern oder extern ist
Der send-MailMessage befehl geht:
- ohne authentifizierung
- egal von welcher öffentlichen-IP. (nur static muss sie sein, da viele Provider Mailversand von dynmaic-IPs mittlerweile als kompromittierte Systeme ansehen und das generell blocken)
- egal wie der absender heißt (egal ob dazu ein Postfach exitiert oder nicht)
- egal ob empfänger intern oder extern ist
Zitat von @glad0s:
Hi zusammen,
Ja, ich habe den SPF-Eintrag als TXT-Record beim Provider mit der Unternehmens WAN-IP gesetzt.
Einerseits verhindert dass aber nicht dass solche spoofing-Mails vom Server angenommen werden und in Umlauf geraten (meiner Meinung nach ist der Schutz viel zu spät angesetzt)
Andererseits: Es werden sowieso nicht alle Mails aus dem Unternehmensnetzwerk gesendet. Mitarbeiter sind auf Geschäftsreise oder arbeiten im HomeOffice. Deren Source-IP ist dann natürlch NICHT im SPF Record.
beste Grüße
dave
Hi zusammen,
Ja, ich habe den SPF-Eintrag als TXT-Record beim Provider mit der Unternehmens WAN-IP gesetzt.
Einerseits verhindert dass aber nicht dass solche spoofing-Mails vom Server angenommen werden und in Umlauf geraten (meiner Meinung nach ist der Schutz viel zu spät angesetzt)
Andererseits: Es werden sowieso nicht alle Mails aus dem Unternehmensnetzwerk gesendet. Mitarbeiter sind auf Geschäftsreise oder arbeiten im HomeOffice. Deren Source-IP ist dann natürlch NICHT im SPF Record.
beste Grüße
dave
Bist Du dir sicher, dass das so richtig ist und du verstanden hast was SPF und DKIM machen sollen?!
Irgendwas passt da noch nicht. Mach doch mal Screenshots von den ganzen Connector-Einstellungen
[EDIT]
Was hast du denn bei
https://protection.office.com/antispam
unter Verbindungsfilterrichtlinie eingestellt?
Hier kannst du prinzipiell ja auch IPs\Netze whitelisten. Ist da vielleicht irgendwas blödes eingetragen?
[EDIT]
Was hast du denn bei
https://protection.office.com/antispam
unter Verbindungsfilterrichtlinie eingestellt?
Hier kannst du prinzipiell ja auch IPs\Netze whitelisten. Ist da vielleicht irgendwas blödes eingetragen?
@142583
Nein, der Threadverlauf zeigen ja dass mein Verständnis hier noch lückenhaft war, SeaStorm sich jedoch die Mühe gemacht hat, die Unklarheiten fürs erste zu beseitigen, wie man dem Threadverlauf entnehmen kann.
@SeaStorm
Connectors:
Antispam Verbindungsfilter:
akzeptierte Domänen:
Remotedomänen:
e-Mail Fluss Regeln:
Ich wüsste nicht, was ich noch prüfen könnte, um das Verhalten zu ändern.
BTW: ich habe die beiden Punkte "SPF-Eintrag schwerer Fehler" und "...ID-Filterung" in der Default AntiSpam Regel aktiviert - die eMails gehen leider immernoch durch und im Header steht nach wie vor "spf=fail" (sollte dort nicht auch schon differenziert aufgeführt werden, ob nun soft oder hardfail?)
...also würde einfach alles ignoriert werden was ich einstelle. (und es ist definitiv der richtige tenant in dem ich angemeldet bin, ich habe keinen anderen)
Nein, der Threadverlauf zeigen ja dass mein Verständnis hier noch lückenhaft war, SeaStorm sich jedoch die Mühe gemacht hat, die Unklarheiten fürs erste zu beseitigen, wie man dem Threadverlauf entnehmen kann.
@SeaStorm
Irgendwas passt da noch nicht. Mach doch mal Screenshots von den ganzen Connector-Einstellungen
da stimme ich dir zu, hier mal ein paar screenshots:Connectors:
Antispam Verbindungsfilter:
akzeptierte Domänen:
Remotedomänen:
e-Mail Fluss Regeln:
Ich wüsste nicht, was ich noch prüfen könnte, um das Verhalten zu ändern.
BTW: ich habe die beiden Punkte "SPF-Eintrag schwerer Fehler" und "...ID-Filterung" in der Default AntiSpam Regel aktiviert - die eMails gehen leider immernoch durch und im Header steht nach wie vor "spf=fail" (sollte dort nicht auch schon differenziert aufgeführt werden, ob nun soft oder hardfail?)
...also würde einfach alles ignoriert werden was ich einstelle. (und es ist definitiv der richtige tenant in dem ich angemeldet bin, ich habe keinen anderen)
sonderbares Ding ...
wenn ich bei mir dein Script nehme, dann bekomme ich die Meldung
also genau das was man erwarten würde.
Ich habe bei mir im Connector die erlaubte IP so angegeben "[MeineExterneIP]/32"
Laut Beschreibung sollte das so nicht nötig sein, aber ein Versuch wäre es wert.
Ansonsten solltest du da wirklich mal ein Ticket bei MS eröffnen.
wenn ich bei mir dein Script nehme, dann bekomme ich die Meldung
Die Serverantwort war: 5.7.51 TenantInboundAttribution; There is a partner connector configured that matched the
message's recipient domain. The connector had either the RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set also genau das was man erwarten würde.
Ich habe bei mir im Connector die erlaubte IP so angegeben "[MeineExterneIP]/32"
Laut Beschreibung sollte das so nicht nötig sein, aber ein Versuch wäre es wert.
Ansonsten solltest du da wirklich mal ein Ticket bei MS eröffnen.
...also würde einfach alles ignoriert werden was ich einstelle.
Dinge die im EO eingestellt werden können sich schon mal ein paar Stunden genehmigen, bis sie tatsächlich "greifen". Ein bisschen Geduld muss man da also schon mitbringen
Warum heißt dein Connector "on_prem_to_O365" wenn du doch gar kein On Prem hast? Hast du in den Anti Spam Einstellungen bei "Bedingung ist:" deine Absender Domain angegeben? Sieht so aus als ob deine Anti Spam Regel einfach nicht verwendet wird.
Also bei "Angewender auf:" und dann deine Domain.
Also bei "Angewender auf:" und dann deine Domain.
Dinge die im EO eingestellt werden können sich schon mal ein paar Stunden genehmigen, bis sie tatsächlich "greifen". Ein bisschen Geduld muss man da also schon mitbringen
...das habe ich auch schon festgestellt.
die Spamfilter Änderung habe ich gestern vorgenommen und heute getestet, ohne dass sich etwas geändert hat.
Ich habe bei mir im Connector die erlaubte IP so angegeben "[MeineExterneIP]/32"
Danke für den Tipp mit der CIDR schreibweise, werde ich direkt ausprobieren.
Ist schon oft genug vorgekommen, dass Beispielvorschläge nicht korrekt waren...
r
Ansonsten solltest du da wirklich mal ein Ticket bei MS eröffnen.
Habe ich schon geöffnet, Auszug aus der original Support-Mail:
Ich würde die folgenden Maßnahmen vorschlagen, damit Sie Spoofing vermeiden:
In Exchange Admin Center > Schutz > Spamfilter > Default > Erweiterte Optionen, aktivieren SIe die Optionen “SPF-Eintrag: Schwerer Fehler:” und > “Bedingte Absender-ID-Filterung: Schwerer Fehler:”, sowie im Anhang angezeigt ist.
Sie könnten auch DMARC zum Überprüfen von E-Mails verwenden. Im nachstehenden Link schicke ich Ihnen die Anweisungen:
https://docs.microsoft.com/de-de/microsoft-365/security/office-365-secur ...
In Exchange Admin Center > Schutz > Spamfilter > Default > Erweiterte Optionen, aktivieren SIe die Optionen “SPF-Eintrag: Schwerer Fehler:” und > “Bedingte Absender-ID-Filterung: Schwerer Fehler:”, sowie im Anhang angezeigt ist.
Sie könnten auch DMARC zum Überprüfen von E-Mails verwenden. Im nachstehenden Link schicke ich Ihnen die Anweisungen:
https://docs.microsoft.com/de-de/microsoft-365/security/office-365-secur ...
..also erstens nichts neues, was trotzdem noch nicht klappt, und zweitens das Grundproblem nicht beachtet.
mal sehen ob noch was brauchbares zurück kommt.
@Ex0r2k16
ja, der Name ist ungünstig, es gibt kein on-prem exchange eben nur ein on-prem relay, was dem wohl nicht gerecht wird.
Die Default Antispam-Regel hat ja keine Bedingung, und die benutzerdefinierte "Strong" Regel ist so eingestellt: wird angewendet wenn...
Empfängerdomäne = unseredomain.com
ja, der Name ist ungünstig, es gibt kein on-prem exchange eben nur ein on-prem relay, was dem wohl nicht gerecht wird.
Die Default Antispam-Regel hat ja keine Bedingung, und die benutzerdefinierte "Strong" Regel ist so eingestellt: wird angewendet wenn...
Empfängerdomäne = unseredomain.com
also um vorrübergehend Schutz für die Postfächer zu schaffen, habe ich jetzt eine Nachrichtenfluss-Regel definiert:
Das funktioniert zumindest...
Dazu aber eine Frage, wo ist definiert was "außerhalb der Organisation" ist?
Wird hier praktischer Weise auch der SPF-Eintrag zu Hilfe genommen und gecheckt, ob die Quell-IP erlaubt ist?
(also ist das eine vereinfachte Regel, die man auch selber machen könnte, indem man in einer Regel den Header auf spf=fail" [usw,] manuell checkt)?
EDIT:
OK, habs selbst einfach ausprobiert, wird nicht am SPF-Eintrag geprüft sondern anhand der zugelassen IPs über die Connectors.
Das funktioniert zumindest...
Dazu aber eine Frage, wo ist definiert was "außerhalb der Organisation" ist?
Wird hier praktischer Weise auch der SPF-Eintrag zu Hilfe genommen und gecheckt, ob die Quell-IP erlaubt ist?
(also ist das eine vereinfachte Regel, die man auch selber machen könnte, indem man in einer Regel den Header auf spf=fail" [usw,] manuell checkt)?
EDIT:
OK, habs selbst einfach ausprobiert, wird nicht am SPF-Eintrag geprüft sondern anhand der zugelassen IPs über die Connectors.
