Référence des ports
Port 636 (TCP) – LDAPS (LDAP sur TLS)
LDAPS — requêtes d'annuaire LDAP encapsulées dans TLS pour la confidentialité et l'intégrité.
État par défaut
Ouvert sur les contrôleurs de domaine disposant d'un certificat serveur (souvent via AD CS). Devrait être le canal d'annuaire privilégié plutôt que le 389 en clair.
Attaques courantes
- Énumération d'annuaire sur un canal authentifié
- TLS faible/expiré et failles de validation de certificat
- Bind anonyme ou non authentifié (si autorisé)
- Abus d'identifiants contre les ACL de l'annuaire
Durcissement
- Exiger LDAPS et désactiver les simple binds LDAP en clair quand c'est possible
- Utiliser un TLS robuste (1.2+), des certificats valides et désactiver les chiffrements obsolètes
- Imposer le channel binding et la signature LDAP
- Désactiver les binds anonymes et appliquer des ACL d'annuaire au moindre privilège
- Restreindre le port 636 aux réseaux d'administration de confiance
Commande nmap
nmap -p636 --script ssl-cert,ssl-enum-ciphers,ldap-rootdse <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Ce qui tourne sur le port 636
Le port 636 est le port par défaut de LDAPS — LDAP sur TLS. Il transporte les mêmes requêtes et modifications d'annuaire que LDAP simple, mais encapsulées dans une session TLS afin que les identifiants et les résultats soient chiffrés en transit. Dans Active Directory, il est servi par les contrôleurs de domaine disposant d'un certificat serveur adéquat (souvent émis par AD CS) et constitue le canal recommandé pour toute opération d'annuaire sensible, y compris les changements de mot de passe.
Pourquoi c'est important pour la sécurité
LDAPS corrige la plus grande faiblesse de LDAP — l'exposition en clair des mots de passe de simple bind et des données d'annuaire — et est nécessaire pour contrer le relais LDAP lorsqu'il est combiné au channel binding. Mais TLS ne protège que le transport. Un annuaire qui autorise les binds anonymes ou accorde un large accès en lecture divulgue toujours sa structure, et des certificats faibles ou expirés ainsi que des suites de chiffrement obsolètes peuvent saper le chiffrement lui-même ou permettre la rétrogradation et l'interception.
Comment c'est attaqué
Même sur TLS, un attaquant disposant d'un bind valide (ou anonyme) peut énumérer utilisateurs, groupes, SPN et ACL exactement comme sur le port 389. Les scanners vérifient sur le 636 les versions TLS faibles, les mauvais chiffrements et les problèmes de validation de certificat permettant l'interception. Là où le channel binding n'est pas imposé, des scénarios de relais peuvent encore réussir, et des ACL d'annuaire trop permissives permettent l'élévation de privilèges.
Liste de durcissement
Exigez LDAPS et supprimez progressivement les simple binds en clair. Ne servez que du TLS 1.2+ avec des certificats valides et désactivez les chiffrements obsolètes. Imposez le channel binding et la signature LDAP pour stopper le relais. Désactivez les binds anonymes et resserrez les ACL d'annuaire au moindre privilège. Restreignez le port 636 aux réseaux d'administration de confiance. Les scripts nmap ci-dessus inspectent le certificat et les suites de chiffrement sur les systèmes que vous êtes autorisé à tester.
Ports liés
Questions fréquentes
- Quelle est la différence entre LDAP (389) et LDAPS (636) ?
- LDAP sur le 389 est en clair ; LDAPS sur le 636 encapsule le même protocole dans TLS, chiffrant identifiants et données d'annuaire en transit. LDAPS est le choix sécurisé.
- LDAPS empêche-t-il l'énumération LDAP ?
- Non. TLS protège la confidentialité, mais un attaquant authentifié (ou lié anonymement) peut toujours énumérer l'annuaire. Combinez LDAPS avec le channel binding et le durcissement des ACL.