Bloquer la connexion UDP vers le port 389 via le pare-feu

Ce guide explique comment protéger un serveur Windows contre les attaques DDoS de type « réflexion/amplification » via LDAP (CLDAP) sur le port UDP 389, et comment procéder en toute sécurité en fonction du rôle du serveur.

Présentation

LDAP (Lightweight Directory Access Protocol) est le protocole de couche application qui sous-tend Active Directory. Il fonctionne normalement sur TCP, mais il existe également une variante sans connexion — CLDAP (Connectionless LDAP) — qui fonctionne sur UDP via le port 389. Les clients Windows utilisent CLDAP pour localiser les contrôleurs de domaine (le « ping LDAP » effectué par le service DC Locator). Les versions récentes de Windows peuvent souvent recourir à la découverte via DNS et au protocole LDAP sur TCP dans de nombreux cas de figure, mais le protocole CLDAP sur le port UDP 389 est toujours utilisé pour les opérations du service DC Locator et l’adhésion au domaine.

Le problème de sécurité réside dans l’exploitation de la réflexion (amplification). Un attaquant envoie une petite requête CLDAP usurpée au port UDP 389 d’un serveur, en falsifiant l’adresse IP source afin que la requête semble provenir de la victime. Le serveur renvoie alors une réponse beaucoup plus volumineuse à l’adresse de la victime. Multiplié par le nombre de serveurs exposés, ce phénomène inonde la victime de trafic. Des facteurs d’amplification supérieurs à 50 ont été observés par le passé, en fonction de 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 de servir de réflecteur, sans pour autant perturber le fonctionnement normal d’Active Directory.

Étape 1 : Déterminez 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 (AD DS) une fois que le serveur a été promu au rang de contrôleur de domaine. Un serveur Windows classique (serveur web, d’applications, de fichiers, etc.) n’écoute pas le port UDP 389 par défaut ; il ne peut donc pas être détourné pour servir de 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 au sein du domaine :

(Get-CimInstance Win32_ComputerSystem).DomainRole

Interprétation du résultat :

• 0 — Poste de travail autonome
• 1 — Poste de travail membre
• 2 — Serveur autonome
• 3 — Serveur membre
• 4 — Contrôleur de domaine (indiqué comme « Contrôleur de domaine de secours » 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 (indiqué comme « contrôleur de domaine principal » pour des raisons de compatibilité historique)

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

Vous pouvez également vérifier si un service est effectivement à l'écoute sur le port 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 le port UDP 389 ; le serveur ne peut donc pas être utilisé abusivement 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. Étant donné qu’aucun service n’écoute sur le port UDP 389, cette règle n’a aucun effet concret.

Si votre serveur EST un contrôleur de domaine

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

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

Idéalement, un contrôleur de domaine ne devrait pas être accessible depuis Internet. L’exploitation de la réverbération provient de l’extérieur ; la solution la plus sûre consiste donc à maintenir le contrôleur de domaine derrière un pare-feu périmétrique et à ne pas exposer publiquement le port UDP 389.

Si le serveur doit être exposé, ne bloquez pas le port UDP 389 de manière globale. Bloquez-le plutôt uniquement à partir des plages d’adresses IP externes/non fiables, en excluant vos sous-réseaux de domaine internes du blocage. Cela permet d’arrêter les requêtes externes usurpées (à l’origine de la réflexion) tout en garantissant le fonctionnement des clients internes. Cette opération s’effectue via les paramètres de portée de la règle, décrits ci-dessous.

Le même principe de portée 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 Defender et sélectionnez « Paramètres avancés » dans le menu de gauche :

Sélectionnez « Règles entrantes » dans le menu de gauche :

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

L'assistant de création de règle 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 », saisissez « 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 « Blocage UDP LDAP », puis cliquez sur « Terminer » :

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

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

Définir la portée de la règle (obligatoire sur un contrôleur de domaine)

Une fois la règle créée, ouvrez ses Propriétés et accédez à l’onglet Portée. 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 » sera bloquée par la règle ; ainsi, l’ajout de sous-réseaux internes bloquerait vos propres clients. Laissez le paramètre « Adresse IP locale » défini sur « N’importe quelle adresse IP ».

De cette manière, 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 délimitation de portée peut être appliquée à l’aide du 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, de l’adresse de bouclage et des plages courantes du réseau local. Cela bloque le trafic externe tout en laissant les clients internes inchangé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 « Domain ». Limiter la règle aux profils « Public » et « Private » empêche celle-ci d’affecter le trafic normal du domaine. Sur un contrôleur de domaine, il est toujours plus sûr de définir explicitement vos sous-réseaux internes dans la section « Portée » 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, celles-ci risquent d’être mal classées ; dans ce cas, répertoriez manuellement vos plages internes et bloquez tout le reste.

Vérifiez le résultat

Le moyen le plus direct de vérifier si un serveur répond toujours aux requêtes CLDAP consiste à envoyer un ping LDAP valide depuis un client membre du domaine :

nltest /ping /server:DC_NAME

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

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

portqry -n SERVER_NAME -p UDP -e 389

Selon la réponse, PortQry peut indiquer LISTENING ou FILTERED. Notez que PortQry envoie un paquet de sondage plutôt qu’un ping CLDAP LDAP complet, et que le service CLDAP peut ne pas le reconnaître comme une requête valide ; il peut donc renvoyer FILTERED même lorsque le port est ouvert. C’est pourquoi vous devez considérer nltest /ping comme le test faisant autorité et PortQry comme une vérification complémentaire approximative.

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

nltest /dsgetdc:example.com

Remplacez example.com par votre nom de domaine. Une réponse positive signifie que les clients peuvent toujours localiser le contrôleur de domaine. Gardez à l’esprit qu’un `dsgetdc` réussi ne prouve pas à lui seul que CLDAP sur UDP fonctionne, car le localisateur de contrôleur de domaine peut recourir à des requêtes DNS et au protocole LDAP sur TCP si CLDAP n’est pas disponible, en fonction de l’opération effectuée — c’est pourquoi la vérification `nltest /ping` ci-dessus constitue 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 de l’implémentation LDAP elle-même (telles que les failles pouvant permettre l’exécution de code à distance) et protègent le serveur contre toute compromission. Il s’agit d’un problème distinct de l’abus de réflexion : l’application des correctifs renforce la sécurité du serveur lui-même, tandis que la configuration du pare-feu décrite ci-dessus empêche le serveur d’être utilisé comme réflecteur à l’encontre d’autres systèmes.

Activez la signature LDAP et la liaison de canal sur les contrôleurs de domaine afin de renforcer la sécurité globale du protocole LDAP.

Pour la protection volumétrique, la limitation de débit et le filtrage DDoS doivent être mis en place au niveau du pare-feu périmétrique ou chez le fournisseur en amont, et non sur l’hôte Windows lui-même.

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

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