Archives mensuelles : décembre 2009

Le département magie est en vacances

Et elles sont plus que nécessaires. Retour le 4 Janvier 2010. En attendant bonnes fêtes de fin d’année et avec un peu d’avance bonne année 2010. On reparlera de DirectAccess en janvier 2010, j’ai plein de choses sur le sujet dans les cartons.

 

BenoîtS – Simple and Secure (J’insiste sur le Secure)

HP Sizer For Microsoft Windows Server 2008 R2 Hyper-V

J’ai jeté un œil au produit et là oui je suis preneur. Certes, il se limite aux seules gammes de serveurs et stockages HP mais c’est complet dans la démarche.

 

Le plus important n’est pas le rapport machine virtuelle par hôte mais la capacité pour le stockage à adresser les demandes d’entrée sortie. Un sous dimensionnement du nombre de serveur Hyper-V n’est par rapport à un sous-dimensionnement du nombre d’entrées sortie que le stockage peut adresser.

 

Benoîts – Simple and secure by design (j’insiste sur le “Secure”)

Techdays 2010, les inscriptions sont ouvertes

Tout est dans le titre, ne manque plus que l’adresse pour s’inscrire. La liste des sessions commence à peine à se remplir mais déjà certaines ont attiré mon attention. Voila donc déjà ma première sélection “Sécurité” :

  • Forefront Threat Management Gateway (TMG) 2010 – Demo Extravaganza (par ce que le produit est bon, tout comme ceux qui vont animer la session, na!)
  • Forefront Unified Access Gateway 2010 / IAG 2007 : les passerelles universelles d’accès distants (Ca parle de NAP et de DirectAccess, cela ne peut pas me déplaire, …)
  • Windows 7 & Windows Server 2008 R2 démo extravaganza Reloaded !!! (Définitivement Geek!)
  • Au cœur de BranchCache : optimisez vos bandes passantes avec Windows 7 & 2008 R2 !(Mon prochain mal de tête)
  • Suivez le câble et découvrez les nouveautés réseau de Windows Server 2008 R2 (Je sais pas pourquoi mais ça va faire très mal, level 400, ça augure rien de bon)
  • Meilleures pratiques et retour d’expérience sur le cluster de basculement (Failover Clustering) (Juste pour le fun)
  • DirectAccess avec Windows 7 & Forefront Unified Application Gateway 2010 (Celle la, je peux définitivement pas la louper)
  • Les nouveautés d’ADFS v2 (M’étant pris le mur avec la V1, j’ai décidé de récidiver, …)
  • Maman j’ai rétréci les virus ! (Obligatoire, impératif d’avoir suivi la session de l’année dernière pour comprendre pourquoi)

 

Et encore, ce ne sont que celles du domaine de la sécurité.

 

Benoîts – Simple and Secure by Design (J’insiste sur le “Secure”, na!)

Une réflexion intéressante à faire partager

Pour une fois, je ne vais pas parler technique mais plutôt faire partager les réflexions plus qu’intéressantes de Stéphane PAPP : Les réseaux sociaux sont-ils une mode passagère? A lire et surtout méditer sans modération.

 

Le web 2.0 a développé de nouveaux usages de l’Internet. Le partage d’informations est aujourd’hui une demande de plus en plus croissante de la part des utilisateurs en entreprise.

 

Voila de nouveaux défis pour les responsables de la sécurité informatique qui doivent maintenant jongler entre la sécurité de leur système d’informations et le besoin d’ouverture vers l’extérieur de leurs utilisateurs. l’ouverture des réseaux d’entreprise est en marche (DirectAccess, fallait bien que je fasse de la technique sinon, …)

 

Benoîts – Simple and Secure by Design (j’insiste sur le “Secure”)

Network Access Protection and IPSEC : épisode 8 et fin

Après une parenthèse causée un par l’indisponibilité du blog mais aussi par un projet tout aussi intéressant qu’accaparant, revenons à notre série en cours sur Network Access Protection. Pour ceux qui prennent la série à ce stade, l’infrastructure NAP est totalement opérationnelle. Nous en sommes maintenant à la mise en œuvre des mesures d’isolation.

 

Etant donné que les clients et le serveur NPS ont déjà été traités, il ne reste plus que notre fameux serveur secure.corp.windows2008R2.com pour lequel l’accès doit être restreint si la conformité du poste de travail n’est pas établie. Volontairement, le contrôleur de domaine ne fera pas l’objet de mesure d’isolation car même non conforme, j’ai tout de même besoin de m’authentifier.

 

