MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Exchange extern absichern

Sie betreiben noch ihren eigenen Exchange Server? Hoffentlich ist es ein Exchange SE Server, der mit allen aktuellen Patches versehen ist. Aber selbst dann sollten Sie prüfen, ob eine Anmeldung mit Benutzername und Kennwort noch wirklich sicher genug ist. Wer immer noch Exchange 2019/2016 oder früher betreibt, weil die Migration noch etwas dauert, sollte erst recht diese Seite lesen.

28 Okt 2025: BSI:  Zehntausende Exchange-Server gefährdet
https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2025/251028_Support_Ende_Exchange-Server.html
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2025/2025-287772-1032.pdf

9. Dez 2025. Es gibt die ersten Security Updates für Exchange SE, die nicht mehr für Exchange 2016/2019 ohne ESU veröffentlicht werden. Wenn Sie Exchange alte Server aus dem Internet erreichbar machen, haben Sie ein deutlich erhöhtes Risiko.

14. Jan 2026: noch 81% der von extern erreichbaren Exchange Server sind noch 2019 oder älter
https://social.bund.de/@certbund/115938937277935516

Es wird sicher noch Zeit dauern, bis die Server alle aktuell sind. Aber egal ob aktuell oder veraltet. Einen zusätzlichen Schutz sollten Sie immer vorsehen.

Exchange ist Kommunikation

Ein Exchange Server ist das Mail- und Kollaboration-Werkzeug und damit per Definition sehr kommunikativ. Damit meine ich nicht nur, dass er Mails per SMTP annimmt und selbst sendet sondern auch den Zugriff der Clients.

  • MAPI - für das "klassische" Outlook
  • ActiveSync - für Mobilgeräte
  • EWS - für Dienste, Outlook/Mac, Outlook/IOS&Android, Teams
  • POP/IMAP/SMTPAuth für Thunderbird & Co
  • OWA - für Browser
  • Autodiscover - für die Bereitstellung von Konfigurationsinformationen

Zudem stellt auch Exchange SE immer noch überflüssigerweise eine Freigabe "Address" per SMB bereit. Natürlich muss Exchange auch Verbindungen zu anderen Servern, insbesondere NTP, DNS, und Domain Controllern (LDAP, GC, KDC, SYSVOL) aufbauen. Das ist aber alles im Rahmen und wer seine Exchange Server gut absichern will, sollte die Server in eigene Subnetze verschieben und den Zugriff nur über einen Loadbalancer oder Router mit Access-Listen erlauben. So können Sie nebenbei z.B.: POP/IMAP auch im LAN auf bestimmte Clients beschränken und jegliche Angriffe auf RPC und andere vielleicht auf dem Server installierte Dienste sind unterbinden. Auch ausgehend können Sie so limitieren, wohin Exchange Server hin darf. Der Hafnium Exploit sollte uns eine Warnung gewesen sein.

Das ist aber nur ein Teil, denn für einen Zugriff auf die erwünschten Zugänge muss natürlich eine Anmeldung erfolgen. Exchange Online bedient sich der Anmeldung per SAML/OAUTH und der Anmeldedienste erlaubt MFA und Conditional Access. Bei lokalen Exchange Servern ist dies nicht einfach mal so konfiguriert. Dort wird immer noch NTLM, BasicAuth und Kerberos gesprochen. OWA nutzt sogar eine formularbasierte Anmeldung. Wird ein Server so auch aus dem Internet erreichbar gemacht, dann können Angreifer sehr einfach Password-Attacken fahren. Entweder stellen Sie Exchange OnPremises ebenfalls auf ADFS/SAML um oder sie stellen davor ein System, welches die Anmeldung sicherer macht.

Das gilt übrigens auch für andere Collaboration-Dienste wie OneDrive, SharePoint aber auch Nextcloud, Dropbox etc. Die sind aber hier kein Thema, auch wenn die Konzepte zum Schutz sehr ähnlich sind.

Sonderfall Autodiscover

