Exchange 2013 Empfangsconnector und Sendeconnector Sicherheitsüberprüfungen

[KevinRo 0]

Hallo Community,

 

wir verwenden einen externen Anbieter, der den Nachrichtenfluss auf SPAM und Schadsoftware überprüft.

Empfangs und Sendeconnector:
 

Email Empfang: 
Domain name --> MX-Record zu --> externen Anbieter (Prüft Email Empfangsmail) --> MX-Record zu --> Public IP --> SMTP Weiterleitung auf Internen Server --> Interner Server EMail Empfang

Dabei habe ich eingerichtet, dass nur SMTP Anfragen am Netzwerk vom externen Anbieter akzeptiert werden.
Bsp. vorgegebener Netzwerkbereich des externen Anbieters: 217.0.1.0/24, wird akzeptiert.  
 

Email Versand: 
SMTP Versand über Smarthost relay ohne Benutzerauth. --> externer Anbieter (Prüft Email Versandsnachricht) --> ... .

Die Authentifizierung am Smarthost Server läuft über die Public IP. 

Nun zu meinen Fragen. Die Variante über einen Smarthost Anbieter sollte doch in diesem Fall die sicherste sein oder? Dadurch wird doch sichergestellt, dass wir keine Emails direkt über unsere IP-Adresse versenden, sondern das die IP-Adresse nur dem Smarthost bekannt ist. Dennoch bekomme ich ab und zu SMTP Anfragen von fremden SMTP Server bsp. aus China, dass wird mir in meinem Firewall log angezeigt, weil dies als Deny Verstoß erkannt wird.

 
Dabei funktioniert der Versand und der Empfang einwandfrei. Selbst das Problem mit den Zertifikaten konnte ich lösen, dabei funktioniert OWA und Outlook Anywhere ohne Probleme, selbst Autodiscovery habe ich hinbekommen (Siehe.: http://www.mcseboard.de/topic/196412-san-zertifikate-exchange-server-2013/).

Nun möchte ich aber für ein paar Clients eine IMAP und SMTP Verbindung bereitstellen. IMAP ist für mich eigentlich klar, hierbei gebe ich den Port 993 an der Firewall frei und leite diesen an den CAS Server weiter (über die Aktivierung von IMAP am Exchange Server bin ich mir auch bewusst).

Aber wie sieht es nun mit einem SMTP Server aus? hierfür müsste ich theoretisch den Port 25 freischalten und diesen an den CAS Server weiterleiten. Dabei lasse ich aber dann alle SMTP Verbindungen zu, was ich ja generell erst mal nicht möchte, weil ich dann nicht mehr die gegebene Sicherheit vom spezifizierten Empfang über den Smarthost habe. 

Leider stehe ich dabei ziemlich auf den Schlauch. Vielleicht kann mir hierfür einer einen Denkansatz geben.

Vielen Dank im voraus!

 

[NorbertFe 2.016]

Stell dir vor, dafür gibt's den Default Client Connector, der läuft auf Port 587. Aber ja, ansonsten müßtest du Port 25 auf deinen CAS freigeben. Und da läßt du dann nur authentifizierten Zugriff zu. Wo ist jetzt dein Problem? Gibt ja ziemlich viele "Schläuche" bei dir im Serverraum. ;)

 

Bye

Norbert

[KevinRo 0]

 

 

Haha, dass ist wirklich kein Problem, So habe ich es hinbekommen. Nein so viele "Schläuche" gibt es nicht :D, aber ich habe noch nicht so viel Erfahrung mit exchange sammeln können.

Trotzdem vielen Dank, du hast natürlich recht, da hätte man auch von selbst drauf kommen können.

bearbeitet 23. Januar 2014 von KevinRo

[KevinRo 0]

Hallo,

 

theoretisch ist es klar. Ich habe den "Client Frontend" Empfangsconnector. Der Port 587 ist auch frei. Die Verbindung kann ich auch aufbauen, wenn ich keine Verschlüsselung verwende. Ich möchte aber TLS verwenden, SSL unterstützt Exchange für SMTP nicht. 

Ich habe für die Authentifizierung TLS aktiviert + Domänensicherheit. 
Als Berechtigungsgruppe werden Exchange Benutzer verwendet. 

 

Wenn ich nun mit Telnet auf den server über Port 587 zugreife habe ich auch kein "250 -Starttls" da stehen. 
Kann mir hierbei jemand weiterhelfen?

Ich benötige das für einige Clients, die noch Outlook 2003 verwenden.


 

Ok ich habe nun eine SSL-Verbindung zwischen Client (Outlook SMTP, Drucker usw.) hinbekommen. Die SSL Verbindung ist wischen dem Client und dem Loadbalancer! dahinter ist die Übertragung nicht mehr verschlüsselt. 

 

Das mit TLS funktioniert leider nicht so wie ich mir das vorgestellt habe. 

[NorbertFe 2.016]

 

Ok ich habe nun eine SSL-Verbindung zwischen Client (Outlook SMTP, Drucker usw.) hinbekommen. Die SSL Verbindung ist wischen dem Client und dem Loadbalancer! dahinter ist die Übertragung nicht mehr verschlüsselt. 

Aha, hätten wir jetzt hellsehen sollen, dass du SSL Offloading konfiguriert hast?

 

Das mit TLS funktioniert leider nicht so wie ich mir das vorgestellt habe. 

Und was genau hast du dir vorgestellt?

 

Bye

Norbert

[KevinRo 0]

Aha, hätten wir jetzt hellsehen sollen, dass du SSL Offloading konfiguriert hast?

 

Und was genau hast du dir vorgestellt?

 

Bye

Norbert

 

Ich habe mir vorgestellt, dass ich vom Client bis zum Server direkt eine Verbindung über TLS herstellen kann. Theoretisch ist dies auch möglich, bei mir habe ich es aber nicht hinbekommen. 

 

Es tut mir leid, dass ich SSL-Offloading nicht erwähnt habe. Nun, mit SSL-Offloading, kann ich aber den gewünschten Effekt erreichen. Mitarbeiter, welche sich von einem unsicheren WLAN hotspot Einloggen, verwenden eine sichere Verschlüsselung für SMTP und IMAP. 

 

Vielen Dank für deine Rückmeldung. ;)

[NorbertFe 2.016]

 

Ich habe mir vorgestellt, dass ich vom Client bis zum Server direkt eine Verbindung über TLS herstellen kann. Theoretisch ist dies auch möglich, bei mir habe ich es aber nicht hinbekommen. 

Stellt sich nur die Frage, warum du das nicht hinbekommen hast. Zumindest zwischen Client und Loadbalancer sollte das ja dann funktionieren, wenn du Offloading konfiguriert haben solltest.

Es tut mir leid, dass ich SSL-Offloading nicht erwähnt habe. Nun, mit SSL-Offloading, kann ich aber den gewünschten Effekt erreichen. Mitarbeiter, welche sich von einem unsicheren WLAN hotspot Einloggen, verwenden eine sichere Verschlüsselung für SMTP und IMAP. 

 

Vielen Dank für deine Rückmeldung. ;)

Also geht's jetzt?

 

Bye

Norbert