security

Gestern habe ich die Konfiguration zum Absichern von Outlook Anywhere beschrieben. Heute zeige ich euch in ultra kurz wie Outlook Web Access (OWA) mit TMG als Proxy abgesichert wird.

Wie bei Outlook Anywhere benutzen wir den Wizard fuer die Freigabe (fuer Weblistener oder anderen vorher gemachten Einstellungen, bitte bei der Outlook Anywhere Kurzanleitung schauen):

-Forefront TMG Management → Forefront TMG (h4desTMG) → Firewall Policy → Rechtsklick → New → Exchange Web Client Access Publishing Rule...

-Exchange Publishing rule name: owa

-Exchange version: Exchange Server 2010

-Outlook Web Access

-Publish a single Web site or load balancer

-Use SSL to connect to the published Web server or server farm

-Internal site name: mail.test.h4des.org

-Accept requests for: This domain name (type below)

-Public name: mail.test.h4des.org

-Web listener → h4des.org exchange

-Select the method used by Forefront TMG to authenticate to the published Web server: No delegation, and client cannot authenticate directly

-This rule applies to requests from the following user sets: All Authenticated Users

-in den Properties von der Regel „owa“ muss unter Public Name die Webseite, unter der diese Regel erreichbar ist, mit den Angaben in dem Zertifikat uebereinstimmen (hierbei „mail.test.h4des.org“). Die Webseite ist auch nur ueber die dort gemachten Angaben erreichbar und nicht ueber die IP-Adresse des TMG oder anderen Namen die auf den TMG zeigen.

Das wars auch schon. Wenn der DNS von aussen bei mail.test.h4des.org auf den TMG zeigt und der TMG mal.test.h4des.org so aufloest, dass er die Exchange CAS Server erreicht, koennen wir nun schon OWA ueber den TMG als Proxy benutzen.

Nun kommen wir aber zum interessanten. Zum "haerten" (ich mag das Wort "hardening" ja viel lieber) der Regel. Auch hier wieder in sehr kurz:

-Forefront TMG Management → Forefront TMG (h4desTMG) → Firewall Policy → owa → Rechtsklick → Configure HTTP

-General
*Maximum headers length (bytes): 32768 (default war 32768)
*Allow any payload length: deaktivieren (default war aktiviert)
*Maximum payload length (bytes): 10485760 (fuer 10MB Anhaenge ueber OWA)
*Maximum URL length (bytes): 10240 (default war 10240)
*Maximum query length (bytes): 4096 (default war 10240)
*Verify normalization: aktivieren (default war deaktiviert)
*Block high bit characters: deaktivieren (default war deaktiviert) (denn sonst werden Umlaute blockiert und der Nutzer kann bei einer deutschen Version nicht einmal eMails schreiben, da die eMail im Ordner "Entwürfe" landet)
*Block responses containing Windows executable content: aktivieren (default war deaktiviert) (dadurch kann der Nutzer ueber OWA bei keiner eMail S/MIME benutzer, der Zugriff auf S/MIME erfordert das Zugreifen auf eine .exe-Datei)

-Methods
*Allow only specified methods (default war Allow all methods)
*Add... → Method: BCOPY
*Add... → Method: BDELETE
*Add... → Method: BMOVE
*Add... → Method: BPROPPATCH
*Add... → Method: DELETE
*Add... → Method: GET
*Add... → Method: MKCOL
*Add... → Method: MOVE
*Add... → Method: POLL
*Add... → Method: POST
*Add... → Method: PROPFIND
*Add... → Method: PROPPATCH
*Add... → Method: SEARCH
*Add... → Method: SUBSCRIBE

-Extensions
*Block specified extensions (allow all others)
*Add... → Extension: .asax
*Add... → Extension: .ascs
*Add... → Extension: .bat
*Add... → Extension: .com
*Add... → Extension: .config
*Add... → Extension: .cs
*Add... → Extension: .csproj
*Add... → Extension: .dat
*Add... → Extension: .dll
*Add... → Extension: .exe (durch Sperrung von dieser Endung, kann z.B. nicht auf S/MIME Komponenten zugegriffen werden)
*Add... → Extension: .htr
*Add... → Extension: .htw
*Add... → Extension: .ida
*Add... → Extension: .idc
*Add... → Extension: .idq
*Add... → Extension: .ini
*Add... → Extension: .licx
*Add... → Extension: .log
*Add... → Extension: .pdb
*Add... → Extension: .pol
*Add... → Extension: .pritner
*Add... → Extension: .ps1
*Add... → Extension: .resources
*Add... → Extension: .resx
*Add... → Extension: .shtm
*Add... → Extension: .shtml
*Add... → Extension: .stm
*Add... → Extension: .vb
*Add... → Extension: .vbproj
*Add... → Extension: .vbs
*Add... → Extension: .vsdisco
*Add... → Extension: .webinfo
*Add... → Extension: .xsd
*Add... → Extension: .xsx
*Block requests containing ambiguous extensions: deaktivieren (default war deaktiviert)
*je nach Anforderung die die Nutzer haben, muessen einige Dateiendungen erlaubt werden, damit sie Dateien ueber OWA herunterladen koennen

-Signatures
*Add...
*Name: \
*Search in: Request URL
*Signature \

*Add...
*Name: ./
*Search in: Request URL
*Signature ./

*Add...
*Name: ..
*Search in: Request URL
*Signature ..

Diese Einstellungen habe ich jetzt einen Tag lang getestet und sie liefern gute Ergebnisse und fuer mich bisher keine Einschraenkungen.

Ich hatte vor einiger Zeit darueber geschrieben, dass ich Outlook Anywhere aus einem Netz heraus erlauben moechte und es moeglichst sicher sein soll. Nun so extrem viel gibt es leider nicht dazu. Aber mit ein paar Einstellungen kann man es sicher erreichbar machen.

Wenn ihr einen TMG installiert habt, der auch noch hinter einer Firewall ist, so das der TMG nur als Proxy Server zwischen Exchange CAS und Clients aus dem Internet dient, koennt ihr Outlook Anywhere sehr schnell ueber den Wizard veroeffentlichen (die Option heisst Exchange Web Client Access Publishing Rule...). Dieser Wizard sollte auch verwendet werden (steht so unter anderem im "Microsoft Forefront Thread Management Gateway (TMG) Administrator's Companion").

So sieht dann die Konfiguration aus (in ASCII ):

Client --> Internet --> Firewall --> TMG Proxy --> Exchange CAS

Die Firewall gibt einfach nur HTTPS zum TMG Proxy frei und der TMG Proxy ist ueber den Namen "mail.test.h4des.org" erreichbar. Nun zu einer kleinen Ultrakurzanleitung, wie ihr einen Weblistener anlegt:

-Forefront TMG Management → Forefront TMG (h4desTMG) → Firewall Policy → Network Objects → Web Listener → Rechtsklick → New Web Listener...

-Web listener name: h4des.org exchange

-Require SSL secured connections with clients

-Listen for incoming Web requests of these networks: External

-Forefront TMG will compress content sent to clients through this Web Listener if the clients requesting the content support compression

-Use a single certificate for this Web Listener: Select Certificate...
*hier das importierte Zertifikat fuer „mail.test.h4des.org“ auswaehlen

-Select how clients will provide credentials to Forefront TMG: HTML Form Authentication

-Select how Forefront TMG will validate client credentials: Windows (Active Directory)

-Enable SSO for Web sites published with this Web listener: Harken entfernen

Da ueber den selben Web Listener auch noch OWA und ActiveSync (dazu werde ich ein andermal was schreiben) benutzt werden soll, wird als HTML Form Authentication (FBA) verwendet. Der Trick ist hierbei, dass Outlook 2010 kein FBA unterstuetzt und dann zurueck zur HTTP Authentication springt (allerdings nur Basic, leider kein "security-in-depth" Konzept, aber durch HTTPS sollte man auch Basic verwenden koennen), welches auch der TMG annimmt. Wichtig ist hierbei auch, dass beim Weblistener die Authentifizierung eingeschaltet ist, denn sonst leitet der TMG die RPC Pakete nach der Ueberpruefung ohne Authentifizierung zum Exchange CAS. Wenn wir dieses zulassen, koennen wir auch direkt RPC nach aussen freigeben und das ist ja bekanntlichermassen nicht gerade das sicherste Protokoll.

Wenn nun der Weblistener steht, koennen wir Outlook Anywhere freigeben:

-Forefront TMG Management → Forefront TMG (h4desTMG) → Firewall Policy → Rechtsklick → New → Exchange Web Client Access Publishing Rule...

-Exchange Publishing rule name: Outlook Anywhere

-Exchange version: Exchange Server 2010

-Outlook Anywhere (RPC/HTTP(s))
*Publish additional folders on the Exchange Server for Outlook 2007 clients

-Publish a single Web site or load balancer

-Use SSL to connect to the published Web server or server farm

-Internal site name: mail.test.h4des.org

-Accept requests for: This domain name (type below)

-Public name: mail.test.h4des.org

-Web listener → h4des.org exchange

-Select the method used by Forefront TMG to authenticate to the published Web server: NTLM Authentication

