ISA Server FAQ Home | ISA 2000 | ISA 2004 | ISA 2006 | TMG | Verschiedenes | Tools | Downloads | Links | Das Buch! | Bücher | User Group | Events | Blog | About | Sitemap | Suche

Kapitel höher
POP3 für Clients
Serververöffentlichung ohne SNAT
IE auf ISA
RPC over HTTPS
HTTP Filterung
DNS Server
OWA mit LDAP
Kennwortänderung mit LDAP
Cloudmark Antigen Engine

 

ISA Server 2006 – HTTP Filter - Von Marc Grote


Die Informationen in diesem Artikel beziehen sich auf:

  • Microsoft ISA Server 2006

 

Einleitung

 

In diesem Artikel erläutere ich die Konfiguration des mit ISA 2006 mitgelieferten HTTP Filters und die interne Funktionalität. Für eine effiziente Arbeit mit dem HTTP Filter müssen Sie die Funktionsweise des HTTP Protokolls in den Grundzügen verstehen. Lesen Sie dazu bitte folgenden Artikel.

 

Was ist ein Webfilter / HTTP-Filter?

 

Bei einem Webfilter handelt es sich um DLLs (Dynamic Link Libraries), welche auf dem IIS ISAPI (Internet Server Application Programming Interface) Modell basieren. Webfilter werden vom Webproxy Filter geladen. Wenn ein Webfilter geladen wurde, werden diese Informationen an den Webproxy Filter von ISA Server 2006 weitergeleitet. Dieser legt fest, welche Typen von Ereignissen überwacht werden sollen. Jedes Mal wenn ein solches Ereignis eintritt, wird der Webfilter benachrichtigt.


Die folgende Grafik zeigt den HTTP-Filter in den Add-Ins von ISA Server 2006.

 

 

Webfilter Funktionalität

 

Der Webfilter im ISA Server 2006 hat folgende Aufgaben:

  • HTTP Anforderungen scannen und modifizieren

  • Datenverkehr analysieren und protokollieren

  • HTTP Antworten scannen und modifizieren

  • Blockieren von speziellen HTTP Antworten

  • Datenverschlüsselung und Komprimierung

  • Benutzerdefinierte Authentifizierungsschemata (RADIUS, OWA, RSA SecurID) zur Verfügung stellen

Wie funktioniert ein Webfilter in ISA Server 2006

  • Ein Client stellt eine Verbindung zu ISA Server 2006 her und fordert eine Ressource aus dem externen Netzwerk an.

  • Die Firewall Engine (FWENG.SYS) führt eine Paketfiltering für die Anfrage durch und prüft, ob die Anforderung auf dieser Ebene erlaubt ist.

  • Wenn die Anforderung erlaubt ist, wird eine Verbindung mit dem Firewall Dienst hergestellt.

  • Der Firewall Dienst überprüft die Firewallregel, ob ein Anwendungs- oder Webfilter für die Regel definiert ist.

  • Wenn das der Fall ist (HTTP/HTTPS), übergibt der Firewall Dienst die Anforderung an den  Webproxy Filter.

  • Die Anfrage wird basierend auf der Webfilter Konfiguration überprüft. Der Webfilter erlaubt oder verweigert die Anforderung.

  • Wenn die Anfrage vom Webfilter akzeptiert wurde, wird die Anfrage zurück an den Firewall Dienst übergeben und über das externe Netzwerkinterface an den Zielserver weitergeleitet.

Wichtig:

 

Der HTTP-Filter in ISA Server 2006 ist regelspezifisch, dass heißt, Sie können den HTTP Filter pro Firewallregel konfigurieren.

Einzige Ausnahme von der Regel: Die Angabe der maximalen Header-Länge im Feld Anwendungsheader ist für alle HTTP-Richtlinien gültig. Eine Änderung die Sie hier vornehmen, gilt für alle Firewallrichtlinien.

 

 

Bemerkung:

 