"Es geht nicht ohne" sagen die einen, "brauchen wir nicht" die anderen. Leider haben beide Seiten Recht und mal Unrecht, denn wir müssen schon sehen, wozu Autodiscover genutzt wird und ob sie diese Funktion benötigen.

  • Was macht Autodiscover?
    Die erste Funktion von Autodiscover ist die Ermittlung der korrekten Konfiguration zur Verbindung mit dem eigenen Postfach. Ein interner Client in der Domain und Support für Service Connection Points findet den Zugangspunkt per LDAP. Andere Clients fragen verschiedene URLs, z.B. "autodiscover.<maildomain>" ab und erhalten nach einer Anmeldung die Informationen.
  • Manchmal geht es ohne Autodiscover
    Wer den Zugriff nur für "Managed Devices" erlaubt, kann Outlook mittels "Local-XML" den Weg vorgeben und mobile Clients sind per MDM ebenso statisch konfigurierbar. Andere Dienste wie die Hybrid Migration (MRSProxy) oder Free/Busy-Seiten bei Hybrid brauchen kein Autodiscover. Sie können hier die EWS-Endpunkte in der OrganizationRelationShip statisch hinterlegen.
  • Autodiscover von Microsoft 365
    Wenn Sie aber Microsoft Teams in der Cloud mit lokalen Postfächern nutzen wollen, dann müssen Sie zumindest die Microsoft IP-Adressen auf ihren lokalen Service zulassen. Auch Zugriffe von Benutzern auf andere Postfächer nutzen Autodiscover und Outlook/IOS und Outlook/Android, die Stellvertreterzugriffe.
  • Autodiscover Redirect und Exchange Online
    Bislang galt die Regel: "Solange ein Postfach lokal ist, muss Autodiscover auch auf das lokale Exchange verweisen". Nur der lokale Exchange Server kann einen Client anhand der TargetAddress zu einer anderen Umgebung umleiten. Aber gerade Microsoft Clients (Outlook) haben mittlerweile eine Funktion, dass sie auch immer in Exchange Online nach einem Postfach suchen. Wenn der Administrator also sein lokales Autodiscover nicht veröffentlicht, stört das zumindest nicht die Verbindung zu Exchange Online.
  • Áutodiscover absichern!
    Das Problem bei der überwiegenden Exchange OnPremises-Installation ist die erforderliche Anmeldung an Exchange/Autodiscover. Meist wird dazu NTLM oder BasicAuth genutzt und MFA oder andere Absicherungen sind Mangelware. Ein Angreifer kann daher sehr einfach mal Password-Attacken fahren um Zugangsdaten zu prüfen oder auch nur lokale Konten zu sperren.

Autodiscover absichern ist daher ein mehrschichtiges Projekt.

Exchange Erreichbarkeit

Auf dem folgenden Bild sind nicht alle Kombinationen abgebildet. Es soll ihnen aber einen Eindruck über die Komplexität und damit möglichen Hintertüren geben. Es soll aber auch zeigen, dass zwischen den Angreifern und ihrem Exchange Server durchaus Möglichkeiten gibt:

Mit wenigen Ausnahmen (SMTP) können Sie für alle Zugriffe auf Exchange eine Authentifizierung oder Beschränkung auf Source-IP-Adressen erzwingen. Dies ist mit Exchange aber auch vorgelagerten Systemen möglich. Drei Kommunikationen möchte ich hier unterscheiden.

Farbe Protokolle Beschreibung
  MAPI/HTTP
EWS/HTTP
ActiveSync/HTTP
IMAP4/TCP
POP3/TCP

Das sind alles Protokolle von Clients auf ihre Postfach, die zwingend "authentifiziert" erfolgen sollten. Anonyme Zugriffe sind nicht erforderlich und insbesondere die Zugriffe per HTTP können und sollten sie über einen Reverse Proxy leiten, der auch eine Pre-Authentication übernimmt, die URLs prüft und Password-Attacken verhindert ohne dass ihr Domain Controller bei zu vielen Fehlversuchen durch ihren Exchange Server selbst die internen AD-Konten sperrt.

Mit der richtigen Firewall ist dies auch für POP3/IMAP4 möglich, wenn Sie denn diese Protokolle überhaupt aktivieren.
 

Hybrid über HTTP 

Die hier betroffenen Verbindungen sind nur für Zugriffe von anderen Exchange Servern, primär ihr eigener Tenant, erforderlich. Exchange Online authentifiziert sich bei ihrem lokalen Exchange Server natürlich mittels OAUTH.

Bei einer Exchange Hybrid-Bereitstellung können und sollten Sie den Zugriff von den Exchange Online IP-Adressen getrennt beachten. So könnten Sie z.B. Hybrid auch mit Exchange 2016/2019 noch nutzen, ohne die Server aus dem Internet quasi "anonym" verfügbar zu machen.
 

SMTP

Bei der Zustellung von Mails per SMTP an Exchange müssen zwischen anonymen Systemen unterscheiden, die sie hoffentlich sowieso über einen Spamfilter leiten und anderen internen Systemen, die per SMTP vielleicht nur Mails an ihre eigenen Empfänger zusenden. Relay ins Internet ist wieder eine ganz andere Herausforderung. Siehe dazu auch SMTP-Relay, Relaykonzept, Exchange Online als Outbound Relay u.a.

Ausgehend kann Exchange eigentlich ohne Risiko seine Mails direkt senden. Allerdings sollten Sie auch auf eine DKIM-Signatur setzen, was bei Exchange OnPremises leider nicht ohne 3rd-Party Tools o.ä. möglich ist.

Firewall, WAF und Loadbalancer

Ehe wir auf Protokolle, Clients und Schutzmöglichkeiten eingehen, schauen wir uns die drei System an, welche Sie zwischen Client und Server stellen können.

Ich habe hier die "internen"- und "VPN"-Client einen Vertrauensvorschuss gegeben, weil Sie z.B. im Gebäude sind und z.B. per 802.1x authentifiziert sein könnten. Das muss aber nicht sein, denn Angriffe kommen auch von innen. Sie können aber auch auf dem Loadbalancer einfach zwei virtuelle Services, einmal für Intern und einmal von extern einrichten.

Eine Firewall steht vorne am Internet und hat den Auftrag bei eingehenden Verbindungen die dahinterliegenden Server gegen Angriffe zu schützen. Sie lässt z.B. nur die erlaubten Ports (443,587,25) eingehend zu und kann diese sogar nach Source-IP-Adressen einschränken. Wenn Sie Zugriffe nur von internen Clients oder VPN-Usern zulassen, dann könnten Sie alle anderen externen Zugriffe auf Exchange Online beschränken. So ist eine Exchange Hybrid Absicherung möglich.

Die nächste Komponente ist ein Application-Firewall, welche die eingehenden Verbindungen samt TLS-Verschlüsselung terminiert. Damit kann sie in die Nutzdaten schauen und z.B. HTTP-Anfragen genauer unter die Lupe nehmen. Sie kann URLs filtern aber auch Payload auf mögliche Angriffe untersuchen. Gute Application-Firewalls verstehen recht tu, wie Exchange aber auch SMTP, POP, IMAP arbeiten und was nicht erlaubt ist.

Diese Schutzfunktionen sind aus meiner Sicht essentiell, um ein Vier-Augen-Prinzip zu haben und nicht nur auf Exchange Patches zu vertrauen. Das gilt insbesondere, wenn Sie noch Exchange 2019/2016 betreiben.

Interessant ist auch die Funktion, dass diese Komponenten die Anmeldedaten des externen Clients abfragt und prüft. Damit können Sie ihrem Exchange Server dahinter viele Anfragen ersparen. Solche Systeme könnten auch einfach z.B. Multi Faktor oder SAML-Anmeldungen umsetzen, ohne dass Sie diese in Exchange selbst konfigurierten müssten. Der interne Zugriff auf Exchange bleibt weiter per NTLM/Kerberos möglich, so dass auch 3rd Party Tools ohne OAUTH-Unterstützung weiter funktionieren können. Auch ein Zugriff von Exchange Online oder Teams kommt mit einem SAML-Token an und ist damit nicht anonym.

Sie müssen nun nur noch überlegen, ob diese WAF selbst dann schon eine Lastverteilung auf die Exchange Server vornimmt oder dazwischen noch ein interner Loadbalancer zum Einsatz kommt. Vielleicht wollen sie ja nicht, dass die internen Client erst ein Stück nach draußen gehen, um dann wieder rein zu kommen. Das Bild kann nicht auf alle individuelle Konstellationen eingehen und ist als Beispiel zu sehen.

Wenn Sie den Loadbalancer als Dual-Arm-LB einsetzen, dann können Sie Exchange schön in ein eigenes Subnetz verbannen, so dass der direkte Zugriff auf die Server gut kontrolliert werden kann.

How-To

Wenn Sie sich nun fragen, wo eine Checkliste zur Einrichtung zu finden ist, dann muss ich sie enttäuschen. Die Grundprinzipien einer Schutzlösung sind immer gleich.

  • Aktuell Server und Programme
  • Sichere Konfiguration
  • Idealerweise eine Pre-Authentifizierung
  • Gerne auch mit URL-Filterung, DoS-Schutz
  • Ein Mindestmaß an Monitoring der Zugriffe und Anomalitäten

Aber das "Wie" ist dann doch sehr davon abhängig, welche System sie schon haben. Sehr oft erlebe ich, dass Firmen leistungsfähige Firewalls und Loadbalancer haben aber diese nur mit den Basisfunktionen "Access Listen" und "Layer4-Verteilung" einsetzen, obwohl beide Systeme durchaus auch TLS aufbrechen, URLs filtern und Zugriffe einer leistungsfähigeren Authentifizierung unterwerfen können, als dies mit dem Windows IIS und Exchange Bordmitteln möglich wäre.

Ich erlebe es auch immer wieder, dass Anwender problemlos POP3/IMAP4 nutzen könnten und es keine Einschränkungen beim Zugriff auf die SMTP-Dienste von Exchange gibt. Es ist halt einfacher alles zuzulassen als Buch über die erlaubte Verwendung zu führen und diese Einstellungen auch durchzusetzen.

Dass Exchange Server ausgehend ins Netzwerk beschränkt werden ist auch sehr selten. Exchange darf in der Regel überall hin. Wohin dies führt, haben wir mit dem Hafnium Exploit gesehen. Wenn eine Sicherheitslücke von extern über die erlaubten Zugriffe ausnutzbar ist, dann ist Exchange sehr schnell ein Sprungsystem auf weitere erreichbare Systeme.

Sie sehen schon, dass eine Checkliste sogar gefährlich ist, da sie nach Abarbeitung aller Punkte eine Sicherheit verspricht, die sie nie halten kann. Sie kommen daher um eine individuelle Betrachtung, Planung und Implementierung gefolgt von einer kontinuierlichen Weiterentwicklung nicht umhin.

Schutz nach Service

Dennoch möchte ich ein paar Empfehlungen zu den verschiedenen Komponenten geben:

Komponente Empfehlung

Infrastruktur ( DNS, DC, Netzwerk etc)

Wer Exchange Server selbst hostet, muss diese in eine Umgebung mit anderen Servern integrieren. Exchange funktioniert nicht ohne DNS und ein Active Directory. Es klingt wie Allgemeinwissen aber ich finde immer wieder erschreckend unsicher konfigurierte Umgebungen, in denen man mich dann um eine Exchange Server Sicherheitsbewertung fragt. Prüfen Sie ihre Umgebung und wenn Sie einen ersten Überblick brauchen, dann starten Sie doch einfach mal die Community Editionen von Ping Castle, Purple Knight und viele anderen Tools. Sie werden überrascht sein, welche Lücken und schwächen sich in ihrem Active Directory finden lassen. Denken Sie dabei auch an DNS-Server und wer hier welche Einträge aktualisieren kann. Sind unsichere Updates erlaubt, dann kann ein interner Angreifer sich nicht nur theoretisch in die Verbindung einschleifen.

Server

Auch der eigentliche Exchange Server kann durch die Platzierung in ein eigenes Subnetz und passende Access-Listen besser gegen Angriff geschützt werden. Normale Client-Subnetze müssen den Exchange Server eigentlich nur über Port 443 erreichen. Ausgewählte Geräte nutzen vielleicht noch POPS/995, IMAPS/993 und etwas SMTP/587. Port 25 kann ebenfalls auf wenige Systeme beschränkt werden. Damit ist schon viel gewonnen, wenn ihr "altes" Betriebssystem vielleicht eine bekannte Lücke in SMB oder RPC hat. Natürlich sollten Sie Windows aktuell halten und auch Virenscanner und Security-Produkte nutzen. Aber warum sollten Sie einen so wichtigen Server wie "Mail" komplett ungeschützt im Netzwerk betreiben

SMTP/25

