Sécurisation de l’Active Directory.

La sécurité est une préoccupation quotidienne des administrateurs. Cette préoccupation devient prioritaire lorsque l’on gère un annuaire qui centralise les données d’identification et les droits d’accès. Le service Active Directory (Microsoft) est répandu et utilisé par de nombreuses organisations dans le monde. Il constitue une cible privilégiée pour les hackers car il renferme une quantité non négligeable de données sensibles (mot de passe, informations diverses et confidentielles, comptes, etc.…). L’ Active Directory est le point faible de la sécurité en entreprise. Non seulement il détient les clés du Sésame, mais c’est aussi la caverne d’Ali Baba pour les hackers. Et comme c’est le pilier de l’infrastructure informatique, si l’AD est effacé ou chiffré, l’entreprise s’arrête brutalement.
S’il devait-être compromis par une attaque (ransomware, vol d’identités, etc.…), ceci pourrait coûter très cher à l’organisation (surtout quand elle est très connue…), avoir un impact négatif sur son image de marque et mettre en péril sa survie. Alors que faire ? Sécuriser, sécuriser et sécuriser !
Mais sécuriser l’Active Directory n’est pas une mince affaire… En effet, on ne sait pas par où commencer ! On parle ici d’une solution classique « On premise » (AD installé localement) et non de l’Azure AD…
Réduction de la surface d’attaque
La surface d’attaque d’une organisation inclut tous les endroits où un hacker peut compromettre des périphériques, des systèmes, etc… de l’entité. Ce qui veut dire que la réduction de la surface d’attaque signifie protéger tous les périphériques, son réseau, etc…, ce qui laisse aux hackers moins de moyens d’effectuer des attaques.
Il existe de nombreuses catégories de surfaces d’attaque.
Un pirate va pouvoir utiliser au choix soit :
- Le réseau
- Les systèmes
- Les logiciels
- Les utilisateurs
À quoi ressemble une attaque ?
En règle générale, les hackers essayent d’obtenir un certain niveau d’accès, tel que :
- Une campagne de phishing (compromission d’un poste de travail avec des privilèges faibles),
- Un hacker qui a compromis un système externe (serveur, RDP, etc…) avec un accès au Lan,
- Une personne malveillante ayant ou ayant eu un accès interne (employé licencié, mécontent, en désaccord…),
- Un prestataire externe, livreurs, des script kiddies, etc… ayant un accès physique ou sans fil au réseau interne.
À partir d’un point d’entrée, d’autres attaques pourront être projetées. L’objectif ultime et prioritaire d’un hacker est d’obtenir les informations d’identification d’utilisateurs à haut niveau de privilège et/ou d’un administrateur de domaine afin de prendre le contrôle total de l’environnement Active Directory. A partir de ce moment-là, il ne reste plus qu’à : soit maintenir un accès permanent, invisible et récupérer des informations sensibles pendant des semaines, mois…, soit déployer un ransomware pour exfiltrer des informations sensibles, chiffrer les données locales et commencer à extorquer financièrement les entreprises…
Voici des préconisations pour vous aidez à sécuriser au mieux l’Active Directory
- Désactivation des protocoles non sécurisés suivants (via une stratégie de groupe par exemple) :
- LLMNR (résolution de noms de multidiffusion)
- Résolution de noms NetBIOS (NBNS)
- WPAD (Web Proxy Auto-Discovery)
- En fonction de votre besoin, création de 2 ou 3 comptes de gestion / administrateur :
- 1 pour l’accès à l’AD seulement sur le modèle (voir section Politique des comptes),
- 1 pour l’accès aux serveurs (voir section Politique des comptes),
- 1 pour l’accès aux autres périphériques (PC, etc…) sur le modèle (voir section Politique des comptes),
- Désactiver ou supprimer les comptes non utilisés,
- Création de mot(s) de passe forts sur le principe ci-contre… (voir les sections Le password, Le password… suite),
- Créer des groupes de sécurité spécifiques en fonction des rôles et éviter les groupes par défaut tels que Admins du domaine, etc… (un post sera fait à ce sujet…),
- Les groupes à privilèges élevés dans Active Directory tels que les administrateurs de domaine, les administrateurs d’entreprise, les administrateurs de schéma ou les groupes d’administrateurs intégrés sont souvent configurés avec des membres de groupe inutiles. L’adhésion à ces groupes devrait être réduite au plus petit nombre de membres possible,
- En fonction de votre besoin, création de 2 ou 3 VM sécurisée (SAW : Secure Admin Workstation) dédiée pour l’administration. Ces VM ne doivent pas être utilisées pour consulter des e-mails ou la navigation : aucun accès à Internet :
- 1 VM dans le Vlan AD avec connexion RDP. Les AD ne doivent accepter que l’IP de cette VM,
- 1 VM dans le Vlan des serveurs avec connexion RDP. Les serveurs ne doivent accepter que l’IP de cette VM,
- 1 VM dans le Vlan des PC avec connexion RDP. Les PC ne doivent accepter que l’IP de cette VM,
- Activation des Firewall locaux et mise en place de règles sur le Firewall central.
Quelques conseils pour ces VM :
-
- Installation d’un système d’exploitation (Windows ou Linux) propre,
- Renforcé la sécurité sur la VM, voir les sections notions de base, notions avancées )
- Chiffrer le disque,
- Utiliser des clefs USB de source fiable,
- Activation du un pare-feu local,
- Logiciel d’administration,
- Utilisez le MFA, si c’est possible.
- Ne pas installer d’autres rôles que l’AD sur les serveurs DC (à part le service DNS),
- Les contrôleurs de domaine doivent être traités comme des composants hautement sécurisés et précieux de l’infrastructure, plus que les serveurs de fichiers, d’impression ou d’autres applications. Ils ne doivent pas exécuter d’applications logicielles inutiles ni exécuter d’autres fonctions susceptibles d’élargir la surface d’attaque,
- Interdiction de surfer sur Internet depuis les AD, sauf vers les éditeurs (MAJ système, Antivirus, etc…) ou passer par un serveur proxy (filtrage url, scan antivirus, etc…),
- Utiliser un service de DNS sécurisé pour les requêtes DNS tel que :
- Mettre à jour son système quotidiennement : correctifs, patch sécurité, zero day, etc… Ne pas faire l’impasse sur cela, surtout pas !,
- Inscrivez-vous sur des sites d’alertes de failles et de vulnérabilités (CVE : Common Vulnerabilities and Exposures) pour vous tenir au courant tels que :
- Envoyer les Logs DNS vers le SIEM afin de détecter toute activité réseau malveillante,
- Mettre à jour l’antivirus natif (Windows Defender) ou votre suite EDR quotidiennement (recherche des signatures virus, signature APT, etc… en automatique),
- Activé le Pare-feu local avec des règles restrictives en entrée /sortis : utilisation des protocoles sécures,
- Désactivation de RDP, Assistance à distance, SSH, si ces protocoles ne sont jamais utilisés…,
- Si utilisation de RDP, utiliser RDS Gateway si possible même en interne,
- Désinstallation des logiciels superflus ou qui ne sont pratiquement jamais utilisés. Ne télécharger pas ou n’exécuter pas de logiciels depuis des sources non sures,
- Désactivation des logiciels qui ne servent pas au démarrage du système.
- N’utilisez pas de clés USB ou d’autres périphériques externes à moins que vous ne les possédiez. Pour éviter toute infection par des logiciels malveillants et des virus, assurez-vous que tous les périphériques externes vous appartiennent ou proviennent d’une source fiable,
- Verrouillage de l’écran après quelques minutes d’inactivité,
- Désactivation des ports USB non utilisés,
- Mettre un mot de passe au niveau du Bios,
- Désactivation de SMBv1 sur toute l’infra et mettre en place SMBv3 (via GPO),
-
Si vous vous êtes assuré de ne plus utiliser NTLMv1, vous pouvez aller plus loin et essayer de désactiver NTLMv2. NTLMv2 est un protocole d’authentification plus sécurisé, mais il est bien en retard par rapport à Kerberos (le maillon le plus faible de la chaîne Kerberos est le mot de passe. Les mots de passe forts ne pourront pas être piratés par force brute ou volés par des attaques de phishing. De plus, la combinaison de l’authentification multi facteur (MFA) et de mots de passe forts, en feront une équipe gagnante…) en termes de sécurité (bien qu’il y ait moins de vulnérabilités dans NTLMv2 que dans NTLMv1, il y a toujours un risque de se faire capturer des trames et de réutiliser ces données à mauvais escient…).
-
Activation de LDAP sur SSL (LDAPS : port 636 et 3269 ) pour les serveurs Active Directory au lieu de LDAP,
- Réinitialisation du compte krbtgt : ce compte est utilisé pour générer les tickets Kerberos (il existe un script PowerShell pour le faire, ici et la procédure est ici),
- Activation de la Protection LSA (procédure ici),
- Protection des comptes Administrateur locaux en utilisant LAPS (procédure ici, téléchargement, ici)
- Stratégies de défense pour se protéger contre diverses attaques basées sur les informations d’identification (protection des faiblesses de Kerberos, etc…), procédure ici,
- Utilisation de RODC quand c’est possible (sites distant par exemple, etc…),
- Une attention particulière est à porter sur les comptes de service gMSA. Savoir qui a accès en écriture à ces objets est pertinent afin de les protéger, quelqu’un qui peut s’ajouter à l’attribut qui contrôle qui peut interroger le mot de passe a en théorie déjà accès pour prendre en charge ce compte et abuser de ses privilèges. En réalité, le seul compte qui devrait pouvoir obtenir le mot de passe pour ces gMSA serait le compte d’ordinateur sur lequel le gMSA est installé. A monitorer via un serveur SIEM par exemple…
-
Les comptes de service doivent avoir des mots de passe très longs qui sont changés régulièrement. Doubler le nombre de caractères (24) par rapport à la taille que je préconise (12) et les pivoter tous les 10 jours. Même avec du matériel moderne et des outils de craquage de mots de passe, les pirates auront énormément de mal à forcer brutalement les mots de passe avant qu’ils ne soient modifiés.
- Sauvegardes régulières des AD avec tests de récupération en cas de compromission : même les meilleures stratégies de prévention et de détection peuvent échouer, il est donc impératif de créer (et de tester régulièrement !) un plan de récupération Active Directory. N’oubliez pas que les attaquants peuvent détruire vos contrôleurs de domaine soit dans le cadre de leur objectif principal, soit simplement pour masquer leurs pistes, et si vos contrôleurs de domaine sont en panne, votre entreprise sera hors service…,
- IPS sur le réseau actif,
- Segmentation du réseau :
- isoler les AD dans un Vlan dédié (ouvrir les flux sur le Firewall central pour l’authentification, etc…),
- les serveurs sur d’autres Vlan dédiés,
- les PC utilisateurs (par exemple, par services…) également sur des Vlan
- Mettre en place le Tiering Model de Microsoft, procédure ici,
- Vérifier que les logs des AD remontent bien dans le serveur SIEM afin de monitorer toutes tentatives de compromission telles que :
- un pic de tentatives de mauvais mots de passe,
- Les changements de mot de passe suspects sur les comptes sensibles ou les réinitialisations de mot de passe en masse doivent être monitorés (bien qu’ils puissent être plus révélateurs d’une attaque par pulvérisation de mot de passe plutôt que d’une attaque AD). Des éléments tels que la création de services suspects sur un contrôleur de domaine, l’utilisation d’un compte administrateur par défaut ou la réactivation de comptes privilégiés précédemment désactivés sont également des signes potentiels d’une attaque AD en cours,
- verrouillages de compte,
- désactivation ou suppression du logiciel antivirus,
- Utilisation d’outils inhabituels tels que les outils Sysinternals, MimiKatz, Adsiedit, etc.
- modifications apportées aux groupes tels que les administrateurs de domaine, les administrateurs d’entreprise et les administrateurs de schéma,
- événements de connexion/déconnexion,
- etc..
- Désactiver ou supprimer les comptes, groupes, PC, serveurs, etc… inutilisés (exemple de logiciel, téléchargement ici),
- Durcissement de la politique des mots de passe à l’attention des utilisateurs (GPO : conservation de l’historique, durée de vie du mot de passe, seuil de verrouillage du compte, exigence de complexité, etc…),
- Sensibilisation des utilisateurs aux risques de piratage (il faut les sensibiliser à savoir pourquoi on met en place des mots de passe longs et complexes, qu’ils ne doivent pas les noter sur un bout de papier… Par exemple, utilisation d’un gestionnaire de mot de passe, ici…),
- Ouverture de session interactive : ne pas afficher le dernier nom d’utilisateur (GPO),
- Quelques logiciels pour tester la sécurité de l’Active Directory (y en a beaucoup, c’est vrai…) :
- Gold Finger (très bon produit recommandé par un ancien de chez Microsoft…)
- PingCastle
- Bloodhound
- AD Info
- MSCT (Microsoft Security Compliance Toolkit)
- Garder à l’esprit que AD doit rester simple !
« Combien de forêts avez-vous ? Combien de domaines avez-vous ? Combien de contrôleurs de domaine avez-vous ? Gardez ce nombre à un nombre gérable ». Au fur et à mesure que les entreprises se développent, se réorganisent et acquièrent de nouvelles activités, l’environnement AD grossit et interfère avec la visibilité dans sa compréhension. Garder l’architecture aussi simple que possible permettra également de simplifier la gestion.
Voilà, j’espère que toutes ces informations vous seront utiles… Je reviendrai assez souvent sur ce Post afin de le mettre à jour…
A bientôt !
Ressources :
- github.com
- it-connect.fr
- blog.netwrix.com
- microsoft.com
- akril.net
- activedirectorypro.com
Auteur