Event ID 5158 no Windows Filtering Platform: por que o dns.exe enche o Log de Segurança e como resolver (Windows Server 2016)

Se o Log de Segurança do Windows “explodiu” com milhões de eventos 5158 – Filtering Platform Connection originados por dns.exe, este guia explica, de forma prática e acionável, como diagnosticar a raiz do problema e como mitigá‑lo sem perder visibilidade ou quebrar requisitos de auditoria.

Índice

Cenário e sintomas

Controlador de domínio Windows Server 2016 (S1) com o registo Security a acumular quase 2 milhões de eventos 5158 em poucas horas.
Todos os 5158 apontavam para o processo \Windows\System32\dns.exe, sugerindo um volume anormal de ligações monitorizadas pelo Windows Filtering Platform (WFP).
Ambiente pequeno (≈ 150 contas, 18 servidores, 65 estações) com dois DC/DNS (S1 e S2). Apenas o S1 apresentava o sintoma.

O que é o Event ID 5158 (Filtering Platform Connection)

O Event ID 5158 é gerado quando o WFP permite a associação de um socket a um ponto de extremidade de rede (por exemplo, abertura/encerramento de ligação TCP ou o envio de datagramas UDP). Quando a auditoria de Filtering Platform Connection está definida para Sucesso, cada ligação legítima pode gerar eventos — em serviços de alto volume, como DNS (porta 53), isso escala rapidamente. Em UDP, o comportamento de “abre/fecha” é frequente, amplificando a contagem.

Porque o `dns.exe` pode disparar milhões de 5158

O serviço DNS de um DC atua como recursor, repositório de zonas e ponto de atualização dinâmica. Um dos seguintes fatores tende a provocar tempestades de conexões (e, portanto, de 5158):

Categoria	Gatilho típico	Impacto direto no 5158
Configuração DNS	Registos duplicados, encaminhamentos em loop, zonas mal configuradas, interfaces IN/OUT erradas	Multiplica consultas/respostas e provoca aberturas/fechos de sockets auditados
Tráfego anómalo	Equipamento interno a fazer flood de queries, varrimento externo, DNS tunneling	`dns.exe` passa a abrir milhares de sockets UDP/TCP por minuto
Firewall/Auditoria	Política “Filtering Platform Connection” em Sucesso	Cada ligação legítima é registada, entupindo o Log de Segurança
Integridade/Desempenho	Ficheiros corrompidos, patches em falta, baixa performance, reinícios do serviço	Ligações repetidas, estados pendentes e reabertura de sockets

Diagnóstico e mitigação: roteiro prático

Validar a configuração DNS

Zonas e encaminhadores: confirme se não existem encaminhamentos recursivos entre S1 e S2 (um apontar para o outro). Avalie também os root hints — evite ter encaminhadores e root hints ativos sem necessidade.
Interfaces escutadas: no Gestor DNS, verifique em Propriedades > Interfaces se o servidor escuta apenas nas NICs corretas.
Registos obsoletos: limpe registos dinâmicos e entradas duplicadas; se usar DHCP, valide credenciais para atualizações dinâmicas seguras.
Cache: limpe a cache para descartar tempestades transitórias.

# Ver interfaces e propriedades via PowerShell (Windows Server 2016)
Get-DnsServerSetting -All
Get-DnsServerForwarder
Limpar cache
Clear-DnsServerCache -Force

Monitorizar tráfego em tempo real

Wireshark: filtre por udp.port == 53 or tcp.port == 53 e identifique top talkers (clientes que mais consultam), padrões de NXDOMAIN e TXT longos (possível tunneling).
Contadores: use Performance Monitor > DNS (Queries Received/sec, Recursion Failures/sec) e Network Interface (Packets/sec).
Netstat: observe o número de sockets em uso.

# Top de conexões na porta 53 por PID
netstat -ano | findstr ":53"
Contadores do DNS
typeperf "\DNS\Total Query Received/sec" "\DNS\Recursive Queries/sec" -sc 10

