====== Différences ======
Cette page vous affiche les différences entre la révision choisie et la version actuelle de la page.
|
securisation:windows [2014/11/26 18:52] r.doiteau |
securisation:windows [2019/05/11 14:35] (Version actuelle) |
||
|---|---|---|---|
| Ligne 96: | Ligne 96: | ||
| ===Pourquoi Préférez le NTLM v2 au NTLM v1=== | ===Pourquoi Préférez le NTLM v2 au NTLM v1=== | ||
| - | |||
| - | Les protocoles "LanManager" et "NTLM v1" ne sont pas sûrs et sont aujourd'hui totalement obsolètes d'un point de vue sécurité. En particulier, en écoutant les échanges faits entre le serveur et le client lors d'une authentification, il est possible avec ces protocoles de capturer l'empreinte du mot de passe de l'utilisateur (voir la référence [3] donnée en fin d'article). Cette empreinte capturée existe sous deux formats dans le monde Windows : | ||
| - | |||
| - | Le format propre à "LanManager" : on parle alors d'empreinte "LM". | ||
| - | |||
| - | Le format "NT" : on désigne souvent cette empreinte sous le nom d'empreinte "NTLM", mais (pour éviter la confusion entre les formats d'empreinte et le protocole d'authentification) nous utiliserons la dénomination d'empreinte "NT". | ||
| Ces faiblesses des protocoles "LanManager" et "NTML" font que, quelque soit la politique de sécurité de l'entreprise (sauf dans le cas où cette politique impose un mot de passe d'au moins 15 caractères, ce qui force alors Windows à ne plus utiliser "LanManager"), les mots de passes des comptes Windows ne seront pas sûrs et pourront être volés. Hors, pour des raisons de compatibilités, ces protocoles obsolètes sont toujours supportés par défaut sur Windows NT4, 2000, XP et 2003. Par exemple, un serveur Windows 2003 installé par défaut : | Ces faiblesses des protocoles "LanManager" et "NTML" font que, quelque soit la politique de sécurité de l'entreprise (sauf dans le cas où cette politique impose un mot de passe d'au moins 15 caractères, ce qui force alors Windows à ne plus utiliser "LanManager"), les mots de passes des comptes Windows ne seront pas sûrs et pourront être volés. Hors, pour des raisons de compatibilités, ces protocoles obsolètes sont toujours supportés par défaut sur Windows NT4, 2000, XP et 2003. Par exemple, un serveur Windows 2003 installé par défaut : | ||
| - | accepte d'utiliser les protocoles d'authentifications "LanManager" et "NTMLv1" | + | * accepte d'utiliser les protocoles d'authentifications "LanManager" et "NTMLv1" et stocke dans sa base de compte (Active Directory ou SAM) les empreintes "LM" des comptes (en plus des empreintes "NT"). |
| - | et stocke dans sa base de compte (Active Directory ou SAM) les empreintes "LM" des comptes (en plus des empreintes "NT"). | + | |
| Pour se protéger contre ces faiblesses, il est impératif de configurer les postes clients et les postes serveurs pour : | Pour se protéger contre ces faiblesses, il est impératif de configurer les postes clients et les postes serveurs pour : | ||
| - | refuser d'utiliser une authentification plus ancienne que "NTLM-V2" | + | *refuser d'utiliser une authentification plus ancienne que "NTLM-V2" ne pas stocker les mots de passe chiffrés (dans la base SAM ou l'Active Directory) sous forme de hash "LM" |
| - | ne pas stocker les mots de passe chiffrés (dans la base SAM ou l'Active Directory) sous forme de hash "LM" | + | |
| + | En effet, les mots de passe ne sont pas stockés en clair, ils sont transformés, par une fonction à sens unique afin de ne garder qu’un condensat (hash), ainsi dans les environnements ayant respecté les règles de bonnes configurations décrites en première partie de cet article (suppression de l'empreinte "LM" et interdiction des protocoles antérieurs à "NTLMv2"), le vol des mots de passe Windows pour un compte de domaine est à priori impossible, si les recommandations suivantes sont appliquées : | ||
| + | |||
| + | * Les mots de passe choisis par les utilisateurs sont complexes (pour résister à des attaques par dictionnaires- bruteforce) | ||
| - | Nota : Ces règles de configuration sont impossibles à mettre en œuvre sur des configurations antérieures à Windows 2000 SP2 (et donc en particulier rendent impossible l'interopérabilité avec d'éventuels postes Windows 98). Ces règles de configuration sont incluses dans les guides de sécurisation publiés par Microsoft depuis 1998 | + | * Ces mots de passe ne sont pas également utilisés dans des environnements moins protégés. Par exemple il n'est pas souhaitable d'utiliser pour son compte de domaine le même mot de passe que pour un compte local (un compte local est plus facile à voler car la compromission d'un poste utilisateur est très souvent beaucoup plus facile que la compromission d'un contrôleur de domaine) ou que le mot de passe de messagerie (qui est souvent enregistré sur le poste de travail). |
| <note tip>http://www.cert-ist.com/public/fr/SO_detail?code=password_windows - {{:securisation:computer_emergency_response_team_-_industrie_services_et_tertiaire.pdf|}}</note> | <note tip>http://www.cert-ist.com/public/fr/SO_detail?code=password_windows - {{:securisation:computer_emergency_response_team_-_industrie_services_et_tertiaire.pdf|}}</note> | ||
| Ligne 415: | Ligne 411: | ||
| {{:securisation:util4.png?400|}} | {{:securisation:util4.png?400|}} | ||
| - | Forcer l'écran de veille au bout de 5 minutes d'inactivité. Demander un mot de passe de sortie de veille=== | + | ===Forcer l'écran de veille au bout de 5 minutes d'inactivité. Demander un mot de passe de sortie de veille=== |
| {{:securisation:util5.png?400|}} | {{:securisation:util5.png?400|}} | ||
| Ligne 486: | Ligne 482: | ||
| Il est nécessaire de créer un jeu de règles par défaut qui autoriseront certaines exécution. | Il est nécessaire de créer un jeu de règles par défaut qui autoriseront certaines exécution. | ||
| - | Ainsi tout ce qui n'est pas explicitement autorisé est refuser. | + | ** Ainsi tout ce qui n'est pas explicitement autorisé est refuser.** |
| + | {{:securisation:app.png|}} | ||
