OWA Absichern

Diese Seite ist im Verbund zu anderen Seiten der MSXFAQ zu sehen, die sich mit Outlook Webzugriff  ISA-Server und SSL und Firewalls beschäftigen. Der Schwerpunkt liegt hier bei der Erläuterungen der verschiedenen Absicherungswege und Optionen und deren Wirkung.

Mittlerweile hat Microsoft seine Ansichten etwas geändert und betreibt angeblich auch Office 365 ohne Reverse Proxy und WebFirewall. Ein regelmäßig gepatchted Windows mit Exchange wäre sicher genug und gegen DoS Attacken auf Kennworte helfen eher lange Kennworte denn PreAuthentication oder Lockout Policies. Ich sehe das etwas differenzierter aber lesen Sie selst

Life in a Post TMG World – Is It As Scary As You Think?
http://blogs.technet.com/b/exchange/archive/2013/07/17/life-in-a-post-tmg-world-is-it-as-scary-as-you-think.aspx

Siehe dazu auch Exchange Webseite absichern - Überlegungen zur Absicherung der Exchange Webdienste

Der nackte Server

Outlook Web Access ist eine Web-Anwendung, die auf einem IIS-Server auf dem Exchange Server ausgeführt wird und seit Exchange 2000 per Default installiert und aktiviert ist. Nun wissen wir aber alle, dass per URL-Anfragen ausgeführter Code häufig anfällig für Angriffe ist und da ist Exchange erst mal keine Ausnahme. Daher sollten Schutzmaßnahmen ergriffen werden, die eine Gefährdung reduzieren.

Die komplette Kette

Auf dem folgenden Bild sehen Sie eine umfangreiche Schutzkette, die den eigentlichen Exchange OWA-Server absichert.

Komponenten der Kette

Kettenglied Beschreibung

Portfilter

Ein Windows Server bietet weit mehr Funktionen an als nur den IIS. Diese zusätzliche Ports sollten natürlich nie aus dem Internet erreichbar sein. Ein Portfilter ist daher der billigste und einfachste Schutz. für den Zugriff per OWA ist genau genommen nur der Port 443 (SSL) erforderlich.
Portfilter können aber auch auf dem Server selbst (Windows Firewall) und internen Routern als zusätzlicher Schutz eingesetzt werden, denn auch intern gibt es Angreifer

SSL

Die Verwendung eines SSL-Zertifikats ist kein aktiver Schutz gegen direkte Angreifer, aber eine essentielle Komponente um ein Belauschen der Verbindung und der Kennworte zu verhindern.

Authentifizierung

Von Hause aus ist für den Zugriff auf das Postfach natürlich eine Anmeldung durch den Anwender erforderlich. Eine zusätzliche Sicherheit bietet natürlich ein vorgelagertes System, an dem Sie der Anwender anmelden muss, ehe er auf den eigentlichen OWA-Server weitergeleitet wird. Dies ist auch eine Möglichkeit, zusätzliche Authentifizierungsverfahren (Tokens) einzubinden.

URL Filter

Es ist sehr gut dokumentiert, welche URLs für den Zugriff auf OWA erforderlich sind. (z.B. /exchange/*  /public/*  /exchweb/* und /owa/*. Auch andere URLs für ActiveSync (/Microsoft-Server-ActiveSync/*) oder Autodiscover und EWS sind dokumentiert.
Eine wichtige Komponente des Schutzschilds ist daher ein System, welches auch die URLs untersucht und nur Anfragen passieren zu lassen, die den Regeln entsprechen.
Hier muss man natürlich zugestehen, dass der Microsoft ISA-Server für diese Protokolluntersuchungen wie geschaffen scheint. Aber auch andere Hersteller können mittlerweile mehr als nur den Pfad der URL zu validieren

IIS-Sicherung

Zuletzt steht natürlich der IIS auf der Prüfliste. Was nicht installiert ist, kann auch nicht erreicht werden. Es ist durchaus eine Überlegung, eigene Webseiten für bestimmte Dienste einzurichten, so dass die Sharepoint Webseite, die Webseite der Hardwareüberwachung und anderer Produkte, die sich im IIS gerne addieren, nicht von außen erreichbar sind.

Die Trennung von OWA vom Mailbox Server bei Exchange 2007 (CAS-Rolle) ist eine weitere Schutzstufe. Die Frontend/Backend-Struktur von Exchange 2000/2003 hingegen bietet nur bedingt Schutz, weil der Frontend nach erfolgreicher Anmeldung die Daten nur zum passenden Backend Server weiter leitet. Dort ist aber weiter der IIS für die Generierung der Daten erforderlich.

Welcher Schutz passt ?

Ich kann ihnen im Rahmen der MSXFAQ keine fertige Konzeption zur Absicherung ihres OWA-Zugangs liefern. Klar ist aber, dass neben der sowieso erforderlichen Anmeldung zumindest ein Portfilter und ein SSL-Zertifikat implementiert werden muss. Aber auch die Integration eines ISA-Servers zwischen Internet und Exchange ist eine generell gute Idee, da damit zum einen die Anmeldung schon vorverlagert werden kann und zudem die URLs gefiltert werden können. Aber der ISA-Server kann noch mehr, da er je nach URL die Daten an verschiedene Server weiter leiten kann. Damit ist es sehr einfach möglich, unter einer IP-Adresse mit einem Zertifikat eine Webpräsenz zu betreiben, die je nach URL die Daten von verschiedenen internen Servern abruft. Ideal um mehrere Dienste zu kombinieren und den Schutz gibt es quasi dazu. Hier noch mal als Liste zur eigenen Bewertung.

Thema Beschreibung Bewertung Erfüllt

URL Filterung

Aus meiner Sicht ist diese eine der wesentlichen Funktionen einer Application Firewall für Exchange OWA und mehr. Erst die Filterung der Zugriffe zumindest nach URL-Pfaden ist eine Pflicht für jede Schutzsoftware.

Ich habe zudem immer wieder mit Exchange Servern zu tun, bei denen im IIS zusätzliche virtuelle Verzeichnisse durch andere Produkte eingerichtet wurde, die so auch aus dem Internet erreichbar waren. Eine URL-Allowlist für virtuelle Verzeichnisse ist billig und einfach einzurichten.

Ansonsten können Sie ja einfach Port 443 aus dem Internet auf machen und den IIS hoffentlich sicher betreiben

Hoch

 

SSL Offloading

Wenn ein System die URLs überprüfen will muss es den SSL-Tunnel aufbrechen und das geht nur, wenn das System selbst SSL-Endpunkt ist. Wenn Sie die Verbindung zum internen System dann nicht weiter per SSL Verschlüsseln, entlasten Sie den Server intern. Wobei dies bei den heutigen CPU-Leistungen weniger ein Problem darstellen dürfte.

 

 

User Preauthentication ?

Eine vorgelagerte Lösung kann auch schon die Credentials des Benutzers Abfragen und die Gültigkeit (z.B. gegen das AD, gegen LDAP oder Radius) prüfen und Zugriffe anhand von Gruppen gewähren oder verweigern. Nur bereits authentifizierte Benutzer können dann die eigentlichen Dienstserver erreichen- Nebenbei kann der Anwender bei passender Konfiguration auch unterschiedliche Dienste ohne erneute Anmeldung erreichen (Single SignOn)
Das kann Last von den CAS-Servern nehmen aber ohne zusätzliche Logik kann auch diese Authentifizierung ein Konto sperren.
Preauth. LockoutPolicy, URL Screening, KomplexPasswords

 

 

Lockout

Gegen Angriffe auf ein Anmeldekonten helfen lange komplexe Kennworte, Drosselung von Anmeldungen und eine Sperrung des Kontos bei zu vielen Fehlversuchen.

Aber wenn ihr UserPrincipalName (UPN) gleich der E-Mailadresse ist, kann ein Angreifer normal einfach ihre Kennwort auch von extern sperren. Er bricht zwar nicht ein, wenn ihr Kennwort nicht erraten wird aber ein oder viele gesperrte Konten stören den intenen Betrieb stark stören. Daher ist eine stenge "LogOut" Strategie für ein Konto eigentlich der falsche Ansatz. Besser wäre es, wenn das System, welches eine Anmeldung erfolglos versucht, weitere Versuche immer weiter verzögert, so das Kennwortattacken nicht lohnen. Kombiniert mit ausreichend sicheren Kennworten kann man so ein "Lockout" von vorneherein vermeiden und nur noch direkte interne ungedrosselte Angriffe würden ein Konto kurzzeitig sperren. Leider kann Exchange das so nicht.

 

 

Starke Authentifizierung

Die Benutzerauthentifizierung kann natürlich über Tokens, Smartcards o.ä., noch sicherer gestaltet werden. OWA selbst kann z.B. kein RSA o.ä. von Hause aus und wenn sie mehrere Webseiten betreiben, dann wollen Sie das sicher nicht auf jeder Webfarm einbinden, zumal diese hohe Sicherheit ja für interne Zugriffe oft gar nicht erforderlich oder gewünscht ist. Auch hier ist ein passendes Gateway der richtige Platz.

 

 

URL Content Inspection

Einige Produkte können auch die URL selbst noch „genauer analysieren, d.h. "verstehen" genauer was OWA macht und braucht und können z.B. auch zwischen POST, GET, etc. Unterscheiden.

Wenn eine Webseite z.B. kein ASP oder PHP nutzt, kann könnte ein Reverse Proxy diese Erweiterungen von vorneherein blocken.

 

 

Portalgedanken

Interessant wird es, wenn Sie über ein Gateway auch weitere interne Dienste veröffentlich können, z.B. indem Sie abhängig von der URL andere interne Webserver anbinden. Das kann Sharepoint sein, aber auch eine Monitoring-Anwendung, RDP over HTTP, SSL-VPNs etc., die auch mehr und mehr HTTPS nutzen. Hier ist es dann wichtig, dass je URL unterschiedliche Anmeldungen unterstützt werden aber auch eine Anmeldung quasi als "Single SignOn" für alle Dienste genutzt werden kann.

 

 

TCP Session Alive

Einige Anwendungen wie z.B. ActiveSync stellen besondere Anforderungen derart, dass TCP-Sessions bis zu 28 Minuten “aktiv” bleiben müssen. Trennt eine Firewall/Proxy die Verbindung aufgrund „Inaktivität“ sehr früh (z.B. nach 2 Minuten TCP Timeout), dann verbindet sich der Client eben sehr oft (Datenvolumen, aber vor allem Akkulaufzeit). Hohe Timeouts können andererseits auch das System belasten, da die Sitzungstabelle auch kurze Verbindungen lange vorhalten muss. (Speicher)

Wichtig

 

SSL-Zertifikate

Wer z.B. Exchange CAS direkt veröffentlicht, braucht eventuell viele eigentlich nur intern genutzte Namen auch auf dem öffentlichen Zugang. Das „verrät“ etwas von innen und kostet zusätzlich Geld. Teilweise geht es auch nicht, dass man „server.firma.intern“ in eine SAN-Zertifikat packt. Ein Proxy kann extern einfach nur die wenigen öffentlichen Namen (z.B. Webmail.firma.tld und autodiscover.firma.tld) bereitstellen und intern kann mit eignen Zertifikaten gearbeitet werden

 

 

Lastverteilung

Zuletzt kann so ein System natürlich auch mehrere interne Server (z.B. ein CAS-Array) veröffentlichen und sogar besser als ein NLB die Verfügbarkeit überwachen. Siehe auch NLB unter "NLB und ISA/TMG"

 

 

Es gibt also schon einige Gründe, ein ordentliches System zwischen Internet und Exchange zu stellen. Ideale Funktion bietet natürlich ein Microsoft ISA oder Microsoft TMG-Server. Das heißt aber nicht, dass andere System nicht auch funktionieren.

URLs zur Veröffentlichung

Ein Portfilter alleine ist mir fast immer zu wenig. Daher würde ich immer einen URL-Filter mit einsetzen, der den internen Webserver vor Anfragen an nicht gewünschte URLs blockiert. Diese sind.

URL Bedeutung Exchange
Version		 OWA
2000
2003		 OWA
2007
 OWA
2010
 OWA
2013
 ActiveSync Outlook
2003
RPC
 Outlook
2007
 Outlook
2010
 WAP
Autodiscover

Autodiscover für Outlook 2007/Exchange 2007
  • 2007
  • 2010

 

 

 

 

 

 

 
EWS

Exchange 2007 "Web Services" für OOF, Free/Busy, Regeln
  • 2007
  • 2010

 

 

 

 

 

 

 
Exchange

OWA Haupt-URL für Postfachzugriff mit Exchange 2000/2003
  • 5.5
  • 2000
  • 2003
  • 2007

 

 

 

 

 
ExchWeb

OWA Haupt-URL für Icons, StyleSheets, Javaskripte etc.
  • 2000
  • 2003
  • 2007

 

 

 

 

 

 

 
Microsoft-Server-ActiveSync

URL für PDA Synchronisation, Pushmail
  • 2003
  • 2007
  • 2010

 

 

 

 

 

 

 

 
OAB

Exchange 2007/2010 Download für Offline Adressbücher
  • 2007
  • 2010

 

 

 

 

 

 

 
OMA

Exchange 2003 WAP Zugriff
  • 2003

 

 

 

 

 

 

 

 

OWA

OWA Haupt-URL für Postfachzugriff mit Exchange 2007/2010
  • 2007
  • 2010

 

 

 

 

 

 
Public

OWA Haupt-URL für öffentliche Ordner 200/2003.
In Exchange 2007/2010 vorhanden, lenkt aber auf /OWA um
  • 5.5
  • 2000
  • 2003
  • 2007
  • 2010

 

 

 

 

 

 

 
ExAdmin

Verwaltung für öffentliche Ordner. Nur intern genutzt.
  • 2000
  • 2003

Rpc

RPCoverHTTP-Proxy für Outlook 2003/2007 und 2010
  • 2003
  • 2007
  • 2010

 

 

 

 

 


Nur mit RPC/HTTP


Nur mit RPC/HTTP


Nur mit RPC/HTTP

 
RpcWithCert

RPC mit Zertifikat. Bislang noch nicht genutzt ?
  • 2003
  • 2007
  • 2010

 

 

 

 

 

 

 

 

 
UnifiedMessaging

Exchange 2007 UM Zugriffe und Einstellungen
  • 2007
  • 2010

 

 

 

 

 

 

 
ECP

Exchange 2010 Control Panel
  • 2010

 

 

 

 

 

 

 
Sonstige URLs

Werden nicht genutzt und sollten auch gesperrt werden

 

Addieren Sie einfach die jeweiligen Dienste, die sie verwenden wollten und schon wissen Sie, welche URLs in der Firewall freizugeben sind.

Achtung Case Sensibel
Einige Firewalls und Reverse Proxy-Systeme (z.B. Apache) sind Case-sensible (Großschreibung/Kleinschrift). So ist im IIS das Verzeichnis "/Rpc" eingetragen, während der Client aber "/rpc" anfordert. für den ISA oder IIS ist das kein Problem.

Firewalls mit Exchange 2000/2003 Frontend und Exchange 2007/2010 CAS-Servern

Es gibt viele Ideen, wie ein Front End Server nun für das Internet erreichbar gemacht werden kann. Der Frontend Server darf bei Exchange 2000/2003 zwar in die DMZ gestellt werden, was auf Grund der notwendigen Verbindungen nach innen aber sehr aufwändig ist. Zudem ist die Verbindung zwischen Frontend und Backend per Default nicht verschlüsselt und kann eventuell von einem anderen System in der DMZ abgehört werden. (Lösung IPSEC). Ein Front End Server direkt innen per NAT erreichbar zu machen ist aber auch nicht optimal, da der IIS nicht immer fehlerfrei ist oder nicht 100% sicher konfiguriert wird.

Bei Exchange 2007/2010 ist die Installation in einer DMZ einfach nicht unterstützt, d.h. zwischen dem CAS-Server und den Postfachservern darf keine Firewall sein

Daher gibt es eine ziemlich ideale Lösung, die aber einen entsprechenden Einsatz von Hardware und Software erfordert.


Quelle: Microsoft

In der DMZ steht ein ISA-Server, welcher als Reverse Proxy nur die gewünschten Verzeichnisse /EXCHWEB, /EXCHANGE, /PUBLIC /OMA nach außen freigibt und unerlaubte URLs (URLSCAN) blockiert. Damit ist der IIS auf dem Frontend Server optimal geschützt. Zusätzliche Autorisierungen (RSA, SecureComputing) sind ebenfalls möglich.

Weitere Informationen finden Sie auch auf:

IPSec

Zuletzt möchte ich noch auf die Option hinweisen, den Zugang zu OWA aber auch anderen Diensten wie Outlook AnyWhere oder MAPI/HTTP auf bestimmte bekannte Clients zu beschränken. Für ActiveSync gibt es ja verschiedene Policies und die EAS Quarantäne aber für Windows Clients mit Outlook ist nichts derart zu finden. Aber Windows PCs, speziell wenn diese auch in der Domäne sind, können sehr einfach mit IPSec konfiguriert werden.

Bei IPSec kommen aber keine FQDNs sondern nur IP-Adressen zum tragen. Wenn Sie die Exchange Dienste nun nicht als "Shared Service" zusammen mit anderen Diensten unter einer IP-Adresse veröffentlichen, können Sie hier den Zugang so konfigurieren, dass 443 gar nicht von extern erreichbar ist, sondern die Clients immer erst einen IPSec-Tunnel zur öffentlichen IP-Adresse des Exchange Servers aufbauen.

Using IPsec to Secure Access to Exchange
http://go.microsoft.com/fwlink/?LinkId=207227 
https://www.microsoft.com/en-us/download/details.aspx?id=23708 

Weitere Links