Exemples d'utilisation

Ici, vous trouverez des exemples pratiques d’utilisation du module dans des scénarios réels. Ces exemples sont conçus pour vous aider à comprendre comment appliquer les fonctionnalités du module.

Voici des exemples un peu plus approfondis et contextuels. Si vous souhaitez uniquement l’utilisation des commandes du module, consultez la référence des commandes.

1 - Flux de travail d'analyse de sécurité avec SQL Server

Convertissez les journaux de débogage DNS en CSV avec DNSServer.DebugLogParser, importez le résultat dans SQL Server, et exécutez une requête simple pour détecter une activité suspecte sur les enregistrements TXT.

Cet exemple montre un flux de travail pratique pour l’analyse de sécurité : analyser un journal de débogage DNS avec Convert-DNSDebugLogFile, importer le CSV généré dans SQL Server, et exécuter une requête qui met en évidence des volumes anormalement élevés de requêtes sur les enregistrements TXT.

Pour une meilleure interopérabilité, cet exemple écrit les horodatages dans un format proche de l’ISO en utilisant -OutputCulture 'sv-SE'.

Modules requis

Cet exemple utilise les modules PowerShell suivants :

  • DNSServer.DebugLogParser
  • SqlServer

Installe-les si besoin :

Install-Module -Name DNSServer.DebugLogParser -Scope CurrentUser
Install-Module -Name SqlServer -Scope CurrentUser

Scénario

Utilise ce flux de travail lorsque tu souhaites transférer les données analysées d’un journal de débogage DNS dans SQL Server afin de pouvoir :

  • rechercher efficacement dans de grands ensembles de données
  • créer des requêtes de détection répétables
  • corréler l’activité entre plusieurs serveurs DNS
  • conserver des données normalisées pour des investigations ultérieures

Résultat de l’étape de conversion

Convert-DNSDebugLogFile n’écrit pas directement dans SQL Server. Il crée d’abord un fichier CSV. Ce fichier CSV est le jeu de données importé dans la base.

Dans cet exemple :

  • journal d’entrée : C:\Administration\Logs\DNS\dns.log
  • CSV généré : C:\Administration\Logs\DNS\dns.csv
  • table cible : dbo.DNSQueries

Créer la table cible

Exécute la commande suivante une fois dans SQL Server pour créer la table cible.

IF OBJECT_ID('dbo.DNSQueries', 'U') IS NULL
BEGIN
    CREATE TABLE dbo.DNSQueries (
        DateTime      datetime2(0)   NOT NULL,
        ThreadId      int            NULL,
        Context       nvarchar(20)   NULL,
        PacketId      int            NULL,
        Protocol      nvarchar(10)   NULL,
        Direction     nvarchar(10)   NULL,
        ClientIP      nvarchar(64)   NULL,
        Xid           nvarchar(16)   NULL,
        Type          nvarchar(16)   NULL,
        Opcode        nvarchar(16)   NULL,
        FlagsHex      nvarchar(16)   NULL,
        FlagsChar     nvarchar(16)   NULL,
        ResponseCode  nvarchar(32)   NULL,
        QuestionType  nvarchar(32)   NULL,
        QuestionName  nvarchar(512)  NULL,
        Information   nvarchar(max)  NULL,
        Details       nvarchar(max)  NULL,
        ComputerName  nvarchar(256)  NULL
    );
END;

Convertir le journal et importer le CSV

L’exemple PowerShell suivant réalise le flux complet :

  1. importe les modules requis
  2. convertit le journal de débogage DNS en CSV
  3. charge le CSV généré
  4. importe en masse les lignes dans SQL Server
# Requires -Modules DNSServer.DebugLogParser, SqlServer

Import-Module -Name DNSServer.DebugLogParser -ErrorAction Stop
Import-Module -Name SqlServer -ErrorAction Stop

$logPath = 'C:\Administration\Logs\DNS\dns.log'
$csvPath = 'C:\Administration\Logs\DNS\dns.csv'
$serverInstance = 'SQLServer'
$databaseName = 'DNSLogs'
$delimiter = ';'

$createTableSql = @'
IF OBJECT_ID('dbo.DNSQueries', 'U') IS NULL
BEGIN
    CREATE TABLE dbo.DNSQueries (
        DateTime      datetime2(0)   NOT NULL,
        ThreadId      int            NULL,
        Context       nvarchar(20)   NULL,
        PacketId      int            NULL,
        Protocol      nvarchar(10)   NULL,
        Direction     nvarchar(10)   NULL,
        ClientIP      nvarchar(64)   NULL,
        Xid           nvarchar(16)   NULL,
        Type          nvarchar(16)   NULL,
        Opcode        nvarchar(16)   NULL,
        FlagsHex      nvarchar(16)   NULL,
        FlagsChar     nvarchar(16)   NULL,
        ResponseCode  nvarchar(32)   NULL,
        QuestionType  nvarchar(32)   NULL,
        QuestionName  nvarchar(512)  NULL,
        Information   nvarchar(max)  NULL,
        Details       nvarchar(max)  NULL,
        ComputerName  nvarchar(256)  NULL
    );
END
'@

Convert-DNSDebugLogFile `
    -InputFile $logPath `
    -ComputerName 'DNS01' `
    -OutputType CSV `
    -OutputFile $csvPath `
    -Delimiter $delimiter `
    -OutputCulture 'sv-SE'

$rows = Import-Csv -Path $csvPath -Delimiter $delimiter

if (-not $rows) {
    throw "Le fichier CSV généré '$csvPath' ne contient aucune ligne."
}

$dataTable = [System.Data.DataTable]::new()
foreach ($columnName in $rows[0].PSObject.Properties.Name) {
    $null = $dataTable.Columns.Add($columnName, [string])
}

foreach ($row in $rows) {
    $dataRow = $dataTable.NewRow()
    foreach ($column in $dataTable.Columns) {
        $columnName = $column.ColumnName
        $dataRow[$columnName] = $row.$columnName
    }

    $null = $dataTable.Rows.Add($dataRow)
}

$connectionString = "Server=$serverInstance;Database=$databaseName;Integrated Security=True"
$connection = [System.Data.SqlClient.SqlConnection]::new($connectionString)

try {
    $connection.Open()

    $command = $connection.CreateCommand()
    $command.CommandText = $createTableSql
    $null = $command.ExecuteNonQuery()

    $bulkCopy = [System.Data.SqlClient.SqlBulkCopy]::new($connection)
    $bulkCopy.DestinationTableName = 'dbo.DNSQueries'

    foreach ($column in $dataTable.Columns) {
        $null = $bulkCopy.ColumnMappings.Add($column.ColumnName, $column.ColumnName)
    }

    $bulkCopy.WriteToServer($dataTable)
}
finally {
    $connection.Dispose()
}

Requête pour détecter une activité suspecte sur les enregistrements TXT

Une fois les données dans SQL Server, tu peux rechercher les clients qui émettent un nombre anormalement élevé de requêtes sur les enregistrements TXT.

SELECT
    ComputerName,
    ClientIP,
    QuestionName,
    COUNT(*) AS QueryCount
FROM dbo.DNSQueries
WHERE QuestionType = 'TXT'
GROUP BY
    ComputerName,
    ClientIP,
    QuestionName
HAVING COUNT(*) > 100
ORDER BY QueryCount DESC;

Si tu préfères exécuter la requête depuis PowerShell, utilise Invoke-Sqlcmd du module SqlServer :

$query = @'
SELECT
    ComputerName,
    ClientIP,
    QuestionName,
    COUNT(*) AS QueryCount
FROM dbo.DNSQueries
WHERE QuestionType = 'TXT'
GROUP BY
    ComputerName,
    ClientIP,
    QuestionName
HAVING COUNT(*) > 100
ORDER BY QueryCount DESC;
'@

Invoke-Sqlcmd `
    -ServerInstance 'SQLServer' `
    -Database 'DNSLogs' `
    -Query $query

Pourquoi les requêtes TXT sont intéressantes

Un volume élevé de requêtes sur les enregistrements TXT peut valoir la peine d’être examiné car cela peut indiquer :

  • un tunnel DNS
  • une exfiltration de données via DNS
  • un abus des enregistrements TXT par des malwares ou des outils
  • des clients anormalement bruyants ou mal configurés

Cette requête n’est qu’un point de départ. En production, tu devrais ajuster le seuil et ajouter des filtres adaptés à ton environnement.

Notes opérationnelles

  • Import-Csv charge le fichier complet en mémoire. Pour des exports de journaux très volumineux, envisage une approche en streaming plutôt que de construire un DataTable complet.
  • Garde -ComputerName dans l’étape de conversion pour que les enregistrements restent attribuables après ingestion centralisée.
  • Utilise un délimiteur et une culture cohérents lors de l’export et de l’import.
  • Vérifie la rétention, l’indexation et le contrôle d’accès dans SQL Server avant d’utiliser ce flux pour un stockage à long terme.

2 - Utilisation pratique dans un environnement de domaine (collection et conversion pilotées par GPO)

Cet exemple montre comment mettre en œuvre un flux de travail piloté par GPO pour collecter et convertir les journaux de débogage DNS sur les contrôleurs de domaine.

Ce document présente un exemple pratique complet d’exécution de DNSServer.DebugLogParser dans un environnement de domaine Active Directory, axé sur la conversion des journaux de débogage du serveur DNS Windows sur les contrôleurs de domaine.

Cet exemple est accompagné d’une archive ZIP, qui fournit les artefacts de stratégie utilisés pour mettre en œuvre le flux de travail décrit ici.
Les artefacts les plus pertinents sont le manifest de sauvegarde, le rapport GPO, le Files.xml, le Set-DNSServerDebugLogging.ps1, et le ScheduledTasks.xml.

Scénario

  • Plusieurs contrôleurs de domaine (DC) hébergent le rôle de serveur DNS.
  • Le journal de débogage DNS est activé et configuré de manière cohérente sur chaque DC via une tâche planifiée (écriture des fichiers journaux dans C:\Administration\Logs\DNSServer).
  • Un processus centralisé convertit les journaux en CSV pour :
    • l’analyse de sécurité
    • le reporting opérationnel
    • le dépannage
    • la conformité / conservation

Résultats visés

  • Paramètres de conversion cohérents sur tous les DC
  • Emplacement et nommage des fichiers de sortie prévisibles
  • Compression optionnelle pour réduire l’espace de stockage
  • Sorties statistiques optionnelles pour des synthèses quotidiennes rapides
  • Risque minimal côté hôte, avec des considérations explicites de relance et nettoyage

Architecture suggérée

Modèle de collecte : conversion locale + collecte centrale

  1. Chaque DC écrit les journaux de débogage DNS sur disque avec rotation activée.
  2. Chaque DC convertit les fichiers *.log archivés en CSV de données et CSV statistiques, puis compresse les sorties en *.zip selon un planning (Planificateur de tâches).
  3. Les sorties sont écrites à côté des fichiers journaux pour garder le pipeline simple.
  4. Un serveur central collecte les fichiers *.zip, par exemple via ingestion de partage de fichiers, copie planifiée, forwarder SIEM ou collecteur basé agent.

Ce modèle minimise les lectures réseau de gros fichiers journaux bruts et maintient l’analyse proche des données.

Flux de travail GPO

Le flux de travail est mis en œuvre via la stratégie de groupe (configuration ordinateur) pour garantir des paramètres cohérents sur tous les contrôleurs de domaine.

Implémentation de référence incluse dans ce dépôt (rapport GPO) :

  • Nom d’archive/rapport : T0-C-Analytics-DNSDebugLogging
  • ID de sauvegarde : {2B6F16BC-0E7C-4787-83D7-2854FED882EE}
  • Cible de lien GPO : corp.company.com/Domain Controllers
  • Filtre d’élément (utilisé pour le déploiement des fichiers et les tâches planifiées) : s’applique uniquement si C:\Windows\System32\dns.exe existe

1) Prérequis (dossiers + module)

La sauvegarde fournie suppose que ces dossiers existent déjà. Ajoutez des éléments GPP séparés si vous souhaitez que le déploiement les crée automatiquement :

  • C:\Administration\Scripts
  • C:\Administration\Logs\DNSServer

La sauvegarde fournie suppose également que Convert-DNSDebugLogFile est déjà disponible sur les DC. La tâche de conversion lance Windows PowerShell 5.1 avec -NoProfile et n’importe pas explicitement le module, donc celui-ci doit être installé dans un chemin de module PowerShell machine-wide visible par LocalSystem. Approches recommandées :

  • Installer DNSServer.DebugLogParser sur les DC. Par exemple, depuis PowerShell Gallery (si la politique le permet).
  • Déployer le module via un repo interne / partage de fichiers pour qu’il soit détectable dans $env:PSModulePath
  • Ajouter un Import-Module explicite à l’action de la tâche si vous souhaitez un chargement déterministe

2) Déployer le script de configuration du journal de débogage (GPP Files)

La GPO déploie le script :

  • Source (dans SYSVOL via GPP) : %GptPath%\Preferences\Files\Set-DNSServerDebugLogging.ps1
  • Cible (sur chaque DC) : C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1

Cela est implémenté dans l’élément de préférence GPP Files dans Files.xml.

3) Tâche planifiée : configurer le journal de débogage DNS

La GPO crée une tâche planifiée nommée Set-DNSServerDebugLogging.

  • Contexte de sécurité dans la sauvegarde fournie : SYSTEM avec type de connexion S4U
  • Déclencheur dans la sauvegarde fournie : quotidien (heure de début 2025-03-01T00:00:01)
  • Action dans ScheduledTasks.xml :
    • powershell.exe -ExecutionPolicy RemoteSigned -command " & { C:\Administration\Scripts\Set-DNSServerDebugLogging.ps1 }"
    • Répertoire de travail : C:\Administration\Scripts

Le script Set-DNSServerDebugLogging.ps1 configure le journal de débogage DNS via Get-DnsServerDiagnostics / Set-DnsServerDiagnostics et notamment :

  • Active la journalisation dans un fichier + rotation
  • Écrit dans : C:\Administration\Logs\DNSServer\DnsDebugLog_<COMPUTERNAME>.<Domain>_.log
  • Utilise une taille de rotation de 10 Mo par fichier
  • Capture principalement l’activité liée aux requêtes (requêtes + notifications + mises à jour + transactions de questions) et exclut la journalisation complète des paquets

4) Tâche planifiée : convertir les journaux de débogage archivés en CSV compressé

La GPO crée une tâche planifiée nommée Convert-DNSDebugLogs.

  • Contexte de sécurité dans la sauvegarde fournie : SYSTEM avec type de connexion InteractiveToken
  • Déclencheur dans la sauvegarde fournie : quotidien (heure de début 2026-01-01T00:30:00)
  • Répertoire de travail : C:\Administration\Logs\DNSServer
  • Action dans ScheduledTasks.xml (formaté pour la lisibilité) :
Get-ChildItem .\*.log |
  Sort-Object lastwritetime, Name -Descending |
  Select-Object -Skip 1 |
  Convert-DNSDebugLogFile `
    -ComputerName $env:COMPUTERNAME `
    -Delimiter ';' `
    -OutputType Both `
    -ContextFilter Packet `
    -OutputCulture sv-SE `
    -CompressOutput

Notes de conception :

  • Select-Object -Skip 1 évite intentionnellement de traiter le fichier journal le plus récent (actif). Convert-DNSDebugLogFile peut lire un journal que le serveur DNS a actuellement ouvert, mais ce fichier change pendant la lecture : la sortie peut manquer les entrées les plus récentes ou se terminer par un enregistrement tronqué, et deux exécutions ne produisent pas des résultats identiques. Ignorer le fichier actif maintient la sortie planifiée reproductible.
  • Cela signifie que les données actuelles ne sont exportées qu’après la rotation ; sur les DC à faible volume, le journal actif peut rester non traité plus d’un jour. Réduisez la taille de rotation si ce délai est trop long pour votre cas d’usage.
  • Parce que Convert-DNSDebugLogFile utilise par défaut -OutputFile « même dossier, même nom, .csv », les sorties se trouvent à côté des entrées *.log.
  • Avec -CompressOutput, chaque journal traité produit un *.zip et les CSV intermédiaires sont supprimés.
  • À moins d’archiver ou supprimer les fichiers *.log traités, les exécutions ultérieures retraiteront tous les journaux non actifs.
  • La tâche génère une erreur si $Error.Count -gt 0 pour signaler un échec.

5) Ingestion centrale

Options (choisir une) :

  • Ingestion via partage de fichiers : le DC écrit (ou copie) C:\Administration\Logs\DNSServer\*.zip vers \\fileserver\share\dns\$env:COMPUTERNAME\... (accorder les droits de partage et NTFS aux comptes ordinateurs DC ou au groupe Domain Controllers si la tâche s’exécute en SYSTEM)
  • Modèle pull : un job central lit \\dc\C$\Administration\Logs\DNSServer\*.zip (moins recommandé ; nécessite les partages admin)
  • Forwarder agent : pipeline SIEM / journal qui expédie les sorties *.zip

Considérations opérationnelles

  • Moindre privilège : les tâches s’exécutent en SYSTEM ; assurez-vous que les dossiers locaux sont accessibles en écriture et que toute cible UNC accorde l’accès au compte ordinateur si utilisée.
  • Politique de signature : les deux tâches utilisent -ExecutionPolicy RemoteSigned ; signez ou débloquez le script et le module déployés selon votre politique.
  • Utilisation disque : -CompressOutput aide significativement, mais ce flux ne supprime pas les journaux sources ; planifiez la conservation et le nettoyage.
  • Comportement de retraitement : sauf archivage ou suppression des journaux traités, la tâche de conversion retraitera chaque fichier *.log non actif lors des exécutions ultérieures. C’est simple et robuste, mais cela peut écraser les sorties et créer des doublons en aval si votre collecteur ne déduplique pas.
  • Consolidation multi-DC : -ComputerName $env:COMPUTERNAME est inclus pour que les jeux de données consolidés restent traçables. Notez que -ComputerName ne fait que marquer la sortie — il n’établit aucune connexion distante.
  • Partages réseau : Convert-DNSDebugLogFile peut lire les journaux sources depuis des chemins SMB/UNC, mais convertir localement et expédier les résultats compressés reste la meilleure pratique pour les gros journaux bruts. Si vous utilisez un chemin UNC, rappelez-vous qu’une tâche s’exécutant en SYSTEM s’authentifie sur le réseau en tant que compte ordinateur et nécessite les droits de partage et NTFS.
  • Format de date : -OutputCulture sv-SE est utilisé délibérément pour que les horodatages s’écrivent sous la forme 2026-01-20 23:00:16. Ce format est lu sans indication par SQL Server, Power BI et la plupart des outils d’import, indépendamment de la locale du DC qui a produit le journal.
  • Validation : la validation de l’en-tête reste activée car la tâche n’utilise pas -SkipHeaderValidation (recommandé).

Valider et adapter (avec le ZIP)

Utilisez l’archive ZIP comme implémentation de référence, puis alignez les aspects suivants à votre environnement :

  • Portée cible : quels DC / OU reçoivent la stratégie
  • Identité d’exécution : confirmez que les deux tâches planifiées utilisent le type de connexion prévu (S4U vs InteractiveToken) ou normalisez-les selon votre standard
  • Création des dossiers : décidez si C:\Administration\Scripts et C:\Administration\Logs\DNSServer sont pré-créés ailleurs ou doivent être créés par des éléments GPP supplémentaires
  • Chemins : confirmez que C:\Administration\Scripts et C:\Administration\Logs\DNSServer correspondent à vos standards
  • Conservation : décidez si vous conservez les journaux bruts et pour combien de temps (surtout si vous activez les options de nettoyage)
  • Ingestion : confirmez où les sorties CSV/ZIP sont écrites et comment elles sont collectées centralement

Si vous souhaitez valider la configuration exacte de la GPO sans l’importer, les sources autoritaires dans ce dépôt sont :

3 - Exemple de tâche planifiée

Cet exemple montre comment créer une tâche planifiée Windows qui exécute un script PowerShell pour traiter quotidiennement les journaux de débogage DNS.

Ce script crée une tâche planifiée Windows qui s’exécute tous les jours à 2h00 du matin. Il importe le module et traite tous les fichiers journaux dans le dossier où le script est exécuté (dans cet exemple “C:\Administration\Logs\DNS”). Le processus compresse la sortie dans des fichiers ZIP et supprime les originaux pour maintenir la propreté.

$actionParams = @{
    Execute = "powershell.exe"
    Argument = '-ExecutionPolicy RemoteSigned -Command "Import-Module DNSServer.DebugLogParser; Get-ChildItem .\*.log | Sort-Object lastwritetime, Name -Descending | Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME -Delimiter \";\" -OutputType Both -ContextFilter Packet -OutputCulture sv-SE -CompressOutput"'
    WorkingDirectory = "C:\Administration\Logs\DNS"
}
$Action = New-ScheduledTaskAction @actionParams

$Trigger = New-ScheduledTaskTrigger -Daily -At "2:00AM"

Register-ScheduledTask -TaskName "Process DNS Logs" -Action $Action -Trigger $Trigger -Description "Convert DNS debug logs to CSV daily"