Konfigurieren des Dienstprogramms "URLScan"

Dieser Artikel beschreibt Schritt für Schritt die Konfiguration des Programms "URLScan", um Ihren Webserver vor Angriffen und Sicherheitsanfälligkeiten zu schützen.

Installieren von URLScan

Besuchen Sie die folgende MSDN-Website, um "URLScan" zu installieren: Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

Ändern der Datei "URLScan.ini"

Die gesamte Konfiguration von URLScan wird über die Datei "URLScan.ini" durchgeführt, die sich im Ordner "%WINDIR%\System32\Inetsrv\URLscan" befindet. Um URLScan zu konfigurieren, öffnen Sie diese Datei in einem Texteditor wie z. B. Editor, führen Sie die entsprechenden Änderungen durch, und speichern Sie anschließend die Datei.

Hinweis: Sie müssen Internetinformationsdienste (IIS) neu starten, damit Ihre Änderungen wirksam werden. Eine Möglichkeit, dies schnell zu tun, ist die Ausführung des Befehls IISRESET an einer Eingabeaufforderung.

Die Datei "URLScan.ini" enthält folgende Abschnitte:

• [Options]: Dieser Abschnitt beschreibt die allgemeinen Optionen von URLScan.
• [AllowVerbs] und [DenyVerbs]: Diese Abschnitte definieren die Verben (auch bekannt als HTTP-Methoden), die URLScan zulässt.
• [DenyHeaders]: Dieser Abschnitt führt die HTTP-Header auf, die in einer HTTP-Anforderung nicht erlaubt sind. Wenn eine HTTP-Anforderung einen der in diesem Abschnitt aufgelisteten HTTP-Header enthält, lehnt URLScan die Anforderung ab.
• [AllowExtensions] und [DenyExtensions]: Diese Abschnitte definieren die Dateinamenerweiterungen, die URLScan zulässt.
• [DenyUrlSequences]: Dieser Abschnitt führt die Zeichenfolgen auf, die in einer HTTP-Anforderung nicht erlaubt sind. URLScan lehnt HTTP-Anforderungen ab, die eine Zeichenfolge enthalten, die in diesem Abschnitt aufgeführt ist.

Jeder Abschnitt wird in diesem Artikel detailliert beschrieben.

Der Abschnitt [Options]

Im Abschnitt [Options] können Sie eine Anzahl an URLScan-Optionen konfigurieren. Jede Zeile in diesem Abschnitt hat das folgende Format: Im Folgenden finden Sie die verfügbaren Optionen und ihre standardmäßigen Werte:

• UseAllowVerbs=1
  
  Standardmäßig hat diese Option den Wert 1. Wenn diese Option auf 1 gesetzt ist, lässt URLScan nur HTTP-Anforderungen zu, die die Verben verwenden, die im Abschnitt [AllowVerbs] aufgelistet sind. URLScan blockiert alle Anforderungen, die nicht diese Verben verwenden. Wenn diese Option auf 0 eingestellt ist, ignoriert URLscan den Abschnitt [AllowVerbs] und blockiert stattdessen nur Anforderungen, die Verben verwenden, die im Abschnitt [DenyVerbs] aufgeführt sind.
• UseAllowExtensions=0
  
  Standardmäßig hat diese Option den Wert 0. Wenn diese Option auf 0 gesetzt ist, blockiert URLScan Anforderungen für Dateinamenerweiterungen, die im Abschnitt [DenyExtensions] aufgelistet sind, lässt jedoch Anforderungen für andere Dateinamenerweiterungen zu. Wenn diese Option auf 1 eingestellt ist, lässt URLScan nur Anforderungen für Dateien mit Erweiterungen zu, die im Abschnitt [AllowExtensions] aufgelistet sind, und blockiert Anforderungen für andere Dateien.