Donc attaquons nous à notre serveur : secure.corp.windows2008R2.com. Son accès doit être exclusivement réservé aux clients ayant démontré leur conformité. Comme c’est le dernier article, je vais donc skiper certaines étapes considérant qu’elles ont été documentées dans les billets précédents (Je passe en mode fainéant, les vacances approchent, …).

 

Stratégie de groupe d’isolation

Comme pour les deux précédentes mesures d’isolation, on va ici encore travailler avec les stratégies de groupe. On commencera donc par créer un conteneur organisationnel pour les serveurs sécurisés pour y déplacer notre serveur.

SECURE0 

Ensuite, nous pouvons créer une stratégie de groupe pour gérer notre isolation. Nous l’appelleront “NAP Serveurs sécurisés”.Comme pour les autres, on va créer une stratégie d’isolation uniquement pour le mode “Domaine”, le seul qui nous intéresse.

ISOLATION31 

On N’oublie pas le “ping” pour aider au dépannage.

ISOLATION31 

Passons maintenant à la stratégie d’isolation à proprement parlé.

ISOLATION33 

Petite subtilité à ce niveau avec l’exigence d’authentification. Le serveur exigera l’authentification pour les connexions entrantes sans pour autant l’imposer pour les connexions sortantes. Sinon, notre serveur serait incapable de joindre le contrôleur de domaine. Si on voulait être plus que complet alors oui, on exigerait aussi l’authentification sortante mais cela imposerait de positionner aussi une stratégie d’isolation sur le contrôleur de domaine.

SECURE1 

Ici encore, c’est une méthode d’authentification avancée.

SECURE2 

Avec une méthode d’authentification basée sur un certificat, plus précisément un certificat d’état de santé.

SECURE3 

La règle d’isolation ne sera applicable que pour les interfaces de type “domaine”, ce qui est le cas de mon serveur sécurisé, membre de domaine.

SECURE4

Elle sera nommé” IPSEC Secure Rule”.

SECURE5 

Dès lors que la stratégie de groupe est liée au conteneur “Serveurs sécurisés” et que notre serveur a bien appliqué la stratégie de groupe, la magie de l’IPSEC va opérer, à condition que le serveur dispose d’un certificat de santé. Oups, il doit donc lui aussi être placé dans le groupe des exceptions NAP.

 

Des preuves

La meilleure preuve, c’est encore le client qui lui est refusé l’accès au serveur par ce qu’il n’est pas conforme à la stratégie imposée par le serveur NPS.

SECURE6

 

Pourtant, dès que le client remonte un état de santé convenable, il accède bien au serveur sécurisé avec ses données critiques.

SECURE7 

Conclusion

Voila pour Network Access Protection. C’est la fin d’une première plongée dans Network Access Protection. On se rend vite compte que l’infrastructure en elle même n’est pas très compliqué. On peut donc mettre en place NAP sans aucune mesure d’isolation. C’est d’ailleurs ma recommandation. De cette manière on arrive à collecter des informations sur la capacité des systèmes à se maintenir conformes. Par contre, cela deviendra nettement plus complexe dès lors qu’il faudra traiter des mesures d’isolation.

 

On n’a pas tous la chance d’avoir un environnement utilisant les dernières technologies. On a encore beaucoup de serveurs de génération antérieurs pour lesquels la mise en place de la mesure d’isolation est un peu plus complexe à mettre en œuvre. C’est cette phase du projet qui sera la plus complexe puisque selon l’exigence d’isolation définie, on peut en arriver à isoler le poste de tout le système d’information. On constate alors ici les limites de NAP IPSEC et l’intérêt que peut présenter NAP 802.1.x, pourvu que l’infrastructure réseau s’y prête.

 

Benoîts – Simple and Secure by Design (j’insiste sur le “Secure”)

Network Access Protection and IPSEC : épisode 7

Septième étage rayons NPS, HRA et PKI et isolation IPSEC. Après avoir travaillé sur l’isolation des postes de travail, on va s’attaquer à la première zone de sécurité, à savoir celle représentée par le serveur NPS et par extension tout serveur devant être mis à disposition des clients pour fournir des ressources pour se remettre en conformité (qui a dit SCCM?).

 

Qui dit isolation dit stratégies de groupe, on va donc créer une stratégie de groupe applicable aux serveurs contenus dans le conteneur “Frontière” qui contiendra :

  • La configuration du pare-feu
  • La stratégie d’Isolation IPSEC propre à ces serveurs

 

Le programme des réjouissances étant relativement sommaire, entrons dans le vif du sujet.

 

Création de la stratégie de groupe