-This rule applies to requests from the following user sets: Authenticated Users

Nun wuerde TMG nachdem der Nutzer sich authentifiziert hat, die Anfrage weiter an unsere Exchange CAS Server schicken. Dort muss Outlook sich allerdings nochmal authentifizieren (macht Outlook automatisch mit den vorher eingegebenem Nutzernamen und Passwort).

Da wir nun NTLM als Authentifizierungsmethode angegeben haben, muessen wir unsere Exchange CAS Server auch noch darauf vorbereiten (und Outlook Anywhere erstmal aktivieren):

-Exchange Management Console → Server Configuration → Client Access → Rechtsklick auf Server → Enable Outlook Anywhere...

-External host name: mail.test.h4des.org

-Client authentication method: NTLM Authentication

-Allow secure channel (SSL) offloading: NICHT AKTIVIEREN (diese Option besagt, wenn aktiviert, dass zwischen Exchange CAS Server und TMG kein SSL verwendet wird)

-nachdem Outlook Anywhere aktiviert wurde, dauert es noch (je nach Konfiguration) 15 Minuten bis die Einstellungen aktiv sind

Jetzt noch Outlook 2010 anpassen:

-Outlook 2010 auf dem Client in den Kontoeinstellungen unter E-Mail den Nutzer auswaehlen und in die Einstellungen gehen

-Weitere Einstellungen... → Verbindung → Exchange-Proxyeinstellungen... → Diese Authentifizierung fuer die Verbindung mit dem Exchange-Proxyserver verwenden: Standardauthentifizierung

Das was ich hier in Ultrakurz beschrieben habe, findet man im Internet wie Sand am Meer. Das war auch nicht das, worauf ich hinaus wollte. Und zwar habe ich den Eintrag gemacht, weil man keine wirklichen Informationen im Internet findet, wie man die Verbindung besser schuetzt. In dem Buch "Microsoft Forefront Thread Management Gateway (TMG) Administrator's Companion" habe ich auch nicht wirklich was dazu gefunden. Allerdings habe ich mit etwas mehr basteln und lesen ein paar Sicherheitseinstellungen finden koennen.

Hier sind diese auch in ultra kurz:

-Forefront TMG Management → Forefront TMG (h4desTMG) → Firewall Policy → outlook anywhere → Rechtsklick → Configure HTTP

-General
*Maximum headers length (bytes): 32768 (default war 32768)
*Allow any payload length: aktivieren (default war aktiviert)
*Maximum URL length (bytes): 10240 (default war 10240)
*Maximum query length (bytes): 4096 (default war 10240)
*Verify normalization: aktivieren (default war deaktiviert)
*Block high bit characters: aktivieren (default war deaktiviert)
*Block responses containing Windows executable content: aktivieren (default war deaktiviert)

-Methods
*Allow only specified methods (default war Allow all methods)
*Add... → Method: RPC_IN_DATA
Add... → Method: RPC_OUT_DATA
(im ISA Server 2006 Handbuch steht angegeben, dass die Methoden RPC_DATA_IN und RPC_DATA_OUT heissen, allerdings Beispiel fuer Outlook 2003. Nach einer Ueberpruefung der Pakete wurden aber die Methoden RPC_IN_DATA und RPC_OUT_DATA gefunden)

-Extensions
*Allow only specified extensions (default war Allow all extensions)
*Add... → Extension: .dll (Der Zugriff erfolgt ueber die RpcProxy.dll)
*Block requests containing ambiguous extensions: aktivieren (default war deaktiviert)

-Signatures
*Add...
*Name: \
*Search in: Request URL
*Signature \

*Add...
*Name: ./
*Search in: Request URL
*Signature ./

*Add...
*Name: ..
*Search in: Request URL
*Signature ..

*Add...
*Name: %
*Search in: Request URL
*Signature %

*Add...
*Name: &
*Search in: Request URL
*Signature &

Durch diese Einstellungen ist Outlook Anywhere (oder RPC-over-HTTP) sehr gut abgesichert und kann von aussen freigegeben werden.

Ich hatte vor einigen Tagen an dieser Stelle hier Zweifel angemeldet, ob RPC over HTTPS (neuerdings das Marketing guenstigere Outlook-Anywhere) sicher ist. Nun habe ich auch einige antworten gefunden.


Die erste Antwort gab mir die Security Basics Mailinglist:

Lets now look at RPC. What are the major vulnerabilities of RPC? RPC
does
not authenticate prior to allowing the connection to proceed. Many of
the
RPC vulnerabilities would be neutered if RPC was force to authenticate
prior
to making the connection. RPC over HTTP solves this problem by forcing
authentication. When I add HTTPS to this senario, I have secured my
credentials while they are in an untrusted environment and provided
authentication prior to allowing RPC to proceed. The RPC traffic is
also
passed through the SSL tunnel providing end-to-end security.

Diese Antwort ist zwar von 2005, aber sollte ja heute noch genau so stimmen. Nun habe ich aber weitere Antworten gefunden:

RPC over HTTP provides three types of security in addition to standard RPC security, which results in RPC over HTTP traffic being protected once by RPC, and then doubly protected by the tunneling mechanism provided by RPC over HTTP. For a description of standard RPC security mechanisms, see Security. The RPC over HTTP tunneling mechanism adds to normal RPC security in the following manner:

Provides security through the IIS (available for RPC over HTTP v2 only).
Provides SSL encryption and RPC Proxy verification (mutual authentication). Also available in RPC over HTTP v2 only.
* Provides restrictions on the RPC Proxy level dictating which machines on the server network are allowed to receive RPC over HTTP calls.

Na das hoert sich doch schonmal recht gut an. Getestet habe ich es allerdings noch nicht. Dazu bedarf es auch noch ein wenig Zeit. Werde ich aber bestimmt demnaechst noch machen. Mein Fazit am gelesenen ist bis jetzt einfach, dass man RPC over HTTPS getrost einsetzen kann, sollte ein TMG davor eingesetzt werden. Diesen Link zur genaueren Konfiguration hatte ich hierfuer zugeschickt bekommen.

Der erste Eindruck und Ueberblick zu TMG zeigt mir, dass man sehr fein den HTTP-Traffic filtern und bearbeiten kann. Macht auf jedenfall (fuer ein M$ Produkt) einen guten ersten Eindruck bei mir.

Ich gehe im Moment der Frage nach, ob Outlook Anywhere (RPC over HTTPS) sicher ist. Ich bin im Moment dabei, ein Exchange 2010 System in Betrieb zu nehmen. Natuerlich moechten alle Nutzer gerne von aussen ihre eMails abrufen koennen ueber Outlook Anywhere. Aber ich bin mir im Moment unsicher, ob es sicher genug ist.

Ich zitiere hier mal das Microsoft ISA 2006 Handbuch:

[...]Der Vorteil von RPC ueber HTTPS ist, dass Sie hierfuer keine VPN-Verbindung benoetigen, wodurch die Clients von ueberall eine Verbindung mit dem Exchange Server herstellen koennen. Diese benoetigen nur eine Verbindung ins Internet, zum Beispiel ueber eine UMTS-Karte. Zudem muessen Sie nicht den kritischen Port 135 fuer Ihre Clients veroeffentlichen, damit eine Verbindung zwischen Outlook und dem Exchange Server hergestellt werden kann.[...]

Das unsichere am Port 135 ist nun mal RPC. Dieses macht man von aussen einfach nicht erreichbar. Und fuer mich ist ein Tunneln von RPC durch das HTTPS Protokoll einfach das selbe. Ob ich nun den Exchange Server direkt ueber RPC von aussen erreiche oder ueber RPC welches durch HTTPS getunnelt ist, macht jetzt nicht so den grossen unterschied in meinen Augen.

Das Exchange System soll natuerlich nicht direkt von aussen erreichbar sein. M$ TMG soll den Traffic vorher ueberpruefen. Allerdings habe ich darueber noch keine Informationen gefunden, ob TMG die RPC Aufrufe ueberprueft. Der ISA-Server 2006 packt (zumindest laut dem, was ich im Handbuch gelesen habe) das RPC Paket einfach nur aus dem HTTP Paket aus und leitet dieses weiter an den Exchange Server. Also kommt RPC ohne Ueberpruefung beim Exchange Server von aussen an.

In meinen Augen bisher nicht so das Wahre. Aber ich bin mit meinen Nachforschungen noch nicht durch. Vielleicht habe ich ja was total wichtiges uebersehen. Das Ergebnis werde ich auf jedenfall mitteilen.

Gerade kam eine eMail bei Bugtraq, in der ich mir wieder dachte: "Und da beschweren sich Software Firmen, dass Sicherheitsluecken sofort veroeffentlicht werden?!?"

Disclosure Timeline
-------------------
20th February 2008 - Vendor Notification
26th February 2008 - Vendor Response for more Details
3rd March 2008 - Vendor Confirm Vulnerability
3rd August 2010 - Vendor Patch Released

Citrix hat ueber 2 Jahre gebraucht, um einen Patch dafuer bereit zu stellen...

Unterstuetzt einfach meine Haltung dazu. Frist setzen und wenn bis dahin der Hersteller keinen Patch fertig hat, selber Schuld.