Recommandations de déploiement RPC sur HTTP

Cette section documente les meilleures pratiques et les configurations de déploiement recommandées pour obtenir une sécurité et des performances maximales lors de l’utilisation de RPC sur HTTP. Les différentes configurations trouvées ici s’appliquent à différentes organisations en fonction de la taille, du budget et des exigences de sécurité différentes. Chaque configuration fournit également des considérations de déploiement utiles pour déterminer lequel est le mieux adapté à un scénario donné.

Pour plus d’informations sur les scénarios RPC sur HTTP à volume élevé, consultez Équilibrage de charge MICROSOFT RPC.

Les recommandations suivantes s’appliquent à toutes les configurations :

• Utilisez des versions de Windows qui prennent en charge RPC sur HTTP v2.
• Placez IIS sur l’ordinateur qui exécute le proxy RPC en mode IIS 6.0.
• Interdire l’accès anonyme au répertoire virtuel du proxy RPC.
• N’activez jamais la clé de Registre AllowAnonymous.
• Faites en sorte que vos clients RPC sur HTTP utilisent certificateSubjectField (voir RpcBindingSetAuthInfoEx pour plus d’informations) pour vérifier que le proxy RPC auquel vous vous êtes connecté est le proxy RPC attendu.
• Configurez la clé de Registre ValidPorts pour qu’elle contienne uniquement les machines auxquelles les clients RPC sur HTTP se connecteront.
• N’utilisez pas de caractères génériques dans la clé ValidPorts ; Cela peut faire gagner du temps, mais une machine complètement inattendue peut également correspondre au caractère générique.
• Utilisez SSL sur les clients RPC sur HTTP. Si les instructions définies dans ces sections sont suivies, le client RPC sur HTTP ne pourra pas se connecter sans utiliser SSL.
• Configurez les clients RPC sur HTTP pour utiliser le chiffrement RPC en plus de l’utilisation de SSL. Si le client RPC sur HTTP ne peut pas atteindre le KDC, il peut utiliser uniquement Negotiate et NTLM.
• Configurez les ordinateurs clients pour qu’ils utilisent NTLMv2. Définissez la clé de Registre LMCompatibilityLevel sur 2 ou une valeur supérieure. Consultez msdn.microsoft.com pour plus d’informations sur la clé LMCompatibilityLevel .
• Exécutez une batterie de serveurs web de machines proxy RPC avec la configuration décrite ci-dessus.
• Déployez un pare-feu entre Internet et le proxy RPC.
• Pour des performances optimales, configurez IIS pour envoyer une réponse courte pour les codes d’erreur non réussis. Étant donné que le consommateur de la réponse IIS est un processus automatisé, il n’est pas nécessaire d’envoyer des explications conviviales au client . ils seront simplement ignorés par le client RPC sur HTTP.

Les objectifs de base du proxy RPC du point de vue de la sécurité, des performances et de la facilité de gestion sont les suivants :