Etant donné que le serveur NPS est déjà présent dans le conteneur “Frontière”, on ne va pas éditer une stratégie de groupe en prenant le risque que le serveur n’actualise sa configuration avec une GPO partielle. On va donc créer la GPO, la configurer, puis la lier au conteneur.

ISOLATION30 

Le paramétrage de la stratégie de groupe va donc commencer par la configuration du pare-feu. Etant donné que nos serveurs sont nécessairement raccordés au domaine, on va donc se limiter à configurer le mode de domaine.

ISOLATION31 

Comme pour le poste de travail, on va ajouter l’autorisation du “Ping” pour le dépannage.

ISOLATION32 

Bien entendu, si pour des raisons de sécurité notre serveur NPS disposait de deux interfaces réseau (public et privée), alors, il faudra affiner la configuration du pare-feu. Par exemple, ce sera très utile pour DirectAccess (Design in progress, …).

 

Passons maintenant à l’isolation de domaine, qui prendra la forme d’une “Connection Security Rule” qui ne fera que demander dans la mesure du possible l’authentification des communications.

ISOLATION33

Pour rappel, ces serveurs doivent pouvoir rester accessibles pour les postes non conformes.

ISOLATION34

Ici encore, ce sera une méthode d’authentification avancée (certificat).

ISOLATION35

On utilisera des certificats issus d’une autorité de certification racine, uniquement ceux présentant le rôle “System Health Authentication”.

ISOLATION36

Ne disposant que d’une seule interface réseau, sur un serveur raccordé au domaine, il n’est pas nécessaire d’appliquer cette mesure d’isolation aux autres types de réseau.

ISOLATION37

Reste plus qu’à nommer cette stratégie d’isolation.

ISOLATION38

On en a fini avec la stratégie de groupe.

ISOLATION39 

Liaison de la stratégie de groupe

La stratégie de groupe est prête, reste plus qu’à lier la stratégie de groupe au conteneur “Frontière” puis forcer l’application sur le serveur nps.corp.windows2008R2.com.

ISOLATION40 

Pour ceux qui ont suivi, ma configuration ne comprend pas de déclaration des protocoles entrants, même pas pour ICMPv4. La raison est toute simple, c’est que ces ports sont déjà ouverts sur le serveur. Par défaut, il est normal qu’une station de travail ne présente pas ses services de partages et d’impression aux autres. Par contre pour les serveurs, c’est normal qu’ils soient activés par défaut, surtout si certains rôles tels que ADCS en ont besoin (partage CertEnroll pour na pas le citer).

 

Pour rappel, le serveur NPS est membre du groupe d’exception NAP. On garantit ainsi qu’il ne pourra pas être configuré comme un client NAP. Si cela arrivait et que le serveur ne respectait pas les exigences de conformité, on serait bien embêté.

 

Premières constations des experts

Notre serveur NPS dispose bien d’un certificat prouvant son bon état de santé et ce qu’elle que soit son réel état de conformité.

CHECKNPS0 

Depuis le poste de travail Seven1.Corp.Windows2008r2.com (dans un état conforme), il est bien possible d’accéder aux répertoires partagés sur le serveur nps.corp.Windows2008r2.com.

CHECKNPS1 

Coté serveur nps.corp.Windows2008r2.com, on doit constater l’établissement d’une session IPSEC :

CHECKNPS2 

Si on arrête le service “Windows Firewall” sur le poste de travail, on doit constater que le certificat prouvant son bon état de santé a bien disparu :

CHECKNPS3 

Mais qu’il est toujours possible d’accéder aux ressources partagées sur le serveur.

CHECKNPS1 

Bien entendu, l’association de sécurité précédemment constatée, n’est plus. Pourtant le client accède bien au serveur. Donc cela fonctionne. A ce stade de la mise en œuvre, nous avons :

  • Des clients qui sont capable d’envoyer leur état de santé
  • Des clients capables d’exploiter le certificat de santé mis à leur disposition pour communiquer entre eux
  • Des clients capables d’exploiter le certificat de santé mis à leur disposition pour communiquer avec le serveur NPS
  • Des clients capables de communiquer avec le serveur NPS même lorsqu’ils ne sont pas conformes

 

Cela sent bon la fin me direz vous? et bien non, il reste encore deux scénarios d’isolation à mettre en œuvre. Reste t’il seulement deux épisodes? On sait jamais avec les experts, …

 

Benoîts – Simple and secure by design

Network Access Protection and IPSEC : épisode 6

