Gelöst NSP Cloud Gateway auf Blocklist

[BWC-DE]

Hi,

getreu dem Motto "mitgehangen - mitgefangen" kann ein Kunde von mir keine Mails mehr über NSP Cloud versenden weil die IP 193.37.132.21 (de-s04-gw1.mail.cloud.nospamproxy.com) auf der Blacklist ivmSIP gelandet ist und lt. Cisco Talos die Reputation auch auf "poor" steht.

Auf der NSP Status Seite ist kein Problem vermerkt.

Wird hier kurzfristig auf das andere Gateway geschwenkt? Interessanterweise steht bei den Sendekonnektoren im Portal "TCP Proxy ungültig", was auch immer das bedeutet. Wann wird die lt. SPF zweite Adresse (178.212.92.66) verwendet, nur wenn das erste Gateway nicht funktioniert?

Wie ist hier die Erfahrung, warten oder das outbound routing in MS365 besser umstellen? Ticket ist schon eröffnet, aber sowas passiert natürlich am Sonntag

--Michael

 

[Fabian]

Hallo Michael,

meinst du nun das Cloud Produkt "Nospamproxy Cloud" oder den TCP-Proxyservice für NSP-Server Kunden welche den NSP auf einer Azure-VM betreiben und Port 25 nicht direkt nutzen können und daher den TCP-Proxyservice von NSP nutzen?

LG
Fabian

 

[Sören]

Wann wird die lt. SPF zweite Adresse (178.212.92.66) verwendet, nur wenn das erste Gateway nicht funktioniert?

du hast ja im EXO nen A Record eingetragen, dass ist ein DNS Round Robin, sprich das EXO entscheidet welchen der beiden Hosts es anspricht...

die IP 193.37.132.21 (de-s04-gw1.mail.cloud.nospamproxy.com) auf der Blacklist ivmSIP gelandet ist und lt. Cisco Talos die Reputation auch auf "poor" steht

ich habe es an unser DevOps gemeldet damit die Kollegen sich das anschauen

 

[BWC-DE]

meinst du nun das Cloud Produkt "Nospamproxy Cloud" oder den TCP-Proxyservice für NSP-Server Kunden welche den NSP auf einer Azure-VM betreiben und Port 25 nicht direkt nutzen können und daher den TCP-Proxyservice von NSP nutzen?

Ja, NSP Cloud (Protection) ... die Meldung "TCP Proxy ungültig" steht bei Konfigurtion -> E-Mail-Routing -> Ausgehende E-Mail-Zustellung. Keine Ahnung ob das schon immer da stand, ist mir nur aufgefallen wegen dem roten Symbol. Hat aber hiermit vermutlich gar nichts zu tun.

193.37.132.21 ist lt. Cisco Talos wieder "neutral" und die IP ist wohl auch wieder von der Blacklist genommen, somit sollte wieder alles passen.

--Michael

 

[BWC-DE]

du hast ja im EXO nen A Record eingetragen, dass ist ein DNS Round Robin, sprich das EXO entscheidet welchen der beiden Hosts es anspricht...

Ahh, da war wars ... dann hätte ja mit viel Glück jede zweite Mail an den Empfänger durchgehen können ... egal, scheint ja behoben.

ich habe es an unser DevOps gemeldet damit die Kollegen sich das anschauen

Das scheint schon geklappt zu haben oder die IP wurde automatisch delisted.

--Michael

 

[StefanCink]

Ja, ein Gateway unseres Shared Stacks stand für eine kurze Zeit auf der oben genannten Blacklist. Das Problem ist schnell behoben worden und das Delisting ging schnell.
Gruß Stefan

 

[BWC-DE]

Servus Stefan,

Ja, ein Gateway unseres Shared Stacks stand für eine kurze Zeit auf der oben genannten Blacklist. Das Problem ist schnell behoben worden und das Delisting ging schnell.

Wie ist hier die generelle Vorgehensweise, immer ein Ticket öffnen oder monitored ihr das eh und die Dinge gehen ihren automatischen Lauf?

--Michael

 

[StefanCink]

Auf letzteres könnt ihr euch auf jeden Fall verlassen. Ich frage aber nochmal im Professional Services Team nach, wie deren Sicht auf das Ticket-Thema ist.
Gruß Stefan

 

[869288141]

Hallo Stefan,

Auf letzteres könnt ihr euch auf jeden Fall verlassen.