• Fournissez un point d’entrée unique pour le trafic RPC sur HTTP dans le réseau du serveur. Le fait d’avoir un point d’entrée unique pour le trafic RPC sur HTTP dans un réseau de serveur présente deux avantages main. Tout d’abord, étant donné que le proxy RPC est accessible sur Internet, la plupart des organisations isolent ces machines dans un réseau spécial appelé réseau de périmètre non approuvé qui est distinct du réseau organisationnel normal. Les serveurs d’un réseau de périmètre non approuvé sont très soigneusement gérés, configurés et surveillés pour pouvoir résister aux attaques provenant d’Internet. Moins il y a de machines dans un réseau de périmètre non approuvé, plus il est facile de les configurer, de les gérer, de les surveiller et de les sécuriser. Deuxièmement, étant donné qu’une seule batterie de serveurs Web avec des proxys RPC installés peut traiter n’importe quel nombre de serveurs RPC sur HTTP résidant sur le réseau d’entreprise, il est très judicieux de séparer le proxy RPC du serveur RPC sur HTTP et de faire résider le proxy RPC dans un réseau de périmètre non approuvé. Si le proxy RPC se trouvait sur la même machine que le serveur RPC sur HTTP, les organisations seraient obligées de placer tous leurs serveurs principaux dans un réseau de périmètre non approuvé, ce qui compliquerait considérablement la sécurisation du réseau de périmètre non approuvé. La séparation du rôle du proxy RPC et du serveur RPC sur HTTP permet aux organisations de conserver le nombre de machines dans un réseau de périmètre non approuvé gérable et, par conséquent, plus sécurisé.
• Servir de fusible de sécurité pour le réseau du serveur. Le proxy RPC est conçu comme un fusible pour le réseau du serveur : en cas de problème sur le proxy RPC, il s’éteint simplement et protège ainsi le serveur RPC sur HTTP réel. Si les meilleures pratiques décrites dans cette section ont été suivies jusqu’à présent, le trafic RPC sur HTTP est chiffré avec le chiffrement RPC en plus de SSL. Le chiffrement RPC lui-même se trouve entre le client et le serveur, et non entre le client et le proxy. Cela signifie que le proxy ne comprend pas et ne peut pas déchiffrer le trafic RPC qu’il reçoit. Il comprend uniquement certaines séquences de contrôle qui lui sont envoyées par le client traitant de l’établissement de la connexion, du contrôle de flux et d’autres détails de tunneling. Il n’a pas accès aux données que le client RPC sur HTTP envoie au serveur. En outre, le client RPC sur HTTP doit s’authentifier indépendamment auprès du proxy RPC et du serveur RPC sur HTTP. Cela permet une défense en profondeur. Si l’ordinateur proxy RPC est compromis, en raison d’une erreur de configuration ou d’une faille de sécurité, les données qui y transitent sont toujours protégées contre toute falsification. Un attaquant qui prend le contrôle du proxy RPC peut au maximum interrompre le trafic, mais pas le lire ou le falsifier. C’est là que le rôle de fusion du proxy RPC entre en jeu : il est utilisable sans que la sécurité du trafic RPC sur HTTP ne soit compromise.
• Distribuez une partie des vérifications d’accès et du déchiffrement entre plusieurs ordinateurs exécutant le proxy RPC dans une batterie de serveurs web. En fonctionnant correctement dans une batterie de serveurs web, le proxy RPC permet aux organisations de décharger le déchiffrement SSL et certaines vérifications d’accès, libérant ainsi plus de capacité sur le serveur principal pour le traitement. L’utilisation d’une batterie de serveurs web de machines proxy RPC permet également à un organization d’augmenter sa capacité à résister aux attaques par déni de service (DoS) en augmentant la capacité sur ses serveurs frontaux.

Dans les directives énoncées jusqu’à présent, les organisations ont encore des choix. Chaque organization a des choix et des compromis entre les inconvénients de l’utilisateur, la sécurité et le coût :

• Utilisez l’authentification de base ou l’authentification intégrée Windows pour vous authentifier auprès du proxy RPC ? RPC sur HTTP prend actuellement en charge uniquement NTLM, car il ne prend pas en charge Kerberos. En outre, s’il existe un proxy HTTP ou un pare-feu entre le client RPC sur HTTP et le proxy RPC qui insère le via pragma dans l’en-tête HTTP, l’authentification NTLM ne fonctionne pas. Lorsque ce n’est pas le cas, les organisations peuvent choisir entre l’authentification de base et l’authentification NTLM. L’avantage de l’authentification de base est qu’elle est plus rapide et plus simple, et qu’elle offre donc moins de possibilités d’attaques par déni de service. Mais NTLM est plus sécurisé. En fonction des priorités d’un organization, il peut choisir De base, NTLM ou autoriser ses utilisateurs à choisir entre les deux. Si un seul est choisi, il est préférable de désactiver l’autre du répertoire virtuel du proxy RPC pour réduire le risque d’attaque.
• Utilisez le même ensemble d’informations d’identification pour le proxy RPC et le serveur RPC sur HTTP, ou utilisez des informations d’identification différentes pour chacun d’eux ? Le compromis pour cette décision est entre la commodité et la sécurité de l’utilisateur. Peu d’utilisateurs aiment entrer plusieurs informations d’identification. Toutefois, si une violation de la sécurité se produit dans un réseau de périmètre non approuvé, le fait de disposer d’ensembles d’informations d’identification distincts pour le proxy RPC et le serveur RPC sur HTTP offre une protection supplémentaire. Notez que si des informations d’identification distinctes sont utilisées et qu’un ensemble d’informations d’identification est les informations d’identification de domaine de l’utilisateur, il est recommandé d’utiliser les informations d’identification de domaine de l’utilisateur pour le serveur RPC sur HTTP et non pour le proxy RPC.