Änderungen bei der Sicherheit zwischen IIS 6.0 und IIS 7 und höher

Artikel
03/12/2024

vom IIS-Team

Einführung

IIS 7 und höher bringen viele neue Sicherheitsverbesserungen gegenüber IIS 6.0. Dieses Dokument gibt einen Überblick über diese Verbesserungen in Bezug auf Authentifizierung, Autorisierung, SSL, Webdiensterweiterung-Einschränkungsliste und IP-Beschränkungen.

Authentifizierung

Für ASP.NET-Anwendungsentwickler gab es vor IIS 7 zwei Authentifizierungsmodelle, für die Sie programmieren mussten. Diese Modelle waren die IIS- und ASP.NET-Pipelines. Zunächst würde der IIS die Anforderung untersuchen und seine Authentifizierungsroutinen durchführen und sie anschließend an ASP.NET weiterleiten, damit dieses eine ähnliche Aufgabe übernehmen kann.

In IIS 7 und höher haben wir diese beiden Modelle vereint, um eine neue robuste Pipeline zu erstellen, die das Beste aus den beiden älteren Modellen herausholt. IIS unterstützt nach wie vor alle alten Authentifizierungsprotokolle, aber jetzt auch die Formularauthentifizierung, die vor allen Inhaltstypen schützen kann und nicht auf Windows-Konten angewiesen ist. Neben der Unterstützung aller alten Funktionen, die Sie kennen und lieben gelernt haben, haben wir auch einige von ihnen verbessert, wie z.B. die Funktion Anonyme Authentifizierung.

Diese Änderungen werden in den nächsten Abschnitten besprochen.

Änderungen bei der anonymen Authentifizierung

In IIS 7 und höher verhält sich die Anonyme Authentifizierung ähnlich wie in den Vorgängerversionen mit nur einer Änderung – der Möglichkeit, unter dem Inhalt der Identität des Arbeitsprozesses zu laufen. Jeder Anwendungspool wird so konfiguriert, dass er unter dem Inhalt eines Benutzerkontos ausgeführt wird. Der Standardwert für dieses Konto ist NETWORKSERVICE.

Es war sehr üblich, dass ASP.NET Anwendungen den Identitätswechsel deaktivieren und unter der Anwendungspoolidentität ausgeführt werden, indem sie den folgenden Code in ihren Web.config-Dateien verwenden:

<identity impersonate="false"/>

Es gibt mehrere Szenarien, in denen Anwendungen unter dem Kontext der Prozessidentität ausgeführt werden müssen:

Die Prozessidentität ist ein Konto mit geringen Rechten und die Administratoren haben ihre Systeme für dieses Konto gesperrt
Die Prozessidentität hat Netzwerkzugriff erhalten und wird für den Zugriff auf Backend-Ressourcen wie Datenbanken verwendet

Im Rahmen der Neugestaltung für IIS 7 und höher wollten wir dieses Szenario sicher und einfach gestalten. Um dieses Szenario zu implementieren, ist im IIS erforderlich:

Installieren und Aktivieren des Moduls Anonyme Authentifizierung
Setzen des anonymen Benutzernamens und des Passworts auf eine leere Zeichenfolge

Ändern Sie dazu Ihre Konfiguration für die anonyme Authentifizierung, so dass sie wie folgt aussieht:

<anonymousAuthentication enabled="true" userName="" defaultLogonDomain="" />

Mit dieser Konfiguration wird IIS aufgefordert, immer unter dem Kontext der Identität des Arbeitsprozesses ausgeführt zu werden.

Standardmäßig ist die anonyme Authentifizierungsidentität in IIS 7.0 und höher das IUSR-Konto. Dieses Konto ist eine wenig privilegierte Identität mit minimalen Rechten und Privilegien. Wenn Sie mehr über das neue integrierte Konto erfahren möchten, lesen Sie den Artikel Das integrierte Konto und die Gruppe in IIS 7 und höher verstehen.

Passport-Änderungen