Der HTTP Filter in ISA Server 2006 kann auch HTTPS Datenverkehr filtern, wenn es sich bei dem Datenverkehr um eine sichere Webserververöffentlichung handelt, bei der die Anfrage im so genannten Bridge Mode betrieben wird. Im Bridge Mode wird die HTTPS Anfrage am ISA Server aufgehoben und vom ISA Server erneut SSL verschlüsselt und an den Client (z. B. internen Webserver gesendet). Im SSL Tunnelmodus (explizite SSL Verbindung zwischen Client und externem Server) ist keine Webfilterung möglich. Sie müssen dazu Software von Drittanbietern verwenden. Ausgehende HTTPS-Anfragen können seit einiger Zeit auch mit Hilfe zu Zusatzsoftware

 

HTTP Filter Konfiguration

 

Klicken Sie jetzt auf "HTTP konfigurieren" in der entsprechenden Firewallregel.

 

 

Anforderungsheader:

 

Maximale Headerlänge (Bytes): Gibt die maximale Anzahl an Bytes im Header (URL und Header) für einen HTTP Request an, bevor die Anfrage geblockt wird. Starten Sie mit einem Limit von 10.000 Bytes und erhöhen Sie den Wert nur, wenn Sie Probleme bei dem Aufrufen von Webseiten feststellen.

 

Anforderungsnutzlast:

 

Maximale Nutzlastlänge (Bytes): Standardmäßig wird jede Nutzlastlänge zugelassen, sie können die Länge aber auch auf Anzahl XX Bytes beschränken. Mit Hilfe dieses Parameters können Sie die Anzahl der Daten beschränken, welche ein Benutzer per HTTP POST an Ihre Webseite in einem Webserververöffentlichungsszenario überträgt.

 

URL-Schutz:

 

Maximale URL-Länge (Bytes): Spezifiziert die maximale Länge einer erlaubten URL. Der Default Wert ist 10.240 Byte. Reduzieren Sie die Länge nur, wenn ein Angriff mit überlangen URLs bekannt wird.

Maximale Abfragelänge (Bytes): Spezifiziert die maximale Länge einer URL Abfrage. Eine URL Abfrage erkennen Sie an den Zeichen nach dem ? in einer URL

Normalisierung verifizieren: Webserver empfangen Anfragen, welche als URL kodiert sind, dass heißt, diese Anfragen können auch Zeichen enthalten, welche mit einem % Zeichen, gefolgt durch eine Nummer, ersetzt werden müssen. Als Normalisierung bezeichnet man den Prozess der Decodierung von URL kodierten Anfragen. Weil das % Zeichen selbst URL kodiert sein kann, kann ein Angreifer einen URL Request an einen Webserver schicken, welcher doppelt kodiert ist. Wenn Sie "Normalisierung verifizieren" ausgewählt haben, normalisiert der HTTP Filter die URL doppelt und wenn er beim zweiten mal einen Unterschied in der URL feststellt, wird der Request verworfen.

High Bit Zeichen sperren: URLs welche Double Byte Character (DBCS) oder Latin1 enthalten, werden geblockt wenn diese Einstellung aktiv ist. Das sperrt in der Regel Sprachen, welche mehr als 8 Bit (also 16 Bit) zur Darstellung aller Zeichen Ihrer Sprache benötigen. Seien Sie mit der Aktivierung dieses Features vorsichtig, gerade in OWA Szenarien führt das unter Umständen zu Problemen.

 

Eine Empfehlung zur Einrichtung der entsprechenden Parameter für unterschiedliche Veröffentlichungszenarien finden Sie hier.

 

Ausführbare Dateien

 

Antworten sperren, die von Windows ausführbaren Inhalt enthalten: Diese Option blockiert sämtlichen von Windows ausführbaren Inhalt (Antworten welche mit einem MZ (z. B. EXE) beginnen). Der HTTP Filter erkennt hier übrigens auch umbenannte EXE Dateien in z. B. .DOC Dateien anhand des MIME Types.

 

Als nächstes können Sie die zugelassenen HTTP-Methoden konfigurieren.

 

 

Beispiele für HTTP Methoden:

 

GET - Empfängt die spezifizierte URI

HEAD - Empfängt nur den Header im URI

POST - Fragt den Server an, die Informationen zu akzeptieren

PUT - Fragt den Server an, die Informationen und den spezifizierten URI zu akzeptierenj

