Restriction des interfaces RPC

Lorsqu'une interface est enregistrée à l'aide de RpcServerRegisterIf, RPC autorise l'application serveur à limiter l'accès à l'interface, généralement au moyen d'un rappel de sécurité. La clé de Registre RestrictRemoteClients force le service RPC à effectuer des contrôles de sécurité supplémentaires pour toutes les interfaces, et ceci même pour les interfaces qui ne disposent pas de rappel de sécurité enregistré.

Les restrictions décrites dans cette section ne concernent pas les clients RPC qui utilisent la séquence de protocole des canaux nommés (ncacn_np). Cette séquence de protocole ne peut pas être limitée du fait de problèmes de compatibilité descendante importants.

La clé de Registre RestrictRemoteClients peut prendre une valeur DWORD parmi trois valeurs, qui peuvent également être contrôlées par programme dans rpcdce.h. Si la clé n'existe pas, cela équivaut à définir la valeur DWORD=0 (RPC_RESTRICT_REMOTE_CLIENT_NONE) pour les numéros SKU de serveurs et DWORD=1 (RPC_RESTRICT_REMOTE_CLIENT_AUTH) pour les numéros SKU de client.

Le tableau suivant donne les informations de référence pour la clé de Registre RestrictRemoteClients :

Il est beaucoup plus difficile d'attaquer une interface lorsqu'une authentification est requise, même s'il s'agit d'un niveau d'authentification relativement faible. L'activation de RestrictRemoteClients peut être une protection particulièrement utile contre les vers qui reposent sur des dépassements de la mémoire tampon exploitable, et qui peuvent être appelés à distance via des connexions anonymes.

Si votre application RPC doit recevoir des appels de clients RPC anonymes distants, il est possible que l'utilisation de cette fonction empêche votre application de fonctionner correctement. Ainsi, les applications qui utilisent DCOM peuvent ne pas fonctionner correctement si cette valeur est définie.

Comme les appels RPC sécurisés émis via des protocoles sans connexion, tels que UDP (User Datagram Protocol) et IPX (Internetwork Packet eXchange) (ncadq_ip_udp et ncadg_ipx), utilisent un niveau de sécurité moins élevé que les appels via des protocoles orientés connexion, ces appels sont toujours considérés comme non sécurisés pour les besoins de cette stratégie. C'est pourquoi les appels RPC émis via des protocoles sans connexion échoueront si cette clé est activée dans Windows Server 2003 Service Pack 1.

Pour autoriser les appels de clients RPC utilisant des protocoles sans connexion, laissez la valeur RestrictRemoteClients sur 0 (RPC_RESTRICT_REMOTE_CLIENT_NONE), définie par défaut dans Windows Server 2003 Service Pack 1.

Les options suivantes peuvent vous permettre d'utiliser RestrictRemoteClients sur le serveur :

• Demandez à vos clients RPC d'utiliser la sécurité RPC lorsqu'ils contactent votre application serveur. Il s'agit de la meilleure méthode pour atténuer les menaces vis à vis de la sécurité.
  
• Définissez l'indicateur RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH lors de l'inscription de l'interface, pour que celle-ci ne demande plus d'authentification. Cela a pour effet de configurer RPC de façon à autoriser les connexions anonymes uniquement vers l'interface de votre application.
  

Une interface RPC accessible à distance de manière anonyme et enregistrée par défaut dans Windows Server 2003 présente une surface d'attaque considérable. Le service RPC lui-même doit enregistrer une telle interface pour permettre la résolution des points de terminaison pour les appels qui utilisent des points de terminaison dynamiques.

Si vous activez l'indicateur RestrictRemoteClients, le mappeur de points de terminaison ne sera pas accessible de manière anonyme. Il s'agit là d'une amélioration considérable pour la sécurité, mais qui modifie le mécanisme de résolution d'un point de terminaison. Actuellement, un client RPC qui tente d'effectuer un appel en utilisant un point de terminaison dynamique commence par interroger le mappeur des points de terminaison RPC sur le serveur pour déterminer à quel point de terminaison il doit se connecter. Cette requête s'effectue anonymement, même si l'appel du client RPC est lui-même effectué à l'aide de la sécurité RPC. Les appels anonymes à l'interface du mappeur de point de terminaison échouent dans Windows Server 2003 Service Pack 1 si la clé RestrictRemoteClients est définie avec une valeur supérieure ou égale à 1. C'est pourquoi il est nécessaire de modifier le client RPC de telle sorte qu'il exécute une requête authentifiée auprès du mappeur de points de terminaison. Si la clé EnableAuthEpResolution est définie, le client RPC utilise NTLM pour s'authentifier auprès du mappeur de points de terminaison. Cette requête authentifiée n'a lieu que si l'appel du client RPC utilise l'authentification RPC.

