Active Directory : durcir la sécurité de votre environnement

Dans ce tutoriel dédié à l’Active Directory et à la sécurité, je vais vous donner quelques astuces pour durcir le niveau de sécurité afin d’être moins vulnérable aux attaques.

Les différents points de configuration, qui vont être aborder permet simplement de rentre les attaques en interne plus difficile et plus longues, en aucun elles vont garantir que vous êtes invulnérable.

Ce qui faut savoir, c’est que votre première allié est le temps, plus il sera « difficile » et long, plus vous aurez de chance que le ou les attaquants passent à autre chose.

Avant d’appliquer les paramètres, ils convient de tester en environnement restreint afin de ne pas créer plus de problème, surtout sur des environnements Active Directory ayant plusieurs années.

Désactiver le support de SMBv1

Un des premiers points, c’est de désactiver le support du protocole SMBv1 sur l’ensemble des ordinateurs (serveurs et postes clients).

Depuis Windows 10 et Windows Server 2019, le support de SMBv1 est désactivé par défaut.

Afin de savoir si le protocole SMBv1 est activé, utiliser la commande suivante :

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Avant de désactiver SMBv1, il est possible de vérifier si celui-ci est encore utilisé sur un serveur.

Pour cela utiliser la commande ci-dessous :

Get-SmbSession | Select-Object -Property ClientComputerName, ClientUserName, Dialect

Cette commande retourne l’adresse IP du périphérique, le nom utilisateur et la version SMB utilisée pour accéder aux partages.

Si vous avez des « vieux » équipements (copieurs, scanner …), il est possible qu’ils ne supportent un version supérieure de SMB.

Il est aussi possible d’activer l’audit d’accès SMBv1 :

Set-SmbServerConfiguration -AuditSmb1Access $true

Une fois activée, il faut recherche les événements avec l’ID 3000 dans le journal : Microsoft-Windows-SMBServer\Audit.

Pour désactiver le protocole SMBv1, il y a plusieurs solutions.

Désactiver le protocole SMBv1, cette solution est à effet immédiat et ne nécessite pas de redémarrage (Windows 8.1 / Server 2012R2 ou plus récent) :

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Pour désactiver le protocole SMBv1 sur les versions ultérieures de Windows (7, Vista, Server 2008 et Server 2008R2), il faut modifier le registre :

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type DWORD -Value 0 -Force

Pour la prise un compte un redémarrage est nécessaire.

Pour Windows 8.1 / Server 2012R2, il est aussi possible de désinstaller le support du protocole SMBv1, ici un redémarrage est nécessaire :

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

J’ai également rédigé un tutoriel sur la désactivation du protocole SMBv1 (Serveur / Client) par stratégie de groupe : https://rdr-it.com/gpo-desactiver-smbv1/

Activé la signature sur le protocole SMB

Afin de se « protéger » d’attaque de Man-in-the-middle (MITM), il est possible d’activer la signature sur les échanges du protocoles SMB.

La signature SMB fonctionne avec SMBv2 et SMBv3.

La configuration de la signature peut se faire :

• au niveau du client
• au niveau du serveur

A partir du moment où l’un des deux négocies la signature, le flux SMB sera signé.

La configuration se fait au niveau des stratégies de groupe : Configuration ordinateur / Paramètres Windows / Paramètres de sécurité / Options de sécurité. Les deux paramètres à activer :

• Client réseau Microsoft : communications signées numériquement (toujours)
• Serveur réseau Microsoft : communications signées numériquement (toujours)

Là aussi, je vous conseille de tester sur quelques ordinateurs avant d’appliquer cela à l’ensemble de votre parc, pour ma part, j’ai eu des soucis avec des serveurs RDS au niveau des accès aux partages.

Pour plus d’informations je vous invite à lire cette page : https://docs.microsoft.com/fr-fr/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always.

Désactiver l’authentification LM et NTLMv1

Toujours dans les « vieux » protocoles, il est nécessaire de désactiver les protocoles LM et NTLMv1 qui ont des hash de mot de passe très facile à passer en brute force.

Petit complément sur le fonctionnement de NTLM et Kerberos : https://academy.rdr-it.com/lesson/authentification-ntlm-et-kerberos/

Une fois de plus, la désactivation peut se faire par stratégie de groupe à l’emplacement : Configuration ordinateur / Paramètres Windows / Paramètres de sécurité / Options de sécurité

Il faut configurer le paramètre : Sécurité réseau : niveau d’authentification LAN Manager.

Pour cela il faut cocher Définir ce paramètre de stratégie et sélectionner : Envoyer des réponses NTLM version 2 uniquement\Refuser LM et NTLM

