Was bringt ein Reverse Proxy vor einem Exchange für KMU?
Hallo,
ich habe bei einem KMU Kunden gesehen, dass dieser einen Reverse-Proxy (NGINX) vor dem Exchange für HTTPs geschaltet hat.
Das ist nicht so mein Thema, ich kann mit OWA, ECP und umgehen und Outlook einrichten.
Es ist mehr eine rein (sicherheits-)technische Frage.
Es geht um einen KMU Kunden mit stark fluktuierenden Personal und vielen Externen.
Deshalb sind Dinge wie VPN, Preauthentifizierung oder Client-Zertifikate keine Option. Sagt der Kunde zumindest.
Hier geht es nur um HTTPs, weder SMTP, POP oder IMAP.
1. Die haben nur /owa und /Microsoft-Server-ActiveSync zugelassen.
Aber was ist mit /ews, /oab, /mapi und /autodiscover?
Braucht man die heutzutage für Exchange 2013, 2016, 2019 und Outlook 2013, 2016, 2019 und 2021 nicht mehr?
2. Was bringt der Proxy?
3. Was machen richtige Firewalls besser?
Laut Aussage eines Firewall-"Experten" eines größeren Systemhauses nutzen viele Firewalls technisch auch nur Squid als Proxy.
Es gibt dort kein IDS oder IPS. Auch kein Brute-Force-Schutz.
Dies hier liest sich genau so.
https://wiki.securepoint.de/UTM/APP/Reverse_Proxy-Exchange
Frage 1: Lohnt sich ein Open Source Proxy mit Geo-Blocking?
Frage 1: Wieviel besser ist eine Firewall als so ein Proxy?
Danke für Eure Gedanken
ich habe bei einem KMU Kunden gesehen, dass dieser einen Reverse-Proxy (NGINX) vor dem Exchange für HTTPs geschaltet hat.
Das ist nicht so mein Thema, ich kann mit OWA, ECP und umgehen und Outlook einrichten.
Es ist mehr eine rein (sicherheits-)technische Frage.
Es geht um einen KMU Kunden mit stark fluktuierenden Personal und vielen Externen.
Deshalb sind Dinge wie VPN, Preauthentifizierung oder Client-Zertifikate keine Option. Sagt der Kunde zumindest.
Hier geht es nur um HTTPs, weder SMTP, POP oder IMAP.
1. Die haben nur /owa und /Microsoft-Server-ActiveSync zugelassen.
Aber was ist mit /ews, /oab, /mapi und /autodiscover?
Braucht man die heutzutage für Exchange 2013, 2016, 2019 und Outlook 2013, 2016, 2019 und 2021 nicht mehr?
2. Was bringt der Proxy?
- ECP bleibt draußen.
- Direkte Zugriff auf Sicherheitslücken des IIS blauben draußen.
- Mit GEO Blocking bleiben unfreundliche Personen von woanders draußen.
- Aber Haifun hätte er nicht verhindert, da der Zugriff auf den Exchange ja 1:1 durchgeleitet wird.
3. Was machen richtige Firewalls besser?
Laut Aussage eines Firewall-"Experten" eines größeren Systemhauses nutzen viele Firewalls technisch auch nur Squid als Proxy.
Es gibt dort kein IDS oder IPS. Auch kein Brute-Force-Schutz.
Dies hier liest sich genau so.
https://wiki.securepoint.de/UTM/APP/Reverse_Proxy-Exchange
Frage 1: Lohnt sich ein Open Source Proxy mit Geo-Blocking?
Frage 1: Wieviel besser ist eine Firewall als so ein Proxy?
Danke für Eure Gedanken
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2906821125
Url: https://administrator.de/contentid/2906821125
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
17 Kommentare
Neuester Kommentar
Moin EDVMan27,
und wie genau nutzt der Kunde diesen Exchange von aussen per HTTPS?
Sind Smartphones angebunden, wenn ja welche (Android/Apple)?
Notebooks mit Outlook?
Nutzt er evtl. nur OWA über den Browser?
Das riecht nach Smartphone.
Das kommt ganz auf den Client an.
Das geht auch per Bordmittel, ganz ohne WAF (Reverse-Proxy/WebApplicationFireWall/ALG).
Theoretisch ja.
GEO Blocking kann bereits schon eine anständige FW (FireWall), dafür brauchst du nicht unbedingt eine WAF.
Das kommt ganz auf die Implementierung der jeweiligen WAF an.
Nichts, eine normale FireWall regelt normalerweise nur auf der Layer 3 Ebene.
Eine WAF, die heutzutage normalerweise in einem Enterprise-Security-Gateway steckt, regelt auf Layer 7 Ebene und ist somit jeder normalen Layer 3 FireWall, schutztechnisch haushoch überlegen.
Dann nutzt dein Firewall-Experte vielleicht die falsche WAF, respektive das falsche Security-Gateway.
Die SG's von Sophos und deren WAF'S, beherrschen sehr wohl IPS & IDS (Snort-Engine), ATP und diverse weitere Schutzmechanismen.
Geo-Blocking ja, aber dafür benötigst du wie schon gesagt, normalerweise nicht extra eine WAF.
Wie schon oben geschrieben, eine reine FireWall (Layer 3) ist einem Security-Gateway (Layer 7) nicht überlegen, sondern haushoch unterlegen.
Noch besser ist übrigens VPN mit 2FA und den Exchange überhaupt nicht über FW oder WAF zu veröffentlichen. 😉
Beste Grüsse aus BaWü
Alex
Es geht um einen KMU Kunden mit stark fluktuierenden Personal und vielen Externen.
Deshalb sind Dinge wie VPN, Preauthentifizierung oder Client-Zertifikate keine Option. Sagt der Kunde zumindest.
Hier geht es nur um HTTPs, weder SMTP, POP oder IMAP.
Deshalb sind Dinge wie VPN, Preauthentifizierung oder Client-Zertifikate keine Option. Sagt der Kunde zumindest.
Hier geht es nur um HTTPs, weder SMTP, POP oder IMAP.
und wie genau nutzt der Kunde diesen Exchange von aussen per HTTPS?
Sind Smartphones angebunden, wenn ja welche (Android/Apple)?
Notebooks mit Outlook?
Nutzt er evtl. nur OWA über den Browser?
1. Die haben nur /owa und /Microsoft-Server-ActiveSync zugelassen.
Das riecht nach Smartphone.
Aber was ist mit /ews, /oab, /mapi und /autodiscover?
Braucht man die heutzutage für Exchange 2013, 2016, 2019 und Outlook 2013, 2016, 2019 und 2021 nicht mehr?
Braucht man die heutzutage für Exchange 2013, 2016, 2019 und Outlook 2013, 2016, 2019 und 2021 nicht mehr?
Das kommt ganz auf den Client an.
2. Was bringt der Proxy?
- ECP bleibt draußen.
Das geht auch per Bordmittel, ganz ohne WAF (Reverse-Proxy/WebApplicationFireWall/ALG).
* Direkte Zugriff auf Sicherheitslücken des IIS blauben draußen.
Theoretisch ja.
* Mit GEO Blocking bleiben unfreundliche Personen von woanders draußen.
GEO Blocking kann bereits schon eine anständige FW (FireWall), dafür brauchst du nicht unbedingt eine WAF.
* Aber Haifun hätte er nicht verhindert, da der Zugriff auf den Exchange ja 1:1 durchgeleitet wird.
Das kommt ganz auf die Implementierung der jeweiligen WAF an.
3. Was machen richtige Firewalls besser?
Nichts, eine normale FireWall regelt normalerweise nur auf der Layer 3 Ebene.
Eine WAF, die heutzutage normalerweise in einem Enterprise-Security-Gateway steckt, regelt auf Layer 7 Ebene und ist somit jeder normalen Layer 3 FireWall, schutztechnisch haushoch überlegen.
Laut Aussage eines Firewall-"Experten" eines größeren Systemhauses nutzen viele Firewalls technisch auch nur Squid als Proxy.
Es gibt dort kein IDS oder IPS. Auch kein Brute-Force-Schutz.
Es gibt dort kein IDS oder IPS. Auch kein Brute-Force-Schutz.
Dann nutzt dein Firewall-Experte vielleicht die falsche WAF, respektive das falsche Security-Gateway.
Die SG's von Sophos und deren WAF'S, beherrschen sehr wohl IPS & IDS (Snort-Engine), ATP und diverse weitere Schutzmechanismen.
Frage 1: Lohnt sich ein Open Source Proxy mit Geo-Blocking?
Geo-Blocking ja, aber dafür benötigst du wie schon gesagt, normalerweise nicht extra eine WAF.
Frage 1: Wieviel besser ist eine Firewall als so ein Proxy?
Wie schon oben geschrieben, eine reine FireWall (Layer 3) ist einem Security-Gateway (Layer 7) nicht überlegen, sondern haushoch unterlegen.
Noch besser ist übrigens VPN mit 2FA und den Exchange überhaupt nicht über FW oder WAF zu veröffentlichen. 😉
Beste Grüsse aus BaWü
Alex
Der Reverse Proxy sendet seinen eigenen Header, somit bekommt der Angreifer nicht mit, dass am Ende ein Microsoft IIS bzw Exchange hängt.
/autodiscover sind für viele Clients wichtig um die Email Einstellungen zu finden.
/ecp wird von Outlook verwendet um z.B. Out Of Office Einstellungen zu übermitteln.
/autodiscover sind für viele Clients wichtig um die Email Einstellungen zu finden.
/ecp wird von Outlook verwendet um z.B. Out Of Office Einstellungen zu übermitteln.
Direkte Zugriff auf Sicherheitslücken des IIS blauben draußen.
Hat es noch welche? Ist die Gefahr höher, als bei Apache oder Nginx, diese können ja auch Sicherheitslücken haben.Laut Securepoint (Telefon) hätte deren Firewall dies nicht verhindert.
https://docs.sophos.com/releasenotes/output/en-us/nsg/IPSReleaseNotes/9. ...
😉
Was zumindest sicher ist: Firmen mit einem sauber konfigurierten Proxy und Reverse-Proxy konnte Hafnium nichts anhaben, egal auf welchem Patchstand der Exchange war, weil die Angreifer entweder erst gar nicht reinkamen (Reverse-Proxy), oder ihren Müll nicht nachladen konnten (Proxy).
Und mit Proxy meine ich keinen „pobligen“ Squid-Proxy wie den einer PFSense, sondern ein richtiges ALG, wie Alex geschrieben hat.
Ich hab hier auch überall SecurePoint im Einsatz, alle Kunden wurden von Hafnium „verschont“, bzw. blieb es wirkungslos.
VG
Und mit Proxy meine ich keinen „pobligen“ Squid-Proxy wie den einer PFSense, sondern ein richtiges ALG, wie Alex geschrieben hat.
Ich hab hier auch überall SecurePoint im Einsatz, alle Kunden wurden von Hafnium „verschont“, bzw. blieb es wirkungslos.
VG
Zitat von @NordicMike:
Der Reverse Proxy sendet seinen eigenen Header, somit bekommt der Angreifer nicht mit, dass am Ende ein Microsoft IIS bzw Exchange hängt.
Naja... Die loginmaske ist doch ziemlich eindeutig.Der Reverse Proxy sendet seinen eigenen Header, somit bekommt der Angreifer nicht mit, dass am Ende ein Microsoft IIS bzw Exchange hängt.
Direkte Zugriff auf Sicherheitslücken des IIS blauben draußen.
Hat es noch welche? Ist die Gefahr höher, als bei Apache oder Nginx, diese können ja auch Sicherheitslücken haben.Ich vertraue da eher auf gekauften Firewall.
Inwieweit zurecht kann ich nicht beurteilen.
"Vermutlich" ist der Unterschied zu einem reinen Proxy nicht groß.
Die Firewalls die ich kennen können ja noch nichtmal einen Brute-Force-Schutz.
Und wenn ich dann noch sehe, dass im Autodiscover bis zu 10 fehlerhafte Anmeldungen ankommen... naja
Zitat von @chgorges:
Was zumindest sicher ist: Firmen mit einem sauber konfigurierten Proxy und Reverse-Proxy konnte Hafnium nichts anhaben, egal auf welchem Patchstand der Exchange war, weil die Angreifer entweder erst gar nicht reinkamen (Reverse-Proxy), oder ihren Müll nicht nachladen konnten (Proxy).
Und mit Proxy meine ich keinen „pobligen“ Squid-Proxy wie den einer PFSense, sondern ein richtiges ALG, wie Alex geschrieben hat.
Ich hab hier auch überall SecurePoint im Einsatz, alle Kunden wurden von Hafnium „verschont“, bzw. blieb es wirkungslos.
VG
Was zumindest sicher ist: Firmen mit einem sauber konfigurierten Proxy und Reverse-Proxy konnte Hafnium nichts anhaben, egal auf welchem Patchstand der Exchange war, weil die Angreifer entweder erst gar nicht reinkamen (Reverse-Proxy), oder ihren Müll nicht nachladen konnten (Proxy).
Und mit Proxy meine ich keinen „pobligen“ Squid-Proxy wie den einer PFSense, sondern ein richtiges ALG, wie Alex geschrieben hat.
Ich hab hier auch überall SecurePoint im Einsatz, alle Kunden wurden von Hafnium „verschont“, bzw. blieb es wirkungslos.
VG
Bei mir hat der „pobligen“ Squid-Proxy genau das verhindert. Da ist aber ein enormes Regelwerk hinter, es ist eine hierarchisches Squid-Mesh (fünf Kisten insgesamt) und die Bereitstellung der EXCH-Webdienste ist nur ein Teil der Aufgaben.
Aber bei uns gab es nicht einen einzigen Versuch oder irgendeine Veränderung, dem „pobligen“ Squid-Proxy sei Dank.
Es kommt nicht darauf an, was etwas ist, sondern was man daraus macht.
Moin Chgorges,
die Erwähnung des Proxy, sprich, ausgehende Filterung finde ich gut und auch sehr wichtig.
Denn es ist beim Exchange und eigentlich auch allen anderen Servern und Clients, nicht nur wichtig von Aussen nach Ihnen richtig "einzuzäunen", sondern auch von Innen nach Aussen.
Wir haben das ausgehende bei unseren Kunden folgend gelöst.
Die drei Regeln gelten explizit für den Exchange.
Die erste Regel erlaubt ausgehend SMTP und scannt die Mails auch ausgehend nach Viren.
Die zweite Regel ist ein transparenter WEB-Proxy, der dem Exchange nur den Zugriff auf Webserver der Kategorie CRL & OCSP (Zertifikatsaktualisierungen) erlaubt und ansonsten alle anderen Webzugriffe komplett blockt.
Und die dritte Regel blockt alles andere richtung WAN, was die oberen beiden Regeln nicht zulassen.
Einfach und absolut effektiv. 😎
DNS Auflösung und NTP gehen über die internen DC's und Updates gibts über den WSUS oder von Hand.
Beste Grüsse aus BaWü
Alex
mit einem sauber konfigurierten Proxy und Reverse-Proxy konnte Hafnium nichts anhaben, egal auf welchem Patchstand der Exchange war, weil die Angreifer entweder erst gar nicht reinkamen (Reverse-Proxy), oder ihren Müll nicht nachladen konnten (Proxy).
die Erwähnung des Proxy, sprich, ausgehende Filterung finde ich gut und auch sehr wichtig.
Denn es ist beim Exchange und eigentlich auch allen anderen Servern und Clients, nicht nur wichtig von Aussen nach Ihnen richtig "einzuzäunen", sondern auch von Innen nach Aussen.
Wir haben das ausgehende bei unseren Kunden folgend gelöst.
Die drei Regeln gelten explizit für den Exchange.
Die erste Regel erlaubt ausgehend SMTP und scannt die Mails auch ausgehend nach Viren.
Die zweite Regel ist ein transparenter WEB-Proxy, der dem Exchange nur den Zugriff auf Webserver der Kategorie CRL & OCSP (Zertifikatsaktualisierungen) erlaubt und ansonsten alle anderen Webzugriffe komplett blockt.
Und die dritte Regel blockt alles andere richtung WAN, was die oberen beiden Regeln nicht zulassen.
Einfach und absolut effektiv. 😎
DNS Auflösung und NTP gehen über die internen DC's und Updates gibts über den WSUS oder von Hand.
Beste Grüsse aus BaWü
Alex
Zitat von @tikayevent:
Bei mir hat der „pobligen“ Squid-Proxy genau das verhindert. Da ist aber ein enormes Regelwerk hinter, es ist eine hierarchisches Squid-Mesh (fünf Kisten insgesamt) und die Bereitstellung der EXCH-Webdienste ist nur ein Teil der Aufgaben.
Es kommt nicht darauf an, was etwas ist, sondern was man daraus macht.
Bei den gekauften UTM Firewalls geht es doch hauptsächlich um das Regelwerk was man erwirbt.Bei mir hat der „pobligen“ Squid-Proxy genau das verhindert. Da ist aber ein enormes Regelwerk hinter, es ist eine hierarchisches Squid-Mesh (fünf Kisten insgesamt) und die Bereitstellung der EXCH-Webdienste ist nur ein Teil der Aufgaben.
Es kommt nicht darauf an, was etwas ist, sondern was man daraus macht.
Viele von denen nutzen auch "nur" Squid.
Zitat von @EDVMan27:
Das ist ja die Frage. Bringt so ein Proxy wirklich Vorteile.
Alle hier im Forum schreiben man muss einen verwenden. Aber wieviel bringt das?
Ein reiner Reverse-Proxy ohne Exchange-Regeln kann nicht viel bewirken.Das ist ja die Frage. Bringt so ein Proxy wirklich Vorteile.
Alle hier im Forum schreiben man muss einen verwenden. Aber wieviel bringt das?
Aber er bietet die Basis für Geo-Blocking, Client-Zertifikate (sehr effektiv aber bei KMUs sehr nervig) oder weiteren Regeln.
Stefan
Dann Frage ich mich natürlich warum es so viele Anleitungen für einen reinen Reverse-Proxy mit NIGNX und Apache für Exchange gibt wenn die eigentlich Nichts bringen.
Es bringt schon was, aber nicht so viel als eine WAF.OPNsense bringt angeblich eine WAF, aber es ist noch keine Zeitankündigung zu sehen. Bis dahin verwende ich den Reverse Proxy, aber auch zusätzlich um zwischen zwei Exchange Server zu steuern. Es macht einfach Spaß einen Exchange Server stundenlang in Ruhe kaputt zu updaten, während der andere stabil die Stellung hält.
Zitat von @NordicMike:
OPNsense bringt angeblich eine WAF, aber es ist noch keine Zeitankündigung zu sehen.
Meinst Du naxsi? Den gibt es doch schon ewig für opnsense. Aber Exchange kann der glaube ich nicht.OPNsense bringt angeblich eine WAF, aber es ist noch keine Zeitankündigung zu sehen.