20
Exchange direkt in das Internet?
Hi zusammen,
darf euer Exchange direkt in das Internet?
Unser Exchange ist hinter einem Webfilter, der die Server nur auf bestimmte Seiten raus lässt. Allerdings ändert Microsoft ständig seine URLs und auch einige andere Zugriffe die der Exchange nach Hause macht, erscheinen im Eventlog weil ich diese noch nicht in der Firewall freigegeben habe. (z.B. https://o15.officeredir.microsoft.com --> MSEchangeApplicationLogic 3018 Fehler täglich mehrmals.)
Wenn der Exchange nicht direkt ins Internet darf hat halt den Vorteil, dass kein Schadcode nachgeladen werden kann.
Wie macht ihr das?
Danke ;)
darf euer Exchange direkt in das Internet?
Unser Exchange ist hinter einem Webfilter, der die Server nur auf bestimmte Seiten raus lässt. Allerdings ändert Microsoft ständig seine URLs und auch einige andere Zugriffe die der Exchange nach Hause macht, erscheinen im Eventlog weil ich diese noch nicht in der Firewall freigegeben habe. (z.B. https://o15.officeredir.microsoft.com --> MSEchangeApplicationLogic 3018 Fehler täglich mehrmals.)
Wenn der Exchange nicht direkt ins Internet darf hat halt den Vorteil, dass kein Schadcode nachgeladen werden kann.
Wie macht ihr das?
Danke ;)
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1074647317
Url: https://administrator.de/forum/exchange-direkt-in-das-internet-1074647317.html
Ausgedruckt am: 26.12.2024 um 13:12 Uhr
20 Kommentare
Neuester Kommentar
darf euer Exchange direkt in das Internet?
NeinWie macht ihr das?
Sämtlicher Traffic läuft durch eine Proxy-Kaskade, egal ob SMTP, MAPI oder HTTP(S), Updates kommen vom WSUS.
Hallo,
Exchange ist hinter einer WAF (Web Application Firewall)
Gruss
Exchange ist hinter einer WAF (Web Application Firewall)
Gruss
Moin
Nein. Alleine bei der Frage bekomme ich Gänsehaut. Das einzige was direkt ins Internet darf ist das Modem, dann kommt die Firewall. Kein Gerät darf direkt ins Internet.
Gruß
Doskias
Nein. Alleine bei der Frage bekomme ich Gänsehaut. Das einzige was direkt ins Internet darf ist das Modem, dann kommt die Firewall. Kein Gerät darf direkt ins Internet.
Unser Exchange ist hinter einem Webfilter, der die Server nur auf bestimmte Seiten raus lässt.
Richtig so.Allerdings ändert Microsoft ständig seine URLs und auch einige andere Zugriffe die der Exchange nach Hause macht, erscheinen im Eventlog weil ich diese noch nicht in der Firewall freigegeben habe. (z.B. https://o15.officeredir.microsoft.com --> MSEchangeApplicationLogic 3018 Fehler täglich mehrmals.)
Also erstens ändert Microsoft ja nicht mehrmals am Tag die Adressen und zweitens kannst du ja auch *.microsoft.com in der Firewall für exakt diesen einen Server freigeben.Wenn der Exchange nicht direkt ins Internet darf hat halt den Vorteil, dass kein Schadcode nachgeladen werden kann.
Was hat das damit zu tun? Der Schadcode wird im Regelfall nicht vom Exchange nachgeladen sondern vom Client-PC im (vermutlich bei dir) Outlook des Anwenders.Gruß
Doskias
Also beim Exchange Exploit hat der Exchange Schadcode nachgeladen...
Nun beim Hafnium Exploit war das Exploit im Webpanel vom Exchange Server, wenn man wie oben beschrieben den Exchange durch ein Web Application Firewall abgesichert hatte. War man nicht betroffen, da das entsprechende Panel nicht erreichbar war von außen.
Zitat von @Scirca:
Nun beim Hafnium Exploit war das Exploit im Webpanel vom Exchange Server, wenn man wie oben beschrieben den Exchange durch ein Web Application Firewall abgesichert hatte. War man nicht betroffen, da das entsprechende Panel nicht erreichbar war von außen.
Nun beim Hafnium Exploit war das Exploit im Webpanel vom Exchange Server, wenn man wie oben beschrieben den Exchange durch ein Web Application Firewall abgesichert hatte. War man nicht betroffen, da das entsprechende Panel nicht erreichbar war von außen.
Dazu braucht man aber einen Reverse Proxy?
Welche Dienste benötige ich eigentlich für die Handys?
Mir bekannt: /owa|/autodiscover|/ecp|/ews|/oab|/Microsoft-Server-ActiveSync|/exchange
owa, autodiscover und Microsoft-Server-ActiveSync sollte doch für eine APP wie GMail reichen?
Wie schon von allen geschrieben würde ich den Exchange nie direkt an das Internet hängen.
Emails gehen vom Exchange per Smarthost an die UTM, diese versendet dann per postfix/smtp weiter.
OWA wurde seit Hafnium komplett ins VPN verfrachtet.
Gruß
Emails gehen vom Exchange per Smarthost an die UTM, diese versendet dann per postfix/smtp weiter.
OWA wurde seit Hafnium komplett ins VPN verfrachtet.
Gruß
Zitat von @preysa:
Wie schon von allen geschrieben würde ich den Exchange nie direkt an das Internet hängen.
Emails gehen vom Exchange per Smarthost an die UTM, diese versendet dann per postfix/smtp weiter.
OWA wurde seit Hafnium komplett ins VPN verfrachtet.
Gruß
Wie schon von allen geschrieben würde ich den Exchange nie direkt an das Internet hängen.
Emails gehen vom Exchange per Smarthost an die UTM, diese versendet dann per postfix/smtp weiter.
OWA wurde seit Hafnium komplett ins VPN verfrachtet.
Gruß
So ist es bei uns auch...
Allerdings will die GF wieder die E-Mails auf Handy ohne VPN... Hier gibt es in unserer UTM einen Reverse Proxy.
Es gäbe noch diese Alternative(englisch):
https://www.alitajran.com/disable-external-access-to-ecp-exchange-2016/
So hatten wir es bei uns gemacht und wir waren, vielleicht nur aus Glück, nicht von Hafnium damals betroffen.
Ansonsten bleibt wohl nur ein Reverse Proxy. Ich hatte aber auch von Leute gelesen, die trotz Reverse Proxy von Hafnium betroffen waren. Wie der RP konfiguriert war weiß ich nicht, aber anscheinend ist ein RP nicht unbedingt die Lösung gegen alle Angriffe.
Ist halt immer die Frage: Sicherheit oder Komfort?
Gruß
https://www.alitajran.com/disable-external-access-to-ecp-exchange-2016/
So hatten wir es bei uns gemacht und wir waren, vielleicht nur aus Glück, nicht von Hafnium damals betroffen.
Ansonsten bleibt wohl nur ein Reverse Proxy. Ich hatte aber auch von Leute gelesen, die trotz Reverse Proxy von Hafnium betroffen waren. Wie der RP konfiguriert war weiß ich nicht, aber anscheinend ist ein RP nicht unbedingt die Lösung gegen alle Angriffe.
Ist halt immer die Frage: Sicherheit oder Komfort?
Gruß
Zitat von @preysa:
Es gäbe noch diese Alternative(englisch):
https://www.alitajran.com/disable-external-access-to-ecp-exchange-2016/
So hatten wir es bei uns gemacht und wir waren, vielleicht nur aus Glück, nicht von Hafnium damals betroffen.
Ansonsten bleibt wohl nur ein Reverse Proxy. Ich hatte aber auch von Leute gelesen, die trotz Reverse Proxy von Hafnium betroffen waren. Wie der RP konfiguriert war weiß ich nicht, aber anscheinend ist ein RP nicht unbedingt die Lösung gegen alle Angriffe.
Ist halt immer die Frage: Sicherheit oder Komfort?
Gruß
Es gäbe noch diese Alternative(englisch):
https://www.alitajran.com/disable-external-access-to-ecp-exchange-2016/
So hatten wir es bei uns gemacht und wir waren, vielleicht nur aus Glück, nicht von Hafnium damals betroffen.
Ansonsten bleibt wohl nur ein Reverse Proxy. Ich hatte aber auch von Leute gelesen, die trotz Reverse Proxy von Hafnium betroffen waren. Wie der RP konfiguriert war weiß ich nicht, aber anscheinend ist ein RP nicht unbedingt die Lösung gegen alle Angriffe.
Ist halt immer die Frage: Sicherheit oder Komfort?
Gruß
Wie oft in der IT steckt der Teufel im Details, also was ist konfiguriert und was kann deine UTM bzgw. deine WAF. wenn man sie halt nur anschaltet und trozdem alles nach drausen weiterleitet wird sie wenig Schutz bringen.
Darum gibt es halt Fälle wo es trozdem durchging und Fälle wo es halt nicht durchging.
Zitat von @leon123:
Allerdings will die GF wieder die E-Mails auf Handy ohne VPN... Hier gibt es in unserer UTM einen Reverse Proxy.
Dafür gibt's doch MDM/MAM inkl. Mikro-VPN.
Moin Leon,
meinst du so ganz alleine ohne Leine? 🙃
Nein auf gar keinen Fall, nur durch einen Proxy, sprich mit Leine.
Und aus dem bösen Internet darf auch keiner direkt drauf, der Weg ist über ne WAF, SMTP Proxy & Co abgesichert.
Beste Grüsse aus BaWü
Alex
darf euer Exchange direkt in das Internet?
meinst du so ganz alleine ohne Leine? 🙃
Nein auf gar keinen Fall, nur durch einen Proxy, sprich mit Leine.
Und aus dem bösen Internet darf auch keiner direkt drauf, der Weg ist über ne WAF, SMTP Proxy & Co abgesichert.
Beste Grüsse aus BaWü
Alex
Danke für die Antworten...
Der Grund für diese Frage ist eigentlich, weil seitdem ich den Systemproxy gesetzt hab, ich ziemlich Probleme habe. Erst ging die Exchange Management Shell nicht. Ich hab jetzt bei den Ausnahmen *.firma.local und *.firma.de hinzugefügt, jetzt scheint zumindest die Management Shell wieder zu laden.
Ich habe Allerdings immer folgende Einträge im Eventlog:
In der UTM ist eigentlich *.microsoft.com freigegeben. Update kommen ja auch über den Proxy.
Mit Set-ExchangeServer ServerName -InternetWebProxy http://192.168.188.1:8080 habe ich den Proxy auch im Exchange gesetzt. Dennoch erhalte ich immer noch die Fehlermeldungen.
Die neuste Warnung ist seitdem ich den Proxy gesetzt habe: Warnung 22.07.2021 21:19:36 ASP.NET 4.0.30319.0 1309 Web Event
Hier wird versucht auf Request URL: https://mx01.firma.local:444/rpc/rpcproxy.dll?localhost:6001 zuzugreifen...
Im Exchange 2013 kann ich keine Bypass Liste setzen. Den Befehl gibt es erst ab 2016... Ich vermute diese Warnung kommt wegen dem Proxy im Exchange Server. Im Systemproxy ist mx01.firma.local als Ausnahme hinzugefügt (zusätzlich ist auch *.firmal.ocal als Ausnahme hinzugefügt... sicher ist sicher haha)
Der Grund für diese Frage ist eigentlich, weil seitdem ich den Systemproxy gesetzt hab, ich ziemlich Probleme habe. Erst ging die Exchange Management Shell nicht. Ich hab jetzt bei den Ausnahmen *.firma.local und *.firma.de hinzugefügt, jetzt scheint zumindest die Management Shell wieder zu laden.
Ich habe Allerdings immer folgende Einträge im Eventlog:
Fehler bei der Anforderung. Postfach: URL: https://o15.officeredir.microsoft.com/r/(...) Ausnahme: System.Net.WebException: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. ---> System.Net.Sockets.SocketException: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat 5------6:443In der UTM ist eigentlich *.microsoft.com freigegeben. Update kommen ja auch über den Proxy.
Mit Set-ExchangeServer ServerName -InternetWebProxy http://192.168.188.1:8080 habe ich den Proxy auch im Exchange gesetzt. Dennoch erhalte ich immer noch die Fehlermeldungen.
Die neuste Warnung ist seitdem ich den Proxy gesetzt habe: Warnung 22.07.2021 21:19:36 ASP.NET 4.0.30319.0 1309 Web Event
Hier wird versucht auf Request URL: https://mx01.firma.local:444/rpc/rpcproxy.dll?localhost:6001 zuzugreifen...
Im Exchange 2013 kann ich keine Bypass Liste setzen. Den Befehl gibt es erst ab 2016... Ich vermute diese Warnung kommt wegen dem Proxy im Exchange Server. Im Systemproxy ist mx01.firma.local als Ausnahme hinzugefügt (zusätzlich ist auch *.firmal.ocal als Ausnahme hinzugefügt... sicher ist sicher haha)
Zitat von @leon123:
Danke für die Antworten...
Der Grund für diese Frage ist eigentlich, weil seitdem ich den Systemproxy gesetzt hab, ich ziemlich Probleme habe.
Danke für die Antworten...
Der Grund für diese Frage ist eigentlich, weil seitdem ich den Systemproxy gesetzt hab, ich ziemlich Probleme habe.
Das kommt weil einige Dienste eines Exchange noch über WinHTTP kommunizieren welcher separate Proxy Einstellungen hat und nicht per Default die WinInet Settings aus dem IE übernehmen.
https://www.msxfaq.de/netzwerk/grundlagen/windows_http_proxy.htm#proxyei ...
Danke für deine Antwort... aber den Systemproxy habe ich schon gesetzt.
Trotz Systemproxy erhalte ich immer noch die Fehler mit dem Zugriff auf https://o15.officeredir.microsoft.com/r/(...), das komische ist ich sehe den Zugriff nicht im Log der Firewall... D.h. der Exchange kommt warum auch immer nicht mal dort hin.
Hat jemand eine Idee was hier falsch läuft?
Hat jemand eine Idee was hier falsch läuft?
Zitat von @leon123:
Trotz Systemproxy erhalte ich immer noch die Fehler mit dem Zugriff auf https://o15.officeredir.microsoft.com/r/(...), das komische ist ich sehe den Zugriff nicht im Log der Firewall... D.h. der Exchange kommt warum auch immer nicht mal dort hin.
Hat jemand eine Idee was hier falsch läuft?
Trotz Systemproxy erhalte ich immer noch die Fehler mit dem Zugriff auf https://o15.officeredir.microsoft.com/r/(...), das komische ist ich sehe den Zugriff nicht im Log der Firewall... D.h. der Exchange kommt warum auch immer nicht mal dort hin.
Hat jemand eine Idee was hier falsch läuft?
Wahrscheinlich ist der Proxy nicht kompatibel mit WinHttp
https://docs.microsoft.com/de-de/microsoft-365/security/defender-endpoin ...
Ich würde wenn eher direkt einen transparent Proxy implementieren als einen klassischen.
Zitat von @149062:
Das kommt weil einige Dienste eines Exchange noch über WinHTTP kommunizieren welcher separate Proxy Einstellungen hat und nicht per Default die WinInet Settings aus dem IE übernehmen.
https://www.msxfaq.de/netzwerk/grundlagen/windows_http_proxy.htm#proxyei ...
Zitat von @leon123:
Danke für die Antworten...
Der Grund für diese Frage ist eigentlich, weil seitdem ich den Systemproxy gesetzt hab, ich ziemlich Probleme habe.
Danke für die Antworten...
Der Grund für diese Frage ist eigentlich, weil seitdem ich den Systemproxy gesetzt hab, ich ziemlich Probleme habe.
Das kommt weil einige Dienste eines Exchange noch über WinHTTP kommunizieren welcher separate Proxy Einstellungen hat und nicht per Default die WinInet Settings aus dem IE übernehmen.
https://www.msxfaq.de/netzwerk/grundlagen/windows_http_proxy.htm#proxyei ...
Mach mal folgenden CMD Befehl (mit Admin rechten, die Proxy Einstellung muss auch als Admin gesetzt sein !! )
netsh winhttp import proxy source=ieZitat von @TomTomBon:
Mach mal folgenden CMD Befehl (mit Admin rechten, die Proxy Einstellung muss auch als Admin gesetzt sein !! )
Zitat von @149062:
Das kommt weil einige Dienste eines Exchange noch über WinHTTP kommunizieren welcher separate Proxy Einstellungen hat und nicht per Default die WinInet Settings aus dem IE übernehmen.
https://www.msxfaq.de/netzwerk/grundlagen/windows_http_proxy.htm#proxyei ...
Zitat von @leon123:
Danke für die Antworten...
Der Grund für diese Frage ist eigentlich, weil seitdem ich den Systemproxy gesetzt hab, ich ziemlich Probleme habe.
Danke für die Antworten...
Der Grund für diese Frage ist eigentlich, weil seitdem ich den Systemproxy gesetzt hab, ich ziemlich Probleme habe.
Das kommt weil einige Dienste eines Exchange noch über WinHTTP kommunizieren welcher separate Proxy Einstellungen hat und nicht per Default die WinInet Settings aus dem IE übernehmen.
https://www.msxfaq.de/netzwerk/grundlagen/windows_http_proxy.htm#proxyei ...
Mach mal folgenden CMD Befehl (mit Admin rechten, die Proxy Einstellung muss auch als Admin gesetzt sein !! )
netsh winhttp import proxy source=ieDas mach ich immer so, ist einfach einfacher. Mit show hab ich den Proxy angezeigt, er ist eingetragen mit Umgehungsliste die ich vorher in den Internetoptionen eingetragen habe...
Zitat von @149062:
Wahrscheinlich ist der Proxy nicht kompatibel mit WinHttp
https://docs.microsoft.com/de-de/microsoft-365/security/defender-endpoin ...
Ich würde wenn eher direkt einen transparent Proxy implementieren als einen klassischen.
Zitat von @leon123:
Trotz Systemproxy erhalte ich immer noch die Fehler mit dem Zugriff auf https://o15.officeredir.microsoft.com/r/(...), das komische ist ich sehe den Zugriff nicht im Log der Firewall... D.h. der Exchange kommt warum auch immer nicht mal dort hin.
Hat jemand eine Idee was hier falsch läuft?
Trotz Systemproxy erhalte ich immer noch die Fehler mit dem Zugriff auf https://o15.officeredir.microsoft.com/r/(...), das komische ist ich sehe den Zugriff nicht im Log der Firewall... D.h. der Exchange kommt warum auch immer nicht mal dort hin.
Hat jemand eine Idee was hier falsch läuft?
Wahrscheinlich ist der Proxy nicht kompatibel mit WinHttp
https://docs.microsoft.com/de-de/microsoft-365/security/defender-endpoin ...
Ich würde wenn eher direkt einen transparent Proxy implementieren als einen klassischen.
unser Proxy hat Benutzer Authentifizierung, das wird mit transparenten Proxy schwer..
