RPC via la sécurité HTTP

RPC sur HTTP fournit trois types de sécurité en plus de la sécurité RPC standard, ce qui entraîne la protection RPC sur le trafic HTTP une fois par RPC, puis doublement protégée par le mécanisme de tunneling fourni par RPC via HTTP. Pour obtenir une description des mécanismes de sécurité RPC standard, consultez de sécurité . Le mécanisme de tunneling RPC sur HTTP ajoute à la sécurité RPC normale de la manière suivante :

• Fournit la sécurité via IIS (disponible uniquement pour RPC via HTTP v2).
• Fournit le chiffrement SSL et la vérification du proxy RPC (authentification mutuelle). Disponible également dans RPC via HTTP v2 uniquement.
• Fournit des restrictions sur le niveau proxy RPC qui dicte les ordinateurs sur le réseau serveur autorisés à recevoir RPC via des appels 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 IIS MMC :

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

Bien que vous puissiez utiliser RPC sur HTTP même lorsque le répertoire virtuel 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é. Au lieu de cela, pour RPC via HTTP, activez l’authentification de base, l’authentification intégrée Windows ou les deux. N’oubliez pas que seul RPC sur HTTP v2 est en mesure de s’authentifier auprès du proxy RPC nécessitant une authentification de base ou intégrée à Windows ; RPC sur HTTP v1 ne pourra pas se connecter si interdire l’accès anonyme est désactivé. Étant donné que RPC sur HTTP v2 est l’implémentation plus sécurisée et robuste, l’utilisation d’une version de Windows qui la prend en charge améliore la sécurité de vos installations.

Chiffrement du trafic

RPC sur HTTP peut chiffrer le trafic entre le client RPC via le client HTTP et le proxy RPC avec SSL. Le trafic entre le proxy RPC et rpc sur le serveur HTTP est chiffré à l’aide de 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). Cela est dû au fait que cette partie du trafic se déplace au sein du réseau d’une organisation et derrière un pare-feu.

Le trafic entre le client RPC via le client HTTP et le proxy RPC, qui se déplace généralement sur 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 l’itinéraire devient doublement chiffré. Le chiffrement du trafic via le proxy RPC fournit une défense secondaire, au cas où le proxy RPC ou d’autres ordinateurs du réseau de périmètre sont compromis. Étant donné que 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 de déploiement RPC sur HTTP. Le chiffrement SSL est disponible uniquement avec RPC via HTTP v2.

Restriction du RPC sur les appels HTTP vers certains ordinateurs

La configuration de sécurité IIS est basée sur les plages d’ordinateurs et de ports autorisées. La fonctionnalité d’utilisation de RPC sur HTTP est contrôlée par deux entrées de Registre sur l’ordinateur exécutant IIS et le proxy RPC. La première entrée est un indicateur qui bascule la fonctionnalité de proxy RPC. La deuxième est une liste facultative d’ordinateurs auxquels le proxy peut transférer des appels RPC.

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

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

L’exemple suivant montre comment configurer le Registre pour permettre aux clients de se connecter à des serveurs sur 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 d’ordinateurs auxquels le proxy RPC IIS est autorisé à transférer des appels RPC et les 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 transférer RPC via des appels HTTP au serveur « Rosco » sur les ports 593 et 2000 à 8000. Il peut également envoyer des appels à n’importe quel serveur dont le nom commence par « Données ». Il se connecte sur les ports 4000 à 8000. En outre, avant de transférer le trafic vers un port donné sur le serveur RPC via 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 des requêtes via HTTP.

Pour obtenir un exemple basé sur ces exemples de paramètres, si un service RPC écoute le port 4500 sur le serveur « Data1 », mais n’a pas appelé l’une des fonctions RpcServerUseProtseq* avec ncacn_http, elle rejette la requête. Ce comportement fournit une protection supplémentaire pour les serveurs qui écoutent sur un port ouvert en raison d’une erreur de configuration ; sauf si le serveur a spécifiquement demandé d’écouter sur RPC via HTTP, il ne recevra pas d’appels provenant de l’extérieur du pare-feu.

Les entrées du ValidPorts clé doivent correspondre exactement au rpc sur le serveur HTTP demandé par le client (il n’est pas sensible à la casse). Pour simplifier le traitement, le proxy RPC n’effectue pas de canonisation du nom fourni par le client RPC sur HTTP. Par conséquent, si le client demande rosco.microsoft.com et, dans ValidPorts contiennent Rosco uniquement, le proxy RPC ne correspond pas aux noms, même si les deux noms peuvent faire référence à la même machine. En outre, si l’adresse IP de Rosco est 66.77.88.99 et que le client demande 66.77.88.99, mais que la clé ValidPorts contient Rosco uniquement, le proxy RPC refuse la connexion. Si un client peut demander le RPC sur le serveur HTTP par nom ou par adresse IP, insérez les deux dans la clé ValidPorts.

IIS lit les entrées de Registre activées et ValidPorts au démarrage. En outre, RPC sur HTTP réexécute le contenu du ValidPorts clé environ toutes les 5 minutes. Si l’entrée ValidPorts est modifiée, les modifications sont implémentées dans les 5 minutes.

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