Blocage de la connexion UDP au port 389 par le pare-feu

Vue d'ensemble

LDAP (Lightweight Directory Access Protocol) est le protocole de couche application derrière Active Directory. Il fonctionne normalement sur TCP, mais possède également une variante sans connexion — CLDAP (Connectionless LDAP) — qui fonctionne sur UDP sur le port 389. Les clients Windows utilisent CLDAP pour localiser les contrôleurs de domaine (le « ping LDAP » effectué par le service Localisateur de contrôleur de domaine). Les versions modernes de Windows peuvent souvent recourir à la découverte basée sur DNS et à LDAP sur TCP dans de nombreux scénarios, mais CLDAP sur UDP 389 est toujours utilisé pour les opérations du Localisateur de contrôleur de domaine et la jonction au domaine.

Le problème de sécurité est l'abus par réflexion (amplification). Un attaquant envoie une petite requête CLDAP falsifiée au port UDP 389 d'un serveur, en usurpant l'adresse IP source pour faire croire que la requête provient de la victime. Le serveur envoie alors une réponse beaucoup plus volumineuse à l'adresse de la victime. Multiplié sur de nombreux serveurs exposés, cela inonde la victime de trafic. Par le passé, des facteurs d'amplification supérieurs à 50× ont été observés, selon la taille de la réponse LDAP, ce qui explique pourquoi les serveurs exposés sont utilisés comme réflecteurs.

L'objectif de ce guide est d'empêcher votre serveur d'agir comme un tel réflecteur — sans interrompre les fonctions légitimes d'Active Directory.

Étape 1 : Déterminer si votre serveur est un contrôleur de domaine

Il s'agit de l'étape la plus importante, car elle détermine ce que vous devez bloquer (le cas échéant).

Dans une installation standard de Windows Server, le port UDP 389 n'est normalement utilisé que par les Services de domaine Active Directory après que le serveur a été promu contrôleur de domaine. Un Windows Server ordinaire (serveur web, d'applications, de fichiers, etc.) n'écoute pas sur UDP 389 par défaut et ne peut donc pas être utilisé comme réflecteur CLDAP, à moins qu'une autre application (telle qu'AD LDS ou un service LDAP tiers) ne fournisse un service CLDAP sur ce port.

Ouvrez PowerShell en tant qu'administrateur et vérifiez le rôle réel du serveur dans le domaine :

(Get-CimInstance Win32_ComputerSystem).DomainRole

Interprétation du résultat :

• 0 — Station de travail autonome (Standalone Workstation)
• 1 — Station de travail membre (Member Workstation)
• 2 — Serveur autonome (Standalone Server)
• 3 — Serveur membre (Member Server)
• 4 — Contrôleur de domaine (signalé comme « Backup Domain Controller » pour des raisons de compatibilité historique — tous les contrôleurs de domaine Active Directory modernes renvoient cette valeur)
• 5 — Contrôleur de domaine détenant le rôle FSMO d'émulateur PDC (signalé comme « Primary Domain Controller » pour des raisons de compatibilité historique)

Si le résultat n'est pas 4 ou 5, le serveur n'est pas un contrôleur de domaine.

Vous pouvez également vérifier si quelque chose écoute réellement sur UDP 389 :

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

Si cette commande ne renvoie rien, Windows n'écoute pas sur le port UDP 389, le serveur ne fournit donc pas de services CLDAP et n'est pas exposé à cette attaque.

Si votre serveur N'EST PAS un contrôleur de domaine

Rien n'écoute sur UDP 389, le serveur ne peut donc pas être utilisé comme réflecteur LDAP. Aucune modification du pare-feu n'est requise pour cette menace spécifique.

Si vous souhaitez documenter votre politique de sécurité ou appliquer une règle de refus explicite, vous pouvez tout de même créer la règle de pare-feu ci-dessous. Comme aucun service n'écoute sur le port UDP 389, la règle n'a aucun effet pratique.

Si votre serveur EST un contrôleur de domaine

Un contrôleur de domaine écoute effectivement sur UDP 389 et peut être utilisé comme réflecteur — mais UDP 389 est également essentiel au fonctionnement normal du domaine.

Avertissement : Ne bloquez pas aveuglément tout le trafic UDP 389 entrant sur un contrôleur de domaine. Les clients joints au domaine utilisent CLDAP (UDP 389) pour trouver un contrôleur de domaine, et le même port est nécessaire pour la jonction au domaine. Un blocage général peut empêcher les clients de localiser le contrôleur de domaine et perturber les opérations de connexion et de jonction au domaine.

L'approche correcte sur un contrôleur de domaine :

Idéalement, un contrôleur de domaine ne devrait pas du tout être accessible depuis Internet. L'abus par réflexion provient de l'extérieur, donc la solution la plus propre consiste à garder le contrôleur de domaine derrière un pare-feu périmétrique et à ne pas exposer UDP 389 publiquement.

Si le serveur doit être exposé, ne bloquez pas UDP 389 de manière globale. Bloquez-le plutôt uniquement à partir des plages d'adresses IP externes/non fiables, en laissant vos sous-réseaux de domaine internes en dehors du blocage. Cela arrête les requêtes externes falsifiées (qui provoquent la réflexion) tout en maintenant le fonctionnement des clients internes. Cela se fait avec les paramètres d'Étendue (Scope) de la règle, décrits ci-dessous.

Le même principe d'étendue s'applique aux contrôleurs de domaine en lecture seule (RODC).

Création de la règle de pare-feu (bloquer le trafic UDP 389 entrant)

Ouvrez le Pare-feu Windows et sélectionnez Paramètres avancés dans le menu de gauche :

Sélectionnez Règles d'entrée dans le menu latéral gauche :

Cliquez sur Action → Nouvelle règle... dans le menu supérieur :

L'assistant de création de règles s'ouvre. Sélectionnez le type de règle Port et cliquez sur Suivant > :

Sur la page suivante, sélectionnez UDP, puis sous Ports locaux spécifiques tapez 389 et cliquez sur Suivant > :

Sur la page suivante, sélectionnez Bloquer la connexion et cliquez sur Suivant > :

Enfin, donnez un nom à la règle, par exemple UDP LDAP block, et cliquez sur Terminer :

La même règle peut être créée à partir de PowerShell, ce qui est pratique pour le script ou pour l'appliquer à plusieurs serveurs :

New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP)" -Direction Inbound -Protocol UDP -LocalPort 389 -Action Block

Avertissement : Sur un contrôleur de domaine, ne vous arrêtez pas là. La règle ci-dessus bloque UDP 389 de toutes les sources, ce qui perturbera la localisation du contrôleur de domaine pour les clients internes. Vous devez en définir l'étendue (étape suivante).

Définir l'étendue de la règle (requis sur un contrôleur de domaine)

Une fois la règle créée, ouvrez ses Propriétés et accédez à l'onglet Étendue (Scope). Sous Adresse IP distante, sélectionnez Ces adresses IP et ajoutez les plages externes ou non fiables que vous souhaitez bloquer. N'ajoutez pas ici vos sous-réseaux de domaine internes — toute plage répertoriée sous « Adresse IP distante » est une plage que la règle bloquera, donc répertorier des sous-réseaux internes bloquerait vos propres clients. Laissez Adresse IP locale définie sur Toute adresse IP.

De cette façon, le blocage s'applique uniquement aux sources externes non fiables que vous spécifiez, tandis que les clients internes (non répertoriés) ne sont pas affectés.

Dans PowerShell, la même étendue peut être appliquée avec le mot-clé intégré Internet. Le mot-clé Internet correspond aux adresses distantes que le Pare-feu Windows classe comme externes, à l'exclusion de l'ordinateur local, du bouclage (loopback) et des plages de réseau local courantes. Cela bloque le trafic externe tout en laissant les clients internes non affectés :

New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP) from Internet" -Direction Inbound -Protocol UDP -LocalPort 389 -RemoteAddress Internet -Action Block -Profile Public,Private

Sur un contrôleur de domaine correctement configuré, le profil de pare-feu actif est normalement Domaine. Limiter la règle aux profils Public et Privé l'empêche d'affecter le trafic de domaine normal. Sur un contrôleur de domaine, il reste plus sûr de définir explicitement vos sous-réseaux internes dans l'Étendue de la règle plutôt que de vous fier uniquement au mot-clé Internet — si votre réseau utilise des plages privées non standard, elles peuvent être mal classées ; dans ce cas, répertoriez vos plages internes manuellement et bloquez tout le reste.

Vérifier le résultat

Avertissement : N'utilisez pas Test-NetConnection pour vérifier UDP 389 — il ne teste que les connexions TCP et donnera des résultats trompeurs pour UDP.

Le moyen le plus direct de confirmer si un serveur répond toujours aux requêtes CLDAP est d'envoyer un ping LDAP approprié depuis un client joint au domaine :

nltest /ping /server:DC_NAME

Cela envoie une requête CLDAP correctement formée et signale la réponse. Remplacez DC_NAME par le nom de votre contrôleur de domaine.

Comme vérification secondaire, vous pouvez utiliser PortQry (un outil de ligne de commande Microsoft gratuit) depuis une autre machine :

portqry -n SERVER_NAME -p UDP -e 389

Selon la réponse, PortQry peut signaler LISTENING ou FILTERED. Notez que PortQry envoie un paquet de sondage plutôt qu'un ping LDAP CLDAP complet, et que le service CLDAP peut ne pas le reconnaître comme une requête valide, de sorte qu'il peut signaler FILTERED même lorsque le port est ouvert. Pour cette raison, considérez nltest /ping comme le test faisant autorité et PortQry comme une vérification complémentaire approximative.

Sur un contrôleur de domaine, confirmez également que la localisation du domaine fonctionne toujours pour les clients internes :

nltest /dsgetdc:example.com

Remplacez example.com par le nom de votre domaine. Une réponse réussie signifie que les clients peuvent toujours trouver le contrôleur de domaine. Gardez à l'esprit qu'un dsgetdc réussi à lui seul ne prouve pas que CLDAP sur UDP fonctionne, car le Localisateur de contrôleur de domaine peut recourir à des requêtes DNS et à LDAP sur TCP si CLDAP n'est pas disponible, selon l'opération effectuée — c'est pourquoi la vérification nltest /ping ci-dessus est le test le plus direct.

Recommandations supplémentaires

Maintenez Windows entièrement à jour. Les mises à jour de sécurité corrigent les vulnérabilités critiques dans l'implémentation LDAP elle-même (telles que les failles susceptibles de permettre l'exécution de code à distance) et protègent le serveur contre toute compromission. Il s'agit d'une préoccupation distincte de l'abus par réflexion — l'application de correctifs renforce le serveur lui-même, tandis que la définition de l'étendue du pare-feu ci-dessus empêche le serveur d'être utilisé comme réflecteur contre d'autres.

Activez la signature LDAP et la liaison de canal sur les contrôleurs de domaine pour renforcer LDAP dans son ensemble.

Pour la protection volumétrique, la limitation du débit et le filtrage DDoS relèvent du pare-feu périmétrique ou du fournisseur en amont (upstream), et non de l'hôte Windows lui-même.

Résumé : quand est-il approprié de bloquer UDP 389 ?

• Le serveur n'est pas un contrôleur de domaine → aucune action requise (UDP 389 n'écoute pas).
• Contrôleur de domaine derrière un pare-feu, non exposé à Internet → aucune action requise ; gardez-le hors de l'Internet public.
• Contrôleur de domaine exposé à Internet → définissez l'étendue de la règle de sorte qu'elle bloque les sources externes tout en laissant les sous-réseaux internes de confiance non affectés.