Après avoir mis les pieds dans NAP, passons maintenant à IPSEC. Pour rappel, dans le précédent billet, on a fini par démontrer que NAP fonctionnait sur les postes clients. Les postes conformes disposent d’un certificat numérique. Dès lors qu’ils ne sont plus conformes, le certificat est automatiquement supprimé du conteneur. C’est maintenant que tout se complique. On va utiliser ces certificats.

 

Configuration du pare-feu

Maintenant, il faut rentrer dans le monde d’IPSEC et plus particulièrement dans l’isolation IPSEC. On va donc demander aux postes de travail d’utiliser le certificat mis à leur disposition pour établir des communications sécurisées. Pour cela, on va s’attaquer à la configuration du pare-feu des postes clients avec la GPO “NAP Configuration Clients”. Commençons par configurer une stratégie de par-feu pour les réseaux de domaine :

ISOLATION0 

On va reproduire la même configuration pour les réseaux privés. Pourquoi? Par ce que dès lors qu’on voudra faire du NAP à l’extérieur de l’entreprise (J’ai pas dit DirectAccess?), ce sera fort utile :

ISOLATION1

 

Donc même configuration pour les réseaux publics :

ISOLATION2 

Reste maintenant à déclarer le protocole ICMP comme autorisé pour le troubleshooting (On verra qu’il en faut plus pour que cela fonctionne).

ISOLATION3 

Configuration de l’isolation IPSEC

Voila donc pour le pare-feu, maintenant, il faut configurer le poste de travail pour qu’il exige les communications sécurisées en entrée et sollicite les communications sortantes sécurisées. On reste donc dans la stratégie de groupe mais cette fois pour des “Connection Security Rules”, plus précisément pour une isolation IPSEC :

ISOLATION4

 

L’idée générale sera donc que le client exige que les communications entrantes sont bien authentifiées (à l’aide d’un certificat de santé) et que les communications sortantes devraient l’être aussi si bien entendu le poste dispose d’un tel type de certificat :

ISOLATION5

 

Les communications entrantes authentifiées sont nécessaires car elles vont nous permettre d’isoler les postes entre eux. Pour la méthode d’authentification, point de choix “Certificat” dans l’interface donc ce sera “Advanced” :

ISOLATION6

 

Ce choix va nous permettre de spécifier l’ordre d’utilisation des méthodes d’authentification. Dans le cas qui nous occupe, ce sera le certificat ordinateur issu d’une autorité de certification racine et uniquement si c’est un certificat de santé :

ISOLATION7

 

Cette mesure d’isolation sera appliquée à tous les profils de pare-feu par défaut. Donc par extension, il serait possible d’avoir des stratégies d’isolation distinctes selon les réseaux, donc des certificats distincts, intéressant, …

ISOLATION8

 

On va finir par la nommer, tout simplement :

ISOLATION9

 

Déclarer les protocoles entrants

Un peu au dessus, j’ai indiqué que le trafic réseau entrant devait obligatoirement être authentifié, encore faut-il préciser pour quel type de trafic. Pour nos postes de travail on va faire simple, à savoir l’utilisation des protocoles liés au partage de fichiers et d’impression. En complément, on va même autoriser la réponse aux requêtes ICMPv4 entrantes (Le Ping quoi!). On va commencer avec le trafic réseau entrant pour l’ensemble des protocoles regroupés sous l’appellation “File and Printer Sharing” :

ISOLATION10

 

Et oui, il y en a des règles. Je vais pas faire le tri, on prendra tout ce qui est proposé dans l’interface :

ISOLATION11

 

Et indiquer que les communications entrantes devront être sécurisées, avec quelques finesses :

ISOLATION12

 

La finesse étant d’authentifier la connexion sans pour autant requérir le chiffrement des données. Ce choix va permettre à nos équipes réseau de continuer à analyser le contenu des trames réseau :

ISOLATION13

 

Il est possible de filtrer les communications entrantes en fonction d’un groupe d’un ou plusieurs utilisateurs, dans le cas qui nous occupe, on ne s’en occupera pas :

ISOLATION14 

Idem pour le filtrage d’ordinateurs :

ISOLATION15

 

Nous voila donc avec nos règles de pare-feu entrantes pour les protocoles en liaison avec le partage de fichiers et d’impression :

ISOLATION16

 

Puis, on va s’attaquer au protocole ICMPv4 entrant avec une nouvelle règle de pare-feu entrante. Pas de bol, “Ping” n’est pas un protocole référencé, donc on va faire du sur-mesure :

ICMPINBOUND0

La règle concernera tout le monde sans exception.

ICMPINBOUND1

Mais uniquement le protocole ICMPv4 (Il faudra une autre règle pour ICMPv6).

ICMPINBOUND2

ICMPv4 oui mais uniquement pour le “Echo Request”, ce qui correspond au “Ping” :

ICMPINBOUND3

Et bien pour lui, ce sera autorisé sur le pare-feu en entrée sans nécessiter que la connexion soit sécurisée :

ICMPINBOUND4

Cette règle va même s’appliquer à tout type de réseaux.

ICMPINBOUND5

Elle aura même un nom explicit.

ICMPINBOUND6

Nous voila donc avec nos règles de pare-feu. Reste plus qu’à ce que nos postes actualisent leurs stratégies de groupe pour tester tout cela.

ICMPINBOUND7 

Tester le bouzin

A ce stade de la mise en œuvre de l’isolation IPSEC, on ne peut tester que la communication entre nos deux postes clients. Etant donné que l’ensemble de protocoles en relation avec les services de partages de fichiers et d’impression est autorisé sur le pare-feu en entrée uniquement si l’association IPSEC est en place, voila notre test. Sur mon poste de travail “seven2.corp.Windows2008R2.com”, j’ai créé une console d’administration contenant les composants :

  • Magasin de certificat Ordinateur local
  • Pare-Feu Windows avec sécurité avancée

 

A ce stade, notre poste de travail est bien conforme puis qu’il dispose d’un certificat.

ISOLATION17 

Et lors qu’il tente d’accéder au poste de travail “seven1.corp.Windows2008R2.com”, il y arrive bien car l’association de sécurité est opérationnelle.

ISOLATION18 

Par contre, si j’arrête le pare-feu de mon poste de travail “seven2.corp.Windows2008R2.com”, on constate tout de suite que le certificat n’est plus.

ISOLATION19 

Et que lorsqu’on tente de nouveau au poste de travail seven1.corp.Windows2008R2.com, c’est automatiquement refusé car celui-ci exige l’établissement d’une authentification IPSEC basée sur le certificat.

ISOLATION20 

Pour preuve que ce n’est pas un problème réseau, on va “pinger” notre poste de travail.

ISOLATION21

A ce stade, on en a fini avec l’isolation IPSEC sur les postes de travail. Etant donné que le processus d’isolation repose sur l’exigence d’authentification de l’hôte de destination, il apparait donc clair qu’il faudra mettre en place des stratégies d’isolations pour :

  • Le serveur NPS
  • Le serveur sécurisé
  • Le contrôleur de domaine

Le serveur NPS fera justement l’objet du prochain billet.

 

Note : Pour Windows XP SP3, la configuration sera quelque peu différente mais le principe reste fondamentalement le même.

 

Benoîts – Simple and Secure by Design

Network Access Protection and IPSEC : épisode 5

On commence enfin à s’approcher de NAP. Techniquement, la base est en place, reste maintenant à l’exploiter pour mettre en place NAP puis les stratégies de pare-feu d’isolation de IPSEC.

 

Configuration des différentes stratégies

Pour ceux qui comme moi avaient expérimenté NAP avant la Beta 3 de Windows 2008 (c’est pas si lointain que cela), on n’avait pas encore l’assistant. Certes ils ne font pas tout mais ils permettent de mettre en place une bonne base de travail pour la suite. Commençons donc  par indiquer quelle méthode d’implémentation de NAP nous allons configurer :

NAPCONFIG0

A ce stade, la notion de “client RADIUS” ne nous intéresse pas car le serveur hébergeant le HRA et le NPS sont identiques. Il n’y a donc pas de besoin d’authentification. Par contre, dès lors qu’on désirera mettre en place une forme de tolérance aux pannes ou même plusieurs HRA (interne/externe), il faudra penser à les renseigner à ce stade et les configurer convenablement :

NAPCONFIG1

Il est techniquement possible de filtrer l’étendue d’application de la “Connection Request Policy” à une population donnée. Par exemple, il peut être intéressant de prévoir des stratégies différentes pour les postes nomades, les VIP ou même les serveurs. Dans le cas de la démonstration, on va faire simple (pour rappel, Simple and Secure by Design, c’est ici) :

NAPCONFIG2

Nous en arrivons à la définition de la conformité. Celle-ci s’exprime au travers des SHV coté serveur. Donc si on a plusieurs SHV, il peut être intéressant de les avoir déjà installé. A ce stade, on va indiquer deux choses :

  • Les SHV que l’on va utiliser dans les “Health Policies”
  • Le fait qu’on active ou non la remédiation automatique

Ce dernier point permet au NPS d’indiquer dans sa réponse les ressources à utiliser pour corriger le problème de conformité. Dans le cas de notre expérimentation, j’ai volontairement désactivé cette fonction car elle m’empêche de bien démontrer le bon fonctionnement de NAP (puis qu’elle va corriger le problème de conformité que je vais introduire plus tard dans ce billet) :

NAPCONFIG3

L’assistant finit par nous résumer que qu’il va mettre en place. A ce stade, on peut noter la présence du lien “Configuration Details” qui va générer une page web qui va résumer toute la configuration (utile pour documenter la mise en œuvre, ce qui est une excellente pratique) :

NAPCONFIG4 

Histoire de démontrer le bon fonctionnement de NAP, j’ai volontairement désactivé l’auto-remédiation. En plus, on va délibérément simplifier les exigences de complexité au minimum. La seul critère de conformité sera la présence du pare-feu dans un état actif. Pourquoi faire si simple? Déjà pour démontrer que les mécanismes de base fonctionnent bien. Si tout fonctionne à ce stade, on corsera progressivement la chose. C’est la meilleur démarche pour mettre NAP en œuvre :

NAPCONFIG5

A ce stade, la configuration du NPS intègre :

  • Une “connection Request Policy” indiquant que les requêtes d’authentification arrivant sont bien traitées localement par le NPS (et non redirigées vers un autre NPS).
  • Deux “Health Policy” décrivant les exigences de conformité selon le ou les SHV utilisés
  • Deux “Network Policies” décrivant les conditions requises, les contraintes et la réponse NAP à apporter.

 

Note : Ceux qui iront faire un tour dans les “Network Policies” découvriront qu’il est possible de configurer NAP dans un mode “Audit”. Cela signifie que le NPS va bien identifier le poste client comme non conforme mais que les mesures d’isolation ne seront pas mises en œuvre. L’intérêt de ce mode de fonctionnement est de faire “tourner NAP à vide” pour valider les différents scénarios qui font qu’un poste conforme ne l’est plus (nouveau correctif de sécurité, signature antivirus obsolète, bref tout le cahier de recette normalement prévu dans une phase d’architecture).

 

Petite subtilité de Windows Server 2008 R2, à savoir la possibilité de disposer de plusieurs stratégies pour un même SHV. L’intérêt est de pouvoir proposer plusieurs niveaux d’exigence de conformité. Avec Windows Server 2008, il était nécessaire d’avoir un serveur par niveau de conformité à mettre en œuvre.

 

NAP coté client

Maintenant, il faut penser à travailler sur les clients. On va commencer par créer un conteneur organisationnel pour y regrouper tous les postes de travail :

NAPCONFIG6 

Ceci facilitera la mise en place d’une stratégie de pare-feu avec une stratégie de groupe:

NAPCONFIG7

Le premier paramètre nécessaire, c’est la réactivation du centre de sécurité. C’est ce composant qui assure la collecte des états de santé des SHA. On va commencer par s’assurer que le composant est bien opérationnel car il est désactivé par défaut dans le cas de stations raccordé au domaine :

NAPCONFIG8

Ensuite, le second paramètre, c’est la configuration de la méthode d’enforcement  IPSEC. Globalement, c’est indiquer au client NAP comment remonter son état de santé :

NAPCONFIG9

Le troisième paramètre sera la configuration de l’interface utilisateur en cas de non conformité :

NAPCONFIG10

Pour le suivant, c’est un peu plus complexe. Il s’agit de configurer la liste des serveurs approuvés qui seront utilisés par les clients NAP pour soumettre leur état se santé :

NAPCONFIG11

Les plus attentifs remarqueront que les URL ne sont pas sécurisées. Nous sommes dans le cadre d’une expérimentation. Enfin, il ne nous reste plus qu’à nous assurer que l’agent NAP est bien démarré sur les postes clients. Sans lui, rien ne fonctionnera (Une installation par défaut de Windows Seven ne démarre pas ce service) :

NAPCONFIG12

Positionnons maintenant la stratégie de groupe sur le conteneur ‘”Postes Clients NAP” :

NAPCONFIG13

Et déplaçons les comptes ordinateurs des postes de travail Windows Seven dans le conteneur :

NAPCONFIG14

Tester la conformité du client

Après un bon redémarrage des postes de travail, une simple commande “NAPSTAT.EXE” doit nous indiquer l’état de notre poste de travail :

NAPRESULT0

Cette réponse est normale. Notre seule exigence de conformité, c’est la présence du pare-feu de Windows Seven dans un état activé. Quand on sait que c’est son mode de fonctionnement par défaut, c’est donc normal d’être conforme à ce stade. On peut même constater la présence d’un certificat prouvant l’état de santé du poste de travail :

NAPRESULT1

On a donc la preuve numérique que notre poste de travail a été déclaré conforme par le serveur NPS. Cet état de conformité est valable  :

  • Tant que le certificat n’expire pas (4 heures)
  • Tant que le certificat n’est pas supprimé du conteneur (non conformité détectée)
  • Tant que les conditions restent remplies (attention, petite subtilité avec les correctifs, l’évaluation est réalisée toute les heures avec le SHA Windows)

 

Testons la non conformité du client

Pour notre expérimentation, la définition de la conformité est simple : Le pare-feu doit être actif. Si on arrête le service du pare-feu de la station de travail, c’est automatique :

NAPRESULT2 

Pour vérifier, le certificat à disparu. Le système ne pourra donc plus signer ses communications réseau avec :

NAPRESULT3

Etant donné que l’auto-remédiation a été désactivé, c’est à nous de redémarrer le service pour que l’état de santé remonté par le poste de travail permettre d’appliquer la “Network Policy” de bonne conformité. A ce stade de la mise en œuvre, la mécanique propre à NAP est en place. Il nous reste à traiter les différents scénarios d’isolation :

  • L’isolation d’un client non conforme par rapport aux autres
  • Les ressources accessibles par un client non conforme
  • L’isolation d’un client non conforme lorsqu’il tente d’accéder à des ressources

 

Benoîts – Simple and Secure by Design (MVP sécurité oblige, …)

Network Access Protection and IPSEC : épisode 2

Avant même de renter dans la démarche technique à proprement parlé, il est important de traiter la démarche de mise en œuvre à proprement parlé. Pour cela, une rapide plongée sur le mode de fonctionnement de NAP IPSEC est nécessaire.

 

Tout part du client

C’est le client (aussi dit NAP Client) qui doit faire la preuve de son état de santé. Donc tout part de lui. Plus précisément, le NAP client va collecter les états de santé des différents composants pris en compte (antivirus, pare-feu, antimalware, Windows Update, …) auprès des SHA (System Health Agents). Chaque SHA génère un Statement of Health (SoH) qui seront tous consolidés par le client NAP sous forme d’un System Statement of Health (SSoH). Cet état de santé doit parvenir directement ou indirectement au serveur NPS pour analyse. Dans ce cas d’IPSEC, le client NAP utilise les URL préalablement configurées permettant de contacter le HRA (Health Registration Authority). Le client dispose de deux URL, selon qu’il est intégré au domaine ou non (tiens une piste à conserver, …).

 

Le HRA, intermédiaire de confiance

Le HRA (Health Registration Authority) reçoit la demande d’accès avec le SOH du client. Cet état de santé étant composé de sous-états propres à chaque SHA, le tout est découpé et soumit au NAP Health Policy Servers, gardiens de la conformité. Leur réponse dépendra du paramétrage fixe que nous auront fixé ainsi que d’éventuels critères de conformité extérieurs livrés par les Health Requirements Servers (antivirus, …).

 

Le NPS, au centre de tout

Chaque Soh est analysé selon le SHV correspondant. Les résultats seront analysés au travers des Health Policies qui détermineront si le client est conforme, non conforme ou dans un état intermédiaire (si c’est possible, par exemple deux critères de conformité sur trois, …). C’est le NPS qui se charge de tout cela. Une fois la Health Policy identifiée, il ne reste plus qu’à identifier la Network Policy qui y fait appel pour déterminer la réponse à apporter.

 

Retour au HRA

Si la demande auprès des Health Policy Servers est acceptée, alors le HRA effectue une demande de certificat pour le compte de l’ordinateur soumissionnaire auprès de l’autorité de certification. Ce certificat prouve l’état de santé de l’ordinateur auprès des autres. A ce stade, le HRA retourne un SSoHR contenant le certificat. Dans le cas contraire, la réponse contient entre autres les éléments nécessaires au poste client pour réaliser la remédiation (manuellement ou non).

 

Pour revenir au client

Le client n’a plus qu’à placer ce certificat dans son magasin personnel et l’exploiter pour authentifier et ou chiffrer les communications avec ses partenaires lorsque ceux-ci vont simplement le demander, voire l’exiger (mode isolation IPSEC). C’est le fait de disposer ou non du certificat qui fait qu’on accède plus ou moins au réseau.

 

Et voila pour la théorie sur NAP IPSEC.  Et si on passait à table maintenant?

 

Benoîts – Simple and Secure By Design

Network Access Protection and IPSEC : épisode 1

C’est le début d’un nouveau marathon (ou la nouvelle saison de 24 heures chrono). Je ne vais pas m’attarder sur les aspects liés à la conception d’une infrastructure NAP. Pour cela, l’IPD traitant de NAP est plutôt bien fait. Je vais donc immédiatement passer à la mise en œuvre dans un cas assez simple mais représentatif tout de même.

Le scénario retenu est celui de NAP utilisant IPSEC comme méthode d’enforcement avec des clients Windows Seven et Windows Server 2008 R2, tout ce petit monde sera connecté à un seul réseau LAN tel qu’illustré ci-dessous :

image

Cette mise en œuvre permettra de démontrer :

  • Comment mettre en œuvre les pré-requis liés à NAP
  • Comment isoler les postes de travail déclarés conformes
  • Comment autoriser un accès limité aux ressources du réseau lorsqu’on n’est pas conforme
  • Comment autoriser l’accès à certaines ressources uniquement si on est conforme

Bien évidemment, ce scénario à ses limites (je ne vais pas tout donner non plus), à savoir :

  • La mise en œuvre d’une CA d’entreprise hors ligne
  • Comment travailler avec des critères de conformité plus complexes (autres que ceux proposés par le centre de sécurité du système d’exploitation)?
  • La haute disponibilité d’une telle infrastructure
  • La mise à disposition de services pour l’auto-remédiation
  • Comment traiter les accès extérieurs (vous avez dit DirectAccess?)
  • Comment traiter les systèmes pas encore conforme car fraichement installés

Certes ce sont tous des sujets importants mais qui ne peuvent être traités qu’au cas par cas, en fonction des scénarios et contraintes imposées

Maintenant que les limites sont posées, rentrons dans le vif du sujet avec la longue phase d’installation des systèmes d’exploitation.

Pour les stations de travail, j’ai retenu Windows Seven. D’une part par ce que c’est le dernier OS à la mode mais aussi par ce que la configuration sera plus simple. Il est techniquement possible de faire du NAP IPSEC avec Windows XP SP3, mais c’est juste un peu plus compliqué à réaliser (pas d’intégration d’IPSEC avec le pare-feu par exemple, …).

Pour les serveurs, tous seront installés avec Windows Server 2008 R2 entreprise Edition. D’un point de vue technique, il aurait été possible d’utiliser la version standard de Windows Server 2008 R2 car celle-ci autorise enfin la manipulation des gabarits de certificats dans ADCS. j’avoue que c’est un peu par fainéantise mais aussi que quelque part j’ai une idée derrière la tête avec DirectAccess, …)

image2

Serveur dc.corp.Windows2008R2.Com

  • OS : Windows 2008 R2 Entreprise Edition
  • Nom d’hôte (FQDN) : dc.corp.Windows2008R2.Com
  • Configuration réseau : 192.168.0.100/24 (pas de passerelle)
  • Raccordé au domaine : corp.Windows2008R2.com

Serveur nps.corp.Windows 2008R2.com

  • OS : Windows 2008 R2 Entreprise Edition
  • Nom d’hôte (FQDN) : nps.corp.Windows 2008R2.com
  • Configuration réseau : 192.168.0.101/24 (pas de passerelle)
  • Raccordé au domaine : corp.Windows2008R2.com

Serveur secure.corp.Windows2008R2

  • OS : Windows 2008 R2 Entreprise Edition
  • Nom d’hôte (FQDN) : secure.corp.Windows 2008R2.com
  • Configuration réseau : 192.168.0.102/24 (pas de passerelle)
  • Raccordé au domaine : corp.Windows2008R2.com

Seven1.corp.Windows2008R2.Com

  • OS : Windows Seven ultimate
  • Nom d’hôte (FQDN) : Seven1.corp.Windows2008R2.Com
  • Configuration réseau : DHCP
  • Raccordé au domaine : corp.Windows2008R2.com

Seven2.corp.Windows2008R2.Com

  • OS : Windows Seven ultimate
  • Nom d’hôte (FQDN) : Seven2.corp.Windows2008R2.Com
  • Configuration réseau : DHCP
  • Raccordé au domaine : corp.Windows2008R2.com

Voila pour la phase initiale de mise en œuvre. Pour le prochain billet, nous rentrerons dans l’intimité de NAP IPSEC avant d’attaquer le problème par la face nord, (PKI hell). Bienvenu dans le petit monde de NAP.

Benoîts – Simple and Secure by Design