DELETE - Fragt den Server an, die spezifizierte URI zu löschen

 

In diesem Beispiel werden HTTP-Anfragen mit der HTTP PUT Methode geblockt.

 

 

Mit Hilfe des geblockten HTTP PUT können interne Clients keine Daten mehr zu externen Webseiten posten. Das kann sinnvoll sein um zu verhindern, das sensitive Informationen nicht auf anderen Webseiten veröffentlicht werden können, aber auch in Webveröffentlichungsszenarien kann dieses Feature sinnvoll sein um zu verhindern, dass Angreifer Malicious Informationen auf der internen Webseite posten können.

 

Dateiendungen sperren

 

Mit Hilfe der Möglichkeit zur Sperrung von bestimmten Dateiendungen im HTTP Filter, können Sie einfach und effektiv zum Beispiel das Downloaden von .EXE Dateien verhindern.

 

 

Anforderungen sperren, die mehrdeutige Erweiterungen enthalten, blockiert alle Extensionen, bei welchen der ISA Server die Erweiterung nicht bestimmen kann.

 

In diesem Beispiel blocken wir den Zugriff auf .EXE Dateien.

 

 

Wie arbeitet der ISA Server 2006 HTTP Filter Dateiendungen ab:

 

Wenn die Filterung basierend auf Dateiendungen aktiviert ist, überprüft der HTTP Filter jede Anfrage basierend auf der Dateierweiterung.

ISA Server interpretiert eine Dateiendung in einer URL nach dem letzten darin enthaltenen Punkt und einem / oder ? oder dem Ende einer URL wenn kein / oder ? enthalten ist.

Zusätzlich versucht der HTTP Filter Zeichen, welche einem Punkt folgen, als Dateierweiterung zu erkennen (z. B. DLL , EXE oder COM).

Wenn mehrere dieser Zeichen in einer URL enthalten sind, evaluiert ISA nur die erste Extension.

 

Um das zu verdeutlichen, einige Beispiele:

 

http://server/pfad/datei.ext                                      .ext wird geblockt
http://server/pfad.exe/datei.ext                                .exe wird geblockt

http://server/pfad/datei.htm/subpfad//msisafaq.asp   .asp wird geblockt
 

Um im zweiten Beispiel auch die .EXT Erweiterung zu verweigern, erstellen Sie eine Signatur, welche die .EXT Erweiterung in der URL verweigert.

 

HTTP Header Behandlung

 

Wenn ein Client eine Anforderung an den Webserver sendet oder der Webserver antwortet, ist der erste Part einer solchen Antwort immer ein HTTP Request oder HTTP Response.

Nach dem HTTP Request oder Response, sendet der Client oder der Server einen HTTP Header. Das Request Header Feld erlaubt dem Client zusätzliche Informationen über den Request an den Server mitzugeben.

Headers enthalten Informationen über den Client (Browser und Betriebssysteminformationen, Autorisierungsinformationen und weitere). Der Client Header verwendet auch das Attribut User-Agent mit welchem bestimmt werden kann, welche Applikation die Anforderung durchführt.

 

Mit Hilfe des HTTP Filters können jetzt z. B. bestimmte HTTP-Header geblockt werden.

 

 

Sie können im Feld Serverheader auch noch festlegen, ob der Header aus der Antwort gelöscht werden soll oder der Header in der Antwort bearbeitet werden soll.

 

In diesem Beispiel wird der HTTP Header für Kazaa geblockt. Somit werden Anforderungen, welche im Anforderungsheader diesen HTTP-Header enthalten, blockiert.

 

 

HTTP Filter Signaturen

 

Eine HTTP Signatur kann jedes Zeichen in einem HTTP Body oder HTTP Header sein.

Sie können HTTP Signaturen dazu verwenden, zum Beispiel die Ausführung von Anwendungen zu verhindern. Um eine HTTP Signatur zu ermitteln, müssen Sie wissen, welche Muster die Applikation im Request Header, Response Header und Body verwendet und dann eine Signatur erstellen, welche Pakete basierend auf diese Zeichenfolge blockiert.

 

