L’aspect réseau d’une infrastructure PKI semble compliqué pour beaucoup, alors qu’il peut être grandement simplifié en prenant un peu de recul.
Pourquoi ?
Parce que fixer les ports dynamiques ADCS reste une bonne pratique.
Compliqué disions-nous, puisque la plupart du temps, nous travaillons dans l’urgence sans prendre la précaution de bien formuler l’équation. Une bonne formulation permet de préparer une bonne architecture. Souvenez-vous, une équation bien posée est toujours à moitié résolue.
Donc, 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.
Installation
Les installations par défaut ont toujours leurs limites vis-à-vis de la sécurité qui est de plus en plus exigeante. C’est pourquoi, la personnalisation d’une installation ADCS est de mise.
En fin de compte, cet article met en exergue le fait qu’une touche de personnalisation est un vrai levier par rapport à la simplification, l’efficacité et la sécurité.
Il est question dans notre exemple de fixer un port de communication entre un serveur ADCS, le serveur PKI, et ses clients pour les besoins de clés cryptographiques au sein d’une organisation.
Un serveur ADCS (Active Directory Certificate Services) est idéalement avant tout un client ADDS (Active Directory Domaine Services), n’oublions pas ce point.
Flux réseaux, ADCS et modules principaux
La bonne pratique commande de ne pas cumuler les rôles ADDS et ADCS au sein d’une seule machine. Par conséquent, la bonne communication entre ADDS et la PKI ADCS requiert des flux réseaux comme indiqué ci-dessous :
- 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-udp : 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êmes flux en tant que client Active Directory sont donc requis pour leur bon fonctionnement.
Flux réseaux et les services de contrôle
Pour vulgariser, les services de contrôle sont ceux représentés par l’OCSP, la CRL et cætera. Ils sont fondamentaux pour la cohérence et la sécurité des services délivrés par l’ADCS.
Dans cet esprit, il convient de les dissocier l’ADCS des services de contrôle, cela pour des raisons évidement de sécurité et de disponibilité.
En fin de compte, des plateformes auxiliaires sont nécessaires pour héberger ces service connexes à l’ADCS.
Le flux requis est généralement :
- 80/tcp : Web
Les fichiers CRL est OCSP sont signés bien qu’ils soient accessibles via le protocole http. Ne faites plus donc bêtement cette erreur !
Pour les clients natifs Windows, l’OCSP est accessible à la fois via le protocole http et ldap. Dans les grandes lignes, l’accès via ldap est lié à essentiellement à l’intepenetration de l’ADCS avec ADDS. Ainsi, en termes d’architecture, vous avez tous les éléments nécessaires quant au comment assurer la haute disponibilité des services de contrôle.
Flux réseau des porteurs
En d’autres termes, les autres composants de votre infrastructure sont tous donc potentiellement des clients ADCS.
En definitive des clients directs de la PKI ADCS ou indirects par l’intermédiaire d’un de ces modules (SCEP ou NDES accessible via un Proxy https (443/tcp : Web sécurisé) pour les clients nomades par exemple).
Dans notre hypothèse, le bon plan consiste à limiter le nombre de ports réseaux nécessaires tout en assurant le bon fonctionnement de la PKI ADCS vis-à-vis de 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 port seulement, en effet : le port RPC et l’autre port de votre choix (le port 6000/tcp est clairement un choix arbitraire de notre part).
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
Mobilité et sécurité
Dans le cadre d’une mobilité, le composant NDES peut potentiellement être exposé sur Internet (c’est une redite).
Cette situation renforce la nécessité de limiter le nombre de ports nécessaires au bon fonctionnement de l’ensemble. Autrement dit, cela permet de limites la voilure des éventuelles attaques réseaux.
Voici ce que nous recommandons :
– Exposer à Internet votre NDES via le port standard chiffré 443. A l’évidence l’exposition se fera à l’aide d’un WAF et un certificat valide,
– Assurer la communication entre votre NDES et votre 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.
Gains
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 relatifs 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 : ensuite, observer en parallèle depuis ce même client les ports en écoute avec la commande ci-après : netstat | find « 6000 » (6000 étant toujours notre port personnalisé).
Recommendations
En termes de localisation, nos conseils sont les suivant :
- L’autorité racine doit être hors-ligne et en consequence enfermée dans un coffre-fort (ordinateur portable avec HSM USB),
- Les autorités intermédiaires dans le LAN (AC avec HSM redondé),
- Les service des contrôle dans le LAN également (CRL, delta CRL et OCSP) publiés éventuellement vers internat à travers un Proxy / Reverse Proxy et un WAF,
- Les modules liés au nomadisme en DMZ (SCEP, NDES) et toujours avec un accès sécurisé avec un Proxy / Reverse Proxy et WAF.
Conclusion
Bien gérer les flux réseaux autour de la PKI a du sens. Peu importe la solution technologique de votre PKI, i.e. ADCS ou autre.
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.