I. Présentation

Dans cet article, nous allons nous intéresser à Sysmon, un outil qui permet une meilleure journalisation des évènements de sécurité système sous Windows. Il s'agit d'un élément indispensable pour une surveillance efficace des évènements de sécurité.

Nous allons notamment voir que les évènements Windows par défaut ne permettent pas d'avoir une détection très précise des activités systèmes et des attaques telles qu'elles sont opérées aujourd'hui, et comment Sysmon permet d'améliorer cette détection.

Nous verrons également comment l'installer et le configurer à l'aide de modèles de configuration proposés par la communauté, et analyserons ensuite concrètement les journaux produits par Sysmon.

II. Sysmon : qu'est ce que c'est ?

Sysmon (pour System monitor) est à la fois un service et un driver fournit dans le package SysInternals de Microsoft. Il vise à améliorer la journalisation des évènements Windows avec un focus sur la journalisation des évènements de sécurité système. Il s'agit plus d'un outil de détection que de prévention, dans le sens où il permet une meilleure journalisation des évènements, mais ne permet pas à lui seul de bloquer des activités malveillantes.

Depuis Sysmon 14, Microsoft a revu sa stratégie concernant Sysmon. Celui-ci peut maintenant bloquer des exécutables malveillants ("FileBlockExecutable") ainsi que la suppression de fichiers via certains outils ("FileBlockShredding"). Cette protection n'est cependant pas parfaite et ne remplace par une solution dédiée (EPP/EDR).

Pour être plus clair, voici une partie de la liste des évènements que Sysmon peut surveiller et journaliser :

• Création de processus
• Modification de l'heure de création d'un fichier
• Connexion réseau
• Modification de l'état du service Sysmon
• Fin d'un processus
• Chargement de pilote
• Chargement d'image (injection de DLL)
• Evènement CreateRemoteThread (création d'un thread par un processus)
• Evènement RawAccessRead
• Requête DNS
• ProcessTampering
• etc.

Tous ces évènements peuvent paraitre très (trop) précis pour être intéressants. Mais, tous correspondent à des attaques et modes opératoires bien identifiés et connus des attaquants. Sysmon permet alors de retracer bien plus précisément que les logs par défaut une activité malveillante sur un système.

En plus de journaliser ces évènements clés pour surveiller l'activité d'un système, il inclut plusieurs éléments importants du point de vue des équipes de sécurité et relatifs au contexte de l'évènement :

• les condensats (ou hash) des images des processus lancés
• les GUID des processus (facilite la corrélation des évènements)
• des informations précises sur les connexions réseau (processus source, adresse IP, numéro de port, etc.)
• Integrity Level du processus
• des informations relatives aux métadonnées des processus (signature, auteur, description)
• etc.

Ces différents éléments facilitent également l'investigation numérique ainsi que la recherche et corrélation d'évènements, par exemple, grâce aux IOC (Indicators of compromise) publiés par la communauté ou une équipe interne de Threat Intelligence (adresse IP, nom DNS, hash d'un binaire, etc). Rien de mieux qu'un exemple pour illustrer cela. Comparons la journalisation de l'évènement "Création d'un processus" entre les logs par défaut Windows et les journaux créés par Sysmon (cliquez sur l'image pour zoomer) :

L'eventID 1 (à droite de l'image) créé par Sysmon est beaucoup plus verbeux en contenu technique. Il fournit plus d'informations de contexte autour de l'exécution du processus. Ces informations vont notamment grandement faciliter la recherche et la détection d'activité malveillante qui ont lieu sur le système.

Il faut savoir que l'intérêt de Sysmon est aussi la journalisation d'évènements qui ne sont pas du tout journalisés par Windows (au contraire de la création d'un processus, qui est le cas le plus simple pour exposer les capacités de Sysmon). Nous verrons ensuite que, grâce à la configuration que nous allons utiliser, les TTP (Tactics, Techniques and Procedures ) relatifs à tel ou tel évènement journalisé sont aussi indiqués. Nous comprenons donc bien ici que l'intérêt de Sysmon est d'avoir des logs plus précis, orientés autour d'évènements de sécurité très importants sur un système d'exploitation et facilitant la détection et l'investigation numérique.

Enfin, comme tout élément capable de générer des journaux d'évènement, la puissance Sysmon est décuplée si ces évènements sont centralisés et analysés par une plateforme de type SIEM (ELK, Splunk, etc.) et traités par un SOC (Security Operation Center).

Le code source de Sysmon est public et peut être consulté librement. Ainsi, vous pouvez découvrir précisément comment il fonctionne : Github - Sysinternals/SysmonCommon

III. Logs Windows : quelques trous dans la raquette

Les journaux d'évènements Windows peuvent paraitre complexes au premier abord. D'apparence, ils sont assez verbeux et consultables à travers un outil de visualisation/recherche peu efficace ("Observateur d'évènements"). Il est difficile de trouver exactement ce que l'on cherche si l'on n'y est pas familier.

Également, la politique d'audit par défaut de Windows passe sous silence des évènements importants de l'activité sur le système. Pour illustrer ce constat, intéressons-nous aux journaux produits durant trois étapes d'attaque d'un système. Pour faciliter cette analyse, j'ai créé un filtre de journalisation dans l'Observateur d'évènements qui centralise tous les Event ID, peu importe leur source :

Admettons qu'en tant qu'attaquant, j'exécute le binaire "mimikatz64.exe" :

.\mimikatz64.exe

Par défaut, cette activité n'est pas journalisée comme nous le montre "auditpol.exe" :

Tel que recommandé dans le guide "Recommandations de sécurité pour la journalisation des systèmes Microsoft Windows en environnement Active Directory" de l'ANSSI, nous pouvons positionner la stratégie d'audit "Suivi Détaillé" > "Création du processus" à "Réussite". Alors, si l'on réitère la même opération, un évènement avec l'Event ID "4688 - A new process has been created" sera créé :

La moindre des choses que l'on puisse dire est que cet évènement est peu verbeux. Les seuls éléments concrets dont nous disposons sont : le nom de compte ayant exécuté la commande, le nom du processus créateur et le nom du processus. Par exemple, le simple fait de renommer "mimikatz64.exe" en "itconnect.exe" suffit à contourner l'un des principaux éléments sur lequel une détection serait possible (le nom du processus) :

Dans un second temps, je décide d'ajouter un moyen de persistance en modifiant le contenu de la clé de registre "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run". Cette clé de registre est utilisée pour lancer des binaires au démarrage (voir Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder). Il s'agit d'un moyen de persistance très connu et souvent utilisé par les attaquants, qui leur permet d'avoir une connexion vers leur serveur C2 (Command & Control) dès le démarrage du système compromis :

reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v mabackdoor /t REG_SZ /d "Z:\backdoor.exe"

J'utilise ensuite la CmdLet PowerShell "Get-EventLog" pour récupérer les évènements 4657 – A Registry Value Was Modified relatifs à la modification d'une clé de registre :

À nouveau, aucun évènement n'est journalisé par défaut sous Windows lors de la modification des clés de registre. Enfin, je vais initialiser une connexion réseau vers un serveur malveillant afin de récupérer un ransomware :

À nouveau, aucun évènement journalisé.

Comment nous le voyons à travers cet exemple, les journaux d'évènements produits par Windows par défaut ne sont pas suffisants pour tracer exactement le déroulement de mon attaque et de mon activité sur le système. Par défaut, ils ne sont pas tous activés et lorsqu'ils le sont, leur contenu n'est pas assez détaillé pour une investigation numérique efficace.

Autrement dit, si vous subissez une cyberattaque et que, par chance, vos journaux d'évènements sont préservés (externalisation, centralisation, voire sauvegarde), ceux-ci ne seront pas suffisants pour que l'équipe d'investigation numérique ou de remédiation puisse vous dire précisément ce qu'il s'est passé, par où est passé l'attaquant, quelles ont été ses actions, etc.

IV. Déploiement de Sysmon

A. Installer Sysmon de façon classique

Nous allons à présent voir comment installer Sysmon sur un système Windows (serveur ou client, la procédure est la même). Pour acquérir la dernière version de Sysmon, il faut le télécharger depuis le site de Microsoft : SysInternals - Sysmon.

Attention à bien télécharger le binaire depuis le site de Microsoft, et nulle part ailleurs.

Une fois que ce binaire est téléchargé, décompressé et présent sur notre système cible, nous allons ouvrir une Invite de commande en tant qu'administrateur, puis exécuter le binaire avec l'option "-i" :

.\Sysmon64.exe -i -accepteula

Voici la sortie attendue :

L'installation de Sysmon64 entraine notamment la création d'un service "Sysmon64" et l'installation d'un driver "SysmonDrv", dont le rôle est de capturer les évènements de sécurité côté kernel. Le driver échange notamment avec les API Windows et exploite l'Event Tracing for Windows (ETW) pour capturer les informations sur les actions qu'il souhaite surveiller.

Il est important de noter que l'installation de Sysmon est permanente, son service et son driver seront toujours présents et actifs après un redémarrage. Il peut toutefois être désinstallé simplement.

Le driver permet notamment à Sysmon d'utiliser des callbacks, aussi appellés hooks (crochet), sur des fonctions clés du système d'exploitation. Lorsqu'une fonction surveillée est invoquée, le callback associé au driver Sysmon est déclenché. À ce moment-là, Sysmon peut collecter des informations pertinentes sur l'événement en cours, telles que les détails du processus impliqué, les arguments de la fonction, les fichiers accédés, etc. Ces informations sont ensuite journalisées. On retrouve cette mécanique sur la plupart des services type EPP/EDR aujourd'hui.

Aucun redémarrage n'est nécessaire, en vous rendant dans le "Gestionnaire de tâches" puis dans "Services", vous devriez voir le service "Sysmon64" en cours d'exécution :

Vous noterez également qu'il est impossible d'arrêter ce service en tant qu'administrateur :

Cela est dû à une protection mise en place par Windows sur ce service : le Protected Process Light. Cette protection est notamment chargée de vérifier l'intégrité du code pour s'assurer que seul le code "vérifié" et "de confiance" est chargé dans le processus protégé. Ainsi, il ne peut être pris pour cible d'une injection de code ou de DLL et personne ne peut toucher à ce processus :

Grâce à cette protection, il sera plus difficile pour l'attaquant d'altérer le fonctionnement de ce processus en vue de mettre fin à la journalisation de ses actions.

Sysmon s'installe par défaut avec une configuration qui permet de journaliser certains évènements. Cette configuration par défaut peut être consultée via l'option "-s" :

.\Sysmon64.exe -s

Voici le résultat attendu :

Comme vous pouvez le voir, il s'agit d'une configuration au format XML. Celle-ci permet de définir les évènements à journaliser, leur Event ID et leur contenu. Exemple avec la journalisation de la création d'un processus :

Ici, nous voyons dans un premier temps la définition de l'event ID avec son nom et son ID ("1"). Les sections précédentes de cet article contiennent déjà un exemple d'évènement créé via cette règle, vous pourrez donc voir les champs déclarés par la configuration dans cet évènement. Par défaut, la journalisation de cet évènement est activée ("ruledefaut=include"). Ce qui n'est pas le cas de tous les évènements, exemple avec l'évènement "11 - Process Create" :

Ainsi, avec la configuration par défaut, vous ne constaterez aucun évènement avec l'ID 11 dans vos logs. Nous voyons ici qu'il faut savoir lire et comprendre cette configuration, au risque de ne pas être assez précis dans notre journalisation.

Pour visualiser les logs, ouvrez l'Observateur d'évènements, puis rendez-vous dans "Journaux des applications et des services" > "Microsoft" > "Windows" > "Sysmon".

En fonction de la configuration en place (pour l'instant, celle par défaut), vous verrez dès à présent différents évènements journalisés.

B. Installation discrète de Sysmon

Les attaquants les plus avancés vont toujours commencer par regarder quels sont les composants de sécurité en place sur un système avant de tenter d'aller plus loin dans leur compromission. Il s'agit d'une phase de prise d'information très classique, par exemple :

• Est-ce qu'un EPP (Endpoint Protection) est en place ? Ils peuvent pour cela regarder la liste des processus en cours d'exécution à la recherche de nom d'agents EPP connus (Trellix, Symantec, Sophos, etc.)
• Est-ce que Microsoft Defender est actif ? Si oui, quelle est sa configuration ? Contient-elle des exclusions intéressantes ? Sa base antivirale est-elle à jour ?
• Les journaux d'évènements sont-ils envoyés sur un autre système ? Ce qui serait le signal qu'un SIEM, voire un SOC peut enregistrer et voir son activité malveillante. L'attaquant peut pour cela regarder les processus et services actifs à la recherche d'agent de transmission de log connus, ou encore les connexions établies visant des ports connus, etc.
• Est-ce que Sysmon est installé ? Quelle est sa configuration ? Contient-elle des exclusions intéressantes ?

La réponse à ces questions permet à l'attaquant d'avoir une idée du niveau de discrétion dont il doit faire preuve pour ses prochaines opérations sur le système ou le réseau.

Cependant, Sysmon donne la possibilité aux administrateurs de dissimuler sa présence, notamment en modifiant le nom du driver et du service lorsqu'il s'exécute. Par défaut, comme nous l'avons vu, nous pouvons voir un service "Sysmon64" actif dans la liste des services en cours d'exécution :

Lors de la phase d'installation, Sysmon propose l'option "-d" pour permettre de donner un nom arbitraire au driver Sysmon (limité à 8 caractères). Quant au nom du service, il est déterminé par le nom du binaire exécuté lors de l'installation. Il nous suffit donc de le modifier avant installation :

Une fois cette opération effectuée, il sera plus difficile pour l'attaquant de détecter la présence de Sysmon sur le système :

Sur l'image ci-dessus, le processus Sysmon apparait bien comme "ITCProc". Dès lors, pour gérer le service Sysmon et par exemple, récupérer sa configuration actuelle, il faudra utiliser le binaire nommé "ITCProc.exe", l'utilisation de "Sysmon64.exe" ne fonctionnera plus.

Attention, cette méthode est une dissimulation et il existe d'autres moyens de détecter la présence du driver Sysmon (notamment via son altitude identifier).

V. Configuration de Sysmon

A. Récupération et étude d'une configuration XML Sysmon

À présent, nous allons configurer Sysmon pour qu'il journalise les évènements qui nous intéressent. La configuration par défaut est un bon départ, mais vous allez voir qu'il est possible d'aller beaucoup plus loin assez simplement.

Nous allons notamment nous baser sur des configurations connues et éprouvées créées par la communauté de la cybersécurité. La configuration la plus connue est celle proposée par SwiftOnSecurity, consultable et téléchargeable ici : Github - SwiftOnSecurity :

Cette configuration comporte plusieurs intérêts :

• Elle est éprouvée par la communauté et sa pertinence est reconnue. Vous pouvez notamment jeter un œil à son historique de modification Github.
• Elle est documentée, même si la lecture de son contenu peut être difficile à cause du format XML, elle contient différents commentaires permettant de comprendre ses principales sections, exclusions
• Elle est bien structurée, ce qui permet une compréhension et une modification aisée. Elle peut ainsi servir de base à une configuration propre à vos besoins et environnements
• Elle contient des cas d'exclusions permettant d'éliminer les faux positifs "classiques" sur les OS Windows, facilitant ainsi l'exploitation des journaux créés par Sysmon.
• Elle apporte des éléments de contexte supplémentaires sur chaque Event ID tels que les TTP du MITRE relatif à une action malveillante journalisée.

Bref, utiliser cette configuration apporte une réelle plus-value par rapport à celle par défaut et un gain de temps qui évite d'avoir à concevoir sa propre configuration XML, avec les difficultés que le format et la complexité des uses-case apportent. Avant de l'appliquer, je vous recommande tout de même de finir la lecture de cet article, puis de lire en détail le contenu de la configuration XML, afin que vous sachiez exactement ce qui sera journalisé et ce qui sera exclu de la journalisation.

B. Application d'une nouvelle configuration Sysmon

Il nous suffit donc de télécharger cette configuration XML puis de l'appliquer à Sysmon, nous pouvons utiliser l'option "-c" :

.\Sysmon64.exe -c .\sysmonconfig-export.xml

Voici la sortie attendue :

Pour vérifier que notre configuration est en place, nous pouvons utiliser l'option "-c" de "Sysmon" :

Les éléments de configuration affichés sont à présent très différents et bien plus verbeux que la configuration par défaut de Sysmon.

Nous pouvons à tout moment revenir à la configuration par défaut avec l'option "-c --".

C. Suppression du fichier de configuration

Maintenant que nous avons appliqué notre configuration à Sysmon, il est très important de ne pas laisser le fichier de configuration persister sur le système sous la forme d'un fichier XML. Si l'attaquant accède à ce fichier, il aura la possibilité de comprendre en détail les règles de détection en place, incluant ses potentielles exclusions et exceptions. Ainsi, il pourra construire une attaque qui exploite ou contourne les règles configurées.

En cela, il est mieux de laisser l'attaquant dans le noir et de supprimer cette configuration du système. Attention à ne pas non plus la laisser accessible sur un partage réseau trop ouvert auquel l'attaquant pourrait avoir accès.

Même si le fichier de configuration initial a été supprimé, Sysmon aura toujours cette configuration à disposition. Lors de l'import d'une configuration avec l'option "-c", Sysmon transforme cette configuration XML en blob de données et le stocke dans une clé de registre :

Ce blob de donnée n'est pas facile à parser et l'attaquant aura du mal à récupérer en clair les règles et exclusions de la configuration à partir de celui-ci.

VI. Exemple de journaux Sysmon

Comme nous l'avons vu, les journaux d'évènements Sysmon sont stockés dans "Journaux des applications et des services" > "Microsoft" > "Windows" > "Sysmon". Si je réitère mon activité malveillante initiale (celle qui n'avait pas été ou peu journalisée par les logs par défaut de Windows) : voici ce que je peux voir dans les logs Sysmon (cliquez sur l'image pour zoomer) :

Nous voyons clairement dans les logs : un event ID 1 - Process Create, un event ID 13 - Registry value set et and event ID 3 : Network Connecion detected. Ce qui correspond et retrace exactement les activités malveillantes réalisées sur le système. Dans la capture ci-dessus, nous avons les détails de l'exécution de "mimikatz64.exe", déjà exposé précédemment dans cet article. On peut noter la présence de nombreuses informations, dont le hash MD5 du binaire, qui ne changera pas en fonction du nom qui lui est donné (bien que des méthodes simples permettent de modifier ce hash pour qu'il ne colle plus aux signatures classiques).

• Pour en savoir plus sur ce qu'est un hash MD5, je vous oriente vers notre article : Gestion d’empreinte numérique sur Linux

Nous pouvons également regarder le contenu de l'évènement relatif à l'ajout d'une valeur dans une clé de registre :

À nouveau, nous avons un grand nombre d'informations à propos de l'évènement, le processus parent, le nom de la clé de registre modifiée, sa valeur, on y retrouve clairement l'exécutable malveillant, etc. Vous remarquerez également la présence du "T1060" dans l'attribut "RuleName", il s'agit de l'identifiant du TTP relatif à cette action malveillante. Cet ajout provient de la configuration SwitfOnSecurity et vise à aider l'analyste à comprendre la nature et l'impact d'un évènement de sécurité.

Pour mieux comprendre l'intérêt et les bénéfices de cette information, regardons par exemple le contenu du TTP T1060 sur le site du framework MITRE ATT&CK (le framework ayant été mis à jour récemment, l'action au TTP 1060 rédige vers son nouvel identifiant : T1547.001 - Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder ):

Il ne s'agit là que d'un extrait, mais l'on comprend ici bien plus en détail les enjeux de cet évènement : l'attaquant a cherché à établir une persistance sur le système en modifiant une clé de registre contenant des binaires exécutés au démarrage.

Enfin, voici l'évènement relatif au téléchargement d'un binaire malveillant depuis un serveur appartenant à l'attaquant, action qui n'était pas du tout journalisée par les logs par défaut de Windows :

Là aussi, nous obtenons des informations claires et précises sur l'évènement, notamment l'IP, nom et port de destination, qui sont des informations importantes en termes de détection (grâce aux IOC) et d'investigation.

Pour mieux comprendre chaque évènement produit par Sysmon, nous pouvons utiliser la documentation Microsoft, qui référence précisément les eventID et leur définition : Sysmon - Events

VII. Conclusion

J'espère que cet article vous a aidé à mieux comprendre ce qu'est Sysmon, son utilisation standard ainsi que sa plus-value pour la sécurité d'un système Windows et plus globalement du système d'information. Nous n'avons pas fait un tour complet de l'outil, notamment en ce qui concerne les évènements plus techniques (CreateRemoteThread, RawAccessRead, Process Tampering, etc.), ni la construction complète d'un fichier de configuration avec ses exclusions, exceptions, etc. Mais, le contenu de l'article devrait être suffisant pour mettre en place et utiliser Sysmon au sein de votre système d'information.

Ce qu'il est important de retenir au-delà de Sysmon est l'importance d'avoir une journalisation la plus complète et précise possible concernant les évènements de sécurité, puis d'être capable de la centraliser (SIEM) et de surveiller activement et comprendre ces différents évènements. Dans cette démarche macro, Sysmon n'est finalement qu'un point de départ.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

The post Windows : utilisation de Sysmon pour tracer les activités malveillantes first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à capturer une image de référence Windows 11 23H2 avec MDT. Cette image, préparée par nos soins, pourra ensuite réutilisée en tant que master afin d'être déployée sur un ensemble de machines de votre parc informatique.

• Cliquez ici pour regarder la vidéo sur YouTube

La méthode que nous allons employer aujourd'hui consiste à :

1 - Prendre une machine Windows 11 qui servira de référence. Sur cette machine, nous pouvons modifier la configuration du système, installer des applications, déposer des fichiers de configuration, etc... Selon les besoins

2 - Capturer cette machine avec MDT afin que l'image Windows dans son intégralité (système + applications) donne lieu à une image WIM

3 - Ajouter cette image WIM à la liste des systèmes d'exploitation de MDT

4 - Déployer cette image de référence, qui est notre master, sur X ordinateurs

Ceci permet d'avoir une image prête à l'emploi, avec tous nos prérequis, ce qui en fait un master sur-mesure. Néanmoins, préférez autant que possible le déploiement d'applications par l'intermédiaire de MDT : ceci est la recommandation, et c'est aussi plus simple pour gérer les versions que vous souhaitez déployer, car l'image WIM capturée est figée (même si nous pouvons toujours agir dessus via les étapes de post-installation).

Dans certaines situations, cette méthode s'avère très utile, voire indispensable, et permettra d'éviter bien des galères aux équipes IT... Surtout, elle permettra de gagner un temps fou. Lors d'une précédente expérience, j'ai eu de nombreuses applications spécifiques à installer sur des machines, du style AutoCAD, Revit, Cadwork, etc... Elles sont à la fois lourdes et difficiles à déployer de façon silencieuse. De ce fait, les applications étaient installées sur une machine Windows 11, puis l'image capturée, ce qui permettait d'avoir une image prête à l'emploi avec ces applications préinstallées.

Voici quelques ressources complémentaires :

• Déployer Windows 11 23H2 avec MDT
• MDT - Intégrer les machines à l'Active Directory

II. Préparer la machine de référence

Pour cette démonstration, une machine sous Windows 11 Pro 23H2, déployée par l'intermédiaire de MDT (via la procédure décrite dans le précédent tutoriel) sert de point de départ.

Pour simuler quelques changements sur le système, je procède à l'installation de deux applications : la suite LibreOffice et VLC Media Player. Vous pourriez également décider de durcir la configuration du système à l'aide d'un outil comme HardeningKitty.

En complément, les VMware Tools sont installées dans la VM. Ainsi, lorsque cette image sera capturée puis de nouvelles VM déployées, elles bénéficieront directement des VMware Tools.

Ceci n'est qu'un exemple afin d'avoir un "master" à capturer. De votre côté, faites ce dont vous avez besoin.

Remarque : vous ne devez pas chiffrer la machine de référence avec BitLocker, sinon la capture échouera.

III. Les permissions sur le DeploymentShare

Si vous avez suivi notre tutoriel sur l'installation de MDT pour déployer Windows 11, vous avez créé le compte "Service_MDT" et vous lui avez attribué des permissions en "Lecture seule" sur le partage DeploymentShare. En fait, il s'agit de l'utilisateur déclaré dans les paramètres de MDT et utilisé par le LiteTouch (WinPE) pour se connecter au DeploymentShare.

Nous devons modifier les permissions car l'utilisateur doit pouvoir écrire dans le répertoire "Captures" afin de venir écrire l'image WIM.

Modifiez les permissions de partage :

1 - Effectuez un clic droit sur le dossier du DeploymentShare puis cliquez sur "Propriétés". Cliquez sur l'onglet "Partage" puis sur "Partage avancé".

2 - Cliquez sur le bouton "Autorisations".

3 - Sélectionnez l'utilisateur dans la liste, ici "Service_MDT".

4 - Attribuez la permission "Modifier" à cet utilisateur.

5 - Validez avec "OK".

Modifiez les permissions sur le système de fichiers NTFS :

1 - Cliquez sur l'onglet "Sécurité".

2 - Cliquez sur "Modifier".

3 - Sélectionnez l'utilisateur "Service_MDT" dans la liste.

4 - Attribuez la permission "Modification" à cet utilisateur.

5 - Cliquez sur "OK".

Voilà, cette étape est terminée.

IV. Créer une tâche Sysprep and Capture pour Windows 11

À partir de la console Deployment Workbench, créez une nouvelle séquence de tâches (via un clic droit sur "Task Sequences"), dans votre DeploymentShare.

Commencez par nommer cette séquence de tâches, par exemple "Capturer Windows 11" et poursuivez.

Lors de la sélection du template, choisissez "Sysprep and Capture".

À l'étape suivante, prenez une image système correspondante à la version que vous allez capturer. Mais, je crois que cela n'a pas de réelle importance puisque nous allons capturer notre image complète par la suite.

Poursuivez jusqu'à la fin... Tout en sachant que ces informations seront écrasées par la future tâche de déploiement de l'image.

Finalisez la création de la séquence de tâche.

Avant d'aller plus loin, accédez aux propriétés de votre DeploymentShare, puis dans l'onglet "Rules", assurez-vous d'avoir la ligne suivante :

SkipCature=NO

Sinon, l'assistant ne vous permettra pas de lancer la capture car l'étape de capture sera masquée.

En complément, si vous avez configuré le CustomSettings pour l'intégration au domaine Active Directory, vous devez commenter les lignes correspondantes, sinon l'étape "Capture Image" de l'assistant LiteTouch ne s'affichera pas (il s'agit probablement d'un bug). Une fois la capture effectuée, vous pouvez "réactiver" ces lignes.

V. Capturer image Windows 11 23H2 avec MDT

A. Démarrer la capture de l'image de référence

Désormais, nous allons initier la capture de l'image Windows 11. Vous ne devez pas démarrer en boot PXE sur le LiteTouch pour cette étape. À partir d'une session, sur la machine Windows 11 à capturer, accédez au DeploymentShare de votre serveur MDT.

À partir du nom ou de l'adresse IP. Puis, dans le répertoire "Scripts", exécutez le fichier "LiteTouch.vbs".

\\SRV-WDS\DeploymentShare$\Scripts
\\192.168.14.11\DeploymentShare$\Scripts

Actuellement, vous êtes toujours sur Windows 11, connecté à la session, et le LiteTouch démarre !

Sélectionnez la séquence de tâche "Capturer Windows 11" créée précédemment puis continuez.

Choisissez "Capture an image of this reference computer". Vous pouvez éventuellement donner un nom personnalisé à l'image WIM. Ici, la capture va générer l'image "CAPTW11-01.wim".

Continuez jusqu'à la dernière étape puis cliquez sur "Begin".

B. Le Sysprep

Le LiteTouch va commencer par initier un Sysprep sur la machine Windows. Cette étape est cruciale car Sysprep efface toutes les informations spécifiques à la machine : le SID, le nom de l'ordinateur, etc... Afin de préparer la machine au clonage ou à la création d'une image de référence (notre cas).

Patientez...

Le Sysprep est l'étape la plus délicate, disons.

Il y a régulièrement des plantages à cette étape, notamment à cause des applications Appx provisionnées dans une session et pas dans une autre. Si vous rencontrez une erreur, consultez ce fichier journal :

C:\Windows\System32\sysprep\Panther\setupact.log

Vous pouvez constater des lignes comme celle-ci :

SYSPRP Package <Nom du package> was installed for a user, but not provisioned for all users.

Dans ce cas, vous devez utiliser PowerShell pour essayer de faire le nettoyage nécessaire. Ceci peut bloquer sur une première application, puis sur une deuxième, donc consultez bien les logs si l'erreur revient après avoir fait le nécessaire.

Remove-AppxPackage -Package <Nom du package>

Pour lister les paquets de Microsoft, vous pouvez utiliser cette commande :

Get-AppxPackage -AllUsers | Where PublisherId -eq 8wekyb3d8bbwe | Format-List -Property PackageFullName,PackageUserInformation

Si vous ne parvenez pas à supprimer le paquet, essayez des commandes en supplément :

Get-AppxPackage -AllUsers <Nom du package> | Remove-AppxPackage -AllUsers
Remove-AppxProvisionedPackage -Online -PackageName <Nom du package>

Vous pouvez consulter cette page de la documentation Microsoft puisqu'elle aborde ce sujet.

Quand le Sysprep sera terminé et effectué avec succès, la machine va redémarrer.

C. Création de l'image WIM

Au redémarrage, la machine va automatiquement poursuivre la capture et procéder à la création de l'image WIM. Ceci signifie que l'image WIM est envoyée dans le répertoire "Captures" de votre DeploymentShare.

Patientez jusqu'à la fin... Ici, la capture s'est déroulée sans problème !

Sur le serveur MDT, il y a bien une nouvelle image WIM. Son poids est d'environ 9,4 Go.

VI. Ajouter l'image de référence à une séquence de tâches

Nous avons fait la capture de notre image de référence, c'est bien, mais comment l'utiliser ? Comment déployer cette image sur des ordinateurs ?

A. Importer l'image WIM dans MDT

Tout d'abord, nous devons importer l'image WIM dans MDT, en tant qu'image de système d'exploitation.

Sur "Operating Systems", effectuez un clic droit et cliquez sur "Import Operating System".

Un assistant s'exécute. Choisissez "Custom image file" comme type d'OS.

Puis, à l'étape "Image", cliquez sur "Browse" pour sélectionner l'image WIM générée par la tâche de capture. Cochez également l'option "Move the files..." pour que l'image WIM soit déplacée dans le répertoire "Operating Systems" de votre DeploymentShare. Sinon, elle sera copiée et elle occupera deux fois plus de place sur votre serveur...

Poursuivez jusqu'à la fin en suivant l'assistant... Il n'est pas nécessaire de changer les autres paramètres, si ce n'est nommer le répertoire de destination.

Voilà, l'image WIM est importée !

B. Associer l'image WIM à une séquence de tâches

Désormais, nous allons associer l'image WIM capturée à une séquence de tâches dans le but de la déployer sur des appareils. Vous pouvez créer une nouvelle séquence de tâches, ou éditer une séquence de tâches existante. Ici, nous allons éditer la tâche "Déployer Windows 11 Pro 23H2".

1 - Rendez-vous dans "Task Sequences".

2 - Double-cliquez sur la séquence de tâches à modifier.

3 - Cliquez sur l'onglet "Task Sequence" pour accéder à la liste des tâches.

4 - Sous "Install", cliquez sur la tâche "Install Operating System".

5 - Sur la droite, cliquez sur "Browse", ceci vous permet de choisir l'image WIM à déployer !

Sélectionnée l'image correspondante à votre capture :

Validez. Vous pouvez cliquer sur "OK" car c'est la seule modification que nous devons apporter à la séquence de tâches.

VII. Déployer l'image de référence avec MDT

Tout est prêt, nous n'avons plus qu'à tester cette nouvelle configuration !

Prenez une machine sur laquelle tester le déploiement... Pour ma part, ce sera une nouvelle machine virtuelle. Puis, démarrez en boot PXE pour charger l'image LiteTouch de votre MDT.

Vous voilà sur l'écran "Task Sequence" où vous pouvez sélectionner la tâche "Déployer Windows 11 Pro 23H2" à laquelle est rattachée l'image WIM de référence.

Suivez les prochaines étapes pour associer un nom à la machine, etc... Puis lancez le déploiement !

Voilà, le déploiement est terminé ! Nous avons une nouvelle machine déployée à l'aide de notre image de référence ! Les applications LibreOffice et VLC Media Player sont bien présentes, tout comme les VMware Tools !

VIII. Conclusion

En suivant ce tutoriel, vous devriez être en mesure de capturer une image de référence personnalisée avec MDT, pour créer votre propre master sur-mesure à déployer sur les machines de votre parc informatique !

The post MDT – Comment capturer et déployer un master Windows 11 23H2 ? first appeared on IT-Connect.

Vous utilisez Microsoft Edge sur Windows Server et il se ferme au bout de quelques secondes ? Sachez que vous n'êtes pas le seul et que ce problème serait lié à la version 123 du navigateur Edge. Faisons le point sur ce problème.

La Build 123.0.2420.53 de Microsoft Edge semble donner du fil à retordre aux administrateurs systèmes qui exploitent ce navigateur sur Windows Server. En effet, cette version ne semble pas fonctionner correctement : une page blanche s'ouvre au démarrage, puis quelques secondes plus tard, le navigateur se ferme tout seul. Ceci peut s'avérer très problématique sur certains serveurs, notamment les hôtes de sessions Bureau à distance (RDS) où les utilisateurs se connectent directement !

Ce problème fait suite à l'installation de la version 123.0.2420.53 sur Windows Server. Une version disponible depuis quelques jours sur Windows et Windows Server puisqu'elle a introduit le canal Stable de Microsoft Edge le 23 mars 2024.

Comment résoudre ce problème ?

Actuellement, la solution consiste à revenir en arrière, c'est-à-dire sur une version antérieure de Microsoft Edge. D'ailleurs, sur le forum de Microsoft une ligne de commande a été fournie par un utilisateur pour expliquer comment revenir en arrière à partir du package MSI d'une précédente version d'Edge grâce à l'utilisation du paramètre "ALLOWDOWNGRADE=1" :

msiexec /I Microsoft Edge_122.0.2365.106_Machine_X64_msi_en-US.msi ALLOWDOWNGRADE=1

Vous pouvez télécharger la version de Microsoft Edge de votre choix à partir de cette page. Sur la page du forum Microsoft, l'agent qui a répondu confirme que d'autres utilisateurs ont rencontré ce problème ! D'ailleurs, ces dernières heures, Microsoft a retiré cette mise à jour de son catalogue et elle n'est plus distribuée via WSUS : preuve qu'il y a un réel problème avec celle ! En attendant, si elle est déjà passée sur vos serveurs, vous risquez de rencontrer ce problème !

Et vous, rencontrez-vous ce bug sur Windows Server ?

PS : merci à Fabien Guérout de chez Délibérata (un ancien collègue !) de m'avoir signalé ce dysfonctionnement et confirmé que le downgrade vers une version antérieure permettait de corriger ce problème !

The post Sur Windows Server, Microsoft Edge 123 ne fonctionne plus ! Que se passe-t-il ? first appeared on IT-Connect.

Depuis plusieurs jours, le sujet affole les administrateurs systèmes : la mise à jour de mars 2024 pour Windows Server fait planter les contrôleurs de domaine à cause d'une fuite mémoire liée au processus LSASS. Microsoft vient à la rescousse de ses utilisateurs grâce à un correctif qui corrige le problème ! Voici ce qu'il faut savoir !

Rappel : les serveurs se figent et redémarrent suite à l'installation de la mise à jour de mars 2024 pour Windows Server (Windows Server 2022, Windows Server 2019, Windows Server 2016 et Windows Server 2012 R2). Ce problème a été constaté sur les contrôleurs de domaine Active Directory. Assez rapidement, Microsoft a confirmé l'existence de ce problème étant à l'origine d'une fuite de mémoire extrême pouvant faire planter le processus LSASS. L'entreprise américaine a également confirmé que les mises à jour publiées le 12 mars 2024 à l'occasion du Patch Tuesday étaient à l'origine de ce dysfonctionnement.

Le vendredi 22 mars 2024, Microsoft a publié de nouvelles mises à jour en urgence pour venir en aide aux administrateurs systèmes et aux organisations impactées. En effet, jusqu'ici, la seule "solution" était de ne pas installer la mise à jour cumulative, ou de la désinstaller afin de revenir en arrière.

La liste des correctifs de Microsoft

Voici la liste des correctifs proposés par Microsoft :

• Windows Server 2022: KB5037422
• Windows Server 2019 : KB5037425
• Windows Server 2016: KB5037423
• Windows Server 2012 R2: KB5037426

Au sein de l'article de support qui accompagne chaque mise à jour, Microsoft précise : "La fuite de mémoire se produit lorsque les DC Active Directory sur site et dans le Cloud traitent les demandes d'authentification Kerberos. Cette fuite importante peut entraîner une utilisation excessive de la mémoire. De ce fait, LSASS peut cesser de répondre, et les DCs redémarreront lorsque vous ne vous y attendez pas."

Vous devez installer cette mise à jour sur les contrôleurs de domaine Active Directory concernés par le bug lié à la mise à jour de mars 2024. Il n'est pas nécessaire d'installer la mise à jour de mars 2024, puis celle-ci ensuite, puisqu'il s'agit d'une mise à jour cumulative : installez directement celle-ci, dans tous les cas, et Windows Server installera uniquement ce dont il a besoin.

Comment télécharger la mise à jour ?

Pour télécharger le package d'installation de cette mise à jour hors bande, rendez-vous sur le Catalogue Microsoft Update. En cliquant sur ce lien, vous devez retrouver toutes les mises à jour, sinon effectuez une recherche directement sur le numéro de KB. Pour vérifier la présence du correctif pour Windows Server 2019, vous pouvez rechercher "Update Windows Server 2019" et regarder la date du correctif le plus récent.

Microsoft que cette mise à jour n'est pas disponible avec WSUS, ni avec Windows Update, donc vous devez impérativement utiliser le Catalogue Microsoft Update (ce qui ne vous empêche pas de l'ajouter ensuite à votre WSUS).

Merci aux différentes personnes qui m'ont signalé l'existence de ce correctif.

The post Reboot Windows Server avec la mise à jour de mars 2024 : voici les correctifs de Microsoft ! first appeared on IT-Connect.

Microsoft a confirmé que la mise à jour de mars 2024 pour Windows Server était à l'origine d'une fuite de mémoire pouvant entrainer le plantage et le redémarrage des contrôleurs de domaine Active Directory.

• Windows Server : la mise à jour de mars 2024 fait planter et redémarrer les contrôleurs de domaine !

Autant vous le dire dès maintenant : il n'y a pas encore de solution officielle ! Néanmoins, Microsoft a identifié le problème et les équipes de l'entreprise américaine devraient proposer une solution dans les prochains jours. "La cause principale a été identifiée et nous travaillons sur une résolution qui sera publiée dans les prochains jours.", peut-on lire sur le site de Microsoft.

Microsoft évoque une fuite de mémoire extrême pouvant faire planter le processus LSASS sur les contrôleurs de domaine, ce qui force le serveur à redémarrer de façon brutale. Les mises à jour publiées le 12 mars 2024 à l'occasion du Patch Tuesday sont bien à l'origine de ce dysfonctionnement.

Il est important de préciser que ce problème affecte les versions suivantes de Windows Server : Windows Server 2022, Windows Server 2019, Windows Server 2016 et Windows Server 2012 R2. Ceci signifie que de nombreuses organisations sont susceptibles d'être impactées ! Par ailleurs, Windows 10 et Windows 11 ne sont pas affectés.

Si vous rencontrez le problème suite à l'installation de la mise à jour, la seule solution viable pour le moment, c'est de désinstaller la mise à jour à l'origine du problème. Sur votre serveur, ouvrez une Invite de commandes ou une console PowerShell en tant qu'administrateur, puis exécutez la commande suivante (en indiquant le bon numéro de KB, selon votre OS) :

# Windows Server 2016
wusa /uninstall /kb:5035855

# Windows Server 2019
wusa /uninstall /kb:5035849

# Windows Server 2022
wusa /uninstall /kb:5035857

Si vous n'avez pas encore procédé à l'installation des mises à jour de mars 2024, nous vous recommandons de patienter...

Le vendredi 22 mars 2024, Microsoft a mis en ligne des correctifs. Plus d'informations dans cet article :

• Windows Server - Bug de mars 2024 - Les correctifs de Microsoft

Source

The post Microsoft avoue que la mise à jour de mars 2024 fait planter les contrôleurs de domaine ! first appeared on IT-Connect.

Les mises à jour de mars 2024 pour Windows Server sont à l'origine d'un nouveau dysfonctionnement sur les contrôleurs de domaine Active Directory. Ce problème, lié au service LSASS, fait planter le serveur, ce qui le pousse à redémarrer. Faisons le point !

Disponibles depuis le mardi 12 mars 2024, de nouvelles mises à jour cumulatives sont disponibles pour les différentes versions de Windows Server encore prises en charge par Microsoft, notamment les KB5035855 et KB5035857. Ces derniers jours, plusieurs messages ont été mis en ligne sur Internet, notamment sur Reddit et sur le site de Microsoft, afin d'évoquer un problème de stabilité à la suite de l'installation de la mise à jour de mars 2024.

Une nouvelle fois, ce problème serait lié au processus LSASS (Local Security Authority Subsystem Service) : une fuite de mémoire engendrerait une "surconsommation" des ressources sur le serveur. Ce dernier finit par figer et redémarrer car le processus consomme toute la RAM disponible !

D'après les quelques messages visibles sur Internet, les contrôleurs de domaine sont directement impactés par ce problème qui concerne au moins Windows Server 2016 et Windows Server 2022.

"Nous avons eu des problèmes avec lsass.exe sur les contrôleurs de domaine (2016 Core, 2022 avec DE et 2022 Core) où il y a une fuite de mémoire également. Au point que tous les contrôleurs de domaine se sont bloqués pendant le week-end et ont provoqué une panne.", peut-on lire sur cette page.

Est-ce qu'il y a une solution ?

Pour le moment, Microsoft ne s'est pas exprimé à ce sujet, et la seule solution temporaire, c'est de désinstaller la mise à jour, ou de ne pas l'installer pour le moment. Pour rappel, l'utilitaire wusa.exe natif dans Windows peut vous permettre de désinstaller une mise à jour :

wusa /uninstall /kb:<numéro de KB>
wusa /uninstall /kb:5035855

Ce problème doit rappeler de très mauvais souvenirs à certains d'entre vous, puisqu'en décembre 2022, Microsoft avait corrigé un bug aux conséquences similaires : le service LSASS consommait trop de mémoire et faisait planter le serveur contrôleur de domaine. Ce problème était directement lié aux mises à jour du Patch Tuesday de novembre 2022.

Avez-vous rencontré ce problème ? N'hésitez pas à faire des retours en commentaire !

Les dernières informations officielles de Microsoft, dans cet article :

• Microsoft avoue que la mise à jour de mars 2024 fait planter les contrôleurs de domaine !

Le vendredi 22 mars 2024, Microsoft a mis en ligne des correctifs. Plus d'informations dans cet article :

• Windows Server - Bug de mars 2024 - Les correctifs de Microsoft

Source

The post Windows Server : la mise à jour de mars 2024 fait planter et redémarrer les contrôleurs de domaine ! first appeared on IT-Connect.

I. Présentation

Dans cet article, nous allons partir à la découverte de l'offre Public Cloud de l'hébergeur suisse Infomaniak. Ce sera l'occasion de vous présenter le tableau de bord et l'interface de gestion avant de vous expliquer comment déployer une instance Windows Server 2022 en quelques minutes.

• Cliquez ici pour regarder la vidéo sur YouTube

II. Quelques mots sur Infomaniak

Avant d'entrer dans le vif du sujet, il me semble important de vous présenter l'hébergeur Infomaniak, ainsi que ses valeurs. Créé en 1994, en Suisse, ce fournisseur Cloud propose une large gamme de services : hébergement web, hébergement WordPress, serveur VPS, infrastructure Public Cloud, housing, etc.... Sans oublier la solution collaborative éthique kSuite qui regroupe des fonctions de stockage en ligne de type Drive, un système de visioconférence, de messagerie électronique, de chat, etc. Dernièrement, Infomaniak a lancé sa propre intelligence artificielle souveraine accessible au travers d'une API.

Aujourd'hui, Infomaniak compte plus d'un million d'utilisateurs et plus de 200 collaborateurs.

Au cœur des priorités d'Infomaniak, il y a la sécurité des données, le respect de la vie privée et l'écologie. L'intégralité des données des clients sont stockées dans des centres de données (Tier 3+) conçus par Infomaniak et situés en Suisse. Ceci est en adéquation avec la volonté d'Infomaniak de proposer des solutions souveraines et adaptées aux données sensibles.

Sur le plan de son empreinte écologique, le fournisseur cloud suisse effectue un travail remarquable depuis 2007 ! Le Green IT est dans l'ADN d'Infomaniak : au-delà de réduire sa consommation en énergie, l'hébergeur utilise exclusivement de l’énergie renouvelable, construit ses propres centrales solaires et prolonge la durée de vie de ses serveurs jusqu’à 15 ans pour limiter son impact au maximum sur la Planète. De plus, Infomaniak ne climatise plus ses data centers depuis 2013, compense à 200% la totalité de ses émissions de CO2, et va encore plus loin avec son nouveau data center D4.

Comme l'explique cet article, ce data center n’a aucun impact sur le paysage, car il est construit sous le parc d’un écoquartier. Son originalité ? Il revalorisera 100% de l'énergie consommée par l'infrastructure et la chaleur dégagée sera utilisée pour le chauffage de milliers de ménages en hiver et pour chauffer l'eau des sanitaires en été. "Cette innovation fournira à pleine capacité 12 750 MWh soit l’équivalent de 5500 tCO2 de pellets par an pour chauffer jusqu’à 6000 ménages", peut-on lire sur le site officiel.

• En savoir plus sur Infomaniak

III. Le Cloud Public Infomaniak

Le Cloud Public Infomaniak correspond à une offre de service de type IaaS où vous pouvez déployer l'infrastructure correspondant à vos besoins et ceux de votre organisation : instance serveurs (CPU/GPU), object storage (compatible S3), stockage bloc (Ceph/Cinder), réseau haute performance, etc.

Ce qui est intéressant, c'est qu'en plus d'être une solution européenne et souveraine, les services d'Infomaniak sont moins coûteux en comparaison de ceux proposés par les géants américains : Microsoft Azure, Amazon Web Services (AWS) et Google Cloud Platform. Consultez cette page pour en savoir plus.

Voici un exemple fournit par Infomaniak :

Un calculateur en ligne vous permet d'estimer votre consommation, ce qui peut être un exercice intéressant, notamment si vous avez déjà des services chez un autre fournisseur.

Tous les tarifs par heure ou par mois sont disponibles sur cette page :

• Les tarifs du Cloud Public Infomaniak

D'un point de vue technique, le Cloud Public d'Infomaniak s'appuie sur la technologie de Cloud computing open source OpenStack. Il s'agit d'une solution populaire reconnue dans le monde entier et utilisée par des centaines de fournisseurs Cloud, ainsi que des organisations. OpenStack peut être utilisé sur une infrastructure locale, hybride ou entièrement Cloud.

Grâce à une API et au fait qu'OpenStack soit une technologie ouverte, vous pouvez utiliser d'autres outils populaires pour gérer et déployer votre infrastructure : Terraform, Ansible, Docker, Kubernetes, etc....

Lors du déploiement d'une instance de type "serveur virtuel" sur le Cloud Public d'Infomaniak, vous avez le choix entre plusieurs images prêtes à l'emploi, aussi bien en Linux (Debian, Ubuntu, Oracle Linux, Arch Linux, Alpine Linux, Red Hat Enterprise Linux, etc.) qu'en Windows Server avec une prise en charge de Windows Server 2019 et Windows Server 2022.

La gestion de ses projets Public Cloud s'effectue à partir de l'interface Manager d'Infomaniak, où vous pouvez retrouver l'ensemble de vos services. Chaque "tenant" Public Cloud est associé à un ou plusieurs projets, où chaque projet à ses ressources, ses utilisateurs, etc... Ce cloisonnement est intéressant pour effectuer une séparation par projets ou par clients selon nos besoins.

A. Créer un projet

La première étape consiste à créer un nouvel environnement avec un projet. Ceci va permettre d'avoir un accès à OpenStack avec un utilisateur dédié. Cette étape s'effectue facilement. Il suffit de se laisser guider par l'assistant.

• Envie de tester le Cloud Public Infomaniak ? Vous pouvez utiliser ce lien.

Une fois cette première étape complétée, nous devons nous connecter à l'interface d'OpenStack à l'aide de notre nouvel utilisateur.

Voilà, nous sommes sur l'interface OpenStack !

C'est ici, que nous allons pouvoir créer nos instances, c'est-à-dire nos serveurs virtuels, mais également configurer les réseaux, le stockage, etc... En effet, nous pouvons créer un ensemble de réseaux virtuels, connectés ou non à Internet, de routeurs pour assurer les communications entre nos réseaux et les communications entre ces réseaux est sécurisé grâce à des groupes de sécurité (security groups).

B. Le coût d'une instance Windows Server

Comme je l'évoquais précédemment, vous pouvez déployer différents systèmes d'exploitation sur vos instances. Si vous choisissez d'utiliser Windows Server, au-delà du coût de l'instance, vous devez aussi louer la licence Windows Server. Ceci est proposé directement par Infomaniak, vous n'avez pas besoin d'apporter votre propre licence.

Actuellement, le tarif est le même pour toutes les versions et éditions de Windows Server. Il s'agit d'un tarif par CPU. Voici, à titre d'exemple, un tableau extrait du site Infomaniak :

IV. Déployer une infrastructure Windows Server

A. Schéma de l'infrastructure cible

Avant de vous expliquer comment utiliser l'interface d'OpenStack, nous allons nous intéresser à notre infrastructure cible. Elle contiendra une seule instance, sous Windows Server, mais nous allons effectuer toute la configuration du réseau virtuel afin de mettre en pratique la création d'un réseau, d'un sous-réseau, d'un port, d'un routeur ou encore d'un groupe de sécurité, en plus de l'instance en elle-même. Ceci vous permettra d'être plus à l'aise et plus ambitieux par la suite.

En résumé, nous allons accomplir les actions suivantes :

• Création d’un réseau nommé "servers-net" et d’un sous-réseau nommé "servers-net-windows" (10.10.10.0/24), avec DHCP activé, et une adresse IP de passerelle définie
• Création d’un port sur ce réseau, avec une adresse IP statique (pour qu’elle soit attribuée à la future instance) – 10.10.10.2/24
• Création d’un routeur connecté au réseau "ext-floating1" pour avoir accès à Internet et avec l'adresse IP "10.10.10.1/24" pour la communication avec notre sous-réseau
• Ajout d’une interface sur le routeur pour faire le lien avec le sous-réseau précédemment créé
• Création d’un groupe de sécurité et ajout d’une règle pour autoriser le protocole RDP (Bureau à distance)
• Ajout d’une adresse IP flottante pour la rattacher au port créé sur le réseau (avec l'adresse IP 10.10.10.2/24)
• Création d’une instance Windows Server
• Connexion à l'instance Windows Server, via RDP

B. OpenStack : créer un réseau

Commençons par la préparation de l'infrastructure réseau virtuelle. La première étape consiste à créer un réseau puis un sous-réseau. Sous "Réseau", cliquez sur "Réseaux" puis sur "Créer un réseau". Il est à noter que nous pourrions directement connecter notre instance sur le réseau "ext-net1" mis à disposition par Infomaniak. Pour plus de contrôle et de souplesse, nous allons créer notre propre réseau.

Vous devez commencer par nommer ce réseau : servers-net. Cochez la case "Créer un sous-réseau" avant de passer à la suite pour créer le sous-réseau dans la foulée, via les onglets correspondants.

Basculez sur l'onglet "Sous-réseau" afin d'indiquer le nom du réseau et l'adresse du réseau : adresse IP + masque de sous-réseau. Ici, nous utilisons l'IPv4, mais nous pourrions utiliser l'IPv6.

• Nom du sous-réseau : servers-net-windows
• Adresse réseau : 10.10.10.0/24
• Adresse IP de la passerelle : 10.10.10.1

Le dernier onglet, nommé "Détails du sous-réseau" est tout aussi important. En effet, nous pouvons activer ou désactiver le service DHCP sur ce sous-réseau. Dans cette démonstration basée sur Windows Server, nous allons attribuer une adresse IP statique à notre instance, donc nous pourrions avoir envie de désactiver ce service. Pourtant, nous devons bien cocher l'option "Activer DHCP" sinon l'instance ne pourra pas être déployée correctement (il manquera une route réseau, ce qui posera problème pour stocker le mot de passe de l'instance).

En complément, nous pouvons indiquer le(s) serveur(s) DNS de notre choix pour la résolution des noms. Cliquez sur "Créer" pour valider.

Voilà, vous venez de créer un réseau et un sous-réseau dans OpenStack.

C. OpenStack : créer un port

La seconde étape consiste à créer un port dans notre réseau afin de lui associer une adresse IP statique. Elle sera affectée à notre future instance, ce qui nous assure que l'instance aura toujours la même adresse IP.

Dans la section "Réseaux", cliquez sur le nom du réseau "servers-net", basculez sur l'onglet "Ports" et cliquez sur "Créer un port".

Donnez un nom à ce port, par exemple "VM-WS-2022-01", ce qui fait référence à ma future instance. Choisissez "Adresse IP fixe" et précisez l'adresse IP fixe. Par exemple : 10.10.10.2. L'association entre le port et l'instance sera effectué par la suite. Cliquez sur "Créer".

D. OpenStack : créer et configurer un routeur

Vous venez de créer un réseau, mais ce dernier est isolé. Nous avons besoin que notre future instance puisse accéder à Internet. Nous allons créer un routeur pour mettre en place cette connectivité vers le monde extérieur. Sous "Réseau", cliquez sur "Routeurs" puis "Créer un routeur".

Nommez ce routeur, par exemple "servers-net-router", choisissez le réseau externe "ext-floating1" et validez.

Grâce à cette action, vous venez de créer un routeur connecté à Internet, mais sans aucun lien avec votre sous-réseau personnalisé (servers-net-windows). Pour cela, vous pouvez ajouter une interface en cliquant sur le routeur ou à partir de la vue topologie en cliquant sur le bouton "Ajouter une interface".

Choisissez votre sous-réseau, correspondant à "10.10.10.0/24". Il n'est pas nécessaire de préciser une adresse IP de passerelle, puisque nous l'avons déjà déclarée dans notre sous-réseau (10.10.10.1/24). Cliquez sur "Envoyer".

Voilà, l'aperçu "Topologie" montre bien notre routeur qui fait le lien entre deux réseaux : ext-floating1 et servers-net.

Passons à la suite de la configuration.

E. OpenStack : créer un groupe de sécurité

Vous devez créer un groupe de sécurité pour gérer les flux entrants et sortants à destination de votre instance. Un groupe de sécurité sert à créer des règles d'autorisation de flux en partant du principe que tout ce qui n'est pas autorisé sera refusé.

Par défaut, il y a le groupe de sécurité "default" qui bloque tous les flux entrants et autorise tous les flux sortants. Vous allez créer votre security group personnalisé en cliquant sur le bouton "Créer un groupe de sécurité" présente sous "Réseau" puis "Groupes de sécurité".

Nommez ce groupe de sécurité, par exemple "servers-net-sg".

Vous pouvez constater la présence des deux règles par défaut pour autoriser tous les flux sortants. Vous devez ajouter au moins une règle de flux entrant pour autoriser le protocole RDP vers votre instance afin de pouvoir vous connecter en Bureau à distance à Windows Server.

Cliquez sur "Ajouter une règle".

Renseignez les différents champs du formulaire pour autoriser le port 3389/TCP en entrée, puisqu'il correspond au RDP. Vous pouvez jouer sur les paramètres "Distant" et "CIDR" pour autoriser une adresse IP source spécifique (ceci peut s'avérer utile pour éviter de trop exposer le port RDP). Cliquez sur "Ajouter".

La règle est bien présente :

Vous pouvez passer à la suite !

F. OpenStack : associer une adresse IP flottante à un port

Dernière étape avant la création de l'instance : vous devez associer une adresse IP flottante au port qui va être utilisé par votre instance. Ainsi, elle va bénéficier d'une adresse IP publique !

Sous "Réseau", cliquez sur "IP flottantes", puis cliquez sur "Allouer une adresse IP au projet".

Choisissez le pool "ext-floating1" et cliquez sur "Allocation d'IP". Nous pouvons définir un nom de domaine DNS, si besoin.

Ensuite, vous devez associer à l'adresse IP flottante. En l'occurrence, l'adresse IP publique doit être associée à l'adresse IP "10.10.10.2" qui sera utilisée par notre future instance Windows Server. Sans cela, l'accès direct à notre instance depuis Internet sera impossible. Cliquez sur "Associer" pour valider.

Nous allons pouvoir créer notre instance Windows Server !

G. OpenStack : créer l'instance Windows Server

Pour créer une ou plusieurs instances, que ce soit sous Linux, Windows Server ou un autre système, à partir de l'interface web, vous devez cliquer sur "Compute", puis "Instances" afin d'accéder au bouton "Lancer une instance".

Un assistant s'ouvre... Nous allons devoir y aller étape par étape.

L'étape "Détails" sert à spécifier le nom de l'instance et la zone de disponibilité (redondance géographique). Nous pouvons aussi décider de déployer plusieurs instances.

Quelle est la source pour cette nouvelle instance ? Il pourrait s'agir d'un instantané d'une instance existante, mais dans le cas présent, nous partons de zéro. Nous allons sélectionner une image : vous pouvez sélectionner l'image de votre choix dans le catalogue d'Infomaniak. A ce jour, il y a 33 images différentes. Sélectionnez : "Windows Server 2022 Standard".

Remarque : vous pouvez importer vos propres images personnalisées. Différentes sources sont prises en charge : ISO, VDI, VHD, VMDK, etc.

L'étape "Gabarit" se présente à vous. L'objectif étant de choisir un modèle de machine virtuelle (ou flavor pour reprendre le terme OpenStack) qui correspond à vos besoins, notamment en termes de vCPU (processeur), RAM, et capacité de disque. Vous pouvez personnaliser l'espace de stockage pour ajouter un volume avec une taille spécifique.

Par exemple, vous pouvez prendre le modèle "a2-ram4-disk80-perf1" pour avoir 2 vCPU, 4 Go de RAM et 80 Go d'espace disque. Ceci me semble cohérent pour démarrer un Windows Server (disons, que c'est le minimal).

Passez l'étape "Réseaux" puisque vous devez associer directement un port réseau à l'étape "Ports réseaux". Il n'y a pas d'intérêt à associer l'instance aux deux à la fois. Ici, avec le bouton qui contient une flèche vers le haut, vous allez sélectionner le port "VM-WS-2022-01" créé précédemment. Pour rappel, ce port correspond à l'adresse IP "10.10.10.2" sur le sous-réseau "servers-net-windows".

Passez à l'étape "Groupes de sécurité". Ici, vous allez associer à l'instance le groupe de sécurité "servers-net-sg" créé préalablement. Une autre méthode consisterait à associer le groupe de sécurité au port, ainsi l'instance pourrait en hériter.

Poursuivez.

L'étape "Key Pair" s'affiche. Ici, vous devez "Créer une paire de clés" SSH. Avec une instance Linux, cette clé sert à sécuriser la connexion SSH vers votre instance pour que l'authentification soit effectuée à l'aide de votre clé privée. Avec Windows Server, l'authentification s'effectue avec un identifiant et un mot de passe. Toutefois, cette paire de clés sert à sécuriser le processus de récupération du mot de passe par défaut : si vous n'avez pas la clé privée, vous ne pouvez pas lire le mot de passe.

Nommez cette paire de clés et cliquez sur le bouton "Créer une paire de clés".

Une paire de clés (clé publique + clé privée) sera générée. Vous devez copier la chaine correspondante à la clé privée afin de la stocker en lien sûr (dans votre gestionnaire de mots de passe, par exemple). Elle sera utile par la suite.

Poursuivez... L'étape "Configuration" sert à préciser le contenu d'un script de personnalisation de Cloud-Init (pour Linux), ce qui peut permettre d'automatiser la configuration de l'instance, en post-déploiement.

Poursuivez jusqu'à la fin en prenant connaissance des dernières étapes puis cliquez sur "Lancer Instance".

Ensuite, vous devez patienter pendant le déploiement de l'instance. Quelques minutes vont suffire. Pour suivre de plus près le déploiement, vous pouvez cliquer sur le nom de l'instance pour ensuite cliquer sur l'onglet "Console" afin de visualiser la console de la VM.

Quand le déploiement sera terminé, vous pourrez visualiser l'écran de verrouillage de Windows Server :

Comment se connecter à l'instance ? C'est ce que nous allons voir dans la prochaine partie !

H. OpenStack : se connecter à l'instance Windows Server

Pour établir la connexion à cette instance Windows Server, nous devons utiliser le protocole RDP. À partir d'une machine Windows, le client Bureau à distance peut être utilisé. Mais, quelle est l'adresse IP ? Quel est le nom d'utilisateur ? Et le mot de passe ?

• L'adresse IP, vous la connaissez puisqu'il s'agit de l'adresse IP publique correspondante à l'adresse IP flottante rattachée au port de l'instance.
• Le nom d'utilisateur est le suivant : Administrator

Pour le moment, quelques manipulations sont requises.

À partir de la liste des instances, cliquez sur la flèche au bout de la ligne de l'instance Windows Server, puis cliquez sur "Récupérer le mot de passe". D'ailleurs, ce menu donne accès à de nombreuses actions : prendre un instantané (snapshot), arrêter l'instance, redémarrer l'instance, etc.... Pour faire des économies, vous pouvez arrêter l'instance quand vous ne l'utilisez pas (chaque heure étant facturée).

Une fenêtre s'ouvre. Vous devez coller votre clé privée (vous savez, celle générée précédemment) ou charger le fichier de clé privée. Puis cliquez sur "Déchiffrer le mot de passe". Et là, le précieux sésame s'affiche au sein du champ "Mot de passe". Vous n'avez plus qu'à le copier. Vous l'aurez compris : pas de clé privé, pas de mot de passe. Pas de bras, pas de chocolat, finalement.

Vous n'avez plus qu'à ouvrir le client RDP sur votre PC ! Indiquez l'adresse IP publique, puis le nom d'utilisateur et le mot de passe afin de vous connecter.

Quelques secondes plus tard, vous êtes connecté à votre instance Windows Server 2022 !

La suite des opérations vous appartient : installation d'applications, de rôles Windows Server, etc... En fonction de vos besoins ou des tests que vous souhaitez effectuer.

V. Conclusion

En suivant ce tutoriel, vous devriez être en mesure de faire vos premiers pas avec l'offre IaaS Public Cloud d'Infomaniak dans le but de déployer une VM sous Windows Server 2022 Standard ! Vous pouvez même déployer une distribution Linux si vous le souhaitez, car finalement, à part pour se connecter à l'instance suite à la création, le processus reste le même !

• Envie de tester le Cloud Public Infomaniak ? Vous pouvez utiliser ce lien.

Souhaitez-vous en savoir plus sur le Cloud Public Infomaniak ? N'hésitez pas à commenter cet article pour évoquer vos idées, poser vos questions, etc.

Cet article inclus une communication commerciale.

The post Déployer une instance Windows Server 2022 sur le Public Cloud d’Infomaniak first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons voir comment effectuer une installation de CrowdSec sur plusieurs machines afin de répliquer les alertes et les décisions entre les différentes instances. Ainsi, lorsqu'un serveur banni une adresse IP, elle est également bannie sur les autres instances CrowdSec synchronisées.

Pour effectuer une installation multiserveur de CrowdSec, toutes les machines doivent avoir une instance CrowdSec installée en local. Ensuite, nous viendrons ajuster la configuration de chaque instance, notamment au niveau de LAPI. Si vous avez plusieurs serveurs exposés sur Internet (un cluster de serveurs Web, par exemple), vous pouvez déployer cette configuration pour que les adresses IP malveillantes soient bannies sur tous les nœuds.

Pour les échanges d'informations, CrowdSec s'appuie sur deux API :

• Local API ou LAPI : ceci correspond à l'hôte local lorsque l'instance CrowdSec fonctionne de façon autonome
• Central API ou CAPI : ceci correspond aux instances CrowdSec dans le Cloud, notamment sollicitées pour récupérer les listes d'adresses IP malveillantes communautaires et pour transmettre les signaux à la console CrowdSec.

Ce contenu est disponible au format vidéo :

• Voir la vidéo sur YouTube

II. Architecture avec un pare-feu PfSense et des serveurs virtuels

Pour le déploiement, plusieurs scénarios sont envisageables. Vous pouvez utiliser une machine CrowdSec destinée à centraliser toutes les décisions et toutes les alertes, et sur laquelle les autres machines viendront se synchroniser. Il est d'ailleurs possible de s'appuyer sur une base de données, pour des questions de performance.

Aujourd'hui, nous allons déployer un scénario basé sur deux machines :

• Un pare-feu PfSense, où CrowdSec sera installé et cet hôte sera utilisé pour héberger le rôle de "Local API" pour les trois machines
• Un serveur Windows Server, où CrowdSec sera installé avec le bouncer windows-firewall

Ici, il n'y a qu'un seul serveur exposé sur Internet, représenté par un serveur Web sous Windows Server, mais il pourrait tout à fait en avoir d'autres (y compris sous Linux). Je vais vous préciser les étapes à effectuer sur les noeuds que l'on pourrait appeler les "clients LAPI".

Remarque : dans la vidéo, le scénario est basé sur trois machines, avec un second serveur en DMZ, sous Linux, lui aussi serveur Web et exposé sur Internet également. Référez-vous à la vidéo si nécessaire, selon vos besoins.

III. Point de départ

Ce tutoriel n'abordera pas l'installation de CrowdSec sur les différents hôtes, ni même l'installation des systèmes d'exploitation. Pour cela, référez-vous aux articles suivants :

• Installer CrowdSec sur Windows Server
• Installer CrowdSec sur PfSense
• Créer un lab virtuel avec VirtualBox et PfSense
• Créer un lab virtuel avec VMware Workstation et PfSense

Quand votre environnement est prêt, vous pouvez passer à la phase de configuration.

IV. Configurer le serveur LAPI central pour CrowdSec

Sur le pare-feu PfSense, nous devons configurer CrowdSec pour qu'il soit en écoute sur une adresse IP du pare-feu, afin de ne pas être accessible uniquement en local. Sans cela, les autres hôtes ne pourront pas venir s'inscrire sur ce serveur LAPI car par défaut l'hôte LAPI est configuré sur l'adresse IP de boucle locale : 127.0.0.1.

Connectez-vous à l'interface d'administration de PfSense, cliquez sur "Services" puis "CrowdSec". Ici, descendez jusqu'à trouver l'option "LAPI host" et remplacez "127.0.0.1" par le nom d'hôte (DNS) de votre pare-feu PfSense, ou l'adresse IP de l'une de ses interfaces. Dans cet exemple, je précise "192.168.200.1" car il s'agit de l'adresse IP de l'interface "DMZ" de mon pare-feu et le serveur Web se situe dans cette zone réseau.

Quand c'est fait, sauvegardez la configuration avec le bouton prévu à cet effet.

Il est à noter que cette modification, bien qu'elle soit effectuée via l'interface web de PfSense, pourrait être effectuée en ligne de commande en modifiant le fichier suivant :

/usr/local/etc/crowdsec/config.yaml

D'ailleurs, ce que nous venons d'effectuer en mode web a permis de modifier le fichier de configuration.

Passez à l'étape suivante.

V. Inscrire et autoriser les hôtes sur le serveur LAPI

Le serveur Web sous Windows Server va devoir s'inscrire sur le serveur LAPI CrowdSec, c'est-à-dire notre pare-feu PfSense. Ensuite, nous devrons approuver la demande d'inscription. Cette étape est à effectuer sur chaque serveur qui doit utiliser le serveur LAPI central.

A. Désactiver l'interface LAPI de CrowdSec

À partir du serveur Windows Server, où CrowdSec est installé, vous devez commencer par modifier le fichier de configuration "config.yaml" situé à cet emplacement :

C:\ProgramData\CrowdSec\config\config.yaml

Dans ce fichier, vous devez ajouter la ligne "enable: false" sous "server:", et commenter la ligne "listen_uri" afin de désactiver la LAPI de CrowdSec. En effet, ce n'est plus utile sur ce serveur puisque nous allons solliciter la LAPI de l'instance CrowdSec installée sur le pare-feu PfSense.

Attention à la syntaxe, notamment aux espaces, car YAML est très pointilleux là-dessus.

Une fois que c'est fait, sauvegardez le fichier.

• CrowdSec - Documentation - Fichier de configuration

B. Inscrire les hôtes CrowdSec sur le serveur LAPI

Toujours sur ce même serveur, ouvrez une console PowerShell ou une Invite de commande afin d'inscrire l'hôte sur le serveur LAPI. Exécutez la commande suivante, en adaptant l'adresse IP (et éventuellement le port, si vous l'avez modifié).

cscli lapi register -u  http://192.168.200.1:8080

Si l'on ne précise pas de nom, comme c'est le cas avec la commande ci-dessus, un ID aléatoire sera généré. Si vous souhaitez préciser un nom, afin que ce soit plus parlant, utilisez la commande de cette façon :

cscli lapi register -u  http://192.168.200.1:8080 --machine <nom de la machine>

Vous devez obtenir un résultat semblable à celui-ci :

Pour prendre en compte l'ensemble des modifications que nous venons d'effectuer, redémarrez le service CrowdSec :

Restart-Service crowdsec

Passez à la suite.

C. Approuver les hôtes CrowdSec

Basculez sur le serveur LAPI, c'est-à-dire sur le pare-feu, afin d'approuver la machine que l'on vient d'inscrire. Connectez-vous à la console, via SSH, par exemple.

Exécutez la commande suivante pour lister les machines :

cscli machines list

Ceci va permettre d'obtenir une liste avec deux machines :

• La machine locale, ici "pfsense"
• La machine distante que l'on vient d'inscrire, identifier par le nom "3f8ba55c46b54537aadaac7c5b7717a44wNuYECMrmksQ9Mm" (car je n'ai pas précisé de nom ; j'ignorais l'option permettant de nommer la machine à ce moment-là)

Désormais, il faut valider / approuver cette nouvelle machine en attente. Pour cela, exécutez la commande suivante :

cscli machines validate <nom de la machine>
cscli machines validate 3f8ba55c46b54537aadaac7c5b7717a44wNuYECMrmksQ9Mm

En principe, vous devriez obtenir un message de confirmation, comme celui-ci :

Passez à la suite.

VI. Déclarer les nouveaux bouncers

A. Ajouter un bouncer et obtenir une clé d'API

Toujours sur le serveur LAPI, à savoir PfSense, nous allons devoir déclarer la machine distante comme étant un bouncer. Ceci signifie qu'elle aura la permission de venir déclarer de nouvelles alertes et décisions pour bloquer des adresses IP malveillantes.

La commande suivante permet de déclarer un bouncer nommé "SRV-WS2022". Vous pouvez reprendre le nom d'hôte de votre machine.

cscli bouncers add <nom de la machine>
cscli bouncers add SRV-WS2022

Comme le montre l'image ci-dessous, nous obtenons une clé d'API pour cet hôte :

Cette clé d'API va lui permettre de s'authentifier sur le serveur LAPI en tant que bouncer.

B. Configurer le bouncer sur l'hôte

Retournez sur le serveur distant. Pour ma part, c'est le serveur Web sous Windows Server. L'objectif va être de configurer le bouncer Windows Firewall installé sur cette machine pour qu'il déclare les décisions sur le serveur LAPI central, plutôt qu'en local. Ceci implique d'installer le bouncer sur le serveur, au préalable.

Éditez le fichier suivant :

C:\ProgramData\CrowdSec\config\bouncers\cs-windows-firewall-bouncer.yaml

Dans ce fichier, vous devez modifier deux options :

• api_endpoint
• api_key

Elles sont mises en évidence sur l'image ci-dessous.

Pour l'option "api_endpoint", vous devez indiquer l'adresse IP (ou le nom d'hôte) ainsi que le port de votre serveur LAPI central (soit le PfSense).

Pour l'option "api_key", vous devez indiquer la clé d'API obtenue précédemment via la commande "cscli bouncers add".

Ce qui donne :

Quand c'est fait, redémarrez le service Windows correspondant au bouncer Firewall :

Restart-Service cs-windows-firewall-bouncer

Du côté de PfSense, si nous regardons l'onglet "Bouncers" présent sur la page de statut de CrowdSec, nous pouvons voir deux bouncers valides ! Il y a le bouncer présent en local sur PfSense et notre hôte distant sous Windows Server.

La configuration est prête, vous allez pouvoir la tester...

VII. Tester la configuration

Pour tester cette configuration, nous allons devoir simuler un comportement malveillant. Dans le cas présent, mon serveur Web Windows Server est accessible grâce à une règle de NAT (car le reverse proxy n'est pas configuré sur le pare-feu) créée sur le pare-feu PfSense.

À l'aide d'une machine distante, je vais accéder à ce site Web qui est celui par défaut de IIS. Il s'agit d'un Lab et l'interface WAN de mon PfSense a l'adresse IP "192.168.1.60", donc j'effectue un scan Web sur cette adresse IP à l'aide de l'outil Nikto.

Ci-dessous, l'action est effectuée à partir d'une machine Kali Linux. Ce scan effectué par Nikto est bruyant et devrait alerter rapidement CrowdSec.

En effet, nous pouvons constater qu'il y a bien eu une décision prise par CrowdSec : bloquer l'adresse IP correspondante à mon hôte Kali Linux. Le résultat ci-dessous est issu de la machine Windows Server.

Nous pouvons voir qu'il y a eu plusieurs alertes générées :

Mais, comment savoir si c'est le pare-feu ou le serveur web qui a pris la décision de bloquer cette adresse IP ?

Pour cela, nous pouvons regarder les détails de l'alerte. Par exemple, l'alerte avec l'ID numéro 4 correspondant à du "http-xss-probbing". Pour cela, nous devons exécuter la commande suivante :

cscli alerts inspect 4

Dans les détails, nous pouvons voir la ligne "Machine :" accompagnée par un nom d'hôte. Ici, j'obtiens un ID de machine (souvenez-vous, la machine n'a pas été nommée lors de son inscription initiale). Cet identifiant correspond bien à mon serveur Web, donc c'est ce serveur qui a bloqué l'adresse IP.

Nous pouvons le vérifier en faisant la correspondance entre cet ID et celui visible dans la liste des machines :

cscli machines list

Voici le résultat en image :

Remarque : nous pouvons également ajouter l'option "-m" aux commandes "cscli alerts list" et "cscli decisions list" pour ajouter une nouvelle colonne avec l'ID de la machine.

Du côté de l'interface Web de PfSense, cette adresse IP est également bannie ! La décision est bien synchronisée entre tous les hôtes. Ainsi, les deux machines vont bloquer tous les flux en provenance de cette adresse IP malveillante.

VIII. Conclusion

Grâce à ce tutoriel basé sur uniquement deux hôtes, nous voyons bien le potentiel et l'intérêt de CrowdSec dans une architecture multiserveur, notamment lorsqu'il y a plusieurs serveurs exposés sur Internet. Le fait de coupler les serveurs avec le pare-feu permet de bannir les adresses IP malveillantes directement en entrée du réseau, ce qui est intéressant pour protéger notre infrastructure.

Sachez que malgré la présence d'une authentification, tous les flux échangés entre les hôtes sont effectués en clair puisque le protocole HTTP est utilisé. Il s'agit de flux interne, entre le serveur en DMZ et le pare-feu, donc c'est acceptable. Toutefois, si vous envisagez d'utiliser un serveur LAPI externe ou qui implique que des flux vont transiter sur Internet, vous devez faire évoluer la configuration pour basculer les connexions en HTTPS.

The post Comment mettre en place une installation multiserveur de CrowdSec ? first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à installer Windows Server 2025, le nouveau système d'exploitation de Microsoft à destination des serveurs. Bien qu'il soit encore en version "Preview", nous pouvons avoir une idée précise du processus d'installation, de son interface, et commencer à évaluer certaines nouveautés.

Pour le moment, Microsoft n'a pas dévoilé officiellement les prérequis de Windows Server 2025, donc je ne m'avancerai pas sur ce point.

Voici des articles que vous pouvez lire pour en savoir plus sur les nouveautés prévues et connues actuellement :

• Les nouveautés de Windows Server 2025
• Windows Server 2025 : les nouveautés pour l'Active Directory
• Windows Server 2025 et l'authentification Kerberos (en local)

II. Télécharger ISO de Windows Server 2025

Afin de pouvoir suivre ce tutoriel, vous de télécharger une image ISO de Windows Server 2025 Preview après avoir rejoint le programme Windows Insiders pour Windows Server.

Voici les étapes à suivre :

1 - Vous devez rejoindre le programme Windows Server Insider avec un compte Microsoft (professionnel ou personnel)

2 - Quand c'est fait, vous devez accéder à cette page pour télécharger l'image ISO de Windows Server Preview

Quand le système d'exploitation sera disponible, d'autres liens seront publiés par Microsoft.

III. Installation de Windows Server 2025

Vous pouvez installer Windows Server 2025 sur une machine physique, mais également dans une machine virtuelle. Si vous avez besoin d'aide pour lancer l'installation, voici quelques liens utiles :

• Débuter avec VirtualBox : créer sa première VM
• Débuter avec VMware Workstation : créer sa première VM
• Créer une clé USB bootable de Windows

Intéressons-nous maintenant à l'installation en elle-même, étape par étape.

La première étape consiste à sélectionner le langage et le format de l'heure.

La seconde étape consiste à sélectionner la disposition du clavier.

Vient ensuite l'étape "Sélectionner l'option d'installation", où nous devons choisir "Installer Windows Server" pour procéder à l'installation du système. Ceci va permettre de poursuivre avec la nouvelle expérience d'installation. En complément, il faut cocher l'option "J'accepte que tout soit supprimé...".

Saisissez la clé de produit que vous souhaitez utiliser pour activer Windows Server 2025. Si vous n'en avez pas, vous pouvez passer cette étape.

Pour la version "Preview", Microsoft fournit les clés de licence suivantes :

• Windows Server 2025 Standard : MFY9F-XBN2F-TYFMP-CCV49-RMYVH
• Windows Server 2025 Datacenter : 2KNJJ-33Y9H-2GXGX-KMQWH-G6H67

En fonction de la clé de licence saisie, et après vérification de celle-ci, l'étape suivante est accessible. Si l'on indique une clé de licence pour Windows Server 2025 Standard, nous avons le choix entre :

• Windows Server 2025 Standard, ce qui correspond au mode "Core" sans interface graphique (minimaliste)
• Windows Server 2025 Standard (expérience utilisateur), ce qui permet d'avoir une installation avec l'interface graphique habituelle, à la sauce Windows 11 dans le cas présent.

Ensuite, acceptez les conditions du contrat de licence Microsoft.

Sélectionnez le disque sur lequel vous souhaitez installer le système d'exploitation. Ici, c'est sur une machine virtuelle avec un seul disque.

Démarrez l'installation... Et patientez pendant ce temps-là.

Une fois que la grosse partie de l'installation est effectuée, le serveur va redémarrer. Quand ce sera fait, vous serez invité à saisir un mot de passe pour le compte Administrateur local du serveur. Quand c'est fait, cliquez sur "Terminé".

Pour finir, une étape peu habituelle s'affiche : "Envoyer des données de diagnostic à Microsoft", comme sur Windows 11. Choisissez si vous souhaitez partager plus ou moins de données de télémétrie avec Microsoft.

Voilà, l'installation de Windows Server 2025 est terminée !

IV. Aperçu de l'interface de Windows Server 2025

Windows Server 2025 intègre le "Gestionnaire de serveur" comme les précédentes générations de Windows Server. Comme le montre l'image ci-dessous, Microsoft nous incite à utiliser Windows Admin Center, en local ou via Azure, pour l'administration de nos serveurs Windows Server. L'entreprise américaine met en avant également sa solution Azure Arc.

L'interface de Windows Server 2025 est similaire à celle de Windows 11, ce qui est assez perturbant au premier abord. Mais, n'oublions pas qu'il s'agit d'une première version "Preview" donc tout cela est susceptible d'évoluer dans les prochains mois... même si en principe ce nouveau Windows Server devrait conserver cette interface, au même titre que Windows Server 2022 est similaire à Windows 10.

V. Conclusion

En suivant ce tutoriel, vous êtes en mesure de pouvoir installer Windows Server 2025 Preview sur un serveur physique ou virtuel afin d'essayer cette nouvelle version de Windows Server. En fonction des évolutions futures, cet article sera actualisé.

Pour ceux qui ont pris le temps d'essayer cette version Preview, qu'en pensez-vous ?

The post Comment installer Windows Server 2025 (Preview) ? first appeared on IT-Connect.

Un correctif non officiel, proposé par la plateforme 0Patch, a été publié pour corriger une faille de sécurité zero-day nommée "EventLogCrasher" ! En exploitant cette vulnérabilité, un attaquant peut faire planter à distance le service Event Log de Windows. Voici ce qu'il faut savoir.

Le 23 janvier 2024, un chercheur en sécurité surnommé Florian a publié sur Twitter des détails au sujet d'une vulnérabilité qui permet de faire planter le service Event Log de Windows (Journal d'événements de Windows), à distance ou en local, à partir de n'importe quel compte utilisateur.

Dans un premier temps, il a contacté l'équipe MSRC de Microsoft pour faire remonter ce problème de sécurité, mais il n'a pas obtenu une réponse positive. Microsoft estime que cette vulnérabilité n'est pas éligible : "ils ont prétendu qu'il s'agissait d'un double d'un autre bug datant de 2022 (coïncidence ?) qui ne répondait pas aux exigences de servicing", précise-t-il.

De ce fait, il a publié un code PoC pour montrer l'exploitation de cette vulnérabilité, en pratique. Nous pouvons voir que c'est très simple. D'un point de vue d'un attaquant, il suffit d'avoir une connectivité réseau avec la machine cible et avoir des identifiants valides (un compte avec de faibles privilèges est suffisant) pour exploiter la vulnérabilité. Même si le pare-feu Windows est actif, l'exploitation est possible (avec la configuration par défaut).

Le risque : ne pas avoir de trace de certains événements

Cette faille de sécurité pourrait être exploitée dans le cadre d'une cyberattaque puisque si l'attaquant fait planter le service Event Log d'un contrôleur de domaine pendant son attaque, les événements associés à ses actions ne seront pas journalisés ! Nous pouvons même dire que cela pourrait empêcher certains événements de remonter dans le SIEM de l'entreprise. Ainsi, l'attaquant peut agir sans se faire remarquer...

À ce sujet, voici ce que précise 0patch dans son article de blog : "La bonne nouvelle à ce stade est que le service Windows Event Log est configuré pour redémarrer automatiquement en cas d'arrêt inattendu. La mauvaise nouvelle est qu'il n'est redémarré que deux fois, puis plus du tout. Par conséquent, si le service d'enregistrement des événements se bloque trois fois, il s'arrête de manière persistante."

Toutefois, il faut savoir que les événements relatifs à la sécurité et au système sont mis en mémoire si le service Event Log n'est pas disponible. Lorsqu'il est de nouveau actif, ils sont inscrits. Malgré tout, cette file d'attente à des limites en termes de taille et elle est éphémère : les événements sont perdus en cas de redémarrage de la machine, ou de plantage.

Comment se protéger ?

Comme je l'évoquais en introduction, la plateforme de micropatching 0patch a publié des correctifs non officiels pour combler cette faille de sécurité. D'ailleurs, cette vulnérabilité affecte toutes les versions de Windows et Windows Server à partir de Windows 7 et Windows Server 2008 R2.

En attendant un éventuel correctif officiel de la part de Microsoft, 0patch met à disposition gratuitement les correctifs suivants :

• Windows 11 v22H2, v23H2 - mise à jour complète
• Windows 11 v21H2 - mise à jour complète
• Windows 10 v22H2 - mise à jour complète
• Windows 10 v21H2 - mise à jour complète
• Windows 10 v21H1 - mise à jour complète
• Windows 10 v20H2 - mise à jour complète
• Windows 10 v2004 - mise à jour complète
• Windows 10 v1909 - mise à jour complète
• Windows 10 v1809 - mise à jour complète
• Windows 10 v1803 - mise à jour complète
• Windows 7 - pas d'ESU, ESU1, ESU2, ESU3
• Windows Server 2022 - mise à jour complète
• Windows Server 2019 - mise à jour complète
• Windows Server 2016 - mise à jour complète
• Windows Server 2012 - pas d'ESU, ESU1
• Windows Server 2012 R2 - pas d'ESU, ESU1
• Windows Server 2008 R2 - pas d'ESU, ESU1, ESU2, ESU3, ESU4

Il faut savoir que 0patch existe depuis plusieurs années et que des correctifs sont régulièrement mis à disposition des utilisateurs. Ils ne sont pas toujours gratuits, car il y a un service payant associé à cette plateforme.

Merci à l'équipe 0patch de m'avoir transmis cette information.

The post Ce correctif non officiel vous protège d’une faille zero-day présente dans l’Event Log de Windows first appeared on IT-Connect.

The announced support for SMB over QUIC in all editions of Windows Server 2025 marks a significant advancement for the file services role. In addition, the upcoming LTSC server release brings several new mechanisms designed to enhance the security of traditional SMB over TCP or RDMA.

The upcoming LTSC release of Windows Server introduces several enhancements to Hyper-V and new storage functions, which primarily benefit the operation of virtual machines. This includes GPU virtualization, a new deduplication feature for ReFS, and live migration of VMs on clusters that are not members of an AD domain.

The post Windows Server 2025 Hyper-V: GPU partitioning, deduplication for VHDs, AD-less live migration first appeared on 4sysops.

Dans cet article, nous verrons ensemble comment installer un serveur SFTP sur Windows Server. J’utiliserai ici Windows Serveur 2022 mais vous pouvez faire de même sur les versions précédentes. Nous utiliserons ici le logiciel open source OpenSSH pour réaliser cette tâche. Pourquoi utiliser un serveur SFTP ? Un serveur SFTP est un moyen sécurisé et …