Déni de service

  • Article

Un déni de service se produit lorsqu'un système est saturé au point que le traitement des messages est impossible ou extrêmement lent.

Consommation de mémoire excessive

La lecture d'un document XML contenant un grand nombre de noms locaux uniques, d'espaces de noms ou de préfixes peut poser problème. Si vous utilisez une classe dérivée de XmlReader et que vous appelez la propriété LocalName, Prefix ou NamespaceURI pour chaque élément, la chaîne retournée est ajoutée à NameTable. La collection détenue par NameTable ne diminue jamais en taille et crée une « fuite de mémoire » virtuelle des handles de chaîne.

Les solutions d’atténuation sont les suivantes :

  • Dérivez de la classe NameTable et appliquez un quota de taille maximale. (Vous ne pouvez pas empêcher l'utilisation d'un NameTable ou basculer NameTable lorsqu'il est plein.)

  • Évitez également d'employer les propriétés mentionnées et utilisez plutôt la méthode MoveToAttribute avec la méthode IsStartElement dans la mesure du possible ; ces méthodes ne retournant pas de chaînes, la collection NameTable n'est pas saturée.

Envoi d'un nombre excessif de demandes de licence à un service par un client malveillant

Si un client malveillant bombarde un service de demandes de licence, il peut induire une utilisation excessive de la mémoire par le serveur.

Atténuation : utilisez les propriétés suivantes de la classe LocalServiceSecuritySettings :

  • MaxCachedCookies : contrôle le nombre maximal de SecurityContextTokens limités par le temps que le serveur met en cache après une négociation SPNego ou SSL.

  • IssuedCookieLifetime : contrôle la durée de vie des SecurityContextTokens que le serveur émet après une négociation SPNego ou SSL. Le serveur met en cache les SecurityContextTokens pendant cette période.

  • MaxPendingSessions : contrôle le nombre maximal de conversations sécurisées établies au niveau du serveur mais pour lesquelles aucun message d'application n'a été traité. Ce quota empêche les clients d'établir des conversations sécurisées au niveau du service, en forçant ainsi le service à conserver un état par client, sans jamais les utiliser.

  • InactivityTimeout : contrôle la durée maximale pendant laquelle le service garde une conversation sécurisée active sans recevoir de message d’application du client pour la conversation. Ce quota empêche les clients d'établir des conversations sécurisées au niveau du service, en forçant ainsi le service à conserver un état par client, sans jamais les utiliser.

Les liaisons WSDualHttpBinding ou les liaisons personnalisées doubles requièrent l'authentification du client

Par défaut, la sécurité est activée pour WSDualHttpBinding. Toutefois, si l'authentification du client est désactivée en affectant à la propriété ClientCredentialType la valeur None, il est possible qu'un utilisateur malveillant provoque une attaque par déni de service sur un service tiers. Ce risque existe car un client malveillant peut commander au service d'envoyer un flux de messages à un service tiers.

Pour atténuer ce risque, n'attribuez pas à la propriété la valeur None. Par ailleurs, ayez ce risque en tête lorsque vous créez une liaison personnalisée avec un modèle de message double.

Risque de saturation du journal des événements d'audit

Si un utilisateur malveillant se rend compte que l'audit est activé, l'intrus peut envoyer des messages non valides pour forcer l'écriture d'entrées d'audit. Si le journal d'audit se remplit de cette manière, le système d'audit échoue.

Pour minimiser ce problème, affectez à la propriété SuppressAuditFailure la valeur true et utilisez les propriétés de l'Observateur d'événements pour contrôler le comportement d'audit. Pour plus d’informations sur l’utilisation de l’Observateur d’événements afin d’afficher et de gérer les journaux des événements, consultez Observateur d’événements. Pour plus d’informations, consultez également Audit.

Les implémentations non valides d’IAuthorizationPolicy peuvent entraîner la non-réponse du service

L’appel de la méthode Evaluate sur une implémentation défaillante de l’interface IAuthorizationPolicy peut entraîner la non-réponse du service.

Atténuation : utilisez uniquement un code de confiance. Autrement dit, utilisez uniquement un code que vous avez vous-même écrit et testé, ou qui provient d'un fournisseur approuvé. N’autorisez pas les extensions non fiables de IAuthorizationPolicy à s’intégrer à votre code sans prendre toutes les précautions requises. Cela s'applique à toutes les extensions utilisées dans une implémentation de service. WCF ne fait pas de distinction entre du code d’application et du code étranger intégré à l’aide de points d’extensibilité.

La taille maximale de jeton Kerberos peut devoir être redimensionnée

Si un client appartient à un grand nombre de groupes (approximativement 900, bien que le nombre réel varie selon les groupes), un problème peut se produire lorsque le bloc d'un en-tête de message dépasse 64 kilo-octets. Dans ce cas, vous pouvez augmenter la taille maximale du jeton Kerberos. Vous devrez peut-être également augmenter la taille maximale des messages WCF pour l’adapter au jeton Kerberos le plus volumineux.

L'inscription automatique provoque la création de plusieurs certificats avec le même nom de sujet pour l'ordinateur

L’inscription automatique est la fonctionnalité de Windows Server 2003 qui permet d’inscrire automatiquement des utilisateurs et des ordinateurs pour les certificats. Lorsqu’un ordinateur se trouve sur un domaine dans lequel cette fonctionnalité est activée, un certificat X.509, dont le rôle prévu est d’authentifier les clients, est créé automatiquement et inséré dans le magasin de certificats personnels de l’ordinateur local à chaque fois qu’un nouvel ordinateur est joint au réseau. Toutefois, l'inscription automatique utilise le même nom de sujet pour tous les certificats qu'il crée dans le cache.

Par conséquent, les services WCF risquent de ne pas pouvoir s’ouvrir sur les domaines dans lesquels l’inscription automatique est activée. Cela est dû au fait que les critères de recherche d'informations d'identification X.509 du service par défaut peuvent être ambigus car il existe plusieurs certificats portant le nom DNS (Domain Name System) complet de l'ordinateur. Un certificat peut provenir de l'inscription automatique tandis qu'un autre peut être un certificat auto-publié.

Pour atténuer ce risque, référencez le certificat exact à utiliser en appliquant un critère de recherche plus précis sur <serviceCredentials>. Par exemple, utilisez l'option FindByThumbprint et spécifiez le certificat par son empreinte numérique unique (hachage).

Pour plus d’informations sur la fonctionnalité d’inscription automatique, consultez Inscription automatique des certificats dans Windows Server 2003.

Dernier des noms de sujet de remplacement utilisés pour l'autorisation

Dans les rares cas où un certificat X.509 contient plusieurs noms de sujet de remplacement, et que vous autorisez l'utilisation du nom de sujet de remplacement, l'autorisation peut échouer.

Protection des fichiers de configuration avec des listes ACL

Vous pouvez spécifier des revendications requises et facultatives dans des fichiers de code et de configuration pour des jetons émis par CardSpace. Cette procédure entraîne l'émission d'éléments correspondants dans les messages RequestSecurityToken envoyés au service de jeton de sécurité. Un intrus peut modifier un code ou une configuration pour supprimer des revendications requises ou facultatives et éventuellement faire en sorte que le service de jeton de sécurité publie un jeton qui n'autorise pas l'accès au service cible.

Pour atténuer ce risque : imposez l'obligation d'accéder à l'ordinateur pour pouvoir modifier le fichier de configuration. Utilisez les listes de contrôle d'accès au fichier (ACL) pour sécuriser les fichiers de configuration. WCF exige que le code soit placé dans le répertoire de l’application ou le Global Assembly Cache avant d’autoriser son chargement à partir de la configuration. Utilisez des listes ACL de répertoire pour sécuriser des répertoires.

Atteinte du nombre maximal de sessions sécurisées pour un service

Lorsqu'un client est correctement authentifié par un service et qu'une session sécurisée est établie avec ce dernier, le service effectue le suivi de la session jusqu'à ce qu'elle soit annulée par le client ou qu'elle expire. Chaque session établie est décomptée du nombre maximal de sessions simultanées actives pour un service. Lorsque cette limite est atteinte, les clients qui essaient de créer une session avec ce service sont rejetés jusqu'à ce qu'une ou plusieurs sessions actives expirent ou soient annulées par un client. Un client peut ouvrir plusieurs sessions sur un service, chacune de ces sessions étant décomptée du nombre limite.

Notes

Lorsque vous utilisez des sessions avec état, le paragraphe précédent ne s’applique pas. Pour plus d’informations sur les sessions avec état, consultez Procédure : créer un jeton de contexte de sécurité pour une session sécurisée.

Pour atténuer ce risque, paramétrez le nombre maximal de sessions actives et la durée de vie maximale d'une session en définissant la propriété SecurityBindingElement de la classe SecurityBindingElement.

Voir aussi