Sécurité RPC sur HTTP

RPC sur HTTP fournit trois types de sécurité en plus de la sécurité RPC standard. Ainsi, le trafic RPC sur HTTP est protégé par RPC, puis est protégé doublement par le mécanisme de tunneling fourni par RPC sur HTTP. Pour une description des mécanismes de sécurité RPC standard, consultez Sécurité. Le mécanisme de tunneling RPC sur HTTP s’ajoute à la sécurité RPC normale de la façon suivante :

• Assure la sécurité via IIS (disponible uniquement pour RPC sur HTTP v2).
• Assure le chiffrement SSL et la vérification du proxy RPC (authentification mutuelle). Également disponible au format RPC sur HTTP v2 uniquement.
• Fournit des restrictions au niveau du proxy RPC, qui indiquent quelles sont les machines du réseau du serveur autorisées à recevoir les appels RPC sur HTTP.

Chacune de ces trois fonctionnalités de sécurité est décrite plus en détail dans les sections suivantes.

Authentification IIS

RPC sur HTTP peut tirer parti du mécanisme d’authentification normal d’IIS. Le répertoire virtuel du proxy RPC peut être configuré à l’aide du nœud Rpc sous le site web par défaut dans le composant logiciel enfichable MMC IIS :

IIS peut être configuré pour désactiver l’accès anonyme et imposer une authentification auprès du répertoire virtuel pour le proxy RPC. Pour ce faire, cliquez avec le bouton droit sur le nœud Rpc, puis sélectionnez Propriétés. Sélectionnez l’onglet Sécurité du répertoire, puis cliquez sur le bouton Modifier dans le groupe Authentification et contrôle d’accès, comme indiqué ici :

Bien que vous puissiez utiliser RPC sur HTTP même quand le répertoire virtuel du proxy RPC autorise l’accès anonyme, Microsoft recommande vivement de désactiver l’accès anonyme à ce répertoire virtuel pour des raisons de sécurité. À la place, pour RPC sur HTTP, activez l’authentification de base ou l’authentification Windows intégrée, ou les deux. N’oubliez pas que seul RPC sur HTTP v2 peut s’authentifier auprès d’un proxy RPC nécessitant une authentification de base ou une authentification Windows intégrée. RPC sur HTTP v1 ne peut pas se connecter si la fonctionnalité Interdire l’accès anonyme est désactivée. Dans la mesure où RPC sur HTTP v2 est l’implémentation la plus sécurisée et la plus robuste, l’utilisation d’une version de Windows qui prend en charge ce protocole permet d’améliorer la sécurité de vos installations.

Chiffrement du trafic

RPC sur HTTP peut chiffrer le trafic entre le client RPC sur HTTP et le proxy RPC avec SSL. Le trafic entre le proxy RPC et le serveur RPC sur HTTP est chiffré à l’aide des mécanismes de sécurité RPC normaux, et n’utilise pas SSL (même si SSL entre le client et le proxy RPC est choisi). En effet, cette partie du trafic transite au sein du réseau d’une organisation et derrière un pare-feu.

Le trafic entre le client RPC sur HTTP et le proxy RPC, qui transite généralement par Internet, peut être chiffré avec SSL, en plus du mécanisme de chiffrement choisi pour RPC. Dans ce cas, le trafic sur la partie Internet de la route fait l’objet d’un chiffrement double. Le chiffrement du trafic via le proxy RPC fournit une défense secondaire, au cas où le proxy RPC ou d’autres machines du réseau de périmètre seraient compromis. Dans la mesure où le proxy RPC ne peut pas déchiffrer la couche de chiffrement secondaire, le proxy RPC n’a pas accès aux données envoyées. Pour plus d’informations, consultez Recommandations pour le déploiement de RPC sur HTTP. Le chiffrement SSL est disponible uniquement avec RPC sur HTTP v2.

Restriction des appels RPC sur HTTP à certains ordinateurs