Cette modification permet à un client RPC d'effectuer un appel vers un serveur RPC qui a inscrit un point de terminaison dynamique sur un système exécutant Windows Server 2003 Service Pack 1 dont la clé RestrictRemoteClients est activée. L'ordinateur client doit définir cette clé de Registre pour qu'il puisse réaliser une requête authentifiée au mappeur de points de terminaison RPC.

Cette clé de Registre est utilisée pour permettre la mise en œuvre du scénario décrit dans la précédente section. Lorsqu'elle est activée, toutes les requêtes du mappeur de points de terminaison RPC qui sont effectuées pour le compte d'appels authentifiés sont réalisées en utilisant l'authentification NTLM.

Ce paramètre peut également être spécifié à l'aide de l'Éditeur d'objets de stratégie de groupe pour configurer l'objet de stratégie de groupe situé dans Configuration ordinateur\Modèle d'administration\Système\Appel de procédure distante\Authentification client du mappeur de points de terminaison RPC.

Trois nouveaux indicateurs ont été créés afin de faciliter le travail des développeurs d'applications en matière de sécurisation des interfaces RPC.

• RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH
  Si cet indicateur est enregistré, l'exécution RPC invoque pour tous les appels le rappel de sécurité enregistré, quels que soient les paramètres de sécurité des appels. Sans cet indicateur, RPC rejette tous les appels non authentifiés avant qu'ils accèdent au rappel de sécurité. Cet indicateur fonctionne uniquement si un rappel de sécurité est enregistré.
  
• RPC_IF_SEC_NO_CACHE
  Un rappel de sécurité est enregistré pour une interface afin de restreindre l'accès à cette interface. Le rappel de sécurité standard se fait passer pour le client afin de déterminer si ce dernier possède des droits suffisants pour appeler l'interface. Si l'identité d'un client spécifique parvient une première fois à franchir un rappel de sécurité, il pourra généralement le franchir à chaque fois.
  L'exécution RPC tire profit de ce mécanisme en mémorisant les identités des clients qui parviennent à franchir un rappel de sécurité, afin d'ignorer les rappels de sécurité lors des appels ultérieurs que ces clients effectueront vers cette même interface. Cette fonction, nommée mise en mémoire cache des rappels de sécurité, existe depuis les systèmes d'exploitation de la famille Microsoft Windows 2000. Dans Windows Server 2003 Service Pack 1, vous pouvez utiliser l'indicateur RPC_IF_SEC_NO_CACHE pour désactiver la mise en mémoire cache des rappels de sécurité pour une interface donnée. Cela peut s'avérer utile si les contrôles de sécurité sont modifiés, ce qui peut causer l'éventuel rejet d'une identité de client précédemment autorisée.
  
• RPC_IF_LOCAL_ONLY
  Lorsqu'une interface est enregistrée avec cet indicateur, RPC refuse les appels des clients RPC distants. De plus, les appels locaux émis via toutes les séquences de protocoles ncadg_* et ncacn_* (à l'exception des canaux nommés qui utilisent ncacn_np) sont également refusés. Lorsqu'un appel utilise ncacn_np, RPC n'accepte cet appel que s'il ne provient pas de SVR, qui filtre tous les appels distants. Les appels Ncalrpc sont toujours autorisés.
  

Cette modification fournit aux développeurs d'applications RPC des outils de sécurité supplémentaires pour sécuriser leur interface RPC.

Les applications Windows Server 2003 existantes ne seront pas modifiées ou perturbées par ces indicateurs. Les développeurs d'applications sont libres d'utiliser ou non ces nouveaux indicateurs.