MOD_REWRITE mit IIS

Archiv:
Die hier beschriebene Software ist nicht mehr im Internet verfügbar. Die Seite besteht nur noch als "Archiv" für bereits bestehende Installationen. Links zu Alternativen finden Sie am Ende der Seite.

Jeder, der einen Exchange Server betreibt, hat damit auch einen IIS aktiv, welcher manchmal sogar aus dem Internet erreichbar ist. Nun wissen wir alle, dass der IIS zwar umfangreich gesichert werden kann, aber auf der anderen Seite einige Anpassungen nicht so einfach möglich sind. Dies trifft insbesondere auf Exchange zu, da Exchange selbst als ISAPI-Filter in den IIS eingebunden ist und damit die meisten Funktionen des IIS einfach nicht greifen.

Es gibt sehr viele Wünsche und Ideen, OWA auf auch andere Webseiten zu erweitern:

  • Sperren von Verzeichnisse in OWA
    Wie können Sie z.B.: Verhindern, dass Benutzer über OWA auf Ordner zugreifen, in denen Sie eigentlich nur per Outlook mit Ordnerformularen arbeiten?. Ein Zugriff per OWA kann damit ihre komplette Business Logik umgehen und Daten korrumpieren.
  • Einbinden fremder Inhalte
    Was würden Sie sagen, wenn unter http://servername/exchange/USERNAME/portal einfach das Sharepoint Portal ihres Webservers eingebunden wird? Das ganz kann natürlich auch umgekehrt funktionieren, wenn Sie in ihre Webseite einfach z.B. den Exchange Posteingang über eine URL einbinden wollen.

Nur wir kann so etwas realisiert werden ?

Anpassungen von OWA

Sie können über mehrere Wege in OWA eingreifen. Nicht alle Wege offerieren das gewünschte Ergebnis:

  • Anpassung von OWA
    OWA kann mittels Konfiguration (siehe so angepasst werden, dass bestimmte Funktionen ausgeblendet werden. So könnte z.B: der Link zu den Kontakten und Terminen ausgeblendet werden. Allerdings ist das kein Schutz gegen den Zugriff als solches. Wenn ein Anwender den Link kennt, kann er sehr wohl auf die Daten zugreifen. Daher ist dies kein hinreichender Schutz.
  • Steuerung bei der Webveröffentlichung
    Eine zweite Funktion wäre die Kontrolle der von Client erreichbaren URL’s. So könnte eine Firewall oder Reverse Proxy z.B.: nur „..../exchange/*/Posteingang/*“ (o.ä.) passieren lassen. Meist ist die Filterfunktion solcher Gateways aber nicht ausreichend.
  • IIS-Beschränkungen
    Von Hause aus erlaubt der IIS keine Filterung von URLs vor der Verarbeitung. Da die Funktion „OWA“ selbst als ISAPI-Filter realisiert ist, können auch keine ASP-Seiten o.ä. angepasst werden, wie die mit Exchange 5.5 möglich gewesen wäre.

Vieles wäre aber möglich, wenn es denn für den IIS ein Modul geben würde, welches bei Apache schon lange vorhanden ist. Ich spreche von MOD_REWRITE, was letztlich eine Methode ist, URLs, die vom Client zum Server gesendet werden mit regulären Ausdrücken zu verändern, ehe diese dann durch den eigentlichen Webserver verarbeitet werden.

Auch wenn der IIS sehr umfangreich durch virtuelle Verzeichnisse, Application Pools etc. zu konfigurieren ist, so können eingehende URLs nicht vorgefiltert werden. URLSCAN zeigt, wie durch einen ISAPI-Filter z.B. Unerwünschte Erweiterungen und Befehle geblockt werden können. Eine kurze Suche im Internet ergab, dass es mehrere Produkt gibt, die diese Funktion beim IIS zur Verfügung stellen.

Vorsicht bei bestimmten Verzeichnissen
Die Funktion URLs zu "verändern" kann sehr schnell auch zur Funktionsstörung führen. Sehr viele Programme nutzen z.B. /Exchange für Zusatzdienste (Mailboxreports, Auswertungen, ActiveSync etc.) so dass Einschränkungen hier oft auch andere Folgen nach sich ziehen. Auch Verzeichnisse wie EXAdmin und ExchWeb sind mit Vorsicht zu betrachten

Reguläre Ausdrücke mit MOD_REWRITE (IISMODS)

MOD_REWRITE funktioniert mit regulären Ausdrücken. Dabei werden bestimmte Muster gesucht und ersetzt. Daher ist zuerst ein regulärer Ausdruck zu erstellen, welche den Anforderungen entspricht. Folgender Ausdruck erlaubt nur den Zugriff auf die Ordner Posteingang, Postausgang, Gesendete Objekte, Gelöschte Objekte, Entwürfen und Kommandofunktionen von OWA. (Der Ausdruck wurde zur Lesbarkeit in mehrere Zeilen aufgetrennt. Der Ausdruck ist etwas komplexer, da eine Kurzform fehlerhaft wäre. Speziell der Ausdruck„.*“ steht für jede beliebige Zeichenkette und damit auch für „/Kalender“)

^/exchange(
$1
|/$
|/[^/]*$
|/[^/]+/$
|/[^/]*/Posteingang.*
|/[^/]*/Postausgang.*
|/[^/]*/Gesendete%20Objekte.*
|/[^/]*/Entw%C3%BCrfe.*
|/[^/]*/\?Cmd=.*)

