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.

Ich würde heute AAR nicht mehr einsetzen, sondern einen anderen Reverse Proxy, Loadbalancer oder notfalls WAP - Web Application Proxy nutzen.

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.

  • Mehr WebServer
    In der ersten Stufe werden Sie anfangen, mehrere WebServer zu betreiben, auf den der gleiche Inhalt liegt. Die Clients werden per DNS-Round-Robin und Loadbalancer entsprechend auf verfügbare Server verteilt. Das funktioniert noch gut mit statischen und lokal auf den Servern gerechneten Inhalten oder wenn die Aufbereitung der Daten auf mehrere Lasten verteilt werden soll
  • Daten von Layout trennen
    Aber immer mehr Systeme nutzen eine SQL-Datenbank im Hintergrund zum Ablegen der Informationen. Der Webserver holt die Inhalte und bindet sie mit lokal vorliegenden HTML-Seiten, CSS Style Sheet und Bildern zusammen. Alle Webserver greifen auf die gleichen Datenbestände zu.
  • Skalierung im Backend über verschiedene Datenbankserver
    Sollte das Backend nun zum Engpass werden, dann wäre es eine Lösung, z.B. verschiedene Anwendungen (Datentöpfe) auf verschiedene Server zu legen und so ein ScaleOut zu fahren. Wer mehrere Anwendungen unter einen Namen bereit stellt, kann so arbeiten.

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:

  • Ein Hostname, verschiedene Contentserver
    Mittels ARR kann man einzelne Pfade einer Webseite von verschiedenen Content-Servern abfragen. für den Client wird gar nicht ersichtlich, dass die Daten von unterschiedlichen internen Servern kommen. Entsprechend reicht auch ein Zertifikat und viele Funktionen des Clients arbeiten ohne Probleme, z.B. einbinden von Inhalten per IFRAME, die bei anderen Host/Domänennamen oft eine Warnung ausgeben. Auch muss man beim Einsatz von SSL eben nur einen Hostnamen absichern.
  • Caching
    Der ARR-Server kann erhaltene Daten, sofern sie eine gewisse Beständigkeit haben, selbst cachen und bei wiederholtem Aufruf die Daten wieder ausliefern. Es muss natürlich etwas der Content-Webserver mitspielen, der für die ausgelieferten Informationen eine Cache-Policy mitgeben muss. Aber so können die Content-Server von statischen Inhalten entlastet werden, ohne dass man diese unter einem anderen Hostnamen daneben betreiben muss
  • Geolocation
    Da keiner der ARR-WebServer eigenen "Content" vorhält aber als Cache dient, kann man diese auch geografisch verteilen. Über entsprechende DNS-Funktionen können die Clients dann auf das ARR-Serverarray geleitet werden, die netztechnisch nahe beim Client sind. Der erreichte AAR-Server bedient die Anfragen dann soweit möglich aus dem Cache und leitet dynamische Abfragen dann zum Content-Server weiter. Auf dem ARR-Server gib es aber nicht zu "pflegen", da der Cache dynamisch verwaltet wird. Das ist z.B. eine Option um Download-Netzwerke analog zu AKAMAI u.a. zu betreiben.
  • Ein WebServer zum Client

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 Reverse-Proxy, 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.

  • Authentifizierung
    ARR bietet keine „FormBased“ Authentication a la TMG an. Man muss also die Zugriffe „Anonym“ durchlassen und erst der Exchange macht dann die Anmeldung.
    Für Lync ist das kein Problem, da er kein „Formular“ hat und die Dienste durch die Trennung nach „InternalWeb“ und „ExternalWeb“ auch applikationstechnisch getrennt sind
    Aber bei Exchange gibt es nur einen IIS indem alle Dienste laufen
    Zudem kann man ohne „vorgelagerte“ Anmeldung natürlich intern die Formularanmeldung mal nicht einfach abschalten. Man muss also manuell eigene OWA-Webs anlegen. Problem nur, dass bestimmte URLs nur einmal auf dem Server und in der Default Webseite liegen können.
    Auch wenn durch ARR nur Anfragen auf freigeschaltete URLs durchkommen, so bleibt doch einiges an Störpotential, die bislang ein TMG wegfiltern konnte.
  • Authentifizierung
    Aber selbst wenn man den Zugriff auf ARR per IIS authentifizieren will, so kommt hier wieder das "Double Hop" Problem beim Einsatz von NTLM zu tragen und Kerberos Delegation. Oft wird einfach empfohlen, dass ARR die Zugriffe "anonym" zum Contentserver durchreicht.

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

  • Schutz des IIS selbst ist kritisch
    Damit stellt man natürlich einen IIS „in die erste Reihe“. Wenn man sonst keinen ReverseProxy hat, dann ist der maximal durch NAT und Portfiltering (443) gesichert. Aber technisch sind alle URLs auf dem IIS dann auch von extern erreichbar.
    Die Sicherheit hängt also davon ab, dass der Admin keine zusätzlichen URLs oder Erweiterungen installiert. Idealerweise also einen IIS, der nur ARR macht und kein ASP, ASPX, PHP etc. anbietet. Und auch nicht irgendwann mal nachinstalliert bekommt.
    Das ist nicht ganz einfach und ich habe da durchaus auch meine Erfahrungen mit.
    Was eine „nicht genutzte“ aber auch nicht deaktivierte PHP4 Funktion auf einem Apache bewirken kann habe ich auf http://www.msxfaq.de/sonst/msxfaqorghack.htm beschrieben. Ein IIS ist da nicht viel anders zu sehen
  • Komplex
    Die Konfiguration von ARR ist nicht jedermanns Sache. Es gibt (noch) keinen Assistenten für Exchange oder Lync und die Steuerung über reguläre Ausdrücke ist fehleranfällig.