Die Unterstützung der Vorgängerversion der Passport-Authentifizierung wurde in IIS 5/6 und Windows Server 2000 und 2003 integriert. Die Passport-Unterstützung in IIS 5 & 6 wurde als Kontrollkästchen auf der Registerkarte Verzeichnissicherheit im IIS-Dienstmanager für "Passport-Authentifizierung aktivieren" angezeigt. Dieses Kontrollkästchen ermöglicht es dem IIS, Legacy-Protokollherausforderungen von Tweener zu senden. Darüber hinaus war es immer noch notwendig, die Website beim Passport Service Bereitstellung Portal zu registrieren, einen Verschlüsselungsschlüssel zu erhalten und den Legacy Passport Manager auf dem Server zu konfigurieren, bevor die IIS-Integration funktionierte.

In Windows Server 2008 und später wurden die alten Passport-Binärdateien und die Integration mit IIS entfernt.

Der Passport-Dienst wurde inzwischen in Windows Live ID umbenannt. Der neue Live ID Service ist zwar aus dem alten Passport Service hervorgegangen, aber es gibt doch einige wichtige Änderungen. Eine der größten Änderungen ist die Integration einer Partnerseite in Live ID. Sie können die Live ID-Authentifizierung hinzufügen, indem Sie das öffentlich verfügbare Windows Live ID Web Authentication SDK verwenden. Der Windows Live ID-Dienst unterstützt zwar auch Identitätsföderation und ADFS, doch handelt es sich dabei um neue Funktionen für spezielle Fälle und nicht um einen Ersatz für "Passport".

Formularauthentifizierung

Die Forms-Authentifizierung ist Teil von ASP.NET und ermöglicht es sowohl Windows- als auch Nicht-Windows-Identitäten, sich zu authentifizieren und ein Benutzerobjekt zu erhalten, das Anwendungen später verwenden können. IIS 7 und höher unterstützen jetzt vollständig die Formularauthentifizierung und können so konfiguriert werden, dass der Zugriff auf alle Inhaltstypen geschützt ist.

Wie IIS 7 und höher die authentifizierte Identität ermitteln

In IIS 7 und höher werden die Authentifizierungsregeln von der Core Engine auf ähnliche Weise verarbeitet wie in früheren Versionen von IIS, mit nur einigen geringfügigen Änderungen. Zum besseren Verständnis der Verarbeitungsreihenfolge finden Sie hier die Regeln in der Reihenfolge, in der sie vom IIS ausgewertet werden:

Zunächst stellt der IIS fest, ob ein Benutzername und ein Passwort für das virtuelle Verzeichnis konfiguriert wurden. Wenn eine Gruppe von Anmeldeinformationen definiert wurde, werden diese Anmeldeinformationen verwendet. Für Administratoren vor IIS 7 sind diese Anmeldedaten die UNC-Anmeldedaten
Wenn für das virtuelle Verzeichnis keine Anmeldeinformationen konfiguriert sind, verwendet der IIS die bei der Authentifizierung angegebenen Anmeldeinformationen. Diese Anmeldedaten können zu der Identität gehören, die für die anonyme Authentifizierung konfiguriert ist, oder zu den Anmeldedaten, die der Benutzer während des Authentifizierungs-Handshakes angibt, wenn die Basic-, Digest- oder Windows-Authentifizierung aktiviert ist
Wenn kein authentifizierter Benutzer eingerichtet wurde (z.B. wenn die Formularauthentifizierung aktiviert ist), wird bestimmt, ob die Prozessidentität verwendet werden soll
Wenn wir zu diesem Zeitpunkt keine Identität haben, gibt der IIS die Meldung Zugriff verweigert zurück

Autorisierung

AzMan Support

In IIS 6.0 haben wir ein neues Autorisierungsmodell eingeführt, das auf AZMan-Regeln basiert. In IIS 7 und höher haben wir diese Funktion zugunsten eines neuen Modells abgelegt, das dem ASP.NET-Autorisierungsmodell sehr ähnlich ist (siehe Thema URL-Autorisierung weiter unten).

URL-Autorisierung