In allen genannten Fällen würde ich erwarten, dass auf der Status-Page ein entsprechender, idealerweise automatisierter, Eintrag erscheint. Nur so entsteht für Kunden ein möglichst hohes Maß an Transparenz und Nachvollziehbarkeit.

Andernfalls dürfte die Anzahl der Support-Tickets vermutlich eher steigen als sinken. Ich würde euch zumindest bei jedem nicht dokumentierten Blacklisting ein Ticket einstellen.


Gruß,
Daniel

 

[StefanCink]

Moin Daniel,
ich diskutiere das gerne mit dem Team. Ich gebe allerdings zu bedenken, dass es in aller Regel nur eine IP-Adresse und damit nur einen Teil eines Stacks betrifft. Es ist also immer nur die Schnittmenge einer Schnittmenge. Unsere Kunden wissen jedoch nicht, auf welchem Stack ihr Tenant liegt und können es deswegen nicht bewerten, ob sie betroffen sind, oder nicht.
Gruß Stefan

 

[869288141]

Hallo Stefan,
Ich sehe hier grundsätzlich beide Seiten in der Verantwortung, sowohl den Kunden als auch den Dienstleister.

Nur weil ich einen Service aus der Cloud buche bzw. nutze, entbindet mich das nicht vom notwendigen technischen Verständnis. Genau das ist aus meiner Sicht ein Irrtum, der inzwischen langsam aber sicher überall ankommt. Auch ein Cloud-Service muss gepflegt, überwacht und verstanden werden. Die Verantwortung verschwindet nicht einfach dadurch, dass die Infrastruktur nicht mehr im eigenen Rechenzentrum steht.

Unsere Kunden wissen jedoch nicht, auf welchem Stack ihr Tenant liegt und können es deswegen nicht bewerten, ob sie betroffen sind, oder nicht.

Ich habe ja nicht gesagt, dass es einfach ist Man könnte beispielsweise die betroffenen Domains referenzieren. Das Argument, dass dadurch euer Kundenstamm sichtbar würde, lasse ich persönlich allerdings nur bedingt gelten. Der lässt sich bereits heute, wenn auch teilweise über ein paar Umwege, durchaus nachvollziehen.

Gerne ein Beispiel aus der Praxis bei meinem Arbeitgeber:

• Wir erzeugen pro Service eine eindeutige Kennung, die im Kundenportal, neben der Kundennummer, deutlich im Header angezeigt wird. Nennen wir sie einfach „Service-ID“.
• Auf diese Service-ID referenzieren wir anschließend Wartungsarbeiten, Störungen oder sonstige betriebliche Ereignisse.
• Dieses Konstrukt mussten wir etablieren, um den unterschiedlichen regulatorischen und organisatorischen Anforderungen der Länder dieser Welt gerecht zu werden.

Gruß,
Daniel

 

[Fabian]

Nur weil ich einen Service aus der Cloud buche bzw. nutze, entbindet mich das nicht vom notwendigen technischen Verständnis. Genau das ist aus meiner Sicht ein Irrtum, der inzwischen langsam aber sicher überall ankommt. Auch ein Cloud-Service muss gepflegt, überwacht und verstanden werden. Die Verantwortung verschwindet nicht einfach dadurch, dass die Infrastruktur nicht mehr im eigenen Rechenzentrum steht.

Yep, spätestens mit der DORA-Verordnung im Finanzwesen muss man sich damit beschäftigen!
Ich begrüße deine Aussage sehr, denn die Karte "Das ist SaaS, damit haben wir nichts zu tun" wird sehr gerne gespielt.

• Wir erzeugen pro Service eine eindeutige Kennung, die im Kundenportal, neben der Kundennummer, deutlich im Header angezeigt wird. Nennen wir sie einfach „Service-ID“.
• Auf diese Service-ID referenzieren wir anschließend Wartungsarbeiten, Störungen oder sonstige betriebliche Ereignisse.
• Dieses Konstrukt mussten wir etablieren, um den unterschiedlichen regulatorischen und organisatorischen Anforderungen der Länder dieser Welt gerecht zu werden.

Ich würde nicht einmal so kompliziert denken! Den Kunden müsste man nur mitteilen in welchem Stack sie sind und dann transparent melden "Der Stack XYZ ist betroffen".

Dann weiß man sofort, ob man betroffen ist oder nicht.

LG
Fabian