La configuration de la sécurité d’IIS est basée sur les plages d’ordinateurs et de ports autorisées. L’utilisation de RPC sur HTTP est contrôlée par deux entrées de Registre sur l’ordinateur qui exécute IIS et le proxy RPC. La première entrée est un indicateur qui permet d’activer/de désactiver la fonctionnalité de proxy RPC. La seconde est une liste facultative d’ordinateurs vers lesquels le proxy peut réacheminer les appels RPC.

Par défaut, un client qui contacte le proxy RPC pour tunneliser les appels RPC sur HTTP ne peut accéder à aucun processus serveur RPC, à l’exception des processus serveur RPC sur HTTP s’exécutant sur la même machine que le proxy RPC. Si l’indicateur ENABLED n’est pas défini, ou si sa valeur n’est pas égale à zéro, IIS désactive le proxy RPC. Si l’indicateur ENABLED est défini et s’il a une valeur différente de zéro, un client peut se connecter aux serveurs RPC sur HTTP sur l’ordinateur qui exécute IIS. Pour permettre au client d’établir un tunnel vers un processus serveur RPC sur HTTP sur un autre ordinateur, vous devez ajouter une entrée de Registre à la liste des serveurs RPC sur HTTP de l’ordinateur IIS.

Les serveurs RPC ne peuvent pas accepter les appels RPC sur HTTP, sauf s’ils ont spécifiquement demandé à RPC d’écouter RPC sur HTTP.

L’exemple suivant montre comment configurer le Registre pour permettre aux clients de se connecter aux serveurs via Internet :

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

L’entrée ValidPorts est une entrée REG_SZ contenant une liste des ordinateurs vers lesquels le proxy RPC IIS est autorisé à réacheminer les appels RPC ainsi que des ports qu’il doit utiliser pour se connecter aux serveurs RPC. L’entrée REG_SZ prend la forme suivante : Rosco:593;Rosco:2000-8000;Data*:4000-8000.

Dans cet exemple, IIS peut réacheminer les appels RPC sur HTTP vers le serveur « Rosco » sur le port 593 ainsi que sur les ports allant de 2000 à 8000. Il peut également envoyer des appels à tout serveur dont le nom commence par « Data ». Il se connecte sur les ports 4000 à 8000. De plus, avant de réacheminer le trafic vers un port donné sur le serveur RPC sur HTTP, le proxy RPC effectue un échange de paquets spécial avec le service RPC à l’écoute sur ce port pour vérifier qu’il est prêt à accepter les requêtes sur HTTP.

Dans le cadre de ces exemples de paramètres, si un service RPC est à l’écoute sur le port 4500 du serveur « Data1 », mais qu’il n’a appelé aucune des fonctions RpcServerUseProtseq* avec ncacn_http, il rejette la requête. Ce comportement fournit une protection supplémentaire pour les serveurs qui sont à l’écoute sur un port ouvert en raison d’une erreur de configuration. À moins que le serveur ne doive spécifiquement écouter RPC sur HTTP, il ne reçoit pas les appels provenant de l’extérieur du pare-feu.

Les entrées de la clé ValidPorts doivent correspondre exactement au serveur RPC sur HTTP demandé par le client (pas de respect de la casse). Pour simplifier le traitement, le proxy RPC n’effectue pas de canonisation du nom fourni par le client RPC sur HTTP. Ainsi, si le client demande rosco.microsoft.com et si ValidPorts contient uniquement Rosco, le proxy RPC n’établit pas de correspondance entre les noms, même si les deux noms peuvent faire référence à la même machine. De plus, si l’adresse IP de Rosco est 66.77.88.99, et si le client demande le 66.77.88.99, mais que la clé ValidPorts contient uniquement Rosco, le proxy RPC refuse la connexion. Si un client peut demander le serveur RPC sur HTTP en fonction de son nom ou de son adresse IP, indiquez les deux dans la clé ValidPorts.

IIS lit les entrées de Registre Enabled et ValidPorts au démarrage. De plus, RPC sur HTTP relit le contenu de la clé ValidPorts toutes les 5 minutes environ. Si l’entrée ValidPorts change, les changements sont implémentés en moins de 5 minutes.

RPC sur HTTP v1 : Le service web doit être arrêté et redémarré à l’aide du Gestionnaire des services Internet pour que les nouvelles valeurs des entrées de Registre soient implémentées.