NoSpamProxy und Mimecast

[Kbaer]

Guten Tag,

wir haben NoSpamProxy Encryption als Standalone Modul im Einsatz und wollen das bei einem Kunden an Mimecast anbinden.
Wir verwenden dafür die Anleitung für Mimecast mit 3rd Party Anbietern:

https://mimecastsupport.zendesk.com/hc/en-us/articles/34000706466451-Policies-Configuring-3rd-Party-Encryption-Solutions#h_01JAWAYM360HVGHXNXG4SFM5X7

Jetzt wollen die aber in der Content Examination Bypass und für Authorized Outbounds eine IP-Adresse vom "..3rd party encryption gateway" haben damit Mimecast erkennt das die E-Mails von einem vertrauenswürdigen Absender kommen.

Was kann ich da eintragen?

Danke und viele Grüße

 

[JanJäschke]

Guten Morgen,

die derzeitigen IPs von welchen Encryption Only Kunden in der Cloud E-Mails zustellen sind folgende.
- 18.157.109.249
- 18.159.191.172
Ich möchte darauf hinweisen, dass wir uns vorbehalten diese zu ändern sofern es notwendig ist. (Geblockt, verbrannt, o.ä.)


LG
Jan

 

[869288141]

Hallo @JanJäschke,
die IP- Subnetze in der Doku zusammen zu tragen ist keine Option?
Das Thema hatten wir letztes Jahr schon mal.


Gruß,
Daniel

 

[JanJäschke]

Nein da es nicht unser Subnetz ist und wir auch nicht sicherstellen können eine IP aus exakt dem gleichen Subnatz zu nutzen.

Es gibt interne Planung die Subnetze nochmal auf ein von uns kontrolliertes umzuziehen, diese sind aber nicht final.
(Dann könnten unsere Subnetze genutzt werden)

Wir möchten aber möglichst vermieden, dass Kunden auf die IPs Subnetze gehen.
Das ist einfach ein fürchterliches vorgehen im SaaS Bereich da es 0 Sicherheit mit sich bringt wenn alle Kunden eines Diensts über die gleichen IPs laufen

 

[869288141]

Das ist einfach ein fürchterliches vorgehen im SaaS Bereich da es 0 Sicherheit mit sich bringt wenn alle Kunden eines Diensts über die gleichen IPs laufen

Mein Verständnis hält in Grenzen. Die Problematik ist nicht neu. Das war schon vor 20 Jahren ein Problem. Damals hieß es aber nicht SaaS sondern einfach Shared (Web) Hosting. Im Worst Case trifft es neben nicht nur einen Kunden, sondern dann eben alle. SaaS ist eben nicht nur geil...

Früher hat man sich 2x überlegt, ob und welche Kunden man hostet und welche nicht. Wer es selbst gehostet hat, hat penibel darauf gedacht, dass seine Systeme sicher sind. Weil sind IP-Adressen an einer Datenleitung verbrannt und wollte diese tauschen, musste man zum Rapport bei seinem ISP, welcher die Datenleitung und damit IP-Adressen bereitstellt. Wer den Luxus hat und ein eigenes BGP AS mit IP Subnetzen hat, hat 4x überlegt was er wie bereitstellt. Heute werden IP-Adressen verbrannt wie Wunderkerzen auf einem Kindergeburtstag...

Abgesehen davon bieten die Großen am Markt (z.B. Google SOAR, Zscaler, CrowdStrike etc.) inzwischen bei den jeweiligen SaaS Lösungen für Ihre Kunden optional dedizierte IP-Adressen an. Und das nicht weil es die Idee von Produktmanagement war, sondern weil die Kunden darauf bestehen.

Es gibt interne Planung die Subnetze nochmal auf ein von uns kontrolliertes umzuziehen, diese sind aber nicht final.

Freut mich zu hören. Wir sind gespannt. Halte uns gerne auf dem Laufenden.

 

[JanJäschke]

Dedizierte IPs bieten wir auch an, das nennt sich dann Enterprise Stack

Wir haben uns auch aktiv dazu entschieden keine IPs aus unserem Subnetz zu nutzen um den Schutz aller anderen Kunden zu erhöhen, denn es reicht nun leider ein Kunde aus der dein Routing bei Encryption Only nicht im Griff hat, malware umher leitet und damit die IP oder im schlimmsten Fall das Subnetz belastet.

Die schönste Lösung wäre TLS Client Authentifizierung, aber das unterstützen die wenigsten weil es Arbeit bedeutet.
Der nächst schönste Weg ist ein sauberer Secret im Header, diesen Weg gehen wir bei O365. Aber auch hier muss der Admin dann schauen, dass es nicht zum leak kommt.

Da wir aktiv vermeiden wollen das jeder überall einfach nur blind unsere Subnetz Tiefensee einträgt ohne drüber nachzudenken, stehen sie nicht in der Doku.
Jeder der weiß wie E-Mail routing funktioniert kann sich die IP Adressen raus suchen und damit auch auf das ganze Subnetz von uns Rückschlüsse ziehen.

Und bei jedem der Fragt können wir explizit davor warnen damit der Admin sich der möglichen Probleme bewusst ist.

 

[869288141]

Hallo Jan,

Dedizierte IPs bieten wir auch an, das nennt sich dann Enterprise Stack

Gut, dass du nicht im Vertrieb arbeitest. Michael hätte es vermutlich nicht einfach mit dir. Grüße gehen an der Stelle raus.
Hättest du das gleich gesagt, hätte ich mir den Kommentar sparen können.

Die schönste Lösung wäre TLS Client Authentifizierung, aber das unterstützen die wenigsten weil es Arbeit bedeutet.

Ich kann dir sagen, es ist im Enterprise Umfeld auf dem Vormarsch. Es ist endlich bei vielen angekommen, dass ein Secret/Passwort nicht das Mittel der Wahl sein darf. Wobei es im SMTP Bereich evtl. einfacher ist wie im Web, wo http3/QUIC die neue Herausforderung für Client Auth ist.

Der nächst schönste Weg ist ein sauberer Secret im Header, diesen Weg gehen wir bei O365. Aber auch hier muss der Admin dann schauen, dass es nicht zum leak kommt.

Interessant. Wo ist da aus eurer Sicht der Sicherheitsgewinn gegeben über einem handelsüblichen Secret?

Jeder der weiß wie E-Mail routing funktioniert kann sich die IP Adressen raus suchen und damit auch auf das ganze Subnetz von uns Rückschlüsse ziehen.

Das wollen wir an der Stelle nicht vertiefen. Ansonsten fällt eure Security by Obscurity in den nächsten Stunden.

Und bei jedem der Fragt können wir explizit davor warnen damit der Admin sich der möglichen Probleme bewusst ist.

Ich plädiere trotzdem für eine Seite in der Doku. In der du gerne nochmals die Gründe dafür nennen darfst warum ihr diese Informationen nicht dokumentiert. Damit kann man auch in Zukunft schön drauf verweisen und muss nicht jedes Mal den Thread suchen.


Gruß,
Daniel