16
Absicherung Exchange Server
Hallo zusammen,
wir sind bei uns in der Firma nun endlich vom Exchange POP3 Connector weggekommen und empfangen nun unsere E-Mail direkt über MX-Einträge.
Nun zu meinem eigentlichen Anliegen:
Aktuell haben wir den externen Zugriff in unserer Firewall für folgende Dienste auf unseren Exchange geöffnet:
Ich kann seit dieser Umstellung nicht mehr wirklich schlafen und würde am liebsten den Zugriff direkt auf den Exchange wieder verbieten. Wie sichert Ihr euren Exchange ab? Habt Ihr in eurer Firewall die Ports auch direkt für den Exchange geöffnet und schickt Ihr den Traffic z.B.: über Relays?
Vielen Dank im Voraus und euch noch einen schönen Tag
Mit freundlichen Grüßen
L. Kleemann
wir sind bei uns in der Firma nun endlich vom Exchange POP3 Connector weggekommen und empfangen nun unsere E-Mail direkt über MX-Einträge.
Nun zu meinem eigentlichen Anliegen:
Aktuell haben wir den externen Zugriff in unserer Firewall für folgende Dienste auf unseren Exchange geöffnet:
- SMTP
- IMAP
- HTTP
- HTTPS
Ich kann seit dieser Umstellung nicht mehr wirklich schlafen und würde am liebsten den Zugriff direkt auf den Exchange wieder verbieten. Wie sichert Ihr euren Exchange ab? Habt Ihr in eurer Firewall die Ports auch direkt für den Exchange geöffnet und schickt Ihr den Traffic z.B.: über Relays?
Vielen Dank im Voraus und euch noch einen schönen Tag
Mit freundlichen Grüßen
L. Kleemann
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: 1099666010
Url: https://administrator.de/contentid/1099666010
Ausgedruckt am: 04.11.2024 um 18:11 Uhr
16 Kommentare
Neuester Kommentar
Du hast mehrere Möglichkeiten.
Davor eine UTM mit WAF hängen, eine WebApplicationFirewall only davor setzen.
IMAP verbieten (benötigt ihr IMAP extern)?
SMTP kannst / solltest du vorher über ein Relay schicken und ggf. schon scannen (per UTM, externer Relay Anbieter, Office365 Server oder internes Relay
Gruß
Davor eine UTM mit WAF hängen, eine WebApplicationFirewall only davor setzen.
IMAP verbieten (benötigt ihr IMAP extern)?
SMTP kannst / solltest du vorher über ein Relay schicken und ggf. schon scannen (per UTM, externer Relay Anbieter, Office365 Server oder internes Relay
Gruß
Hallo @LKleemann,
sei mir bitte nicht böse, aber hast Du die Ereignisse im März bzgl. des Exchange-Desasters verschlafen? Damals wurde hier viel im Forum über den Exchange-Hack und das Thema Sicherheit philosophiert. Nicht nur hier, sondern auch von der Fachpresse und dem BSI wurden anleitungen herausgegeben, wie man einen Exchange absichern und sicher bereitstellen kann.
Wenn ich das hier lese, offene Ports für SMTP, IMAP, HTTP, HTTPS, und das alles ohne VPN-Absicherung, UTM-Firewall, etc., dann grenzt das schon stark an grobe Fahrlässigkeit.
Geh mal davon aus, dass Dein System bereits gehackt wurde und Du alles neu aufsetzen darfst. Dann aber bitte richtig!
Gruß
its
sei mir bitte nicht böse, aber hast Du die Ereignisse im März bzgl. des Exchange-Desasters verschlafen? Damals wurde hier viel im Forum über den Exchange-Hack und das Thema Sicherheit philosophiert. Nicht nur hier, sondern auch von der Fachpresse und dem BSI wurden anleitungen herausgegeben, wie man einen Exchange absichern und sicher bereitstellen kann.
Wenn ich das hier lese, offene Ports für SMTP, IMAP, HTTP, HTTPS, und das alles ohne VPN-Absicherung, UTM-Firewall, etc., dann grenzt das schon stark an grobe Fahrlässigkeit.
Geh mal davon aus, dass Dein System bereits gehackt wurde und Du alles neu aufsetzen darfst. Dann aber bitte richtig!
Gruß
its
Die Frage ist welche Dienste du wirklich brauchst d.h. muss das alles nach aussen offen sein?
Vermutlich brauchst du ja nur owa + activesync
Viele UTM Kästchen haben bereits fertige profile für die Exchange Dienste
Falls du das alles selbst machen willst, kann man das mit OpenSource Software realisieren, z.B. mit einem nginx als reverse-proxy, hier ein paar Links die Google auf die schnelle ausspuckt:
https://www.hoelzle.net/nginx-als-reverse-proxy-fuer-exchange-2010201320 ...
und
https://blog.friedlandreas.net/2013/07/reverseproxy-fur-eas-exchange-act ...
Das schöne ist das man auf der Webserver ebene für eine sichere Clientauthentifizierung sorgen kann mit z.B. Clientszertifikaten:
https://www.ssltrust.com.au/help/setup-guides/client-certificate-authent ...
Will man noch mehr prüfen, könnte man noch mit z.B. modsecurity eine web-application-firewall basteln
Aber schlussendlich mehr Code, mehr systeme = mehr Fehlerquellen und einfallstore :D - daher die Kernfrage: Brauchst du Exchange wirklich?
MFG
N-Dude
Vermutlich brauchst du ja nur owa + activesync
Viele UTM Kästchen haben bereits fertige profile für die Exchange Dienste
Falls du das alles selbst machen willst, kann man das mit OpenSource Software realisieren, z.B. mit einem nginx als reverse-proxy, hier ein paar Links die Google auf die schnelle ausspuckt:
https://www.hoelzle.net/nginx-als-reverse-proxy-fuer-exchange-2010201320 ...
und
https://blog.friedlandreas.net/2013/07/reverseproxy-fur-eas-exchange-act ...
Das schöne ist das man auf der Webserver ebene für eine sichere Clientauthentifizierung sorgen kann mit z.B. Clientszertifikaten:
https://www.ssltrust.com.au/help/setup-guides/client-certificate-authent ...
Will man noch mehr prüfen, könnte man noch mit z.B. modsecurity eine web-application-firewall basteln
Aber schlussendlich mehr Code, mehr systeme = mehr Fehlerquellen und einfallstore :D - daher die Kernfrage: Brauchst du Exchange wirklich?
MFG
N-Dude
z.B. Proxmox als Mailgateway in der DMZ dem Exchange vorschalten. Den Rest nur über VPN.
Moin,
Wie die Kollegen schon sagten, ohne besondere Vorkehrungen ist es keine gute Idee, einen Exchange mit dem "nackten Arsch ins Internet" zu stellen, d.h. Dienste da drauf direkt per SMTP, IMAP, HTTP/HTTPS zugreifbar zu machen. Da muß man entweder den Server selbst härten, was eine Sisyphos-Aufgabe ist, oder durch geeignete Maßnahmen (Firewall, Proxy, VPN) dafür sorgen, daß da nur gefilterte Zugriffe möglich sind. Da sollte man nochmal darüber sinnieren, wer wie auf was zugreifen muß und dementsprechend nacharbeiten. Mindestens den SMTP würde ich über einen lokalen Proxy in der DMZ laufen lassen.
lks
PS. Eine lokalen Exchange direkt per SMTP von außen zu beliefern wiederspricht auch dem Grundsatz, alles von außen erreichbare in eine DMZ zu stellen.
Wie die Kollegen schon sagten, ohne besondere Vorkehrungen ist es keine gute Idee, einen Exchange mit dem "nackten Arsch ins Internet" zu stellen, d.h. Dienste da drauf direkt per SMTP, IMAP, HTTP/HTTPS zugreifbar zu machen. Da muß man entweder den Server selbst härten, was eine Sisyphos-Aufgabe ist, oder durch geeignete Maßnahmen (Firewall, Proxy, VPN) dafür sorgen, daß da nur gefilterte Zugriffe möglich sind. Da sollte man nochmal darüber sinnieren, wer wie auf was zugreifen muß und dementsprechend nacharbeiten. Mindestens den SMTP würde ich über einen lokalen Proxy in der DMZ laufen lassen.
lks
PS. Eine lokalen Exchange direkt per SMTP von außen zu beliefern wiederspricht auch dem Grundsatz, alles von außen erreichbare in eine DMZ zu stellen.
Moin,
SMTP
Entsprechende dedizierte Server, welche als Malware, URL Filter, etc. agieren. Wichtig für uns war das diese als SMTP Proxy agieren und nicht als SMTP Relay.
IMAP
Ist bei uns nicht erlaubt. Wir bieten dafür Outlook Anywhere an.
HTTPS
Darüber stellen wir Active Sync, OWA, Outlook Anywhere bereit.
Grundsätzlich setzen wir eine Kombination aus Firewall, Web Application Firewall (WAF), Microsof Web Application Proxy (WAP) mit Active Directory Federation Service (AD FS) ein. Die ersten beide Komponenten sprechen für sich. Natürlich macht eine WAF nur mit entsprechenden Regeln für die veröffentlichen Applikationen Sinn.
WAP + AD FS dient dazu, dass die Authentifizierunganfragen nicht auf dem Exchange Server durchgeführt werden sondern in einer unabhängigen, vorgelagerten Instanz (Pre-Authentifizierung). So kann u.a. vermieden werden, dass von außen durch Testen Kontosperrungen im Active Directory verursacht werden (Stichwort A FS Extranet Logout). Das können die Lösungen auf Nginx, HAproxy, Apache, etc. nicht abbilden und verhindern.
Für Active Sync haben wir in den Postfächern hinterlegt, welche Geräte diese auch einbinden dürfen. Somit erfolgt bei jedem Versuch eines fremdes Gerät seine Isolation.
Für OWA nutzen wir eine 2FA für alle Nutzer - ohne Ausnahme. Dazu setzen wir Hardware OTP Token ein, um keine Abhängigkeit zu Smartphone o.ä. zu schaffen.
Outlook Anywhere ist in der Tat nur per VPN erreichbar. Da hier weder eine 2FA aktuell möglich ist, sowie eine Authentifizierung der Clients mit Hilfe eines SSL Zertifikats noch nicht sauber funktioniert.
Wir können ruhig schlafen.
Gruß,
Dani
Wie sichert Ihr euren Exchange ab? Habt Ihr in eurer Firewall die Ports auch direkt für den Exchange geöffnet und schickt Ihr den Traffic z.B.: über Relays?
SMTP
Entsprechende dedizierte Server, welche als Malware, URL Filter, etc. agieren. Wichtig für uns war das diese als SMTP Proxy agieren und nicht als SMTP Relay.
IMAP
Ist bei uns nicht erlaubt. Wir bieten dafür Outlook Anywhere an.
HTTPS
Darüber stellen wir Active Sync, OWA, Outlook Anywhere bereit.
Grundsätzlich setzen wir eine Kombination aus Firewall, Web Application Firewall (WAF), Microsof Web Application Proxy (WAP) mit Active Directory Federation Service (AD FS) ein. Die ersten beide Komponenten sprechen für sich. Natürlich macht eine WAF nur mit entsprechenden Regeln für die veröffentlichen Applikationen Sinn.
WAP + AD FS dient dazu, dass die Authentifizierunganfragen nicht auf dem Exchange Server durchgeführt werden sondern in einer unabhängigen, vorgelagerten Instanz (Pre-Authentifizierung). So kann u.a. vermieden werden, dass von außen durch Testen Kontosperrungen im Active Directory verursacht werden (Stichwort A FS Extranet Logout). Das können die Lösungen auf Nginx, HAproxy, Apache, etc. nicht abbilden und verhindern.
Für Active Sync haben wir in den Postfächern hinterlegt, welche Geräte diese auch einbinden dürfen. Somit erfolgt bei jedem Versuch eines fremdes Gerät seine Isolation.
Für OWA nutzen wir eine 2FA für alle Nutzer - ohne Ausnahme. Dazu setzen wir Hardware OTP Token ein, um keine Abhängigkeit zu Smartphone o.ä. zu schaffen.
Outlook Anywhere ist in der Tat nur per VPN erreichbar. Da hier weder eine 2FA aktuell möglich ist, sowie eine Authentifizierung der Clients mit Hilfe eines SSL Zertifikats noch nicht sauber funktioniert.
Wir können ruhig schlafen.
Gruß,
Dani
WAP + AD FS dient dazu, dass die Authentifizierunganfragen nicht auf dem Exchange Server durchgeführt werden sondern in einer > unabhängigen, vorgelagerten Instanz (Pre-Authentifizierung). So kann u.a. vermieden werden, dass von außen durch Testen > Kontosperrungen im Active Directory verursacht werden (Stichwort A FS Extranet Logout). Das können die Lösungen auf Nginx, > HAproxy, Apache, etc. nicht abbilden und verhindern.
Eigentlich schon, siehe oben -> Clientzertifikate als die wirklich gute Lösung
Und wenn man doch über AD Auth machen will:
https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html
Exchange Online wäre auch eine Überlegung wert.
Je nachdem wie groß das Unternehmen ist, darf man den Rattenschwanz an Wartung nicht vergessen, der zusätzlich zu dem Einrichtungsaufwand (siehe die Beiträge der Kollegen oben) noch hinzukommt:
- Datensicherung Exchange
- Updates Exchange
- Updates Firewall
- Erneuerung Zertifikate
- Regelmäßige Prüfung ob das auch alles funktioniert etc.
Wenn man ein großes IT-Team hat, kein Problem. Ist das aber eine Butze mit 50 Leuten und 1 Admin, dann ist das eine enorme Arbeit.
Je nachdem wie groß das Unternehmen ist, darf man den Rattenschwanz an Wartung nicht vergessen, der zusätzlich zu dem Einrichtungsaufwand (siehe die Beiträge der Kollegen oben) noch hinzukommt:
- Datensicherung Exchange
- Updates Exchange
- Updates Firewall
- Erneuerung Zertifikate
- Regelmäßige Prüfung ob das auch alles funktioniert etc.
Wenn man ein großes IT-Team hat, kein Problem. Ist das aber eine Butze mit 50 Leuten und 1 Admin, dann ist das eine enorme Arbeit.
@NetzwerkDude
Gruß,
Dani
Eigentlich schon, siehe oben -> Clientzertifikate als die wirklich gute Lösung
Wenn ich das richtig verstanden habe, läuft die Authentifizierung trotzem direkt gegen den Exchange Server und nicht am vorgelagerten System ab. Weil schlussendlich antwortet wieder trotz Reverse Proxy am Ende der IIS. D.h. ein WAF wäre eine Mindestanforderung.Und wenn man doch über AD Auth machen will:
https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html
Damit unterbindest du keine Sperrungen von Benutzerkonten Account durch Probieren der Zugangsdaten im Active Directory. Zudem wie könnte dann eine Implementierung einer 2FA aussehen?Funktioniert damit neben OWA auch Active Sync als Pre-Auth? Weil das Modul setzt auf HTTP Basic Authentification, was meines Wissens nicht supportet wird/ist. Oder ist das inzwischen überholt? Bin leider schon länger aus der direkten Administration ausgeschieden.https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html
Gruß,
Dani
Zitat von @Drohnald:
Exchange Online wäre auch eine Überlegung wert.
Je nachdem wie groß das Unternehmen ist, darf man den Rattenschwanz an Wartung nicht vergessen, der zusätzlich zu dem Einrichtungsaufwand (siehe die Beiträge der Kollegen oben) noch hinzukommt:
- Datensicherung Exchange
ist auch ohne Exchange notwendig für andere VM / Server notwendigExchange Online wäre auch eine Überlegung wert.
Je nachdem wie groß das Unternehmen ist, darf man den Rattenschwanz an Wartung nicht vergessen, der zusätzlich zu dem Einrichtungsaufwand (siehe die Beiträge der Kollegen oben) noch hinzukommt:
- Datensicherung Exchange
- Updates Firewall
ist auch ohne Exchange notwendig- Erneuerung Zertifikate
ist auch ohne Exchange notwendig- Regelmäßige Prüfung ob das auch alles funktioniert etc.
ist ebenfalls bei anderen VM notwendig ;)Gruß
Kann zu Activesync nicht viel sagen da ich das nicht aktiv im Einsatz habe, aber die Clientzertifikate authentifizieren sich gegenüber dem Proxy-Webserver, also vorm IIS/Exchange.
Man kann schon sperrungen verhindern, indem man z.B. das nicht direkt an den AD weitergibt sondern sich z.B. gegen einen LDAP Proxy Authentifiziert - wird halt immer komplexer so ein aufbau je mehr wann will
Für 2FA im Webserver gibts auch einige Projekte wie zB.
https://github.com/itemir/apache_2fa
Ich wollte mit meinen Post nur darlegen das man, sofern man die Kompetenz und Zeit hat, das alles selbst machen kann ohne ein propriäteres Kästchen
Man kann schon sperrungen verhindern, indem man z.B. das nicht direkt an den AD weitergibt sondern sich z.B. gegen einen LDAP Proxy Authentifiziert - wird halt immer komplexer so ein aufbau je mehr wann will
Für 2FA im Webserver gibts auch einige Projekte wie zB.
https://github.com/itemir/apache_2fa
Ich wollte mit meinen Post nur darlegen das man, sofern man die Kompetenz und Zeit hat, das alles selbst machen kann ohne ein propriäteres Kästchen
@NetzwerkDude
Schlussendlich ist es immer eine Abwägung zwischen Zeit, Aufwand, technischer Support bei Problemen und Resultat.
Hast du solch ein Konstrukt (Pre-Auth, WAF, 2FA) in der von dir geschilderten Umfang aktiv im Einsatz?
Gruß,
Dani
Ich wollte mit meinen Post nur darlegen das man, sofern man die Kompetenz und Zeit hat, das alles selbst machen kann ohne ein propriäteres Kästchen
Na du hast mich schon neugierig gemacht. Und den anderen Leser sicherlich auch. Schlussendlich ist es immer eine Abwägung zwischen Zeit, Aufwand, technischer Support bei Problemen und Resultat.Hast du solch ein Konstrukt (Pre-Auth, WAF, 2FA) in der von dir geschilderten Umfang aktiv im Einsatz?
Gruß,
Dani
Hi Dani,
nicht die drei Sachen und nicht für den Exchange.
Bin meist in Projekten mit Entwicklern wo wir z.B. REST APIs auf Webserver ebene absichern, da kommt alles Mögliche zum Einsatz, je nach Szenario. Aber die Kombi oben müsste so gehen, habe ich aber wie gesagt nicht im Einsatz
nicht die drei Sachen und nicht für den Exchange.
Bin meist in Projekten mit Entwicklern wo wir z.B. REST APIs auf Webserver ebene absichern, da kommt alles Mögliche zum Einsatz, je nach Szenario. Aber die Kombi oben müsste so gehen, habe ich aber wie gesagt nicht im Einsatz
Spielt keine Rolle. Exchange onPrem = mehr Aufwand und mehr Backupspeicher als mit EXO
Man muss weit weniger Releasenotes prüfen, wenn die Firewall von außen komplett zu ist und keinerlei Verbindung zum AD etc. hat
Wozu? Welche Zertifikate braucht eine Firma ohne Exchange OnPrem grundsätzlich und immer?
Spielt keine Rolle. Es ist _zusätzlicher_ Aufwand den man mit EXO nicht hat.
- Updates Firewall
ist auch ohne Exchange notwendig- Erneuerung Zertifikate
ist auch ohne Exchange notwendig- Regelmäßige Prüfung ob das auch alles funktioniert etc.
ist ebenfalls bei anderen VM notwendig ;)
Zitat von @Drohnald:
Spielt keine Rolle. Exchange onPrem = mehr Aufwand und mehr Backupspeicher als mit EXO
Spielt keine Rolle. Exchange onPrem = mehr Aufwand und mehr Backupspeicher als mit EXO
Willst Du damit sagen dass Exchange Online kein Backup benötigt?
- Updates Firewall
ist auch ohne Exchange notwendigLetzteres hat sie ja schon in 90% der Anwendungsfälle schon allein wegen Webfiltern...
Gruß
Alex
Jedenfalls nicht im Sinne von Backup/Restore Lösungen die man OnPrem benutzt, schon allein weil man das Azure-AD nicht mit exportieren kann. Backup bei EXO = Export von Postfächern, Kalendern usw.
Den "Exchange Online Server", falls man das so nennen möchte, kann man sowieso nicht sichern, da muss man auf MS vertrauen.
Archivierung von E-Mails für Geschäftszwecke findet sowieso in einer eigenen Software statt, schon allein wegen Zuordnung von Geschäftsvorgängen.
Letzteres hat sie ja schon in 90% der Anwendungsfälle schon allein wegen Webfiltern...
Wenn man auf Benutzerebene filtern möchte bestimmt. Ansonsten nicht zwingend und gerade kleinere Firmen nutzen das Erfahrungsgemäß eher selten, weil die nicht für jedes "könnt ihr mal für User ABC, Seite XY freischalten" den Dienstleister rufen wollen.
Den "Exchange Online Server", falls man das so nennen möchte, kann man sowieso nicht sichern, da muss man auf MS vertrauen.
Archivierung von E-Mails für Geschäftszwecke findet sowieso in einer eigenen Software statt, schon allein wegen Zuordnung von Geschäftsvorgängen.
Letzteres hat sie ja schon in 90% der Anwendungsfälle schon allein wegen Webfiltern...
