|
|
|
|
|
Schluß mit lustig Teil 2 - das URLScan Tool
Geschrieben von: Christian Holm Von Tag zu Tag werden Viren immer agressiver, hartnäckiger und schwerer zu bekämpfen bzw. abzuwehren. Dies hat sich wieder einmal mit dem Auftauchen des aktuellen Nimda Virus gezeigt. Um Administratoren die Arbeit zu erleichtern und Firmen vor großem Schaden zu bewahren hat Microsoft ein weiteres Sicherheitstool bereitgestellt - das URLScan Tool. Dieses analysiert die Requests auf den IIS Web Server und je nach Konfiguration werden die Requests akzeptiert oder oder verweigert. Dieser Artikel zeigt Ihnen wie man das Tool je nach Firmen-Webseitencontent anpaßt und wie es auf potentielle Attacken reagiert. Viren- oder Wurmattacken sind immer eine Gefahr für einen Web Server. Die letzten Ereignisse in denen der Nimda Virus wieder einmal großen Schaden anrichten konnte, zeigen daß eine sicherheitsbewußte Administration eines Web Servers unabdingbar ist. Die Vielseitigkeit der möglichen Attacken sollten nicht nur aus dem Artikel Schluß mit lustig - das IIS Lockdown Tool bekannt sein. Und die Angreifer, die Viren als ihre "Waffe" verwenden werden leider immer einfallsreicher. Somit ist eine Absicherung eines Web Servers unbedingt notwendig um Ausfälle und ein hohes Schadensausmaß zu vermeiden. Microsoft hat neben dem IIS Lockdown Tool, welches ich Ihnen im Artikel Schluß mit lustig - das IIS Lockdown Tool vorgestellt habe, ein weiteres veröffentlicht - das URLScan Tool. Dieses scannt den einkommenden HTTP Request auf den IIS Web Server und je nach erstellter Konfiguration wird der Request akzeptiert oder für den Fall, daß es sich um einen verdächtigen oder gar um eine Attacke handelt verweigert. Wie schützt das URLScan Tool?Das URLScan Tool ist ein ISAPI Filter, der auf einem Web Server - registriert und ensprechend konfiguriert - die eingehenden HTTP Requests analysiert. Die Analyse besteht aus einer Filterung bzw. Parsing des URLs. Dabei wird jeder URL auf folgendes geprüft:
Alle diese Listenpunkte lassen sich je nach Auflagen dementsprechend konfigurieren. Beginnen wir vorerst mit der Installation. Nach dem Download des URLScan Tools führen Sie die exe-Datei aus dem Verzeichnis aus, in dem Sie die Datei speichern haben lassen. Nach ein paar Klicks (EULA Akzeptierung, etc.) werden die Dateien in ein Standardverzeichnis kopiert - C:\WINNT\system32\inetsrv\urlscan. Diesen Pfad sollten Sie sich merken, da das Tool nur einen Eintrag bei den installierten Programmen erstellt. In den meisten Fällen wird diese Installationsprozedur erfolgreich sein. Falls nicht, können Sie das URLScan Tool auch manuell installieren. Hierfür kopieren Sie die extrahierten Dateien
in das C:\WINNT\system32\inetsrv\urlscan oder ein beliebiges Verzeichnis. Da es sich bei dem Tool um einen ISAPI (Internet Server Application Programming Interface) Filter handelt, ist dieser im ISM (Internet Services Manager) zu registrieren. Öffnen Sie also den ISM und klicken Sie mit der rechten Maustaste auf einen gesamten Server, nicht auf die einzelnen Web Sites. Damit steht der ISAPI Filter für alle Sites zur Verfügung. Für den Fall, daß Sie im ISM mehrere Web Server registriert haben, müssen Sie die Registrierung für den Filter für jeden separat durchführen. Im Kontextmenü wählen Sie den Eintrag Properties (Eigenschaften) aus und klicken in der Sektion Master Properties des WWW Services auf Edit. Im Tab ISAPI Filters klicken Sie auf Add. Im Add-Dialog geben Sie dann im Feld für den Filternamen UrlScan ein und mit Browse verweisen Sie auf den physikalischen Speicherort der urlscan.dll Datei: 
Alles mit OK bestätigen, den IIS neu starten, damit der Filter aktiv wird und wir sind ready for rock n' roll. Nun kann es mit der Konfiguration losgehen. Die standardmäßige Konfiguration mag vielleicht für die meisten Web Server ausreichend sein, wir wollen aber selber überprüfen, ob die Einstellungen auch für unseren Web Server zutreffen. Dazu sehen wir uns die urlscan.ini Datei etwas genauer an. Diese ist fein säuberlich in einzelne Untergruppen (gekennzeichnet durch eckige Klammern) unterteilt. Sehen wir uns zunächst die [options] Sektion an: [options] UseAllowVerbs=1 ; if 1, use [AllowVerbs] section, else use [DenyVerbs] section UseAllowExtensions=0 ; if 1, use [AllowExtensions] section, else use [DenyExtensions] section NormalizeUrlBeforeScan=1 ; if 1, canonicalize URL before processing VerifyNormalization=1 ; if 1, canonicalize URL twice and reject request if a change occurs AllowHighBitCharacters=1 ; if 1, allow high bit (ie. UTF8 or MBCS) characters in URL AllowDotInPath=0 ; if 1, allow dots that are not file extensions RemoveServerHeader=0 ; if 1, remove "Server" header from response EnableLogging=1 ; if 1, log UrlScan activity PerProcessLogging=0 ; if 1, the UrlScan.log filename will contain a PID (ie. UrlScan.123.log) AllowLateScanning=0 ; if 1, then UrlScan will load as a low priority filter. Diese Options Sektion beinhaltet die Flags für die in der Datei nachfolgenden Sektionen. Je nach dem wie das Flag gesetzt wird (0 bzw. 1), werden die enthaltenen Einträge behandelt oder nicht. Praktischerweise stehen die jeweiligen Erklärungen für die Einträge daneben - benötigen also keine weitere Erklärungen. Um Einträge in diesen nachfolgenden Untergruppen zu verändern, löschen Sie Einträge oder fügen neue (ohne vorgehenden Strichpunkt, da sonst Auskommentierung) hinzu. Sehen wir uns dies einmal anhand eines Beispiels an. Wenn Sie auf Ihrem Web Server z.B. die Ausführung von ASP.NET (aspx) Dateien verbieten wollen, dann tragen Sie in der Sektion [DenyExtensions] die Endung .aspx ein: [DenyExtensions] .aspx ; Neuer Eintrag ; Executables that run on the server .exe .bat .cmd .com ... Damit diese Einstellung auch übernommen wird, müssen Sie nach dem Speichern der urlscan.ini Datei den Web Server neu starten, da aus Performancegründen die ini-Datei nur während des Initialisierungsvorganges eingelesen wird. Wenn jetzt ein User auf eine ASP.NET Datei zugreifen möchte, erhält er die simple Meldung: The system cannot find the file specified. Zwecks der Überwachung des Web Servers kann optional die Aktivität des UrlScan Tools mitgelogt werden. Hierfür muß aber in der [options] Sektion das Flag für EnableLogging auf "1" gesetzt sein. Da wir nun mit einem Request versucht haben eine ASP.NET Datei auszuführen, dies aber verweigert wurde, sehen wir uns einmal das Logfile (urlscan.log) an. Dieses enthält neben einer umfangreichen Beschreibung aller eingehenden HTTP Requests auch die aktuellen Einstellungen aus der urlscan.ini Datei. Diese Informationen werden für jeden Initialisierungsvorgang des UrlScan Tools (IIS (Re)Start) eingetragen. Sehen wir uns also so ein Beispiellog für unseren verweigerten Request an: [Wed, Sep 26 2001 - 19:08:02] ---------- UrlScan.dll Initializing ---------- [Wed, Sep 26 2001 - 19:08:02] URLs will be normalized before analysis. [Wed, Sep 26 2001 - 19:08:02] URL normalization will be verified. [Wed, Sep 26 2001 - 19:08:02] URLs may contain OEM, international and UTF-8 characters. [Wed, Sep 26 2001 - 19:08:02] URLs must not contain any dot except for the file extension. [Wed, Sep 26 2001 - 19:08:02] Only the following verbs will be allowed (case sensitive): [Wed, Sep 26 2001 - 19:08:02] 'GET' [Wed, Sep 26 2001 - 19:08:02] 'HEAD' [Wed, Sep 26 2001 - 19:08:02] 'POST' [Wed, Sep 26 2001 - 19:08:02] Requests for following extensions will be rejected: [Wed, Sep 26 2001 - 19:08:02] '.exe' [Wed, Sep 26 2001 - 19:08:02] '.bat' [Wed, Sep 26 2001 - 19:08:02] '.cmd' [Wed, Sep 26 2001 - 19:08:02] '.com' [Wed, Sep 26 2001 - 19:08:02] '.htw' [Wed, Sep 26 2001 - 19:08:02] '.ida' [Wed, Sep 26 2001 - 19:08:02] '.idq' [Wed, Sep 26 2001 - 19:08:02] '.htr' [Wed, Sep 26 2001 - 19:08:02] '.idc' [Wed, Sep 26 2001 - 19:08:02] '.shtm' [Wed, Sep 26 2001 - 19:08:02] '.shtml' [Wed, Sep 26 2001 - 19:08:02] '.stm' [Wed, Sep 26 2001 - 19:08:02] '.printer' [Wed, Sep 26 2001 - 19:08:02] '.ini' [Wed, Sep 26 2001 - 19:08:02] '.log' [Wed, Sep 26 2001 - 19:08:02] '.pol' [Wed, Sep 26 2001 - 19:08:02] '.dat' [Wed, Sep 26 2001 - 19:08:02] Requests containing the following headers will be rejected: [Wed, Sep 26 2001 - 19:08:02] 'translate:' [Wed, Sep 26 2001 - 19:08:02] 'if:' [Wed, Sep 26 2001 - 19:08:02] 'lock-token:' [Wed, Sep 26 2001 - 19:08:02] Requests containing the following character sequences will be rejected: [Wed, Sep 26 2001 - 19:08:02] '..' [Wed, Sep 26 2001 - 19:08:02] './' [Wed, Sep 26 2001 - 19:08:02] '\' [Wed, Sep 26 2001 - 19:08:02] ':' [Wed, Sep 26 2001 - 19:08:02] '%' [Wed, Sep 26 2001 - 19:08:02] '&' [Wed, Sep 26 2001 - 19:14:31] Client at 127.0.0.1: URL contains extension '.aspx', which is disallowed. Request will be rejected. Raw URL='/aspx/file.aspx' Somit wäre eine eventuelle Gefahr abgewandt. Dies war nur ein sehr einfaches Beispiel - natürlich kann der ISAPI Filter auch mit richtig gefährlichen URLs umgehen. Solche Einträge sehen dann so aus: [Wed, Sep 26 2001 - 19:15:01] Client at 127.0.0.1: URL normalization was not complete after one pass. Request will be rejected. Raw URL='/_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe' [Wed, Sep 26 2001 - 19:15:18] Client at 127.0.0.1: URL normalization was not complete after one pass. Request will be rejected. Raw URL='/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe' SchlußbemerkungWie Sie aus diesem Artikel unschwer erkennen können ist das URLScan Tool sehr nützlich und läßt auch die sinnlosesten URLs außenvorne. Da Sie das Tool auch leicht konfigurieren können, kann es leicht an die Firmenvorgaben angepaßt werden. Manche Einstellungen bedürfen jedoch eines eingehenden Verständnisses und sollten nur von erfahrenen Administratoren geändert werden. Daß sich dieses Tool spätestens jetzt auf Ihrem Web Server befinden sollte (es ist kostenlos downloadbar und sicher) brauche ich wohl nicht zu erwähnen. Verwandte Artikel
Der Microsoft Baseline Security Analyzer (MBSA) 1.0 Links zu anderen SitesWenn Sie jetzt Fragen haben...Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.
Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.
Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.
©2000-2006 AspHeute.com |
