securisation:windows [wiki.doiteau.fr]

====== Différences ======

Cette page vous affiche les différences entre la révision choisie et la version actuelle de la page.

Lien vers cette vue comparative

--- securisation:windows [2014/11/24 20:21]
r.doiteau [IV - GPO : serveurs]
+++ securisation:windows [2019/05/11 14:35] (Version actuelle)
@@ Ligne 96: / Ligne 96: @@
 ===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 :
-    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 :
-    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>
@@ Ligne 163: / Ligne 159: @@
 ce sont les permissions les plus restrictives qui
 s ’appliquent.
 //Ex: Soit un répertoire partagé **Solaris**
-  * Permissions au niveau du partage :
+Permissions au niveau du partage :
 Tout le monde : Contrôle total
-  * Permissions NTFS locales :
+Permissions NTFS locales :
 Olmèques : LIRE
 Olmèques ne peut pas créer un fichier, il ne dispose que des droits de lecture//
-**TP**
+===TP===
-ntfs :
+**ntfs :**
   * tout refuser pour le groupe invités
@@ Ligne 185: / Ligne 180: @@
 {{:securisation:ntfs.png?400|}}
-smb:
+**smb:**
   * tout refuser pour le groupe invité
@@ Ligne 242: / Ligne 237: @@
       conservation : 3
-{{:securisation:gpo1.png?400|}}
+{{:securisation:gpo1.png|}}
 <note>Editions ENI: Windows serveur 2008 page 52</note>
@@ Ligne 306: / Ligne 301: @@
 Application :
-{{:securisation:gpo8.png?400|}}
+{{:securisation:gpo8.png|}}
 {{:securisation:gpo9.png?400|}}
@@ Ligne 346: / Ligne 341: @@
 {{:securisation:arret1.png?200|}}
-{{:securisation:arret2.png?400|}}
+{{:securisation:arret2.png|}}
 ===Autorisation l'ajout et la suppression des comptes et des des groupes présent dans l' OU UTILISATEURS===
@@ Ligne 352: / Ligne 347: @@
 Création d'une délégation de contrôle sur l'OU UTILISATEURS
-{{:securisation:deleg1.png?400|}}
+{{:securisation:deleg1.png|}}
 {{:securisation:deleg2.png?400|}}
@@ Ligne 416: / Ligne 411: @@
 {{: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|}}
@@ Ligne 430: / Ligne 425: @@
 Création d'une règles gpo, pour plus de visibilité une règle sera créée par éléments a superviser
-{{:securisation:proxy.png?400|}}
+{{:securisation:proxy.png|}}
 {{:securisation:proxy1.png?400|}}
@@ Ligne 447: / Ligne 442: @@
 {{:securisation:hor3.png?200|}}
-{{:securisation:hor2.png?400|}}
+{{:securisation:hor2.png|}}
 {{:securisation:hor1.png?400|}}
@@ Ligne 454: / Ligne 449: @@
 Cette solution n'est utilisable que pour les sessions invités, en effet elle est trop restrictive pour un utilisateurs dit "classique"
+En Effet les gpos appliquées ne permettent une utilisation avancée du poste de tavail.
+//Exemple de restrictions de postes de travail//
+{{:securisation:menu.png?400|}}
+Dans cette exemple, seul la calculatrice en autorisée
+{{:securisation:menu3.png?400|}}
+Le rapport ci-dessous décrit les différents actions apportés aux profils
+{{:securisation:restriction.pdf|}}
 ===Mise en place des restrictions applicatives===
+**Applocker**
+Fonctionnalité de verrouillage d’application implémentée par Stratégies de Groupe
+**Création de la GPO :**
+La configuration d’Applocker se découpe en 3 parties :
+  * Le verrouillage des exécutables
+  * Le verrouillage des installations basées sur Windows Installer
+  * Le verrouillage de l’exécution de scripts
+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.**
+{{:securisation:app.png|}}
 ==== IX - Expliquer les 4 types de règles disponibles dans les restrictions logicielles====
@@ Ligne 510: / Ligne 540: @@
 Pour intégrer une granularité supplémentaire vous pouvez positionner ces règles de zone Internet et ensuite ajouter des règles de plus grande priorité (voir plus haut) pour calquer le plus possible aux spécificités de votre infrastructure.
-{{:securisation:logi.png?400|}}
+{{:securisation:logi.png|}}
 <note tip>http://www.labo-microsoft.org/articles/win/strategie_restriction/1/</note>