9
SMTP-Relay öffnen
Hallo,
wir haben aktuell folgende Situation:
Unsere Sophos UTM ist das SMTP-Relay für den internen Exchange-Server, zugleich zeigt der MX-Record auf die UTM und es existiert ein korespondierender SPF-Record für unsere Mail-Domain.
Es gibt nun die Anforderung, dass ein externes und nicht über VPN angebundendes System mit fester IP-Adresse Mails unter unserer Absenderdomain versendet. Dieses System macht aktuell kein direktes SMTP und benötigt daher ein Relay.
Wir haben nun folgende Möglichkeiten:
1. Wir können die feste IP-Adresse in der UTM für die Benutzung des SMTP-Relays eintragen.
2. Wir können den SPF-Record um die feste IP-Adresse des Systems ergänzen und ein SMTP-Proxy auf dem System installieren.
Der Vorteil der ersten Lösung ist, dass wir über die UTM die Kontrolle über die versendeteten Mails haben. Der Nachteil ist, dass im schlimmsten Fall bei Missbrauch unsere UTM auf Blacklisten landen könnte. Dies wäre bei der zweiten Lösung nicht der Fall, jedoch fehlt jegliche Kontrolle über die versendeten Mails.
Vielleicht gibt's auch noch einen anderen Weg, oder jemand mal eine ähnliche Problemstellung gehabt?
wir haben aktuell folgende Situation:
Unsere Sophos UTM ist das SMTP-Relay für den internen Exchange-Server, zugleich zeigt der MX-Record auf die UTM und es existiert ein korespondierender SPF-Record für unsere Mail-Domain.
Es gibt nun die Anforderung, dass ein externes und nicht über VPN angebundendes System mit fester IP-Adresse Mails unter unserer Absenderdomain versendet. Dieses System macht aktuell kein direktes SMTP und benötigt daher ein Relay.
Wir haben nun folgende Möglichkeiten:
1. Wir können die feste IP-Adresse in der UTM für die Benutzung des SMTP-Relays eintragen.
2. Wir können den SPF-Record um die feste IP-Adresse des Systems ergänzen und ein SMTP-Proxy auf dem System installieren.
Der Vorteil der ersten Lösung ist, dass wir über die UTM die Kontrolle über die versendeteten Mails haben. Der Nachteil ist, dass im schlimmsten Fall bei Missbrauch unsere UTM auf Blacklisten landen könnte. Dies wäre bei der zweiten Lösung nicht der Fall, jedoch fehlt jegliche Kontrolle über die versendeten Mails.
Vielleicht gibt's auch noch einen anderen Weg, oder jemand mal eine ähnliche Problemstellung gehabt?
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: 500661
Url: https://administrator.de/contentid/500661
Printed on: April 23, 2024 at 18:04 o'clock
9 Comments
Latest comment
Hi,
das hängt natürlich von der Sicherheit des externen Systems ab. Verschlüsseltes und authentifiziertes Relay sollte gehen...
Welchen Missbrauch würdest du erwarten?
das hängt natürlich von der Sicherheit des externen Systems ab. Verschlüsseltes und authentifiziertes Relay sollte gehen...
Welchen Missbrauch würdest du erwarten?
Hallo,
theoretisch einfach: du ergänzt den MX-Record um den zweiten SMTP .
Baust einen zweiten SMTP auf , der muß ja nicht empfangen können...
Fertig.
Man kann auch auf einem Relay einliefern (VPN?) und dann mit der Realy-IP Mails senden!
SPF (beim Empfänger) prüft in der Regel, ob sendende IP und sendender Name ( domain) zueinander passen
Wenn nicht, wird der Mailempfang eben abgelehnt
Und da wirst du wohl eher nicht SPF ergänzen können - oder ?
Fred
theoretisch einfach: du ergänzt den MX-Record um den zweiten SMTP .
Baust einen zweiten SMTP auf , der muß ja nicht empfangen können...
Fertig.
Man kann auch auf einem Relay einliefern (VPN?) und dann mit der Realy-IP Mails senden!
SPF (beim Empfänger) prüft in der Regel, ob sendende IP und sendender Name ( domain) zueinander passen
Wenn nicht, wird der Mailempfang eben abgelehnt
Und da wirst du wohl eher nicht SPF ergänzen können - oder ?
Fred
Ich würde zu Variante 1 tendieren - so habt ihr einmal konsolodiert die Verwaltung eurer Domain was SPF und DKIM angeht und ihr könntet notfalls auch den Versand von Mails von diesem System mit ein paar Handgriffen nötigenfalls abstellen.
Was die Gefahr des Missbrauchs angeht, musst du abschätzen - aber grundsätzlich hast du die Gefahr ja auch, wenn das System unter eigener IP sendet und bei starkem Missbrauch eure Domain blacklisted wird.
Wenn du Angst hast, dass eines Tages eventuell mal die Remote-Büchse aufgemacht und zur Spamschleuder wird, sorge dafür, dass es ein Limit gibt, wie viele Mails pro Stunde von diesem System versendet werden dürfen. Das verhindert Missbrauch dann zwar nicht, dämmt aber die Auswirkungen schnell ein.
Wozu dann der MX-Record?
Was die Gefahr des Missbrauchs angeht, musst du abschätzen - aber grundsätzlich hast du die Gefahr ja auch, wenn das System unter eigener IP sendet und bei starkem Missbrauch eure Domain blacklisted wird.
Wenn du Angst hast, dass eines Tages eventuell mal die Remote-Büchse aufgemacht und zur Spamschleuder wird, sorge dafür, dass es ein Limit gibt, wie viele Mails pro Stunde von diesem System versendet werden dürfen. Das verhindert Missbrauch dann zwar nicht, dämmt aber die Auswirkungen schnell ein.
Zitat von @fredmy:
theoretisch einfach: du ergänzt den MX-Record um den zweiten SMTP .
Baust einen zweiten SMTP auf , der muß ja nicht empfangen können...
Fertig.
theoretisch einfach: du ergänzt den MX-Record um den zweiten SMTP .
Baust einen zweiten SMTP auf , der muß ja nicht empfangen können...
Fertig.
Wozu dann der MX-Record?
ich glaube, er setzt MX Record mit SPF gleich.
Hallo,
sicher nicht !
der sendende Server (smtp-IP) muß auflösbar sein,
A record ist untauglich, smtp.domain.tld schon
Fred
sicher nicht !
der sendende Server (smtp-IP) muß auflösbar sein,
A record ist untauglich, smtp.domain.tld schon
Fred
öhm, ja, muss er, das ist aber kein mx record...
Lösung 1 würde ich bevorzugen. Und klar, die IP bzw. DNS Name des externen Servers in der Sophos hinzufügen.
Relay ausgehend kann ja auch von der Sophos gescannt werden... bringt zusätzliche Sicherheit.
Die Geschichte mit zweiter MX ist Käse.
Relay ausgehend kann ja auch von der Sophos gescannt werden... bringt zusätzliche Sicherheit.
Die Geschichte mit zweiter MX ist Käse.
Moin,
Gruß,
Dani
1. Wir können die feste IP-Adresse in der UTM für die Benutzung des SMTP-Relays eintragen.
Wie viele bzw. wie große E-Mails werden denn von dem 3rd Party System verschickt? Denn deine Bandbreite am Standort der Sophos wird dadurch 2x fach belastet. Einmal als Download und anschließend als Upload. Im Worst Case steht eurer Internet still... Baust einen zweiten SMTP auf , der muß ja nicht empfangen können...
Würde ich ebenfalls bevorzugen. Gerade, wenn es um Missbrauch, Fakemails, Blacklisting geht, kannst du schnell und einfach den (v)Server herunterfahren und gut ist. Somit bleibt eurer System außen vor.Gruß,
Dani
Hallo,
vielen Dank für die vielen Antworten, ich komme erst heute zum antworten.
Hier ist das Problem, das externe System wird von einer anderen Abteilung unseres Unternehmens installiert und administriert. Ich kann daher keinerlei Einschätzung über die Sicherheit des Systems treffen, die Kommunikation mit dem Relay ist simples SMTP ohne Verschlüsselung und Authentifizierung (bzw. erfolgt die Authentifizierung über unsere dedizierte IP-Adresse).
Diese Einschränkungen können wir auf der UTM nicht konfigurieren, wir können daher nur anhand der Logs nachträglich wie Du schon sagst die IP-Adresse wieder sperren.
Das wäre auch noch eine Möglichkeit.
Fazit:
Grundsätzlich lese ich hier die klare Meinung heraus, dass wir doch eher unser SMTP Relay verwenden sollten, um Kontrolle und Überblick zu behalten und notfalls eingreifen zu können. Der SPF bleibt dann wie er ist ("v=spf1 mx -all").
Wir müssen nun überlegen, ob wir einen zweiten SMTP verwenden oder nicht.
vielen Dank für die vielen Antworten, ich komme erst heute zum antworten.
Zitat von @BirdyB:
das hängt natürlich von der Sicherheit des externen Systems ab. Verschlüsseltes und authentifiziertes Relay sollte gehen...
Welchen Missbrauch würdest du erwarten?
das hängt natürlich von der Sicherheit des externen Systems ab. Verschlüsseltes und authentifiziertes Relay sollte gehen...
Welchen Missbrauch würdest du erwarten?
Hier ist das Problem, das externe System wird von einer anderen Abteilung unseres Unternehmens installiert und administriert. Ich kann daher keinerlei Einschätzung über die Sicherheit des Systems treffen, die Kommunikation mit dem Relay ist simples SMTP ohne Verschlüsselung und Authentifizierung (bzw. erfolgt die Authentifizierung über unsere dedizierte IP-Adresse).
Zitat von @LordGurke:
Wenn du Angst hast, dass eines Tages eventuell mal die Remote-Büchse aufgemacht und zur Spamschleuder wird, sorge dafür, dass es ein Limit gibt, wie viele Mails pro Stunde von diesem System versendet werden dürfen. Das verhindert Missbrauch dann zwar nicht, dämmt aber die Auswirkungen schnell ein.
Wenn du Angst hast, dass eines Tages eventuell mal die Remote-Büchse aufgemacht und zur Spamschleuder wird, sorge dafür, dass es ein Limit gibt, wie viele Mails pro Stunde von diesem System versendet werden dürfen. Das verhindert Missbrauch dann zwar nicht, dämmt aber die Auswirkungen schnell ein.
Diese Einschränkungen können wir auf der UTM nicht konfigurieren, wir können daher nur anhand der Logs nachträglich wie Du schon sagst die IP-Adresse wieder sperren.
Zitat von @Dani:
Baust einen zweiten SMTP auf , der muß ja nicht empfangen können...
Würde ich ebenfalls bevorzugen. Gerade, wenn es um Missbrauch, Fakemails, Blacklisting geht, kannst du schnell und einfach den (v)Server herunterfahren und gut ist. Somit bleibt eurer System außen vor.Das wäre auch noch eine Möglichkeit.
Fazit:
Grundsätzlich lese ich hier die klare Meinung heraus, dass wir doch eher unser SMTP Relay verwenden sollten, um Kontrolle und Überblick zu behalten und notfalls eingreifen zu können. Der SPF bleibt dann wie er ist ("v=spf1 mx -all").
Wir müssen nun überlegen, ob wir einen zweiten SMTP verwenden oder nicht.