Rever políticas de auditoria

Se a necessidade é manter visibilidade sem encher o log, a estratégia mais segura é auditar apenas falhas nesta subcategoria. Isto reduz drasticamente o ruído e mantém eventos realmente relevantes (por exemplo, packet drop é outra subcategoria distinta).

# Ver estado atual
auditpol /get /subcategory:"Filtering Platform Connection" /r

Recomendo, em ambientes pequenos, focar em falhas:

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

Nota importante: a subcategoria Filtering Platform Connection não tem granularidade por processo. Ou seja, não é possível “desactivar apenas para dns.exe” usando auditpol. Pode filtrar a visualização no Event Viewer (ou no SIEM), mas os eventos continuarão a ser gerados se a auditoria estiver ligada para Sucesso.

Analisar integridade e desempenho do servidor

# Verificação de ficheiros do sistema e imagem
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Validar se o serviço DNS não está a reiniciar

Get-EventLog -LogName System -Source "Service Control Manager" -Newest 200 |
Where-Object {$_.Message -like "DNS"}

Monitore CPU, memória e IO. Reinícios ou hangs do serviço podem multiplicar aberturas/fechos de sockets, criando ondas de 5158.

Intervenções rápidas

Reiniciar o serviço DNS fora de horas de pico para libertar estados e sockets pendentes:

Restart-Service -Name DNS -Force

Reinício controlado do servidor se o problema persistir e só afetar um DC — útil para limpar estados do WFP/stack de rede.

Aprofundar logs correlatos

No Event Viewer, crie filtros para IDs úteis:

DNS Server: 4000–4010 (inicialização/erros), 4013 (zona AD não carregada), 4015 (erro de serviço), 5501/5504 (falhas de encaminhamento).
DNS Client: 1014 (falha de resolução no próprio DC).

Escalar quando necessário

Se identificar query rate legítimo mas muito elevado (por exemplo, varredura de inventário, load test, dispositivo mal configurado ou suspeita de exfiltração por DNS), envolva segurança e/ou suporte Microsoft. Em paralelo, planeie captura prolongada com rotação (ring buffer) para não saturar disco.

Ferramentas e comandos úteis

Contar 5158 por hora e por processo

Exemplo de PowerShell para contar quantos 5158 vêm de cada executável e focar no dns.exe:

$inicio = (Get-Date).AddHours(-1)
$xpath = "*[System[(EventID=5158) and TimeCreated[timediff(@SystemTime) <= 3600000]]]"

Get-WinEvent -LogName Security -FilterXPath $xpath |
ForEach-Object {
[xml]$x = $*.ToXml()
$app = ($x.Event.EventData.Data | Where-Object {$*.Name -eq 'Application'}).'#text'
[pscustomobject]@{ Time = $_.TimeCreated; Application = $app }
} | Group-Object Application | Sort-Object Count -Descending |
Select-Object Count, Name

Filtrar 5158 no Event Viewer por `dns.exe`

Use um filtro XML personalizado (aplicável a Custom Views):

&lt;QueryList&gt;
  &lt;Query Id="0" Path="Security"&gt;
    &lt;Select Path="Security"&gt;
      *[System[(EventID=5158)]]
      and
      *[EventData[Data[@Name='Application' and (contains(., 'dns.exe') or contains(., 'DNS.EXE'))]]]
    &lt;/Select&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;

Para esconder dns.exe da vista (sem o impedir de ser registado):

&lt;QueryList&gt;
  &lt;Query Id="0" Path="Security"&gt;
    &lt;Select Path="Security"&gt;
      *[System[(EventID=5158)]]
      and
      not(*[EventData[Data[@Name='Application' and (contains(., 'dns.exe') or contains(., 'DNS.EXE'))]]])
    &lt;/Select&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;

Aumentar e proteger o tamanho do Log de Segurança

Amplie o Security para evitar rotatividade precoce e defina sobreposição automática (antigos primeiro):

