IIS ARR (Application Request Routing)

Seit November 2012 können Neukunden nicht mehr den TMG 2010 Server kaufen. Microsoft wird diese pfiffige Lösung zur sicheren Veröffentlichung leider nicht weiter führen. Bestandkunden haben natürlich auch die nächsten Jahre noch Anrecht auf Support und Updates. Für Neuninstallationen wird man sich aber nach anderen Lösungen umschauen müssen. Es ist aber nicht so, dass der Markt hier nichts zu bieten hat. Die Veröffentlichung von Exchange ist ja nur eine Aufgabenstellung die heute in Firmen anstehen. Webdienste und Webservices sind allgegenwärtig und so müssen auch Sharepoint, Lync und andere HTTPS-Dienste sicher veröffentlicht werden.

Was ist ARR ?

Vergessen Sie erst mal alles um das Thema Firewall und stellen Sie sich vor, sie müssten  eine Webseite betreiben, die nicht nur viel Inhalt hat, sondern auch von ganz vielen Clients angesprochen wird. Ein einzelner Webserver, der alle Inhalte für alle Clients bereit stellt ist also definitiv nicht mehr geeignet. Es sind zu viele Anfragen aus verschiedenen Regionen.

Bislang kommt in diesen Punkten ARR noch gar nicht vor, denn bislang gibt es auch noch keine Anforderung. ARR wird nämlich nicht auf dem Webserver selbst installiert, der die Daten bereit stellt, sondern auf einem oder mehreren Systemen davor. Die Anfrage landet dann nicht mehr direkt auf dem Content-Webserver sondern einem IIS, der das ARR-Feature installiert und konfiguriert hat. Dieser leitet die Anfrage dann an den Content-Webserver weiter. Dies hat mehrere Vorteile beim Betrieb einer Webseite:

ARR ist also eine weitere Komponente bei der "Scale Out"- Thematik von Webservern. Die Funktion lässt sich am besten als "Reverse Proxy" beschreiben, der zudem URLs per Regular Expressions bewerten und durch Caching den Content-Server entlasten kann.

Einsatz mit Exchange und Lync ?

Wer Exchange oder Lync aus dem Internet erreichbar machen will, muss aus technischer Sicht die Verbindungen der Client, die per DNS einen Zugangspunkt auflösen auf Port 443/TCP annehmen. In ganz kleinen Umgebungen kann das natürlich direkt der IIS auf dem Exchange Server sein, der direkt mit einem Bein im Internet hängt (z.B. als Hosted Server bei einem Provider) oder hinter einem NAT-Router zumindest etwas abgeschirmt ist. Größere Firmen werden eh über eine Portal-Lösung oder "große Firewall" nachdenken, die auch eine Anmeldung der Benutzer unterstützt und erst dann die Anfragen an Exchange weiter gibt.

Aber es gibt natürlich auch sehr viele Firmen, die bislang mit dem ISA-Server bzw. TMG 2010 Server als Reverse Proxy gearbeitet. Und hier könne ein vorgeschalteter IIS mit AAR doch eine interessante Option sein. Sicher sind all die Funktionen bezüglich Caching, Lastverteilung etc. nicht interessant aber ein ReverseProxy, der Abhängig von der URL die Daten nach hinten durchreicht ist auf jeden Fall eine bessere Schutzmauer als ein einfaches Port 443-ReverseNAT oder eine portbasierte Firewall.

Aber ist es gut genug, denn ein TMG macht ja noch mehr als nur "Reverse Proxy" zu sein. Er prüft ja auch noch HTTP-Protokolleigenschaften und erlaubt die Authentifizierung samt Single-Sign-On, wenn der Anwender auch noch andere Dienste nutzen will. Für Lync gibt es aber schon einen ersten Blog-Eintrag, wobei Lync eher "einfach" ist in Hinsicht auf Protokollspezialitäten

Einschränkung

Auch wen ARR auf den ersten Blick fast wie der perfekte Nachfolger für die TMG2010 Funktion zur Veröffentlichung von Webseiten ist, so sollten Sie auch die Einschränkungen verstanden haben. Schließlich geht es um ein Stück "Schutz" gegen Angriffe aus dem Internet, bei dem zum einen das System dahinter, also z.B. ihr Exchange Server gesichert werden muss aber auch das System selbst, welches die Umsetzung ausführt. Denn dieses System steht mit einem Bein "draußen" und hat in der Regel auch ein Bein intern oder ist sogar Mitglied der Domäne.

With regard to tunneling of authentication, ARR behaves the same way that a router/switch on your network behaves - as long as the hostname that the client is connecting to (may not be the ARR machine name) is registered in AD with the spn assigned to the identity running on the backend server, the kerberos encryption/decryption will be done for/by that identity and kerberos would work
Of course, if part of the site needs to be served from ARR and part from the backend server, both ARR and the backend server would need to run using a common domain identity so that both parts of the site can authenticate correctly
Quelle: Anil Ruia Software Design Engineer IIS Core Server auf http://forums.iis.net/t/1162690.aspx

Sicherheit

Wer z.B. Exchange OWA sicher veröffentlichen will, muss mehrere Aspekte beleuchten.

Funktionalität NAT ARR TMG ihre Lösung
Authentifizierung
Damit ist gemeint, dass der Benutzer schon vor Exchange sich anmelden muss, damit das System den Benutzer erkennt		 Nein Nein Ja  
Autorisierung
Anhand der nun bekannten Identität kann das System festlegen, welche Dienste der Anwender nun nutzen kann		 Nein Nein Ja  
Schutz gegen Account ausspähen/proben Nein Nein Ja (1)  
Schutz gegen Zugriff auf nicht gewünschte URLs Nein Ja Ja  
Schutz gegen Portscan und Zugriff auf Dienste auf anderen Ports Ja Nein(2) Ja  
Schutz gegen bestimmte "Muster" in URLs, z.B. "*.php" oder "*/cgi-bin/*" Nein Ja Ja  
SSL Offloading zur Lastreduzierung und erforderlich, um URLs zu filtern. Nein Ja (3) Ja (3)  
Lastverteilung Auf mehrere Backend-Systeme mit Client Affinity Nein Cookie Ja  
HealthCheck der Backend Server Nein Ja Ja  
Graceful Shutdown, d.h. beim Einsatz als Loadbalancer einen Content-Server frei schalten Nein Ja Ja  
URL "Firewall" Nein Nein (4) Ja  
  1. TMG kann seit SP2 (?) so eingestellt werden, dass nach einigen Fehlversuchen dieser User sich einige Zeit nicht über TMG anmelden kann und damot das interne Konto nicht gesperrt wird.
  2. Die Windows Firewall kann aber genutzt werden, um ungenutzte Ports geschlossen zu halten.
  3. Diese Funktion ist erforderlich, um die SSL-verschlüsselten Anfragen zu inspizieren.
  4. Es gibt mit http://www.modsecurity.org/ Möglichkeiten, auch einen IIS besser abzusichern. Allerdings muss man schon selbst die Regeln erstellen.

Unter sicher meint man, dass der Zugriff zum einen autorisierte und authentifiziert sein muss. Sicher bedeutet aber auch, dass die verschiedenen Formen des Missbrauchs wie z.B. Accounts "proben", Lücken ausnutzen etc. verhindert werden. Ein TMG kann die Benutzer authentifizieren und dann anhand der Anmelde dann für bestimmte Ziele autorisieren. Zudem kann TMG selbst die "Anmeldeseite" erstellen und so intern eine "integrierte Anmeldung" in OWA zulassen.

Einschätzung

Aus meiner Sicht ist ARR ein Workaround bei dem eigentlich eine Technik zweckentfremdet wird, die eigentlich für andere Aufgabenstellungen entworfen wurde. Die Gegenüberstellung der Funktionen zeigt schon, dass einige Komponenten von TMG auch mit AAR möglich sind und ARR zum Teil sogar eine Lastverteilung durchführen kann. Allerdings ist ARR keine Firewall und der Schutz des Systems, auf dem ARR selbst installiert ist, wird in keinster Weise von ARR verbessert.

Sie dürfen ARR also auf keinen Fall als irgendwie geartete Firewall ansehen und sollten sich hüten, einen Windows Server mit IIS und ARR ungeschützt aus dem Internet erreichbar zu machen. Davor muss zumindest ein Portfilter sein, der Zugriffe auf andere Ports außer 443 verhindert. Wenn ihnen dann die Funktionen von ARR ausreichen, dann können Sie es vielleicht wagen. Es ist allemal ein Sicherheitsgewinn, wenn durch ARR nur die erlaubten (Whitelist) URLs überhaupt weiter gegeben werden.

Nutzen Sie aber auf jeden Fall alle Mittel einer Überwachung und Konfigurationssicherung. Nicht dass "etwas" oder "jemand" den ARR -Server um neue (unerwünschte) Funktionen erweitert.

Unbeantwortet lassen muss ich die Frage nach der "Zukunftssicherheit". Wer ARR als "halbe Firewall" für OWA einsetzt, muss bei Updates und zukünftigen Versionen immer selbst prüfen, ob die Funktion gegeben ist. ARR als ReverseProxy vor Exchange ist kein von Microsoft "getestetes" Szenario und wollen wir hoffen, dass das IIS-Team diese Funktion in zukünftigen Versionen weiter so bereitstellt, dass es für Exchange genutzt werden kann.

Weitere Links

Keywords:TMG AAR Firewall ReverseProxy OWA