• NormalizeUrlBeforeScan=1
  
  IIS empfängt Anforderungen, die URL-codiert sind. Das bedeutet, dass bestimmte Zeichen möglicherweise durch ein Prozentzeichen (%) gefolgt von einer bestimmten Nummer ersetzt werden. So steht beispielsweise %20 für ein Leerzeichen. Eine Anforderung für "http://meinserver/Mein%20Verzeichnis/Meine%20Datei.htm" entspricht also einer Anforderung für "http://meinserver/Mein Verzeichnis/Meine Datei.htm". Normalisierung ist der Vorgang des Decodierens von URL-codierten Anforderungen. Diese Option hat standardmäßig den Wert 1. Wenn die Option NormalizeUrlBeforeScan auf 1 gesetzt ist, analysiert URLScan die decodierte Anforderung. Wenn sie auf 0 eingestellt ist, analysiert URLScan stattdessen die nicht decodierte Anforderung. Wird diese Option auf 0 eingestellt, wird URLScan dabei behindert, bestimmte Arten von Angriffen zu blockieren.
• VerifyNormalization=1
  
  Da das Prozentzeichen (%) selbst URL-codiert sein kann, kann ein Angreifer eine sorgfältig erstellte Anforderung an einen Server übermittelt, die grundsätzlich doppelt codiert ist. Wenn dies geschieht, akzeptiert IIS unter Umständen eine Anforderung, die normalerweise als nicht gültig abgelehnt werden würde. Diese Option hat standardmäßig den Wert 1. Wenn die Option VerifyNormalization auf 1 eingestellt ist, normalisiert URLScan den URL zweimal. Wenn sich der URL nach der ersten Normalisierung vom URL nach der zweiten Normalisierung unterscheidet, lehnt URLScan die Anforderung ab. Dies verhindert Angriffe, die auf doppelt codierten Anforderungen basieren.
• AllowHighBitCharacters=0
  
  Diese Option hat standardmäßig den Wert 0. Wenn diese Option auf 0 eingestellt ist, lehnt URLScan alle Anforderungen ab, die Nicht-ASCII-Zeichen enthalten. Dies kann bestimmte Arten von Angriffen verhindern, aber es blockiert möglicherweise auch Anforderungen für bestimmte legitime Dateien, wie etwa Dateien mit nicht-englischen Dateinamen.
• AllowDotInPath=0
  
  Diese Option hat standardmäßig den Wert 0. Wenn diese Option auf 0 gesetzt ist, lehnt URLScan alle Anforderungen ab, die mehrere Punkte (.) enthalten. Dies verhindert Versuche, Anforderungen für gefährliche Dateinamenerweiterungen zu tarnen, indem eine sichere Dateinamenerweiterung in der Pfadinformation oder im Bereich der Abfragezeichenfolge des URLs eingesetzt wird. Wenn beispielsweise die Option auf 1 eingestellt ist, lässt URLScan möglicherweise eine Anforderung für http://servername/GefährlicheDatei.exe/SichereDatei.htm zu, da es davon ausgeht, dass es sich um eine Anforderung für eine HTML-Seite handelt, wenn es eigentlich eine Anforderung für eine ausführbare Datei (.exe-Datei) ist, mit dem Namen einer HTML-Seite im Bereich "PATH_INFO". Wenn diese Option auf 0 eingestellt ist, lehnt URLScan möglicherweise auch Anforderungen für Verzeichnisse ab, die Punkte enthalten.
• RemoveServerHeader=0
  
  Standardmäßig gibt ein Webserver einen Header zurück, der angibt, welche Webserversoftware in allen Antworten ausgeführt wird. Dadurch kann die Serveranfälligkeit erhöht werden, da ein Angreifer feststellen kann, dass ein Server IIS ausführt. So kann der Angreifer bekannte IIS-Probleme ausnutzen, anstatt zu versuchen, einen IIS-Server mit Mitteln und Methoden anzugreifen, die für Sicherheitslücken anderer Webserver entwickelt wurden. Diese Option hat standardmäßig den Wert 0. Wenn Sie die Option RemoveServerHeader auf 1 festlegen, verhindern Sie, dass Ihr Server den Header versendet, der ihn als IIS-Server identifiziert. Wenn Sie RemoveServerHeader auf 0 setzen, wird der Header weiterhin gesendet.
• AlternateServerName=(nicht standardmäßig festgelegt)
  
  Wenn RemoveServerHeader den Wert 0 hat, können Sie eine Zeichenfolge in der Option AlternateServerName spezifizieren, um festzulegen, was im Server-Header zurückgegeben wird. Wenn RemoveServerHeader auf 1 gesetzt ist, wird diese Option ignoriert.
• EnableLogging=1
  
  URLScan speichert standardmäßig ein vollständiges Protokoll aller blockierten Anforderungen in "%WINDIR%\System32\Inetsrv\URLScan". Sie können EnableLogging auf 0 einstellen, wenn Sie dieses Protokoll nicht beibehalten möchten.
• PerProcessLogging=0
  
  Diese Option hat standardmäßig den Wert 0. Wenn die Option auf 1 eingestellt ist, erstellt URLScan ein separates Protokoll für jeden Vorgang, der "URLScan.dll" hostet. Wenn die Option auf 0 eingestellt ist, werden alle Vorgänge in derselben Datei protokolliert.
• PerDayLogging=1
  
  Diese Option hat standardmäßig den Wert 1. Wenn dieser Wert 1 ist, erstellt URLScan jeden Tag eine neue Protokolldatei. Jede Protokolldatei hat den Namen "Urlscan.MMTTJJ.log", wobei MMTTJJ für das Datum der Protokolldatei steht. Wenn dieser Wert auf 0 eingestellt ist, wird die gesamte Protokollierung in derselben Datei gespeichert, unabhängig vom Datum.
• AllowLateScanning=0
  
  Diese Option hat standardmäßig den Wert 0. Wenn diese Option auf 0 gesetzt ist, wird URLScan als Filter mit hoher Priorität ausgeführt. Das bedeutet, dass es ausgeführt wird, bevor andere ISAPI-Filter (ISAPI = Internet Server Application Programming Interface), die auf dem Server installiert sind, ausgeführt werden. Wenn diese Option auf 1 festgelegt ist, wird URLScan als Filter mit niedriger Priorität ausgeführt, sodass andere Filter den URL abändern können, bevor URLScan Analysen durchführt. Für FrontPage-Servererweiterungen (FrontPage Server Extensions, FPSE) muss diese Option den Wert 0 haben.
• RejectResponseUrl=(nicht standardmäßig festgelegt)
  
  Diese Option spezifiziert den virtuellen Pfad zu einer Datei, die ausgeführt wird, wenn URLScan eine Anforderung blockiert. Dadurch können Sie die Antwort anpassen, die an den Client für blockierte Anforderungen gesendet wird. Sie müssen RejectResponseUrl als virtuellen Pfad zu der entsprechenden Datei festlegen, wie etwa "/Pfad/Zu/RejectResponseHandler.asp". Sie können eine Datei angeben, die URLScan üblicherweise blockiert, wie etwa eine Active Server Pages (ASP)-Seite. Sie können außerdem folgende Servervariablen der Seite verwenden:
  • HTTP_URLSCAN_STATUS_HEADER: Dies gibt an, warum die Anforderung blockiert wurde.
  • HTTP_URLSCAN_ORIGINAL_VERB: Diese Variable benennt das ursprüngliche Verb von der blockierten Anforderung (z. B. GET, POST, HEAD oder DEBUG).
  • HTTP_URLSCAN_ORIGINAL_URL: Dies gibt den ursprünglichen URL der blockierten Anforderung an.
  Wenn Sie für RejectResponseUrl den speziellen Wert /~* einsetzen, verwendet URLScan den Protokollierungsmodus. Dadurch wird IIS erlaubt, alle Anforderungen zu bedienen, aber es wird ein Eintrag in das URLScan-Protokoll für alle Anforderungen, die üblicherweise blockiert werden, hinzugefügt. Dies ist hilfreich, wenn Sie Ihre Datei "URLScan.ini" testen möchten.
  
  Wenn Sie keinen Wert für RejectResponseUrl festlegen, verwendet URLScan den Standardwert /<Rejected-By-UrlScan>.
  
  
