PKI ADCS, les flux réseaux et les principes de base
L’aspect réseau d’une infrastructure PKI ADCS semble compliqué pour beaucoup, alors qu’il peut être grandement simplifié en prenant un peu de recul.
Compliqué disions-nous, puisque la plupart du temps, nous travaillons dans l’urgence sans prendre la précaution de bien formuler l’équation.
Souvenez-vous, une équation bien posée est toujours à moitié résolue.
Peu importe la taille de votre environnement informatique, la simplification apporte des gains non négligeables à long terme. Cela nécessite du temps, de la réflexion et une bonne maîtrise des technologies à mettre en œuvre.
Les installations par défaut, celles des PKI ADCS, ont leurs limites vis-à-vis de la sécurité qui est de plus en plus exigeante.
Cet article met en exergue le fait qu’une touche de personnalisation est un vrai levier par rapport à la simplification et l’efficacité.
Il est question dans notre exemple de fixer un port de communication entre un serveur PKI ADS et ses pour les besoins de clés cryptographiques au sein d’une organisation.
Un serveur PKI ADCS (Active Directory Certificate Services) est avant tout un client ADDS (Active Directory Domaine Services) ne l’oublions pas.
La bonne pratique commande qu’un serveur donné ne cumule pas les deux rôles ADDS et PKI ADCS. Aussi, la bonne communication entre ADDS et la PKI ADCS requiert des flux réseaux comme indiqué ci-dessous :
ADCS est un client ADDS :
- 53/tcp-udp : DNS
- 88/tcp-udp : Kerberos
- 123/tcp-udp : W32Time
- 135/tcp : RPC
- 137/tcp-udp : NetBIOS Name Service
- 138/udp : NetBIOS Datagram Service, NetLogon
- 139/tcp : NetBIOS Session Service, NetLogon
- 389/tcp-udp : LDAP
- 445/tcp : SMB
- 464/tcp-udp : Kerberos password change
- 636/tcp-udt : LDAP over TLS
- 3268/tcp : LDAG CG
- 3269/tcp: LDAP GC over TLS
- 49152-63535/tcp : RPC/DCOM, LSA, SAM, Netlogon
SCEP et NDES, des modules de publication cryptographiques dépendant de la PKI ADCS, sont joints au domaine Active Directory et restent également des clients ADCS. Les même flux Active Directory sont requis pour leur bon fonctionnement.
Pour le reste, les autres composants de votre infrastructure sont tous potentiellement des clients PKI ADCS, donc directs vis-à-vis de la PKI ADCS ou indirects par l’intermédiaire d’un de ces modules (SCEP ou NDES).
Dans notre hypothèse, le bon plan consiste à limiter le nombre de ports réseaux nécessaires afin d’assurer le bon fonctionnement de la PKI ADCS par rapport à ses clients :
- 135/tcp : RPC
- 443/tcp : Web Enrollment (en potion)
- 6000/tcp : RPC/DCOM (le fameux port personnalisé de votre choix)
De la plage de ports dynamiques fournie par l’éditeur, il est donc possible d’assurer le bon fonctionnement de la PKI ADCS avec 2 ports seulement. Le port RPC et celui de votre choix (le port 6000/tcp dans cet article).
Comment fixer le port RPC ?
Il y a deux possibilités de fixer le port de communication de la PKI ADCS avec ses clients.
Elles sont, sachant que la seconde étant la plus digeste à réaliser :
– Via la base de registre :
Computer\HKEY_CLASSES_ROOT\AppID\{D99E6E74-FC88-11D0-B498-00A0C90312F3}
Créer une entrée de type REG_MULTI_SZ avec le nom Endpoints dont la valeur sera ncacn_ip_tcp,0,6000 (6000 étant le port personnalisé)
certutil -setreg ca\interfaceflags +0x8
Redémarrer le service ADCS
– Via la Console MMC « Component Services » :
Computers
My Computer
DCOM Config
CertSrv Reques > Properties
Endpoint tab > Add
Use static endpoint > TCP > 6000
Dans le cadre d’une mobilité, le composant NDES peut potentiellement être exposé sur Internet. Cette situation renforce la nécessité de limiter le nombre de ports nécessaires au bon fonctionnement de l’ensemble.
Voici ce que nous recommandons :
– Exposer à Internet, via le port standard chiffré 443, votre NDES. A l’évidence l’exposition se fera à l’aide d’un WAF et un certificat valide,
– Assurer la communication entre votre NDES et la PKI ADCS au moyen des deux ports : l’incontournable 135/tcp et le port personnalisé 6000/tcp,
– Comme NDES est un client ADCS, la personnalisation du port que vous avez effectué est profitable à l’ensemble des clients.
Les gains à travers une telle approche sont la simplicité, la bonne maitrise de ses flux réseaux et le maintien d’un bon niveau de sécurité.
En effet, un pare-feu se trouvant avec les ouvertures de flux relatives aux ports dynamiques, vers Active Directory d’une part et vers la PKI ADCS d’autre part, ressemblerait à n’importe quoi sauf à un pare-feu.
Pour rappel, la plage de ports dynamiques est la suivante 49152-65535/tcp (ces paramètres sont trouvables avec la commande suivante : netsh int ipv4 show dynamicport tcp).
Pour valider la bonne configuration et le bon fonctionnement du port statique, vous pouvez demander un certificat depuis un client PKI ADCS, puis observer en parallèle depuis ce même client les ports en écoute avec la commande ci-après : netstat | find « 6000 » (6000 étant notre port personnalisé).
En termes de localisation, nos recommandations sont les suivantes :
– L’autorité racine doit être enfermée dans un coffre-fort (ordinateur portable, HSM USB)
– Les autorités intermédiaires dans le LAN (HSM, AC, CRL OCSP)
– Les modules liés au nomadisme en DMZ (SCEP, NDES)
Cette approche est simple et à la fois contraignante si l’architecture est petite, mais elle reste sérieuse et bien pensée (sécurité, scalabilité et cætera).
Gardez à l’esprit que si votre approche de base est saine et cohérente, le reste c’est du gâteau.