Ce paramètre c’est dans un monde idéale, si NTLMv1 doit encore être utilisé, utiliser ce paramètre pour désactiver LM : Envoyer uniquement les réponses NTLMv2\Refuser LM

Si vous devez utiliser ce paramètre, des HASH NTLMv1 peuvent encore circuler sur le réseau et ceci sont vulnérables aux attaques par brute-force plus rapidement que NTLMv2.

Il est possible d’auditer le trafic NTLM en activant les paramètres afin d’identifier où NTMLv1 est utilisé

• Sécurité réseau : Restreindre NTLM : Auditer le trafic NTLM entrant
• Sécurité réseau : Restreindre NTLM : Authentification NTLM dans ce domaine

La configuration de NTLM permet pas mal de souplesse au niveau de sa configuration et d’ajouter des exceptions.

Désactiver LLMNR, NBT-NS et MDNS

LLMNR (Link-Local Multicast Name Resolution) et NBT-NS (Netbios Name Service) sont deux « protocoles » de résolutions de nom de broadcast/multicast qui sont activés par défaut, ils sont utilisés quand la résolution de nom dns échoue.

Si vous utilisez un logiciel type Wireshark pour écouter le réseau, vous verrez qu’il y a beaucoup trafic LLMNR et NBT-NS.

Le principal danger de LLMNR et NBT-NS, c’est qu’il est facile d’envoyer une fausse réponse avec un autre ordinateur afin de récupérer un hash NTLM du client qui a fait la demande.

Ci-dessous des captures d’écran de responder qui permet de répondre aux requêtes LLMNR et NBT-NS

Maintenant, on va voir comment désactiver LLMNR et NBT-NS

Désactiver LLMNR

Bonne nouvelle, LLMNR se désactive par stratégie de groupe en configuration le client DNS des ordinateurs.

Pour désactiver LLMNR, il faut activer le paramètre Désactiver la résolution de noms multidiffusion qui se trouve à l’emplacement : Configuration ordinateur / Modèles d'administration / Réseau / Client DNS.

Après application de la GPO sur les ordinateurs du domaine, il n’utiliseront plus LLMNR.

Si vous avez des ordinateurs hors domaine, il sera nécessaire de le faire dessus.

Désactiver NBT-NS

Ici, ça se complique un peu car NBT-NS est configuré au niveau de la carte réseau et il n’y a pas de stratégie de groupe applicable. La bonne nouvelle, c’est que pour les ordinateurs clients (principalement poste de travail), il est possible de le faire par une option sur le serveur DHCP.

Au niveau des options (étendue ou serveur), il faut configurer l’option 001 Options Microsoft de désactivation du NetBios dans la classe fournisseur Option Microsoft Windows 2000. Il faut entrer la valeur 0x2 pour désactiver NBT-NS.

Pour les ordinateurs qui ne sont pas en adressage automatique, il faut désactiver Netbios sur la ou les cartes réseaux.

Ouvrir les propriétés de la carte réseau.

Sélectionner Protocole Internet version 4 (TCP/IPv4) et cliquer sur Propriétés.

Depuis l’onglet Général, cliquer sur Avancé.

Aller sur l’onglet WINS, et sélectionner Désactiver NetBIOS sur TCP/IP.

Fermer les différentes en validant la configuration.

Il est possible de désactiver Netbios par GPO à l’aide d’un script PowerShell exécuté au démarrage.

Voici le scripts :

Désactiver MDNS

La désactivation de MDNS se fait à travers une clé de registre.

Il faut ajouter la valeur DWORD 32 bits EnbleMDNS à la valeur 0 à l’emplacement suivant : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient

Pour le faire par GPO : GPO : ajouter une clef registre

Quelques pistes supplémentaires

Voici quelques pistes supplémentaires :

• Déployer LAPS sur les ordinateurs et serveurs afin d’avoir des mots de passe administrateur local différent.
• Signer votre zone DNS (DNSSEC)
• Auditeur régulièrement les comptes à privilèges.

Il est également important de suivre quelques règles d' »hygiène » simple :

• Limiter l’utilisation de compte à privilège (admins du domaine)
• Ne pas utiliser des comptes admins du domaine sur des stations de travail
• Mettre à jour régulièrement les serveurs et ordinateurs
• Mettre à jour les applications (Serveur web, base de données … )
• S’assurer d’avoir un antivirus à jour
• S’informer des bulletins de sécurité : https://www.cert.ssi.gouv.fr/

Concernant le dernier point que je vais aborder, c’est les mots de passes, pour les comptes administrateurs du domaine, privilégié des mots de passe long (20 à 30 caractères) qui prendront beaucoup plus de temps à être « brute-forcé » qu’un mot de passe de 8 caractères même avec une complexité.

N’oublier également d’auditer votre Active Directory gratuitement avec Ping Castle.