Alors de quel mécanisme de sécurité vais-je aborder ?

Dans l’ère du temps, nous parlons sans cesse de PAM¹, PIM², ZTNA³, termes qui jusqu’il y a quelques années étaient obscurs et commençaient tous justes à émerger. Si aujourd’hui ces termes sont incontournables, je m’interroge à implémenter ces derniers dans un environnement OnPremise (pour ne pas dire mon environnement) en tenant compte :

• Du modèle de tiering de l’infrastructure
• De la segmentation en place des rôles et permissions
• Du durcissement de sécurité

Toutefois et encore une fois, comme le disait un ancien collègue la sécurité ce n’est pas pratique et je souhaite mettre en place une certaine souplesse à certains comptes utilisateurs bien identifiés.

Pif, PAM, Pouf, Je suis informaticien ; Pif, PAM, Pouf ça c’est vraiment trop bien !

Donc me voilà parti pour l’étude et l’implémentation d’une des fonctionnalités PAM fournit par Windows, l’appartenance temporaire à un groupe ou Temporary Group Membership (TGM⁴).

Avant-Propos

Je pars du principe que nous avons un environnement Windows avec un contrôleur ADDS⁵. Ce dernier est OnPremise est non hybride (pas de jonction avec AAD⁶).

Notre architecture se base sur la segmentation en tiering de notre SI⁷ et notre ADDS est durci selon les préconisations de l’ANSSI⁸.

L’objectif que je me fixe est donc de mettre en place la fonctionnalité d’attribution de droit d’administration temporairement à un utilisateur sans à avoir de :

• Créer un compte d’administration dédié à un usage ponctuel
• D’attribuer les droits d’administration (domaine ou local) permanent

Comme d’accoutumé (car nous ne changeons pas les bonnes vieilles habitudes) l’environnement Windows sera durci selon les bonnes pratiques et j’utiliserai mes deux contrôleurs de domaine 2025 en CORE.

Prérequis

• SE :
  • Windows Server : 2k16 et version ultérieures
• Apps :
  • ADDS
• Autres :
  • Non applicable

Théorie

Il est important de comprendre comment fonctionne et ce qu’apporte l’ajout de la fonctionnalité « Privileged Access Management Feature ».

Il est impératif et primordial que l’ensemble des serveurs AD soit au minima en version WS 2k16 et donc que le schéma de la forêt soit en version 2016.

Au vu des derniers propos énoncés, nous pouvons nous douter que nous allons altérer le schéma de notre AD. Ce qui est implicite (mais enfonçons une porte ouverte), l’installation de cette fonctionnalité sera irréversible (oui c’est une extension du schéma… La base j’en encore envie d’écrire. Oups c’est fait).

Extension du schéma Active Directory

Je juge important de savoir ce qui va être ajouté. C’est pourquoi une sous partie va être nécessaire pour regarder plus en détail la liste des nouveaux objets et attributs.

La liste n’est pas longue. Toutefois il convient de rappeler que « ce n’est pas le nombre d’objet qui fait la force » mais leur usage.

Et avec tous les points, quand est-il des risques ? Oh quasi rien (#MDR)

Risques

Structurels

L’un des premiers risques seraient lors du déploiement de la fonctionnalité. Il est important de bien prendre en compte le côté irréversible de l’opération. Je recommanderai de vérifier en amont l’état de santé des DCs et de la topologie souhaitée. L’objectif étant de ne pas se coltiner une dette technique des familles à la suite d’une mauvaise conception.

Délégations

Attention à la délégation sur notre container (CN=Shadow Principal Configuration). Si ces derniers sont trop larges un type comme Waldo peut se définir Admin du Domain en créant un ShadowPrincipal. Et hop ! Une escalade invisible…

Sécurités

Continuons de parler d’escalade (perso, moi c’est le bloc jusqu’à ce que je ni**e deux ménisques), le risque d’une escalade furtive et temporaire…

Les mécanismes PAM octroyant des droits temporaires, l’usage d’un compte admin temporaire serait peu visibles dans les journaux d’audit et sont souvent peu, voire mal surveillés. Ainsi, un attaquant peut devenir Admin du Domain pour 1 heure réaliser une opération de type DCsync plus la création d’une backdoor et ce je la jouer à la David Copperfield…

Une attaque directe par ShadowPrincipals à travers un compte compromis ayant les droits PAM. De cette manière, notre Charlie ou Waldo peut créer un ShadowPrincipal ajoutant un TTL à un groupe d’administration (Tiers 0) sans à avoir besoin de modifier directement le groupe. Cette méthode permettrait de contourner un grand nombre de mécanisme de sécurité en place.

L’attaque par SID, le classique des classiques. Comme vu précédemment, l’attribut msDS-ShadowPrincipalSid accepte des SID internes et externes (dans le cas de forêt approuvé). Ainsi, une mauvaise gestion des relations d’approbations ou la compromission d’une forêt externe donnerait automatiquement un accès privilégié au SI local.

Opérationnels

La perte d’un accès administrateur qui aurait été délégué sur une mauvaise évaluation de la durée du TTL pourrait être lourd de conséquence. Risque de ne plus être administrateur durant une opération critique nécessitant les droits d’administrations par exemple et donc de se retrouver totalement bloqué.

Une complexité trop élevée peut également relever d’un frein. Cela peut rendre les débogages longs et fastidieux (un peu comme ma b**e… Très très drôle M’sieur…) ainsi que des comportements inattendus. La pire chose possible reste la mauvaise formation des équipes et le risque d’erreurs fréquentes par les équipes de Niveau 0 ou 1.

Gouvernances et Humains

De la mauvaise formation des équipes relèvent souvent de processus non définis ou totalement ignoré. Ainsi il ne serait pas rare d’assigner des TTLs trop longs dans le temps pour avoir la paix (qu’est-ce que la sécurité peut être pénible) ou de définir des TTLs trop courts et d’enchainer les élévations temporaires.

Se pose alors la question de « Mais à quoi sert le PAM finalement ? »

L’excès de confiance et son mauvais usage peut entrainer un faux sentiment de sécurité. Le PAM a été implémenté, nous ne risquons rien. Sauf que les comptes d’administrations ne sont pas protégés correctement et dans le cas de compromission d’un poste admin… Je ne fais pas de dessin hein ?

Audits et Conformités

Comme inscrit précédemment, les journaux d’évènements sont assez difficiles à identifier et à corréler dans le cadre d’attribution temporaire des droits. Ainsi, l’expiration d’un TTL n’est pas un évènement clair pour l’audit. Ce qui peut facilement limiter l’analyse et le diagnostic de la part des équipes.

C’est pourquoi il va être nécessaire de porter une vigilance particulière sur les événements suivants :

Event ID	Description / Rôles / Types
4728	Ajout à un groupe global
4732	Ajout à un groupe local
4756	Ajout à un groupe universel
4729	Expiration ou Suppression à un groupe global
4733	Expiration ou Suppression à un groupe local
4757	Expiration ou Suppression à un groupe universel
5137	Création d’un objet
5136	Modification d’un objet
5141	Suppression d’un objet
4672	Attribution de privilège élevés
4624	Logon d’un compte ayant des droits d’administration
4634	Logoff d’un compte ayant des droits d’administration
4648	Logon explicite d’un compte ayant des droits d’administration
4662	Accès d’objets AD sensibles
4719	Modification audit policy
1102	Effacement des journaux
4768/4769	Kerberos (corrélation des TTLs)

A cela s’ajoute les diverses solutions du marché qui viennent auditer la santé des SIs et notamment celui des AD. Ces derniers ne prennent pas en compte l’attribut member;TTL et ShadowPrincipal. Les SIEMs¹⁴ valant paroles d’évangiles pour les SOCs¹⁵, hop ni une ni deux l’informations passent à la trappe.

Recommandations

Les objectifs sont de pouvoir garantir AUCUN accès administrateur permanent afin d’obtenir une élévation temporaire, traçable et approuvée (je reviendrai sur ces points dans la partie pratique). Tout cela afin de contenir et maitrisé en cas de compromission l’impact ainsi que la surface d’exposition.

Il est également primordial de comprendre que l’usage du PAM au sens windows du terme ne doit servir que pour :

• Admin du Domaine
• Administrateur de l’entreprise
• Administrateur du schéma
• Administrateurs DC¹⁶
• Autres (Comptes ADCS¹⁷, ADFS¹⁸, AAD Connect)

L’usage pour du helpdesk ou pour des serveurs applicatifs doit être proscrit. Ce qui est logique car il revient à Services Informatiques d’arbitrer sur les demandes utilisateurs. Néanmoins, pour octroyer des droits d’administrateur à un stagiaire ou prestataire ça fonctionne très bien mais encore une fois sous réserve DE certains mécanismes.

Cela passe donc par plusieurs axes.

Architecture

Il est important de noter qu’avant toutes choses, les serveurs en Tiers 0 ne doivent pas avoir accès à internet en dehors des URLs approuvés (et c’est non négociable) et ne doivent contenir QUE les logicielles d’architecture et de sécurité (donc vous me virez vos salop***ies de NinjaRMM, LogMeIn, TeamViewer et compagnie).

• URLs des serveurs antivirus (genre TrendMicro etc)
• URLs des serveurs de mises à jour Microsoft

Il va de soi qu’étant en Tiers 0, le réseau est isolé et filtré en entrée et sortie. Il n’y a pas d’administration direct depuis une ressources de Tiers 1 ou 2.

Ci-contre, la topologie comme cette dernière devrait l’être avec MIM et PAM. Le fait d’intercaler un server MIM-PAM entre notre ADDS et nos postes clients permettent d’user comme dit précédemment des mécanismes d’approbations de workflow et d’automatisation. Le serveur PAM doit être vu comme un bastion dans un réseau isolé de niveau T0.

La mise place d’une telle architecture va être relativement complexe pour moi au vu des ressources disponibles niveau homelab. Je vais donc me passer du serveur intermédiaire MIM PAM.

Cette topologie est compatible et valide bien qui moins recommandée quant aux risques accrus relatif à l’audit et d’un contrôle moins efficace. Cela nous demandera donc en contrepartie d’être irréprochable sur les groupes, droits et permissions lié à la délégation. Il sera nécessaire d’avoir un regard et contrôle réguliers des scripts Powershell.

Donc me concernant je resterai sur mon modèle en place de tiering T0-T1-T2 avec segmentation et contrôle des flux.

Comptes & IDs

Cela me semble logique, mais important de le répéter il ne faut en aucun cas user d’authentification interactif et de ne pas utiliser de compte administrateur. Et cherry on the cake, les comptes sont TOUJOURS nominatifs (oui même pour vous les éditeurs).

Ainsi, pas de compte admin permanent. 🙂

Néanmoins, il est important d’avoir des comptes brises-glaces afin de ne pas se couper l’herbe sous le pied. Dans la logique il en faudrait minimum deux et selon l’ANSSI maximum deux (Décidemment la sécurité c’est borderline). Naturellement ces comptes doivent être utilisés en cas d’extrême urgence et lors de leurs usages une alerte doit être notifiée.

Ce qu’il faut comprendre avec PAM, nous ne mettons pas tous nos œufs dans le même panier.

Nomenclatures des groupes

Après ce qui a été dit dans le volet ci-haut, il est nécessaire de définir des GGS¹⁹ propres au PAM et d’ajouter ces derniers en tant que membre des groupes adéquates.

Ainsi pour ma part j’userai de la nomenclature suivante :

GGS_PAM_NOM_Elevation

Simple et efficace.

Durée de vie

Crucial dilemme de la définition de la durée de l’élévation de droit temporaire… Dans la logique une intervention standard est de 30 à 60 minutes en cas de crise nous pourrions définir 120 minutes maximum. Toute durée supérieure à 2 heures et donc interdit.

Oui mais voilà, je dois faire une opération sensible en tant que SysAdmin sur un SI sur la journée comment je fais ?

Excellente question à laquelle je répondrai, nous sommes SysAdmin et donc nous avons l’accréditation pour intervenir sur notre SI. Donc je n’utiliserai pas PAM mais le système classique de mon compte utilisateur avec élévation de droit avec mon compte administrateur délégué ou super administrateur.

Mon presta doit faire une montée de version de la solution applicative sur l’un de nos serveurs pour la journée soit 7 heures de boulot. Comment tu réponds à ça Monsieur jesaistout ?

J’ai pour habitude de ne jamais laissé un prestataire intervenir seul sur mon SI ou un SI sous ma responsabilité. Donc je passe ma journée à surveiller d’un coin de l’œil ces actions. Et dans son cas, je me note de renouveler personnellement toutes les deux heures ça durée de vie. Généralement il n’y a pas trop besoin car le prestataire est administrateur local du serveur mais certaines fois il est nécessaire de lui octroyer les droits d’administrations du domaine (et ça, ça fait froid dans le dos et en dit long sur la topologie de la solution applicative…).

En complément, il en va de soi mais la tacite reconduction des renouvellements des TTLs et à bannir et encore une fois pas de TTL trop long par ne pas être emme**é toutes les deux minutes.

Bien je pense qu’avec tout ça nous en savons assez pour passer à la pratique non ?

Pratique

Installation

Commençons par vérifier le niveau fonctionnel de notre forêt. Nous retrouvons la commande qui devient normalement un automatisme maintenant 🙂

> Get-ADForest

La preuve à l’appui, ci-contre la preuve que pour l’attribut ForestMode la valeur Windows2016Forest est présente. Donc les prérequis sont atteints. Néanmoins, je recommande un petit contrôle de santé de l’AD par précaution et actions avant de poursuivre.

Vérifions maintenant si la fonctionnalité est déjà présente ou non sur notre SI.

> Get-ADOptionalFeature -Filter "name -eq 'Privileged Access Management Feature'"

Si la valeur de l’attribut EnabledScopes est vide, la fonctionnalité n’est pas déployée sur le système. Sinon ba elle l’est déjà. Evident Cap’taine Obvious !

Activons alors cette fonctionnalité.

/!\Attention : C’est à ce moment que l’opération devient irréversible. Et deuxième point de vigilance il faut que nous soyons administrateur du schéma temporairement

> Enable-ADOptionalFeature 'Privileged Access Management Feature' -Scope ForestOrConfigurationSet -Target ronelab.lan

Il suffira de valider le déploiement en activant la touche T pour oui pour tout. Et quelques secondes plus tard, c’est terminé. Oui tous ces mots pour ça… Il faut bien faire durer le plaisir non ? <3

Si nous voulons vraiment valider le bon déploiement de notre fonctionnalité, nous pouvons rappeler la seconde commande ci-haut pour vérifier les paramètres d’activation de notre scope.

Nous constatons donc que cette dernière n’est plus vide ou $null. Nous pourrions également aller nous balader dans la configuration de notre AD pour trouver notre container.

Place à l’assignation temporaire des droits 🙂

Attribution temporaire

Bhin alors comment qui font qu’on fait pour assigner des droits temporaires ?

De la manière la plus simple du monde gazier, même si au passage il faudrait parler un langage au minima courant plutôt que familier.

Pour se faire, un compte admin et un accès à l’un de nos DCs en powershell (où au DC en lui même). Je proscris volontairement les RSATs. Pourquoi ? Parce qu’un DC doit être le plus isolé possible.

# Définir notre TTL en secondes en tant que variable de type Timespan
> $ttl=New-TimeSpan -Hours 1 -Minutes 15
# Ajouter notre utilisateur temporairement au groupe
> Add-ADGroupMember -Identity "GGS_PAM_AdminDomain_Elevation" -Members "john.doe" -MemberTimeToLive $ttl

Et c’est tout. Je vous l’avais dit, rien de bien difficile. Un peu de RTFM et de ligne de commande… Ce qui est intéressant c’est de s’attarder sur les événements de sécurité. Nous retrouvons avec exactitude ce que nous avons énoncé dans la partie théorie concernant le périmètre d’audit.

Ouai mais alors comment vérifier que notre utilisateur à bien des droits qui court dans le temps ?

Vérifications et Analyses

Soyons un peu curieux et penchons nous dans les attributs de notre objets utilisateurs, groupe d’élévation (auquel appartient notre utilisateur) et notre groupe final.

No Surprise ! Il n’y a rien !

Etonnant non ? 🙂 J’ai été surpris et j’ai donc reparcouru la documentation en long, large diagonale… Pourquoi pouvons nous obtenir l’information en powershell (oups j’ai divulgâché la suite) et pas en GUI ?

C’est là que c’est malin. La durée de vie se trouve sur le lien entre l’objet utilisateur et le groupe d’appartenance (rien sur le groupe cible ce qui est logique).

> Get-ADGroup -Filter * -Properties members -ShowMemberTimeToLive | Where-Object {$_.members -match "TTL*"}

Et donc côté Kerberos qu’est ce qui se passe ? La documentation en parle et nous invite à être vigilant sur ces événements (4768 et 4769). Naturellement comme tout ajout à un groupe, il est nécessaire de fermer et d’ouvrir de nouveau la session pour prendre en compte le changement.

#Dans le contexte de l'utilisateur
> klist

Nous pouvons donc constater (modulo mon temps d’ouverture de session) que notre TGT20 à une durée de 1h11 / 1h15. Ce qui correspond à la durée définit dans notre délégation. Une fois le temps imparti passé, le ticket sera renouvelé et donc les droits temporaires d’administrations retirés.

Et alors côté journaux d’événements qu’elles sont les nouvelles ma sœur Anne (#BARBEBLEU) ?

J’ai envie de dire il suffit de parcourir les journaux d’évènement de sécurité.

Bon par contre ne nous cachons pas c’est un peu pénible pour ne pas dire casse-cou***e de taper les requêtes powershell. Il faut définir le TTL, connaitre les SAMs des utilisateurs, connaitre les groupes. Bref, source d’erreur à gogo. Alors à votre avis en tant que fainéant qu’ais je bien pu faire ? 🙂

Applications

Oui, cela peut paraitre étrange, mais j’ai réalisé une application GRAPHIQUE. Un jour à marquer dans les calendriers FOR SURE d’une bière blanche !

J’ai commencé à faire l’outil en PS CLI, mais j’ai vite trouvé que cela n’était pas ergonomique. Alors je me suis demandé pourquoi ne pas réaliser une application en VB.NET ? Flemme monstrueuse. Puis pourquoi pas reprendre une frustration passé du GUI en powershell ?

Hé bien voilà, que je réouvre une vieille blessure et alors quel pied put**n ! Je me suis éclaté.

Bon il reste quelques points à améliorer :

• Multitâche pour retourner les valeurs de l’AD
• Ajouter des petites icones sympas
• Ajouter un petit About (j’ai droit à mes droits d’auteur)
• Publier l’application en certifiant cette dernière
• Quelques contrôles d’erreurs ? :p

Bref pas mal de petite chose mais rien de bien méchant.

Démonstration

Rien de telle qu’une petite démonstration en images successives pour comprendre, aussi appelé vidéo.

Github

Miaou

Conclusion

Je mettais attaqué à ce morceau en ne pensant à la base ne pas y consacrer autant de temps. Je me suis rendu compte une nouvelle fois que ce sont les choses les plus simples qui requiert davantage de recul et de réflexion.

Je lutte encore entre les bonnes pratiques et recommandations contre mon usage et le périmètre d’applicabilité. Dans un certaine mesure PAM, PAM, PAM je me mettrai bien une cartouche pour ne pas avoir connu plus tôt cette fonctionnalité. Bref, il est nécessaire d’étudier avec sérieux son implémentation et son usage.

Je n’ai volontairement pas abordé le système de délégation des droits AD et sur les GPOs. Mais cela reste un impondérable car tout va reposer sur cette base. Ouvrir d’un côté pour mieux fermer de l’autre, dilemme cornélien que la sécurité. Et honnêtement si j’avais traité ce point, l’article serait insoutenable (comme la poitrine de PAMELA dans Alerte à Malibu ; Franchement tu devais la faire celle-là espèce de 90tard, tu ne pouvais pas t’en empêcher ?).

Je suis conscient qu’il reste des axes d’améliorations (notamment sur le code). Toutefois, je pense que si suite il doit y avoir cela plus sur PIM ce qui ouvrira la voie vers l’environnement Azure.

Le mot de la fin :

Si je PAM sur PAMELLA ? J’offre un CADEAU en infogérance ? Malheureusement vous ne pouvez pas Jean-Pat il y a une « couille dehors » en diagonale. Vous retournez en case magouille. Un partout PAM au centre…

Erwan GUILLEMARD

Sources

• Microsoft : Fonctionnalités WS 2k16
• Microsoft : PAM
• Microsoft : Class ShadowPrincipal
• Microsoft : Class Container ShadowPrincipal

1. PAM : Privilege Access Manager ↩︎
2. PIM : Privilege Identity Manager ↩︎
3. ZTNA : Zero Trust Network Access ↩︎
4. TGM : Temporary Group Membership ↩︎
5. ADDS : Active Directory Domain Service ↩︎
6. AAD : Azure Active Directory ↩︎
7. SI : Système d’Information ↩︎
8. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
9. SID : Security IDentifier ↩︎
10. AD : Active Directory ↩︎
11. TTL : TimeToLive ↩︎
12. MIM : Microsoft Inditity Manager ↩︎
13. PIM : Privileged Identity Manager ↩︎
14. SIEM : Security Information Event Management ↩︎
15. SOC : Security Operation Center ↩︎
16. DC : Domain Controler ↩︎
17. ADCS : Active Directory Certificates Services ↩︎
18. ADFS : Active Directory Federation Services ↩︎
19. GGS : Groupe Global de Sécurité ↩︎
20. TGT : Ticket Granting Ticket ↩︎

Plus sérieusement et sans détour, il se trouve que ce sont les choses les plus simples dans la vie qui sont le plus souvent bâclées ou négligées. C’est pourquoi je me suis dit, et si je m’attardais un peu plus sur les politiques de mots de passe dans un environnement WINDOWS ?

Il relève de nombreux articles déjà sur le net qui traite ce sujet, mais voyez-vous encore une fois je pense aller un peu plus loin que les excellents articles déjà présents. Difficile de parler de ce que j’ai fait sans toutefois présenter les bases 🙂

Mais alors jusqu’où es-tu allé cette fois ci ?

Je suis parti de la politique classique de définition de la politique de mot de passe dans un domaine AD¹ et du traitement des événements de verrouillage de compte. Sujet traité par mon précédent mentor et qui m’a demandé un peu de recherche pour arriver à mes fins (je voulais faire ma propre solution, comprendre et maitriser le sujet).

Bref, cela sera je le pense un petit billet avec du script, des schémas et naturellement du powershell avec une pointe de désinvolture et assurément de sécurité.

Avant-Propos

Comme rédigé légèrement plus tôt, je n’ai pas la volonté de faire un article détaillé qui reprend la majorité des articles déjà présent sur le NET. Il me faut néanmoins une base de départ.

Mon mentor, dans le cadre d’une esquisse de PSSI² il y a un certain nombre d’année c’est dit qu’il serait bien d’informer l’équipe du SI interne (ou externalisé) d’un potentiel blocage, verrouillage de compte sur un AD. La première question que nous pourrions nous poser serait d’abord quel cas pourrait entrainer un verrouillage d’un compte ?

• Un dysfonctionnement de la couche 8 du modèle OSI³ :
  • Je suis méchant avec cette couche, je sais bien. Nous parlons ici (ou plutôt je parle car cela n’engage que ma responsabilité ET ma personne) du dysfonctionnement entre le siège du bureau et le clavier. Soit en un mot et un seul ? L’utilisateur bien sûr !! Mais qu’est ce que ce mec est condescendant… C’est affligeant. Généralement, le verrouillage de compte est généré par une erreur de frape lors de la saisie et dans certains cas (compte non nominatif utilisé par plusieurs collaborateurs) de la saisie d’un mauvais mot de passe.
• Une tentative de Charlie qui veut « poutrer » le compte de Bob pour récupérer le cœur d’Alice
  • On comprend assez aisément le brute force d’un intru pour s’infiltrer dans le SI⁴ est tout casser…
• Un dysfonctionnement de la couche 7 du modèle OSI :
  • Oui celle-là existe officiellement et concerne la couche applicative :). Je ne peux pas non plus raconter des conneries en permanence tout de même. Pour faire simple une application a des informations qui ne sont pas à jour (un client de messagerie qui pete un plomb par exemple).

Donc l’intérêt de notifier l’équipe interne ? S’assurer que notre utilisateur ne veut pas s’octroyer une pause-café supplémentaire ou que nous avons un petit malin dans la place qui veut nous faire passer nos prochains jours à la première place de l’enfer dans le plus beau des pandémoniums <3

Mon côté brun ténébreux qui ressort avec les vilains corbeaux de Sir Alan Edgar Poe… Alors comment faire pour déceler un verrouillage de compte et comment notifier les équipes ? Spoiler ? La suite dans les parties ci-dessous.

Prérequis

• SE : 
  • Windows Server 2k16 et version ultérieures
• Apps : 
  • Rôle ADDS
• Autres :
  • PowerShell version 5 et supérieure
  • SMTP
  • Domaine AD

Théorie

Avant de commencer, posons nous la question de comment fonctionne l’authentification dans poste dans une domaine (pour faire simple, nous restons dans une forêt avec un seul domaine).

Authentification, comment ça marche ?

En tous lieux, je dirai avec des chaussures… Ok, je sors…

Nous pourrions résumer le cycle de vie de l’authentification en 7 étapes (encore la magie du nombre 7…) l’authentification d’un utilisateur.

1. Saisie des identifiants login et mot de passe
   • Rien de bien sorcier, CONTOSO\John.Doe et mon superpassword (si tenter que le mot de passe soit bien celui attendu dans l’AD pour l’utilisateur John DOE…
2. Localisation du DC via DNS
   • Notre poste va alors à travers l’enregistrement DNS⁵ _ldap._tcp.dc._msdcs.contoso.x pour trouver un DC⁶ disponible
3. Négociation, KERBEROS ou NTLM ?
   • Deux mots protocoles qui peuvent faire peur. Je ne rentre pas dans le détail des deux protocoles. Gardons à l’esprit toutefois que KERBEROS est supérieur au protocole NTLM⁷ (d’ailleurs KERBEROS est utilisé comme protocole par défaut).
   • Cas de KERBEROS, le poste demande un TGT⁸ auprès du KDC⁹ du DC à travers une requête. Si le couple d’authentification saisie est correct le KDC retournera en réponse le TGT chiffré ainsi qu’une clé de session. Le poste à travers le TGT va demander un TGS¹⁰ afin d’accéder aux différentes ressources du SI (fichiers, imprimantes etc…).
   • Cas de NTLM, le poste va réaliser un challenge au DC en attendant une réponse.
4. Validation du compte
   • Une fois la négociation réussi (Où est-ce qu’il a appris à négocier ?), le DC va vérifier le mot de passe haché, le compte doit être actif (soit pas verrouillé, expiré ou désactivé), récupérer les groupes de sécurité de l’utilisateur ainsi que les stratégies de connexion et de mot de passe.
   • C’est marrant, c’est cette étape qui nous intéresse 🙂
5. Chargement du profil
   • Si la vérification du compte utilisateur est ok, alors c’est réussi. HIGH FIVE ! Le poste va alors charger le profil local ou selon la configuration un profil itinérant. Dans le pire des cas, un profil temporaire.
6. Application des GPO
   • Dans la logique, ensuite sont téléchargées et appliquées les GPO¹¹ utilisateurs, ordinateurs…
7. Ouverture de session
   • Hé nous voilà normalement sur notre bureau.

Bon j’avoue que la partie négociation, j’avais dit que je ne rentrerai pas dans le détail. J’effleure la technicité et croyez moi, nous pourrions aller beaucoup plus loin. Toutefois, demander à vos Admins Systèmes et Réseaux ou Techniciens Systèmes et Réseaux, je ne suis pas certains qu’ils vous expliquent clairement le cycle de vie d’authentification d’un utilisateur…

Stratégie de mot de passe

Avant de rentrer plus dans le détail de ce qui nous intéresse, il est important de parler de la stratégie de mot de passe. Cela s’est plutôt bien démocratisé car nous retrouvons sur la grande majorité des sites web à ce jour le traditionnel message :

Votre mot de passe doit répondre aux critères minimaux ci-dessous :

• 16 caractères minimum
• 1 Majuscule
• 1 Minuscule
• 1 caractère numérique
• 1 caractère spécifique

Je vous vois déjà hurler, ou vos utilisateurs vous ont gueulé dessus… Quant à la politique mis en place. Mais alors que devons nous appliquer et à qui ? L’objectif est de sécuriser les SIs sans pour autant être un vrai tyran avec ces utilisateurs. Gardons toujours à l’esprit que « Trop de sécurité tue la sécurité ». A quoi bon exiger 26 caractères pour retrouver le mot de passe sur un post-it ou AZERTY123456AZERTY123456azerty123456azerty123456$…

Pour cela, j’aime me référer à l’ANSSI¹² comme ça je peux dire haut et fort, « C’est pas moi, c’est eux qui veulent. » 🙂 Je suis courageux n’est ce pas ? 🙂

Dans le guide de Recommandation relatives à l’authentification multi-facteurs et aux mots de passe, il est recommandé d’appliquer la politique de mot de passe suivante (R20):

• Catégorie des mots de passe
• Longueur des mots de passe (Entre 9 et 11, c’est faible. Entre 12 et 14 c’est moyen. Au-delà de 15 c’est fort)
• Règles de complexité des mots de passe (le nombre de caractère utilisable)
• Délais d’expiration des mots de passe (la fréquence de renouvellement)
• Mécanisme de limitation d’essais d’authentification
• Mécanisme de contrôle de la robustesse des mots de passe
• Méthode de conservation des mots de passe
• Méthode de recouvrement d’accès en cas de perte ou de vol des mots de passe
• Mise à disposition d’un coffre-fort de mot de passe

Dans notre cas, seuls les points en vert nous intéressent. Pour définir techniquement notre GPO ou notre FGPP.

D’où tu dis que je suis un FDP ?! Gros Tarba va ! Je vais….

STOP ! En aucun cas je vous insulte ! FGPP¹³ ou Fine Grained Password Policy permettent de manière plus simple de définir plusieurs politiques de mots de passe dans une organisation selon les services et criticité de ces derniers. Croyez-moi, c’est bien plus simple que la gestion par GPO. Ca nous le verrons rapidement dans la pratique quant au déploiement.

Dans tous les cas, j’aime définir la stratégie de mot de passe « par défaut » dans la GPO (vous pouvez me jeter des petits cailloux au visage et du sable dans les yeux), Default Domain Policy : HERESIE ! BLASPHEME ! AU BUCHET ! (Oui ba c’est bien la seule chose que je modifie dans la Default Domain Policy) :

J’ouvre un aparté, dans le cas d’un poste hors domaine que nous souhaiterions durcir, il suffira de faire de même. Il faut que je pose la question de scripter cela. Aparté fermée.

J’ai donc une politique de mots de passe qui s’appliquent (sans verrouillage de compte) par défaut pour l’ensemble des utilisateurs de mon parc, de mon domaine. Néanmoins, je vais définir par FGPP une politique par groupe utilisateur.

Dans ma logique, je choisie de faire trois politiques par défaut en respectant le tiering d’administration des comptes utilisateurs.

Administrateur du domaine > Utilisateurs avec pouvoir > Utilisateur du domaine

La puissance des FGPPs résident dans la possibilité de définir une pondération sur chaque politique. Ainsi, un utilisateur peut se retrouver avec une ou plusieurs politiques liées. Les politiques ne pouvant se cumuler, la politique avec la pondération la plus forte sera minoritaire par rapport à une politique avec une pondération plus faible.

« Unbelievable » diraient nos voisins outre-manche ! Nous retrouvons les mêmes paramètres que dans notre GPO… A noter et point important, la FGPP vaut sur la GPO si cette dernière est lié à un utilisateur ou un groupe d’utilisateur.

Authentification & events

Pour bien comprendre le fonctionnement de l’authentification, nous avons vu ci-haut que tout se passe sur nos DCs. Comme le système n’est pas trop mal foutu (et qu’accessoirement l’authentification à un système relève de la plus grande criticité) tout est consigné dans les journaux d’événements de sécurité.

Elle est pas belle la vie ?

Alors la question est la suivante, qu’elle est ou plutôt qu’elles sont les événements qui nous sont important ? Microsoft est vraiment sympa car ils ont pour nous référencier les événements à surveiller…

Mon cœur cogne un truc esthétique ! Vous voyez tout ce qu’il est possible de faire en termes de sécurité et de suivi, gestion du SI ? Limite ça me fait ba**er. Je vais soumettre l’ID d’un nouveau projet au comité qui vie dans ma cafetière.

Dans notre cas, précis il y a deux événements qui nous intéressent :

• 4624 : Hérité des événements 528 et 540, je cite « L’ouverture de session d’un compte s’est correctement déroulée. »
• 4740 : Hérité de l’événements 644, je cite « Un compte d’utilisateur a été verrouillé. »

Il est important de comprendre dans l’annexe que la notion de criticité est celle qui remonte dans les journaux d’événements. Personnellement certains événements pourraient être revu à la hausse. Enfin, c’est mon opinion personnelle qui n’a de crédit que pour le type qui écrit ces mots…

C’est donc dans le déclenchement de l’évent 4740 que nous trouverons notre bonheur.

Approche

La question est comment récupérer l’information que le compte d’un utilisateur ou compte de service est verrouillé ?

Consultation des objets

Dans un premier temps, j’ai pensé à scruter l’état de chaque objet utilisateur ou ordinateur de l’AD sur un intervalle définis dans le temps.

Le professeur rend les copies, et c’est un 4/20 qui tombe… L’idée peut paraitre bien, mais c’est mauvais. Oui je vais avoir l’information des comptes verrouillés, mais cela n’est pas du tout optimisé, cela va charger pour rien le serveur et générer des lenteurs et niveau proactivité c’est un zéro pointé. Imaginons si nous étions sur un SI avec genre 2k d’objets dans l’AD ?

Consultation des évènements déclenchés

La seconde approche consiste à définir une tache planifiée qui se déclenche sur un événement déclenché. Je l’ai fait il y a peu pour contourner un dysfonctionnement non patché de MS, donc c’est faisable. Mais je n’aime pas cette méthode car elle ouvre une vieille blessure intellectuelle… Ce traumatisme tout bête me dite vous ? Comment retourner et transmettre un paramètre de l’événement déclenché dans un script powershell…

Je peux vous dire qu’en 2015 je me suis torturé l’esprit à un point ou écouter du Evanescence en slip le soir de la Saint Valentin avec un kebab douteux et de l’alcool frelaté relève du plaisir (passe encore pour le kebab et l’alcool m’enfin).

Dix ans après, je rempile sur cette problématique et spoiler je trouve la solution. Comme quoi, un informaticien c’est comme un bon vin. Plus on le garde plus c’est bon. Enfin tout dépend de l’organisation. Oups pardon, je voulais dire la cave 🙂

Vous l’aurez compris ça sera la seconde méthode qui sera utilisé. Nous retournerons alors les attributs suivants :

• Le nom du compte qui lock
• Le nom de l’ordinateur, équipement source qui a cherché à s’authentifier
• Le nom de domaine

Là où j’ai merdé, ce que j’ai choisi de prendre en temps le temps de déclenchement du script et non le temps de lock de l’event. Ce qui du coup dans une configuration spécifique fausse complétement les informations. Donc il doit y avoir une adaptation de ma part sur la première version du code…

Sécurité

Nous sommes dans le domaine ? Nous allons réaliser une tâche planifiée ? Alors la réponse elle est vite répondu mon copaing ! Nous passerons par un compte de service managé, oui un gMSA¹⁴ comme d’habitude (et dire que je ne jugeais que par les comptes de services restreint avant…).

Les droits seront mis sur le script ainsi que l’ensemble des dépendances des utilisateurs externes. Sur le répertoire en somme ? Oui c’est ça…

Structure

S’agissant d’un petit projet, je me suis demandé si je devais ou non découper ce billet en différent sous article. Au final, je ne pense pas. Il y a eu plus indigeste que ça par le passé 🙂

Topographie – Applicative

Nous retrouvons donc l’architecture classique de mes projets précédents (Etonnant non ?) 🙂

A la racine du répertoire, nous retrouvons cette fois ci UN fichier exécutable (au lieu de DEUX) :

• SS_044_WIN_AD_LOCKACCOUNT_1.0.0_Services.ps1 : Fichier pensé pour fonctionner uniquement en mode service. Il ne peut être exécuté si et seulement si un event 4740 est levé. A voir si je fais un mode debug ou pas.

La suite se déroule en 3 répertoires distincts.

• Modules : Répertoire contenant les modules powershell développé pour l’application. Aujourd’hui au nombre de deux dissociant la partie Windows Système et HTML.
• Log : Répertoire qui va contenir la ou les traces d’exécution du code si l’option est activée. Cela à son importance car il permet au petit gars qui à dev l’application dans sa cave de corriger les bugs. Le fichier ne prend pas de place et est réinitialisé à chaque lancement.
• Config : Répertoire contenant le fichier de configuration powershell. Je reviendrai plus en détail sur le contenu de ce fichier dans la partie Pratique. Contrairement aux projets DreamNebula et GreenRay, je n’ai pas développé la fonction de reconstruction, régénération du fichier de configuration. Inutile car il n’y a pas de mode manuel et il n’y a pas grand-chose dans le fichier de conf…

Topographie – Logiciel

Je me passe par fénéantise la topographie du logiciel. Il n’est pas complexe du tout… Pour faire simple, cela se résume au cycle de vie suivant :

• 0 : Entrez dans le journal d’événement de sécurité d’un événement 4740.
• 1 : Déclenchement de la tâche planifiée sur l’événement. Récupération des informations liées au verrouillage du compte utilisateur, le poste source et le domaine d’application. Ces valeurs de type strings sont passés en argument du script powershell qui est exécuté SS_044_WIN_AD_LOCKACCOUNT_1.0.0_Services.ps1.
• 2 : Le script lit la configuration, puis charge les modules. Une fois les modules chargés, le corps du mail est construit et ce dernier est envoyé par mail. Naturellement et selon les options activées, le mode debug redirigeras l’ensemble des transactions powershell dans le fichier de log dans le répertoire du même nom.

Et le code ? Il est sur GitHub. Je ne souhaite pas le présenter. Toutefois, je partagerai volontiers ces derniers avec celui qui viendra m’en exprimer le souhait. Ca sera l’occasion de papoter un peu 🙂

Pratique

Configuration

Avant de lancer le script, il est nécessaire de faire un tour vers le fichier de configuration contenu dans le répertoire config à la racine du projet. Je vais prendre le temps de décrire chacune des parties de ce fichier.

Le fichier se découpe en 1 partie et 1 sous-partie.

* Une sous-partie globale qui définit les paramètres du script et de son fonctionnement * Une sous-partie concernant l’envoie de notification SMTP15, futur feature/bug (rayer la mention inutile) à venir

Avec la compréhension du fichier de configuration, je pense que nous pouvons passer à la suite, soit déployer l’application sur le serveur.

Installation

Je passe alégrement la partie gMSA il y a un certain nombre d’article sur le net (comme déjà dit dans des billets précédents) qui traite déjà du sujet. Pour le reste, j’ai comme d’habitude renforcé la sécurité et implémenté mes propres mécanismes (la preuve en est, j’ai passé deux put**n d’heures à trouver pourquoi ma tâche ne se lançait pas…).

Là où ça se corse, c’est au niveau de la tache planifiée. Si vous êtes sur un environnement possédant l’expérience utilisateur, vous êtes sauvés. En revanche, dans mon cas sur mes serveurs CORE, je l’ai mais alors bien profond dans la cucurbitacée… Voyez vous comme quoi une chose tout insignifiante soit il peut devenir un vrai casse-tête.

Mais alors qu’elle est cette petite chose insignifiante ?

The ScheduledTask

A première vue, vous vous demandez pourquoi je parle de la tache planifiée… Il s’avère que dans la version WINDOWS Core, nous ne pouvons pas créer de tache planifiée sur un déclenchement d’événement.

En réalité, nous pouvons constater également le dysfonctionnement sur un environnement WINDOWS avec expérience utilisateur. Il suffit d’utiliser la console powershell (il suffit de revenir aux bases du RTFM¹⁶).

Donc comment faire une tache planifiée, si :

• Nous n’avons pas d’interface graphique
• Les commandes powershell ne fonctionne pas
• Les moyens de contournement comme WAC¹⁷ ne fonctionne pas (normale co**ard c’est du powershell derrière)
• La console mmc.exe en remote pas plus de chance

J’ai essayé l’exécutable schtasks mais je ne suis pas arrivé à mes fins. Vous vous voulez la vérité ? J’ai lu qu’il fallait faire une fichier XML et ajouté les champs blablablabla… Je me suis dit « No Way » je vais encore me foirer dans une balise ou je vais avoir un problème d’encodage sur des caractères à la mord moi le noeud…

J’ai donc pensé à un autre moyen (tu as surtout épluché le net et les divers forum technet oui…). Pourquoi ne pas créer la tache sur mon poste avec des paramètres que je modifierai une fois importé ? Et bien ça voyez vous, ça fonctionne.

La création de la tâche ne pose pas de problème. Je joins toutefois la petite capture pour la configuration des critères de déclenchement de l’évent.

Une fois la tache créée, exportons là et ouvrons cette dernière dans un éditeur de texte.

Oh mais dit donc, ça ne serait pas ? Hé si le voilà notre fichier XML que l’on devait construire via la commande svctasks. Et dire qu’une tache planifiée ça ressemble à ça. Vous noterez que j’ai occulté deux parties. La première partie permet de récupérer les valeurs de l’événement. Il sera nécessaire de modifier manuellement le fichier XML. Mais je reviendrai plus en détails sur ce point dans la sous partie à venir (c’est ça ma frustration décennale !). La seconde partie permet de passer les variables que contiennent les valeurs récupérées ci haut en paramètre de notre script.

Bien. Maintenant importons la tâche 🙂

> $myTask = Get-Content "PATH_WHERE_XML_FILE\myTask.xml" | Out-String
> Register-ScheduledTask -XML $myTask -TaskName "PROD_EVENT_4740" -TaskPath "\_ronelab"

Récupérer les valeurs

Comme écrit plus haut, ce point va mettre fin à une frustration longue de 10 ans. Comment retourner les valeurs levées dans un event depuis l’exécution d’une tâche planifiée…

Là j’ai lu un nombre important de documentation pour comprendre comment cela fonctionne et comment mettre en œuvre la chose surtout. Toujours dans la démarche des 3S¹⁸.

Dans les approches :

• Quel est la structure, schéma du fichier XML d’une tache planifié : Lien
• Quel est la structure la plus adapté pour un eventTrigger de type complexe : Lien
• Un exemple d’implémentation : Lien

Avec la plus grande sincérité du monde, je n’avais pas il y a 10 ans de cela la maturité intellectuelle pour assimiler cette notion. Aujourd’hui je rougis de l’imbécile que je suis et de la simplicité et évidence de son mécanisme.

Maintenant que j’ai compris (mais que je n’ai pas expliqué 🙂 Il faut bien que vous vous investissiez aussi non ? Passons à la compréhension d’un événement. Il faudra sélectionner un évent 4740 et se rendre dans la vue Detail en Friendly, mais nous pouvons aussi se la jouer XML.

Nous notons deux catégories que nous pouvons déployer :

• System : Va contenir l’ensemble des balises et valeurs propres au déclenchement de la tâche avec les propriétés de l’évent. Comme dit plus tôt, l’un des attributs qui pourrait nous intéresser est le temps où l’évent a été inscrit dans le journal. Je prenais le temps de lancement du script, mais ce dernier n’est pas la bonne source de temps. Bref, il convient alors de noter le chemin de l’attribut qui nous intéresse :
  • Event/System/TimeCreated/@SystemTime

Il est important de noter que tout part de notre événement d’où le Event en début de path. Puis le chemin /System/TimeCreated/ jusqu’à la variable qui contient notre valeur spécifiée par le @ devant SystemTime

• EventData : Va contenir l’ensemble des balises et valeurs propres à l’évènement de sécurité déclenché. Ce qui nous intéresse ce sont les attributs TargetUserName qui contient le login utilisé et verrouillé, TargetDomainName qui contient le nom de poste cible où la connexion a tenté d’être initier et le SubjectDomainName qui contient le nom de domaine cible du compte verrouillé. Soit alors les les chemins suivants :
  • Event/EventData/Data/@[Name= »TargetDomainName »]
  • Event/EventData/Data/@[Name= »SubjectDomainName »]
  • Event/EventData/Data/@[Name= »TargetUserName »]

Alors comment intégrer proprement dans notre fichier XML correspondant à notre tache planifier nos 4 paths pour récupérer les valeurs ?

Normalement, nous avons eu toutes les informations ci-haut pour réaliser l’opération 🙂

Nous avons défini nos variables qui contiennent nos données. Il suffit alors de passer nos variables en arguments de notre script. Je passe une nouvelle fois mon tour. Le passage de variable en arguments d’un script powershell c’est un basique. La modification peut être réalisé en graphique dans le TaskScheduler ou directement dans le fichier XML.

Maintenant, il ne reste plus qu’à réimporter la tache de nouveau puis de réaliser un test.

Reporting

Pour le test, rien de plus facile… J’ai choisie d’initier une connexion à l’une des ressources des domaines à partir d’un compte pour lequel la FGPP est active : * RONEALB\erwan.guillemard Depuis une instance de bureau à distance, je décide de mettre en application ma plus belle couche 8 en saisissant 5 fois mon mot de passe de manière erroné. Windows m’informe que mon compte a été verrouillé à la suite de plusieurs tentatives d’authentifications infructueuses. Quelques minutes après, je reçois le mail ci-contre.

En regardant en détail, j’ai bien les informations qui m’informe que le compte erwan.guillemard a été verrouillé à la suite d’une plusieurs tentatives de connexions depuis la machine EGWKS-RDB01 le 26/09/2025 à 20:31:40 sur le domaine RONELAB.

Toutefois et si je regarde avec précision le déclenchement de la tâche, j’ai 7 minutes de retard dans le temps affiché dans mon mail et la date d’entrée dans le journal de sécurité. Ce retard s’explique par une mauvaise prise en compte de la valeur DateTime. Je pensais que la valeur Datetime du script serait définis lors du lancement du script à la détection de l’événement. Cependant, mon SI étant très ancien, la tache met une bonne dizaine de minutes (en grossissant le trait) à se lancer. Ainsi je génère un delta ce qui n’est pas super en termes de sécurité. Il faudrait donc que je récupère la valeur DateTime présente dans l’événement.

Conclusion

Je suis content d’avoir réinventé mon propre système de notification sur le verrouillage d’un compte utilisateur dans un domaine à partir de la problématique qu’avait il y a maintenant plusieurs années un ancien collègue. Ainsi, j’ai pu combler une problématique vieille de 10 ans en relation avec les événements et les taches planifiées (dans mon projet de mémoire sur la supervision Shinken).

J’ai également constaté que les modules développés dans les projets précédents m’ont fait gagner un temps monstrueux. Cela me permet donc de me dire et de m’auto-confirmer que premièrement je ne fais pas que de la merde, secondement qu’à partir de maintenant je vais prendre un chemin différent quant à l’ensemble des problématiques qui nécessite un dev en powershell.

Le plus difficile restera je le pense de toujours garder une vision claire et qui réponde au 3S.

Si je devais être efficient, je reprendrais mes bouts de code existant concernant la création de ticket dans la solution ITSM de COMBODO (ITOP) pour générer un ticket en criticité haute pour le verrouillage d’un compte. De cette manière, le centre de service ou les équipes locales (internalisées ou externalisées) pourraient être proactives quant à tous comportements succès en relation avec l’authentification et l’accès à des ressources. Ce qui pourrait alors se résumer selon notre bon vieux William Shakespear par « Le plaisir d’un travail en guérit la peine ».

J’ai encore une fois repris une idée. Je pense qu’il serait temps que je reprenne un peu de temps pour innover. Certes, comprendre et mettre en pratique les idées de mes paires et une bonne chose mais je pense qu’il est souhaitable de vivre pleinement une nouvelle fois cette satisfaction personnelle. Mon ultime rature se limitera à « Est ce que cela valait ce billet ?« .

Je vous laisse jugez de tout ça et prendre contact si vous voulez le bout de code 🙂

Le mot de la fin :

Vous êtes surqualifié pour le poste ? Que neni, j’aime les salsifis et je sens vaguement le chou. Je vous embauche et Toper Harley reste dans la boucle. Merci, j’ai les films de programmateurs.

Erwan GUILLEMARD

Sources

• ANSSI : Guide d’authentification multi facteur et mots de passe
• WINDOWS : Authentification & Identification
• WINDOWS : Evénements à surveiller
• WINDOWS : Type Complexe EventType
• WINDOWS : KERBEROS
• WINDOWS : Svctasks
• WINDOWS : New-ScheduledTask
• WINDOWS : Register-ScheduledTask
• WINDOWS : Event & Queries

1. AD : Active Directory ↩︎
2. PSSI : Politique de Sécurité des Systèmes d’Informations ↩︎
3. OSI : Open Systems Interconnection ↩︎
4. SI : Système d’Informations ↩︎
5. DNS : Domain Name Service ↩︎
6. DC : Domain Controller ↩︎
7. NTLM : NT Lan Manager ↩︎
8. TGT : Ticket Granting Ticket ↩︎
9. KDC : Key Distribution Center ↩︎
10. TGS : Ticket Granting Server ↩︎
11. GPO : Group Policy Object ↩︎
12. ANSSI : Agence Nationale de Sécurité des Systèmes Informatiques ↩︎
13. FGPP : Fine Grained Password Policy ↩︎
14. gMSA : Group Managed Service Account ↩︎
15. SMTP : Simple Mail Transfert Protocol ↩︎
16. RTFM : Read The F*cking Manual ↩︎
17. WAC : Windows Admin Center ↩︎
18. 3S : Simple, Standard, Sécurisé ↩︎

Logique dans un sens puisque le certificat auto-généré par ce même équipement ne peut-être juge est parti. Le certificat doit être demandé par l’équipement à une autorité certifiant que c’est bien lui.

M’enfin comme le dirai notre bon vieux LAGAFFE, j’ai défait fait un billet dans ce sens et je ne vais donc pas user de la combinaison Ctrl+C, Ctrl+V. Et gardons à l’esprit jeune damoiseau (plus encore pour longtemps) les bonnes résolutions de rédaction de cette année 2025.

Nous voilà en route pour aborder le sujet des certificats d’infrastructure à clé publique (PKI¹) dans un environnement windows avec domaine pour renforcer la sécurité de nos SIs², ménager nos WebBrowser quant à l’affichage de ce type d’avertissement.

Et surtout, préparons nous à nous arracher les cheveux par moment.

Mais alors pourquoi faire de nouveau un article sur ce sujet si tu as déjà couvert ce même sujet ? Difficile de tester et de traiter de certain sujet sans avoir de serveur PKI. Implémenter des fonctionnalités c’est bien. Les sécuriser c’est mieux.

Cet article permettra par la suite de pouvoir traiter de sujet comme (et ce n’est qu’un exemple) :

• WinRM Over HTTPS
• SMB OverQuick
• Applications en HTTPS
• etc

Une autre raison, reste d’avoir de maintenir un niveau technique cohérent avec mon cercle professionnel et non pas rester sur le banc de touche. Si la théorie est acquise, la pratique ne l’est pas, du moins ne l’était pas avant la rédaction de ce papier.

Prérequis

• SE : Windows Server 2k19 et version ultérieures
• Apps : N/A
• Autres :
  • Domaine AD
  • Applications supportant TLS/SSL

Avant Propos

Avant de rentrer dans le vif du sujet et d’aborder ce qui est propre Windows, je pense utile de faire un rappel des bases de la cryptographie moderne aussi loin qu’il m’est possible de me remémorer mes cours de cryptographie.

Sinon à quoi bon aborder le sujet de certificat sans en piper le moindre mot ? Et croyez moi, je fume bien la pipe….

Déjà, le pourquoi de chiffrer une information ? Pour cela nous devons faire appel à CAIN.

Rien à voir avec Abdel se faisant tuer par Cain premier meurtrier, mais il me faisait plaisir de partager l’œuvre de Sebastiano RICCI que je trouve magnifique (la confiture c’est comme la culture, moins on en a plus on l’étale). Plus sérieusement : C : Confidentialité des informations stockées ou manipulées A : Authentification des protagonistes lors des des communications I : Intégrité des informations stockées ou manipulées N : Non-Répudiation des informations

En complément du premier principe fondamental, j’enchainerai avec un second qui est précieux pour mon petit cœur, le principe de Kerckhoffs.

• La sécurité repose sur la clé de chiffrement et non sur le secret de l’algorithme
• Le déchiffrement d’un contenu chiffré doit être impossible dans un temps raisonnable
• Déterminer la clé à partir du contenu en clair et du contenu chiffré doit être impossible dans un temps raisonnable

Soit, toute attaque doit être envisagée en supposant que l’attaquant connait tous les détails du cryptosystème.

Je pense qu’avec ces deux principes, nous pouvons faire un grand pas en avant et plonger dans le monde de la cryptographie moderne. [Je ne suis pas un spécialiste de la question, je laisse à mes pères le droit de me sabrer sur le sujet.]

La cryptographie moderne tourne autour du chiffrement asymétrique et de plusieurs algorithmes. Tout est régis dans notre bas monde par ces algorithmes et la capacité et puissance des nombres premiers. Toutefois l’émergence de la technologie quantique et de l’age d’or de l’IA³ va remettre assez rapidement en cause ce paradigme.

L’un des derniers en date. Cela fait froid dans le dos hein ?

Bref, parlons peu mais parlons bien. Qu’est que le chiffrement asymétrique ?

Le chiffrement asymétrique consiste à la génération d’une clé dite privée et d’une clé publique. A travers de fonction unique, il n’est pas possible de déchiffrer un message chiffré par la même clé.

Ainsi, la clé privée est l’élément sensible et doit rester connu que de la source et non de la cible. Seule la clé publique et communiqué. Ainsi, prenons le cas d’un échange entre Alice et Bob (sacré Robert et Alice, toujours là depuis des décennies à s’envoyer des messages sans jamais arriver à conclure ou pécho pour les millénials… Tout ça car Charlie veut pécho Alice ou Bob. C’est un peu l’Antigone 3.0 de notre temps… Je laisse à Jean Anouilh la version 2.0).

Ainsi, si nous regardons un échange entre Alice et Bob sans inclure Charlie :

Alice étant folle amoureuse de Bob, elle a communiqué sa clé publique (mais pas à Charlie) mais garde sa clé publique. Si Alice veut écrire un message à Bob (1), elle va chiffrer son message avec sa clé publique et déposer son fichier dans le grand tuyau qu’est l’internet. Charlie qui est caché derrière son écran et qui veut de la thune (et pas que) ne voit passé qu’un message incompréhensible car il n’a pas la clé publique d’Alice. Bob, lui reçoit le message chiffré, qu’il pourra déchiffrer grâce à la clé publique qu’Alice lui a transmis. Mais voilà (2), Bob est un peu beauf et ne comprend pas l’amour que lui porte Alice et lui répond qu’il aime les moules frites et les soirées tunnings. Il chiffre sa réponse avec la clé publique et la retourne à Alice. Charlie, lui aime le tunning mais il ne pourra jamais déchiffrer à temps le message… Alice reçoit la réponse de Bob, est malgré la clé privée ne devrait pas déchiffrer le message de Bob.

Mais à l’inverse, si nous admettons qu’Alice échange également avec Charlie (donc que Charlie possède la clé publique d’Alice), Charlie peut pas échanger des menaces de morts à Bob de manière sécurisé MAIS Bob ne sera pas dans la capacité de déchiffrer le message de Charlie. Bob, petit conseil d’ami, compose le numéro de police secours, j’dis ça, j’dis rien.

Bref, Alice finira dans sa baignoire à écouter « Avril Lavigne » (a prononcer avec l’accent) avant d’être de nouveau figurante dans un schéma d’explication d’un échange cryptographique.

Nous avons donc l’idée du fonctionnement. Et bien les certificats c’est presque pareil dans le fonctionnement, mais en complément nous allons retrouver des informations permettant d’identifier le fournisseur, la source. Afin de garantir la sécurité, une durée de vie est définie dans le temps. Ce dernier devra être regénéré. Les certificats sont uniques et intrinsèques à une entreprise, une personne.

J’espère donc avec cette courte introduction ne pas avoir dit d’ânerie. C’est que 2013 ce n’est plus si proche que ça. Sinon, je corrigerai ou supprimerai l’article. J’assumerai l’entière responsabilité de cet échec en me retirant définitivement de la cryptographie… Non, je retournerai en khôls sur les bancs de la fac (#IUTdeLens #StadeBollaert #RinceCochon #Frites).

Théorie

Je pense que nous sommes assez armés pour aborder la suite. Comment construire et définir correctement son architecture PKI dans son SI.

La première vraie question est qu’est ce que je souhaite implémenter et comment je souhaite gérer les inscriptions et demande de certificat ?

C’est à cette question que nous allons tâcher de répondre.

Architecture & Best Pratices

La documentation Microsoft est pour le coup pas mal gaulé. Et deux architectures sont proposées. Bien que l’une convienne plus à une autre en termes de sécurité, il est important de définir le temps et la complexité à passer par l’équipe en place pour administrer la solution.

Sortir une architecture autonome pour 4 serveurs, utilisé par 30 personnes et administré par 1 seul SysAdmin c’est un peu surdimensionné. Oui c’est une bonne pratique mais quand même. Alors qu’une architecture d’entreprise serait plus appropriée.

Oh Pt’ain le con il a lâché les deux types d’infrastructures comme ça ! T’es un précoce de la vie non ?

T’inquiète, j’ai encore une balle dans la chambre lapin.

Peu importe le type d’architecture, nous devons considérer qu’un serveur ADCS⁴ (ou avec les rôles PKIs) est critique pour l’organisation du SI. Donc il passe directement en case T0 du modèle de tiering.

Ainsi, il est primordial que ce serveur ADCS ne soient pas accessible de n’importe qui et de n’importe où. Si ce dernier se fait compromettre, c’est l’ensemble de notre SI qui sera hors service. Vous pouvez toujours dire ce n’est pas moi et aller pointer au France Travail. Blague à part, notre serveur va nous servir à délivrer les certificats de notre SI. Le serveur certifiera ces derniers comme valider par lui, autorité de confiance. Or, ce même serveur s’appuie sur ADDS5. Donc, nous n’avons pas à exposer ce dernier (mais je reviendrai sur ce point car il y a des exceptions).

Le modèle ci-dessus représente clairement l’architecture d’autorité d’entreprise. Cette architecture convient au petit système d’information et donc au PME⁶. Il convient donc de joindre le serveur ADCS à notre domaine. Notre serveur d’autorité de certification sera donc disponible et validera les demandes d’inscriptions ains que les différents modèles. Le problème réside dans la sécurité de ce dernier. Si nous voulons nous assurer que notre autorité de certification racine ne soit pas compromis, il serait bien de la rendre inaccessible. Microsoft, recommande clairement d’éteindre ce dernier. Toutefois, ce n’est pas possible car ce dernier est unique et en plus joint au domaine…

C’est ainsi que rentre en jeu l’architecture d’autorité autonome. Comme son nom l’indique, cette architecture est indépendante de notre domaine, mais nécessite un serveur dit d’autorité secondaire ou d’autorité intermédiaire. Ce qui concrètement nous donne le modèle suivant de tiering.

Nous déployons hors domaine dans une bulle à part notre serveur d’autorité de certification racine. Nous définissons notre certificat racine. Dans notre bulle T0, nous allons créer un nouveau serveur dit d’autorité intermédiaire ou secondaire. Ce dernier va avoir un certificat que va être certifié par l’autorité racine. Ainsi, ce dernier aura dérogation pour délivrer les certificats et les inscriptions sur notre SI. Dérogation et délégation oui, mais pas les pleins pouvoirs. C’est là que ça devient fun. Niveau sécurité, il ne reste plus qu’à éteindre notre serveur d’autorité racine. Il n’est pas au domaine donc qu’est qu’on en a à fo***re ? Si nous en avons besoin, nous le remettrons sous tension et pas de risque de tombstone.

Nous pouvons descendre d’un niveau hiérarchique supplémentaire en parlant d’une autorité de certification émettrice. Mais je n’irai pas jusqu’à ce niveau là d’architecture. Dans le cas commun des entreprises, un niveau de hiérarchie voir deux sont suffisantes.

• Niveau 1 : Autorité de Certification Racine
  • Niveau 2 : Autorité de Certification Secondaire/Intermédiare (ou de Stratégie)
    • Niveau 3 : Autorité de Certification émettrice

Dans les architectures les plus complexes il est également possible de réaliser des approbation inter-certificat, comme nous pourrions le faire avec une relation d’approbation inter-domaine. Mais je n’ai jamais vu, ni même penser cela possible jusqu’à ce que je mette ma truffe dans la documentation. Je vais déposer les armes devant cette architecture car je ne pense pas que cela soit monnaie courante (quoi que…). Joker, je fais appel à mon droit de véto pour cette fois.

Bien, mais alors vu que le serveur qui porte les rôles d’autorité de certification racine n’est pas au domaine, les fonctionnalités et services proposés ne peuvent être les mêmes qu’une autorité de certification d’entreprise ? Tout juste.

Clairement, je ne vais pas me faire ch**r et vais donc reprendre le tableau de Microsoft. J’ai une flemme de montrer ma maitrise en paraphrase.

Concernant la méthode d’inscription, ou plutôt les méthodes d’inscriptions il est nécessaire de considérer le besoin. Personnellement, je réalise l’ensemble des demandes si ce n’est la totalité manuellement. L’inscription via les services WEB (à travers IIS⁷) est compromise depuis la découverte de PetitPotam et bien qu’un KB⁸ soit disponible pour renforcer la sécurité cela représente un risque trop certains (et surtout, j’ai jamais été foutu de le faire fonctionner avec mon serveur core. L’arroseur arrosé en somme 🙂 ).

Bien, je pense que niveau théorie, la boucle est bouclée. Si besoin je reviendrai dessus mais entre deux poses déjeuner et le travail nocturne (si je peux nommer ça travail) j’ai la fâcheuse tendance à perdre le fil. 🙂 Enfin bon, place à la pratique.

Pratique

Pour répondre à la partie théorique, je resterai sur une inscription manuelle ainsi que dans de rare cas un inscription des postes. Naturellement et comme souligné plusieurs fois, je déploierait une architecture type autorité de certification d’entreprise à un niveau de hiérarchie.

Okay, let’s go…

Installation

Pour cette partie je veux réaliser deux approches, l’approche sur un serveur classique soit avec l’expérience utilisation et sur un serveur core (bye bye la GUI⁹). A la liberté de chacun de choisir son type d’installation.

Or je me permets de citer (après je dis ça je dis rien hein ?).

Un autre point à prendre en compte est le type d’installation du système d’exploitation. L’Expérience utilisateur et les scénarios d’installation Server Core prennent en charge AD CS. Server Core minimise la surface potentielle du pirate et la surcharge de maintenance du système d’exploitation, ce qui en fait le choix optimal pour AD CS dans un environnement d’entreprise.

Un rédacteur chez MS

Comme indiqué précédemment, mon serveur de certification racine sera joint au domaine par manque de ressource, naturellement si les ressources étaient présentes, j’aurais déployé une architecture Intermédiaire avec le serveur CA¹⁰ hors domaine.

Je considère donc que l’environnement est à jour et préalablement durci.

GUI

1 – Add me if you can

Les actions se passent comme d’accoutumé via le gestionnaire de serveur en ajoutant un rôle. Nous devons choisir le rôle Services de certificats Active Directory.

2 – Fonctionnalités

Facultatif, mais utile de mon point de vue, l’installation des outils d’administrations distant pour administrer le service de certificat AD¹¹.

3 – Wizard

Une petite explication de ce que nous allons installer. Naturellement et comme 99% de la population nous cliquerons sur Suivant comme pour les conditions générales d’utilisations et autres droits d’usage. (Sauf qu’ici nous ne vendrons pas nos données et notre c*l ne sera pas considéré comme une base de loisir).

4 – Sélection du rôle

Enfin, cela devient intéressant. Dans le déploiement de notre rôle nous avons la possibilité d’ajouter des services supplémentaires. Dans mon cas, je n’utiliserai que la partie Autorité de certification mais il est possible d’ajouter d’autres services plus particulièrement des services d’inscription pour faciliter les demandes de création et d’inscriptions.

Toutefois et attention, certains services ouvrent des angles de vulnérabilités de par la criticité de notre serveur et surtout de ces rôles. De plus les services web ont été challengé il y a peu par PetitPotam (2022 c’était bien hier non ? Azy t’abuse gros…). Donc la prudence est de mise, pour plus d’information sur le sujet, je vous renvoie vers le KB MS traitant de la CVE¹².

(Pour le coup, je me suis bien fait fi*t* la gueule en CORE car je n’ai aucune souplesse en IIS avec mon powershell. Tiens Monsieur JDO, vous marquez un point pour le coup 🙂 ).

5 – Confirmation du déploiement

Comme chez le notaire, nous acceptons le redémarrage automatique, et nous validons les émoluments compensatoires (Merci Didier !).

6 – Installation en cours, Coffee break

L’installation se débute, se poursuit et normalement se termine par un succès. Voilà, notre rôle ajouté. Elle est pas belle la vie ?

CORE

Comme toujours (pour ne pas dire enGORE et enGORE, je vous la sorts bonne hein ! Vous l’avez SORBONNE #TESLOURD), l’installation du rôle sur un serveur core et de loin plus facile et efficace que via l’interface graphique…

Jugeons plutôt.

Et puis voilà… L’inconvénient encore une fois, c’est qu’en cas de dysfonctionnement il faudra être agile du powershell et de la ligne de commande pour se sortir de la merde. Pas question de compter sur ce bon Samsagace GAMEGIE face à SHELOB…

Configuration

Si l’installation du rôle est plutôt simple, la configuration nécessite un tantinet plus de réflexion. Naturellement, j’aborde les deux méthodes de déploiement de notre rôles ADCS pour un environnement GUI et CORE.

Important, pour la base de données et les journaux d’événement, nous stockerons ces derniers sur un volume dédié indépendamment du volume système (C:\). La raison me semble évidente et je ne m’attarderai pas sur ce point.

GUI

1 – On montre patte blanche

Les opérations pour configurer le rôle nécessite un compte Administrateur local et Administrateur d’entreprise.

Deux approches possibles :

• Rien à fo***e du principe de tiering et de moindre privilège : J’utilise le compte administrateur du domaine. Ce dernier ayant tous les droits nécessaires. Perso, c’est pas ma philosophie, mais chacun voit midi à sa porte.
• Je suis consciencieux de la sécurité : Je crée un compte dans mon domaine membre du groupe Administrateur d’Entreprise et membre du Groupe Local d’administration de notre serveur. Je désactiverai par la suite ce compte.

Tout le monde sait que je défendrai bec et ongles le premier point 🙂

2 – Choix du service à configurer

Quel rôle souhaitons nous configurer ? Sans grande surprise, vu que nous n’avons installer que le service d’Autorité de certification… La question est vite répondue.

3 – Type d’installation, croisé des chemins

Je parle de croisé des chemins car selon moi il y a ici un choix crucial. Le choix entre plus de sécurité mais plus de contrainte et un choix plus standard.

J’ai écrit un peu plus tôt que pour des raisons de ressources mon serveur serait joint au domaine. Cela rentre donc dans le choix Autorité de certification d’entreprise.

Dans le cas contraire où, nous aurions pris le parti de ne pas joindre notre serveur d’autorité de certification ce dernier aurait été autonome et nous devrions déployer un serveur de certification intermédiaire.

J’essaierai de maquetter cette architecture. Reste néanmoins à trouver quel serveur je dois sacrifier sur l’autel de la connaissance. (Le type qui se la joue clerc au XVI).

4 – Génération de la clé privée

La génération de la clé privée est une étape importante de la configuration. Aux prémices de cette dernière, nous avons le choix de générer un nouvelle clé ou d’importer une clé existante.

Le second choix étant généralement dans le cadre d’une réinstallation ou d’une migration.

5 – Chiffrement

Le chiffrement ce n’est pas compliqué (bien que si en réalité). Nous gardons Windows comme générateur et fournisseur de notre chiffrement.

Plus c’est long, plus c’est bon… Je parle de la longueur de la clé de chiffrement naturellement. Je vous vois venir avec votre œil lubrique. Concernant l’algorithme de hachage, le plus complexe proposé donc SHA512¹³.

Je dis donc complexe car il est nécessaire de prendre en compte des applications ou OS¹⁴ obsolètes (ou ayant des dépendances obsolètes), qui ne prennent malheureusement pas en charge certaines longueurs de clé ou d’algorithme. Un petit renseignement est nécessaire en amont. Dans le doute et cela passe quasiment tout le temps SHA256/2048 en paramètre de chiffrement.

6 – Nom de l’Autorité de Certification

Le nom va permettre non seulement d’identifier rapidement notre certificat mais également de garantir sa singularité.

Ici mon certificat d’autorité portera le nom ronelab-CA-Root et couvrira le suffixe de mon domaine soit ronelab.lan, d’où DC=ronelab,DC=lan.

7 – Durée de vie

La durée de vie de mon autorité racine… Plus c’est grand dans le temps moins c’est bien. A l’inverse de la durée de vie d’un être vivant. Cherchez l’erreur… Toutefois et comme spécifié, la durée de vie de notre AC doit être supérieur à la durée de vie des certificats qui seront délivrés (logique).

Ici, je ne vais pas mentir en disant que je ne veux pas trop m’emmerder avec une échéance trop courte. Je n’ai jamais en toute franchise été confronté aux cas où le CA d’entreprise a expiré. Faudra tester…

8 – BDD et Journaux

Depuis les prémices de mes études dans l’IT, il m’a toujours été dit que ce qui doit être sur la partition système va sur le système, ce qui peut être déplacé vers un disque dédié ou partition doit être réalisé. C’est le cas ici.

9 – Récap

Comme d’habitude avec le wizard de configuration nous avons un récapitulatif de la configuration qui va être mis en place.

Le rôle est maintenant configuré. Reste plus qu’à faire un petit check up avant de se lancer dans la génération de certificat et de modèle.

CORE

En core, c’est plus simple. Pour mieux comprendre l’unicité de l’étape de configuration, il faudrait repartir de la partie 9-Récap précédente.

Le plus compliqué reste selon moi, de trouver quel argument appelé et quelle valeur lui définir.

Je glisse le lien dans les sources.

Nous retrouvons également les mêmes informations que ce qui a été présenté précédemment dans la partie GUI. Je ne passerai donc pas plus de temps sur ce sujet.

Le rôle est maintenant configuré. Reste plus qu’à faire un petit check up avant de se lancer dans la génération de certificat et de modèle.

Contrôles

L’une des premières questions que nous pouvons nous poser, est ce que notre certificat d’autorité est bien présent ?

Mon serveur étant en CORE, je vais donc à travers mon rebond d’administration user des RSAT¹⁵s lié au certificat ou à travers une console MMC¹⁶ :

• Autorité de certification
• Modèle de certificats

Ce qui est bon signe, nous constatons que notre serveur apparait en ligne et fonctionnel. Mais vérifions plus loin que ce dernier est bien présent sur notre domaine. Logique car nous avons déployé une autorité de certification d’entreprise.

Pour ce contrôle là, il est nécessaire de passer par la console ADSI¹⁷. Personnellement je ne suis jamais à l’aise dans cette console de gestion et je pense ne jamais l’être. La gymnastique d’esprit est différente de ce que nous pouvons entreprendre opérationnellement au quotidien dans la console de gestion des utilisateurs et ordinateurs AD. Bref, la navigation dans le gestionnaire ADSI se résume dans la navigation par « Qu’est ce que je recherche dans la configuration ? »

Donc nous pouvons conclure que de ce côté, je ne me suis pas iech dessus niveau configuration. Ce qui me semble une bonne chose.

Nous sommes en droit de nous poser la question, « Comment je vais pouvoir accéder à des ressources sécurisées si je n’ai pas le certificat d’autorité racine sur mon poste ? » Si le poste est au domaine (et sauf cas spécifique il l’est), ce dernier étant dans l’AD, le certificat est automatiquement ajouté comme Certificat de certification racines de confiance.

Nous pouvons double tap pour afficher les propriétés et caractéristiques de notre certificat.

Là nous sommes certains qu’il n’y a pas de loup dans le déploiement de notre service et de sa configuration. Nous pouvons donc nous pencher sur la partie Modèle de certificat.

Modèles

Lorsque nous avons déployé notre rôle, un certain nombre de modèle ont été déployé dans l’AD pour couvrir le cas échéant le domaine d’application nécessaire à la sécurisation des différents services (Ordinateur, Exchange, Serveur WEB, Utilisateurs, etc).

Ces différents modèles peuvent être utilisés pour générer nos certificats. Toutefois, il est d’usage et recommandé de dupliquer ces modèles pour les services que nous souhaitons protéger. Cela nous permet de faciliter la gestion et de garantir un niveau de sécurité en ne se basant pas sur les propriétés et paramètres par défaut des modèles.

Moi pas comprendre…

En gros, si je duplique mes modèles (qui ont les mêmes propriétés du SI de M. TUCHMUCHE) et que je custom les attributs par rôle ou service que je veux procéder, en cas de vulnérabilité, je limite mon exposition. De même que si mon SI est vulnérable par l’un de ces services, il sera plus facile de limiter le périmètre d’exposition et donc en conséquence le risque qu’il en découle.

Dupliquons un modèle pour comprendre les tenants et aboutissants des paramètres.

1 – Compatibility Tab

Lors de la duplication du modèle, le premier onglet portera sur la compatibilité de notre certificat. Personnellement et bien sûr c’est intrinsèque. Qui peut le plus ne peut pas forcément le moins.

Mon cas, avec mon lab en WS 2k22 et WS 2k25 (je crois avoir un WS 2k19 mais surement perdu quelque part) je partirai sur le niveau de compatibilité le plus haut. Mais encore une fois tout s’étudie.

J’aime à afficher les modifications résultantes pour prendre pleinement connaissance des modifications qui vont être apportés sur mon nouveau modèle. Cela peut permettre d’identifier clairement une dépendance que nous aurions omis de prendre en compte dans notre analyse. Bord*l de Dieu, il faut être curieux ! <3

2 – General Tab, Name & EOL

L’onglet Général permettra d’attribuer un nom à notre modèle ainsi que la période de validité de notre modèle. Attention il en va de soi la durée de validité doit être inférieur strict à la durée de notre certificat d’autorité racine.

Logique mon père ne peux pas être plus âgé que mon grand père. Quoi que dans certaines régions…. Alalala, les préjugés ont la vie dure…

La notion de publication dans l’Active Directory dépendra clairement du type de modèle que nous souhaitons implémenter. Pour une application WEB non Windows et non jointe au domaine, pas besoin par exemple.

3 – Subject Name

Le nom du sujet, comprendre le client. Il convient de définir les informations lorsqu’une demande est réalisée. Je n’ai pas eu à ce moment eu le besoin de modifier la valeur par défaut. En d’autres termes, Joker ?

4 – Extension

Les extensions c’est plutôt un onglet intéressant. C’est dans cette partie que nous allons pouvoir définir les stratégies d’applications, les contraintes liées à notre modèle, les stratégies d’émissions et d’utilisation de la clé. Pour plus d’informations et bien choisir l’action ou non de telles ou telles options je renvoie à la page de caractéristiques des extensions standards x509.

Soit dans le cas de la stratégie de définir dans quel contexte le certificat va être utilisé. L’authentification Serveur ? Client ? Pour du RDP¹⁸ ? Une liste est déjà présente et nous pouvons ajouter au besoin de nouvelle stratégies d’application avec des codes définit par Microsoft (ce qui sera le cas plus bas avec la sécurisation de RDP).

Les contraintes sont là pour définir les usages qui doivent être fait des clés. Pour se faire, comme dit précédemment il faut se rapprocher de la documentation sur les certificats x509. Dans le cas des contraintes, nous pouvons refuser que la clé publique valide les empreintes par exemple.

5 – Security

L’onglet que l’on retrouve sans grande surprise dans beaucoup de menu de configuration. Il est important de définir les droits et les permissions avec réflexion. Les options les plus critiques restent naturellement l’écriture et le control total. Attention également aux permissions d’inscription et d’inscription automatique.

6 – Publish a template

Une fois le modèle de certificat dupliquer, il sera nécessaire d’activer ce dernier afin de l’utiliser.

Par sécurité, il est recommandé une fois le ou les certificats générés de désactiver, désinscrire les modèles de certificats du gestionnaire de certificat. Ainsi, il sera difficile pour un assaillant de générer un certificat depuis un modèle.

Exemple d’implémentation

Il existe une multitude d’implémentation. Je ne traiterai ici que deux exemples, l’un hors domaine et sur un SE non Windows et l’autre dans un environnement windows.

Toutefois, je pense pour ne pas faire un article à rallonge aborder l’implémentation des certificats dans les articles dédiés.

De plus, il y a plusieurs moyens d’effectuer une demande d’inscription de certificat.

• Fournit par l’appliance ou application
• Via IIS
• Via le gestionnaire de certificat

Dans l’ensemble des cas, nous partirons toujours d’un fichier CSR¹⁹ (ou REQ²⁰ je ne suis pas obtus) afin de générer notre CRT²¹.

VMWare : VCSA

1 – Génération du fichier CSR

Sur notre appliance VCSA²², à partir du menu il faut se rendre dans le menu d’administration partie Certificat. Pour le reste, il suffira de suivre les captures ci-dessous pour générer notre CSR.

Renseigner les informations d’authentification, puis valider.

2 – Inscription et génération du fichier CRT

Sur notre serveur ADCS, il est nécessaire d’exécuter la commande suivante :

> certreq.exe -submit -attrib "CertificateTemplate:WebServer" "‪C:\monFichier.csr"

L’inscription en GUI à travers les RSATs ne semble pas fonctionner chez moi sans retourner au préalable une erreur relatif au modèle. Un collègue m’a donné cette astuce. Je trouve d’ailleurs logique au vu de ma radinerie d’utiliser une commande powershell sur mon serveur CORE !

Commande Powershell tu es certain de toi ? Tu paries combien ?

Effectivement il s’agit bien là d’une commande cmd. Et ayant poussé le vice plus loin, cette commande ne fonctionnera pas si vous êtes :

• Authentifié sur le serveur avec un compte local
• Via une session PowerShell distante à travers WAC²³
• Via une session PowerShell distante

Une petite interface graphique est appelé vous demandant de sélectionner une autorité de certification… Seule solution, réaliser l’opération directement en powershell à travers la console VMWare.

3 – Autorité de certification racine de confiance CER

Depuis un poste du domaine, nous exportons notre certificat d’autorité racine CER au format base 64.

Naturellement, on laisse pas trainer ça n’importe où hein et nous supprimerons ce dernier une fois l’opération terminée.

Pourquoi ? Avez vous déjà essayé de laisser un billet de 50 balles sur un banc public ? Voilà vous avez votre réponse 🙂

4 – Import du certificat et reboot des services

De retour dans notre VCSA, Administration > Certificates > Certificate Management. Choisir pour le Certificat Machine SSL²⁴ l’import et le remplacement du certificat.

Ayant préalablement réalisé une demande CSR, la clé privé est donc connu de notre appliance.

Nous importons notre fichier CRT généré par notre serveur de certificat dans le champ Machine SSL Certificate et dans le champ Chain of Trusted root certificates notre certificat d’autorité racine.

Plus qu’à cliquer sur Replace.

Si toutes les actions se passe bien, vous êtes expulsés mani millitari de l’interface VCSA. Normal puisque le processus de mise à jour des services vient de s’enclencher pour appliquer le nouveau certificat. Vous pouvez aller prendre un café, voire deux.

Pour les curieux, vous ne pourriez plus non plus accéder à la plateforme de VMCA²⁵. Pas de panique c’est normal. Il gambade dans le couloir, il va revenir rapidement. Patiente est mère de vertu.

En conclusion, nous arriverons au résultat suivant.

L’absence de l’encarts rouge sur le protocole HTTPS n’est plus présent. Après contrôle du certificat ce dernier est bien valide. Ce qui nous amène donc à nous dire que si nous accédons à cette ressource un jour et que l’encarts rouge reviens nous sommes dans le scénario :

• Mon certificat a expiré je suis un boulet
• Charlie tente de nous piéger avec un site qui ressemble mais n’est pas notre site. Qui s’appelrio phising

Dans le cas de la VCSA, bien penser aux dépendances tierces. Changement de certificat implique de facto de renouveler les empreintes et poignée de main.

Donc qu’est ce qu’on fait ?

Par exemple, on se connecte sur notre serveur VEEAM (et oui encore et toujours… Vous aurez compris mon amour inconditionnel pour cet éditeur et solution <3 ) et on réalise de nouveau un paramétrage pour prendre en compte le nouveau certificat ? Très bien. Tu gagnes une tagada #PASCALDUB.

Windows : RDP

L’un des usages les plus fréquents sur un SI pour les SysAdmins, l’usage du protocole RDP pour se connecter d’un server, ordinateur à un autre. Mais alors, il est fréquent de se retrouver en permanence avec le même avertissement nous informant que la connexion n’est pas sécurisé du fait de l’utilisation du certificat auto-signé.

Il est donc temps de remédier à ça. 🙂

1 – Modèle

Direction, la création d’un nouveau modèle en dupliquant le modèle Ordinateur. Je n’invente rien, je ne fais que suivre le guide MS. Je ne fais pas le choix de publier le certificat dans l’AD. La raison est qu’en activant cette case, cela va avoir pour conséquence de stocker les certificats dans l’AD afin de faciliter la gestion, l’inscription et la consultation des certificats. Ce qui me semble un peu risqué… Mon POV comme disent les jeunes de nos jours.

Pour la durée (je ne parle pas des macarons, et pourtant je vous confirme qu’ils sont bons), 2 ans me semblent pas mal. D’ici là, j’ai le temps de perdre mon LAB à la maison (si ma conjointe qui n’est pas encore mon épouse ne l’a pas accidentellement accompagnée vers le paradis des machines. C’est qu’il prend dans la buanderie le bougre).

Dans l’onglet Extensions, nous devons ajouter une nouvelle stratégie d’application. Pour une raison étrange l’application RDP n’est pas présente dans la liste des applications par défaut. Nous supprimerons l’authentification du client et du serveur.

Ce qui nous donne une fois configurée, le résultat ci-dessous. Les permissions sont importantes. J’ai choisi de limiter les droits d’inscriptions uniquement aux ordinateurs nécessaires. D’où la présence du groupe local de sécurité GLS_CERT_RDP.

Si le groupe n’est pas présent, pas de panique. Un petit switch dans la console AD users & computers et le tour est joué. La nomenclature m’est propre à vous de faire parler votre créativité.

Validez la création du modèle et activer ce dernier.

2 – GPO

Bien maintenant il faut bien déployer notre certificat. Du moins plutôt dire quel certificat doit être utilisé par notre service de bureau à distance.

Soit le gestionnaire de stratégie de groupe 🙂

Toutefois, il subsiste un petite subtilitée lors de l’ajout du nom du modèle de certificat. Comme l’indique le guide, nous pouvons préciser :

• Le nom du modèle
• Le nom de l’objet identificateur (ce que nous avons ajouté précédemment dans la stratégie d’application)

Selon Microsoft, l’usage du nom du modèle inscrira avec succès le service de configuration de bureau à distance (SessionEnv) mais en contrepartie, à chaque application de la stratégie une nouvelle inscription aura lieu. De facto cela peut engendrer une sursollicitions de l’autorité de certification.

Je cours le risque car mon SI est petit et même si mon ADCS ou mes ADDS ont des ressources plus que limités (c’est voulu, c’est du core) cela reste un banc de test. Mais attention toutefois. Je pense que c’est bon à savoir.

Je vous résume la stratégie ordinateur.

J’ai été choqué. Pas vous ? Regardez bien…

Pour une raison que m’échappe en parcourant les paramètres, nous pouvons spécifier une couche de sécurité spécifique pour les connexions par distante. En lisant la description nous avons le choix entre deux méthodes :

• SSL
• RDP

Le chiffrement RDP étant déconseillé, il est recommandé de forcer le type de chiffrement sur SSL. Sauf que cela ne prend en compte que TLS²⁶ 1.0… Voilà voilà… Un petit TLS 1.2 aurait été bien mais non. Espérons que cela va évoluer.

En bonus, j’aime a activer la saisie du mot de passe à chaque session en plus du mot de passe saisie dans le client RDP.

Une fois la GPO terminée, je lis cette dernière à un bon niveau de mon OU et ne l’applique que sur mon GLS_CERT_RDP. L’objectif étant à l’avenir de pouvoir jouer sur la flexibilité et ajouter des membres si besoin à mon groupe. Pour appliquer la GPO, cette dernière étant ordinateur elle s’appliquera au bout de 15 minutes. Sinon un petit gpupdate /force des familles et le tour est joué.

3 – Tests et Vérification

Vérifions que cela fonctionne bien. J’ouvre depuis mon réseau domestique une session RDP sur ma bulle d’administration/management (Ne vous inquiétez pas, il y a bien une règle de parfeu en Inbound).

Une petite consultation dans notre console d’autorité de certification dans les certificats délivrées et…. Oh surprise, nous retrouvons nos objets ordinateurs #COEURAVECLESMAINS.

Force et de constater que cela fonctionne. <3 Que d’amour dans cette partie 🙂 Je dirai que c’est le plaisir du devoir accomplie.

En inspectant le certificat présenté depuis mon poste domestique, nous retrouvons bien les informations d’inscriptions ainsi que le tampon de notre autorité de certification racine.

Mais alors pourquoi cet avertissement ?

Simplement que mon poste, lui ne connait en aucun cas l’autorité de certification de confiance ronelab.lan. Normal car il n’est pas dans le domaine. Donc mon poste considéré ce dernier comme non légitime puisqu’il ne peut vérifier l’authenticité de ce dernier.

Bien… Cela aurait peut-être mérité un article dédié. M’enfin ça me plait comme ça.

Conclusion

Et voilà le terminus, tel Jesus je claque ma portière en descendant de ma croix. Encore un pari non tenu quant à la longueur excessif de ce billet…

Il reste difficile de parler de sécurité sans savoir comment cela fonctionne (et encore je ne suis pas rentré dans les détails des algorithmes de chiffrement). Je pense qu’il est important et nécessaire déployer le rôle d’infrastructure ADCS sur les systèmes d’informations pour jouir et bénéficier des avantages des services qu’il propose.

Naturellement, cela permet de sécuriser les services et de garantir l’authenticité de l’accès de l’information sur des ressources le plus souvent visibles comme des sites web internes ou applications, mais également indirect (comprendre non visible) comme des protocoles et services LDAPS, WinRM over SSL, SMB over Quick, RDP etc.

Malheureusement, ce rôle est sous-estimé par les AdminSys qui voit en ce dernier plus une source de problème à venir et des difficultés de gestion que de la première pierre qui sert de socle à la sécurité du système d’information.

Voyons plutôt les avantages et inconvénients.

Le jour où ça déconne, le SysAdmin peut vite se sentir seul et démuni avec comme arme uniquement sa b**e et son couteau…

Pas de serveur ADCS, pas de serveur Radius. Pas de serveur Radius, pas de sécurité. Pas de sécurité, Pas de serveur ADCS. Pas de serveur ADCS…

J’ai donc été confronté à cette problématique qui m’a pour le coup empêché de publier plusieurs articles considérés comme inachevé. Il est certain que plus nous avançons dans le temps plus ce qui était considéré comme « optionnel » en termes de sécurité devienne un standard.

J’ai également en toute honnêteté rencontré un point de blocage qui a nécessité une aide extérieure quant à l’implémentation. La théorie c’est bien, mettre en pratique cette dernière est parfois plus délicat. Je remercie donc ce collègue amateur d’andouillette 5A pour le quart d’heure de pratique concernant VMWare. D’ailleurs est il incompatible de parler IT autour d’une table de brasserie ou semi-gastro ? L’idée est à débattre, je pense qu’il y a quelque chose à faire.

Vous l’aurez compris, il ne faut pas avoir peur de ADCS et de PKI. Il est impératif de sécuriser un maximum les services et ce rôle. Sans eux, et je crois en avoir dit assez long tout au long de ce papier je vais pouvoir étudier et présenter d’autres technologies.

Le mot de la fin ?

Je chiffre les paroles d’une chanson et paume ma clé privée, qui suis je ? George Alain bien sûr. Mais c’est pas un SHAOne ? Non un SHA d’IRAN. Okay cool, merci R-One.

Erwan GUILLEMARD

Sources

• RFC
• X509 : Extension
• Windows : ADCS Guide
• Windows : CVE PetitPotam
• Windows : ADCS Configuration CA
• Windows : RDP Certificat Settings

1. PKI : Public Key Infrastructure ↩︎
2. SI : Système d’Information ↩︎
3. IA : Intelligence Artificielle ↩︎
4. ADCS : Active Directory Certificate Services ↩︎
5. ADDS : Active Directory Domain Services ↩︎
6. PME : Petites et Moyennes Entreprises ↩︎
7. IIS : Internet Information Services ↩︎
8. KB : Knownledge Base ↩︎
9. GUI : Graphic User Interface ↩︎
10. CA : Certification Authority ↩︎
11. AD : Active Directory ↩︎
12. CVE : Common Vulnerabilities and Exposures ↩︎
13. SHA512 : Secure Hash Algorithms ↩︎
14. OS : Operating System ↩︎
15. RSAT : Remote Server Administration Tools ↩︎
16. MMC : Microsoft Management Console ↩︎
17. ADSI : Active Directory Service Interfaces ↩︎
18. RDP : Remote Desktop Protocol ↩︎
19. CSR : Certificate Signing Request ↩︎
20. REQ : Request ↩︎
21. CRT : Certificate ↩︎
22. VCSA : vCenter Server Appliance ↩︎
23. WAC : Windows Administration Center ↩︎
24. SSL : Secure Sockets Layer ↩︎
25. VMCA : vCenter Management Appliance ↩︎
26. TLS : Transport Layer Security ↩︎

Pourquoi commencer ce billet en étant si désagréable ? Parce que le sujet de la supervision, surveillance ou « monitoring » représente un enjeu capital pour l’activité des entreprises et il existe un large panel de solution payante ou gratuite sur le marché. Toutes ces solutions ne couvrent pas les mêmes périmètres de surveillance. Il est donc facile de multiplier les applications et de ne plus savoir où donner de la tête.

Personnellement, j’aime dissocier la surveillance d’un SI avec 3 types de solutions :

• Firewall et Liens
• Réseau Local
• Equipements Infrastructures Physiques et Virtuels

Dans certains cas, une 4 et dernière brique peut être amenée à être utilisée pour superviser des services applicatifs. Néanmoins, je ne suis pas un grand fan de ce niveau de surveillance (mais c’est mon opinion personnel) et il faut bien justifier le poste d’un Responsable Informatique dans sa société non ? (Je suis réducteur, mais un RSI ça sert à bien d’autre chose et ça ne fait pas que de boire des cafés toute la sainte journée avec Martine de l’accueil. Coucou Martine 🙂 ).

Je souhaite donc aborder le point de surveillance « Equipements Infrastructures Physiques et Virtuels » à travers une solution payante.

Soyons claire sur un point car je vois venir les détracteurs de la communauté GNU/UNIX et autres DAFs (bien trop proche de leurs budgets).

« Ouai mais il y a des solutions gratuites sous licence GNU qui font très bien l’affaire. En plus tu n’arrêtes pas de nous em*****r avec tes RHELs. VENDU ! »

Mon avocat à la barre, commis d’office me représente et assure ma défense.

« Mon client, tiens à préciser qu’il présentera une solution de supervision libre dans un autre billet car il est important de couvrir un périmètre similaire et plus flexible. Mon client s’engage dans cette démarche pour réduire sa peine si toutefois il est jugé coupable. Dans un second temps, il est important de se rapporter à la maxime « Le pas cher coute trop cher ». Une solution libre et gratuite c’est bien. Mais le jour où le MCO ne se passe pas comme prévu il est facile de passer un nombre d’heure conséquent. Les solutions payantes offrent un service de support et de correctif en cas de vulnérabilité critique. » CHEH ! Et en plus je vais tenter de vous convaincre que nous pouvons gagner ou économiser du MONEY MONEY.

J’ai donc décidé, d’après le titre de ce billet de continuer avec les solutions VEEAM, VEEAMOne.

Pourquoi le choix de VEEAMOne ? La solution est cross plateforme et permet d’avoir une bonne visibilité sur le socle de virtualisation, les ressources virtualisées ainsi que l’ensemble des éléments et environnement propres à la sauvegarde (VBO365, VDP). La cerise sur le gâteau reste la partie Business View, Reporting et Capacity Planning. Mais promis, je reviendrai plus en détail sur ces points bonus.

Je me garde également pour plus tard un autre article pour lequel j’ai besoin de VEEAMOne 🙂

Prérequis

• SE : Windows Server 2k19 et version ultérieures
• Apps : VEEAM B&R 12.x, VEEAMOne 12.x, VMWare/Hyperv
• Autres :
  • VEEAM B&R 12.x
  • License VEEAM Entreprise

Avant-Propos

Dans une logique de garantir un niveau de sécurité optimal, j’ai dans un premier temps longtemps pensé que l’ensemble des environnements de surveillance (supervision/monitoring) devaient être dans le même subnet que les éléments d’administrations ou de management. Maintenant, mon approche est différente. Je préfère dédier un subnet pour l’ensemble des solutions.

Mais pourquoi ? Je juge ces éléments sensibles. Ils donnent une bonne, trop bonne visibilité sur l’ensemble du SI. Admettons que la bulle de monitoring soit compromise, il nous suffira de restreindre totalement les flux réseaux ou à en limiter les flux depuis des ressources isolés. De plus, et cela se vérifie avec le temps certaines solutions de monitoring apportent des fonctionnalités d’actions sur les ressources sous surveillance ou de remédiations automatiques. (Mon dernier HP Tour Customer & Partner nous indique bien la tendance de l’IA et sa capacitée [monstrueuse ?] de traitement). Bref, ce n’est pas un outil à mettre dans toutes les mains, c’est un coup à être satellisé…

Théorie

Architecture & Best Pratices

Encore une fois, chacun voit midi à sa porte. Il est donc compliqué de définir une MO¹ empirique. Cela dépendra des technologies et solutions utilisées que ce soit en socle de virtualisation (VMWare, HyperV etc) et produits VEEAM (VBO MS365, VBR², VCC³ etc).

Mais commençons par le début. Qu’est-ce que contient VEEAM One et qu’a-t-il dans le ventre ?

VEEAM One se décompose de deux grandes parties. Une partie client et une partie serveur.

Clients

Comme on s’en doute, cela permet d’accéder aux données des environnements virtualisés ainsi que les données relatives à la sauvegarde, réplication et autres. Toutefois, nous distinguerons deux types de client.

Client Lourd : Son objectif est de permettre à travers la console d’accéder à l’ensemble des données de manière efficiente et d’avoir une vue globale sur notre infrastructure et d’interagir avec ce dernier selon les alertes remontées par les différentes sondes. Il sera nécessaire de déployer/installer le client sur le poste concerné et d’ouvrir les ports.

Client Web : A l’inverse, la console web est moins orientée « opérationnelle » au sens technique, mais plus au sens qualitatif avec l’élaboration de rapport, de tableau de bord et de définir l’évolution du SI (capacity planning, optimisation des ressources, optimisation des couts etc). Si les flux sont ouverts, il suffira d’accéder à ce dernier à travers un navigateur web à travers l’url https://monserver.contoso.lab:1239

Ce qui nous donne le schéma des flux suivants.

Donc si nous résumons, les choses. Le client lourd sera satisfaire les équipes opérationnelles et la partie client web les responsables / directeurs de services. Les jambes et la tête en sommes. 🙂

Dans son fonctionnement et c’est là l’une des forces de la solution. Le client lourd fonctionne sur la base d’une API. Ce qui implique que nous pouvons réaliser TOUTES les actions qui sont présents dans la console 😀 (Vous me voyez venir avec mes grosses charentaises ? )

Serveur

La partie serveur est bien plus complexe. De facto, les deux clients présentés précédemment sont présents sur le serveur

• VEEAM One Client
• VEEAM One Web Client

Ce qui est logique puisqu’il faut bien administrer la solution…

Toutefois, nous rencontrons également les rôles suivants :

• VEEAM One Server
• VEEAM One Database
• VEEAM One Agent
• VEEAM One WebServices

Dans le détail de chaque rôle, la partie Server va servir à la collecte des informations, des données et stocker ces dernières dans la Database afin de pouvoir par la suite les restituer sur l’action de l’utilisateur à travers les clients (web ou lourd). Il est possible de mutualiser la base de données VEEAMOne (MSSQL) avec d’autres produits. Toutefois je préfère ne pas mettre tous mes œufs dans le même panier et tenter de mutualiser mes BDDs, cela reviendrait à essayer d’additionner un veau avec des cigarettes…

La partie WebServices permettra comme nous pouvons nous en douter de garantir l’accès depuis un navigateur web au WebClient ainsi qu’à l’API.

C’est quoi la partie Agent ? Ne me dit pas qu’il faut se palucher le déploiement d’un agent sur les ressources que nous souhaitons surveiller ? Si c’est le cas, j’arrête ma lecture après ta réponse !

La partie Agent n’est pas à déployer sur toutes les ressources et heureusement. VEEAM One a été pensé pour être flexible ! La communication avec les applications de virtualisation se font soit par le biais de protocoles « classiques » ou par les APIs constructeurs.

L’Agent est nécessaire uniquement lors du monitoring, de remonter d’informations (logs) et d’effectuer des commandes de remédiations si nécessaire entre les serveurs VBRs et le serveur VEEAM One. Le guide, recommande son installation, toutefois il n’est obligatoire de déployer l’agent (personnellement, pourquoi ne pas le faire ?).

La partie Agent comporte deux modes. Un mode client (paramètre par défaut) ainsi qu’un mode serveur. La différence entre les deux se trouve dans l’exécution des commandes de remédiation qui ne sont présentes que dans le mode client. La partie serveur quant à elle va gérer les mises à jour des signatures et analyser les journaux VBR.

Et si nous réalisions une petite Map des différents flux ? 🙂 Naturellement, je ne compte pas réinventer la roue, mais juste mettre en avant ce que je vais implémenter plus tard. Pour le reste, il suffira de consulter le lien constructeur.

Comme pour le serveur VEEAM dans un billet précédent, une restriction des flux sortant vers l’extérieur est appliquée sur le serveur VEEAMOne. Ainsi, seul les URLs et NDDs habilités à communiquer avec VEEAM et MS sont autorisés.

Soit pour VEEAM One :

• Serveurs de mise à jour :
  • dev.veeam.com
• Serveurs de licences :
  • one.butler.veeam.com
  • download2.veeam.com

Okay, maintenant que nous voyons un peu plus clair dans nos différents flux, posons-nous la traditionnelle question du « le principe de moindre privilège ».

Access & Less Privileged

Cette partie (peu importe la solution à mettre en place) est un véritable casse-tête. La simplicité voudrait que nous attribuions les permissions root ou system pour avoir la paix.

« Regarde, ça fonctionne ! » J’aime à répondre à ça soit par le traditionnel « Peinture sur merde égal propreté » ou « Je travaillais comme ça quand mon patron m’a viré« .

Soyons sérieux deux secondes… VEEAM nous mache encore une fois le travail et nous allons voir en détail comment configurer les différents comptes avec les moindres privilèges. Cependant, je pense utile de nous remémorer que dans certains cas, il est obligatoire d’attribuer des permissions d’administrateur du domaine ou à privilège (sudo) et malheureusement nous ne pouvons pas faire autrement.

Dans ce cas de figure, il est difficile de faire autrement. Néanmoins, nous pouvons et je dirai même c’est notre devoir de mettre tous les artifices en place pour restreindre le périmètre d’exposition de ce type de compte.

Nous distinguons dans notre cas 3 accès à configurer. L’accès à l’application, l’accès à notre socle de virtualisation et notre infrastructure de sauvegarde.

1 – VEEAM BR : Infrastructure de sauvegarde

Dans le respect des bonnes pratiques, notre serveur VEEAM n’est pas joint au domaine. Nous avons besoin pour interconnecter VEEAMOne à notre serveur VEEAM d’un compte administrateur local.

Pourquoi ? Parce que VEEAMOne doit avoir les droits nécessaires pour déployer son agent. Comme présenté précédemment, il nous faut contraindre ce compte.

Typiquement, nous pouvons considérer ce compte comme une compte de service. Il nous faudra alors interdire les connections locales et distantes à ce compte directement sur le serveur VEEAM.

Attention, étant un compte local il sera nécessaire d’effectuer au minima une rotation du mot de passe une fois par an.

2 – VMWare : Infrastructure de virtualisation

Là, c’est plutôt simple, il suffit d’utiliser directement le compte root de notre VCSA⁴.

NO WWWWAAAAYYYYY !

RTFM⁵ mon gars ! VEEAM explique ce qu’il faut faire (ici). Je ne vais donc pas m’attarder là-dessus.

Là, il y a deux écoles. Je n’ai pas encore fait un article sur le sujet VCSA et personnellement je ne sais pas si j’ai envie d’en faire un car les interfaces changes tout le temps au gré des montées de version VMWare. Bref, il reste à définir si nous souhaitons utiliser des comptes locaux ou un compte du domaine pour interconnecter VEEAMOne à notre environnement VMWare.

Les raisons sont toujours les mêmes. Sécurité, Sécurité et Sécurité.

3 – VEEAMOne : Application

L’application se base également sur le principe de moindre privilège ainsi que sur le principe de RBAC⁶ (un truc vraiment cool pour les SysAdmins).

Nous retrouvons donc les schémas 3-Tiers classiques, utilisateurs lecture seul, utilisateur avec pouvoir et les utilisateurs administrators.

Sur notre serveur VEEAMOne, nous retrouverons ainsi les groupes locaux qu’il siéra à notre guise de peupler en respectant les bonnes pratiques et recommandation avec les ressources de notre domaine.

Pour enfoncer le clou, les rôles énumérés précédemment permettent les actions ci-dessous. A nous de mettre les bonnes ressources techniques en face du bon profil.

Rôles	Permissions
VO Read-Only	Accès à la surveillance des données en lecture seule Accès à la génération de rapport
VO Powered	Accès à la surveillance des données Accès à la génération de rapport
VO Administrator	Accès à l’ensemble de la plateforme Accès à l’administration des données Accès à la génération de rapports Modification de la configuration VEEAMOne

Licensing

Pratiques

Nous considérons que le serveur Windows a été durci au préalable et que nous possédons un serveur à jour.

Nous avons également téléchargé en amont les sources (iso) de Veeam One.

Nous ne traiterons ici que de l’installation d’un server VEEAMOne « AllinOne » (car j’ai un petit lab). Mais il est possible d’envisager un déploiement 3-Tiers (VEEAMOne Server, MSSQL Server et VEEAMOne UI). Je propose quelques choses de standard (car il faut sur un petit LAB se satisfaire du nécessaire et être heureux) sur la base de VEEAM BR, ESXi⁷ et VCSA.

Installation

Nous partons donc du principe que notre serveur Windows est déjà configuré et joint à un domaine (oui oui, j’ai bien écrit joint à un domaine). Que nous avons une appliance vCenter (joint ou non au domaine) ainsi qu’un serveur VEEAM BR (non joint au domaine et préalablement durci et conforme aux recommandations VEEAM.

Les prérequis en termes de ressources doivent être les suivantes (pour une Single Server):

• OS : WIN10, WIN11, WS 2012 à WS 2022
• CPU : 4 cores (minimum)
• RAM : 8 Go (Minimum) / 16 Go (Recommandé)
• Disk : 50 Go pour la SGBD MSSQL et VEEAMOne DB
• Network : 1 Gbps minimum

Top à la vachette, démarrons l’installation !

1 – You are a wizard Veeam ONE !

2 – Server or client ?

3 – Licenses & EULA

4 – License bite ! (Ou restez en Community Edition)

5 – VEEAM One Service Account (si si ombre !)

6 – System Check… Hold on 2 minutes

7 – Install or not 😀 (Customize)

8.0 – Customize, Choose VEEAM Components

8.1 – Customize, Database

8.2 – Customize, DataLocations

8.3 – Customize, Mode

8.4 – Customize, Ports

8.5 – Customize, Resume & Install (sure ?)

9 – Install ongoing, please offer me a coffee <3

10 – CONGRATULATION

A prononcer façon Smash Brosh 🙂

Configuration

Lors du premier lancement du client VEEAMOne, nous allons être invité à configurer l’application. Il faut comprendre par configuration le paramétrage général du serveur. Pour ce qui relève de la configuration des autres vues ou fonctionnalités, cela relèvera d’une partie dédiée dans cet article ou d’un article à part entière (je n’ai pas encore décidé).

De la sorte et je pense qu’il est utile de le souligner une nouvelle fois, un système de supervision et de monitoring sans être notifier reviens à commander un steack frites alors que l’on aime pas les frites et que l’on est végétarien. Hé ben c’est con ! Configurons alors les notifications.

1 – SMTP un incontournable !

Nous commençons à avoir l’habitude avec les solutions VEEAM de configurer les notifications. C’est exactement la même chose que pour VEEAM BR, à l’exception que l’IHM⁸ est d’une couleur différente.

M’autorisez vous à passer cette partie ? Naturellement car je fais ce que je veux 🙂 Le seul point, bien penser à ouvrir les flux outbounds concernant le protocole utilisé. Sinon ba ça marche pas et ça ne court pas non plus… (Il est comique le garçon…)

2 – A qui le postier doit il délivrer le courrier ?

Dans ce cas, nous pouvons ajouter plusieurs adresses mails en destinataire des notifications selon l’état des notifications (Toutes, les erreurs et avertissements, les resolved etc).

Toutefois, cela pose un problème car si nous souhaitons notifier qu’une équipe particulière sur certaines ressources, cela va être difficile de se coltiner toutes les notifications de l’infrastructure et donc d’être pollué…

Il faut voir ce paramétrage ci à destination de l’équipe Cloud, Services Hébergés et autres fiches de poste. Concernant les notifications plus ciblées à destination d’équipe spécialisée, je reviendrai dessus dans la partie Business View.

3 – Politiques de notification

Pour cette étape, je suis un peu un SysAdmin sans personnalité car je vais laisser les paramétrages par défaut.

Il est possible de définir et de modifier un template. Dans mon cas d’usage, je trouve (et encore une fois il va nous dire que c’est son avis personnel…) que ça fait le taf.

4 – SNMP

Encore un classique de la supervision. Qui dit supervision dit log et donc SNMP⁹. Cela permet d’avoir une bonne visibilité de son réseau, des équipements et de l’état de santé de ces derniers.

Je ne l’utilise pas.

HAAAANNNN, NANI !!!!

J’ai une excuse. Dans un contexte professionnel, je préfère utiliser les solutions propriétaires. L’inconvénient, c’est que cela à un coup. Néanmoins, je pense qu’il serait temps de regarder d’un peu plus prêt cette fonctionnalité de collecte.

5 – ITSM : ServiceNow

Et si nous cherchions un peu d’efficience pour notre infrastructure, les équipes opérationnelles ? L’un des rêves d’un SysAdmin (surtout le mien) reste d’intégrer les alertes dans la solution ITSM¹⁰ afin de pouvoir traiter de manière pro-active les alertes systèmes.

VEEAMOne propose de s’interconnecter à la solution ITSM ServiceNow. M***e pas de bol je n’utilise pas cette solution. Donc je passe mon tour…

« Tristesse, ton petit cœur doit saigner et tu dois roter du sang en boule sur ton paillasson ? »

Hé non ! Si VEEAMOne ne propose pas de passerelle avec la solution ITSM que j’utilise (ITOP pour ne pas la nommer), les deux solutions possèdent une API¹¹. Vous voyez où je veux en venir. 🙂

Je prépare cette introduction depuis longtemps et j’espère vous présenter mon connecteur dans le prochain article. Je ne suis pas vache, je vous lâche un petit teasing <3

6 – Le puit de Log

Le puit de log… Fonctionnalité que je n’utilise pas non plus. Mais sur laquelle je devrais me pencher.

Garantir un historique des alarmes déclenchées et centraliser ces dernières seraient vraiment sympa. Toutefois, je rencontre une problématique. Je n’ai pas ce jour mis là main sur une solution libre qui soit facile d’administrer et de maintenir. Libre ne veut pas dire gratuit que nous nous entendons bien.

Par exemple, j’ai utilisé la solution GrayLog. Nous sommes vite limités par la licence communautaire sur le notre de flux journalier échangé. Il suffirait de prendre la CB est hop le tour est joué.

1-0 pour la solution

J’ai voulu mettre à jour la plateforme et j’ai tout cassé. Il suffirait de passer en SaaS chez l’éditeur comme ça plus de problème de MCO.

2-0 pour la solution

Pour le coup, je demande la VAR. Je ne suis pas fan de l’hébergement en SaaS dans ce cas précis. L’arbitre accorde donc 1-1, balle au centre…

Conclusion, il faut que je torture encore quelques cellules grises dans mes travaux nocturnes pour étudier ce point.

7 – Récap

Le petit récapitulatif, comme nous avons l’habitude de l’avoir chez VEEAM. Je trouve cela d’une simplicité et d’une efficacité remarquable. Chose que nous n’avons pas toujours sur d’autres solutions.

Tu vas vraiment nous faire croire que t’as pas d’action chez VEEAM ?

La configuration terminée, nous pouvons admirer notre console vierge et vide de toutes données. Il faut l’avouer, il y a là un côté tristoune. Je rassure, pas pour bien longtemps.

Virtual Infrastructure

La vue Virtual Infrastructure va nous permettre de suivre l’intégralité de l’état de santé ainsi que les évènements de notre SIs depuis le socle de virtualisation jusqu’aux SEs des machines virtuelles.

Comme souligné précédemment, l’objectif est d’être proactif face à un dysfonctionnement d’infrastructure ou d’anomalie sur un serveur virtuelle en production.

VEEAMOne prend en charge les produits suivants, VMWare, VMWare Cloud Director, Microsoft Hyper-V.

Un exemple ci-dessous d’ajout d’une appliance VCSA.

VMWare

1 – Add Server

Sous Virtual Infrastructure, faire un clic droit et ajouter un nouveau serveur.

2 – VMWare Connection

VEEAMOne nous demande si nous souhaitons ajouter une appliance ou un hote directement. Renseignons le nom DNS de notre appliance.

3 – Credentials

J’ai fait le choix (pour l’instant) de ne pas binder mon appliance VCSA à mon AD. C’est pourquoi j’ai créé un compte local svc.veeamon@vsphere.local sur mon appliance avec les permissions nécessaires.

Naturellement, il ne faut pas oublier d’ouvrir les ports interlan dans le cas de segmentation des réseaux.

4 – Summary

Le traditionnel rappel et voilà notre appliance VEEAMOne connecté à notre VSCA.

Veeam Backup & Replication

La vue Veeam Backup & Replication comme son nom l’indique va traiter de la sauvegarde et de l’ensemble des jobs de protection. Si la vue d’infrastructure vient à donner une bonne visibilité de notre infrastructure virtuelle, nous aurons avec cette vue ci une visibilité sur l’ensemble de notre infrastructure VEEAM.

Depuis l’état du serveur de sauvegarde, des jobs en passant par la charge des proxies VEEAM ainsi que l’utilisation des repos de sauvegarde ainsi que le détail des chaines (full et incréments).

Lors de la présentation de la solution dans la partie « Théorique » le déploiement d’un agent de supervision permettra de réaliser en plus de la remontée d’informations la possibilité de réaliser des actions de remédiations.

1 – Add Server

M’sieur, un petit clic droit sur Add Server 🙂

2 – VEEAM BR Connection

Nous renseignons comme précédemment pour l’ajout d’une ressource d’infrastructure le nom DNS de notre serveur VBR. Il est également possible d’intégrer un serveur VB Entreprise Manager.

Je n’utilise pas ce dernier et pourtant c’est le manque de temps en ce moment qui vient ralentir ma boulimie intellectuelle et m’empêche d’avancer.

Je coche volontairement l’installation de l’agent VEEAMOne pour avoir les actions de remédiation et d’avoir le relevé de journaux d’événements ainsi que son analyse.

La seconde coche permet de joindre notre serveur VBR à notre serveur VEEAMOne et donc avoir directement dans la console VBR les informations et performance de notre infrastructure de sauvegarde. (Franchement, il ne faut pas hésiter C’est du read only pas de risque 🙂 )

3 – Credentials

Renseignons le compte local de notre serveur VBR qui va permettre le relevé d’installation. J’ai déjà expliqué les actions préconisées pour garantir un niveau de sécurité acceptable.

Toutefois, rappelons-nous qu’il est nécessaire d’avoir les droits d’administrations pour que VEEAMOne puisse installer l’agent VEEAMOne. Sans quoi vous aurez le joli message ci-dessous <3

4 – Summary

Le récap, le récap, le récap !

Une fois ajoutée, nous obtenons une interface vide. Pas de panique, c’est normal. Ce n’est pas un bug.

En regardant l’image précédente, nous remarquons en bas à droite que l’infrastructure est en cours d’import. Ah ouf ! Il en sera de même avec l’installation de l’agent et la remontée de log. Il faut faire preuve de patience et non pas cliquer 50 fois sur le bouton d’impression au risque de griller notre imprimante. Les données remonteront d’elles-mêmes comme présenté dans le début de cette partie.

Dans la même logique, si nous avons coché l’accès aux tableaux de bords dans la console VBR, il sera nécessaire d’attendre l’intégration des datas.

Dans notre console VBR, dans l’onglet Analytics nous retrouverons les informations sur la planification, durée des jobs. La sollicitation de telle ou telles ressources, l’espace de stockage de nos repos ainsi qu’une vue globale MENSUELLE de nos jobs de sauvegarde (et dire qu’avant cette fonctionnalité je me suis fait iéch à faire des extracts et tableau xlsx…. Je les utilise toujours pour mes indicateurs hein 😉 ).

Sinon, il est tout à fait possible d’avoir les mêmes informations dans la WebConsole VEEAMOne. Si vous savez, le truc qui commence par https et se termine par 1239 du type https://monseveur_VEEAMOne.contoso.com:1239.

Business View

Cette partie est intéressante pour celui qui sait la manier. Personnellement j’ai mis un certain temps à comprendre son mécanisme et l’intérêt que cet onglet peut apporter.

Dans cette « Vue Affaire », il va nous être possible de faire presque quasiment tout ce que nous souhaitons en termes de filtre et d’identification sur les ressources VMs, Hosts, Datastores et Clusters.

Cette vue va donc nous permettre de répondre à des problématiques financières et techniques.

• Financière : Afin d’avoir un rapport précis des ressources consommées par un service (SaaS) ou d’infrastructure (IaaS). D’assurer l’efficacité et l’efficience de notre infrastructure afin de définir si nous sommes en over-capaciting ou under-capaciting. Investir, pas investir ? Prospecter, pas prospecter ? (Mon PDG répondrait sans hésiter OUI ! et il a bien raison)
• Technique : Pour garantir un état de santé par service, la présence de snasphot, la possibilité de notifier que certaines ressources aux bonnes équipes… J’en passe car la liste pourrait être longue.

Sincèrement, je vois la partie Business View comme le pivot et point le plus important pour maitriser son budget ainsi que son SI.

Bon hormis le fait que je laisse l’impression que mon exploitation n’est pas faite à la maison. Objection lecteur ! Mon MCO est fait. Il se trouve que l’erreur disque sur mon second AD est lié à la sauvegarde Windows et que je n’ai pas acquittée cette dernière (Oui j’ai bien écrit Acquitté et non Résoudre).

Mais bon entre nous, un système de monitoring sans erreurs et avertissements ça serait d’un ennui non ?

Par défaut nous avons la vue ci-contre. Il sera alors possible pour nous de définir des nouvelles catégories pour chacune des familles présentée plus tôt. Nous allons réaliser les catégorisations selon 3 critères. *** Single Parameter *** Muliple Conditions *** Grouping expression

Je pense que pour bien comprendre la puissance de ces trois méthodes de catégorisation, il faut que nous nous attardions dessus.

1 – Single Parameter

Comme présenter rapidement plus haut, nous allons catégoriser une ressource sur un groupe d’objet qui se base sur une propriété du type concerné (VMs, Hosts, Datastores ou Clusters).

L’étape qui suit vous demandera si vous souhaitez créer un tag sur l’environnement vSphere ou non. Personnellement je n’utilise pas les tags sur ce genre de catégorisation.

Je reviendrai plus bas sur la notion de tag au sens VMWare du terme car il y a des subtilités à assimiler.

Le cas d’usage pour cette catégorisation (à mon sens) et de filtrer, identifier rapidement des ressources sur des actions, états simples. Je dirais donc parfait pour l’administration et le MCO.

2 – Multiple Parameter

La catégorisation mutli-paramètres va nous offrir plus de possibilité quant à la possibilité de trier et de sélectionner les ressources que nous souhaitons obtenir.

Comme nous pouvons le constater ci-dessous, la liste des critères de ciblage est plutôt conséquente. Passant des paramètres systèmes aux éléments d’infrastructures en réalisant une halte par la sauvegarde. Nous retrouvons également les classiques opérateurs de comparaisons (Equals, Not Equals, Contains, Starts/Ends with…) par rapports à une valeurs.

Comme vu ci-dessus, j’ai choisi ici d’identifier l’ensemble des VMs contenu dans les VM Folder qui contiennent les noms IaaS et SaaS. Il faudra comprendre VM Folder au sens VMWare du terme lors de la création d’un dossier dans la vue VMs & Templates de notre VCSA naturellement.

Contrairement au cas de catégorisation précédent, je vais choisir de créer les tags vSphere. Ainsi, les ressources (VMs) qui se trouvent sous le répertoire parents IaaS se verront identifiés comme un type IaaS. Il en sera de même pour le type SaaS.

C’est là que le sujet commence à devenir intéressant. Car comme évoqué plus tôt, nous commençons à travailler la donnée de notre infrastructure en donnée financière.

Quels est la part de notre infrastructure consommée et allouée à nos services BaaS, SaaS, IaaS, ect… Quels est la part de notre SI allouée à son fonctionnement et la production ?

Je vois dans déjà dans le fond de la salle les yeux pétillants des DAFs, DCs et autres dirigeant d’entreprises. Oui, nous SysAdmins nous savons vous faire faire des économies et apporter un vrai valeur ajoutée <3. (Je développerai ce point dans la conclusion).

3 – Grouping Expression

Je crois que c’est la méthode de catégorisation que je préfère car elle permet de faire presque tout ce que l’on souhaite. Cette vue est orientée « développeur » (le style old school VisualBasic).

Ci-dessous, un exemple avec la catégorie VMs with Snapshots qui va selon la date des snapshots nous offrir une vue et métriques sur les snasphots présent si c’est la durée de vie de ces derniers est inférieurs à 1 jour, 7 jours, 30 jours. Dans cet usage, cela permet au SysAdmin d’avoir une granularité sur une tâche bien distincte et dans certaines situations maintenir le curseur sur ce qui est acceptable ou non.

Au-delà de cette possibilité, il est également possible de gérer (créer, pas supprimer hein) les tags vSphere de manière dynamique selon l’évolution de l’infrastructure de notre arborescence VMs & Templates. Ainsi, admettons que nous créons une nouvelle bulle SaaS ou IaaS sous cette même infrastructure, l’ensemble des ressources qui se trouvent sous ce dernier sera identifié comme IaaS ou SaaS et du nom du répertoire. Pratique donc par la suite de sortir des indicateurs de ressources et de faire une facturation à la carte (refacturation interne ou facturation à un client final).

Pour bien comprendre l’intérêt des tags vSphere générés par VEEAMOne, pourquoi ne pas se lancer un petit RVTools des familles ? 🙂

C’est un coup des Indiens Lucky Luke, il y a des flèches partout !

Au delà de mon humour douteux (ainsi que mon admiration pour Terence Hill quand j’étais jeune garçon), nous avons là un outil puissant. La création des tags par catégorisation au délà du client et de la solution VEEAMOne est exploitable dans VMWare. Donc, il va nous être possible avec de l’huile de coude et un peu de rigueur d’établir des métriques et rapports sur l’évolution d’une bulle, d’un service. Et pourquoi pas établir un outil de capacity planning ? Tout devient possible.

J’avais pour projet de créer une petite application sur un moteur SQLite ou MariaDB un outil de suivi des ressources sur 13 mois glissants. Malheureusement, pour moi il faut faire du web…

Oui, on sait, c’est une étape traumatisante de ta vie. Tu ne voudrais pas débuter une thérapie et arrêter de nous briser les noix avec ça ?

Oui, promis je vais y penser. Mais au délà du traumatisme, il faut du temps et difficile de me cloner (et je ne suis pas certain que cela soit une bonne chose). Toutefois et dans le cadre professionnel, j’ai développé un fichier excel qui fait le taf mais comme tous fichiers excel, ce dernier ne connait que son maitre. C’est pour ça qu’une petite application web serait sympa. Et je crois qu’il est important de souligner que les fichiers excel pour faire tout et rien. C’est has been maintenant car il faut faire du PowerBI… Je pense que je ferai un article là-dessus quand j’aurai redéveloppé une solution plus simple (en gros sans code en VB et des formules de 5 km de long).

J’ai déjà bien abordé le sujet des tags. Il y a néanmoins une chose importante à savoir sur l’utilisation de ces derniers. L’application des tags vSphere (création) peut prendre un temps certain c’est pourquoi il faut être patient (selon la documentation cela peut prendre jusqu’à 3 heures et plus selon la taille de l’infrastructure). De plus il sera nécessaire de se rendre dans la console WEB pour réaliser une collection des données.

Par défaut cette dernière est définit quotidiennement à 03:00 AM.

J’ai personnellement modifié cette dernière pour qu’elle se lance toutes les 3heures. Attention à vos performances. Il est également possible de lancer une collecte de données manuellement.

VEEAM Report

La partie Report se passe sur le client Web (https://monVEEAMOne.contoso.lan:1239). Une fois connecté, c’est dans la partie Dashboard et Reports que nous allons avoir les outils les plus pertinents.

Dashboard

Dans le tableau principal, nous allons retrouver les catégories par défaut. Il sera toutefois possible d’ajouter des « tuiles » avec des vues personnalisées. Je trouve que les tuiles présentes suffisent largement à mon activité. Je pense qu’il est important de présenter chacune d’entre elles. Pourquoi ? Parce qu’il est facile de ne pas comprendre les informations présentées et de passer à côté de métriques et d’éléments qui faciliterons la prise de décision technique et financière. 🙂

1 – Veeam Backup & Réplication

Sans grande surprise, nous retrouvons ce que nous avions déjà vu précédemment dans VEEAM BR dans la rubrique Analytics. Normal puisque VEEAMBR vient chercher les métriques dans VEEAMOne qui vient lui aussi les chercher dans VEEAMBR.

La boucle est bouclée.

Blague à part et j’adore le phénomène démo. J’ai la majorité de mes jobs qui ne passent pas. Cela se retranscrit dans mes charts. A moi de résoudre le problème.

Merci qui ? Merci Jacquie et … Non un peu de sérieux ! Merci VEEAM One <3

2 – HeatMap

Comme pour la partie précédente, nous retrouvons également cette partie dans la console VEEAM BR.

Si la première partie de l’accordéon concernait les jobs et l’état des jobs, là nous sommes plus sur les performances et usages des différentes ressources de l’infrastructures VEEAM. La notion de dégradée sera utilisée de vert à rouge selon l’usage et la sollicitation des différents composant VEEAM.

3 – vSphere Trends

J’avoue que cette vue n’est pas bien parlante dans mon cas car je ne possède pas de Cluster VMware.

Toutefois, cette vue va permettre d’afficher les tendances de notre cluster concernant l’utilisation des différentes ressources. Parfait pour identifier les pics et évolution du SI sur une période.

4 – vSphere Alarms

L’une de mes vues favorites. Pourquoi ? Car elle indique et offre une visibilité totale de l’état de vie de notre SI. L’évolution du nombre d’avertissements ou d’erreurs critiques.

Au déla des métriques quantitatives, ces métriques sont identifiées par catégories. Ce qui facilite grandement et facilement les actions prédictives vis à vis d’une panne d’infrastructure logique ou physique.

5 – vSphere Hosts & Clusters

Nous retrouvons comme dans la tuile numéro 3 – vSphere Trends le même constat aussi triste soit-il dans mon cas. Pas de cluster, pas de métrique…

Ce qui n’est que partiellement vrai. Puisque nous constatons dans cette vue la tendance de consommation à la hausse ou à la baisse des ressources d’un hôte VMWare ou d’un cluster. Cela peut donc se traduire par, à la hausse ou en sous-évaluation de l’infrastructure et un besoin de renforcer cette dernière. A la baisse, une infrastructure surévaluation de l’infrastructure vis à vis de son usage quotidien.

Dans la logique, je dirai que nous devons tendre vers une constante en acceptant un léger taux de variation et non à une fonction croissante, décroissante.

6 – vSphere Datastores

Un incontournable ! Pour les nostalgiques des ayatollahs de l’exploitation à travers les RVTools. Nous retrouvons l’évolution des datastores à la hausse comme à la baisse sur l’espace disponible. La visibilité des vmdks quant à l’espace consommé et l’espace disponible. La latence des différents datastores (impeccable pour la prédiction d’un disque qui va lâcher), les IOPS pour chaque datastore.

Que dire de plus. C’est merveilleux, c’est extra !

7- vSphere VMs

J’ai l’impression de me répéter… Après les datastores et la partie hosts & clusters, maintenant c’est au tour des virtuals machines.

Cette fenêtre permet d’identifier assez rapidement si une VMs nécessite l’ajout de ressources supplémentaires ou une surallocation. Elle permet également dans un certain contexte d’orienter un potentiel dysfonctionnement de type hardware, ou software (mauvaise configuration d’une application métier par exemple comme ça au hasard).

8 – vSphere Infrastructure

De nouveau un petit coup de pouce sur les ressources disponibles et sur les ressources consommées.

Parfait pour éviter l’overprovisionning, le balloning 🙂

9 – vSphere Capacity Planning

La vue crainte par les SysAdmins, DSI et DAF.

Cela correspond à partir des tendances d’usage en une projection de la durée de vie de l’infrastructure et donc de son renouvellement ou de sa consolidation en ajoutant des ressources supplémentaires.

En gros :

Exprimer le besoin, Présenter le devis, Faire valider l’investissement, Obtenir le chèque signé, Mettre en production les ressources. Simple non ? :p

Pour le reste, il suffit d’un peu d’imagination et d’établir les métriques que l’on souhaite obtenir et pourquoi pas générer les rapports et se les faire envoyer dans notre boite mail ?

Le conseil que je donnerai, c’est de se perdre dans le choix des possibles qu’offre VEEAMOne et de garder en tête « Est ce que cela m’apporte une valeur ajoutée business et technique ?« . Si c’est le cas alors vous êtes, nous sommes sur la bonne voie 🙂

Report

La fonctionnalité du Report et de générer des rapports. Merci Capt’aine Obvious…

Oooooh ba si on ne peut plus rigoler… Pour faire simple nous allons être dans la capacité de générer des rapports précis sur des thématiques précises :

• Charge de l’infrastructure
• Facturation VEEAM Backup
• Supervision VEEAM Backup
• Optimisation vSphere
• Capacity Planning
• …

Il suffit de regarde l’interface.

Prenons deux exemples. L’un orienté pour le business et l’autre pour la technique.

1 – Business – Facturation VEEAM Backup

Admettons que nous souhaitons vérifier ce que nous devrions facturer à un client des bulles T0 et T1 mensuellement. Et que le cout de la sauvegarde est de 24,79€ du TB.

Nous configurons les paramètres en sélectionnant nos différents tags T0 et T1 ainsi que les jobs concernés. Nous précisons la période sur le mois en cours. Puis nous cliquons sur Preview en haut à gauche.

Et tadam ! Voilà notre rapport (sur deux pages).

Page 1	Page 2

Franchement, que demander de plus ? Nous avons même inclus le cout de notre repository (multipliant le cout par 4). Et nous voilà avec le cout pour le mois en cours. A oui nous sommes le 01 Octobre…. J’ai peut-être eu la main lourde sur le prix unitaire au TB 🙂

Bref, pas mal pour mettre en évidence le ROI¹² <3

2 – Technique – Surdimensionnement des VMs

Nous allons vérifier par le biais d’un rapport que nos ressources allouées sur notre infrastructure ne sont pas sous/surprovisonnées. Dans le cas contraire, il faudra engager ou non des actions.

On valide une nouvelle fois sur Preview, puis on tourne trois fois sur sa chaise de bureau.

Page 1	Page 2	Page 3

Alors c’est super nous pouvons faire des économies en réduisant considérablement les ressources !

Tout doux bijoux !

Ce ne sont que des recommandations, il ne faut pas prendre tout pour argent comptant. L’évaluation est une moyenne et viens prendre en compte les piques de suractivités. Mais ce n’est pas pour autant qu’il ne faut pas réfléchir. Dans le cas de mon lab, les ressources se (je ne sais pas si je peux me permettre cette expression… Allez… Vous ferez mon procès ultérieurement) touchent ! Mais si nous ciblons une heure bien précise (genre sauvegarde par exemple) les recommandations ne seront pas les mêmes. Il est également important de bien faire attention au paramètre de génération du rapport.

Le rapport sera différent si nous considérons le compteur de vRAM en « Active » et « Consumed ».

Pourquoi avoir pris ces deux exemples ? Tout simplement pour montrer la dimension économique et technique de la supervision. Dans un monde de brut où nous licencions au vCPU, il est important de maitriser l’allocation des ressources. Il est également important de ne pas mettre en péril son organisation quant à la sauvegarde vis à vis de son activité tout comme mettre celle-ci en péril parce que cette dernière représente un cout certain.

Dans un contexte particulier de Service Provider (Fournisseur de Service), il est également important d’avoir un curseur le plus juste possible entre la facturation client et le service délivré sans offrir des ressources sans le vouloir et vendre à perte.

Les rapports, c’est la vie.

Conclusion

La supervision et l’ensemble des outils qui sont mis à disposition par VEEAMOne permettent d’unifier et de rendre la Technique au service de l’administration et de la stratégie financière. Une telle synergie ne doit pas être négligée et doit être mis en place.

De par mon expérience de responsable informatique auprès des clients que j’ai accompagnés, l’informatique et la gestion du SI sont toujours trop onéreux. Menant souvent à l’accumulation à terme d’une dette technique conséquente qui devra être acquitter plus tard. L’erreur qui est faite à ce moment par le responsable informatique est de ne pas avoir présenté les choses sous le bon angle.

Mais alors qu’est ce que le bon angle pour éviter la traditionnelle tragédie racinienne ou choix cornélien ?

Je pense que pour répondre à cette question, il faut que le Responsable Informatique prenne de la hauteur pour présenter le SI sans aborder de terme technique pour commencer et présenter des métriques ainsi que des projections sur l’évolution du SI.

Je fais un aparté, sans déco**é une fois, j’ai un DG qui a explosé en réunion à la suite de la prononciation du mot switch xD. La personne qui avait énuméré le mot a dû donner une définition. Chose qu’il a fait en parlant de commutateur… Le DG a explosé de nouveau. Mon collègue à côté fini par intervenir (avant un nouvelle intervention de la personne en interne) en expliquant « c’est une multiprise réseaux ». Le DG a compris sans problème. 🙂 Aparté terminé.

De rapprocher ce dernier sur l’activité de l’organisation et de définir les axes d’évolutions possibles. Un plus serait de soutenir un budget prévisionnel ainsi qu’un plan d’amortissement. Présenter de cette façon en tenant compte du besoin et de l’activité de l’organisation va faciliter les décisions et permettre à la direction d’avoir une vision claire de son informatique. Mais pour en arriver là, il est nécessaire de savoir ce que nous souhaitons surveiller et interpréter. N’oublions pas que si les diseuses de bonnes aventures lisent dans les boules de cristal, les membres de la direction lisent dans les fichiers excels et les SysAdmins dans les logs. <3

Je pense qu’il est donc primordiale d’utiliser VEEAMOne (non je n’ai toujours pas d’action chez VEEAM) pour répondre aux besoins du quotidien d’un SysAdmin ainsi que pour la stratégie d’une organisation. Il faut cependant de la rigueur et ne pas se disperser dans les catégorisations et l’élaboration des rapports. L’objectif étant de maitriser son SI, se prémunir des pannes et de garantir une stratégie d’investissement financier.

VEEAM ? One ! Raviolis ? Je relance avec une requête CIM. Je contre avec un arbre ! Dommage, il y avait un DAF en diagonal. Aïe Aïe Aïe, votre SI va chercher son solde de tout compte. Mais vous gagnez un pins de Marlène SCHIAPPA. Alors heureux ?

Erwan GUILLEMARD

Sources

• VEEAM One : Guide
• VEEAM One : Guide – Ports
• VEEAM One : Supported Virtualization Platforms
• VEEAM One : Supported VEEAM BR
• VEEAM One : Supported System
• VEEAM One : Sizing
• ITOP
• RVTOOLS

1. MO : Mode Opératoire ↩︎
2. VBR : VEEAM Backup et Réplication ↩︎
3. VCC : VEEAM CloudConnect ↩︎
4. VCSA : VCenter Server Appliance ↩︎
5. RTFM : Read The Fucking Manual (please 🙂 ) ↩︎
6. RBAC : Role Based Access Control ↩︎
7. ESXi : Elastic Sky X Integrated ↩︎
8. IHM : Interface Homme Machine ↩︎
9. SNMP : Simple Network Management Protocol ↩︎
10. ITSM : Information Technology Service Management  ↩︎
11. API : Application Programming Interface ↩︎
12. ROI : Return On Investisment ↩︎

À L.LU , mon étoile, le plus parfait des sciences.

Changer les mots de passe des comptes c’est un fait, mais ensuite où les stocker ? Dans un gestionnaire de coffre fort, un excel ? Comment s’assurer que le mot de passe saisie et celui copier dans le fichier/gestionnaire est identique ?

Ca nous fait tous de même un ch*ée de question… Et je termine avec une petite dernière, en cas de compromission du support de stockage des mots de passe, quel temps nous accordons pour tout changer ?

C’est bon Père Fouras, tu as terminé ? Oui je crois. 🙂

J’ai une mélodie qui me vient en tête…

C’est petit joli c’est doux c’est fort, C’est plein de sécu… Pour l’amour l’ennui ou pour la mort. Pour éviter les pleurs. Les Passwords…
LAPS pour Windows

Un IT fan de StarMania – Lien

Nous aborderons donc comment éviter le casse tête de la gestion et le stockage des mots de passe du compte administrateur local des environnements WINDOWS (joint à un domaine) avec Windows LAPS¹.

Je n’aborderai pas la partie LAPS Legacy père de Windows LAPS.

Prérequis

• SE : Windows 2019 minimum (niveau fonctionnel/domain 2016 et plus)
• Apps : Powershell
• Autres :
  • SMTP

Avant-Propos

Dans un temps Far Far Away où WS2016 n’était pas encore présent, la gestion des mots de passe administrateurs locaux serveur et ordinateur pouvait se faire par GPO². Malheureusement, cela impliquait d’être moins regardant sur l’aspect sécuritaire du SI :

• Mot de passe en clair dans la GPO
• Pas de rotation de mot de passe
• Mot de passe identique pour tous les CIs³ lié à la GPO

Ainsi pour chaque changement de mot de passe, il fallait se connecter sur chaque serveur pour modifier ce dernier ou modifier la GPO ordinateur, appliquer la GPO etc. C’était toujours mieux que rien, toutefois cette époque est révolu et aujourd’hui il n’est pas envisageable ni concevable d’aborder la gestion des accès dans ce sens.

L’arrivée de LAPS à permis de répondre à ce point bien plus tard courant 2016. C’est en 2021 que LAPS devient LAPS Legacy. Ce dernier étant déprécié pour les SE W11 23h2. LAPS Legacy est remplacé par Windows LAPS.

De plus, si LAPS Legacy est un composant tiers à déployer sur chaque poste pour gérer le mot de passe administrateur local, Windows LAPS est dorénavant inclu directement à partir de la Tuesday Update d’Avril 2023 à partir des SEs Serveur 2019 et SEs Computer W10.

Néanmoins, pour bénéficier pleinement de toutes les fonctionnalités de LAPS, il est nécessaire d’avoir un DFL⁴ 2016 ou plus (ce qui à cette heure n’existe pas encore. Peut être avec WS 2025 ???) .

Microsoft résume tout cela dans un joli tableau.

Dans mon cas et le périmètre que je souhaite traiter, l’ensemble de mon SI est constitué de SE pris en charge par Windows LAPS (comme par hasard) et mon DFL est en 2016 (encore une coïncidence). Je ne toucherai donc pas à la parti émulation de LAPS Legacy à travers Windows LAPS (et en plus il est fainéant le gazier…).

Théories

Cette partie (sans vouloir la paraphraser et m’attribuer ce qui appartient à Caesar) relève d’un synthèse et de ma compréhension du sujet. Il est possible naturellement de sauter cette partie où de lire l’intégralité de l’article technet.

Il est également important que je vous précise (une nouvelle fois ?) que je ne traiterai pas non plus de la partie Azure AD/Entra ID. Je ne possède pas de tenant de test Microsoft O365. C’est pourquoi tous schéma d’origine abordant les composants Azures seront modifiés pour faciliter la lecture et se limiter au périmètre que je souhaite traiter.

Architecture

Une image vaut bien milles mots parait il…

Scénario Windows Serveur AD

La gestion des mots de passe administrateur locaux à travers un Serveur AD va se dérouler par GPO.

Dans mon approche, je souhaite protéger l’ensemble des ordinateurs du domaine ainsi que les contrôleurs de domaine.

Afin de garder un certain niveau de sécurité, je vais créer 3 GPOs ayant chacun un périmètre défini d’application et d’exploitation.

• LAPS_Computers : Pour la gestion des ordinateurs du domaine (comprendre poste utilisateurs) avec les droits de lecture et de déchiffrement du mot de passe aux équipes opérationnelles (Centre de service, technicien et administrateurs délégués)
• LAPS_Serveurs : Pour la gestion des ordinateurs du domaine (comprendre les serveurs du domaine hors Contrôleurs de domaine) avec les droits de lecture et de déchiffrement uniquement des administrateurs du domaines.
• LAPS_ServeursDCs : Pour la gestion des Contrôleurs de domaine avec les droits de lecture et de déchiffrement uniquement des administrateurs du domaines.

Il reste néanmoins important de garder en tête le principe fondamental de moindre privilège et d’usage lié à LAPS. Résumé trop joliment comme ci-dessous :

Une fois la stratégie configurée et appliquée, lorsque le mot de passe va expirer, un nouveau mot de passe va être générer selon les critères de complexité défini puis être stocké et chiffré dans l’AD avant d’être appliqué sur l’équipement concernée.

Question ? Comment le mot de passe est il chiffré en base ?

Il faut pour rappel avoir un DFL en 2016. Pour la suite, l’ensemble d’outil cryptographique DPAPI CNG⁵ via l’algorithme AES-256⁶ assurera de chiffrer notre mot de passe.

Il est également possible de définir un historique des mots de passe et de forcer le renouvellement du mots de passe avant la date d’expiration.

Dans la même philosophie, Windows LAPS inclus également une protection contre la falsification de compte. C’est à dire que si un outil ou un individu vient à modifier le mot de passe Administrateur local sans passer par l’AD, Windows LAPS va rejeter la tentative de modification :

• STATUS_POLICY_CONTROLLED_ACCOUNT (0xC000A08B)
• ERROR_POLICY_CONTROLLED_ACCOUNT (0x21CE\8654)

Illustré par l’évènement suivant côté poste ordinateur.

Cycle de vie

Le cycle de vie est plutôt simple. Le logigramme ci contre résume parfaitement le fonctionnement. Si le mot de passe a atteint ça date d’expiration. Le DC va générer un nouveau mot de passe selon les critères établis. Stocker ce dernier dans l’AD le chiffrer (si les prérequis sont présents) avant d’appliquer ce dernier sur l’équipement concernée. Dans le cas contraire où la date d’expiration n’est pas atteinte, aucun changement n’est réalisé.

Maintenant, je pense que nous pouvons passer à la pratique.

Pratiques

Vérifications

Vérification de la présence de LAPS sur nos DC⁷ :

> Import-Module LAPS
> Get-Command -Module LAPS

Les commandes sont bien présentes sur notre DC concernant le module LAPS. Pour autant, ce dernier n’est pas présent dans le Schéma de notre AD⁸. Il sera donc nécessaire d’ajouter celui-ci en mettant jour le Schéma.

Mise à jour du Schéma

La mise à jour nécessite d’avoir les privilèges Administrateur du Schéma. Dans le cas du respect des bonnes pratiques de sécurité, vérifier au préalable que l’utilisateur qui va être utilisé pour réaliser l’opération de mise à jour soit bien membre de ce groupe. A la fin de la mise à jour il sera nécessaire de retirer celui-ci pour des raisons de sécurité.

> Update-lapsADschema

La mise à jour du Schéma réalisée, actualisons notre console de gestion AD. Regardons les propiétés d’un objet computer.

Un onglet supplémentaire est apparu (non par magie mais grâce à la mise à jour du Schéma). L’ajout d’attribut ayant été apporté aux objets de type computer.

LAPS TAB	LAPS Attributs

Si nous rentrons dans le détails des attributs et de l’onglet ?

• Expiration actuelle du mot de passe LAPS : Date d’expiration actuelle du mot de passe. Une fois la date atteinte, le mot de passe sera changé automatiquement.
• Définit l’expiration du nouveau mot de passe LAPS : Date de la prochaine expiration du mot de passe. Il est possible de réaliser le changement du mot de passe immédiatement en réalisant une action sur le bouton Expirer maintenant.
• Nom du compte d’administrateur local LAPS : Nom du compte concerné
• Mot de passe du compte d’administrateur local LAPS : Le mot de passe du compte est defacto chiffré et ne peut être déchiffré que par les utilisateurs autorisés.

Configuration

Computers Objects

Mon avis sur le sujet est de faire la différence entre les postes utilisateurs, les serveurs divers et les serveurs AD. Soit, de réaliser une politique pour chaque rôle tiers. Il est nécessaire d’inscrire ces politiques dans la PSSI (oui c’est chiant, mais au moins comme ça c’est carré.).

Commençons par donner les autorisations aux ordinateurs membres de l’OU Rebond de venir écrire les attributs LAPS.

> Set-LapsADComputerSelfPermission -Identity "OU=Rebond,OU=Computers,OU=_root,DC=ronelab,DC=lan"

Maintenant que les permissions sont défini il est nous faut faire une petite GPO 🙂 [Ne pas oublier de copier le fichier C:\Windows\PolicyDefinitions\laps.{admx,adml} dans le magasin central]

1 – Emplacement de Sauvegarde

Il est possible de définir l’emplacement de sauvegarde du mot de passe local du compte adminitrateur dans l’AD (OnPremise) ou dans AAD (Cloud) voir le laisser désactivé.

2 – Politiques et Complexité du MDP

Nous définissons selon ce qui est décrit dans la PSSI la politique de mot de passe local ainsi que sa complexité.

Devons nous faire une distinction entre les postes utilisateurs et les serveurs par exemple ?

Il s’agit d’un compte Administrateur local donc la politique doit être la plus forte possible. Aucun besoin pour qu’un utilisateur utilise le compte d’administration local.

Pour cela j’aime bien me référer à cette image fournit par Hive SYSTEMS et repris par l’ANSSI.

Donc pour ma part, c’est 26 caractères, Majuscule, Minuscule, Chiffre et Spéciaux. J’ai choisi de faire expirer, renouveller le mot de passe tous les 30 jours.

3 – Chiffrement du mot de passe

Par défaut le mot de passe est chiffré avant d’être stocké. Toutefois, je pense (et c’est mon point de vu) que forcer l’activation est une bonne chose. Nous ne sommes jamais assez prudent.

/!\ Attention : Car le chiffrement est pris en compte pour un niveau fonctionnel Windows Server 2016. En dessous, cela ne sera pas pris en compte.

4 – Historique

Il est possible de garder un historique des mots de passe générer. Je pense par sécurité que garder 12 entrées est une bonne chose.

En lien avec la complexité du mot de passe est la fréquence de renouvellement défini, cela permet de vérifier que le changement a bien eu lieu et de remonter en cas d’avarie sur le mot de passe Administrateur local actuel à ceux défini précédemment.

365 Jours = Fq Renouvellement x Nb Retention Historique

5 – Compte Administration Local

Il nous faut spécifier le compte local dont nous souhaitons manager la rotation des mots passe.

Si le compte reste Administrateur, nous pouvons passer notre route. Toutefois cela ne représente pas selon moi une bonne pratique. Le compte Administrateur local doit être désactivé est un compte doit être créé, membre du groupe Administrateur.

6 – Habilitation, gestion des MDP

Questions, qui peut lire et déchiffrer les mots de passe ?

Par défaut c’est uniquement le groupe Administrateur du Domaine qui a ce privilège. Mais voilà, nous nous retrouvons à un carrefour sécuritaire.

Admettons (et c’est une bonne raison) que je souhaite donner les droits à mes équipes d’accéder au mot de passe chiffré des comptes administrateurs locaux des postes utilisateurs uniquement.

• Soit je fais de la délégation sur les attributs en plus de la délégation en place sur l’AD
• Soit je les passe membre du groupe Administrateur du domaine
• Soit je ne leur donne pas les droits et je surcharge l’équipe d’administration avec ce genre de requête.

Ou alors, je leurs créé uniquement les droits que pour les objets computers concernés par cette politique.

Au préalable, nous avons créé un GLS⁹ propre au déchiffrement des mots de passe ayant pour membre les utilisateurs. Récupérons l’objectSID et collons la valeur dans le champs du paramètre de la GPO Déchiffreurs de mdp autorisés.

Sauf que voilà, avec l’utilisateur qui à la délégation, cela ne fonctionne pas… Pourtant le groupe est bien le bon ?

Alors là, il suffit de RTFM. Nous pouvons faire deux constats.

• Le compte Administreur du domaine (celui que j’utilise actuellement) n’est PLUS de facto autorisé à lire les mots de passe. Donc il va être nécessaire d’ajouter le groupe Admin du Domaine comme membre de notre GLS.
• Il nous manque les autorisations de lecture sur l’OU, comme nous l’avons fait initialement. Sans quoi, le groupe n’a pas le droit de venir lire les attributs

> Set-LapsADReadPasswordPermission -Identity "OU=Rebond,OU=Computers,OU=_root,DC=ronelab,DC=lan" -AllowedPrincipals "RONELAB\GLS_SECU_LAPS_REBOND_DECRYPT"

Domain Controllers Objects

Tout comme ce que nous avons pu voir précédemment l’une des grandes puissances de Windows LAPS est la capacité de pouvoir sauvegarder et de réaliser une rotation du mot de passe DSRM pour les DCs.

Ce mot de passe n’est que trop peu modifié et même j’ose le dire quasiment jamais modifié. Cela entrainant une vulnérabilité de sécurité importante pour l’ensemble de notre SI.

Si nous regardons de nouveau les propriétés de l’un de nos ADs, nous remarquerons que l’onglet LAPS est également présent, bien que différent dans son affichage.

Définition donc notre stratégie DSRM 🙂

Attribuons les droits pour autoriser nos AD à écrire le mot de passe DSRM.

> Set-LapsADComputerSelfPermission -Identity "OU=Domain Controllers,DC=ronelab,DC=lan"

Configurons notre GPO.

1 – Emplacement de Sauvegarde

Il est possible de définir l’emplacement de sauvegarde du mot de passe local du compte adminitrateur dans l’AD (OnPremise) ou dans AAD (Cloud) voir le laisser désactivé.

2 – Politiques et Complexité du MDP

Nous définissons selon ce qui est décrit dans la PSSI la politique de mot de passe local ainsi que sa complexité.

Devons nous faire une distinction entre les postes utilisateurs et les serveurs par exemple ?

Il s’agit d’un compte Administrateur local donc la politique doit être la plus forte possible. Aucun besoin pour qu’un utilisateur utilise le compte d’administration local.

Pour cela j’aime bien me référer à cette image fournit par Hive SYSTEMS et repris par l’ANSSI.

Donc pour ma part, c’est 26 caractères, Majuscule, Minuscule, Chiffre et Spéciaux. J’ai choisi de faire expirer, renouveller le mot de passe tous les 30 jours.

3 – Chiffrement du mot de passe

Par défaut le mot de passe est chiffré avant d’être stocké. Toutefois, je pense (et c’est mon point de vu) que forcer l’activation est une bonne chose. Nous ne sommes jamais assez prudent.

/!\ Attention : Car le chiffrement est pris en compte pour un niveau fonctionnel Windows Server 2016. En dessous, cela ne sera pas pris en compte.

4 – Historique

Il est possible de garder un historique des mots de passe générer. Je pense par sécurité que garder 12 entrées est une bonne chose.

En lien avec la complexité du mot de passe est la fréquence de renouvellement défini, cela permet de vérifier que le changement a bien eu lieu et de remonter en cas d’avarie sur le mot de passe Administrateur local actuel à ceux défini précédemment.

365 Jours = Fq Renouvellement x Nb Retention Historique

5 – Compte DSRM

Le prérequis pour réaliser la sauvegarde du mot de passe DSRM dans l’AD réside dans la réalisation du point N°3 Chiffrement du mot de passe.

Alors il suffit d’activer le paramètre.

6 – Habilitation, gestion des MDP

Contrairement à la partie précédente concernant les Computers Objects, il est impensable d’ouvrir et de déléguer l’accès au mot de passe DSRM à toutes autres personnes que les membres du groupe Admin du domaine. Et quand bien même l’information doit être accessible par le mois de personne possible.

Dans mon cas, ayant mis un semblant de RBAC Tiers 3 sur l’AD, je laisserai le groupe Admin du Domain.

Une fois la GPO appliqué sur notre OU Domain Controllers, jetons un œil sur les valeurs de nos attributs LAPS (en powershell ce coup ci).

> Get-LapsADPassword -Identity "EGSRV-AD01" -IncludeHistory

With -AsPlainText	Without -AsPlainText

J’ai volontairement demandé un rotation du mot de passe manuellement. Force est de constater que tout fonctionne. Egalement, étant avec un compte Administrateur du domaine, je peux déchiffrer le mot de passe. Néanmoins, si nous ne précisons pas le classique -AsPlainText, ce dernier n’affichera que le type SecureString.

Mise en garde

Il est important de noter qu’il y a un risque à automatiser la rotation des mots de passe locaux. Surtout dans le cas des comptes DSRM. Prenons l’exemple ci-dessous.

Admettons que nous ne pouvons plus nous connecter à notre contrôleur de domaine hébergeant les rôles FSMO. Nous envisageons la procédure classique de passer par une restauration à partir du mot de passe DSRM. Nous saisissons le mot de passe et normalement nous devrions commencer à suer du CIF (et je parle pas de SQL…). Hé oui, le mot de passe a changé dans le cadre de la rotation que nous avons paramétrés. Alors que faire ?

Je me suis posé la question de vérifier s’il était possible de récupérer ce dernier depuis VEEAM dans les attributs.

Standard Objects Computers	DC Objects Computers

Pour les objets ordinateurs « standards » ou « communs », le mot de passe local est bien présent mais chiffré Toutefois, il est surprenant de se rendre compte qu’il n’existe aucun objet ordinateur dans l’OU Domain Controllers (normal au vu de la criticité du rôle et logiquement, cela reviendrait à faire une restauration du serveur lui-même en non autoritaire/autoritaire selon le scénario envisagé).

Bref, pour réinitialiser un mot de passe local pour un serveur ou un poste, nous avons toujours la bonne vieille méthode du média d’installation. Pour l’AD, c’est compromis… Restera alors à passer par un autre DC et de reset si possible le mot de passe DSRM de notre DC impacté (avec ce bon vieux ntdsutils).

Je recommande donc dans la logique de ne pas instancier la rotation des mots de passe DSRM s’il n’y a pas de procédure en place. Dans le cas contraire, il est nécessaire d’être d’une rigueur extrême dans le MCO des mots de passe.

Journalisation

Ce qui m’a tapé dans l’œil avec LAPS c’est quelques choses de très simple mais souvent négligé dans certains outils. Les actions sont loggées dans l’Observateur d’évènements ! Comme quoi il suffit certaines fois de pas grand chose… 🙂

Journaux d’applications > Microsoft > Windows > LAPS

MCO

Comme toutes solutions, c’est bien beau d’avoir une application qui sécurise et administre les comptes d’administrations locaux, mais comment s’assurer que les politiques sont bien appliquées sur les postes et qu’il n’y a pas de trou dans la raquette pouvant amené à rendre vulnérable notre SI ?

Si j’ai fait les louanges dans la partie précédente concernant la journalisation. Là c’est je pense un gros manque pour assurer un niveau de sécurité du système d’information.

Je pense qu’il existe des outils sur le net développé par d’autres SysAdmins consciencieux de leurs jobs et de leurs postes. Toutefois, et si aucune solution existe, il serait pas mal de se faire un petit outil non ? Et si cet outil nous envoyait un rapport par mail ? Ca serait merveilleux et nous pourrions hurler sans bruit !

Implémentation LAPS Audit

Dans un premier temps, il convient de définit notre infrastructure. Notre outil (script) sera exécuté directement sur le serveur AD hébergeant les rôles FSMO pour plus de sécurité.

Dans le respect des bonnes pratiques, nous bénéficions d’une infrastructure 3 tiers. Du fait de cette infrastructure nous n’autorisons pas notre tiers 0 (nos DCs) à communiquer vers l’extérieur. Pour envoyer le rapport par mail, nous utiliserons un serveur SMTP dans notre tiers 1 qui jouera le rôle de relai SMTP vers notre serveur SMTP externe.

Je considère que nous avons déjà un serveur relai SMTP configuré et fonctionnel sur notre infrastructure (Mutt ou Windows). Il sera nécessaire également de réaliser sur l’UTM les policies interlans et outbounds.

Analyse du script

Le script (SS_040_WIN_LAPS-Audit) dans sa version 1.0 est plutôt simple et comporte quatre fonctions :

getADComputersObject : Fonction qui permettra de retourner l’ensemble des objets ordinateurs joint à notre domaine. Je prends soins de faire une distinction entre les Contrôleurs de Domaines, les Serveurs et les Ordinateurs. getLAPSAudit : Fonction qui permettra de retourner les attributs Microsoft LAPS des objets ordinateurs du domaine indiquant si LAPS est appliqué sur les objets et l’échéance de rotation des mots de passe du compte Administrateur local. getLAPSHTML_Report: Fonction qui va générer le rapport HTML pour chaque objet ordinateur et l’état LAPS associé. sendSMTPMail : Fonction qui va envoyé le mail, notre rapport à notre serveur SMTP.

Il convient d’éditer le script est d’adapter les constantes suivantes :

$From : De type string, l’adresse mail de l’émetteur. Généralement le nom de votre serveur AD. $To : De type string, l’adresse mail du récepteur. $SMTPServer : De type string, le FQDN ou l’IP du serveur SMTP interne. $Port : De type int, à voir si le serveur interne accepte le protocole SMTP, SMTPS ou TLS.

Et c’est tout. Il n’y a rien d’autre à faire. Si ce n’est implémenter ce dernier. Sur notre serveur AD.

Implémentation

Avant toutes choses, la méthode reste libre quant à l’exécution de la tâche. Certains dirons j’aime faire de la MSA¹⁰, d’autre de la gMSA¹¹ et d’autres les puristes qui n’ont pas été mise à jour depuis longtemps des comptes utilisateurs restreints. (Il existe aussi une autre catégorie de SysAdmin du Dimanche qui utilisent des comptes non restreints. Mais il faut le dire doucement pour ne pas réveiller leurs impérities).

Il est important de préciser avant de prendre ma dernière aparté pour une réflexion condescendante de ma part et remplie d’orgueil que je ne suis pas dans le jugement. Le manque de compétence se corrige en se remettant en cause chaque jour. Ce qui a pour conséquence de venir palier et combler les impérities. Pour le reste, c’est toujours la question classique du « Quelle est la différence entre le bon et le mauvais SysAdmin« . Restons dans la dynamique du Plan-Do-Check-Act. 🙂

Bref, chacun voit midi à sa porte et nous sommes responsable de nos décisions et de nos choix. Je passe donc la partie compte dédié.

Sous C:\ créer un répertoire scripts avec pour sous répertoire SS_040_WIN_LAPS-Audit contenant notre script. Modifions les ACLs comme ci dessous en prenant soin de désactiver l’héritage.

Ouvrons le TaskManager et créons notre tâches.

1 – Général

Comme d’accoutumé, je reprends En nom de tâche le nom du répertoire racine du projet. Je renseigne le compte utilisateur qui va exécuter la tâche (ici un compte restreint avec une sécurité qui m’est propre). Naturellement nous n’enregistrons pas le mot de passe et nous configurons la tâche pour les Windows Server 2022 (nous sommes sur notre DC et ce dernier Dieu m’en est témoin, ce n’est pas un 2008 !).

2 – Triggers

Point un peu plus sensible et singulier, quand recevoir le rapport d’audit ? Ayant définit la rotation des mots de passe à 30 jours au plus bas, il me semble logique de réaliser un déclencheurs tous les mois.

C’est pourquoi, je configure la tâche à s’exécuter tous les Premiers Lundis de chaque mois sans échéance de fin.

3 – Actions

Call me, call me any, anytime ! Nous allons préciser que l’action a réaliser et d’exécuter notre script avec l’argument -File Path utilisant le programme powershell.exe.

4 – Conditions

Décochez ou cochez selon vos envies les conditions. Pour ma part, pas de conditions particulières.

5 – Settings

J’autorise la possibilité d’exécuter cette tâche manuellement et d’arrêter la tâche si cette dernière au bout de 3 jours. Surtout, et je crois que c’est important (du moins pour moi) de ne pas démarrer une nouvelle instance si la tâche est déjà en cours d’exécution.

En résumé, si nous attendons patiemment la prochaine exécution de la tâche planifiée ou que nous exécution manuellement cette dernière, nous devrions recevoir dans notre BAL le rapport ci-dessous.

Nous n’allons pas nous mentir et vous pouvez rameuter vos collègues FrontEnd, mon CSS et HTML sont plus que nauséeux. Mais mon avocat tiens à vous rappeler que je déteste faire du HTML et CSS, et qu’au vu de l’effort fournit vous devriez plutôt m’encourager (et initier une troisième mi-temps. Car n’oublions pas, On voit quand j’ai bu, on voit pas quand j’ai soif. <3).

Oui, il y a de quoi penser à une version 1.0.1 en ajoutant des fonctionnalités telles qu’un peu de forme, des statistiques sur le périmètre protégé par LAPS, un suivi d’Azure AD etc. Toutefois, je vais laisser un peu de temps avant de pousser ces bugs, ou features [rayer la mention utile].

GitHub

La première version stable de mon petit outils. Toutefois il sera nécessaire de suivre la partie précédente pour implémenter ce dernier.

Miaou

Conclusion

Je vais être honnête et vous dire que je me suis éclaté sur cette technologie. C’est un outil puissant, simple et complet. Le seul bémol que je pointe (et que j’ai pointé) reste la partie audit et reporting.

Il est également important de prendre avec précaution la rotation des mots de passe DSRM. Il est nécessaire d’aborder ce point dans la PSSI et de définir le rythme ainsi que tous les caractéristiques de son renouvellement et de l’emplacement de stockage de ces derniers.

N’oublions pas néanmoins que nous ne traitons que des comptes d’administration local des postes qui sont joint au domaine et non des postes, serveurs qui n’y sont pas. Il faudra en cas d’avarie définir la procédure de rotation des mots de passe et des ressources non concernés par cette automatisation d’être traitées en priorité selon leurs criticités.

L’un des points qui me frustre et que je n’ai pas détaillé car je me suis cassé les dents (pour l’instant) reste de ne pas avoir pu déchiffrer un mot de passe LAPS depuis la restauration de l’attribut VEEAM. Mais je ne désespère pas et vais y passer d’avantage de temps. Je reviendrai plus tard sur ce billet 🙂

Le mot de la fin

Le mot de passe ? Comment est votre blanquette. Caput Draconis? Nous avons un gagnant. Vous repartez avec votre point en gratin dauphinois sur un air latinos ! OH-oh-OH

Erwan GUILLEMARD

Sources

• Windows LAPS : Guide
• Windows LAPS : Concept Guide
• Windows LAPS : DPAPI CNG
• ANSSI : Politique et complexité des MDPs

1. LAPS : Local Administrator Password Solution ↩︎
2. GPO : Group Policy Object ↩︎
3. CIs : Configurations Items ↩︎
4. DFL : Domain Forest Level ↩︎
5. DPAPI CNG : DataProtection API New Generation ↩︎
6. AES-256 : Advanced Encryption Standard 256 bits ↩︎
7. DC : Domain Controler ↩︎
8. AD : Active Directory ↩︎
9. GLS : Group domain Local Security ↩︎
10. MSA : Managed Service Accounts ↩︎
11. gMSA : Group Managed Service Accounts ↩︎

Si hardened est un bien vilain mot, immuable ne vaut pas mieux. Et à chaque fois que j’ai évoqué ces termes à quelqu’un j’ai dû donner une définition.

Qui demeure inchangé, ne subit pas ou ne paraît pas subir de modification pendant un temps relativement long

Dictionnaire Larousse

Le titre de ce billet ainsi que les multiples appels du pied du précédent article technique sur VEEAM, ne laisse pas de doute quant au fil conducteur de ce feuillet technique.

Nous aborderons ici la sauvegarde dit immuable ou inaltérable pour répondre à l’un des bonnes pratiques et recommandations de la sauvegarde.

Prérequis

• SE : Ubuntu Server 20.04 LTS
• Apps : VEEAM B&R 12.1
• Autres :
  • Environnement GNU LINUX Durci
  • VEEAM B&R 12.1

Avant Propos

Le pourquoi du comment de la sauvegarde Immuable ou Hardened vient d’un constat. Avec l’évolution depuis 2015 des virus de nature cryptographique, les attaquants ne s’amusent plus à effacer toutes traces d’un SI (car c’est moins drôle de nous jours ce coup de HOCUS, POCUS) mais de chiffrer ce dernier de virer les sauvegardes et de tenir une situation de prise d’otage (sans permettre un syndrome de Stockholm) et de chantage à divulguer les données d’entreprise sur le Dark & Deep Web. Toutefois, les rançons demandées dans la grande majorité des cas sont indexées sur le CA des sociétés piègés ou de la nature critique des données extorquées…

Alors il y a bien des techniques, mécanismes pour assurer une sauvegarde hors ligne. L’une des plus vieilles à ma connaissance reste la sauvegarde sur bande (Tape). Même si cette dernière comme le langage COBOL était amené à mourir car dépassé par notre évolution technologique. Force est de constatée, que cette technologie reste l’un des mécanismes fiables pour assurer une sauvegarde hors ligne. Il y a bien la sauvegarde sur média externe (pour ne pas dire HDD) qui fonctionne très bien. Mais ce genre de solution, voyez vous, ça rentre parfaitement dans le cadre d’une PME ou d’un SI local (pour ne pas dire OnPremise) qui n’a pas un SI avec des fluctuations de stockage à la hausse. Pour résumer, comment assurer la sauvegarde déconnecté dans un datacenter ou une infrastructure qui peut être amené à grossir rapidement ?

Je vois (c’est mon point de vu. Si vous n’êtes pas d’accord, je suis prêt à échanger sur le sujet) les avantages et inconvénients suivants :

« Ouai mais qu’est ce que tu fais du Stockage Objet, des buckets toussa toussa ? C’est bien inaltérable non ? »

Oui et non. Je n’ai pas encore eu le loisir de jouer avec les stockages objets S3 ou d’autres technologies qui se base sur ce standard. Avant toutes choses, il est je pense important de se poser la question de la nature des données que nous souhaitons sauvegarder. Il y a des avantages et des inconvénients au type de sauvegarde en blocks et objets. Certains types de données sont plus favorables à l’un ou l’autre des technologies de sauvegarde. Bref, spoiler c’est un billet en réflexion et sur lequel je me dois de me motiver (à coup de grand coup de pied au c*l car je suis à l’ouest du néant en ce moment).

Bref, si nous rattrapons notre fil d’ariane, je vois dans une cloud privé un facilité à choisir la sauvegarde hardened sur un serveur dédié. Si le SI augmente et que nous devons ajouter des ressources des nœuds supplémentaires, j’ajoute un nouveau repo. Si mon SI diminue, je recycle mon serveur de repository pour un autre usage. Seul hic, cela demande de bonnes compétences en GNU/LINUX (mais cela est il vraiment un frein ? Les compétences ça s’acquiert non 🙂 ).

Pour ce billet, je vais tricher un peu. N’ayant pas de repo physique sur mon lab (et que mon lab tiens à mon poste perso), nous partirons d’un serveur virtuel qui « jouera » le rôle de notre repo physique.

Ce dernier sera sur un SE¹, Ubuntu Server 20.04 LTS² durci préalablement selon le guide de recommandation de l’ANSSI³. Un disque pour la sauvegarde est dédié, monté et formaté en XFS⁴.

Euh Question M’sieur GUIGUI ! Toi qui nous rabache du RHEL matin, midi et soir. Pourquoi d’un coup tu pars sur un Ubuntu ? Ca t’a pris comme un envie de ch**r de changer de distrib ?

A cette question, je répondrai tendrement qu’il s’agit simplement et tout bonnement des prérequis de l’éditeur VEEAM. Sinon, la question n’aurait pas eu lieu :rhel: (pour ceux qui ont connu le :noel: ).

Fin de l’avant propos, place à la lecture du menu avant de mettre un coup de fourchette.

Théorie

Attaquons donc ce menu qui nous fait tant de l’oeil. La première question que nous nous devons de poser est « Qu’est ce que l’immuabilité ? » et la seconde question, « Comment fonctionne t’elle ? »

Introduction à l’ i-mmuabilité

L’immuabilité au sens UNIX du texte existe depuis le 16 Janvier 1996. Cette commande est présente dans le paquet E2fsprogs de la release 1.02. (Si je me fourvoie, merci de me le dire car j’ai du mal à trouver l’histoire de cette dernière…).

Cette commande permet de définir des attributs complémentaires sur les systèmes de fichiers dont notamment l’immuabilité des fichiers.

Pour manipuler ces attributs, nous pouvons utiliser l’ensemble des commandes suivantes :

• chattr
• lsattr
• getattr
• setxattr

Observons ci dessous l’ensemble des commandes suivantes :

$ sudo chattr +i test.txt
$ sudo lsattr test.txt
$ sudo rm -Rf test.txt
$ sudo chattr -i test.txt
$ sudo lsattr test.txt
$ sudo rm -Rf test.txt

J’ai appliqué l’attribut d’immutabilité sur le fichier test.txt et surprise, même en élevant mes droits, je ne suis pas autorisé à supprimer le document. Cela ne sera possible qu’en retirant l’attribut. Nous tenons le début de notre mécanisme.

Ouvrez le GUILLEMARD « 

Je pense après une courte nuit de réflexion que je dédierai un article sur les attributs étendus car il y a énormément de matière sur le sujet. De plus, j’ai ouvert the PANDORAS BOX (toi aussi tu te souviens des jours anciens des LANs sur AoM ? Petit canaillou de cheater va) et je me dois de boire jusqu’à la lie ce module et l’éventail des fonctionnalités qu’il propose.

«  Fermez le GUILLEMARD

Mais alors comment cette fonctionnalité va t-elle être pilotée par notre serveur VEEAM ?

V-immutability-M

Là deux possibilités. Either you speak and read english and you can directly jump to the Veeam hardened guide. Ou alors on peut regarder ensemble ma compréhension du sujet.

Après tout, je n’ai eu que 5/20 au BAC en LV1 Anglais, ça promet d’être sympa 🙂 (Si si et j’ai même pas été au rattrapage ! Et il est content…)

Bref, nous verrons plus bas lors du déploiement que lorsque nous ajoutons notre Serveur Ubuntu en tant que Single Use Credential nous allons déployer les rôles :

• Transport : (veeamtransport) pour le service datamover (port tcp/6162)
• Installer : (veeamdeploymentsvc) pour déployer l’ensemble des composants et permettre de maintenir à jour les différents composants (ports tcp/2500

Toutefois, c’est lorsque nous déclarerons notre repository en tant que Hardened repository que cela va devenir intéressant. Car c’est à ce moment que nous allons définir les paramètres de gestion de l’immuabilité sur une période minimum de 7 jours (promis je reviendrai un jour sur la magie du nombre 7). Bref une fois configuré, voilà les services les plus importants.

• VEEAM Data Mover : Ces ce dernier qui va communiquer avec notre serveur VEEAM et récupérer les paramètres de temps quant aux datas qui doivent être inaltérables. Une fois les informations en sa possession, il réalise une passe décisive au service ci dessous VEEAM Immutability Service (veeamimmureposvc), comme la passe décisive de Djorkaeff à Thuram à la 47eme minutes du match France-Croatie en 1998 (Souviens toi du 12 Juillet 1998 !).
• VEEAM Immutability Service : Va aller mettre une patate à Jean-Pierre… Promis j’arrête, Bah Pourquoi ?… Tu vas la fermer ta grande gu***e !! Ce service va vérifier sur les chaque fichiers de backup toutes les 20 minutes les attributs immuables jusqu’à ce que le date de fin soit atteinte. Ce service est un sous service de VEEAM Data Mover.

A partir de la version 12.1.0.2131, le mécanisme change avec un control, détection sur un potentiel décalage de temps.

Lorsque le VEEAM Immutability Service démarre, un fichier timeLog va être créé sous /etc/veeam/immureposvc/. Ce fichier sera mis à jour toutes les 10 minutes.

Oui mais que se passerai t-il si la valeur du moveTime ou accelerationTime dépasse 24 heures ?

Par sécurité, les données relatifs aux opérations de rétentions seront bloqués. Un message d’avertissement remontera dans la session du job de sauvegarde. Ce qui est rassurant. Oui mais voilà, comment j’unlock la situation ? Ba en suivant le KB mon gars…

Architecture

Dans les recommandations et l’un des prérequis de l’implémentation d’un repository hardened est d’avoir un équipement dédié sans surcouche de virtualisation. Nous parlons donc de serveur et non pas d’hyperviseur.

En dehors des bonnes pratiques de configuration d’un serveur, je ne m’intéresserai qu’à la partie réseau. La configuration de la partie ILO/IDRAC/IPMI ne sera pas abordée. Pourquoi ? car je n’en ai pas envie et surtout je n’ai pas les moyens de le mettre en œuvre sur mon lab. Peut être un jour dans un autre article.

Au vu de la criticité de ce que nous souhaitons mettre en place, il nous faut dissocier la partie management de la partie sauvegarde.

Avec des équipements d’infrastructures adéquates et selon la volumétrie de datas à sauvegarder, l’agrégation d’interfaces est nécessaire. Au minima SFP+⁵, au maximum FC⁶. Assurer les performances réseaux sont un fait, toutefois si le stockage ne suit pas et génère un goulot d’étranglement (bolteneck), cela ne sert pas à grand chose.

Réseau

Bien entendu, si notre Firewall gère les liaisons supérieurs à 1 Gbits/s, il y a un intérêt de faire un VLAN dédié à l’immuabilité dissocié de la sauvegarde. Dans le cas contraire et assurer de bonne performance, il conviendra de rester dans le même subnet et de passer par commutation.

Encore une fois, si nous avons de la micro segmentation, cela facilitera grandement les choses sur un même subnet. Dans le cas contraire, il sera nécessaire de définir les règles côté repo selon les interfaces, sources et destinations avec les ports et protocoles autorisées à transiter.

Lors de la configuration du repository et donc sans restriction les flux réseaux sont les suivants :

Une fois les ressources push du serveur VEEAM vers le serveur hardened (tcp:22), le service VEEAM Installer se charge d’installer et de déployer les composants (tcp:6160). Une fois les dépendances installées, la sauvegarde se déroulera à travers le service VEEAM Data Mover (tcp:6162) ainsi que le service Mount Server (tcp:2500-3000).

Soit au final nous n’avons besoin que des flux suivants :

Ok, ça c’est pour VEEAM, mais niveau serveur physique, il n’y a pas des choses à faire ?

Bien vu l’aveugle. Il sera nécessaire d’autoriser les protocoles :

Users & Permissions

Dans l’idée, il convient d’utiliser un compte utilisateur pour la sauvegarde veeam. Ce dernier aura la charge de quelques services. Ce compte ne doit en aucun cas être membre du groupe SUDO. Il l’est uniquement lors du déploiement et lors du MCO logiciel. Ensuite les droits doivent lui être retirés.

Il en va de même que l’accès au répertoire qui va contenir les sauvegardes doivent avoir des droits restreints à notre seul et unique utilisateur VEEAM que ce soit en tant qu’utilisateur et groupe.

Les droits devant être défini sur 700.

Mouai, c’est enfoncer une porte ouverte non ? Ouai ba j’ai vu des SysAdmins faire des choses à la limite de faire voir des choses terribles à un petit garçon.

Il en va de soi, mais le sticky bit on oublie. Perso, je ne comprends qu’elle serait l’utilité du sticky bit. Mais bon, si VEEAM le précise, c’est bien que certains SysAdmins ont essayés.

Chaînes, maillons, et immutabilité

Pour assurer l’immuabilité des données de nos chaines, le mécanisme qui sera utilisé sera le même que pour la Foreward Incremental avec automatiquement une active full ou une syntetic full.

Pourquoi ? Une petit schéma s’impose.

Partons du principe que nous définissions le nombre de point d’immuabilité à 7 jours. Avec une synthétique full hebdomadaire tous les dimanches.

Sauf que voilà, il y a un problème. Le premier point immuable est une full et le dernier point avant la dernière full est une incrémental (Sunday to Saturday). L’immuabilité étant défini à 7 jours les points sont donc inaltérables tant que l’échéance du dernier point incrémental n’est pas atteint. Si la full est supprimée les incréments ne sont pas utile. Donc nous devons attendre de nouveau 7 jours pour supprimer la première chaine et la création d’une troisième full.

Nous avons pas 7 points inaltérables mais 13 points.

Une fois la full réalisée le 3 dimanches nous passons à 14 points. C’est à ce moment là, une fois la full terminée et rendu inaltérable que les 6 premières points de la chaine se verront retirés l’attribut d’immuabilité puis les maillons seront supprimés (Le principe, se base sur le Grand-Père, Père et fils).

Et puis on recommence.

Donc nous avons un minimum de 7 points de rétention et un maximum de 13 points.

Un point sur lequel je n’ai toutefois pas encore fait de test, reste le traitement de l’externalisation (backup copy). Le principe de GFS doit alors être configuré. J’essaierai plus tard.

Je pense que maintenant nous avons toutes les informations requises pour passer à la pratique. Il n’est pas impossible que certaines parties ne soient pas toutes à fait complètes. Il est difficile de tout couvrir et de ne rien oublier. Mais on peut toujours échanger pour toutes questions.

Pratique

Configuration Repository

$ sudo useradd usr.veeam
$ sudo passwd usr.veeam

$ sudo usermod -aG sudo usr.veeam

$ sudo gpasswd -d usr.veeam sudo

$ sudo gdisk /dev/sdX
   * n
   * 1
   * Paramètres par défaut
   * 8300
   * w
   * y

$ sudo mkfs.xfs /dev/sdX1

$ sudo mkdir /mnt/veeam
$ sudo mkdir /mnt/veeam/hardened_repository
$ sudo mount -o rw /dev/sdX1 /mnt/veeam/hardened_repository

$ sudo chmod 700 -R /mnt/veeam/hardened_repository
$ sudo chown usr.veeam:usr.veeam /mnt/veeam/hardened_repository

Si je n’ai rien omis, nous pouvons passer à la suite et toutes les étapes devraient bien se passer. Dans le cas contraire, je vous autorise à me donner une grande tape sur l’épaule, promis je vous dirai merci pour ne pas m’en reprendre une dizaine.

Intégration dans VEEAM

Ajout du serveur Linux

1 – Scream my Name !

Dans l’onglet Backup Infrastructure, sélectionnez ajouter un serveur. Puis ajouter un nouveau serveur Linux.

Comme ci-dessous vous avez deux possibilités. Soit vous ajoutez l’IP de votre repo (absence de serveur DNS dans mon cas et flemme d’aller faire une surcharge dans le fichier host juste pour le lab) ou d’ajouter le nom DNS. Ayant plusieurs repositories, j’aime bien mettre une petite description (surtout en l’absence de nom DNS).

2 – Linux Credential (une fois seulement)

Dans la partie SSH Connection, nous n’avons pas d’entrée dans le gestionnaire de mot de passe de notre VEEAM. Et nous ne voulons surtout pas que nos informations d’authentifications soient stockées (Sinon à quoi faire du hardened ?).

Cliquons donc sur Add et sélectionnons la dernière proposition « Single-use credentials« . Normalement vous devriez avoir l’écran ci-dessous.

Si vous avez fait les choses proprement, vous renseignez le login de votre compte utilisateur propre à VEEAM avec son petit mot de passe. Dans mon cas svc.veeam et password1234 ou azerty1234. Cochez la case d’élévation de privilège ainsi que la case « Use su if sudo fails » et là, renseigner le mot de passe du compte root.

Toujours si vous avez bien fait les choses, le compte svc.veeam est à ce moment un compte membre du groupe sudo. Donc un utilisateur à privilège le temps de l’installation. Si ce n’est pas le cas, ajoutez le :

$ sudo usermod -aG sudo svc.veeam

Pour le fun, essayer de mettre en compte utilisateur le compte root. Normalement, VEEAM devrait exprimer votre nom indien avec sa main « Dresser avec le Majeur« . 🙂

3 – Actions Review

Si vous êtes là c’est que le serveur VEEAM arrive à pu initier la connexion en SSH avec notre futur repository immuable.

Les composants transport et installer vont être déployés. Ces derniers ne sont pas déjà présent sur le serveur. Pour le moment pas un faux pas !

Passons à l’étape suivante.

4 – Jamais du premier coup 😉

Bon ba nous voilà comme un con sur un quai de gare un jour de grève à la SNCF… Ca ne fonctionne pas BORDEL ! (Pourquoi tu n’as pas censurer l’injure ? Parce que je suis frustré d’avoir durci une saloperie de système GNU/LINUX dans l’état de l’art et d’avoir des erreurs de ce type. Je suis pas une base de loisir MERDE !)

Monsieur, Calmez vous ! Oui, c’est bon. Pas de castagne. LINUX et VEEAM sont sympa car ils nous donnent gentiment le message d’insulte que l’un donne à l’autre. C’est alors qu’en bon copain nous allons arrondir les angles pour que VEEAM et notre repo LINUX puissent fleurter ensemble.

L’une des mesures de sécurité que j’applique sur mes systèmes GNU en terme de durcissement est d’interdire l’exécution sur la partition /var et /tmp. Donc un petit remove de l’argument noexec et un remount des partitions et c’est repartie comme en 40 ! (Il y a quelques choses d’autres à faire mais je le garde pour moi).

On relance un Previous, puis un Next pour relancer le déploiement. Là, à la surprise générale, l’installation se déroule sans accro.

Alors elle est pas belle la vie ?

5 – Congratulations

L’installation est terminée. Les composants ont bien été déployées nous avons ci-dessous le récapitulatif.

Toutefois, nous devons remettre en l’état les quelques points de sécurité que nous avons assouplis pour permettre l’arrimage de notre repository Hardened LINUX à notre serveur VEEAM.

• Retirer l’utilisateur svc.veeam du groupe sudo
• Rétablir les arguments noexec sur les partitions /var, /tmp
• Rétablir les paramètres que l’auteur a vraiment décider de ne pas divulger

Ajout du repository

1 – Quels types choisir ?

Choisissons le type de repository pour déclarer notre repo hardened, soit Direct Attached Storage.

2 – Linux Hardened Repository

Dans les choix, j’hésite vraiment sur l’option pour notre type de repo. Peut-être la réponse numéro 3, Linux (Hardened Repository) ?

3 – Scream my Name (Again)

On note le nom de notre repo. Tachons donc de rester logique et de choisir un nom dans le standard des repositories. Pour ma part REPO_HARDENED_01. Comme j’aurais pu avoir un REPO_SVG_01 ou REPO_EXT_01. Soignons pragmatique Père UBU par ma chandelle verte !

4 – Server Selection

Le serveur ayant été ajouté précédemment nous avons le listing de chacune des partitions présentent et montée.

Dans la liste (5ème positions) nous retrouvons bien notre partition sous /mnt/veeam/hardened_repository monté sur /dev/sdb1.

5 – Choix du repository (Path)

Sélectionnons la partition qui nous intéresse.

Activons ensuite les paramètres de clonage rapide sur les volumes XFS. Je défini la durée de l’immuabilité sur 14 jours (le minimum étant 7 jours). Je limite le nombre de tâche parallélisé à 4.

Dans les options avancées, j’ai pour habitude d’activer l’alignement des blocks pour améliorer les performances quant à la sauvegarde et à la restauration malgré une légère hausse du CPU.

J’active également le paramètre d’utiliser le paramètre per machine backup files car il améliore les performances de stockage pour les équipements qui bénéficient de flux important d’I/O. Ce qui tombe bien est notre cas.

Les deux autres options ne doivent pas être cochés, puisque nous n’avons pas de support rotatif et l’option de décompression n’est pas compatible avec la sauvegarde immuable.

6 – Where is the mount Server ?

De nouveau nous avons un petit récapitulatif des rôles à ajouter ou déjà présent sur notre repo.

• Transport
• vPower NFS
• Mount Server

Il est possible de cocher la case de recherche de chaine existante. Ce n’est pas notre cas.

7 – Applying

Nous appliquons la configuration de notre repo. Deux avertissements toutefois. Dû au durcissement de mon SE GNU/LINUX. Toutefois rien de bien méchant car on regarde l’avertissement lié au service de déploiement.

8 – Petit Résumé

Encore une fois, le petit récapitulatif nous informant que le repo a bien été créé.

Backup Job & Tests

Pour ce point, je ne vois pas de grand intérêt à décrire comme créer un jobs de backup. C’est pourquoi j’irai à l’essentiel, un en mot un seul, pour être succinct, sans détour et fioriture, bref j’irai droit au but…

Pourquoi cette entrée en matière dans cette partie ? Simplement car cela dépend de la source sur laquelle le serveur de sauvegarde se base.

• VMWare VCenter
• VMWare ESXi
• NUTANIX Prism Element
• NUTANIX Prism Central
• MICROSOFT HyperV
• VEEAM Backup Agent
• etc

La liste pourrait s’allonger comme un jour sans pain au vu du nombre de point d’entrée OnPremise et Cloud.

Dans mon cas et sur mon petit environnement de lab, ça sera sur un job de sauvegarde pour du VEEAM Backup Agent pour Windows (en Guest Processing) d’un serveur local.

Backup

Nous considérons qu’un compte d’administration est déjà présent pour la sauvegarde est durci dans les règles de l’art et que le serveur source se trouve dans la bonne configuration pour être sauvegardé.

1 – Storage

Dans la partie Storage de notre job (peut importe le type), il nous suffit de sélectionner notre repository hardened.

Le nombre de point de rétention doit être en adéquation avec la politique d’immuabilité en place comme décris dans la partie théorique. Dans mon cas 14 jours.

2 – Storage GFS

La sauvegarde hardened se base sur le principe GFS⁷. Effectivement et comme une nouvelle fois expliqué précédemment, il n’est pas possible et cela n’a pas de sens de faire de la RI⁸ mais bien FI⁹.

Je défini donc de réaliser une full backup synthétique de manière hebdomadaire, le 7 jour de la semaine, 7 jour où le Seigneur exténué (comme moi d’ailleurs) d’avoir travaillé si dure les 6 jours précédents de prendre un jour de repo. Et comme la sauvegarde est là pour nous prémunir de tout aléas

Les premiers seront les derniers, et les derniers seront les premiers

Marc 10:31

Nous pouvons faire confiance à Saint Marc. Amen.

Laissons notre job tourner et admirer les performances et actions en cours.

Tests

Une fois le job terminé avec succès. L’une de nos grandes questions que nous devons nous poser en tant que SysAdmin (et que n’importe quel client, chef d’entreprise doit se poser) est « Comment s’assurer que la chaine de sauvegarde est bien inaltérable, immuable ? »

Le plus simple, c’est de supprimer la chaine de sauvegarde ou l’une des ressources protégées. Normalement, dans la boite de dialogue se préparant à l’exécution de la suppression, vous devriez avoir un violent message d’avertissement vous informant que NON, VEEAM ne veut pas. Mais comme VEEAM n’est pas si en désaccord avec votre volonté de supprimer le backup, il vous donne toutefois la date d’échéance où il sera possible de supprimer la chaine si et seulement si le job est désactivé naturellement.

Si nous voulons allés plus loin, c’est du côté repo qu’il faudra contrôler que l’attribut d’immutabilité est bien positionné sur nos fichiers. Un petit coup de lsattr et le tour est joué.

Altérer l’inaltérable ?

Super cette sauvegarde immuable ! Avec ça, nous sommes paré à toutes éventualités contre la suppression et altération de nos chaines de sauvegarde.

Sauf que ce n’est pas tout à fait vrai. Désolé de vous mettre un stop. En haut de ce billet, j’ai insisté sur la topologie et l’architecture. Tout va reposer sur cette dernière pour ne pas altérer le contenu de votre repository hardened.

Avant de rentrer plus dans les explications, je rappel dans le contexte que le système GNU est durci. Le compte utilisateur dédié à la sauvegarde n’a pas de droit d’élévation, le daemon ssh est désactivé.

Allez, faut y aller, oui mais où ? Maintenant rentrons dans le vif du sujet.

En me connectant directement à mon repo en console ou en direct. Regardons nos différents maillons de chaines pour notre job. J’ai deux full. Pourquoi ? Parce que je suis un abruti qui lors du la configuration de mon job, j’ai oublié de chiffrer ma chaine. M’en rendant compte après coup, j’ai donc corrigé ce petit détail. Sauf que activer le chiffrement d’un job implique forcément de repartir sur un full. Merdouille non ?

Alors comment faire pour supprimer le premier maillon .vbk qui est indépendant de mon second .vbk ?

• Je suis patient et j’attends 28 jours
• Je supprime le point au niveau système et je clean ma configuration

Pour le coup je ne serai pas patient et je vais donc contourner l’immuabilité.

1. Je liste uniquement les maillons de la chaine qui sont des fulls (.vbk) afin d’identifier le point que je souhaite faire disparaitre
2. Etant en root, je retire l’attribut d’immuabilité sur le fichier
3. Je liste de nouveau les attributs des maillons de la chaine qui sont des fulls (.vbk) pour vérifier que c’est bon
4. Je supprime le fichier
5. Je liste de nouveau les attributs des maillons de la chaine qui sont des fulls (.vbk) pour vérifier que je n’ai plus qu’un fichier vbk

Nous nous déconnectons de notre console. Et regardons notre chaine côté VEEAM Ordo.

Là j’ai été un vite en besogne car j’ai déjà nettoyer la configuration. Mais notre point remontait comme inaccessible car nous l’avons supprimé (petite icone rouge et police en italique). Mais une fois nettoyé, nous avons 4 points en lieu et place de 5.

Donc il est possible d’altérer l’inaltérable sous certaines conditions.

Conclusion

La sauvegarde immuable ou hardened est vraiment une solution indispensable des organisations. Cette dernière ne doit pas être négligé. Malheureusement et c’est là un triste constat les organisations et entreprises pour des raisons de coût néglige cette protection supplémentaire.

« J’ai déjà une sauvegarde et une externalisation, je ne risque rien. Mon Service interne est parano ou Mon prestataire informatique me prend pour une vache à lait »

Ce sentiment de puissance, de confiance et d’invincibilité pourtant ne tiens qu’à un fil et c’est lorsque ça tourne mal qu’il nous reste plus qu’à pleurer en regardant comme Loth, sa femme pétrifié de sel (Genése 19:26). Attention, la facture est salée.

Toutefois, l’implémentation d’un tel système nécessite des aptitudes avancées pour les systèmes LINUX/GNU ce qui peut représenter un frein à la mise en place de ce dernier. Notamment sur la partie durcissement. A cela peut s’ajouter des budgets ainsi que des ressources limitées sur l’infrastructures ne permettant pas d’assurer cette fonctionnalité.

Il reste à moindre cout l’usage et l’implémentation d’une sauvegarde sur disque externe. Cependant je pense que cette solution est moins performante, plus espacée dans le temps, moins adapté à l’évolution du SI et soumis au risque humain (oublie, corruption, etc). Mais cela reste une solution.

Encore une fois la question de curseur se pose sur le rapport bénéfices risques. Qu’est ce que je suis prêt à accepter pour mon organisation ? Il suffit d’avoir frôlé la banque route ou d’avoir dans ces connaissances un patron qui a perdu son entreprise ou sauver de peu son business pour se sentir concerné.

Ouai mais tu nous as démontré que ce n’était pas inaltérable à 100%. Tu ne serais pas en train de nous refourguer une solution pour éviter le bug de l’an 2000 ?

Oui je conçois et l’ai démontré. Nulle solution n’est parfaite est sécurisé à 100%. Toutefois les opérations pour retirer l’immuabilité nécessite de passer plusieurs mécanismes de sécurités et le risque bien de présent est minime voir nul. Disons que si un individu malveillant s’attaque à la sauvegarde immuable, normalement l’équipe interne ou le service IT seront informés car c’est le point d’entrée le plus complexe à infiltrer. Et donc, cet individu aura pris le temps de mettre un joyeux bor**l sur l’ensemble de notre infra au préalable.

Nous pourrions également dire que 7 jours ou 14 jours d’immuabilité c’est peu. Et pourtant il faut voir cette sauvegarde comme l’as dans la manche qui nous sortira de l’échec et compromission de notre sauvegarde et externalisation. C’est une sauvegarde certes, mais la dernière carte à jouer. Sincèrement, vous SysAdmin/DSI persuadez votre DG, DAF ou PDG d’implémenter cette fonctionnalité.

Rare image d’échange entre un DAF avec un DSI/SysAdmin concernant le budget informatique

Vous DG, DAF ou PDG, écoutez votre SysAdmin/DSI et permettez lui de passer des nuits tranquilles loin des valium, tranxène, nembutal (ouai je sais ça faut beaucoup de référence à HFT, mais je suis dans ma période de vilain garnement 🙂 ).

Le mot de la fin

Consonnes, Voyelles. Je demande un 50/50 sur une garde sans. Risquez comme opération, mais ça passe et vous partez avec Maïté car votre préféré c’est le rondelé.

Erwan GUILLEMARD

Sources

• Définition Immuable
• VEEAM B&R 12.1 – Hardened Guide
• Linux – chattr
• E2fsprogs

Je remercie LLU, d’avoir su me mettre sur la voie et d’avancer sur ce sentier.

1. SE : Système d’Exploitation ↩︎
2. LTS : Long Time Support ↩︎
3. ANSSI : Agence National de Sécurité des Systèmes d’Informations ↩︎
4. XFS : X File System ↩︎
5. SFP+ : Small Form-Factor Pluggable+ (10 Gb/s) ↩︎
6. FC : Fiber Channnel ↩︎
7. GFS : Grand Father, Father, Son ↩︎
8. RI : Reverse Incremental ↩︎
9. FI : Forward Incremental ↩︎

Vous l’avez compris, je vais parler de sauvegarde et mon autorité à moi, c’est VEEAM. (Je vous rassure je n’ai pas de part, ni d’action dans cette société).

Déjà pourquoi VEEAM et pas un autre ? Je n’ai absolument rien contre les autres solutions. J’ai juste commencé avec cette solution et j’ai continué avec cette dernière ainsi que toutes la suite de produits qui gravite autour 🙂 Alors pourquoi changer une équipe qui gagne ?

Avant de rentrer dans le vif du sujet, la question que nous devons nous poser, c’est pourquoi la sauvegarder un système informatique d’un simple poste utilisateur à la totalité d’un système d’information.

Jusqu’à présent, les données étaient stockées sur des supports physiques (papier, photo, etc). Aujourd’hui la majorité de nos données sont stockées sur des supports logiques numériques dans des supports physiques (téléphone, disque dur, USB, Serveurs etc) à un endroit, voir plusieurs. Or, comment s’assurer que ces données non physiques à base de 0 et de 1 soient protégées de toutes suppressions accidentelles ? Nous allons faire une copie de ces données et les stockées autre part. Ainsi en cas de suppression ou d’avarie nous serons en capacité de les « retrouver ».

La solution VEEAM Backup et Réplication répond à ce besoin pour les systèmes d’informations. C’est pourquoi je vous propose dans ce billet de déployer un serveur de sauvegarde. (Attention et comme d’habitude, je vais suivre le guide officiel fournit par le fournisseur. Je ne compte pas réinventer la roue, mais m’attarder sur des points importants qui sont bien malheureusement négligés par certains SysAdmin).

Prérequis

• SE : Windows 2016 à 2022
• Apps : VEEAM B&R 12.1, 12.2
• Autres :
  • Média externe
  • Stockage Object
  • Stockage Hardened

Guide

L’article historiquement était trop long (+ 9500 mots pour 51 minutes de lecture) et après plusieurs remarques constructives, j’ai pris la décision de scinder en deux parties ce billet. De plus cela permettra de faciliter dans un seul article de gérer les diverses versions de VEEAM Backup et Replication à l’avenir (oui je fais parti de ces groupies qui trépignent d’impatience devant la Version 13 en devenir 🙂 ).

• Partie 1 : Théorie
  • Aborder les bonnes pratiques, l’architecture et topologies la plus adéquate pour une infrastructure VEEAM B&R. Les performances systèmes requis, ainsi que les permissions
• Partie 2 : Pratique
  • Installation et configuration de la solution. Présentation point à point de la sécurisation et durcissement de la solution VBR

Github

/!\ Attention /!\ : Le script dans sa version 1.0.2 contient deux dysfonctionnements et restent en statu béta, alpha. Il manque les blocks de descriptions des fonctions, et l’optimisation des points 7 et 10. D’autres fonctionnalités viendrons s’ajouter. Comme indiqué, le travail de R&D reste sur mon temps perso et donc ne me permet pas de « livrer »/ »mettre à disposition » une solution propre clé en main. Avant d’appliquer le script, je vous recommande un snapshot à froid de votre serveur VEEAM.

Miaou

Conclusion

C’est encore un gros billet que tu nous sors là Père GUILLEMARD ! Hé, oui mon gars ! Félicitation si t’as pas décroché entre temps. Je penserai à te donner un succès Gold ou Platinium sur le PlayStation Store 🙂

Plus sérieusement, je n’avais JAMAIS poussé aussi loin la configuration et la sécurisation d’une infrastructure VEEAM B&R. Et encore, par manque de ressource sur ma petite machine, je n’ai pas poussé le vice à déployer un WAN Accelerator et un Proxy VEEAM (m’enfin dans la logique c’est pas super compliqué il faut juste de la rigueur et du bon sens). Comme nous sommes dans la confidence, je dirai même que j’ai le sentiments d’être un imposteur quant aux infrastructures VEEAM que j’ai pu déployer. C’est un peu le fameux « Nan, mais je sais » alors qu’en réalité je ne savais pas.

VEEAM nous offre dans ces versions de nouvelles fonctionnalités toujours plus poussées et orientées sécurité. Il est difficile (par manque de temps peut-être ?) de suivre toutes ces nouvelles fonctionnalités d’une version à une autre et donc de se remettre en question et de modifier en bien nos infrastructures. Pour autant, cela fait il de moi un charlot ? Egalement ce qui doit être souligné, c’est que VEEAM en plus de prodiguer les bonnes pratiques met à disposition des outils pour suivre l’état de santé des services dans ces solutions pour rester le plus performant possible.

La sauvegarde et l’ensemble de son écosystème représente le dernier bastion des systèmes d’informations. La bonne gestion de cet écosystème permet de se prémunir de sinistre matériel, infrastructure ou d’attaques informatiques et de pouvoir repartir dans des délais acceptable selon le RTO établi. Dans le cas contraire, des mots durs et difficiles à entendre peuvent apparaitre « dépôt de bilan », « licenciement », « perte financière », « cessation d’activité »… Welcome to Amish Paradise

Il ne faut pas négliger la sauvegarde.

Et j’inviterai chaque dirigeant ou directeur des systèmes d’informations à demander un rapport d’audit de leur infrastructure de sauvegarde de manière ponctuelle. De plus les KPIs¹ de l’ensemble des jobs de sauvegardes devraient être présenté dans des rapports et revues hebdomadaires, mensuelles et annuelles.

Dans les perspectives d’évolutions et le pourquoi de cette article, VEEAM DR (ou Backup & Réplication) va me permettre de poursuivre avec d’autres articles, notamment la VCC, VSPC, Repo Hardened, Repo Stockage S3 ainsi qu’une passerelle entre VEEAM et ITOP concernant le MCO des sauvegardes journalières.

Le mot de la fin :

C’est un coup des russes ? Alerte Générale !!! Ah pardon, mais vous étiez en case mandoline. Vous reculez de 3 GFS et vous restaurez chez LAMELOISE. Pensez à la NDF.

Erwan GUILLEMARD

Sources

• Définition Sauvegarde
• FIPS
• VEEAM B&R 12.1 – ISO
• VEEAM B&R 12.1 – Guide
• VEEAM B&R 12.1 – Ports
• VEEAM B&R 12.1 – Securities Compliants guide
• VEEAM B&R 12.X – VMWare Permissions
• WINDOWS – LSASS
• WINDOWS – WPAD
• WINDOWS – WinUpdate Server

1. KPIs : Keys Performances Indicators ↩︎

• Le manque de budget pour acheter un NDD¹ et un certificat TLS/SSL²
• Un manque de compétence pour générer un certificat auto-signé

Le bât blesse hein ? Et pourtant même si un moment de honte est si vite passé, l’orgueil en prend toujours un coup. Je me suis dit que cela serait une bonne chose de rappeler le fonctionnement théorique d’un certificat. Puis le côté pratique pour générer un certificat autosigné, voir même pourquoi pas un certificat Lets Encrypt ?

Prérequis

• SE : GNU LINUX
• Apps : openssl, certbot
• Autres :

Théorie – Certificats

Déjà la première question légitime serait « Qu’est ce qu’un certificat ? » . L’une des définition pourrait être « Un fichier qui permet de garantir l’identité d’une ressource de manière singulière et permettre l’établissement d’échange d’informations de manière sécurisée. »

Il existe trois grands types de certificats SSL :

• DV (Domain Validated)
• OV (Organization Validated)
• EV (Extended Validation)

Les certificats (les vrais authentiques) sont délivrés par des AC³ qui vont vérifier la véracité des informations d’une personne ou d’une entreprise dans l’optique d’établir précisément son identité. L’AC va émettre le certificat à l’administrateur du site qui en à fait la demande. Dans le certificat, nous allons retrouver les informations suivantes :

• L’url du site, de l’ensemble des SANs⁴ ou wildcard certifiés
• Les informations de l’entreprise tel que son nom, adresse
• La clé publique
• Le nom de l’AC qui a fournit le certificat ainsi que ça signature
• La date de début et de fin de validité du certificat

Personnellement je n’ai utilisé à ce jour que des certificats DV. Bien que tous ces certificats garantissent la sécurité d’échanges d’information ils n’ont pas le même niveau d’exigence, le même cout et le même temps de création et de livraison.

DV < OV < EV

Le certificat DV fournit le niveau le plus faible niveau d’authentification. Il est facile d’obtenir un certificat dans l’heure. Lors de la demande de création du certificat, l’AC va s’assurer que le nom de domaine est bien la propriété de la personne ou de l’entreprise.

Le certificat OV va fournir un niveau de sécurité un niveau au dessus en garantissant plus précisément l’identité du certificat délivré auprès de la personne ou de l’entreprise. L’AC va reprendre les mêmes vérifications que pour le certificat DV tout en ajoutant d’autres contrôles afin de garantir de l’identité du demandeur et donc d’une confiance supplémentaire auprès des utilisateurs. Cette vérification peut être visible dans le certificat dans les attributs lié à l’entreprise.

Le certificat EV fournira le niveau de confiance le plus élevé quant à l’authentification. Lors de la demande de ce type de certificat, l’AC va reprendre les mêmes points de contrôle que pour la construction des certificats OV et DV en poussant le contrôle bien plus loin. Tel que le contrôle du numéro d’entreprise (SIRET, SIREN ect), le numéro de téléphone ect. Une fois le certificat délivré ce dernier est vu par les navigateurs comme une source de confiance maximum et gage de sécurité quant à l’organisation qui le présente.

Ok pour les types de certificat. Mais qu’en est il de la navigation entre un poste client et un site web ?

Avant d’attaquer la navigation et l’affichage d’un site web sécurisé par un certificat, le poste client va établir auprès du site web un ensemble d’opération (négociation TLS) afin d’établir une clé de session entre les deux parties pour réaliser les échanges d’informations chiffrés.

• Le poste client requête le serveur WEB
• Le serveur WEB présente son certificat au poste client ainsi que la clé publique afin d’établir une connexion sécurisée, chiffrée. C’est l’établissement de la clé de session
• Le poste client valide qu’il a confiance à l’AC dans les informations présentées par le certificat à condition que la date de validité du certificat est conforme
• La navigation peut alors débutée

Pour le reste, si ça vous intéresse, je vous laisse approfondir le sujet. Comme pour le stockage et format de disque, il serait facile de débattre et d’échanger sur le sujet durant des heures.

Intéressons nous plutôt en détails au contenu de notre certificat. Toc Toc Toc qu’est ce qu’il y a dans notre certificat (certificat.csr ou certificat.crt) ? Comme vu plus haut il contient les informations propres à notre identité physique pour garantir le niveau de confiance de notre ressource.

$ sudo cat /etc/pki/tls/certs/portail.erwanguillemard.com.crt

Bon on va pas se mentir, comment doit on lire ça ? Ma méthode Champollion date des mes derniers cours de math lorsque je déchiffrais tant bien que mal les vagues d’écritures rouges de mes professeurs « Oh le cours et le chapitre ne sont pas maitrisés, ressaisissez vous !!!! » (il y a du vrai et en toute honnêteté, j’étais malheureusement bon client de ce genre d’encouragement ?!) 🙂 Mis à part ça, sauf si vous savez décoder de tête le standard x509, vous pouvez passer par ce petit site que j’aime bien Lien et copier le contenu de notre certificat.

Ouwa la classe, il est même certifié 10 ans ! Sauf que c’est pas un « vrai » certificat. C’est un « faux » ou du moins un toléré. Au tout début de cet article j’ai parlé de certificat autosigné. Si nous reprenons les trois types de certificats disponible, il en existe un quatrième, j’ai nommé l’autosigné ou AS.

AS < DV < OV < EV

Le certificat AS est considéré comme le certificat avec le niveau de sécurité le plus faible de tous pour ne pas dire inexistant (car il chiffre les données tout de même). L’AS est considéré comme tel car comme son nom l’indique, nous n’allons pas passer par une AC tierce. L’AC c’est moi ! Et donc vous conviendrez que nous ne pouvons pas être juge et partie. Niveau confiance c’est pas top. Toutefois (car il y a un toutefois), cela est plutôt pratique pour garantir sur notre LAN le chiffrement des données entre des applications (attention, pas de publication vers l’extérieur. Sauf si vous êtes joueurs et voulez à tous prix benchmarker les performances de Pôle Emploie vs France Travail). Un exemple, un accès à une solution de ticketing, CMDB :3

Notre navigateur « n’est pas content » et il nous le fait savoir « ERR_CERT_AUTHORITY_INVALID » car il ne peut pas vérifier l’AC et donc ne fait pas confiance au certificat qui est présenté. Cela pourrait être un individu malveillant ? Bien que si nous poursuivons le navigateur nous informe que notre navigation n’est pas sécurisée, nos échanges sont bien chiffrés à travers la clé publique présente dans notre certificat.

Et si maintenant nous passions à quelques choses de plus concret ?

Pratique – Certificats

Autosigné

Comme présenté précédemment, le certificat autosigné a son avantage si l’on souhaite garantir un minimum de sécurité sur notre LAN à moindre cout.

Pour se faire nous allons dans un premier temps générer les informations de l’entité de certification « AC », certificat et clé privée. Puis nous générerons notre certificats que nous adouberons dans par NOTRE entité de confiance.

Autorité de Confiance

La commande qui suit va nous permettre de générer la clé privé de notre autorité de confiance. Passons à la loupe l’ensemble des commandes que nous allons exécuter. OpenSSL peut vite se montrer complexe et il est facile de se perdre dans les commandes quand nous ne les utilisons pas quotidiennement.

$ sudo openssl ecparam -out erwanguillemard_racine.key -name prime256v1 -genkey

$ sudo openssl req -new -sha256 -key erwanguillemard_racine.key -out erwanguillemard_racine.csr

$ sudo openssl x509 -req -sha256 -days 3650 -in erwanguillemard_racine.csr -signkey erwanguillemard_racine.key -out erwanguillemard_racineCA.crt

Certificat – portail.erwanguillemard.com

Et voilà notre AC terminée. Il ne nous reste plus qu’à recommencer les étapes pour notre certificat que nous déploieront pour notre application ITOP sous l’url portail.erwanguillemard.com. L’exception se verra lors de la génération du certificat puisque nous utiliserons notre certificat racine ainsi que notre clé racine de notre autorité de certification « homemade ».

$ sudo openssl ecparam -out portail.erwanguillemard.com.key -name prime256v1 -genkey

$ sudo openssl req -new -sha256 -key portail.erwanguillemard.com.key -out portail.erwanguillemard.com.csr

$ sudo openssl x509 -req -in portail.erwanguillemard.com.csr -CA  erwanguillemard_racineCA.crt -CAkey erwanguillemard_racine.key -CAcreateserial -out portail.erwanguillemard.com.crt -days 3650 -sha256

Nous avons donc notre certificat valide est disponible. Toutefois pour utiliser celui ci et ne pas le laisser trainer n’importe où (au vu de la criticité des informations qu’il contient), nous allons les déplacer dans les répertoires adéquates. Nous verrons ça plus bas.

Let’s Encrypt

Les certificats Let’s Encrypt sont apparu bien après mon cursus universitaire et donc je ne connaissais pas le principe. Aujourd’hui je dirais que c’est l’un des plus utilisés pour les sites vitrines. Pour rappel, le remplacement d’un certificat au delà du cout financier (variable) nécessite des actions humaines qui peuvent être conséquentes dans des infrastructures complexes. C’est pourquoi Let’s Encrypt propose de fournir gratuitement des certificats et de permettre de piloter et d’industrialiser le renouvellement de ces derniers directement sur les environnements. Cela permet également de générer facilement un certificat.

Ci-dessous, un exemple de déploiement depuis un serveur linux. Il sera toutefois nécessaire de déployer les paquets certbot ainsi que certbot pour apache.

# dnf install certbot python3-certbot-apache

Nous souhaitons générer notre certificat. Certbot va nous permettre de générer le certificat et de l’installer directement sur notre server ou de seulement générer celui-ci pour notre daemon apache. Je suis plutôt partisan de la seconde option. Je préfère ne pas faire confiance à la machine. Surtout que nous sommes en root.

# certbot certonly --apache

Le bot est sympa, il vous demande même votre adresse mail pour vous notifier de l’expiration de votre certificat en cas d’oublie. Il sera nécessaire également d’accepter les termes d’utilisations (que je n’ai pas lu naturellement comme tout le monde… Que celui qui me contredise m’offre la première bière !)

Libre à vous de dire Y pour accepter ou N pour refuser avec vos petits doigts.

Et là, et bien ça a merdé… Je vous passe les captures d’écrans d’échec critique. En voulant générer mon certificat, je n’avais pas à se moment générer mon fichier de configuration apache (mon virtualhost) et ni installer la partie web d’ITOP. Or, le certbot se base sur la configuration apache pour générer le certificat.

Conclusion, avoir un fichier de configuration valide.

Nous allons donc faire les choses bien et réaliser un enregistrement DNS pour notre site portail.erwanguillemard.com puis nous rappelons notre dernière commande.

# certbot certonly --apache

Ca ne fonctionne pas mieux… Ce qui est normal puisque mon site n’est pas joignable depuis l’extérieur car :

• Je n’ai pas de firewall (en dehors de ma box) pour faire un SNAT digne de ce nom
• Je n’ai pas la possibilité de faire un réseau de couche 2 à la maison (je donne raison à ma femme, ça reviendrait à rammener du travail à la maison. Mais j’y arriverai un jour 🙂 )
• Je n’ai pas d’ESXi (un petit vSwitch avec un groupement de port par dessus et yopi hop !)

Enfin, cela ne change rien puisqu’à la fin de cette étape, nous récupérons notre certificats ainsi que notre clé qu’il conviendra de déplacer dans les bons répertoires et de configurer notre fichier de configuration apache propre à notre site web.

Où stocker le .key et .crt

Il m’est déjà arrivé lors d’audit d’un système GNU de trouver des clés et certificats dans des répertoires qui ne devraient pas l’être. D’où la première réflexion qui me vient à ces moment là.

Qui qu’a mis ça là pis qu’a pas balayé?

Pierre BENICHOU

Effectivement, les informations sont sensibles et je crois avoir bien insisté sur ce point précédemment. En temps normal, les informations sont stockées sous /etc/pki/. Dans notre cas plus précisément dans /etc/pki/tls/.

Les certificats doivent être stockés sous /etc/pki/tls/certs/, les clés doivent être stockées quant à elles sous /etc/pki/tls/private/. Dans tous les cas les permissions doivent être 600 pour root:root.

Conclusion

Je pense que tant que faire se peut il est nécessaire de déployer des certificats. Il se pose alors la question de la criticité et de l’exposition de notre site.

Effectivement, si notre site est publié sur internet, le certificat doit être délivré par une CA afin de garantir une niveau de confiance satisfaisant. Un certificat Let’s Encrypt est également envisageable mais de mon point de vu plus à destination de site vitrine. Toutefois pour un usage interne l’utilisation d’un certificat auto-signé fait l’affaire et c’est toujours mieux que rien.

L’un des points de vigilance est de contrôler que les éléments (certificats, key etc) sont bien « rangés » dans les bons répertoires et que les droits et permissions sont bien appliqués.

Dans le cas de renouvellement de certificat, il sera nécessaire de ne pas collectionner les éléments expirés. Quand un changement est réalisé autant aller jusqu’au bout.

Le mot de la fin :

Je NAT mes congés, galoche mon CA. Ca nous ramènera pas Carlos cette histoire.

Erwan GUILLEMARD

Sources

• Certbot
• CertificateSSL Decoder
• OpenSSL – ECPARAM
• OpenSSL – x509

1. NDD : Nom De Domaine ↩︎
2. TLS/SSL : Transport Layer Security / Secure Sockets Layer ↩︎
3. AC : Authorization Certificate ↩︎
4. SAN : Subject Alternative Name ↩︎
5. EC : Elliptic curve ↩︎
6. CSR : Certificat Signature Request ↩︎
7. EC : Elliptic curve ↩︎
8. CSR : Certificat Signature Request ↩︎

Aujourd’hui, un grand nombre de site si ce n’est la quasi-totalité proposent la mise en place à ces usagers l’authentification multifactoriel (MFA) et ce à travers différents biais, mail, sms, authenticator, clé physique ect.

Depuis quelques années déjà je me suis interrogé sur la mise en place d’une telle fonctionnalité sur les environnements UNIX que je trouvais trop exposés et vulnérables.

LINUX, vulnérable ? et Windows alors t’en fait quoi pèpère ?

A cette époque j’avais 20 ans disait la chanson et il était plus facile (c’est toujours d’actualité), de déployer un petite VM LINUX avec un daemon configuré pour publier un service (xFTPx, Serveur WEB perso ect) que de monter une grosse VM Windows avec des applications tierces et une configuration chronophage. Toutefois, je laisse à chacun le choix des solutions et ne souhaite pas engager le sujet Est-ce que Linux est mieux que Windows t-elle est la question. Quelqu’un de constitution normal ne se poserait pas la question quant à la publication du protocole SSH directement sur le WWW (ou autres services à risques) de manière frontale.

Et pourtant bien qu’en 2024 il subsiste toujours ce type de publication sans Firewall, sans durcissement du système d’exploitation et sans renforcement de l’authentification sur le WWW. Dans le cas contraire, même à travers un firewall le risque subsiste.

La question bien avant d’aborder le durcissement d’un environnement LINUX dans un environnement ISO27001/HDS est donc de limiter le risque lié à l’authentification de base Login/Password.

Les puristes me diront que la MFA existe depuis longtemps à travers l’authentification par clé (privée, publique) et par passphrase. Je vois cette méthode d’authentification différemment.

Effectivement, si je ne possède pas la clé privée pas possible de m’authentifier via SSH. Donc cela répond à la MFA. Toutefois, il faut stocker la clé dans un endroit sécurisé, ne pas la perdre, ne pas se la faire voler. Ne pas l’avoir déployée sur une armada d’autres serveurs (pratique courante dans l’administration des systèmes d’informations pour faciliter le MCO).

« La sécurité ce n’est pas pratique » disait l’un de mes collègues et il a malheureusement bien raison. Je suis partisan des relation 1:1 soit d’un jeu de clé par serveur.

Pour cela je préfère donc les méthodes d’authentifications suivantes uniquement pour les comptes utilisateurs :

• Login + MFA
• Key + MFA

Rien ne justifie l’authentification direct par le biais d’un compte avec privilège, administrateur ou root. La notion d’escalade de privilège et donc de RBAC ferra l’objet d’un autre billet.

Prérequis

• SE: RHEL, DEBIAN, UBUNTU
• Apps: Google-Authenticator
• Autres: Sauvegarde fonctionnelle et/ou sauvegarde des fichiers de configurations au préalable

MFA – Google Authentificator

Installation

Rechercher et installer les paquets suivants, google authenticator et qrencode-libs.

• Le premier paquet permettra de générer les tokens de connexion toutes les 30 secondes
• Le second paquet permettra de générer le QRCode pour intégrer le code dans un gestionnaire d’authentification.

$ sudo dnf search google-authenticator 
$ sudo dnf search qrencode-libs
$ sudo dnf install google-authenticator qrencode-libs  

Configuration

Pour la phase de configuration, la majorité des actions sont à réaliser en tant qu’utilisateur et non en tant que root.

Création d’un répertoire caché .ssh dans le home de l’utilisateur 

$ mkdir ~/.ssh

Ce répertoire contiendra le fichier d’authentification propre à l’utilisateur avec les tokens générés par Google Authentificator. Cette manipulation permet de ne pas désactiver le SELinux. Ce service n’autorise pas par défaut le daemon SSHD à écrire en dehors de son répertoire dans le home des utilisateurs, c’est pourquoi nous allons configurer l’application google-authentication pour changer d’emplacement par défaut.

$ google-authentication -s ~/.ssh/google_authenticator

Activer la génération des tokens basés sur le temps. (Y)
Scanner et enregistrer le QRcode ainsi que les 5 codes de secours lorsque vous aurez saisie le code généré par l’application.   La perte de ces informations ne vous permettra plus à l’avenir de vous authentifier.   Vous pouvez également préciser l’url comme source TOIP en copiant l’URL fournit en amont du QRCode.   Mettez à jour le fichier google_authenticator (Y)
Prémunissez vous des attaques man-in-the-middle en saisissant (Y)   Ne permettez pas la durée de vie d’un token au-delà de 40 minutes une fois les 30 secondes écoulées (N)
Activer la fréquence de limitation dans le cas d’échec d’authentification au-delà de 3 tentatives (Y)

Si tu veux du challenge pour me « tipiaker » tu peux y aller à savoir que :

• La VM n’est pas publiée
• La VM est jetable c’est du LAB
• La VM est sur mon poste et pas sur une infrastructure de production
• La VM a été reconfiguré plusieurs fois
• J’ai un doctorat en paint obtenu sur Windows 95 (True story pour le SE et paint)

Une fois la configuration effectuée, réactualiser le contexte du daemon SSH dans le SELinux

$ restorecon -rv ~/.ssh/

SSH & 2FA

Avant de commencer, faite une sauvegarde des fichiers de configuration suivant (sshd et sshd_config).

$ sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.origin
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.origin

Modifiez le fichier de configuration sshd et ajouter les lignes suivantes à la fin du fichier.

$ sudo vim /etc/pam.d/sshd

auth       required     pam_google_authenticator.so secret=/home/${USER}/.ssh/google_authenticator 
auth       required     pam_permit.so

Comme nous avons modifié l’emplacement par défaut de l’apps google_authenticator, nous spécifions l’emplacement du fichier de configuration dans le home de l’utilisateur. L’avantage de cette méthode, nous pouvons générer un nouveau fichier MFA pour d’autres utilisateurs vus que le chemin appel la variable d’environnement ${USER}.
Afin de rendre optionnel la méthode d’authentification, nous pouvons préciser à la fin de la première ligne l’argument nullok.
La seconde ligne permet d’autoriser l’authentification si un utilisateur n’utilise pas la MFA dans le cas de l’utilisation nullok.

Modifiez le fichier de configuration du daemon ssh pour activer le challenge d’authentification en passant ce dernier à YES et en vérifiant que l’argument UsePAM est à YES également.

Sauvegardez le fichier.

/!\Attention : Depuis RHEL 9 la configuration est différente pour l’authentification google.
Il est donc nécessaire de spécifier le challenge d’authentification dans le fichier gauth.conf.

$ echo "ChallengeResponseAuthentication yes" > /etc/ssh/sshd_config.d/10-gauth.conf

Relancez le daemon SSH sans quitter le terminal.

$ sudo systemctl restart sshd.service

Test

Dans un second terminal, connectez vous en tant qu’utilisateur protégé par la MFA.
Saisissez le mot de passe local de l’utilisateur, puis saisissiez le TOTP.

Vous voilà authentifiés.

Conclusion

L’accès à la ressource est sécurisé via SSH ainsi que par une authentification complémentaire. Nous pouvons toujours en cas d’incident passer par l’authentification classique depuis la console système. Toutefois nous pouvons noter une limite à l’implémentation de cette fonctionnalité.

Certaines solutions tierces ne prennent pas en charge la MFA. Ce qui peux poser un problème et ce malgré la précision du NULLOK.

Dans mon cas, quatre solutions sont envisageables :

1. Présenter à l’éditeur de la solution le cas et demander si une évolution est possible. Si oui, désactiver temporairement la MFA si le risque est maitrisé et contenu
2. Etudier le remplacement de la solution Tierce et garder le niveau de sécurité en place. Attention toutefois car cela aura des couts financiers, humains
3. Désactiver la MFA si le risque est maitrisé et si rien ne peut être réalisé
4. Déployer un nouveau serveur, Appliance dédié au client ou application concernés sans fonctionnalité de MFA

Le mot de la fin :

Je vais un tour du côté de chez SWAN. Je MFA ma culotte de chasteté, j’ai perdu le codex et envie de pisser.

Erwan GUILLEMARD

Sources

• Google-authenticator
• Google-authenticator_libpam
• Qrencode

Ces Judas électroniques étaient inexistant il n’y a pas si longtemps. A défaut d’être chez soi et de lorgner dans le Judas pour vérifier qui frappe à la porte (ou s’abandonner au plaisir solitaire du commérage), nous étions bien e******s quand nous n’étions pas chez nous. D’où les systèmes d’alarmes, sirènes qui hurlent et c*****t les c******s du voisinage.

A partir de ce postulat et avec un peu d’imagination, mon domicile c’est mon serveur LINUX. Se pose la question de vérifier qui frappe à la porte, qui rentre, qui rentre pas. Qui se fait kick par Jean-Pierre, notre bon chien (plus petit que Cerbère quand même car il bouffe ce c*n) quand je ne suis pas scotché sur mon système le nez dans mes journaux de log.

Une nouvelle fois je me suis tourné vers une solution purement personnelle. Pourquoi ?

Parce que j’ai pas trouvé chaussure à mon pied…

Afin de répondre à cette question, je vais vérifier si des utilisateurs sont lock et envoyer une notification mail à l’équipe en charge du MCO du serveur. Si ça ne suffit, pas, le mail reviendra tant que le compte n’aura pas été unlock.

Plusieurs raisons peuvent être dû au verrouillage d’un compte :

• Syndrome des doigts palmés
• Oublie du login, password
• Compte non habilité à se connecter
• Tentative d’intrusion

Dans la majorité des cas, il résulte du syndrome du palmipède. Le compte est rapidement déverrouillé (par un autre compte ou par un autre biais). Dans le dernier cas, il convient d’éplucher les journaux et de mettre rapidement des mesures pour isoler et interdire les IPs sources ayant tenter de s’authentifier. D’aller consulter son Responsable Sécurité pour engager les actions nécessaires en adéquations selon le risque couru.

Prérequis

• RHEL, Debian, Ubuntu
• Mutt, cyrus-sasl-plain, Faillock

Locked Account & Notifications

Installation et configuration de MUTT

Concernant cette partie, je vous invite à parcourir la section déjà documentée dans l’article Apps – MUTT.

Configuration de Faillock

Le module faillock vient remplacer le module pam_tally2 devenu obsolète il y a un petit moment déjà. Il est présent nativement sur quasi tout les systèmes à ce jour.

Je ne traite pas volontairement dans cette partie de la politique de mot de passe. Cela fera parti d’un autre article à la limite de l’indigeste.

Il va être nécessaire de modifier les fichiers password-auth et system-auth du module d’authentification.

password-auth

Editer le fichier password-auth

$ sudo /etc/pam.d/password-auth

Ajouter les lignes suivantes dans le fichier

1) auth        required      pam_faillock.so preauth audit silent deny=5 unlock_time=900

2) auth        [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900

3) account     required      pam_faillock.so

La première ligne assure que l’utilisateur à 5 tentatives de connexion avant de voir son compte verrouillé pour une durée de 15 minutes. Nous choisissons de logger l’information et de ne pas indiquer que le compte est désactivé.

La seconde ligne indique qu’en cas d’échec de la ligne précédente, le compte sera locked.

La troisième ligne indique que le module d’authentification faillock et requis.

system-auth

Editer le fichier system-auth

$ sudo /etc/pam.d/system-auth

Ajouter les lignes suivantes dans le fichier

1) auth        required      pam_faillock.so preauth audit silent deny=5 unlock_time=900

2) auth        [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900

3) account     required      pam_faillock.so

Les explications sont les mêmes que pour le module précédent.

Test

Vérifions que les modifications apportées ont bien été prise en compte. Pour se faire nous allons vérifier l’état des comptes Valid

$ sudo faillock

Volontairement nous allons verrouiller le compte adm.r-one. Il est nécessaire d’avoir un second shell d’ouvert en parallèle pour déverrouiller le compte ou de passer par la console système en root directement.

Ou encore, en dernière option d’attendre 15 minutes.

Nous allons libérer l’utilisateur adm.r-one puis vérifier que ce dernier est bien unlocked.

$ sudo faillock --user adm.r-one --reset
$ sudo faillock

Configuration et installation du Script

J’ai toujours pour habitude de positionner mes scripts à la racine du système dans un répertoire à part avec des droits spécifiques. L’objectif étant de toujours garantir un niveau de sécurité suffisant et d’éviter une escalade potentiel des droits.

$ sudo mkdir /script
$ sudo mkdir /script/SS_027-LINUX_LockAccount

Editez le fichier ou copiez le fichier suivant : SS_027_D_LINUX_LockAccount.sh

A ce jour le fichier en version D est construit de la manière suivante :

• Les constantes
• Une fonction vérifiant l’OS
• Une fonction vérifiant les derniers logon authentifiés avec succès (utilisateurs et services)
• Une fonction vérifiant les comptes verouillés
• Une fonction pour préparer le mail
• Une fonction d’envoi de mail
• Une fonction pour forger le mail en html

Comme tous mes autres outils, les premiers échanges de mails se sont fait au format texte brut, puis pour un soucis de compréhension j’ai dû passer au format HTML…

Il est encore trop tôt pour expliquer cette aversion personnel pour le monde du web… Mais passons, il est donc possible d’envoyer les notifications sous les deux formats.

Pour le script, comme pour mon premier article sur le sujet je ne souhaite pas pour l’instant rendre ce dernier accessible à la disposition de tous.

Couvrez ce code que je ne saurais voir. Par de pareils objets les AdminSys sont blessées, Et cela fait venir de coupables pensées…

Molière 2.0

Et surtout cela me demanderai de configurer mon GitHub, de soigner mon code etc.

So, comment le code fonctionne ? De la plus simple des façons.

Le code va vérifier la version du SE, puis vérifier si des comptes sont verrouillés ou non. Si un des comptes est verrouillés, nous récupérons ces derniers. Nous récupérons la date de la dernière fois que tous les comptes se sont connectés (afin de contrôler qu’il n’y a pas de Léviator sous Racaillou). S’ensuit la préparation du mail, le « forgeage » puis l’envoi.

Dans le cas où aucun compte n’est verrouillé, le code ne fait rien.

Nous controllons les droits sur le fichier afin de s’assurer que ce dernier est bien en 700 pour root:root.

$ sudo ls -ahl /script/SS_027-LINUX_LockAccount/

Dans le cas contraire, il sera nécessaire de réaliser les opérations adéquates.

Configuration du cron

Comme nous voulons une alerte plutôt réactive, mais qui ne spam pas trop non plus, j’aime par confort définir une vérification toutes les 3 minutes. Libre à chacun de faire comme il le souhaite.

# vim /etc/crontab

Ce qui nous donne dans notre BAL, lorsqu’un compte est verrouillé la notification ci-dessous.

Conclusion

La roue a dû encore une fois être réinventée. Mais cette solution me convient et répond à mon besoin.

Nous revenons toujours sur ce curseur bénéfices, risques que cette solution apporte.

Si niveau système, la configuration et l’usage du module faillock dans les modules d’authentifications relève de la bonne pratique, ma solution pose question.

Avantages

• Suivi des alertes quasi en temps réel sur lock du compte

Inconvénients

• Utilise le compte root pour la tâche planifiée
• Repose sur un paquet, application tiers « MUTT »
• Doit être ajusté selon les SEs qui ne sont pas pris en charge
• S’assurer que le script n’est pas altéré

Au delà des axes récurrents d’améliorations, nous comptons plus d’inconvénients que d’avantages. Le point le plus bloquant selon moi est que tout repose sur le daemon assurant les notifications mails. Si le daemon vient à planter ou à être la cible d’un individu malveillant rendant ce dernier inopérant, l’attaquant a le champ libre.

Dans un sens si nous revenons à notre analogie initiale du serveur et de notre maison, l’individu malveillant nous à couper notre système d’alarme, internet et électricité ect.

Nous devons donc coupler des mécanismes de sécurité supplémentaires en amont et aval de notre serveur.

Le mot de la fin :

J’Houdini ma twingo et pars avant l’orage. Vous ne pouvez pas vous êtes faillock avec Francis Huster pendant deux madeleines

Erwan GUILLEMARD

Sources

• Faillock
• Mutt