• UseFastPathReject=0
  
  Diese Option hat standardmäßig den Wert 0. Wenn diese Option auf 1 gesetzt ist, ignoriert URLScan die Einstellung RejectResponseUrl und gibt sofort eine Fehlermeldung des Typs 404 an den Browser zurück. Dies ist schneller als die Verarbeitung von RejectResponseUrl, aber es lässt nicht so viele Protokollierungsoptionen zu. Wenn diese Option den Wert 0 hat, verwendet URLScan die Einstellung RejectResponseUrl, um die Anforderung zu verarbeiten.

Die Abschnitte [AllowVerbs] und [DenyVerbs]

Die Abschnitte [AllowVerbs] und [DenyVerbs] definieren die HTTP-Verben (auch als Methoden bekannt), die URLScan zulässt. Zu den allgemeinen HTTP-Verben gehören GET, POST, HEAD und PUT. Andere Anwendungen, wie etwa FPSE und Web Distributed Authoring and Versioning (WebDAV), verwenden zusätzliche Verben.

Die Abschnitte [AllowVerbs] und [DenyVerbs] haben dieselbe Syntax. Sie bestehen aus einer Liste an HTTP-Verben, und jedes Verb wird in einer eigenen Zeile angezeigt.

URLScan entscheidet basierend auf dem Wert der Option UseAllowVerbs im Abschnitt [Options], welcher Abschnitt verwendet wird. Diese Option hat standardmäßig den Wert 1. Wenn UseAllowVerbs auf 1 gesetzt ist, lässt URLScan nur Anforderungen zu, die die Verben verwenden, die im Abschnitt [AllowVerbs] aufgeführt sind. Eine Anforderung, die nicht eines dieser Verben verwendet, wird abgelehnt. In diesem Fall wird der Abschnitt [DenyVerbs] ignoriert.

Wenn UseAllowVerbs auf 0 eingestellt ist, lehnt URLScan Anforderungen ab, die Verben verwenden, die explizit im Abschnitt [DenyVerbs] aufgeführt sind. Alle Anforderung, die Verben verwenden, die nicht in diesem Abschnitt erscheinen, werden zugelassen. In diesem Fall ignoriert URLScan den Abschnitt [AllowVerbs].

Der Abschnitt [DenyHeaders]

Wenn ein Client eine Seite von einem Webserver anfordert, sendet er üblicherweise einige HTTP-Header, die zusätzliche Informationen über die Anforderung enthalten. Zu den häufigsten HTTP-Headern gehören:

• Host:
  
  Dieser Header enthält den Namen des Webservers.
• Accept:
  
  Dieser Header legt die Dateitypen fest, die der Client verarbeiten kann.
• User-Agent:
  
  Dieser Header enthält den Namen des Browsers, der die Seite anfordert.
• Authorization:
  
  Dieser Header definiert die Authentifizierungsmethoden, die der Client unterstützt.

Clients senden möglicherweise andere Header an den Server, um zusätzliche Daten zu spezifizieren.

Im Abschnitt [DenyHeaders] definieren Sie die HTTP-Header, die von URLScan abgelehnt werden. Wenn URLScan eine Anforderung empfängt, die einen in diesem Abschnitt aufgeführten Header enthält, wird die Anforderung abgelehnt. Dieser Abschnitt besteht aus einer Liste von HTTP-Headern, wobei jeder Header in einer eigenen Zeile angezeigt wird. Nach Headernamen muss ein Doppelpunkt (:) stehen (beispielsweise Headername:).

Die Abschnitte [AllowExtensions] und [DenyExtensions]

Die meisten Dateien haben eine Dateinamenerweiterung, die angibt, zu welchem Dateityp sie gehören. Dateinamen für Word-Dokumente enden üblicherweise mit .doc, HTML-Dateinamen enden normalerweise mit .htm oder .html, und reine Textdateinamen enden für gewöhnlich mit .txt. Die Abschnitte [AllowExtensions] und [DenyExtensions] ermöglichen Ihnen, die Erweiterungen festzulegen, die von URLScan blockiert werden. Sie können beispielsweise URLScan so konfigurieren, dass Anforderungen für .exe-Dateien abgelehnt werden, um zu verhindern, dass Webbenutzer Anwendungen auf Ihrem System ausführen.