Die Schwierigkeit ist es, eine Signatur zu erstellen, die wirklich nur "schadhafte" Aufrufe blockiert. Wenn Sie zum Beispiel eine Signatur erstellen, welche das Wort Mozilla blockiert, werden die meisten Webbrowser und Applikationen blockiert, weil die meisten Browser Mozilla kompatibel sind und diese Informationen in der HTTP-Antwort übermitteln.

 

Um die Nutzung des MSN Messenger zu blockieren, konfigurieren Sie den User-Agent:MSN Messenger in einem Request Header.

 

Sie können aber auch den Zugriff auf Webseiten mit bestimmten Malicious Code verbieten indem Sie z. B. die Zeichenfolge <iframe src="?"/> blockieren. Diese Zeichenfolge veranlasst den Internet Explorer CPU Ressourcen zu verwenden.

 

Wichtig:

 

Die Filterung von HTTP-Signaturen funktioniert nur, wenn die Anfragen und Antworten UTF-8 (eine Transformation von Unicode) codiert sind. Wird ein anderes Kodierungsschema verwendet, kann keine Blockierung von Signaturen durchgeführt werden.

 

 

In folgendem Beispiel wird die Ausführung des MSN Messenger mit Hilfe einer HTTP Signatur geblockt.

 

 

Zum Glück müssen Sie nicht jede HTTP-Signatur  selbst erstellen. Sie können im Internet diverse Filter Signaturen downloaden. Achten Sie beim Download jedoch darauf, dass diese Informationen aus vertrauenswürdigen Quellen stammen.

 

Sie finden hier eine Übersicht über ISA Server 2004/6 HTTP Filter Signaturen.

Eine Übersicht über typische Applikations-Signaturen finden Sie hier.

 

Wichtig:

 

Standardmäßig überprüft der HTTP-Filter nur die ersten 100 Bytes im Anforderungs- oder Antwort Body. Sie können den Wert erhöhen. Beachten Sie dabei allerdings, dass die Performance von ISA Server 2006 darunter leiden kann.

 

Ergebnis einer geblockten Verbindung durch den HTTP-Filter von ISA Server 2006



Anmerkung:
In der obigen Grafik wurden Informationen wie IP-Adresse, Ursprungsanfrage etc. aus Datenschutzgründen entfernt.

 

Ermittlung von HTTP Anwendungsignaturen

 

Zur Ermittlung von HTTP Anwendungssignaturen, die Ihnen nicht bekannt sind, können Sie den Windows eigenen Netzwerkmonitor verwenden und den Netzwerkverkehr sniffen.

Die folgende Grafik zeigt ein Beispiel für einen Netzwerktrace mit dem in Windows 2000/2003 verfügbaren Netzwerkmonitor. Sie können natürlich auch jeden anderen Netzwerkmonitor, zum Beispiel Wireshark (ehemals Ethereal) verwenden.

 

Dieses Beispiel zeigt den HTTP Request Typen (GET), den HTTP Request Header (HTTP/1.1) den User-Agent (Mozilla/4.0) und die Signatur (MSIE 6.0).

 

HTTPFILTERCONFIG.VBS

 

Verwenden Sie HTTPFILTERCONFIG.VBS aus dem Verzeichnis C:\PROGRAMME\MICROSOFT ISA SERVER 2006 SDK\SDK\SAMPLES\ADMIN aus dem ISA Server 2006 SDK um HTTP-Filter zu importieren und zu exportieren.

 

 

 

 

 

Stand: Friday, 28. August 2009/MG. http://www.it-training-grote.de


Home | ISA 2000 | ISA 2004 | ISA 2006 | TMG | Verschiedenes | Tools | Downloads | Links | Das Buch! | Bücher | User Group | Events | Blog | About | Sitemap | Suche

Fragen oder Probleme in Zusammenhang mit dieser Website richten Sie bitte an den Webmaster. Bitte inhaltliche oder technische Fragen ausschließlich in der deutschen ISA Server Newsgroup stellen.
Verbesserungsvorschläge, Anregungen oder Fremdartikel sind jederzeit willkommen! Copyright 2001-2009. Alle Rechte vorbehalten. msisafaq.de steht in keiner Beziehung zur Microsoft Corp.
Stand: Saturday, 19. June 2010 / Dieter Rauscher