MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. DNS : stopper l’inondation du journal Sécurité (événement 5158 WFP par dns.exe) sur Windows Server

DNS : stopper l’inondation du journal Sécurité (événement 5158 WFP par dns.exe) sur Windows Server

Windows Server

Votre journal Sécurité se remplit à la vitesse de l’éclair avec des milliers d’événements 5158 signés dns.exe ? Ce guide explique pourquoi la WFP « Filtering Platform Connection » peut exploser sur un contrôleur de domaine et propose une méthode éprouvée pour diagnostiquer et corriger.

Sommaire

Contexte et symptômes

Sur un contrôleur de domaine Windows Server 2016 (S1), le journal Sécurité s’est saturé en quelques heures : près de 2 millions d’événements 5158 en moins de cinq heures, tous émis par C:\Windows\System32\dns.exe. Les autres serveurs, dont un second DC (S2, Windows Server 2019), n’étaient pas affectés. Les événements arrivaient par salves de 60 000 à 72 000 toutes les 5 à 15 minutes, alors même que l’infrastructure était modeste (≈ 18 serveurs, 65 postes, 4 zones DNS, < 150 comptes AD).

Pourquoi l’événement 5158 explose-t-il sur un serveur DNS ?

L’événement 5158 appartient au sous‑catégorie d’audit Filtering Platform Connection de la Windows Filtering Platform (WFP). Il se déclenche lorsqu’un processus effectue un bind sur un port local. Pour un serveur DNS, deux comportements se cumulent :

  • Écoute permanente sur UDP/53 et TCP/53 (service DNS).
  • Requêtes sortantes du service DNS vers d’autres résolveurs (redirecteurs, racines, serveurs faisant autorité). Chaque requête UDP utilise un port source aléatoire (randomisation), ce qui provoque un bind fugace pour chaque paquet sortant. Si l’audit des réussites est activé, le volume d’événements 5158 peut donc monter en flèche.

Autrement dit, activer la réussite sur « Filtering Platform Connection » sur un rôle DNS revient souvent à consigner chaque usage de port éphémère, et pas seulement les opérations bloquées ou anormales. D’où la sensation de « déluge » dès qu’il y a du trafic.

Cartographie rapide des événements WFP utiles

ÉvénementQuand survient‑il ?Usage principal
5154Une application est autorisée à écouter sur un port localInventorier qui écoute où (succès)
5155Une application est empêchée d’écouterDéboguer un échec d’ouverture de port (échec)
5156Connexion autoriséeTraçage fin des connexions permises
5157Connexion bloquéeIdentifier les connexions refusées
5158Bind sur un port local autorisé (ports éphémères inclus)Très verbeux sur DNS : à limiter

À retenir : pour un contrôleur de domaine exécutant dns.exe, 5158 est quasi toujours bruyant si l’audit de succès est activé. Il convient donc de privilégier les échecs (drops) et d’activer le succès uniquement lors d’un dépannage ciblé et temporaire.

Hypothèses techniques plausibles

  • Audit inadapté : l’audit « Filtering Platform Connection » en succès est activé via stratégie locale ou GPO uniquement sur S1.
  • Trafic sortant inhabituel : S1 effectue bien plus de résolutions récursives (redirecteurs externes, nombre de postes dirigés vers S1, application bavarde, scanner réseau, fuite DNS via proxy, etc.).
  • Incohérence transitoire du service DNS : file de sockets/ports éphémères anormalement sollicitée jusqu’à purge ou mise à jour.
  • Configuration DNS divergente entre S1 et S2 : forwarders, racines, zones intégrées AD, scavenge, cache.

Plan d’enquête et de remédiation (pas à pas)

La table suivante synthétise les axes que vous pouvez dérouler immédiatement. Chaque colonne « Actions » propose des commandes concrètes.

Axe d’investigationObjectifActions pratiques
Configuration DNSÉcarter un afflux anormal de requêtesComparer zones, redirecteurs et racines entre S1/S2 Chasser les enregistrements erronés (boucles, CNAME circulaires) Vérifier la récursivité et les destinataires des clients
Trafic réseauIdentifier la source des connexionsCaptures sur port 53 (UDP/TCP) Compter et classer les IP bavardes
Pare‑feu / WFPComprendre la verbosité des logsExaminer les GPO et l’audit avancé WFP Désactiver le succès ou le limiter aux échecs
Intégrité systèmeExclure fichiers corrompus / mises à jour manquantesWindows Update complet sfc et DISM
Ressources serveurS’assurer que DNS ne sature pasSurveiller CPU/RAM du rôle DNS Redémarrer le service DNS si nécessaire
JournalisationÉviter le remplissage du journal SécuritéAjuster la taille et la rotation Archiver automatiquement
Audit cibléRéduire le bruit, garder l’utileDésactiver 5158 sauf dépannage ponctuel Créer une vue « DNS only »

Vérifier et comparer la configuration DNS

Sur chaque DC, comparez les paramètres essentiels :

# Zones
Get-DnsServerZone

# Redirecteurs et paramètres de récursivité

Get-DnsServerForwarder
Get-DnsServerRecursion

# Diagnostics DNS (journalisation, etc.)

Get-DnsServerDiagnostics

# Statistiques rapides

Get-DnsServerStatistics | Format-List \*

Recherchez des enregistrements problématiques (boucles CNAME, délégations orphelines) :

# Exemple : repérer les CNAME pointant vers eux-mêmes (boucle triviale)
Get-DnsServerResourceRecord -ZoneName "exemple.local" -RRType CNAME |
Where-Object { $_.RecordData.HostNameAlias -eq ("{0}.{1}" -f $_.HostName, "exemple.local") }

Capturer et qualifier le trafic

Sur S1, lancez une capture réseau courte au moment d’une salve :

# Capture ETL circulaire (sans redémarrage)
netsh trace start capture=yes persistent=no maxsize=200 filemode=circular report=no tracefile=C:\Trace\dns.etl

# Arrêt

netsh trace stop

Dans Wireshark :

  • Filtre d’affichage : udp.port == 53 || tcp.port == 53
  • Requêtes uniquement : dns.flags.response == 0
  • Repérez les « top talkers » (clients trop bavards, redirecteur qui répond lentement, etc.).

Audits WFP : inspecter et ajuster

Commencez par interroger l’état actuel des sous‑catégories WFP :

auditpol /get /subcategory:"Filtering Platform Connection"
auditpol /get /subcategory:"Filtering Platform Packet Drop"

Pour réduire le bruit sur un serveur DNS tout en gardant la sécurité, désactivez le succès et conservez l’échec :

auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:enable

Si une GPO force ces réglages, localisez‑la :

gpresult /h C:\Temp\gp.html && start C:\Temp\gp.html

Intégrité système

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Ressources et stabilité du rôle DNS

Surveillez le service et purgez un état incohérent si besoin :

Get-Process -Name dns
Get-Counter '\Process(dns)\% Processor Time'
Restart-Service -Name DNS -Force

# Purger le cache DNS serveur (non destructif)

Clear-DnsServerCache

Prévenir l’emballement du journal Sécurité

Ajustez la taille maximale du journal et mettez en place une rotation/archivage automatique.

# Augmenter la taille (ex : 200 Mo)
wevtutil sl Security /ms:209715200

# Export périodique (tâche planifiée)

\$ts = Get-Date -Format "yyyyMMdd\_HHmmss"
wevtutil epl Security "D:\Logs\Security\_\$ts.evtx" /ow\:true

Audit ciblé et vues personnalisées

Si vous devez temporairement conserver 5158, créez une Vue personnalisée qui exclut tout sauf dns.exe afin d’en réduire l’impact visuel, ou au contraire l’exclut pour se concentrer sur le reste.
Filtre XML (exclure dns.exe dans le journal Sécurité)

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=5158)]]
      and
      *[EventData[not(Data[@Name='Application'] = 'C:\Windows\System32\dns.exe')]]
    </Select>
  </Query>
</QueryList>

Mesures rapides (Playbook)

  1. Photographier l’état : export d’un échantillon du journal Sécurité, capture de configuration DNS (Get-DnsServer*), sauvegarde des paramètres d’audit (auditpol /get /category:* > audit.txt).
  2. Limiter le bruit : désactiver temporairement le succès pour « Filtering Platform Connection » (commande ci‑dessus). Aucune interruption de service.
  3. Comparer S1/S2 : redirecteurs, récursivité, clients pointant sur chaque DC, zones intégrées AD.
  4. Qualifer le trafic : courte capture réseau (1–2 min) pendant une salve, identification des IP bavardes.
  5. Maintenance : Windows Update, sfc/DISM, purge du cache DNS, redémarrage ciblé du service si nécessaire.
  6. Normaliser : conservez Packet Drop (échec), désactivez Connection (succès) par GPO, documentez le paramétrage.

Scripts d’aide à l’analyse

Compter les 5158 par minute et isoler dns.exe

$start = (Get-Date).AddHours(-6)
$events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5158; StartTime=$start} -ErrorAction SilentlyContinue
$dnsOnly = $events | Where-Object { $_.Properties.Value -contains 'C:\Windows\System32\dns.exe' }

\$byMinute = \$dnsOnly | Group-Object { \$*.TimeCreated.ToString('yyyy-MM-dd HH\:mm') } | Sort-Object Name
\$byMinute | Select-Object Name, @{n='Count';e={\$*.Count}} | Format-Table -AutoSize

Top « binds » par port local (éclairer le rôle des ports éphémères)

# Les détails varient selon le système, adaptez le champ suivant si besoin
$ports = foreach($e in $dnsOnly){
  # Recherche du champ "Local Port" dans les données
  $port = ($e.Message -split "`n" | Where-Object {$_ -match 'Local Port'}) -replace '[^\d]',''
  if($port){ [int]$port }
}
$ports | Where-Object { $_ } | Group-Object | Sort-Object Count -Descending | Select-Object Name,Count -First 20

Comparer l’audit WFP entre deux serveurs

Invoke-Command -ComputerName S1,S2 -ScriptBlock {
  '=== {0} ===' -f $env:COMPUTERNAME
  auditpol /get /subcategory:"Filtering Platform Connection"
  auditpol /get /subcategory:"Filtering Platform Packet Drop"
}

Liste des clients les plus bavards vus par dns.exe

À corréler avec la capture (Wireshark) ; côté serveur, vous pouvez aussi exploiter le journal DNS analytique (ETW) de façon temporaire si nécessaire.

# Activation temporaire du journal analytique DNS-Server (à désactiver après usage)
wevtutil sl "Microsoft-Windows-DNS-Server/Analytical" /e:true

# Exemple d’exploitation (événements très volumineux)

wevtutil qe "Microsoft-Windows-DNS-Server/Analytical" /q:"\*\[System\[(EventID=256)]]" /c:200 /rd\:true /f\:text

Résultat observé dans le cas présenté

Quelques jours après la constatation, les salves 5158 ont brutalement cessé sans intervention manifeste (ni redémarrage, ni changement formel). Deux scénarios restent plausibles :

  • Un correctif ou un redémarrage de service indirect (via Windows Update, purge du cache, recalcul de stratégies) a normalisé l’état du rôle DNS ou du sous‑système WFP.
  • Un état transitoire côté réseau (client bruyant, redirecteur lent, boucle de résolutions) s’est résorbé de lui‑même.

Dans ces cas, archivez un échantillon du journal avant remise à zéro : il sera précieux si le phénomène réapparaît.

Bonnes pratiques à pérenniser

  • N’activez « Filtering Platform Connection » en succès que pour un dépannage ciblé et temporaire.
  • Sur des rôles DNS intensifs, privilégiez la télémétrie applicative (journaux DNS) à la WFP si le but est de tracer les requêtes.
  • Documentez et versionnez toute modification des stratégies d’audit et des GPO de sécurité.
  • Mettez en place une rotation et un archivage automatiques des journaux sensibles (Sécurité, DNS).
  • Normalisez la configuration DNS (redirecteurs, récursivité, zones intégrées AD) entre vos contrôleurs de domaine.
  • Surveillez la latence des redirecteurs : un service lent côté DNS upstream multiplie les sockets éphémères côté serveur et donc les 5158.

Questions fréquentes

Pourquoi un seul DC est touché ?

Parce que l’audit WFP (succès) peut être activé par GPO ou localement sur un seul hôte. Une configuration DNS divergente (redirecteur différent, clients pointant massivement vers S1) peut aussi expliquer l’écart.

Est‑ce dangereux de désactiver 5158 ?

Non si vous conservez les échecs (Packet Drop). Vous continuez de voir ce que le pare‑feu bloque. Les succès détaillés (5156/5158) sont utiles pour du diagnostic, pas pour la surveillance continue d’un DC en production.

Quels impacts sur les performances ?

La journalisation massive (désérialisation d’événements, I/O disque) peut dégrader la machine et éclipser des alertes critiques. D’où l’importance de réduire la verbosité.

Checklist résumée (copier-coller)

# 1) Photographier
wevtutil epl Security C:\Temp\Security_sample.evtx /ow:true
auditpol /get /category:* > C:\Temp\audit_before.txt

# 2) Réduire le bruit (sur DC/DNS)

auditpol /set /subcategory:"Filtering Platform Connection" /success\:disable /failure\:enable

# 3) Comparer S1/S2

Get-DnsServerForwarder
Get-DnsServerRecursion
Get-DnsServerZone

# 4) Capturer (2 min)

netsh trace start capture=yes filemode=circular tracefile=C:\Trace\dns.etl
timeout /t 120 >nul
netsh trace stop

# 5) Maintenance rapide

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
Clear-DnsServerCache

# 6) Journal Sécurité (prévention)

wevtutil sl Security /ms:209715200
schtasks /Create /SC DAILY /TN "ExportSecurity" /TR "wevtutil epl Security D:\Logs\Security\_\$(date /t)\_\$(time /t).evtx /ow\:true" /ST 23:00

Conclusion

Une inondation 5158 sur un contrôleur de domaine exécutant dns.exe est généralement le symptôme d’un paramétrage d’audit trop verbeux conjugué au comportement normal d’un serveur DNS (ports éphémères). La résolution la plus efficace consiste à désactiver le succès de « Filtering Platform Connection », à éclairer le trafic (captures courtes, comparaison S1/S2) et à documenter une ligne de base d’audit soutenable. Si le pic disparaît spontanément, conservez un échantillon et vos notes : c’est votre meilleure assurance pour un éventuel retour de flamme.

Annexe : glossaire express

  • WFP : Windows Filtering Platform, moteur de filtrage réseau et d’audit de Windows.
  • Port éphémère : port source aléatoire utilisé pour des connexions sortantes, recréé très souvent.
  • Bind : opération d’attache d’un port local par un processus, déclenche typiquement l’événement 5158 en succès.
  • Redirecteur : résolveur DNS amont auquel un serveur transmet ses requêtes récursives.
  • Scavenge : nettoyage des enregistrements obsolètes dans les zones DNS.

Références internes de configuration (sans liens externes)

  • Stratégies d’audit avancées → Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies d’audit avancées > Accès aux objets > Filtering Platform Connection / Packet Drop
  • Journaux DNS : « Microsoft‑Windows‑DNS‑Server/Analytical » (ETW, très volumineux ; activer seulement pour un diagnostic court)
  • Journal Sécurité : vues personnalisées filtrant EventID=5158 avec inclusion/exclusion de dns.exe
Windows Server
PowerShell DNS troubleshooting Windows Server Audit Windows WFP Événement 5158
Sommaire