Der reguläre Ausdruck prüft also mehrere „ODER“-verknüpfte Bedingungen ab. Wenn einer zutrifft, ersetzt MOD_REWRITE diesen Ausdruck. So sind folgende URLs erlaubt.

/exchange
/exchange/
/exchange/USERNAME
/exchange/USERNAME/
/exchange/USERNAME/Posteingang
/exchange/USERNAME/Posteingang/*
/exchange/USERNAME/Postausgang
/exchange/USERNAME/Postausgang/*
/exchange/USERNAME/Gesendete Objekte
/exchange/USERNAME/Gesendete Objekte/*

Folgende URLs sind z.B.: nicht erlaubt

/exchange/USERNAME/Kalender
/exchange/USERNAME/Kalender/*

Zudem sind für die Funktion von OWA noch weitere Pfade erforderlich, z.B.:

  • /exchange/USERNAME/?cmd=content
    Für die Anzeige der Iconleiste am linken Rand
  • /exchange/USERNAME/?cmd=galsearch
    Für die Suche im Adressbuch

Insofern ist speziell beim Einsatz von MOD_REWRITE ein gutes Verständnis der „Nutzung“ von Outlook Web Access erforderlich. Planen Sie daher ausreichend Zeit für Tests ein. Bei der Analyse und Fehlersuche sind die die Diagnosefunktionen von MOD_REWRITE und das IISLog.

MOD_REWRITE erlaubt so sehr einfach und sicher den Zugriff auf bestimmte URLs komplett zu sperren, selbst wenn andere ISAPI-Filter wie Exchange keine Sperre zulassen. Allerdings ändert sich dadurch nicht das Layout und Design der Webseite, d.h. Links auf solche gesperrte Bereiche werden nicht automatisch entfernt. Eventuell sind daher eigene Frameseiten zu erstellen

Konfigurationsdatei für MOD_REWRITE

Ausgehend von dem regulären Ausdruck kann nun die Konfigurationsdatei erstellt werden. Es gibt mehrere Hersteller einer DLL für die Nachrüstung der MOD_REWRITE-Funktion für den IIS. Da alle bei Apache quasi abgeschaut haben, sind für alle die Konfigurationsdateien auch sehr ähnlich.

Ich beschreibe hier URL Rewrite für IIS (http://www.iismods.com/URL-rewrite/index.htm), welches Open Source und kostenfrei für privaten und gewerblichen Einsatz ist. Auch die Lite-Version von www.isapirewrite.com ist kostenfrei.

Der Inhalt der Date MOD_REWRITE.INI enthält folgende Zeilen (Achtung Zeilenumbruch. Es sind zwei Zeilen):

Debug 0
Reload 5000
RewriteRule ^/exchange($|/$|/[^/]*$|/[^/]+/$|/[^/]*/Posteingang.*|/[^/]*/Postausgang.*|/[^/]*/Gesendete%20Objekte.*|/[^/]*/Entw%C3%BCrfe.*|/[^/]*/\?Cmd=.*) /exchange$1 {l]
RewriteRule ^/exchange/(.*) /error.htm

