Freigeben über


Kategorisieren von mehrschichtigen Dienstanbietern und Apps

Hinweis

Mehrschicht-Dienstanbieter sind veraltet. Ab Windows 8 und Windows Server 2012 verwenden Sie die Windows-Filterplattform.

 

Winsock 2 ermöglicht mehrschichtige Protokolle. Ein mehrschichtiges Protokoll ist ein Protokoll, das nur Kommunikationsfunktionen auf höherer Ebene implementiert, während es sich für den eigentlichen Datenaustausch mit einem entfernten Endpunkt auf einen zugrunde liegenden Transportstapel stützt. Ein Beispiel für ein mehrschichtiges Protokoll oder einen mehrschichtigen Dienstanbieter wäre eine Sicherheitsebene, die dem Verbindungsaufbau ein zusätzliches Protokoll hinzufügt, um eine Authentifizierung durchzuführen und ein gemeinsam vereinbartes Verschlüsselungsverfahren einzurichten. Ein solches Sicherheitsprotokoll erfordert in der Regel die Dienste eines zugrunde liegenden zuverlässigen Transportprotokolls wie TCP oder SPX. Der Begriff Basisprotokoll, das von einem Basisanbieter implementiert wird, bezieht sich auf einen Winsock-Anbieter, der ein Protokoll wie TCP oder SPX implementiert, das in der Lage ist, Datenkommunikation mit einem entfernten Endpunkt durchzuführen. Der Begriff mehrschichtiges Protokoll wird verwendet, um ein Protokoll zu beschreiben, das nicht allein stehen kann. Diese mehrschichtigen Protokolle werden als Winsock Layered Service Providers (LSPs) installiert.

Ein Beispiel für einen LSP ist der Microsoft Firewall Clientdienstanbieter, der als Teil des Internet Security and Authentication Servers (ISA) auf Clients installiert ist. Der Microsoft Firewall Clientdienstanbieter wird über die Winsock-Basisanbieter für TCP und UDP installiert. Eine Dynamic Link Library (DLL) in der ISA Firewallclient-Software wird zu einem Winsock-Schichtdienstanbieter, den alle Winsock-Anwendungen transparent verwenden. Auf diese Weise kann der ISA Firewallclient LSP Winsock-Funktionsaufrufe von Clientanwendungen abfangen und dann eine Anforderung an den ursprünglichen zugrunde liegenden Basisdienstanbieter weiterleiten, wenn das Ziel lokal ist, oder an den Firewalldienst auf einem ISA Server-Computer, wenn das Ziel remote ist. Ein ähnlicher LSP wird als Teil des Microsoft Forefront Firewall Service und des TMG-Client (Threat Management Gateway) auf den Clients installiert.

Während der LSP-Initialisierung muss der LSP Zeiger auf eine Reihe von Winsock Service Provider Interface (SPI)-Funktionen bereitstellen. Diese Funktionen werden während der normalen Verarbeitung von der Schicht direkt über dem LSP (entweder von einem anderen LSP oder von Ws2_32.DLL) aufgerufen.

Es ist möglich, LSP-Kategorien zu definieren, die auf der Teilmenge der SPI-Funktionen basieren, die ein LSP implementiert, sowie auf der Art der zusätzlichen Verarbeitung, die für jede dieser Funktionen durchgeführt wird. Durch die Klassifizierung von LSPs sowie die Klassifizierung von Anwendungen, die Winsock-Sockets verwenden, ist es möglich, selektiv zu bestimmen, ob ein LSP zur Laufzeit an einem bestimmten Prozess beteiligt sein soll.

Unter Windows Vista und höher gibt es eine neue Methode zur Kategorisierung von mehrschichtigen Winsock-Dienstanbietern und -Anwendungen, so dass nur bestimmte LSPs geladen werden. Es gibt mehrere Gründe für das Hinzufügen dieser Features.

Einer der Hauptgründe dafür ist, dass bestimmte systemkritische Prozesse wie winlogon und lsass zwar Sockets erstellen, diese Prozesse diese Sockets aber nicht verwenden, um Datenverkehr über das Netzwerk zu senden. Daher sollten die meisten LSPs nicht in diese Prozesse geladen werden. Es wurde auch eine Reihe von Fällen dokumentiert, in denen fehlerhafte LSPs zum Absturz von lsass.exe führen können. Wenn lsass abstürzt, erzwingt das System ein Herunterfahren. Ein Nebeneffekt dieser Systemprozesse, die LSPs laden, ist, dass diese Prozesse nie beendet werden. Wenn also ein LSP installiert oder entfernt wird, ist ein Neustart erforderlich.

Ein zweiter Grund ist, dass es Fälle gibt, in denen Anwendungen bestimmte LSPs nicht laden möchten. Einige Anwendungen möchten beispielsweise keine kryptografischen LSPs laden, was die Kommunikation der Anwendung mit anderen Systemen, auf denen die kryptografischen LSPs nicht installiert sind, verhindern könnte.

Schließlich können LSP-Kategorien von anderen LSPs verwendet werden, um zu bestimmen, wo in der Winsock-Protokollkette sie sich selbst installieren sollen. Seit Jahren wünschen sich verschiedene LSP-Entwickler*innen eine Möglichkeit zu wissen, wie sich ein LSP verhalten wird. Ein LSP, der den Datenstrom prüft, sollte beispielsweise über einem LSP liegen, der die Daten verschlüsselt. Natürlich ist diese Methode der LSP-Kategorisierung nicht narrensicher, da sie sich darauf verlässt, dass LSPs von Drittanbietern sich selbst angemessen kategorisieren.

Die LSP-Kategorisierung und andere Sicherheitsverbesserungen in Windows Vista und höher sollen verhindern, dass Benutzer*innen unbeabsichtigt bösartige LSPs installieren.

LSP-Kategorien

Unter Windows Vista und höher kann ein LSP auf der Grundlage seiner Interaktion mit Windows Sockets-Aufrufen und -Daten klassifiziert werden. Eine LSP-Kategorie ist eine identifizierbare Gruppe von Verhaltensweisen für eine Teilmenge der Winsock SPI-Funktionen. Ein HTTP-Inhaltsfilter würde beispielsweise als Dateninspektor eingestuft werden (Kategorie LSP_INSPECTOR). Die Kategorie LSP_INSPECTOR prüft (aber verändert nicht) die Parameter der SPI-Funktionen zur Datenübertragung. Eine Anwendung kann die Kategorie eines LSP abfragen und sich basierend auf der LSP-Kategorie und des Set der erlaubten LSP-Kategorien der Anwendung dafür entscheiden, den LSP nicht zu laden.

In der folgenden Tabelle sind Kategorien für LSPs aufgeführt.

LSP-Kategorie Beschreibung
LSP_CRYPTO_COMPRESS Der LSP ist ein Kryptografie- oder Datenkomprimierungsanbieter.
LSP_FIREWALL Der LSP ist ein Firewallanbieter.
LSP_LOCAL_CACHE Der LSP ist ein lokaler Cacheanbieter.
LSP_INBOUND_MODIFY Der LSP ändert eingehende Daten.
LSP_INSPECTOR Der LSP prüft oder filtert Daten.
LSP_OUTBOUND_MODIFY Der LSP ändert ausgehende Daten.
LSP_PROXY Der LSP fungiert als Proxy und leitet Pakete um.
LSP_REDIRECTOR Der LSP ist ein Netzwerkumleitungsmodul.
LSP_SYSTEM Der LSP ist für die Verwendung in Diensten und Systemprozessen akzeptabel.

 

Ein LSP kann zu mehreren Kategorien gehören. Zum Beispiel könnte ein Firewall/Sicherheits-LSP gleichzeitig zu den Kategorien Inspektor (LSP_INSPECTOR) und Firewall (LSP_FIREWALL) gehören.

Wenn für einen LSP keine Kategorie festgelegt ist, zählt er zur Kategorie „Alle anderen“. Diese LSP-Kategorie wird in Diensten oder Systemprozessen nicht geladen (z. B. lsass, winlogon und viele svchost-Prozesse).

Kategorisieren von LSPs

Zur Kategorisierung eines LSP stehen unter Windows Vista und höher mehrere neue Funktionen zur Verfügung:

Um einen LSP zu kategorisieren, wird die Funktion WSCSetProviderInfo oder WSCSetProviderInfo32 mit einer GUID aufgerufen, um den versteckten LSP-Eintrag, die Informationsklasse, die für diesen LSP-Protokolleintrag gesetzt werden soll, und eine Reihe von Flags zu identifizieren, mit denen das Verhalten der Funktion geändert werden kann.

Die Funktion WSCGetProviderInfo oder WSCGetProviderInfo32 wird ebenfalls verwendet, um die mit einer Informationsklasse für einen LSP verbundenen Daten abzurufen.

Kategorisieren von Anwendungen

Ab Windows Vista gibt es mehrere neue Funktionen zur Kategorisierung einer Anwendung:

Um eine Anwendung zu kategorisieren, wird die Funktion WSCSetApplicationCategory mit dem Ladepfad zum ausführbaren Image aufgerufen, um die Anwendung, die Befehlszeilenargumente, die beim Starten der Anwendung verwendet werden, und die LSP-Kategorien, die für alle Instanzen dieser Anwendung zulässig sind, zu identifizieren.

Die Funktion WSCGetApplicationCategory wird ebenfalls verwendet, um die Kategorien der mehrschichtigen Dienstanbieter (LSP) abzurufen, die mit einer Anwendung verbunden sind.

Bestimmen, welche LSPs geladen werden

Der letzte Schritt der LSP-Kategorisierung ist die Festlegung, welche LSPs in welche Prozesse geladen werden. Wenn ein Prozess Winsock lädt, werden zwischen der Anwendungskategorie und den LSP-Kategorien die folgenden Vergleiche für alle installierten LSPs durchgeführt:

  • Wenn die Anwendung nicht kategorisiert ist, können alle LSPs in den Prozess geladen werden.
  • Wenn sowohl der Anwendung als auch dem LSP Kategorien zugewiesen wurden, muss folgendes erfüllt sein:
    Mindestens eine der LSP-Kategorien muss unter den von der Anwendung angegebenen Kategorien vorhanden sein.
    Nur die Kategorien, die als Kategorien der Anwendung angegeben sind, werden in den LSP-Kategorien angegeben. Wenn die Anwendung z. B. eine Kategorie angibt, muss diese der Kategorie des LSP entsprechen.
    Wenn die Kategorie LSP_SYSTEM als Kategorie in der Anwendung vorhanden ist, muss sie auch unter den Kategorien des LSP vorhanden sein.

Hinweis

Wenn ein LSP nicht kategorisiert ist, ist seine Kategorie effektiv null. Damit eine Übereinstimmung zustande kommt, müssen alle vom LSP angegebenen Kategorien in den Kategorien der Anwendung vorhanden sein (die Kategorien der Anwendung müssen eine Obermenge der Kategorien des LSP sein), mit der Einschränkung, dass, wenn LSP_SYSTEM in der Kategorie der Anwendung vorhanden ist, es auch in der Kategorie des LSP vorhanden sein muss.

 

Sehen Sie sich das folgende Beispiel an:

Die Anwendung Foo.exe wird als LSP_SYSTEM + LSP_FIREWALL + LSP_CRYPTO_COMPRESS kategorisiert. Die Anwendung Bar.exe wird als LSP_FIREWALL + LSP_CRYPTO_COMPRESS kategorisiert. Auf dem System sind vier LSPs installiert:

  • Für LSP1 wurde die Kategorie LSP_SYSTEM festgelegt.
  • Für LSP2 ist keine Kategorien festgelegt, sodass die Kategorie null ist.
  • Für LSP3 wurde die Kategorie LSP_FIREWALL festgelegt.
  • Für LSP4 wurden die Kategorien LSP_SYSTEM + LSP_FIREWALL + LSP_CRYPTO_COMPRESS + LSP_INSPECTOR festgelegt.

In diesem Beispiel würde die Anwendung Foo.exe nur LSP1 laden, während die Anwendung Bar.exe LSP3 laden würde.

Ermitteln der installierten Winsock-Anbieter

Das Microsoft Windows Software Development Kit (SDK) enthält ein Winsock-Beispielprogramm, mit dem Sie die auf einem lokalen Computer installierten Winsock-Transportanbieter ermitteln können. Für Windows 7 wird der Quellcode für dieses Winsock-Beispiel standardmäßig in das folgende Verzeichnis des Windows SDK installiert:

C:\Programme\Microsoft SDKs\Windows\v7.0\Samples\NetDs\winsock\LSP

Dieses Beispiel ist ein Hilfsprogramm zum Installieren und Testen von mehrschichtigen Dienstanbietern. Es kann aber auch verwendet werden, um programmgesteuert detaillierte Informationen aus dem Winsock-Katalog auf einem lokalen Computer zu sammeln. Um alle aktuellen Winsock-Anbieter aufzulisten, sowohl die Basisanbieter als auch die Anbieter von Layer-Diensten, erstellen Sie dieses Winsock-Beispiel und führen Sie den folgenden Konsolenbefehl aus:

instlsp -p

Die Ausgabe ist eine Liste der Winsock-Anbieter, die auf dem lokalen Computer installiert sind, einschließlich der mehrschichtigen Dienstanbieter. Die Ausgabe listet die Katalog-ID und den Namen für den Winsock-Anbieter als Zeichenfolge auf.

Führen Sie den folgenden Konsolenbefehl aus, um ausführlichere Informationen zu allen Winsock-Anbietern zu erhalten:

instlsp -p -v

Die Ausgabe ist eine Liste der WSAPROTOCOL_INFO-Strukturen, die auf dem lokalen Computer unterstützt werden.

Eine Liste der Dienstanbieter, die auf dem lokalen Computer installiert sind, erhalten Sie, wenn Sie den folgenden Konsolenbefehl ausführen:

instlsp -l

Um die LSP-Struktur abzubilden, führen Sie den folgenden Konsolenbefehl aus:

instlsp -m

Hinweis

Die TDI-Funktion ist veraltet und wird in zukünftigen Versionen von Microsoft Windows entfernt werden. Je nachdem, wie Sie TDI einsetzen, verwenden Sie entweder den Winsock Kernel (WSK) oder die Windows-Filterplattform (WFP). Weitere Informationen zu WFP und WSK finden Sie unter Windows-Filterplattform und Winsock Kernel. Einen Blogeintrag von Windows Core Networking über WSK und TDI finden Sie unter Einführung in den Winsock Kernel (WSK).