Freigeben über

RPC über HTTP-Sicherheit

  • Artikel

RPC über HTTP bietet zusätzlich zur standardmäßigen RPC-Sicherheit drei Arten von Sicherheit, was dazu führt, dass RPC über HTTP-Datenverkehr einmal durch RPC geschützt wird, und dann doppelt durch den Tunnelingmechanismus geschützt wird, der von RPC über HTTP bereitgestellt wird. Eine Beschreibung der standardmäßigen RPC-Sicherheitsmechanismen finden Sie unter Sicherheit. Der RPC-über-HTTP-Tunnelingmechanismus erweitert die normale RPC-Sicherheit auf folgende Weise:

  • Bietet Sicherheit über die IIS (nur für RPC über HTTP v2 verfügbar).
  • Stellt SSL-Verschlüsselung und RPC-Proxyüberprüfung (gegenseitige Authentifizierung) bereit. Auch nur in RPC über HTTP v2 verfügbar.
  • Bietet Einschränkungen auf der RPC-Proxy-Ebene, die festlegen, welche Rechner im Servernetzwerk RPC over HTTP-Aufrufe empfangen dürfen.

Jedes dieser drei Sicherheitsfeatures wird in den folgenden Abschnitten genauer beschrieben.

IIS-Authentifizierung

RPC über HTTP kann den normalen Authentifizierungsmechanismus der IIS nutzen. Das virtuelle Verzeichnis für RPC-Proxy kann mithilfe des RPC-Knotens unter der Standardwebsite im IIS MMC-Snap-In konfiguriert werden:

Screenshot showing the Rpc node under the Default Web Site in the IIS MMC snap-in.

IIS können so konfiguriert werden, dass anonymer Zugriff deaktiviert wird und eine Authentifizierung für das virtuelle Verzeichnis für den RPC-Proxy erforderlich ist. Klicken Sie hierzu mit der rechten Maustaste auf den RPC-Knoten, und wählen Sie Eigenschaftenaus. Wählen Sie die Registerkarte Verzeichnissicherheit aus, und klicken Sie auf die Schaltfläche Bearbeiten in der Gruppe Authentifizierung und Zugriffssteuerung, wie hier gezeigt:

Screenshot showing the RPC Properties dialog box.

Obwohl Sie RPC über HTTP verwenden können, auch wenn das virtuelle RPC-Proxyverzeichnis anonymen Zugriff zulässt, empfiehlt Microsoft aus Sicherheitsgründen dringend, anonymen Zugriff auf dieses virtuelle Verzeichnis zu deaktivieren. Für RPC über HTTP aktivieren Sie stattdessen die Standardauthentifizierung, die integrierte Windows-Authentifizierung oder beides. Denken Sie daran, dass nur RPC über HTTP v2 in der Lage ist, sich bei RPC-Proxy zu authentifizieren, der die standardmäßige oder in Windows integrierte Authentifizierung erfordert; RPC über HTTP v1 kann keine Verbindung herstellen, wenn Anonymen Zugriff verweigern deaktiviert ist. Da RPC über HTTP v2 die sicherere und robustere Implementierung ist, erhöht die Verwendung einer Windows-Version, die diese unterstützt, die Sicherheit Ihrer Installationen.

Hinweis

Standardmäßig ist das virtuelle RPC-Proxyverzeichnis so gekennzeichnet, dass anonymer Zugriff zulässig ist. Der RPC-Proxy für RPC über HTTP v2 lehnt jedoch Anforderungen ab, die nicht standardmäßig authentifiziert sind.

 

Datenverkehrsverschlüsselung

RPC über HTTP kann Datenverkehr zwischen dem RPC-über-HTTP-Client und dem RPC-Proxy mit SSL verschlüsseln. Der Datenverkehr zwischen dem RPC-Proxy und dem RPC-über-HTTP-Server wird mit normalen RPC-Sicherheitsmechanismen verschlüsselt und verwendet SSL nicht (auch wenn SSL zwischen dem Client und dem RPC-Proxy ausgewählt wird). Der Grund dafür ist, dass dieser Teil des Datenverkehrs innerhalb des Netzwerks einer Organisation und hinter einer Firewall stattfindet.

Der Datenverkehr zwischen dem RPC-über-HTTP-Client und dem RPC-Proxy, der im Allgemeinen über das Internet übertragen wird, kann zusätzlich zu dem für RPC ausgewählten Verschlüsselungsmechanismus mit SSL verschlüsselt werden. In diesem Fall wird der Datenverkehr im Internetteil der Route doppelt verschlüsselt. Das Verschlüsseln des Datenverkehrs über den RPC-Proxy bietet eine sekundäre Verteidigung, falls der RPC-Proxy oder andere Computer im Umkreisnetzwerk kompromittiert werden. Da der RPC-Proxy die sekundäre Verschlüsselungsebene nicht entschlüsseln kann, hat der RPC-Proxy keinen Zugriff auf die gesendeten Daten. Weitere Informationen finden Sie unter Empfehlungen für die RPC-über-HTTP-Bereitstellung. SSL-Verschlüsselung ist nur mit RPC über HTTP v2 verfügbar.

Einschränken von RPC-über-HTTP-Aufrufen auf bestimmte Computer

Die IIS-Sicherheitskonfiguration basiert auf zulässigen Computer- und Portbereichen. Die Funktion zum Verwenden von RPC über HTTP wird durch zwei Registrierungseinträge auf dem Computer gesteuert, auf dem IIS und der RPC-Proxy ausgeführt werden. Der erste Eintrag ist ein Flag, mit dem die RPC-Proxyfunktionalität umgeschaltet wird. Die zweite ist eine optionale Liste von Computern, an die der Proxy RPC-Aufrufe weiterleiten kann.

Standardmäßig kann ein Client, der den RPC-Proxy kontaktiert, um RPC über HTTP-Aufrufe zu tunneln, nicht auf RPC-Serverprozesse zugreifen, mit Ausnahme der RPC-über-HTTP-Serverprozesse, die auf demselben Computer wie der RPC-Proxy ausgeführt werden. Wenn das ENABLED-Flag nicht definiert oder auf einen Nullwert festgelegt ist, deaktiviert IIS den RPC-Proxy. Wenn das ENABLED-Flag definiert und auf einen Wert ungleich Null festgelegt ist, kann ein Client eine Verbindung mit RPC-über-HTTP-Server auf dem Computer herstellen, auf dem IIS ausgeführt werden. Damit der Client in einen RPC-über-HTTP-Serverprozess auf einem anderen Computer tunneln kann, müssen Sie der IIS-Computerliste der RPC-über-HTTP-Server einen Registrierungseintrag hinzufügen.

RPC-Server können RPC-über-HTTP-Aufrufe nicht akzeptieren, es sei denn, sie forderten RPC speziell auf, RPC über HTTP zu überwachen.

Im folgenden Beispiel wird veranschaulicht, wie Sie die Registrierung so konfigurieren, dass Clients eine Verbindung mit Servern über das Internet herstellen können:

HKEY_LOCAL_MACHINE\
   Software\Microsoft\Rpc\RpcProxy\Enabled:REG_DWORD
   Software\Microsoft\Rpc\RpcProxy\ValidPorts:REG_SZ

Der Eintrag ValidPorts ist ein REG_SZ-Eintrag mit einer Liste von Computern, an die der IIS-RPC-Proxy RPC-Aufrufe weiterleiten darf, und den Ports, mit denen eine Verbindung mit den RPC-Servern hergestellt werden soll. Der REG_SZ-Eintrag hat folgende Form: Rosco:593; Rosco:2000-8000; Data*:4000-8000.

In diesem Beispiel können IIS RPC-über-HTTP-Aufrufe an den Server „Rosco“ an die Ports 593 und 2000 bis 8000 weiterleiten. Sie können auch Anrufe an jeden Server senden, dessen Name mit „Data“ beginnt. Die Verbindung erfolgt an den Ports 4000 bis 8000. Darüber hinaus führt der RPC-Proxy vor dem Weiterleiten des Datenverkehrs an einen bestimmten Port auf dem RPC-über-HTTP-Server einen speziellen Paketaustausch durch, und der RPC-Dienst überwacht diesen Port, um zu überprüfen, ob Anforderungen über HTTP akzeptiert werden.

Wenn ein RPC-Dienst an Port 4500 auf dem Server „Data1“ lauscht, aber keine der RpcServerUseProtseq*-Funktionen mit ncacn_http aufgerufen hat, wird die Anforderung abgelehnt. Dieses Verhalten bietet zusätzlichen Schutz für Server, die aufgrund eines Konfigurationsfehlers an einem geöffneten Port lauschen; es sei denn, der Server hat ausdrücklich angefordert, auf RPC über HTTP zu lauschen, empfängt er keine Anrufe, die von außerhalb der Firewall stammen.

Einträge im Schlüssel ValidPorts müssen eine genaue Übereinstimmung mit dem RPC-über-HTTP-Server sein, der vom Client angefordert wird (Groß-/Kleinschreibung wird nicht beachtet). Um die Verarbeitung zu optimieren, führt der RPC-Proxy keine Kanonisierung des Namens durch, der vom RPC-über-HTTP-Client bereitgestellt wird. Wenn der Client daher nach rosco.microsoft.com fragt und ValidPorts nur Rosco enthält, stimmt der RPC-Proxy nicht mit den Namen überein, obwohl beide Namen möglicherweise auf denselben Computer verweisen. Wenn die IP-Adresse von Rosco 66.77.88.99 lautet und der Client nach 66.77.88.99 fragt, aber der ValidPorts-Schlüssel nur Rosco enthält, lehnt der RPC-Proxy die Verbindung ab. Wenn ein Client den RPC-über-HTTP-Server nach Name oder nach IP-Adresse fragt, fügen Sie beide in den ValidPorts-Schlüssel ein.

Hinweis

Obwohl RPC IPv6 aktiviert ist, unterstützt der RPC-Proxy keine IPv6-Adressen im ValidPorts-Schlüssel. Wenn IPv6 verwendet wird, um den RPC-Proxy und den RPC-über-HTTP-Server zu verbinden, können nur DNS-Namen verwendet werden.

 

IIS liest die Registrierungseinträge Enabled und ValidPorts beim Start. Darüber hinaus liest RPC über HTTP den Inhalt des ValidPorts-Schlüssels ungefähr alle 5 Minuten neu. Wenn der Eintrag ValidPorts geändert wird, werden die Änderungen innerhalb von 5 Minuten implementiert.

RPC über HTTP v1: Der Webdienst muss beendet und neu gestartet werden, indem der Internet Service Manager verwendet wird, um neue Werte in den Registrierungseinträgen zu implementieren.