In IIS 7 und höher stehen Ihnen zwei Autorisierungslösungen zur Verfügung. Die erste ist die Verwendung des ASP.NET-Autorisierungsmodells. Bei dieser Methode müssen Sie alle Ihre Autorisierungsregeln in der <system.web>-Konfiguration definieren. Für Anwendungen, für die bereits Regeln für ASP.NET geschrieben wurden, sind keine Änderungen erforderlich. Das zweite Modell ist die Umstellung auf die neue IIS-Autorisierungsarchitektur. Dieses Modell ist dem Modell von ASP.NET sehr ähnlich, mit einigen kleinen Änderungen:

Regeln sind nicht von der Reihenfolge abhängig
Ablehnungsregeln werden an den Anfang der Liste sortiert
Die Regeln werden in umgekehrter Weise wie bei ASP.NET verarbeitet, hauptsächlich in der Reihenfolge: das Element der zweiten übergeordneten Ebene, das Element der übergeordneten Ebene, dann das Element der untergeordneten Ebene; die ASP.NET-Autorisierung verarbeitet Regeln in der umgekehrten Reihenfolge: das Element der untergeordneten Ebene, das Element der übergeordneten Ebene, dann das Element der zweiten übergeordneten Ebene

Um die Unterschiede zwischen dem ASP.NET-Autorisierungsmodell und dem IIS-Autorisierungsmodell besser zu verstehen, sehen wir uns zunächst eine ASP.NET-Autorisierungskonfiguration an:

<authorization>
    <allow users="Vik_Malhotra" />
    <deny roles="administrators" />
    <deny users="*" />
</authorization>

In diesem Beispiel erlauben wir Vik_Malhotra, aber wir verweigern allen anderen die Teilnahme. Im IIS ist die Konfiguration sehr ähnlich:

<authorization>
    <add accessType="allow" users="Vik_Malhotra" />
    <add accessType="deny" roles="administrators" />
    <add accessType="deny" users="*" />
</authorization>

Der Grund für die Änderung der Syntax war, dass wir sicherstellen wollten, dass Anwendungsentwickler wissen, dass diese beiden Modelle tatsächlich unterschiedlich sind, sie aber gleichzeitig mit minimalem Aufwand Regeln von einer Implementierung in die andere übertragen können.

SSL

In IIS 6.0 hatte IIS SSL-bezogene Informationen in der Metabasis gespeichert und einen großen Teil des SSL-Aushandlungsprozesses in Verbindung mit HTTP.SYS verwaltet. In IIS 7 und höher haben wir den größten Teil dieser Konfiguration in den Speicher von HTTP.SYS verschoben.

Um zu veranschaulichen, wie die einzelnen Einstellungen der IIS 6.0-Konfiguration in die Konfiguration von IIS 7 und höher (oder die HTTP.SYS-Konfiguration) übernommen werden, wurde die folgende Tabelle erstellt.

IIS 6.0 Metabase-Konfiguration	Beschreibung der Eigenschaft	Architektur von IIS 7.0 und höher
AccessSSLFlags	AccessSSLFlags ist eine Bitmaske von AccessSSL AccessSSL128 AccessSSLNegotiateCert AccessSSLRequireCert AccessSSLMapCert Ein Wert von 0 bedeutet kein SSL.	Diese Eigenschaft wird in der Konfiguration von IIS 7.0 und höher im Bereich <Zugriff> noch unterstützt
CertCheckMode	Aktivieren oder deaktivieren Sie die CRL-Prüfung (Zertifikatswiderrufsliste).	Dieser Wert wird nun in http.sys im Objekt PHTTP_SERVICE_CONFIG_SSL_PARAM gespeichert.
RevocationFreshnessTime	Wenn die Eigenschaft RevocationFreshnessTime auf 1 (true) gesetzt ist, wird die Zertifikatswiderrufsliste (CRL) auf dem Zertifikats-Client durch die CRL von der Gegenstelle aktualisiert, auch wenn die CRL, die auf dem Zertifikats-Client zwischengespeichert ist, gültig ist. Das Standardintervall für die Zeitüberschreitung beträgt einen Tag, es sei denn, Sie verwenden die Option RevocationURLRetrievalTimeout, um ein anderes Zeitintervall (in Minuten) anzugeben.	Dieser Wert wird nun in http.sys im Objekt PHTTP_SERVICE_CONFIG_SSL_PARAM gespeichert.
SecureBindings	Die SecureBindings Eigenschaft gibt eine Zeichenfolge an, die von IIS verwendet wird, um zu bestimmen, welche sicheren Netzwerkendpunkte von der Serverinstanz verwendet werden.	Diese Eigenschaft wird in der Konfiguration von IIS 7.0 und höher unter dem Abschnitt <Bindung> für <Sites> weiterhin unterstützt. Das verwendete Protokoll muss "https" sein.
SSLAlwaysNegoClientCert	Die Eigenschaft SSLAlwaysNegoClientCert steuert die Aushandlung von SSL-Client-Verbindungen. Wenn diese Eigenschaft auf true gesetzt ist, handelt der Server jedes Mal, wenn SSL-Verbindungen ausgehandelt werden, sofort ein Client-Zertifikat aus, um eine teure Neuaushandlung zu vermeiden. Die Einstellung SSLAlwaysNegoClientCert hilft auch, Deadlocks bei der Neuverhandlung von Client-Zertifikaten zu vermeiden, die auftreten können, wenn ein Client beim Empfang einer Neuverhandlungsanforderung beim Senden eines großen Anforderungstexts blockiert wird.	Dieser Wert wird nun in http.sys im Objekt PHTTP_SERVICE_CONFIG_SSL_PARAM gespeichert.
SSLCertHash	Die Eigenschaft SSLCertHash wird verwendet, um den Hash-Wert des verwendeten SSL-Zertifikats zu speichern.	Dieser Wert wird nun in http.sys im Objekt PHTTP_SERVICE_CONFIG_SSL_PARAM gespeichert.
SslCtlIdentifier	Die SslCtlIdentifier-Eigenschaft enthält einen eindeutigen Wert, der eine bestimmte Zertifikatvertrauensliste (Certificate Trust List, CTL) identifiziert. Er muss zusammen mit SslCtlStoreName verwendet werden, um eine CTL genau zu referenzieren.	Dieser Wert wird nun in http.sys im Objekt PHTTP_SERVICE_CONFIG_SSL_PARAM gespeichert.
SslCtlStoreName	Die SslCtlStoreName-Eigenschaft enthält den Namen des CryptoAPI-Speichers, der Zertifikatvertrauenslisten (Certificate Trust Lists, CTL) enthält. Er muss zusammen mit SslCtlIdentifier verwendet werden, um eine CTL genau zu referenzieren.	Dieser Wert wird nun in http.sys im Objekt PHTTP_SERVICE_CONFIG_SSL_PARAM gespeichert.
SSLStoreName	Die Eigenschaft SSLStoreName wird verwendet, um den Namen des Speichers zu speichern, in dem sich das Schlüsselpaar des Zertifikats befindet.	Dieser Wert wird nun in http.sys im Objekt PHTTP_SERVICE_CONFIG_SSL_PARAM gespeichert.
SslUseDsMapper	Die Eigenschaft SslUseDsMapper gibt an, ob IIS den Windows Directory Service-Zertifikat-Mapper oder den IIS-Zertifikat-Mapper verwenden soll. Wenn SSLUseDSMapper auf false gesetzt ist, verwendet IIS den IIS-Zertifikat-Mapper.	Dieser Wert wird nun in http.sys im Objekt PHTTP_SERVICE_CONFIG_SSL_PARAM gespeichert.

Weitere Informationen über das Objekt HTTP.SYS PHTTP_SERVICE_CONFIG_SSL_PARAM finden Sie in der folgenden Dokumentation.

All diese Änderungen werden transparent und unbemerkt durchgeführt, so dass Sie als Serveradministrator nichts Besonderes tun müssen – IIS erledigt alles für Sie. Wenn Sie Anwendungen haben, die auf die alten IIS 6.0-Eigenschaften zugreifen, die sich jetzt im Konfigurationsspeicher von HTTP.SYS befinden, sorgt unsere ABO-Mapper-Schnittstelle dafür, dass die richtigen Werte gelesen/geschrieben werden, so dass Ihre Anwendungen nicht fehlschlagen, sondern weiterhin funktionieren.

Webdiensterweiterung-Einschränkungsliste

In IIS 7 und höher wurde diese Funktion geringfügig geändert, so dass ihr Name jetzt "isapiCgiRestrictionList" lautet -- aber ansonsten verhält sie sich wie in IIS 6.0.

Der Grund für diese Änderung war die Betonung der tatsächlichen Verwendung. In IIS 6.0 wurde diese Funktion hinzugefügt, um sicherzustellen, dass bösartige ISAPI- oder CGI-Binärdateien nicht auf Ihre IIS-Server kopiert und dann ausgeführt werden können. Mit der Umgestaltung für IIS 7 und höher haben wir zwei unterstützte Modelle:

Die „klassische“ ISAPI-Pipeline
Die neue integrierte Pipeline

Wenn wir uns in der "klassischen" ISAPI-Pipeline befinden, wird alles weiterhin so funktionieren, wie Sie es bei der Verwendung von IIS 6.0 erwarten würden. Um diesen Punkt zu veranschaulichen, betrachten Sie, wie ASP.NET im ISAPI-Modus funktioniert. Fügen Sie zunächst den vollständigen Pfad der aspnet_isapi.dll hinzu und setzen Sie allowed="true" wie unten gezeigt:

<isapiCgiRestriction>
    <add path="F:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
    allowed="true" groupId="ASP.NET v2.0.50727" description="ASP.NET v2.0.50727" />
</isapiCgiRestriction>

Jetzt, und nur jetzt, wird dieser Code (aspnet_isapi.dll) zur Ausführung zugelassen. Wenn wir unseren Pipeline-Modus auf integriert umstellen und allowed="false" ändern, wird der ASP.NET-Code trotzdem ausgeführt.

Warum? Der Grund dafür ist, dass die isapiCgiRestrictionList nur für ISAPI- und CGI-Code gilt. Im integrierten Modus ist ASP.NET jetzt Teil der neuen Architektur und ist daher nicht von der isapiCgiRestrictionList betroffen. Wenn Sie keinen ASP.NET-Code in der neuen integrierten Pipeline ausführen möchten, müssen Sie einfach die managedEngine aus der Liste der Module entfernen.

IP-Beschränkungen

IP-Einschränkungen funktionieren genauso wie in der Vergangenheit, außer dass wir jetzt eine neue Eigenschaft namens "allowUnlisted" unterstützen. Diese Eigenschaft wurde hinzugefügt, um die Konfiguration von Sicherheitsrichtlinien für Ihr System auf globaler Ebene zu erleichtern. Wenn Ihre Richtlinie beispielsweise vorschreibt, dass nur bestimmte IP-Adressen zugelassen werden, aber alle anderen, die nicht in der Liste aufgeführt sind, abgelehnt werden sollen, war das in der Vergangenheit nicht so einfach zu bewerkstelligen. Auch das Ablehnen einer bestimmten Gruppe von IP-Adressen und das Zulassen aller nicht aufgelisteten Adressen ist jetzt problemlos möglich. Als Serveradministrator können Sie eine globale Richtlinie festlegen und diesen Wert dann sperren, damit er auf Ihrem Server nicht von Anwendungs- oder Site-Administratoren geändert werden kann.

Nehmen Sie zur Veranschaulichung einen Entwicklungscomputer, auf den die Benutzer nur lokal zugreifen können sollen. Die folgende Konfiguration setzt diese Richtlinie um, indem sie allowUnlisted="false" setzt und dann explizit nur den Zugriff auf localhost (127.0.0.1) erlaubt:

<system.webServer>
    <security>
        <ipSecurity allowUnlisted="false">
            <add ipAddress="127.0.0.1" allowed="true" />
        </ipSecurity>
    </security>
</system.webServer>

Freigeben über