UrlScan 2.5 installieren

Microsoft-Sicherheitstools: UrlScan
(Engl. Originaltitel: UrlScan Security Tool)
Mit dem Tool UrlScan 2.5 können Sie festlegen, welche HTTP-Anfragen von den Internet Information
Services (IIS) bearbeitet werden dürfen und welche nicht. Angriffe auf IIS-Server, bei denen
bestimmte Anfragetypen ausgenutzt werden, lassen sich dadurch schon im Vorfeld unterbinden. Sie
können UrlScan auf Servern, die IIS 4.0 oder höher ausführen, installieren.
Dieser Artikel enthält die folgenden Informationen:

Neue Features in UrlScan 2.5

Soll UrlScan 2.5 mit IIS 6.0 eingesetzt werden?

UrlScan 2.5 installieren

Häufig gestellte Fragen
Neue Features in UrlScan 2.5
Microsoft hat UrlScan in der Version 2.5 zusammen mit einem neuen Installationsprogramm
veröffentlicht. Dieses Installationsprogramm gewährleistet eine reibungslose Installation des Tools auf
Systemen mit IIS 4.0 oder höher.
Wichtig: UrlScan verhindert viele Arten von Angriffen. Es ist jedoch nicht dafür gedacht,
Updates und Patches auf dem aktuellen Stand zu halten. Microsoft empfiehlt Ihnen dringend,
Sicherheitspatches zu installieren, um Server sicher zu halten und bekannte
Sicherheitsprobleme zu beheben.
Das Sicherheitstool UrlScan besteht aus den zwei Dateien UrlScan.dll und UrlScan.ini, die beide in
der Datei UrlScan.exe enthalten sind. Mit der Version 2.5 erhalten Sie als Administrator noch mehr
Kontrolle über die Konfiguration von UrlScan. Die Version stellt Funktionen zur Verfügung, die Ihnen
bei der weitern Absicherung der Server helfen.
Die folgenden Features wurden mit UrlScan 2.5 eingeführt und standen in vorhergehenden Versionen
nicht zur Verfügung:
Verzeichnisse für Protokolldateien ändern
UrlScan 2.5 verfügt über die neue Funktion LoggingDirectory. Diese wird verwendet, um den Ordner
für die Speicherung von Protokolldateien anzugeben. Bei dem Wert muss es sich um einen absoluten
Pfadnamen handeln (z.B. c:\directory_path). Wenn Sie keinen Ordner bestimmen, erstellt UrlScan das
Protokoll in dem Ordner, in dem die Datei UrlScan.dll liegt.
Lange URLs protokollieren
Die Funktion LogLongUrls wurde hinzugefügt, um die Länge der protokollierten URLs zu erhöhen. In
früheren Versionen hat UrlScan jede Zeile im Protokoll nach 1024 Bytes abgeschnitten. Die neue
Option erlaubt es, diese Beschränkung auf 128 KB heraufzusetzen. Gültige Werte sind 0 oder 1. Die
Voreinstellung ist 0. Dies bedeutet, dass weiterhin nur die ersten 1024 Bytes protokolliert werden.
Wenn Sie den Wert auf 1 setzen, protokolliert UrlScan bis zu 128 KB pro Anfrage.
Anfragengröße beschränken
Mit der Funktion RequestLimits können Sie Anfragen, die den Server erreichen, entsprechend ihrer
Größe in Bytes einschränken. Die Funktion enthält die folgenden drei Einträge:

MaxAllowedContentLength: Setzt einen Maximalwert für die Länge des Inhaltes durch. Diese
Einstellung schützt den Server nicht notwendigerweise davor, mehr Daten einzulesen, als hier
angegeben sind. Beispiel: Wenn ein Client eine gestückelte POST-Anfrage startet, kann UrlScan
nicht die Größe der gesamten Anfrage erkennen. Der voreingestellte Wert beträgt ~2 GB
(2.000.000.000 Bytes).

MaxUrl: Schränkt die Länge der angefragten URL in Bytes ein, wobei allerdings nicht die Länge
der Abfrage limitiert wird. Wenn Sie UrlScan über den Installer aktualisieren, wird der
Standardwert auf 16 KB gesetzt.
Anmerkung: Wenn Sie die Datei UrlScan.dll manuell aus UrlScan.exe entpacken, und die
Datei UrlScan.ini daher nicht aktualisiert wird, lautet die Standardeinstellung für diesen Wert
260 Byte. In diesem Fall müssen Sie in die Datei UrlScan.ini den Eintrag MaxUrl = 16384
einfügen.

MaxQueryString: Beschränkt die Länge der Abfrage in Byte. Der Standardwert beträgt 4 KB. Sie
können zusätzlich ein Limit in Byte für einen speziellen Anfrage-Header setzen, indem Sie den
einen Eintrag “Max-HEADERNAME” erstellen. Beispiel: Der folgende Eintrag setzt ein Limit von
100 Bytes für den Header 'Content-Type' durch: Max-Content-Type=100. Wenn Sie für einen
Header keine Beschränkung festlegen möchten, verwenden Sie den Wert 0. Beispiel: Max-UserAgent=0. Alle Header, die in diesem Abschnitt nicht angegeben werden, unterliegen ebenfalls
keiner Längenbeschränkung.
Soll UrlScan 2.5 mit IIS 6.0 eingesetzt werden?
Der Microsoft® Windows Server™ 2003 besitzt eine Vielzahl systemeigener Features, die bei der
Absicherung von IIS 6.0-Servern helfen. Als Ergänzung zu den Möglichkeiten von IIS 6.0 stellt
UrlScan weitere Funktionen für die Absicherung zur Verfügung, zum Beispiel die Funktion verb
control. Einige Organisationen haben UrlScan außerdem bereits in die Verwaltungsprozesse ihrer IISServer aufgenommen. Wenn Sie die zusätzlichen Features von UrlScan 2.5 verwenden oder Ihre
momentane Sicherheitsverwaltung aufrecht erhalten möchten, sollten Sie UrlScan 2.5 zusammen mit
IIS 6.0 verwenden.
UrlScan 2.5 ist in IIS 6.0 nicht enthalten. Die systemeigenen Features von IIS 6.0 bieten in den
meisten Fallen eine höherwertige oder mindestens gleichwertige Sicherheitsfunktionalität. In Tabelle 1
können Sie vergleichen, wie die Funktionen von UrlScan 2.5 und IIS 6.0 mit unterschiedlichen
Sicherheitsanforderungen umgehen. Wenn Sie Sich nicht sicher sind, ob Sie UrlScan 2.5 auf Ihren IIS
6.0-Servern installieren sollen, sehen Sie Sich als Hilfestellung diese Gegenüberstellung an.
Tabelle 1: Vergleich von UrlScan 2.5 und IIS 6.0
Features von UrlScan 2.5
Systemeigene Möglichkeiten des IIS 6.0
DenyExtensions: Diese Funktion wurde
in UrlScan zu Verringerung der
Die IIS 6.0 schränken die Angriffsoberfläche von Servern ein,
indem Administratoren definieren können, welcher ISAPI- und CGI-
Angriffoberfläche implementiert. Anhand
von Dateierweiterungen verhindert sie,
dass bestimmte Anfragen ISAPI- oder
CGI-Code ausführen.
Code ausgeführt werden soll. Da die IIS 6.0 den Code sofort
einordnen, ist es nicht mehr notwendig zu wissen, welche
Dateierweiterung in der URL möglicherweise Schaden anrichten
könnte.
DenyVerbs: Angreifer können auf
Webservern anhand von bestimmten
HTTP-Verbs WebDAV-Code aufrufen.
Diese Funktion wurde implementiert, um
zu verhindern, dass Anfragen WebDAV
aufrufen.
Die IIS 6.0 geben Administratoren die Möglichkeit, WebDAV explizit
zu aktivieren oder zu deaktivieren. Da dieser Vorgang den
WebDAV-Code direkt betrifft, ist das Feature von UrlScan nicht
mehr notwendig.
DenyVerbs: Angreifer können auf
Webservern anhand von bestimmten
HTTP-Verbs WebDAV-Code aufrufen.
Diese Funktion wurde implementiert, um
zu verhindern, dass Anfragen WebDAV
aufrufen.
Die IIS 6.0 geben Administratoren die Möglichkeit, WebDAV explizit
zu aktivieren oder zu deaktivieren. Da dieser Vorgang den
WebDAV-Code direkt betrifft, ist das Feature von UrlScan nicht
mehr notwendig.
NormalizeUrlBeforeScan: Mit dieser
Funktion können Sie festlegen, ob die IIS
die vom Client gesendete unbearbeitete
URL oder die auf dem Server
normalisierte URL verarbeitet.
Die in IIS 6.0 enthaltenen Lockdown-Mechanismen basieren auf
dem erlaubten ausführbaren Code – er basiert nicht auf der vom
Client angefragten URL. Aus diesem Grund ist die Funktion
NormalizeUrlBeforeScan unter IIS 6.0 nicht notwendig.
Anmerkung: Auf Produktionsservern ist
es nicht empfehlenswert, diesen Wert auf
0 zu setzen. Wenn dieser Wert auf 0
gesetzt ist, müssen alle möglichen
Codierungen jedes Zeichens für die
Dateierweiterungen und die anderen
Tests in der Datei UrlScan.ini spezifiziert
werden. Die Zahl der möglichen Varianten
dürfte auf einen Produktionsserver wohl
nicht umzusetzen sein.
VerifyNormalization: UrlScan kann unter Die von den IIS 6.0 enthaltene Komponente HTTP.SYS verwendet
vielen IIS-Versionen ausgeführt werden.
erweiterten Code zur Verarbeitung. Dieser wurde speziell für den
Das Tool, das die URLs verarbeitet,
Schutz gegen URL-Verarbeitungsangriffe geschrieben.
wurde mit späteren Releases und Service
Packs von IIS erweitert. Mithilfe dieser
Funktion kann UrlScan mögliche
Probleme bei der URL-Verarbeitung auf
ungepatchten Systemen erkennen.
DenyUrlSequences: Über dieses
Die IIS 6.0 müssen keine URL-Sequenzen ablehnen. Aufgrund
Feature kann UrlScan Sequenzen
ihres Designs sind sie nicht durch URL-Sequenzen verwundbar.
entdecken, die in URL-basierten Angriffen
verwendet werden.
AllowDotInPath: Der LockdownDie Funktion AllowDotInPath ist unter IIS 6.0 nicht notwendig, da
Mechanismus von UrlScan hängt davon
diese nicht von Benachrichtigungen über Filter abhängig sind.
ab, dass in einem frühen Stadium des
Verarbeitungsprozesses eine
Benachrichtigung über einen Filter erfolgt.
Zu diesem Zeitpunkt kann UrlScan
allerdings noch nicht genau wissen, wie
die IIS die URL für PATH_INFO parsen
wird. Es besteht die Möglichkeit, dass
PATH_INFO die Dateinamenerweiterung
der URL verändert. Wenn Sie
AllowDotInPath auf den Wert 0 setzen,
lehnt UrlScan jede Anfrage mit
Dateierweiterungen ab, bei denen ein
Punkt im Pfad vorhanden ist.
RemoveServerHeader: Mithilfe dieser
Funktion kann UrlScan bei der Antwort an
den Client im Response-Header die
Identität des Servers ändern oder
entfernen.
In den IIS 6.0 ist die Einstellung RemoveServerHeader nicht
vorhanden, denn sie bringt keinen entscheidenden
Sicherheitsvorteil. Die meisten Angriffe sind nicht
betriebssystemspezifisch. Es gibt andere Möglichkeiten, die
Identität des Servers festzustellen und Informationen über das
Betriebssystem zu erhalten.
EnableLogging, PerProcessLogging
und PerDayLogging: UrlScan ist kein
Teil des IIS-Server Kernels, sondern ein
zusätzliches Werkzeug. Daher produziert
es auch seine eigenen Protokolldateien.
Mit diesen Funktionen können Sie
verschiedene Aspekte im Zusammenhang
mit diesen Protokolldateien festlegen.
Die IIS 6.0 speichern alle Lockdown-Aktivitäten in den W3SVCProtokollen. Anfragen, die die IIS aufgrund eines Lockdowns oder
wegen ausführbaren Codes zurückweisen, werden als 404.2Fehler protokolliert. Anfragen zu statischen Dateien, die aufgrund
eines unbekannten Typs abgelehnt werden, werden als 404.3Fehler identifiziert.
AllowLateScanning: Mit dieser Funktion
können Sie festlegen, ob UrlScan die
URLs vor oder nach anderen Filtern
überprüfen soll. Es gibt eine Reihe von
Filtern, die URLs verändern. In diesem
Fall ist es unter Umständen
wünschenswert, URLs erst nach der
Veränderung zu überprüfen. Ein Beispiel
für diese Art von Filtern sind die Filter der
FrontPage Server Extensions.
Die Funktion AllowLateScanning ist in den IIS 6.0 nicht
erforderlich, da die Lockdown-Mechanismen hier nicht von
Benachrichtigungen durch Filter abhängen. Die IIS 6.0Mechanismen basieren auf dem Code, dessen Ausführung auf der
vom Client angefragten URL nicht gestattet ist.
RejectResponseUrl: Diese Funktion
arbeitet mit UseFastPathReject
zusammen. Falls die Einstellung für
UseFastPathReject auf 0 gesetzt ist,
werden alle abgelehnten Anfragen auf die
unter RejectResponseUrl angegebene
URL weitergeleitet. Wenn diese URL nicht
existiert, erhält der Client eine 404Fehlermeldung – so als hätte er
tatsächlich eine nicht bestehende URL
angefragt. Sie haben allerdings auch die
Möglichkeit, die Meldung an den Client
entsprechend Ihren Anforderungen
anzupassen.
Die IIS 6.0 speichern alle Lockdown-Aktivitäten in den W3SVCProtokollen. Anfragen, die die IIS aufgrund eines Lockdowns oder
wegen ausführbaren Codes zurückweisen, werden als 404.2Fehler protokolliert. Anfragen zu statischen Dateien, die aufgrund
eines unbekannten MIME-Typs abgelehnt werden, werden als
404.3-Fehler identifiziert. Als Administrator können Sie die
benutzerspezifisch konfigurierbaren Fehlermechanismen der IIS
nutzen, um diese Antworten zu steuern.
UseFastPathReject: LockdownMechanismus von UrlScan hängt davon
ab, dass in einem frühen Stadium des
Verarbeitungsprozesses eine
Benachrichtigung über einen Filter erfolgt.
Daher kann auch nicht der normale 404Fehler als Antwort zurückgesendet
werden, wenn UrlScan die Anfrage
aufgrund der Benachrichtigung ablehnt.
Der Client wird wahrscheinlich eher eine
kurze Fehlermeldung als die ausführliche
benutzerdefinierte Meldung erhalten. Falls
die Einstellung für UseFastPathReject
auf 0 gesetzt ist, werden alle abgelehnten
Anfragen auf die unter
RejectResponseUrl angegebene URL
weitergeleitet.
Die Funktion UseFastPathReject ist unter IIS 6.0 nicht notwendig,
da diese nicht von Benachrichtigungen über Filter abhängig sind.
Die IIS 6.0 speichern alle Lockdown-Aktivitäten in den W3SVCProtokollen. Anfragen, die die IIS aufgrund eines Lockdowns oder
wegen ausführbaren Codes zurückweisen, werden als 404.2Fehler protokolliert. Anfragen zu statischen Dateien, die aufgrund
eines unbekannten Typs abgelehnt werden, werden als 404.3Fehler identifiziert.
AllowHighBitCharacters: Mithilfe dieser
Funktion kann UrlScan Zeichen erkennen,
bei denen es sich nicht um ASCII-Zeichen
handelt.
Der erlaubte Zeichenbereich wird von HTTP.SYS verwaltet. Dieser
Wert kann über den folgenden Registrierungsschlüssel geändert
werden: HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\HTTP\Parameters\EnableNonUTF8.
Warnung: Ein Fehler bei der Bearbeitung der Registrierung könnte
Ihr System schwer beschädigen. Bevor Sie Änderungen an der
Registrierung vornehmen, sollten Sie eine Sicherung aller
wertvollen Daten auf dem Computer vornehmen.
MaxAllowedContentLength: Mit dieser
Funktion kann UrlScan die Größe von
Anfragen beschränken.
Die IIS 6.0 sind von sich aus in der Lage, die Größe von Anfragen
zu beschränken. Die Konfiguration erfolgt über die MetabaseEigenschaften MaxRequestEntityAllowed und
ASPMaxRequestEntityAllowed.
MaxUrl, MaxQueryString und
MaxHeader: Mit diesen Funktionen kann
UrlScan die Größe von URLs,
Abfragestrings und bestimmten Headern
beschränken.
Die von den IIS 6.0 verwendete Komponente HTTP.SYS erlaubt
es, Anfragen ganz oder in bestimmten Teilen zu beschränken. Die
Konfiguration erfolgt über die Werte AllowRestrictedChars,
MaxFieldLength, UrlSegmentMaxLength und
UrlSegmentMaxCount. Sie finden die Werte unter den
Registrierungsschlüsseln:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\HTTP\Parameters\AllowRestrictedChars
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\HTTP\Parameters\MaxFieldLength
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\HTTP\Parameters\UrlSegmentMaxLength
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\HTTP\Parameters\UrlSegmentMaxCount
Warnung: Ein Fehler bei der Bearbeitung der Registrierung könnte
Ihr System schwer beschädigen. Bevor Sie Änderungen an der
Registrierung vornehmen, sollten Sie eine Sicherung aller
wertvollen Daten auf dem Computer vornehmen.
UrlScan kann auch zusammen mit den IIS 6.0 eingesetzt werden. Hierfür spricht, dass UrlScan einige
Funktionen zur Absicherung von Webservern bietet, die in den IIS 6.0 nicht enthalten sind. UrlScan ist
ein sehr flexibles Werkzeug und wird von einigen Kunden noch für Zwecke genutzt, die in diesem
Artikel nicht beschrieben sind. Mehrere Organisationen haben UrlScan außerdem in die
Verwaltungsprozesse ihrer IIS-Server aufgenommen. Aus diesen Gründen könnten Sie sich für eine
gemeinsame Verwendung von UrlScan 2.5 und IIS 6.0 entscheiden.
Weiter Informationen zu UrlScan 2.5 finden Sie im Microsoft Knowledge Base Artikel 307608,
Verwenden von UrlScan auf einem IIS (englischsprachig).
UrlScan 2.5 installieren
Sie können UrlScan 2.5 auf IIS 4.0-System oder höher installieren. Upgrades werden ebenfalls
unterstützt.
So installieren Sie UrlScan 2.5:
1. Downloaden Sie die Datei Setup.exe für UrlScan 2.5.
2. Klicken Sie doppelt auf das Icon Setup.exe.
3. Lesen Sie die Endbenutzervereinbarung im Installationspaket und klicken Sie auf Yes, um sie zu
akzeptieren. Wenn Sie auf No klicken, wird das Setup beendet.
4. Sobald das Setup fertiggestellt ist, wird folgende Meldung angezeigt: UrlScan has been
successfully installed. Klicken Sie auf OK, um das Setup zu schließen.
So deinstallieren Sie UrlScan:
5. Klicken Sie in der Systemsteuerung auf Software.
6. Wählen Sie UrlScan 2.5 aus, und klicken Sie auf die Schaltfläche Ändern/Entfernen.
7. Sobald UrlScan 2.5 von Ihrem Server entfernt ist, wird die folgende Nachricht angezeigt: UrlScan
has been successfully uninstalled. Klicken Sie auf OK, um den Deinstallationsprozess
abzuschließen.
Informationen zum UrlScan 2.5 Installer
Wenn UrlScan 2.5 installiert wird, führt der Installer folgendes aus:

Er installiert die Dateien UrlScan.dll und UrlScan.ini im Ordner
%windir%\system32\inetsrv\UrlScan. Wenn UrlScan bereits auf diesem Computer installiert ist,
werden die Dateien aktualisiert.

Er fügt einen globalen Filter zum IIS hinzu.
Wenn Sie UrlScan auf einem Server mit IIS 6.0 installieren, nimmt der Installer einige zusätzliche
Änderungen vor, damit UrlScan 2.5 mit dem neuen Prozessmodel der IIS 6.0 arbeiten kann. Hierbei
handelt es sich um die folgenden Änderungen:

PerProcessLogging wird in der Datei UrlScan.ini auf 1 gesetzt. Dies stellt sicher, dass zwei
UrlScan-Prozesse nicht zur gleichen Zeit in die Protokolldatei schreiben.

UrlScan wird in der Metabase für Cache-Erkennung markiert. Dies stellt sicher, dass zwei
UrlScan-Prozesse nicht zur gleichen Zeit in die Protokolldatei schreiben.

Ein neues Protokollverzeichnis wird als Unterordner unter \inetsrv\UrlScan erstellt. Dies stellt
sicher, dass das UrlScan-Verzeichnis nicht mit den vielen von der Funktion PerProcessLogging
produzierten Protokolldateien gefüllt wird.
Wenn Sie UrlScan 2.5 unter früheren Versionen von IIS installieren, setzt der Installer Berechtigungen
für die Dateien UrlScan.dll, UrlScan.ini und für die Protokolldateien. Wenn Sie UrlScan unter IIS 6.0
installieren, setzt der Installer für die gleichen Dateien noch weitere Berechtigungen. Diese
ermöglichen es UrlScan 2.5, mit dem Prozessisolationsmodus der IIS 6.0 zu arbeiten. Die bei der
Installation von UrlScan 2.5 gesetzten Berechtigungen sind in Tabelle 2 aufgeführt.
Tabelle 2: Berechtigungen
Datei/Verzeichnis
Berechtigungen
..\inetsrv\UrlScan\UrlScan.dll
Lesen und Ausführen (nur unter IIS 6.0): lokaler
Dienst, IIS_WPG und Netzwerkdienst
Vollzugriff: Administratoren und lokales System
..\inetsrv\UrlScan\UrlScan.ini
Lesen (nur unter IIS 6.0): lokaler Dienst, IIS_WPG und
Netzwerkdienst
Vollzugriff: Administratoren und lokales System
..\inetsrv\UrlScan\logs
Lesen und Schreiben (nur unter IIS 6.0): lokaler
Dienst, IIS_WPG und Netzwerkdienst
Vollzugriff: Administratoren und lokales System
Wenn festgestellt wird, dass schon eine Version von UrlScan auf dem Computer vorhanden ist, wird
ein Upgrade statt einer Installation durchgeführt. Bei einem Upgrade entsprechen die
Berechtigungsänderungen denen, die bei einer Installation vorgenommen werden, es sein denn, Sie
haben einen abweichenden Protokollordner konfiguriert. Wenn Sie die UrlScan-Protokolle an eine
andere Position verschoben haben, werden die neuen Protokollverzeichnisse nicht erstellt.
Häufig gestellte Fragen
Frage: Was ist UrlScan?
Antwort: UrlScan prüft alle auf dem Server eingehenden Anfragen und filtert Sie nach den vom
Administrator festgelegten Regeln. Da der Server dann nur noch gültige Anfragen ausführt, erhöht
dies die Sicherheit des Systems. Die meisten gefährlichen Angriffe weisen ein gemeinsames Merkmal
auf: Sie verwenden eine Anfrage, die auf irgendeine Art ungewöhnlich ist. Die Anfrage könnte zum
Beispiel extrem lang sein, eine ungewöhnliche Aktion anfordern, mit einem alternativen Zeichensatz
codiert sein oder Zeichenketten enthalten, die in legitimen Anfragen normalerweise nicht vorkommen.
Indem es alle ungewöhnlichen Anfragen filtert, verhindert UrlScan, dass potentiell schädliche Anfragen
den Server erreichen.
Frage: Arbeitet UrlScan 2.5 mit den IIS 6.0 zusammen?
Antwort: Ja. UrlScan 2.5 ist die einzige Version, die von Microsoft für die Nutzung mit den IIS 6.0
unterstützt wird.
Frage: Ich nutze schon Version 2.0 von UrlScan. Warum sollte ich das Update herunterladen?
Antwort: UrlScan 2.5 bietet die folgenden neuen Features:

Verzeichnisse für Protokolldateien ändern

Lange URLs protokollieren.

Größe von Anfragen beschränken.
Frage: Ich habe UrlScan für meine Website bereits passend konfiguriert. Überschreibt UrlScan
2.5 meine aktuellen Konfigurationseinstellungen?
Antwort: Nein. UrlScan 2.5 fügt der Konfigurationsdatei nur neue Einträge hinzu. Vorhandene
Einträge werden nicht verändert.
Frage: Wenn UrlScan 2.5 mein System gegen Sicherheitsprobleme schützt, ist es dann
trotzdem notwendig, die Patches zu installieren?
Antwort: Ja, dies ist auf jeden Fall notwendig. Patches stellen den letztendlichen Schutz gegen
Sicherheitslöchern dar. Microsoft empfiehlt Ihnen dringend, zum Schutz Ihres Systems alle
Sicherheitspatches so schnell wie möglich zu installieren.
Frage: Ich bin nicht sicher, ob ich in einer meiner Anwendungen gestückelte Anfragen
verwende. Was ist das?
Antwort: Eine gestückelte Anfrage überträgt die Nachricht an den Client in mehreren Teilen. Da in
jedem Teil die Größe des Teiles angegeben ist, kann der Client feststellen, ob er alle vom Server
gesendeten Daten erhalten hat. „Chunked transfer encoding“ ist das gleiche wie die MIME-Codierung
im Bezug auf Internet-Mail. Weiter Informationen finden Sie im Kapitel 3.6.1 des Memos RFC 2616,
„Hypertext Transfer Protocol HTTP/1.1“.