Sicherheit

Wer z.B. Exchange OWA sicher veröffentlichen will, muss mehrere Aspekte beleuchten. die verschiedenen Punkte bedeuten:

  • NAT - Network Address Translation
    Zugriffe auf die offizielle IP-Adresse:443 werden durch einen Router 1:1 auf die interne private Adresse umgesetzt. Der primäre Schutz ist, dass von extern nur die ausgewählten Ports überhaupt durchgereicht werden. Weitere Inspektionen auf das Protokoll gibt es nicht.
  • ARR
    Diese Spalte bezeichnet die Funktion des IIS Application Routing
  • TMG
    Auch wenn das Microsoft Thread Management Gateway (TMG) mittlerweile nicht mehr gekauft werden kann, gibt es sicher noch sehr viele Installationen und ich habe dessen Funktion hier mit beschrieben
  • UAG
    Das unified Access Gateway ist eine Übermenge des TMG und erfüllt die gleichen Anforderungen. Allerdings ist die Lizenzierung deutlich teurer
  • Win2012WAP (Windows 2012SP2 Web Application Proxy)
    Mit Windows 2012 SP2 wird eine neue Rolle im Betriebssystem enthalten sind, die eine Veröffentlichung von internen Diensten erlauben wird.

Und dann habe ich extra eine Spalte gelassen, in der Sie ihre eigene Lösung bewerten können, z.B. eine vorhandene Firewall, ein Apache oder Squid o.ä.

Funktionalität NAT ARR TMG UAG Win2012
WAP		 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

Ja

Ja ?

 

Autorisierung
Anhand der nun bekannten Identität kann das System festlegen, welche Dienste der Anwender nun nutzen kann

Nein

Nein

Ja

Ja

Ja ?

 

Schutz gegen Account ausspähen/proben

Nein

Nein

Ja (1)

Ja (1)

?

 

Schutz gegen Zugriff auf nicht gewünschte URLs

Nein

Ja

Ja

Ja

Ja ?

 

Schutz gegen Portscan und Zugriff auf Dienste auf anderen Ports

Ja

Nein(2)

Ja

Ja

?

 

Schutz gegen bestimmte "Muster" in URLs, z.B. "*.php" oder "*/cgi-bin/*"

Nein

Ja

Ja

Ja

Ja ?

 

SSL Offloading zur Lastreduzierung und erforderlich, um URLs zu filtern.

Nein

Ja (3)

Ja (3)

Ja (3)

Ja ?

 

Lastverteilung Auf mehrere Backend-Systeme mit Client Affinity

Nein

Cookie

Ja

Ja

Ja ?

 

HealthCheck der Backend Server

Nein

Ja

Ja

Ja

Ja ?

 

Graceful Shutdown, d.h. beim Einsatz als Loadbalancer einen Content-Server frei schalten

Nein

Ja

Ja

Ja

Ja ?

 

URL "Firewall"

Nein

Nein (4)

Ja

Ja

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 (Allowlist) 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 Reverse Proxy 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