Die Bedeutung der Zeilen im einzelnen:

  • Debug 0
    Wird hier eine 1 eingesetzt, dann protokolliert MOD_REWRITE die erhaltenen URLs und dazugehörigen Ersetzungen einfach in MOD_REWRITE.TXT. Diese Funktion sollte nur auf einem Testsystem oder einer eigenen virtuellen Webseite zum Test aktiviert werden, damit die Last des Webserver nicht zu hoch wird
  • Reload 5000
    Dieser Parameter bestimmt, nach wie vielen Request die DLL die Konfiguration nachlädt. Da auch das Nachladen CPU-Leistung kostet, sollte dieser Wert nur für Testzwecke sehr niedrig gesetzt werden. So kann aber die Konfiguration geändert werden und wird ohne Neustart des IIS nach einiger Zeit aktiv. (Primäre gedacht für Webhoster, so dass Kunden die Konfiguration ändern können)
  • RewriteRule expression1 expression2 Options
    Diese Zeile kann mehrfach vorkommen und steuert das Verhalten von MOD_REWRITE. Jede eingehende URL wird gegen den Ausdruck „expression1“ evaluiert und wenn er zutrifft, wird er durch expression2 ersetzt. Die Optionen erlauben eine weitere Steuerung. Das „[l] bewirkt, dass die nachfolgenden Zeilen nicht mehr ausgeführt werden.

Die zweite RewriteRule sorgt dafür, dass alle anderen URLs des Ausdrucks auf eine Fehlerseite verwiesen werden.

Achtung Case sensibel
Reguläre Ausdrücke als auch URLs sind case sensibel, d.h. berücksichtigen Sie dies bei der Planung. In der Windows Welt macht es meist keinen unterschied, ob Klein oder Großbuchstaben verwendet werden. Die ist hier nicht so.

Hinweis
MOD_REWRITE ändert nicht die Elemente der Webseite, d.h. auch wenn z.B. die Kontakte nicht mehr erreichbar sind, so sind in OWA die Links doch noch sichtbar. MOD_REWRITE erlaubt aber die umlenkung beim Zugriff auf eine eigene Fehlerseite (hier „/error.htm“)

Ich hatte wiederholt Stabilitätsprobleme mit MOD_Rewrite. Nach dem Wechsel auf die Lite-Version von ISAPIREWRITE waren die Fehler weg. Testen Sie daher die Funktion mit WebStress oder anderen Lastgeneratoren.

Download, Installation und Einbindung

Die Installation und Einrichtung geht sehr einfach:

  • Download und Installation
    Zuerst muss der Code für MOD_REWRITE aus dem Internet bezogen werden
    http://www.iismods.com/downloads/mod_rewrite.zip
  • Installation = Auspacken
    Die Installation beschränkt sich auf das Auspacken der DLL und INI-Datei ein Verzeichnis ihrer Wahl. Nur der IIS muss dieses Verzeichnis lesen können. Es sollte daher z.B. nicht unter wwwroot oder einem anderen "veröffentlichten" Verzeichnis liegen. Denkbar ist z.B.: ein unterverzeichnis im Programmverzeichnis oder System32, wie URLSCAN es vormacht.
  • Virtuelles Verzeichnis
    Legen Sie mit dem Exchange System Manager ein weiteres virtuelles Verzeichnis für den Einsatz von MOD_REWRITE an. Vermeiden Sie bitte die direkte Filterung von /exchange, da dieses Verzeichnis auch von anderen Diensten (ActiveSync etc.) genutzt wird.
  • Error.htm
    Wird MOD_REWRITE genutzt, um Seiten zu verbieten, sollte eine passende Fehlerseite angelegt und in MOD_REWRITE konfiguriert werden, auf die der Anwender dann umgelenkt wird.
  • Filterdatei speichern
    Erstellen/Pflegen Sie die Filterdatei für MOD_REWRITE. Speichern Sie diese Datei im gleichen Verzeichnis wie die DLL.
  • ISAPI-Einbinden
    In der Webseite des IIS muss der ISAPI-Filter eingebunden werden. Gehen Sie dazu auf den Eigenschaften der Webseite auf die Karteikarte ISAPI-Filter und fügen dort den Filter hinzu:
  • IIS Webseite neu starten.
    Erst nach dem Neustart der Webseite wird der ISAPI-Filter auch geladen.
  • ISAPI-Reihenfolge
    Kontrollieren Sie, dass der ISAPI-Filter MOD_REWRITE geladen wurde und die Reihenfolge korrekt ist.

    Filter wie URLScan werden meist davor stehen während Filter wie Exchange, RSA etc. meist dahinter stehen werden

Weitere Links