8
Externe Mail mit interner Domain wird zugestellt
Guten Morgen,
folgender Sachverhalt:
Wir setzten eine Sophos UTM in aktuellster Version als Mail Gateway ein, diese ist der MX für unsere Domain.
Als akzeptierte Domain ist firma.de eingetragen, als erlaubtes Mail-Relay der interne Exchange.
Für die Domain gibt es einen SPF-Record der ausschließlich die UTM erlaubt.
Nun passiert folgendes:
1. Wir erhalten von extern eine Mail mit Absender xyz@firma.de und Empfänger abc@firma.de
-> Mail wird abgelehnt, da der Absender nicht unter @firma.de senden darf
2. Wir erhalten von extern eine Mail mit Absender F=<SRS0=aG35vD=CZ=firma.de=name@anderedomain.de> und Empfänger abc@firma.de
-> Mail wird akzeptiert, erscheint jedoch durch das SRS beim Empfänger als Absender xyz@firma.de
Es scheint also so, als wenn die UTM keine Überprüfung der maskierten Adresse vornimmt.
Hat jemand Erfahrung damit? Wie lösen andere dieses Problem?
Auf diesem Wege lässt sich nicht verhindern, dass von extern Mails mit vermeintlich internem Absender an unsere Mitarbeiter gesendet werden.
Ad-hoc fällt mir nur ein die Mails von extern zu Kennzeichen, so wie das größere Unternehmen bereits häufig machen (z.B. Dell)
folgender Sachverhalt:
Wir setzten eine Sophos UTM in aktuellster Version als Mail Gateway ein, diese ist der MX für unsere Domain.
Als akzeptierte Domain ist firma.de eingetragen, als erlaubtes Mail-Relay der interne Exchange.
Für die Domain gibt es einen SPF-Record der ausschließlich die UTM erlaubt.
Nun passiert folgendes:
1. Wir erhalten von extern eine Mail mit Absender xyz@firma.de und Empfänger abc@firma.de
-> Mail wird abgelehnt, da der Absender nicht unter @firma.de senden darf
2. Wir erhalten von extern eine Mail mit Absender F=<SRS0=aG35vD=CZ=firma.de=name@anderedomain.de> und Empfänger abc@firma.de
-> Mail wird akzeptiert, erscheint jedoch durch das SRS beim Empfänger als Absender xyz@firma.de
Es scheint also so, als wenn die UTM keine Überprüfung der maskierten Adresse vornimmt.
Hat jemand Erfahrung damit? Wie lösen andere dieses Problem?
Auf diesem Wege lässt sich nicht verhindern, dass von extern Mails mit vermeintlich internem Absender an unsere Mitarbeiter gesendet werden.
Ad-hoc fällt mir nur ein die Mails von extern zu Kennzeichen, so wie das größere Unternehmen bereits häufig machen (z.B. Dell)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 605366
Url: https://administrator.de/contentid/605366
Printed on: April 20, 2024 at 00:04 o'clock
8 Comments
Latest comment
Zitat von @JoeDevlin:
Guten Morgen,
folgender Sachverhalt:
Wir setzten eine Sophos UTM in aktuellster Version als Mail Gateway ein, diese ist der MX für unsere Domain.
Als akzeptierte Domain ist firma.de eingetragen, als erlaubtes Mail-Relay der interne Exchange.
Für die Domain gibt es einen SPF-Record der ausschließlich die UTM erlaubt.
Nun passiert folgendes:
1. Wir erhalten von extern eine Mail mit Absender xyz@firma.de und Empfänger abc@firma.de
-> Mail wird abgelehnt, da der Absender nicht unter @firma.de senden darf
2. Wir erhalten von extern eine Mail mit Absender F=<SRS0=aG35vD=CZ=firma.de=name@anderedomain.de> und Empfänger abc@firma.de
-> Mail wird akzeptiert, erscheint jedoch durch das SRS beim Empfänger als Absender xyz@firma.de
Es scheint also so, als wenn die UTM keine Überprüfung der maskierten Adresse vornimmt.
Guten Morgen,
folgender Sachverhalt:
Wir setzten eine Sophos UTM in aktuellster Version als Mail Gateway ein, diese ist der MX für unsere Domain.
Als akzeptierte Domain ist firma.de eingetragen, als erlaubtes Mail-Relay der interne Exchange.
Für die Domain gibt es einen SPF-Record der ausschließlich die UTM erlaubt.
Nun passiert folgendes:
1. Wir erhalten von extern eine Mail mit Absender xyz@firma.de und Empfänger abc@firma.de
-> Mail wird abgelehnt, da der Absender nicht unter @firma.de senden darf
2. Wir erhalten von extern eine Mail mit Absender F=<SRS0=aG35vD=CZ=firma.de=name@anderedomain.de> und Empfänger abc@firma.de
-> Mail wird akzeptiert, erscheint jedoch durch das SRS beim Empfänger als Absender xyz@firma.de
Es scheint also so, als wenn die UTM keine Überprüfung der maskierten Adresse vornimmt.
Works as designed. Wie soll die UTM denn wissen, daß die Darstellung Euch was anderes vorgaukelt? Für die UTM sieht das wie ein normale Maiadresse von außen aus. Du kannst natürlich Address-Rewriting machen oder einen ordentlichen Client einsetzen, der eben Dir auch die Originaladresse anzeigt.
Hat jemand Erfahrung damit? Wie lösen andere dieses Problem?
Ordentlicher Mailclient oder Address rewriting.
Auf diesem Wege lässt sich nicht verhindern, dass von extern Mails mit vermeintlich internem Absender an unsere Mitarbeiter gesendet werden.
Genau.
Ad-hoc fällt mir nur ein die Mails von extern zu Kennzeichen, so wie das größere Unternehmen bereits häufig machen (z.B. Dell)
Das wäre auch eine Möglichkeit.
lks
Zitat von @Lochkartenstanzer:
Works as designed. Wie soll die UTM denn wissen, daß die Darstellung Euch was anderes vorgaukelt? Für die UTM sieht das wie ein normale Maiadresse von außen aus. Du kannst natürlich Address-Rewriting machen oder einen ordentlichen Client einsetzen, der eben Dir auch die Originaladresse anzeigt.
Works as designed. Wie soll die UTM denn wissen, daß die Darstellung Euch was anderes vorgaukelt? Für die UTM sieht das wie ein normale Maiadresse von außen aus. Du kannst natürlich Address-Rewriting machen oder einen ordentlichen Client einsetzen, der eben Dir auch die Originaladresse anzeigt.
Naja, die UTM sieht laut SMTP-Log folgendes:
F=<SRS0=aG35vD=CZ=firma.de=name@anderedomain.de>
Daraus macht die UTM selbst im eigenen Log im Webinterface xyz@firma.de. Die UTM hat also alle notwendigen Informationen um die Maskierung zu erkennen und eine entsprechende Prüfung vorzunehmen.
Hat jemand Erfahrung damit? Wie lösen andere dieses Problem?
Ordentlicher Mailclient oder Address rewriting.
Outlook scheint mir im Exchange-Umfeld immernoch der Platzhirsch zu sein, aber ich sehe hier auch nicht das Problem bei dem Client, da genau hierfür SRS ja eingesetzt wird.
Zitat von @JoeDevlin:
Naja, die UTM sieht laut SMTP-Log folgendes:
F=<SRS0=aG35vD=CZ=firma.de=name@anderedomain.de>
Daraus macht die UTM selbst im eigenen Log im Webinterface xyz@firma.de.
Naja, die UTM sieht laut SMTP-Log folgendes:
F=<SRS0=aG35vD=CZ=firma.de=name@anderedomain.de>
Daraus macht die UTM selbst im eigenen Log im Webinterface xyz@firma.de.
Du verwechselt Darstellung und Codierung. Das mag zwar im Webinterface wie xyz@firma.de aussehen, ist aber vermutlich immer noch als F=<SRS0=aG35vD=CZ=firma.de=name@anderedomain.de codiert. Daraus kann die UTM nicht schließen, daß es in der Darstellung wie xyz@firma.de aussieht. Schau mal in den HTML-Code, wie es da aussieht.
Das ist genauso wie manche Spammer Codes von anderen Alphabeten (z.B. kyrillisch oder griechisch) verwenden, deren Glyphen wie die im lateinischen Alphabet aussehen. In der Darstellung liest sich das so, als ob es z.B. von Amazon kommen würde, aber die Absender-Domain ist fake und sieht nur in der Darstellung so aus.
Man müßte daher erstmal ein Verzeichnis aller Kombinationen machen und die dann prüfen, was faktisch sehr aufwendig ist und daher kaum gemacht wird.
lks
PS: Аmаzon.de und Amazon.de sind zwei verschiedene Strings, auch wenn sie hier im Browser gleich aussehen:
$ echo "Аmаzon.de" | od -hc
0000000 90d0 d06d 7ab0 6e6f 642e 0a65
320 220 m 320 260 z o n . d e \n
$ echo "Amazon.de" | od -hc
0000000 6d41 7a61 6e6f 642e 0a65
A m a z o n . d e \n
Du kannst ja hinter dem Sophos (Exchange, was auch immer) eine Transportregel definieren, das die maskierte Adresse im Header überprüft.
Zitat von @NordicMike:
Du kannst ja hinter dem Sophos (Exchange, was auch immer) eine Transportregel definieren, das die maskierte Adresse im Header überprüft.
Du kannst ja hinter dem Sophos (Exchange, was auch immer) eine Transportregel definieren, das die maskierte Adresse im Header überprüft.
Das hilft aber nur gegen diesen einen String. Es gibt unzählige Variationen, wie man die interne Adresse vorgaukeln kann.
lks
Vielen Dank für eure Antworten, das hat mir geholfen das ganze Prinzip noch besser zu verstehen.
Ich werde wohl anregen, dass wir externe Mails kennzeichnen, ggf. alternativ je nach Möglichkeit den Filter für diese Konstellation anpassen.
Ich werde wohl anregen, dass wir externe Mails kennzeichnen, ggf. alternativ je nach Möglichkeit den Filter für diese Konstellation anpassen.
Hallo,
macht denn das UTM ausgehend SRS?
Eine SRS-Adresse darf eigentlich nur von dem wieder in eine "normale" Adresse umgewandelt werden, der sie erstellt hat. Die Adresse ist dazu... naja... "kryptografisch" abgesichert wäre übertrieben. Das "CZ" in deinem Beispiel sollte ein Timestamp sein, damit ist eine solche Adresse nur wenige Tage gültig (wie lange legt der fest, der sie erstellt). Das aG35vD in einem Beispiel sollte ein Hashwert sein, der aus der gesamten Adresse sowie einem Secret gebildet wird.
Wenn ein System, das SRS-Adressen generiert, eine Mail mit einer solchen Adresse empfängt, dann müsste es prüfen, ob diese gültig ist (Timestamp nicht abeglaufen und Hash gültig) und dann und nur dann die Adresse zurückübersetzen.
Du müsste also auch im Message Tracking auf der UTM eine ausgehende Nachricht _an_ SRS0=aG35vD=CZ=firma.de=name@anderedomain.de finden. Hast du danach schonmal gesucht?
Grüße
Filipp
macht denn das UTM ausgehend SRS?
Eine SRS-Adresse darf eigentlich nur von dem wieder in eine "normale" Adresse umgewandelt werden, der sie erstellt hat. Die Adresse ist dazu... naja... "kryptografisch" abgesichert wäre übertrieben. Das "CZ" in deinem Beispiel sollte ein Timestamp sein, damit ist eine solche Adresse nur wenige Tage gültig (wie lange legt der fest, der sie erstellt). Das aG35vD in einem Beispiel sollte ein Hashwert sein, der aus der gesamten Adresse sowie einem Secret gebildet wird.
Wenn ein System, das SRS-Adressen generiert, eine Mail mit einer solchen Adresse empfängt, dann müsste es prüfen, ob diese gültig ist (Timestamp nicht abeglaufen und Hash gültig) und dann und nur dann die Adresse zurückübersetzen.
Du müsste also auch im Message Tracking auf der UTM eine ausgehende Nachricht _an_ SRS0=aG35vD=CZ=firma.de=name@anderedomain.de finden. Hast du danach schonmal gesucht?
Grüße
Filipp
Nee, wir selbst machen kein SRS.
Eine SRS-Adresse darf eigentlich nur von dem wieder in eine "normale" Adresse umgewandelt werden, der sie erstellt hat. Die Adresse ist dazu... naja... "kryptografisch" abgesichert wäre übertrieben. Das "CZ" in deinem Beispiel sollte ein Timestamp sein, damit ist eine solche Adresse nur wenige Tage gültig (wie lange legt der fest, der sie erstellt). Das aG35vD in einem Beispiel sollte ein Hashwert sein, der aus der gesamten Adresse sowie einem Secret gebildet wird.
Wenn ein System, das SRS-Adressen generiert, eine Mail mit einer solchen Adresse empfängt, dann müsste es prüfen, ob diese gültig ist (Timestamp nicht abeglaufen und Hash gültig) und dann und nur dann die Adresse zurückübersetzen.
Du müsste also auch im Message Tracking auf der UTM eine ausgehende Nachricht _an_ SRS0=aG35vD=CZ=firma.de=name@anderedomain.de finden. Hast du danach schonmal gesucht?
Wenn ein System, das SRS-Adressen generiert, eine Mail mit einer solchen Adresse empfängt, dann müsste es prüfen, ob diese gültig ist (Timestamp nicht abeglaufen und Hash gültig) und dann und nur dann die Adresse zurückübersetzen.
Du müsste also auch im Message Tracking auf der UTM eine ausgehende Nachricht _an_ SRS0=aG35vD=CZ=firma.de=name@anderedomain.de finden. Hast du danach schonmal gesucht?
Das kann ich leider erst nächste Woche nachsehen, ist aber eine interessante Information.
Wenn ich es richtig verstehe, dann versucht hier nun jemand von einem externen MX anderedomain.de an unseren MX an firma.de eine Mail zuzustellen, soweit alles normal. Nun wird über SRS versucht, die Absenderadresse als eine interne zu maskieren. Da der eigentliche Absender anderedomain.de ist, greift der SPF für firma.de nicht.
Du sagst nun, dass diese SRS-Rückübersetzung eigentlich nur vorgenommen werden sollte, wenn es vorher eine entsprechende ausgehende Mail von unserer UTM gab?