# Aumentar para 500 MB (ajuste conforme a sua política)
wevtutil sl Security /ms:524288000
No Event Viewer &gt; Security &gt; Properties: "Overwrite events as needed (oldest events first)"

Alerta simples por limiar

Agende a cada 5 minutos um script que conta 5158 recentes e avisa se exceder limiar:

$janela = (Get-Date).AddMinutes(-5)
$cnt = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5158; StartTime=$janela} | Measure-Object | Select-Object -ExpandProperty Count
if ($cnt -gt 5000) {
  # Substitua pelo seu método de alerta
  Write-EventLog -LogName Application -Source "Admin" -EventId 9100 -EntryType Warning -Message "5158 &gt; 5k/5min no DC S1"
}

Mapa de hipóteses vs sintomas

Sinal observado	Hipótese provável	Testes rápidos	Mitigação
Somente S1 afetado; S2 normal	Encaminhador/loop local, interface errada, carga direcionada ao S1	Comparar Forwarders e interfaces; `netstat` na porta 53	Corrigir encaminhadores; alinhar interfaces; balancear clientes
Muitos NXDOMAIN	Cliente mal configurado, domínio inexistente em loop	Wireshark filtro por `dns.flags.rcode == 3`	Corrigir cliente; criar zona de sinkhole se apropriado
Queries predominantes tipo TXT/longas	DNS tunneling/segurança	Inspeção de payload na porta 53	Bloquear padrões; isolar origem; envolver SOC
Eventos 5158 em “explosões” após reinício	Recuperação de serviço / cache quente	Correlacionar com eventos 4000–4015 do DNS	Aplicar atualizações; revisar limites de cache e timeouts

Runbook rápido (15 minutos)

Confirmar a origem: filtrar 5158 por dns.exe (filtro XML acima).
Contar o volume: medir 10 minutos de eventos para dimensionar o impacto.
Ver tráfego: Wireshark em udp.port==53 or tcp.port==53 e identificar IPs de origem com maior QPS.
Aplicar mitigação de ruído: auditpol para Falhas apenas (se políticas o permitirem).
Corrigir configuração: rever encaminhadores, interfaces e limpar cache Clear-DnsServerCache.
Reiniciar serviço DNS fora de pico para estabilizar sockets.
Dimensionar o Security: aumentar o tamanho e ativar sobreposição.

Checklist de validação (depois da intervenção)

Queda sustentada na taxa de 5158 por minuto (>= 90% quando a auditoria de sucesso é desativada).
Sem erros 4000–4015 no log DNS Server durante pelo menos 24 horas.
Latência de resolução (nslookup) constante e tempo de CPU do dns.exe estável.
Clientes sem 1014 recorrente (DNS Client).

Resultado observado pelo autor

Nos dias seguintes, os picos de 5158 cessaram sem alteração manual evidente. A hipótese mais plausível é o efeito combinado e retardado de intervenções anteriores (limpeza de zonas/entradas, esvaziamento de cache e aplicação de atualizações), seguido de autorrecuperação do serviço DNS. Ainda assim, manter o hardening e a auditoria afinada é crucial para evitar regressões.

Recomendações complementares

Ajustar a auditoria ao risco real: em ambientes pequenos, auditar falhas costuma ser suficiente e poupa espaço e ruído.
Limitar e rodar o Security: defina um tamanho adequado e “Overwrite events as needed”. Considere forwarding (WEF) para retenção prolongada fora do DC.
Alertas proativos: Task Scheduler + script a contar 5158 por janela de tempo (ex.: > x/min). Assim recebe aviso antes de o log encher.
Documentar: registe alterações (GPO, DNS, patches) e crie um marco. Se o problema regressar, será mais fácil correlacionar a intervenção eficaz.

Perguntas frequentes

Posso desactivar 5158 apenas para o processo `dns.exe`?

Não a nível de política nativa. A subcategoria Filtering Platform Connection aplica‑se ao sistema. Pode, no entanto, filtrar a visualização (Event Viewer/SIEM) para esconder dns.exe dos relatórios do dia‑a‑dia e manter a auditoria conforme necessário.

Desativar a auditoria de sucesso em “Filtering Platform Connection” é seguro?

Depende do seu requisito de conformidade. Em muitos ambientes, auditar apenas falhas e manter “Packet Drop” ativo dá uma boa relação sinal/ruído. Caso a sua política exija rastreio de sucesso, aumente o tamanho do log e exporte os eventos para um coletor.

Porque só um DC tem o sintoma se ambos são DNS?

Diferenças pequenas (encaminhador, ordem de NIC, cliente “falador” a usar apenas um DC, ou loop local) são suficientes para concentrar tráfego num único servidor. Compare a configuração lado‑a‑lado e valide quem os clientes estão realmente a utilizar.

Como deteto DNS tunneling rapidamente?

Procure muitas queries TXT/NULL, nomes anormalmente longos ou padrão de subdomínios pseudo‑aleatórios, vinda de um único IP. Se confirmado, isole o host e envolva a equipa de segurança.

Conclusão

O Event ID 5158 a partir de dns.exe costuma ser um sintoma — não a causa. Resolver passa por três frentes: (1) corrigir a configuração DNS e eliminar loops, (2) entender o tráfego (quem está a falar, o quê e porquê) e (3) afinar a auditoria para captar o que importa sem entupir o Security. Com o roteiro acima, é possível estabilizar rapidamente e manter observabilidade adequada.

Anexos úteis

Lista de verificação de configuração DNS

Encaminhadores sem recursividade mútua (DC ↔ DC)?
Root hints apropriados ou desativados quando encaminhadores são preferidos?
Interfaces corretas em Propriedades > Interfaces (sem NICs desativadas/obsoletas)?
Zonas AD integradas a replicar apenas para os parceiros necessários?
Atualizações dinâmicas seguras e credenciais do DHCP válidas?

Consulta PowerShell para “top destinos” nas ligações 5158

$inicio = (Get-Date).AddMinutes(-30)
$xpath = "*[System[(EventID=5158) and TimeCreated[timediff(@SystemTime) &lt;= 1800000]]]"
Get-WinEvent -LogName Security -FilterXPath $xpath |
  ForEach-Object {
    [xml]$x = $_.ToXml()
    [pscustomobject]@{
      When = $_.TimeCreated
      App  = ($x.Event.EventData.Data | Where-Object {$_.Name -eq 'Application'}).'#text'
      Dst  = ($x.Event.EventData.Data | Where-Object {$_.Name -eq 'DestAddress'}).'#text'
      Proto= ($x.Event.EventData.Data | Where-Object {$_.Name -eq 'Protocol'}).'#text'
    }
  } | Where-Object {$_.App -match "dns.exe"} |
  Group-Object Dst | Sort-Object Count -Descending | Select-Object -First 10

Política de auditoria via GPO (caminho)

Configuração do Computador → Definições do Windows → Configuração Avançada de Política de Auditoria → Políticas de Auditoria do Sistema → Acesso a Objetos → Filtering Platform Connection.

IDs correlatos úteis para procurar

Security: 5156 (conexão permitida), 5157 (conexão bloqueada), 5158 (associação de endpoint).
DNS Server: 4000–4015 (estado do serviço), 5501/5504 (reencaminhamento).
DNS Client: 1014 (falha de resolução do próprio host).

Resumo executivo (para partilhar com gestão)

O enchimento do Log de Segurança por eventos 5158 originados pelo dns.exe decorre de alto volume de ligações auditadas pelo WFP. As ações de maior impacto são: auditar apenas falhas nesta subcategoria, corrigir a configuração DNS (eliminar loops/duplicações), monitorizar e reduzir tráfego anómalo e dimensionar o Security. Após ajustes e uma janela de estabilidade, o pico cessa e a operação normaliza.