Exchange OnPremises hat keinen effektiven Spamfilter. Also müssen Sie so oder so zwischen Internet und Exchange ein SMTP-Relay senden und damit spricht Exchange nicht mehr direkt mit dem Internet sondern ein hoffentlich "vertrauenswürdiges" System, welches die meisten Problemnachrichten abwehrt. Mit dem passenden Spamfilter und ausgehenden Smarthost ist Exchange über SMTP/25 eigentlich nicht mehr angreifbar.
Etwas anderes sind interne Client, die direkt an Exchange Anonym per SMTP zustellen. Hier können Sie den Nutzerkreis über Firewall-Regeln auf ausgewählte IP-Adressen zumindest einschränken

POP/IMAP

Diese Protokolle sind schon lange nicht mehr die bevorzugten Zugänge und sind by Default sogar deaktiviert. Wer sie nutzt, musste die Dienste in Exchange auf automatisch stellen. Aber auch dann können und sollen Sie die Nutzung auf die Postfächer beschränken, die wirklich IMAP4/POP3 nutzen. POP3 sehe ich aus Sicht der Funktion noch kritischer, da hier Clients Mails in der Regel "herunterladen" statt wie bei IMAP synchronisieren. Das Risiko ist hoch, dass die Mails damit nicht mehr auf dem Server liegen, sondern einem Client und leicht verloren gehen.
Es gibt IMAP4-Proxy-Server, die eine Preauthentication durchführen können, und damit den Exchange Server vor den Angriffen anonymer Clients besser schützen. Auch eine Firewall vor dem Exchange Server könnte den Zugriff auf die TCP-Ports (993/995) auf ausgewählte Quell-IP-Adressen beschränken, um die Sicherheit zu erhöhen. Ich hoffe, dass Sie keine Clients aus dem Internet haben, die unbedingt IMAP4 nutzen sollen. Mit ActiveSync, EWS, oder MAPI gibt es viel leistungsfähigere Protokolle.

HTTP

HTTP ist ein dankbares Protokoll, da es sehr viele Firewalls, Loadbalancer und WebApplicationProxy-Server gibt, die HTTP und HTTPS verstehen, URLs bewerten und eine Preauthentication durchführen können. Eine vorgelagerte Anmeldung ist aus meiner Sicht auch der erste und stärkste Schutz des Servers vor Angriffen. Alle anonymen Zugriffe können mit wenigen Ausnahmen direkt abprallen, so dass nur noch authentifizierte Anwender ein Risiko darstellen. Das Risiko ist natürlich vorhanden aber auch dann gibt es Lösungen, die nur bestimmte URLs zulassen und selbst hier noch über Patterns, Feldlängen, Sonderzeichen etc. die Angriffsmöglichkeiten weiter reduzieren. Microsoft hat mit Exchange hat selbst z.B. die AMSI-Schnittstelle implementiert, bei der jeder Request vom IIS erst mal über AMSI - AntiMalware Scan Interface dem Virenscanner/Malware-Scanner vorgelegt wird. Solche Erweiterungen funktionieren natürlich auch auf einem Reverse-Proxy. Wenn es für Exchange SE dann die ersten Updates gibt, die nicht mehr für Exchange 2019/2016 bereitgestellt werden, dann kann man vielleicht hoffen, dass die Vektoren über WAF-Systeme abgeblockt werden.

Wer mag, könnte seinen Exchange Server auch per Modern Hybrid Agent Absicherung über OAUTH härten. Allerdings schalten Sie damit die anderen Anmeldeverfahren nicht automatisch ab. Dann würde ich eher OAUTH mit Conditional Access/MFA auf einem vorgelagerten WAF-System umsetzen, welche dann mittels Kerberos - Constraint Delegation und Double Hop sich am Exchange Server anmeldet. Wenn es rein um OWA geht, dann könnte auch Azure AD Application Proxy oder WAP - Web Application Proxy eine Option sein.

Das soll aber sie nicht dazu verleiten, einen Exchange 2019/2016-Server noch noch ältere Versionen noch länger zu betreiben. Aber Sie können bis zum Abschluss der Migration das Risiko schon deutlich reduzieren.

Letztlich müssen Sie eine eigene Sicherheitsbetrachtung, Risikoabschätzung und Bewertung der Anforderungen machen um dann mit technischen und organisatorischen Maßnahmen (TOMs) den Betrieb von Exchange ausreichend abzusichern.

Für alle weiteren Fragen und Diskussionen können Sie mich gerne anschreiben oder über Net at Work beauftragen.

Weitere Links