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.DebugLogParserSqlServer
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 :
- importe les modules requis
- convertit le journal de débogage DNS en CSV
- charge le CSV généré
- 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
- Chaque DC écrit les journaux de débogage DNS sur disque avec rotation activée.
- 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). - Les sorties sont écrites à côté des fichiers journaux pour garder le pipeline simple.
- 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\ScriptsC:\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.
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"