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.

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.
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.    
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.    
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
 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:

Weitere Links

Keywords:OWA ISA Internet Portfilter Firewall