Die Abschnitte [AllowExtensions] und [DenyExtensions] haben dieselbe Syntax. Sie bestehen aus einer Liste an Dateinamenerweiterungen, und jede Erweiterung wird in einer eigenen Zeile angezeigt. Die Erweiterung beginnt mit einem Punkt (.) (beispielsweise .ext).

URLScan entscheidet basierend auf dem Wert von UseAllowExtensions im Abschnitt [Options], welcher Abschnitt verwendet wird. Diese Option hat standardmäßig den Wert 0. Wenn UseAllowExtensions auf 0 gesetzt ist, lehnt URLScan nur Anforderungen für Dateinamenerweiterungen ab, die im Abschnitt [DenyExtensions] aufgelistet sind. Alle Dateinamenerweiterungen, die nicht in diesem Bereich aufgeführt sind, werden zugelassen. Der Abschnitt [AllowExtensions] wird ignoriert.

Wenn UseAllowExtensions auf 1 gesetzt ist, lehnt URLScan nur Anforderungen für Dateinamenerweiterungen ab, die nicht explizit im Abschnitt [AllowExtensions] aufgelistet sind. Nur Anforderungen für eine Dateinamenerweiterung, die in diesem Abschnitt aufgeführt ist, werden zugelassen. Der Abschnitt [DenyExtensions] wird ignoriert.

Weitere Informationen dazu, wie Sie URLScan so konfigurieren, dass Anforderungen für Dateien, die keine Erweiterung haben, zugelassen werden, finden Sie im folgenden Artikel der Microsoft Knowledge Base:

Der Abschnitt [DenyUrlSequences]

Sie können URLScan so konfigurieren, dass Anforderungen blockiert werden, die bestimmte Zeichenfolgen im URL enthalten. Sie können z. B. Anforderungen blockieren, die zwei aufeinander folgende Punkte (..) enthalten, die häufig mit Angriffen verwendet werden, die Sicherheitsanfälligkeiten bei Verzeichnistraversalen ausnutzen. Um eine Zeichenfolge festzulegen, die blockiert werden soll, geben Sie die Zeichenfolge in einer eigenen Zeile in den Abschnitt [DenyUrlSequences] ein.

Beachten Sie, dass das Hinzufügen von Zeichenfolgen Outlook Web Access (OWA) für Microsoft Exchange beeinträchtigen kann. Wenn Sie eine Nachricht von OWA öffnen, ist die Betreffzeile der Nachricht im URL enthalten, der vom Server angefordert wird. Da die Datei "URLScan.ini" alle Anforderungen blockiert, die das Prozentzeichen (%) und das kaufmännische Und-Zeichen (&) enthalten, erhalten Benutzer eine Fehlermeldung des Typs 404, wenn sie versuchen, eine Nachricht mit einer Betreffzeile wie "Umsatzsteigerung von 100%" oder "Andreas & Nina kommen in die Stadt" zu öffnen. Um dieses Problem zu beheben, können Sie diese Zeichenfolgen aus dem Abschnitt [DenyUrlSequences] entfernen. Beachten Sie, dass hierdurch die Sicherheit verringert wird, da so schädlichen Anforderungen potenziell ermöglicht wird, den Server zu erreichen.

Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:

Konfigurieren von URLScan für die Verwendung mit IIS-abhängigen Anwendungen

Die ordnungsgemäße Funktion von Anwendungen wie Exchange, FPSE und Microsoft Visual Studio .NET hängt von IIS ab. Wenn Sie URLScan nicht ordnungsgemäß konfigurieren, funktionieren diese Anwendungen möglicherweise nicht mehr richtig.

Weitere Informationen dazu, wie Sie URLScan für die Verwendung mit diesen Anwendungen konfigurieren, finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:

Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: