MENU
  1. ホーム
  2. Python
  3. Event ID 5158: sovraccarico del registro Security su Windows Server DNS (WFP) — diagnosi e soluzioni

Event ID 5158: sovraccarico del registro Security su Windows Server DNS (WFP) — diagnosi e soluzioni

Python

Un picco di Event ID 5158 può saturare il registro Security in poche ore. In questo articolo trovi un playbook pratico per diagnosticare e mitigare un’ondata generata da dns.exe su Windows Server (2016/2019), con controlli mirati su DNS, rete, WFP, criteri di audit e performance.

Indice

Panoramica del problema

In un’infrastruttura Active Directory, un controller di dominio Windows Server 2016 (S1) ha generato oltre 1,9 milioni di eventi 5158 – Filtering Platform Connection in meno di cinque ore. L’analisi ha mostrato che quasi tutti gli eventi erano attribuiti al processo dns.exe. L’altro DC (S2), basato su Windows Server 2019 e con ruoli simili, non presentava la stessa anomalia. Il carico arrivava a ondate da 60.000–72.000 eventi, riempiendo rapidamente il registro Security e riducendo la visibilità su eventi davvero critici.

Che cos’è l’Event ID 5158 (Filtering Platform Connection)

Il 5158 viene emesso quando il Windows Filtering Platform (WFP) registra una connessione consentita. A differenza degli eventi di Packet Drop (es. 5152/5157), il 5158 non segnala un blocco ma un allow. In ambienti ad alto traffico — specialmente su server DNS, DHCP, domain controller, proxy e reverse proxy — il numero di connessioni legittime può essere elevatissimo. Se l’auditing “success” è abilitato per Filtering Platform Connection, il risultato è un flusso di log potenzialmente ingestibile.
Campi tipici dell’evento (semplificato)

Event ID: 5158
Process Name: C:\Windows\System32\dns.exe
Direction: Outbound/Inbound
Source Address / Port
Destination Address / Port
Protocol: UDP o TCP
Application ID (WFP)

Perché può esplodere sul DNS

Il servizio DNS su un DC gestisce risoluzioni ricorsive, aggiornamenti dinamici, forwarder e reverse lookup. Combinazioni sfortunate di configurazione (loop di inoltro, forwarder non raggiungibili, time-out aggressivi), traffico anomalo da client o IoT, e politiche di auditing troppo verbose possono far precipitare la situazione. Nello scenario S1, l’ondata di 5158 aveva un pattern a “raffiche”, spesso indicativo di code interne o retry di massa verso un set di destinazioni.

Diagnosi e possibili cause

Categoria di verificaScopo principale
Configurazione DNSDuplicati di record, zone mal configurate, loop di inoltro o recursion anomale che moltiplicano le query.
Traffico di reteCattura con Wireshark / NetMon per individuare host o IP che inviano volumi anomali di richieste DNS.
Firewall / WFPRegole o software di sicurezza che loggano ogni connessione in uscita di dns.exe.
Integrità del sistemaFile corrotti o patch mancanti (sfc, DISM, Windows Update).
Criteri di audit“Filtering Platform Connection – Success” abilitato a livello globale può generare enormi volumi di log.
Risorse serverCPU o RAM carenti che innescano comportamenti anomali del servizio DNS.

Playbook di diagnostica rapida

Quando il Security log si riempie di 5158, il tempo è essenziale. Ecco una sequenza operativa che privilegia impatto e rapidità.

  1. Stabilizza la telemetria
    • Aumenta temporaneamente la dimensione del registro Security e passa a “Do not overwrite (clear manually)” solo se hai un sistema di raccolta centralizzata: wevtutil sl Security /ms:838860800 wevtutil gl Security | findstr "enabledRecord"
    • In alternativa imposta “Overwrite events as needed” ma con dimensione ampia, per non perdere eventi essenziali.
  2. Conferma l’origine
    • Filtra gli eventi 5158 per Process Name: # PowerShell (elevato) Get-WinEvent -FilterHashtable @{LogName='Security';Id=5158} -MaxEvents 50000 | Where-Object {$_.Properties[4].Value -match 'dns\.exe'} | # indice soggetto al template Measure-Object
    • Se non è dns.exe, individua il processo responsabile e adatta il playbook.
  3. Controlla i forwarder e la recursion
    • Verifica forwarder non raggiungibili o loop: Get-DnsServerForwarder Get-DnsServerRecursion Get-DnsServerSetting -All | fl Timeout,Retry,Cache
    • Se i forwarder sono down, il DNS può moltiplicare i tentativi.
  4. Cattura minima di rete
    • Avvia una cattura mirata (60–120 s) per isolare i “top talker”: # Esempio tshark (se presente) tshark -a duration:120 -f "udp port 53 or tcp port 53" -qz "io,stat,1,COUNT(dns)dns" tshark -a duration:120 -Y "dns" -T fields -e ip.src -e dns.qry.name | sort | uniq -c | sort -nr | head
    • In Wireshark usa i filtri dns e udp.port==53 || tcp.port==53, e la statistica “Conversations”.
  5. Confronta S1 vs S2
    • Confronta versioni, patch, impostazioni DNS, auditing e WFP: systeminfo | findstr /B /C:"OS Name" /C:"OS Version" Get-WindowsUpdateLog # se necessario auditpol /get /category:"Object Access" netsh wfp show state
  6. Riduci il rumore in sicurezza
    • Se confermato che il volume è dovuto a allow legittimi, imposta Filtering Platform Connection su Failure only (vedi sezione dedicata).

Approfondimenti per ciascuna categoria

Configurazione DNS

Focalizzati su tre temi: forwarding, recursion e aggiornamenti dinamici.

  • Loop di inoltro: controlla che S1 non inoltri a un resolver che, direttamente o tramite catena, torna a S1. Evita forwarder multipli che a loro volta usano il DC come “backup”.
  • Forwarder non raggiungibili: se i forwarder rispondono lentamente o vanno in time-out, dns.exe può generare nuovi tentativi, gonfiando le connessioni. Verifica con: Test-NetConnection -ComputerName <forwarder-ip> -Port 53 Resolve-DnsName -Server <forwarder-ip> microsoft.com
  • Duplicati di record e PTR obsoleti: record “A/PTR” o SRV duplicati possono innescare query ripetute, specialmente se il client è aggressivo. Elenca e deduplica: Get-DnsServerZone | ? {$_.IsReverseLookupZone -eq $true} | % { Get-DnsServerResourceRecord -ZoneName $_.ZoneName -RRType PTR } | Group-Object RecordData -NoElement | Sort-Object Count -Descending | Select -First 20
  • Recursion policy: su DC esposti solo a client interni, limita la recursion secondo necessità. Se non serve, disabilita o restringi i client ammessi.

Traffico di rete

Una fonte esterna (client, appliance, IoT, malware, test di penetrazione) può saturare di richieste DNS lecite ma superflue. Individua i “chi fa cosa”.

  • Top talker con PowerShell e netstat: netstat -ano | findstr ":53" Get-NetTCPConnection -LocalPort 53 | Group RemoteAddress | Sort-Object Count -Descending | Select -First 15
  • Riconoscere pattern: raffiche ogni N secondi spesso indicano retry sincroni (p.es. client senza connettività verso internet che risolvono host esterni).
  • Reflection/Amplification: anche se non bloccate dal firewall, generano molte connessioni consentite (UDP). Verifica query con flag “ANY” o domini sospetti.

Firewall / Windows Filtering Platform

Regole iper-verbose o prodotti di sicurezza che registrano ogni allow possono scatenare valanghe di 5158. Controlla policy locali e GPO.

  • Inventario delle regole: netsh advfirewall firewall show rule name=all | more Get-NetFirewallRule | ? {$_.Enabled -eq 'True'} | Get-NetFirewallPortFilter | ft Name,Protocol,LocalPort,RemotePort
  • Prodotti di sicurezza: verifica se l’agente EDR/AV ha opzioni di log “allow”. Disabilitale o spostale su livelli meno loquaci.
  • WFP state: netsh wfp show state > C:\temp\wfp_state.txt

Integrità del sistema

  • Esegui una verifica rapida: sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth
  • Controlla update pendenti e riavvii pianificati. Un componente di rete in stato inconsistente può accelerare retry o leak di socket.

Criteri di audit

Il nodo cruciale: Object Access → Filtering Platform Connection. Se impostato su Success, ogni connessione consentita (UDP/TCP) genera 5158. Su DNS ad alto traffico i numeri esplodono.

  • Verifica stato attuale: auditpol /get /subcategory:"Filtering Platform Connection" auditpol /get /category:"Object Access"
  • Raccomandazione operativa: impostare su Failure (o disabilitato), mantenendo attivi gli eventi di Packet Drop per segnalare reale impatto sicurezza.

Risorse server

Se CPU/RAM sono al limite, il servizio DNS può accumulare code e moltiplicare gli handle di rete.

  • Contatori utili (Perfmon):
    • DNS Server: Total Query Received/sec, Recursive Queries/sec, TCP/UDP Receive/Send.
    • Process(dns): Handle Count, Thread Count, Private Bytes.
    • Network Interface: Bytes Total/sec.
  • Riduci workload non essenziale (backup, scansioni AV complete) durante l’incidente.

Soluzioni consigliate

Controllo approfondito delle zone DNS

  • Evita loop di forwarding (es. il forwarder ritorna verso S1 tramite rotte indirette).
  • Rimuovi record duplicati o obsoleti (soprattutto SRV e PTR in zone AD-integrated).
  • Valuta l’uso di scavenging con parametri realistici per liberare record vecchi.

Monitoraggio del traffico

  • Identifica client/subnet che bombardano il DNS con query ripetute o domini inesistenti.
  • Indaga eventuali attacchi di riflessione o firmware IoT configurati con DNS errato.

Revisione del firewall / software AV

  • Disattiva regole di logging “allow” non necessarie.
  • Allinea le policy WFP alla reale esigenza di audit: drop sì, allow solo dove serve.

Aggiornamento e riparazione del sistema

  • Applica patch recenti, soprattutto su stack di rete e DNS.
  • Esegui sfc e DISM per riparare eventuali file corrotti.

Riduzione dell’auditing

In “Criteri di controllo avanzati” disabilita (o imposta su Failure only) Object Access → Filtering Platform Connection se i log non sono richiesti per conformità.
Come applicare via GPO / CLI

  • Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Object Access → Filtering Platform Connection: deseleziona “Success”, mantieni/attiva “Failure” se ti serve segnalare i drop.
  • Host singolo: auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:enable

Riavvio mirato

  • Riavvia il servizio DNS Server (dnscache è lato client) per scaricare stati e code.
  • Se persiste, valuta un riavvio del server in finestra controllata.

Verifica delle performance

  • Assicurati che S1 abbia risorse adeguate (RAM/CPU) e nessun carico batch concomitante.
  • Valuta l’ottimizzazione della cache DNS e dei timeout.

Escalation

Se il comportamento continua, apri un ticket con il supporto Microsoft e prepara: ETL WFP, dump del processo dns.exe in caso di leak di handle, esport dei contatori Performance Monitor, e configurazioni DNS.

Automazione: individuare e contenere l’ondata

Un approccio proattivo evita sorprese in orario di punta.

  • Alert sui volumi: crea una pianificazione che conta i 5158 negli ultimi 5 minuti e segnala se superano una soglia: $t=(Get-Date).AddMinutes(-5) $events=Get-WinEvent -FilterHashtable @{LogName='Security';Id=5158; StartTime=$t} if($events.Count -gt 20000){ Write-EventLog -LogName Application -Source "Ops" -EntryType Warning -EventId 9001 -Message "Valanga 5158: $($events.Count) in 5m" }
  • Top endpoint in tempo reale: Get-WinEvent -FilterHashtable @{LogName='Security';Id=5158} -MaxEvents 200000 | % { $_.Properties[8].Value } | Group-Object | Sort-Object Count -Descending | Select -First 20 (L’indice del campo dipende dal template; adegua dopo un Export-CSV di esempio.)
  • Log sizing: dimensiona il Security log in base al picco stimato: wevtutil sl Security /ms:1073741824 wevtutil sl Security /rt:true
  • Offload su sistema centralizzato (WEF/SIEM) per storicizzare gli eventi realmente utili.

Confronto S1 (2016) vs S2 (2019): cosa verificare

Il fatto che S2 (2019) non mostri l’anomalia offre una pista. Confronta puntualmente:

AmbitoS1 (2016)S2 (2019)Azioni
Patch e buildLivello update?Più recenteAllinea cumulative update, in particolare networking/DNS.
Auditing WFPSuccess abilitato?Failure only?Uniforma l’audit tra i DC.
Forwarder DNSSet ASet BUniforma i forwarder e verifica raggiungibilità/latency.
RecursionAbilitata per tuttiLimitataRestringi recursion a subnet fidate o disabilita se non serve.
Carico clientSubnets X,YSubnets ZBilancia i client tra DC o applica policy locali di caching.

Gestione del registro Security: buone pratiche

  • Dimensione adeguata: parti da 512–1024 MB per DC ad alto traffico, poi calibra sui picchi reali.
  • Metodo di retention: “Overwrite as needed” con dimensione ampia è spesso preferibile per garantire continuità, salvo vincoli di compliance.
  • Canalizzazione: sposta l’osservabilità su eventi di drop (5152/5157) e policy change, riducendo il rumore degli allow.
  • WEF: centralizza solo ciò che serve (drop, policy change, autenticazioni, escalation privilegi), riducendo ingest e costi SIEM.

Query e filtri utili (Event Viewer / SIEM)

XML Query: 5158 da dns.exe

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=5158)]] and
      *[EventData[Data[@Name='ProcessName'] and (contains(.,'dns.exe'))]]
    </Select>
  </Query>
</QueryList>

PowerShell: top destinazioni

Get-WinEvent -FilterHashtable @{LogName='Security';Id=5158} -MaxEvents 200000 |
  Select-Object -ExpandProperty Properties |
  Where-Object {$_.Value -match '(\d{1,3}\.){3}\d{1,3}'} |
  Group-Object Value | Sort-Object Count -Descending | Select -First 20

DnsDiag rapido

Resolve-DnsName -Name . -Server 127.0.0.1 -Type NS
Resolve-DnsName -Name microsoft.com -Server 127.0.0.1 -NoHostsFile -DnsOnly -CacheOnly:$false

Hardening dell’audit: ridurre il rumore senza perdere sicurezza

L’obiettivo è dare priorità a ciò che indica un rischio reale. Gli eventi di blocco (Packet Drop) sono più predittivi per la sicurezza rispetto agli allow massivi.

  • Mantieni: Filtering Platform Packet Drop (Failure), Policy Change, Logon/Logoff, Privilege Use, DS Access (solo se richiesti).
  • Riduci: Filtering Platform Connection – Success salvo casi di indagine mirata e temporanea.
  • Documenta la change con ticket e approvazione di sicurezza.

Esito reale e raccomandazioni

Nel caso descritto, il fenomeno è cessato spontaneamente pochi giorni dopo l’osservazione iniziale, senza interventi né riavvii. Questo suggerisce una causa transitoria (coda DNS bloccata, forwarder momentaneamente degradati, lock interni, aggiornamento in attesa). Le azioni proposte restano valide per:

  • Prevenire il riempimento futuro del registro Security.
  • Identificare rapidamente le sorgenti di traffico DNS eccessivo.
  • Ridurre il rumore di log mantenendo solo gli eventi realmente utili.

Nota tecnica
L’Event ID 5158 registra ogni connessione consentita dal Windows Filtering Platform. In ambienti dove i servizi di rete (DNS, DHCP, AD) generano molte connessioni legittime, tenere l’auditing “success” abilitato può produrre log ingestibili e compromettere la visibilità di eventi critici. Valuta un livello di auditing più selettivo, spostando il monitoraggio sul canale Filtering Platform Packet Drop (eventi di block), molto più significativo per la sicurezza.

Checklist finale pronta all’uso

  • Security log dimensionato ≥ 512 MB e policy di overwrite adeguata.
  • Audit WFP su Failure per Filtering Platform Connection (Success disabilitato).
  • Forwarder DNS allineati e raggiungibili, recursion limitata.
  • Catture di rete brevi e mirate per trovare top talker.
  • Deduplica record A/PTR/SRV e attiva scavenging con parametri realistici.
  • Perfmon su DNS/Process/Network per individuare code o leak di handle.
  • Automazione alert sulla soglia di 5158 in 5–10 minuti.
  • Documentazione delle modifiche e, se serve, escalation con ETL WFP e dump diagnostici.

Appendice A — Script di triage 5158 per DNS

# Esegui in PowerShell (elevato)
1) Conteggio 5158 nelle ultime 2 ore
$since=(Get-Date).AddHours(-2)
$e=Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5158; StartTime=$since}
"5158 nelle ultime 2h: {0}" -f $e.Count

2) Solo dns.exe

$dns=$e | Where-Object { $_.Properties[4].Value -match 'dns.exe' }
"di cui dns.exe: {0}" -f $dns.Count

3) Top destinazioni (attenzione all’indice proprietà)

$topDst=$dns | ForEach-Object { $_.Properties[8].Value } |
Group-Object | Sort-Object Count -Descending | Select -First 15
$topDst | Format-Table Name,Count

4) Esporta campione per analisi

$dns | Select-Object -First 5000 | Export-Csv C:\Temp\5158-dns-sample.csv -NoTypeInformation

Appendice B — Comandi DNS di verifica rapida

# Impostazioni generali
Get-DnsServerSetting -All | fl ListenAddresses,ForwardingTimeout,Port

Forwarder e recursion

Get-DnsServerForwarder
Get-DnsServerRecursion

Zone e record “chiacchieroni”

Get-DnsServerZone | % {Get-DnsServerResourceRecord -ZoneName $_.ZoneName} |
Group-Object RecordType | Sort-Object Count -Descending | ft Name,Count

Diagnostica: disabilita temporaneamente debug eccessivo se attivo

Get-DnsServerDiagnostics | fl *

Appendice C — Impostazione audit WFP

# Disabilita Success e abilita Failure per Filtering Platform Connection
auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:enable

Verifica

auditpol /get /subcategory:"Filtering Platform Connection"

Appendice D — Dimensionamento registro Security

# Imposta a 1.5 GB e overwrite as needed
wevtutil sl Security /ms:1610612736
wevtutil sl Security /rt:true

Verifica dimensione

wevtutil gl Security | findstr "maxSize retention"

Appendice E — Indici dei campi 5158 (orientativi)

A scopo pratico, gli indici in $.Properties[i].Value possono variare in base a build/lingua. Usa Select-Object -Expand Message su un evento per mappare i campi nella tua installazione. In genere:

  • ProcessName ≈ indice 4
  • SourceAddress/Port ≈ indici 6/7
  • DestinationAddress/Port ≈ indici 8/9
  • Protocol ≈ indice 5

Conferma sempre con un campione.

Gestire correttamente l’auditing e la configurazione DNS riduce drasticamente la possibilità che ondate di 5158 ti privino della visibilità su eventi critici. Un DC che funge da DNS è per sua natura “chiacchierone”: la chiave è distinguere rapidamente il traffico lecito rumoroso da quello anomalo e concentrare l’osservabilità dove serve davvero.

Python
DNS Server Event ID 5158 Security Log Troubleshooting Windows Filtering Platform Windows Server
Indice