Dans cet article, nous allons découvrir comment automatiser les sauvegardes des zones DNS sur un contrôleur de domaine Active Directory.
Dans un environnement Microsoft, qu'il soit sous Active Directory ou non, le service DNS joue un rôle essentiel. Il assure la traduction des noms de machines en adresses IP et inversement, tout en permettant la résolution des noms de domaine externes, qu'ils soient sous forme d'alias ou non. Il est donc primordial de veiller à ce que ces zones DNS soient disponibles et à jour.
Cette disponibilité peut être assurée par le nettoyage régulier des zones DNS, dont nous discuterons prochainement, ou par la mise en place de sauvegardes régulières, qui réduiront la durée d'indisponibilité en cas de problème.
La sauvegarde des zones DNS est essentielle pour restaurer une zone en cas de problèmes tels que des anomalies, des suppressions accidentelles ou des dysfonctionnements. De plus, elle permet de comparer facilement les différents enregistrements à l'aide de tableaux Excel ou de PowerShell.
Il peut arriver que des enregistrements statiques de serveurs soient supprimés de la zone, entraînant ainsi un dysfonctionnement.
De même, une erreur lors du nettoyage de la zone peut entraîner la suppression accidentelle d'enregistrements dynamiques, tels que ceux des clusters ou des objets enfants CNO (Cluster Name Oobject) avec des pointeurs SQL comme Always On, ce qui perturberait la production.
Dans de tels cas, une restauration est nécessaire.
Par défaut, la zone principale est disponible dans le chemin suivant :
ConnexionC:\windows\System32\DNS
La sauvegarde des contrôleurs de domaine avec différents outils (Veeam, Commvault, Windows Backup) ne permet de sauvegarder que le fichier en cours.
Cela signifie que seule la dernière sauvegarde sera disponible. Par exemple, si la sauvegarde des VMs s'effectue le soir à 21h, vous perdriez toutes les modifications effectuées durant la journée en cas de restauration. Il est alors nécessaire de remonter la sauvegarde pour avoir accès à plusieurs versions des zones et explorer les enregistrements pour une comparaison.
Note : Il est à noter que les zones intégrées à l'AD sont déplacées dans la corbeille pour une durée correspondante au tombstone. Il est alors possible de restaurer ces zones après suppression seulement à l'aide des commandes PowerShell. La restauration des enregistrements seuls est un peu plus compliquée et sera traitée dans un prochain article.
La console DNS offre la possibilité d'exporter la zone sous différents formats tels que ".txt" ou ".csv". Cependant, cette méthode est réciproque à la zone sauvegardée présente dans le chemin par défaut, mais ne permet pas de restaurer toutes les zones.
De plus, il n'est pas pratique d'effectuer cela manuellement sur toutes les zones plusieurs fois par jour.
La commande Dnscmd, un outil en ligne de commande apparu dans Windows Server 2003, permet de gérer le DNS en ligne de commande.
Elle propose diverses actions de maintenance sur la zone DNS, telles que le nettoyage de la zone, la suppression du cache, et surtout l'exportation partielle ou complète de la zone. Malheureusement, cette commande a été dépréciée par Microsoft et n'est pas intégrée à PowerShell pour faciliter la gestion des sorties.
Une interface de ligne de commande pour la gestion des serveurs DNS. Cet utilitaire est utile dans les scripts des fichiers batch pour automatiser des tâches courantes de gestion DNS, ou pour effectuer une installation sans assistance simple et la configuration de nouveaux serveurs DNS sur votre réseau.
Différentes options sont disponibles. Voici quelques exemples.
# Définit l'heure actuelle sur tous les horodateurs dans une zone ou d'un nœud
Dnscmd /ageallrecords
# Efface le cache du serveur DNS
Dnscmd /clearcache
# Réinitialise la configuration du serveur ou une zone DNS
Dnscmd /config Par ailleurs, DNSCMD permet d'exporter la configuration DNS à l'aide de la commande suivante :
Dnscmd /ZoneExportLe problème, c'est que Dnscmd exporte toujours le fichier dans le même répertoire, ce qui peut entraîner l'écrasement de sauvegardes précédentes.
Il n'est pas possible d'enregistrer dans un autre dossier sans ajouter une action dans le script qui regroupera le contenu et modifiera ou déplacera le nom du dossier.
Pour pallier cette limite, Microsoft a introduit des commandes PowerShell permettant de mieux exploiter le DNS.
La commande "Export-DnsServerZone" permet d'exporter une zone dans un dossier. Cependant, comme pour le Dnscmd, il n'est pas possible de changer le dossier racine de sauvegarde.
Pour effectuer une sauvegarde de toutes les zones, nous allons utiliser la commande PowerShell permettant de lister les zones DNS présentes, à savoir "Get-DnsServerZone". Ceci va nous permettre de créer un script de sauvegarde des zones DNS.
Nous exclurons les zones inverses loopback par défaut "0", "127" et "255" car elles ne contiennent pas d'enregistrement et n'existent pas de réseaux 255 ou 0. Ces enregistrements ne sont pas possibles et génèrent une erreur lors de la sauvegarde.
Le script permet de créer un dossier au format date et heure/minutes du jour pour sauvegarder les zones à l'intérieur, ce qui permet d'avoir plusieurs enregistrements par jour/semaine et évite l'écrasement. Généralement, cette partie n'est pas répliquée ni nettoyée.
La taille des zones DNS pour les grandes entreprises ne dépasse généralement pas quelques Ko, voire 4 ou 5 Mo, ce qui nous permet d'avoir plusieurs sauvegardes sans risque d'occuper trop d'espace sur le disque.
Intéressons-nous au code du script et à sa logique de fonctionnement.
La partie suivante permet de créer un dossier horodaté.
$backupDate = Get-Date -Format 'yyyy-MM-dd-HHmm'
$backupDirectory = "$env:SystemRoot\system32\dns\Backup\$backupDate"
New-Item -ItemType Directory -Path $backupDirectory -ErrorAction StopEnsuite, nous exclurons les zones non utiles, et effectuerons une sauvegarde.
$zonesToExclude = @( '0.in-addr.arpa', '127.in-addr.arpa', '255.in-addr.arpa')
Try {
Write-Output "Backup zonename : $($_.ZoneName)"
Export-DnsServerZone -Name $_.ZoneName -FileName Backup\$backupDate\Backup.$($_.ZoneName).$zoneBackupDate -ErrorAction Stop
}Le script nécessite les droits administratifs du domaine ou d'administrateur DNS pour effectuer la sauvegarde. La commande PowerShell ne permet pas d'effectuer la sauvegarde sur un serveur distant nativement, mis à part l'utilisation de la commande "Invoke-Script".
Il est alors judicieux de l'exécuter sur le contrôleur de domaine. Il n'est pas nécessaire de l'exécuter sur tous les contrôleurs de domaine si les zones sont répliquées. Idéalement le DC ayant le rôle PDC, car c'est celui qui orchestre le plus souvent les changements. Toutefois, le choix peut être décidé selon l'architecture de l'entreprise, notamment en cas d'un foret multi-domaine.
Le script est disponible sur GitHub, ce qui garantira sa maintenance et ses mises à jour, ainsi que d'éventuelles améliorations.
Pour exécuter le script, veuillez l'ouvrir ou copier son contenu à l'aide d'un éditeur ISE, puis cliquez sur "Exécuter".
Vous remarquerez dans la sortie le nom des zones sauvegardées.
Un dossier contenant les sauvegardes est créé dans le chemin par défaut.
Dans le dossier, vous trouverez les enregistrements sous format ".dns". Il est possible d'explorer ces fichiers à l'aide d'un éditeur de texte.
La principale raison du développement du script est la sauvegarde automatisée. Pour cela, nous allons créer une tâche planifiée pour exécuter le script, à l'aide du "Planificateur de tâches" de Windows Server.
Voici les étapes à suivre :
Si vous avez besoin d'aide à ce sujet :
Dans l'onglet "Déclencheurs", cliquez sur "Nouveau".
Choisissez l'heure qui vous convient pour l'exécution de la sauvegarde automatique.
Dans notre cas, nous avons choisi d'exécuter la sauvegarde à 10h et à 15h. Cette planification permet de minimiser l'écart entre les enregistrements DNS sauvegardés et la sauvegarde complète du contrôleur de domaine prévue pour le soir à 21h. De cette manière, nous nous assurons d'avoir peu d'écart dans les enregistrements DNS tout au long de la journée, ainsi que lors de la sauvegarde principale.
Répétez l'opération pour créer un second déclencheur correspondant à la seconde sauvegarde.
Dans l'onglet "Actions" cliquez sur "Nouveau"
Choisissez ensuite "Démarrer un programme", saisissez "Powershell.exe" et dans les arguments, entrez :
-file <chemin complet vers votre script>Validez ensuite par "OK".
Pour vérifier si le script s'est exécuté correctement, rendez-vous dans l'historique des tâches après avoir exécuté la tâche planifiée une première fois.
Votre contrôleur de domaine crée désormais automatiquement des sauvegardes de toutes vos zones DNS.
Nous verrons dans un prochain article comment restaurer une zone DNS à partir d'une sauvegarde.
La sauvegarde régulière des zones DNS permet de réduire les interruptions de service en cas de problème et soulage la charge sur les solutions de sauvegarde qui ne peuvent pas effectuer de sauvegarde en continu. Il est utile d'avoir plusieurs sauvegardes des zones DNS pour pouvoir les comparer facilement en cas de besoin à l'aide d'un fichier CSV ou Excel, ou pour récupérer une entrée supprimée.
Il est à noter que les zones intégrées dans l'Active Directory seront toujours disponibles et pourront être récupérées à partir d'une procédure différente, que nous aborderons dans un prochain article.
The post Active Directory : comment automatiser la sauvegarde des zones DNS ? first appeared on IT-Connect.
PowerShell est le nouveau shell de Windows qui permet aux administrateurs de passer toutes sortes de commandes sur Windows 10 et Windows 11.
Il possède aussi des cmdlet pour gérer la base de registre Windows.
Ainsi vous pouvez sans problème manipuler le registre Windows en PowerShell.
Grâce à ce tutoriel, vous allez comprendre comment créer, modifier, effacer des clés du registre Windows en PowerShell et bien plus.
Afin de ne pas rencontrer des problèmes d’autorisations et permissions sous la forme de message d’accès refusé lors de la modification du registre Windows en Powershell, ouvrez ce dernier en administrateur.
Pour cela :
Plus d’informations : Comment ouvrir PowerShell
Voici comment lister une clé du registre Windows en PowerShell.
On utilise Get-Item avec le caractère * pour lister en récursif.
Get-Item -Path 'HKCU:\SOFTWARE\SysInternals\*'Une autre méthode pour lister le contenu du registre Windows en PowerShell consiste à utiliser Get-childitem.
Tout d’abord on se positionne sur la clé à lister avec Set-location :
Set-location -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Puis on utilise Get-childitem :
Get-childitemPour recherche une clé dans le registre Windows PowerShell, on utilise Get-childitem.
Ici on recherche des valeurs Chrome dans HCKU (HKEY_CURRENT_USER) :
Get-childitem -path hkcu:\ -recurse -ErrorAction SilentlyContinue | Where-Object {$_.Name -like "*chrome*"}Voici comment créer une nouvelle clé dans le registre Windows en PowerShell :
Get-Item -Path 'HKLM:\Software\Policies\Microsoft\Windows' | New-Item -Name 'Windows Search' -ForcePar exemple pour créer une valeur DWord en PowerShell, ici une clé AllowIndexingEncryptedStoresOrItems :
New-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows\Windows Search' -Name 'AllowIndexingEncryptedStoresOrItems' -Value "1" -PropertyType DWORD -ForcePar exemple pour ajouter un programme au démarrage de Windows en modifiant la clé Run :
Set-Itemproperty -path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run' -Name 'MonProgramme' -value 'C:\Program Files\MonProgramme\monprogramme.exe'Voici comment modifier une valeur de clé du registre Windows en PowerShell.
Ici on passe la valeur HideSCAVolume à 0 :
Set-ItemProperty -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer -Name HideSCAVolume -Value 0 -ForcePar exemple pour supprimer la clé CleASupprimer du registre Windows en PowerShell :
Remove-Item -Path HKCU:\Software\CleASupprimer -Force -VerbosePour supprimer une valeur du registre Windows, on utilise le cmdlet Remove-ItemProperty :
Remove-ItemProperty -Path 'HKCU:\Software\CleASupprimer' -Name "ValeurASupprimer"Le cmdlet Rename-Item permet de renommer une clé du registre Windows en Powershell :
Rename-Item -Path "HKCU:\test\cle1" cle2Pour modifier une valeur avec Rename-ItemProperty :
Rename-ItemProperty -Path "HKCU:\dummy\cle1" -Name "valeur1" -NewName "valeur2"Pour lister des valeurs du registre Windows sur le PC distant “NomduPC” en PowerShell, on utilise Invoke-Command :
Invoke-Command -ComputerName NomDuPC -ScriptBlock { Get-ItemProperty -Path 'HKCU:\Software\System' -Name WorkingDirectory}L’article Créer, modifier, effacer des clés du registre Windows en PowerShell est apparu en premier sur malekal.com.
Le journal des événements Windows est un outil important qui permet aux administrateurs de suivre les erreurs, les avertissements et les autres rapports d’information consignés par le système d’exploitation, ses composants ou ses programmes.
Vous pouvez utiliser le snap-in graphique MMC de l’Observateur d’événements (eventvwr.msc) pour afficher le journal des événements de Windows. Dans certains cas, il est beaucoup plus pratique d’utiliser PowerShell pour analyser les informations des journaux d’événements. Dans cet article, vous apprendrez à utiliser la cmdlet Get-WinEvent pour obtenir des informations à partir des journaux d’événements Windows.
Lorsque vous utilisez la commande sans aucun paramètre, PowerShell liste l’ensemble des journaux Windows.
Get-WinEventPour filtrer sur un journal, utilisez l’option -LogName suivi du nom.
Get-WinEvent -LogName system
Get-WinEvent -LogName securityAutre exemple pour récupérer tous les évènements “disk” avec une erreur matériel (Microsoft-Windows-Kernel-WHEA) !
Get-WinEvent -LogName *disk*, Microsoft-Windows-Kernel-WHEADe plus, vous pouvez restreindre le nombre d’évènements grâce l’option -MaxEvents.
Get-WinEvent -LogName Application -MaxEvents 30Par défaut, la commande affiche les colonnes Date de création, Id, niveau du message et message.
Pour afficher ou masquer des colonnes, utilisez la cmdlet Format-table comme ceci.
Get-WinEvent -LogName System | Format-Table Machinename, TimeCreated, Id, UserID, MessageNous l’avons vu il est possible de filtrer sur un journal.
Pour obtenir la liste complète, utilisez la commande suivante :
Get-WinEvent -ListLog *Puis utilisez le paramètre LogName pour spécifier le journal des événements de Windows PowerShell
Get-WinEvent -LogName Microsoft-Windows-Winlogon/OperationalOu encore pour obtenir les événements d’erreur dont le nom contient une chaîne de caractères spécifiée :
Get-WinEvent -LogName *PowerShell*, Microsoft-Windows-Kernel-WHEA* | Group-Object -Property LevelDisplayName, LogName -NoElement Group-Object -Property LevelDisplayName, LogName -NoElement | Format-Table -AutoSizeL’argument FilterHashtable vous permet de filtrer en fonction des attributs d’événements suivants :
Extraire tous les journaux d’événements de Windows Defender en direct :
Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Windows Defender/Operational"}Beaucoup d’évènements identiques sont répétés.
Pour compter le nombre d’évènement par leur EventID :
Get-WinEvent -LogName "Windows PowerShell"| Group-Object -Property Id -NoElement | Sort-Object -Property Count -DescendingVous pouvez avoir besoin de filtrer des évènements des journaux Windows.
Par exemple, si vous souhaitez obtenir des informations sur les erreurs et les avertissements des journaux Système et Application pour les dernières 24 heures, utilisez le code suivant :
$StartDate = (Get-Date) - (New-TimeSpan -Day 1)
Get-WinEvent Application,System | Where-Object {($_.LevelDisplayName -eq "Error" -or $_.LevelDisplayName -eq "Warning") -and ($_.TimeCreated -ge $StartDate )}Si vous avez besoin de trouver des événements par EventID, utilisez la commande suivante avec le paramètre FilterHashtable :
Get-WinEvent -FilterHashtable @{logname='System';id=1074}|ft TimeCreated,Id,MessageSi vous souhaitez chercher des évènements sur un mot clé, vous pouvez aussi utiliser cette syntaxe :
Get-WinEvent -FilterHashtable @{logname='System'}|Where {$_.Message -like "*erreur*"}Vous pouvez très facilement exporter les journaux Windows grâce à l’option -FilterXML
Voici un exemple d’export en CSV :
$Events= Get-WinEvent -FilterXML $xmlQuery
$events| Export-CSV "C:\outils\FiltresJournauxWindows.csv" -NoTypeInformation -Encoding UTF8L’article Interroger les journaux d’événements Windows avec PowerShell est apparu en premier sur malekal.com.
Dans ce tutoriel, nous allons voir comment calculer le hash d'un fichier avec PowerShell ! Depuis PowerShell 4.0, le cmdlet nommé "Get-FileHash" est présent et il permet de calculer le hash d'un ou de plusieurs fichiers selon plusieurs algorithmes.
PowerShell 4.0 est disponible nativement depuis Windows 8.1 et Windows Server 2012 R2, ce qui en fait une version très largement répandue aujourd'hui.
Le hash d'un fichier est souvent utilisé pour vérifier l'intégrité du fichier. Les algorithmes de hachage couramment utilisés comprennent MD5, SHA-1, SHA-256, etc. Chacun de ces algorithmes produit un hash de longueur différente.
Par exemple, si vous téléchargez un fichier à partir d'Internet, vous pouvez comparer le hash du fichier téléchargé avec le hash fourni par le site web pour vous assurer que le fichier n'a pas été altéré pendant le téléchargement. Si les deux valeurs sont égales, vous pouvez affirmer que le fichier est authentique (vis-à-vis de la version d'origine). Ceci peut s'avérer utile aussi pour de l'échange de données.
Vous pouvez calculer le hash des différents types de fichiers : images ISO, packages d'installation d'applications (EXE, MSI, etc.), et tout autre fichier selon vos besoins.
Version originale de l'article : 11 décembre 2013.
Intéressons-nous au cmdlet évoqué en introduction de cet article.
Voici la syntaxe à utiliser :
Get-FileHash -Algorithm <Nom-algorithme> -Path <Chemin-vers-fichier>
Concernant les algorithmes, voici ceux disponibles avec Windows PowerShell 5.1 :
Attention, avec PowerShell 7, le nombre d'algorithmes pris en charge est différent et plus limité : MD5, SHA1, SHA256, SHA384 et SHA512. Dans les deux cas, SHA256 est la valeur par défaut du paramètre "-Algorithm".
Ouvrez une console pour essayer la commande. Par exemple, pour calculer le hash SHA1 du fichier "it-connect.txt" situé dans "C:\files\" :
Get-FileHash -Algorithm SHA1 -Path "C:\files\it-connect.txt"
Cela donnera un résultat de ce type où l'on voit le hash :
Que faire de cette information ? La valeur du hash retournée ici peut être comparée avec la valeur de hash fournie sur le site depuis lequel vous avez téléchargé le fichier. Sinon, vous pouvez aussi calculer le hash et au moment de transmettre le fichier à quelqu'un, vous lui fournissez aussi le hash. Ceci lui permettra de vérifier l'authenticité du fichier reçu.
Vous pouvez aussi calculer le hash d'un ensemble de fichiers. Voici un exemple :
Get-FileHash -Algorithm SHA256 -Path *.* | Format-List Path,HashCi-dessous, le résultat en image. Le résultat est identique à chaque fois, car il s'agit d'un même fichier dupliqué : d'ailleurs le hash identique permet de l'affirmer.
Vous êtes désormais en mesure de calculer un hash facilement sous Windows, avec une commande simplissime mais à connaître : Get-FileHash.
The post PowerShell : comment calculer le hash d’un fichier ? first appeared on IT-Connect.
Maester est un projet communautaire créé en avril 2024 par Merill Fernando, chef de produit chez Microsoft et deux MVP Security Fabian Bader et Thomas Naunheim. C’est un outil PowerShell conçu pour vous aider à comprendre la configuration de votre tenant Microsoft 365.
Il vous permet d’avoir une vision de votre configuration par rapport aux bonnes pratiques de sécurité, et ainsi, surveiller la posture de sécurité de votre tenant Microsoft 365. Cet outil fournit un rapport, mais ne réalise aucune action de correction.
À l’heure actuelle, l’outil contient 92 vérifications de sécurité, toutes concentrées sur la partie Microsoft Entra. Ces vérifications proviennent de plusieurs sources :
Maester réalise plusieurs vérifications de sécurité, incluant :
Avant de rentrer dans le vif du sujet, voici le lien vers le site officiel du projet :
Maester utilise l'API Microsoft Graph pour accéder aux informations de votre tenant Microsoft 365. Cet outil vérifie la conformité de votre configuration par rapport aux bonnes pratiques de sécurité. L’originalité de cet outil réside dans l’utilisation de Pester pour vérifier cette conformité.
Pester est un module PowerShell conçu pour les tests unitaires. Bien qu’il soit souvent utilisé pour valider des scripts ou des fonctions, son mode de fonctionnement permet à chacun d’écrire ses propres tests unitaires.
Dans le cas de Maester, Pester est employé pour s'assurer que la configuration de votre tenant Microsoft 365 correspond aux critères définis dans des fichiers. Ces fichiers, appelés fichiers de tests dans la suite de l’article, permettent de réaliser des vérifications sur la conformité de votre configuration. L’appellation tests provient du fait que Pester suit une nomenclature stricte concernant les fichiers qu’ils utilisent : xxxx.Tests.ps1.
Cela permet ainsi une vérification rigoureuse et continue de la sécurité d’un tenant.
Il est important de comprendre que Maester, utilisant Pester, ne fournit pas de valeurs directes de votre tenant, mais indique plutôt si vos configurations respectent les normes établies dans les fichiers Tests.
Par exemple, au lieu de spécifier le nombre d'administrateurs globaux, Maester vous informera si la configuration est conforme aux bonnes pratiques définies dans les tests. Cette méthode peut représenter une nouvelle approche pour certains qu’il est essentiel de comprendre.
Maester est publié dans la PowerShell Gallery, son installation peut être réalisée en seulement deux Cmdlets :
Install-Module Pester -SkipPublisherCheck -Force -Scope CurrentUser
Install-Module Maester -Scope CurrentUserSur votre PC, il faut ensuite créer un dossier et installer les fichiers de tests. Dans notre cas, nous installerons les fichiers Tests dans "C:\temp", mais tout autre chemin fonctionnera.
cd c:\temp
mkdir maester-tests
cd maester-tests
Install-MaesterTests .\testsLes fichiers de tests sont installés dans C:\Temp\maester-tests\tests.
Dans un premier temps, il faut se connecter :
Connect-MaesterComme indiqué plus haut, Maester s’appuie sur Microsoft Graph. Si vous n’avez pas les autorisations requises, il faudra autoriser les autorisations OAuth pour l’application Microsoft Graph Command Line Tools.
Ensuite, vous pouvez exécuter les tests :
Invoke-MaesterÀ la fin de l'exécution des tests par Maester, un bref résumé est affiché dans la console.
Ce résumé indique les résultats des tests avec le nombre de tests réussis, échoués ou ignorés, fournissant ainsi un aperçu rapide de l'état de la configuration de sécurité de votre tenant Microsoft 365.
Un fichier de rapport HTML est aussi créé, il est stocké dans le dossier "tests-results" et s’ouvre automatiquement dans votre navigateur :
Un élément en "Passed" indique que la configuration de votre tenant respecte le test en question.
Un élément en "Failed" indique que la configuration de votre tenant ne respecte le test. Cependant, selon les contraintes de votre entreprise, il convient de statuer si c’est un réel problème, ou bien un risque accepté.
Pour chaque élément du rapport, vous retrouverez :
Pour la majorité des tests, il est évident de comprendre pourquoi un test échoue, comme une fonctionnalité non activée ou un nombre excessif d'utilisateurs non conformes.
Cependant, il peut être plus complexe de déterminer la cause d'un échec dans certains cas, où le problème pourrait ne pas résider dans la non-conformité, mais plutôt dans un bug au sein du code PowerShell du test lui-même. Dans ces situations, il sera nécessaire d'examiner en détail les fichiers "*.Tests.ps1" pour identifier et résoudre l'erreur.
Le gros intérêt de Maester est que ce n’est qu’un framework, c’est-à-dire qu’il peut être étendu pour correspondre à vos besoins avec des tests personnalisé.
Pour créer un test personnalisé dans Maester, vous devez suivre une certaine structure. Par exemple, nous allons créer un test pour vérifier qu'un groupe contient exactement deux membres.
Pour cela, créez un fichier nommé "Test-CustomITConnect.Tests.ps1" dans le répertoire "<chemin>\maester-tests\Custom". Pester recherche les fichiers se terminant par ".Tests.ps1" pour les exécuter comme des tests.
Dans notre cas, nous créons un fichier" Test-CustomITConnect.Tests.ps1" dans "C:\temp\maester-tests".
Pour le contenu du fichier "Test-CustomITConnect.Tests.ps1", nous devons suivre la syntaxe Pester, ce qui donne :
Describe "Test-MyGroupMembership" -Tag "Group" {
It "Check 'MyGroup1' Members" {
$groupID = "cc831d2a-6e92-4988-903c-1799de3a9aa1"
$members = Get-MgGroupMember -GroupId $groupID
# Test if the group has exactly 2 members
$members.Count | Should -BeExactly 2
}
}Il est alors possible d’exécuter Maester avec uniquement notre test :
cd c:\temp\maester-test
Invoke-Maester .\tests\Custom\Le rapport contient uniquement notre test personnalisé.
À noter qu’il est aussi possible de simplement exécuter "Invoke-Maester", pour exécuter tous les tests, y compris les tests personnalisés.
Maester peut être configuré pour surveiller en permanence la configuration de votre tenant à l'aide de service DevOps comme Azure DevOps Pipeline, GitHub Actions et Azure Automation.
Avec ces solutions, il est possible de recevoir un e-mail régulier avec les informations concernant la sécurité du tenant.
La configuration de cette automatisation n’est pas détaillée dans cet article, mais vous pouvez retrouver toutes les informations dans la documentation de Maester.
L'équipe Maester ajoute de nouveaux tests au fil du temps, il faut donc penser à mettre à jour le module et les tests de temps en temps.
cd <chemin>maester-tests\testsMettre à jour le module Maester :
Update-Module Maester -Force
Import-Module MaesterMettre à jour les tests Maester :
Update-MaesterTestsTous les tests personnalisés dans le dossier "/Custom" seront conservés.
Les fichiers de test des autres dossiers, notamment "/EIDSCA", "/Maester" et "/CISA", seront remplacés par les tests les plus récents :
Maester est une solution récente et se focalise pour le moment uniquement sur les tests Microsoft Entra ID. Cependant, compte tenu de son fonctionnement et de sa flexibilité, il est tout à faire possible de créer ses propres tests et de participer à ce projet communautaire.
Pour approfondir le sujet de l'audit Microsoft 365, vous pouvez consulter cet article :
The post Maester, l’outil pour automatiser vos tests de sécurité Microsoft 365 first appeared on IT-Connect.
Dans ce tutoriel, nous allons exploiter PowerShell pour créer un journal personnalisé et des événements personnalisés dans l'Observateur d'événements de Windows ou Windows Server, à l'aide de deux cmdlets : New-EventLog et Write-EventLog. En complément, nous verrons comment utiliser la classe .NET "EventLog" pour créer des entrées avancées.
Sur Windows, le système d'exploitation, les composants et les applications peuvent générer des événements qui sont inscrits dans les différents journaux centralisés dans l'Observateur d'événements. Ces journaux sont une mine d'informations pour les administrateurs systèmes, mais aussi pour les équipes en charge de la sécurité : une action suspecte peut être consignée dans un événement, qui représentera alors une trace intéressante.
L'intérêt ensuite est de collecter ces événements dans un puits de logs ou un SIEM afin de les analyser et de détecter les comportements suspects ou les anomalies sur une infrastructure.
Grâce à la commande Write-EventLog ou à l'utilisation de la classe EventLog, nous pouvons alimenter les journaux de Windows avec des événements personnalisés qui, eux aussi, pourront être exploités par une solution telle qu'un SIEM. Autrement dit, votre script PowerShell pourra créer des événements contenant les informations de votre choix.
Remarque : avant de pouvoir utiliser Write-EventLog, cette action était possible sous Windows grâce à l'utilisation de l'utilitaire en ligne de commande EVENTCREATE.exe.
Au sein de l'Observateur d'événements, vous pouvez créer un journal personnalisé, associé au nom de votre choix, à condition que celui-ci ne soit pas déjà utilisé. Cette étape est facultative, car nous pouvons créer des enregistrements dans certains journaux natifs, notamment dans le journal "Applications" de Windows.
Néanmoins, le fait de créer un journal personnalisé et d'y inscrire par la suite nos propres événements, permet "d'isoler" nos événements personnalisés. Ceci peut vouloir dire également qu'il faudra adapter la configuration de votre outil de collecte de log pour qu'il prenne en charge ce nouveau journal.
La commande suivante permet de créer un journal nommé "PowerShell-Demo", qui accepte deux sources : "Script-1" et "Script-2". Vous pouvez en ajouter autant que vous le souhaitez, et, vous pouvez ajouter des sources supplémentaires à un journal existant. Ceci est indispensable, car chaque événement de journal doit être associé à une source.
New-EventLog -LogName "PowerShell-Demo" -Source "Script-1","Script-2"Ce journal sera immédiatement visible dans l'Observateur d'événements sous "Journaux des applications et des services".
D'ailleurs, pour ajouter une source supplémentaire, il suffit d'exécuter une nouvelle fois New-EventLog en indiquant le nom du journal et le nom de la source supplémentaire à ajouter. Voici un exemple pour ajouter la source "Script-3" :
New-EventLog -LogName "PowerShell-Demo" -Source "Script-3"Si vous effectuez une erreur, par exemple, dans le nom de votre journal, sachez que vous pouvez le supprimer avec cette commande :
Remove-EventLog -LogName "PowerShell-Demo"Pour approfondir l'utilisation de ce cmdlet, vous pouvez consulter cette page :
Désormais, nous allons voir comment écrire un nouvel événement dans le journal d'événements que nous venons de créer. Nous pourrions aussi l'ajouter dans un autre journal (attention, certains sont protégés), tout se joue au niveau du paramètre "-LogName" de la commande Write-EventLog puisqu'il permet de préciser le journal cible.
Comme pour les autres cmdlets PowerShell, vous pouvez spécifier le nom du cmdlet suivi de chaque paramètre et de sa valeur, mais dans le cas présent, l'écriture proposée ci-dessous permet d'avoir une meilleure lisibilité.
$Event = @{
LogName = "PowerShell-Demo"
Source = "Script-1"
EntryType = "Error"
EventId = 10000
Message = "Cette alerte a été généré depuis PowerShell"
}
Write-EventLog @EventCe bout de code va créer un événement de type "Erreur" dans notre journal, associé à la source "Script-1" et l'ID "10000". Il contiendra le message "Cette alerte a été généré depuis PowerShell", comme vous pouvez le voir sur l'image ci-dessous. Essayez d'utiliser des ID différents pour vos types d'événements, et évitez aussi d'utiliser des ID déjà utilisé par Windows.
À la place du type "Error" permettant de générer une erreur, vous pouvez utiliser les valeurs suivantes : Warning, Informational, SuccessAudit, et FailureAudit. Sachez que cette commande prend en charge le paramètre "-ComputerName", ce qui permet de créer un événement dans le journal d'un ordinateur distant.
Pour consulter ce journal personnalisé, ou un autre journal, vous pouvez utiliser le cmdlet PowerShell "Get-EventLog". Bien que ce cmdlet soit très pratique, il ne permet pas d'accéder à tous les journaux, donc sachez qu'il existe aussi un second cmdlet prévu pour consulter les journaux : "Get-WinEvent".
Voici la commande à utiliser pour récupérer les logs de notre journal :
Get-EventLog -LogName "PowerShell-Demo"Pour approfondir l'utilisation de ces cmdlets, vous pouvez consulter ces pages :
Pour aller plus loin dans l'écriture d'événements dans un journal Windows, il convient d'exploiter la classe EventLog directement depuis PowerShell. Celle-ci va nous permettre d'ajouter des données mieux structurées dans notre événement, notamment dans la section "EventData" visible à partir de la vue XML. C'est utile pour stocker plusieurs informations tout en permettant de récupérer de façon indépendante chaque information.
Voici un exemple :
Nous avons mis en pratique cette méthode dans ce tutoriel :
Ceci complexifie l'inscription d'un nouvel événement, car nous devons créer nos propres objets et nous passer de l'utilisation de Write-EventLog. Un premier objet "System.Diagnostics.EventInstance" permettra d'indiquer le numéro d'ID et le type d'événements, tandis qu'un second objet "System.Diagnostics.EventLog" permettra de préciser les données de l'événement.
Néanmoins, pour que l'utilisation reste simple, nous vous proposons d'utiliser cette fonction :
function Write-EventLogV2 {
<#
.SYNOPSIS
Crée un évènement dans l'observateur d'évènement
.DESCRIPTION
La fonction utilise la CmdLet WriteEvent pour créer un évènement à partir des paramètres d'entrée.
.PARAMETER dataUser
Nom utilisateur qui sera inscrit dans le contenu de l'évènement à créer
.PARAMETER dataDescription
Contenu de la description qui sera inscrite dans le contenu de l'évènement à créer
.PARAMETER ID
Event ID de l'évènement à créer
.PARAMETER evtLog
Journal de l'évènement à créer
.PARAMETER evtSource
Source de l'évènement à créer
.EXAMPLE
New-EventLog -dataUser "John" -dataDescription "new description"
.OUTPUTS
None
#>
param(
[Parameter(Mandatory=$true)]$dataUser,
$dataDescription="",
$ID=10000,
$evtLog="PowerShell-Demo",
$evtSource="Script-2"
)
# Charge la source d'événement dans le journal si elle n'est pas déjà chargée.
# Cette opération échouera si la source d'événement est déjà affectée à un autre journal.
if ([System.Diagnostics.EventLog]::SourceExists($evtSource) -eq $false) {
[System.Diagnostics.EventLog]::CreateEventSource($evtSource, $evtLog)
}
# Construire l'événement et l'enregistrer
$evtID = New-Object System.Diagnostics.EventInstance($ID,1)
$evtObject = New-Object System.Diagnostics.EventLog
$evtObject.Log = $evtLog
$evtObject.Source = $evtSource
$evtObject.WriteEvent($evtID, @($dataUser,"Description : $dataDescription"))
}En entrée, cette fonction accepte deux messages ($dataUser et $dataDescription - vous pouvez renommer ces paramètres dont le nom a été choisi vis-à-vis du script d'origine), un numéro d'ID (par défaut, ce sera 10000), le nom d'un journal d'événement (par défaut, ce sera "PowerShell-Demo") ainsi qu'une source (par défaut, ce sera "Script-2").
De plus, par défaut, cette fonction génère des événements de type "Information". Si vous souhaitez changer le type d'événement, vous devez ajuster la valeur présente sur cette ligne :
$evtID = New-Object System.Diagnostics.EventInstance($ID,1)En effet, la première valeur correspond à l'ID souhaité, ici associé à la variable $ID, tandis que la seconde valeur correspond au type d'événement. Le 1 correspond au type "Information".
Ce qui permettra de générer des événements similaires à celui-ci :
Si besoin, vous pouvez ajouter d'autres valeurs dans la seconde partie de "$evtObject.WriteEvent" pour avoir des lignes "<Data>" supplémentaires.
En suivant ce tutoriel, vous devriez être en mesure de créer vos propres événements personnalisés dans les journaux Windows, que ce soit dans un journal existant ou dans votre propre journal à l'aide de PowerShell ! Libre à vous d'utiliser ces cmdlets ou cette fonction dans vos scripts, et de les adapter à vos besoins ! En tout cas, ceci ouvre des possibilités très intéressantes !
The post Comment utiliser PowerShell pour créer un événement dans un journal Windows ? first appeared on IT-Connect.
Des chercheurs en sécurité soupçonnent les cybercriminels d'avoir utilisé l'IA générative dans le cadre d'une attaque pour générer un script PowerShell. Il a été utilisé pour distribuer un malware infostealer. Faisons le point !
En mars 2024, les chercheurs en sécurité de chez Proofpoint ont identifié une campagne malveillante ciblant des dizaines d'organisations allemandes et associées au groupe de pirates suivi sous le nom de TA547, et connu également sous le nom de Scully Spider. Il s'agirait d'un groupe actif depuis 2017 et appartenant à la catégorie des "initial access broker" (courtier d'accès initial).
"Outre les campagnes menées en Allemagne, d'autres organisations ont été ciblées récemment en Espagne, en Suisse, en Autriche et aux États-Unis.", peut-on lire dans le rapport de Proofpoint.
Lors de cette campagne, les pirates ont tenté d'usurper l'identité de la marque allemande Metro en envoyant des e-mails malveillants avec une facture, au format ZIP, en pièce jointe. Pour échapper aux analyses de sécurité, ce fichier ZIP est protégé par le mot de passe "MAR26". Il contient un fichier de raccourci malveillant (.LNK) qui, lorsqu'il est exécuté, déclenche l'exécution d'un script distant via PowerShell.
L'objectif final est d'infecter la machine avec le logiciel malveillant "Rhadamanthys", de type infostealer. Ce malware a pour objectif de voler des données sur chaque machine infectée, notamment des identifiants et des cookies.
Les chercheurs en sécurité ont procédé à l'analyse du script PowerShell utilisé par les cybercriminels. Et, ils ont été surpris de constater que chaque ligne de code était précédée par un commentaire, très bien rédigé, comme ceux intégrés par l'IA lorsqu'on lui demande de l'aide pour un bout de code.
Voici un extrait du script PowerShell en question :
Les chercheurs affirment que c'est une caractéristique typique d'un code PowerShell généré avec l'aide d'une IA générative, que ce soit ChatGPT, Gemini ou Microsoft Copilot. Bien que ce ne soit pas certain à 100%, il y a de fortes chances pour que les cybercriminels aient utilisé l'IA pour écrire ou réécrire le code.
Cela signifierait que dans le cadre de cette campagne malveillante, les pirates du groupe TA547 ont recouru à l'IA. Bien entendu, cela n'est qu'un exemple parmi d'autres et dans le cas présent, l'IA pouvait difficilement se douter qu'il s'agissait d'un code PowerShell utilisé à des fins malveillantes.
The post Un script PowerShell surement codé par l’IA a été utilisé pour distribuer un malware infostealer first appeared on IT-Connect.
Il arrive qu'il y ait un grand nombre de sessions RDP sur un serveur Windows (environnement TSE/RDS ou non). Chaque connexion déconnectée continue de consommer des ressources comme CPU et RAM.
Voici comment fermer les sessions déconnecter en une ligne de commande PowerShell.
C'est grâce à quser que nous pouvons identifier les sessions déconnectées qui ne sont pas fermées :
quser | Where-Object { $_ -notmatch (Get-Date).ToString("dd/MM/yyyy") } | Select-String "Déco" | ForEach {logoff ($_.tostring() -split ' +')[2]}
Que fait cette commande ?
Cette commande ferme toutes les sessions déconnectées qui ne datent pas d'aujourd'hui. En effet je considère qu'une session déconnectées depuis plus d'un jour n'a rien à faire sur une serveur.
Cela peut engendrer une perte de données si vos utilisateurs ont un logiciel ouvert (comme Word) parce que la session sera fermée en mode forcé (les modifications non enregistrées seront perdues).
Il est vrai que sur Windows Server la traduction française ne permet à l'utilisateur de comprendre la différence entre :
La première option laisse la session ouverte en arrière plan tandis que la seconde la ferme complètement. Microsoft aurait pu choisir "fermer la session" pour ce soit plus clair pour tout le monde.
Si vous êtes sur une machine Windows Server en langue anglais la ligne de commande ne fonctionnera pas.
Voici une version qui fonctionne en anglais et en français :
quser | Where-Object { ($_ -like '*Déco*' -or $_ -like '*Disc*') -and $_ -notmatch (Get-Date).ToString("dd/MM/yyyy") } | ForEach { logoff ($_.ToString() -split ' +')[2] }
La limite de cette ligne de commande est que le nom d'utilisateur ne devra jamais contenir "déco" ou "Disc" car c'est cet élément qui permet d'identifier une session déconnectée, sinon la session sera systématiquement fermée.
Je vous conseille de définir une politique pour limiter la durée des sessions, qu'elles soient actives ou inactives. Vous pouvez le faire par GPO ou bien directement dans les propriétés de votre collection RDS.
Ainsi vous n'aurez même pas besoin d'utiliser cette astuce.
Pour créer une limite de connexion sur votre ferme RDS suivez ce tutoriel.
Si vous faites partie de ceux qui doivent fermer les sessions RDP d'un serveur sur lequel beaucoup de monde "oublie" de se déconnecter, cela devrait vous faire gagner du temps. Que l'on parle d'une ferme RDS, d'un serveur RDS avec ou sans CAL.
Si vous souhaitez que ce script fonctionne en automatique ne le faites pas via le planificateur de tâches, mais par GPO. Et cela ne vous empêche pas de faire une communication *avant* pour avertir les utilisateurs, be smart
Vous n'aimez pas le RSS : abonnez-vous par email
Article original écrit par Mr Xhark publié sur Blogmotion le 10/04/2024 |
2 commentaires |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons
