Active Directories
Informations relatives au hardening d'Active Directories et les notions sur lesquelles il faut avoir un œil lorsqu'on maintient un AD.
Dernière mise à jour
Cet article vous a-t-il été utile ?
Informations relatives au hardening d'Active Directories et les notions sur lesquelles il faut avoir un œil lorsqu'on maintient un AD.
Dernière mise à jour
Cet article vous a-t-il été utile ?
Il existe plusieurs services et fonctionnalités activées par défaut et absolument non nécessaires. D'ailleurs, beaucoup d'entre eux peuvent grandement faciliter la compromission de l'AD :
(Protocoles de découvertes d'hôtes. Utile pour une utilisation courante et anecdotique, mais dangereux dans le cadre d'une infrastructure professionnelle)
(Protocole multicast utilisé en fallback en cas de résolution DNS non satisfaisante. Même principe que les deux précédents)
(Inutile dans un AD mais offre pourtant des possibilités supplémentaires d'attaques de type MitM)
Les macros et Wscript (Désactiver les macros peut permettre de réduire le champs d'action d'un attaquant ayant réussi à s'introduire sur une machine, de même pour Wscript)
Hash LM (Le Hash LM n'est absolument pas nécessaire et est par défaut stocké dans la mémoire d'un AD. Autant désactiver cette fonctionnalité...)
Compatibilité doit être désactivée car se repose sur des protocoles vulnérables et n'est pas nécessaire.
WDigest doit être désactivé si possible. En effet, celui-ci stocke des mots de passe en clair dans la mémoire des serveur, augmentant alors les risques suite à une compromission du serveur
Dans le cas où la résolution IPv6 sur les clients de l'AD est activée, il est possible d'exploiter la priorisation de la résolution IPv6 sur la résolution IPv4 en montant un serveur DNS malveillant et se positionner en MitM pour par exemple faire du NTLM Relay. En effet, les identifiants du client peuvent être demandés via l'utilisation du protocole WPAD. Il y a évidemment plein d'autres cas ou le MitM est possible, sur d'autres protocoles présents dans l'AD, mais cette stratégie représente un vecteur d'attaque potentiel supplémentaire.
Il faut savoir que concernant les Active Directories, pour des raisons d'historique, il y a deux systèmes de permissions qui agissent simultanément et peuvent rendre les choses confuses. Pour cette raison, il est bien d'en utiliser qu'un seul :
Il y a les permissions SMB, qui est le protocole de partage de fichier généralement utilisé dans les AD.
Il est alors souvent recommandé de tout autoriser pour everyone au niveau des permissions SMB et donc de configurer nos accès via le système de permissions NTFS.
Le concept derrière la politique de restriction est de diminuer la surface d'attaque pour s'en tenir au strict nécessaire au bon fonctionnement de notre infrastructure. Beaucoup de fonctionnalités sont activées par défaut pour des raisons de simplicité, cependant, nombre d'entre elles représentent des vecteurs d'attaques inutilement présents.
Il y a des concepts principaux auxquels il faut rester vigilent :
La délégation (Il est possible de déléguer à un serveur les droits d'utilisateurs. En effet, il est parfois pratique qu'un service effectue des actions auprès d'un autre service, au nom d'un utilisateur)
Les URA (User Rights Management sont les droits des différents utilisateurs au sein de l'AD. Là aussi, plus on restreint les URA pour que les utilisateurs puissent faire le moins d'actions possible tout en ne compromettant pas le bon fonctionnement de notre infrastructure)
Les GPO (Il est également bien de parcourir les différentes GPO et de n'activer que celles que vous jugez nécessaires)
Un utilisateur peut effectuer une action sur un serveur B, via un serveur A. Ainsi, un serveur A compromis par un attaquant pourrait alors, au nom d'un compte privilégié s'y connectant, compromettre le serveur B. Il est alors évident que les délégations ne sont pas à prendre à la légère et qu'elles doivent être mesurées et restreintes au maximum)
Il est courant de créer une bastion. C'est une zone isolée, dont l'accès se fait souvent physiquement. Une zone qui est donc plus protégée que les autres et qui centralise les pleins accès. En effet, il faut forcément au moins un compte disposant de tous les droits administrateurs et la création d'un bastion permet de sécuriser ce dernier et d'éviter les ingérences et les mauvaises pratiques parfois inattentives ou motivée par une certaine praticité.
Tier 0 : Réuni tous les services d'administration de l'infrastructure. Gestion des certificats, des authentifications, des sauvegardes (archivage).
Tier 1 : Réuni les applications métiers, donc les outils informatiques hébergés dans l'infrastructure comme le serveur de fichiers SMB, les bases de données, les VM mises à disposition pour les employés.
Tier 2 : Réuni la totalité des machines clientes des employés ainsi que tous les périphériques utilitaires et dont l'accès total est disponible pour ces derniers, comme les imprimantes et les scanners.
MitMIl est important d'utiliser un chiffrement TLS dès que possible pour tous nos services, surtout ceux demandant une authentification. Cela permet de prévenir de l'écrasante majorité des attaques de type MitM. C'est par exemple fortement recommandé pour les services utilisant le protocole RDP, SMB, LDAP, etc..
Pour RDP, vous devez donc faire comme précédemment expliquer et puis partager les certificats de confiance sur les machines clientes.
Je ne vais pas fournir d'explications pour les différentes activations par GUI ou ligne de commande, car c'est une règle générique qui s'applique plus largement à tout le monde de l'informatique : Forcez les échanges signés (TLS) lorsque possible.
Précisons tout de même que chaque client doit faire confiance au certificat du serveur et que chaque employé doit être sensibilisé pour ne pas accepter de certificat qu'il ne connaît pas. C'est l'administrateur qui doit choisir de faire confiance une première fois au certificat du serveur. C'est l'UNIQUE moyen d'éviter les attaques de type MitM. En effet, même un échange de clé DH (Diffie Hellmann) est vulnérable aux attaques de type MitM si l'attaquant peut agir sur les échanges. DH n'est pas vulnérable si l'attaquant est un observateur passif. Le certificat empêche l'observateur d'agir. Sans cette confiance initiale en le certificat, alors l'attaquant pourrait faire une attaque de type Relay et proposer son propre certificat au client et effectuer l'échange de clés DH des deux côtés de l'échange (client et serveur).
Dans l'hypothèse où un attaquant est parvenu à compromettre un compte privilégié, il est souhaitable de réduire son champ d'action via des mécanismes de confirmation d'identifiants. En effet, il est courant qu'une compromission se fasse sans que l'attaquant connaisse le mot de passe du compte compromis. Pour certaines actions délicates, il est donc préférable de demander à nouveau le mot de passe du compte.
Notons qu'il existe tout de même des techniques pour bypass l'UAC en exploitant certaines applications bénéficiant (à tort selon moi) de la confiance de Microsoft et pouvant alors s'auto-elevate sans que l'utilisateur ait à confirmer son identité. Pour lutter contre cela, nous allons donc prendre les mesures ci-dessous.
En activant sur toutes les machines clientes, l'option en Toujours notifier pour le contrôle d'utilisateur, Windows demandera alors systématiquement l'identification pour exécuter un programme à IL (Integrity Level) haut, même pour ceux qu'il estime dignes de confiance :
Il est important de désactiver les options de downgrading de protocoles. Notamment pour RDP et Kerberos.
Loption Negotiate côté serveur, qui est présente par défaut et qui malheureusement, permet au client d'effectuer une connexion RDP au serveur de manière non chiffrée. C'est problématique pour des raisons évidentes déjà expliquées, un MitM pourrait avoir des conséquences malheureuses. Il faut forcer la négociation SSL et activer la NLA qui est un mécanisme de pré-authentification permettant de vérifier les identifiants avant d'initialiser la connexion. Cela peut sembler inutile puisque cet échange d'identifiant peut très bien se faire au niveau de l'établissement de la connexion RDP, mais rajouter des étapes supplémentaires est souvent souhaitable et renforce la sécurité par stratification.
Le mieux est alors d'utiliser des outils de scanning comme BloodHound, ForestDruid, Purple Knight et Microsoft BPA (Best Practice Analyzer), l'outil proposé par Microsoft. Ces outils nous aident à détecter des chemins pour faire de la propagation latérale voire verticale (élévation de privilège) créés par des erreurs de configuration ne respectant pas les différents cloisonnement que nous avons mis en place.
Ces bonnes pratiques ne sont pas suffisante, il est TOUJOURS recommandé d'attaquer notre propre infrastructure, soit nous même, soit via la sollicitation d'entreprises d'audit. Nous sommes tous humains et faisons tous des erreurs, des oublis. Microsoft est un enfer sans nom avec un mille-feuille de fonctionnalités et de conditions d'accès et de privilèges, une erreur de configuration est alors vite arrivée.
Le mieux est alors d'utiliser des outils de scanning :
Il y a les permissions qui est le système de permissions inhérent au système de fichiers propriétaire Microsoft.
Ce bastion pourra alors gérer les comptes moins privilégiés. Il est courant d'organiser ces autres comptes dans un système de . Plus généralement, on peut même ajouter de la granularité selon nos besoins spécifiques, plus il a de cloisonnement des accès, plus la sécurité est forte. Plusieurs modèles de tiering peuvent être utilisés mais l'écrasante majorité des entreprises se reposent sur une base commune et souvent suffisante :
Pour SMB, ça s'appelle le SMB Signing et c'est exactement le même principe. Cela va permettre d'empêcher les attaques de type .
Ce mécanisme s'appelle l'UAC (User Access Control) chez Microsoft et permet de protéger l’exécution de certains programmes dont le niveau d'intégrité appelé est assez haut pour l'utilisateur mais pas pour sa session. Le but est alors d'avoir une session à niveau d'intégrité basse afin de protéger les actions à plus haute intégrité via l'UAC.
Désactiver la possibilité de s'authentifier via le (NTLM). Il est vulnérable aussi bien au bruteforce en local qu'aux attaques de type PtH (Pass The Hash). Il a alors des successeurs : Net-NTLMv1 et Net-NTLMv2, souvent appelés NTLMv1 et NTLMv2. Ces protocoles sont bien plus sécurisés et ne sont pas vulnérables aux attaques de type PtH. Pour des raisons de sécurité au niveau de la vitesse de bruteforce de ces hash, il est préférable de désactiver l'utilisation de l'authentification par NTLMv1 et donc de forcer l'utilisation de NTLMv2.
, (Outils pour trouver des chemins vulnérables pour de la via des erreurs de configuration)
(Outils d'évaluation des bonnes pratiques au sein de l'AD avec attribution d'un score)
(Best Practice Analyzer est un outil de scanning proposé par Microsoft)
UAC