Cómo detener la avalancha de eventos 5158 de dns.exe en Windows Server

Una avalancha de eventos 5158 de Filtering Platform Connection generados por dns.exe puede llenar el registro de seguridad de un controlador de dominio en pocas horas, provocar ralentizaciones en la consola de eventos y enmascarar alertas críticas. A continuación encontrarás una guía completa y práctica para entender la causa, diagnosticarla y detenerla en Windows Server 2016, aplicable igualmente a versiones posteriores.

Índice

Entendiendo el evento 5158

El identificador 5158 pertenece a la auditoría de la Windows Filtering Platform (WFP) y se dispara cada vez que una aplicación abre un flujo de red saliente. Cuando el servicio DNS lo hace con gran frecuencia, el Visor de eventos muestra millones de entradas en tiempo récord.

Origen: WFP – capas FWPMLAYERALEAUTHCONNECT_V4/V6.
Proceso: dns.exe localizado en %systemroot%\system32.
Datos clave: PID, dirección/puerto local y remoto, ID de capa, action=PERMIT/DENY.

Por qué puede dispararse masivamente en un DC

En un controlador de dominio, el servicio DNS resuelve nombres para todo el bosque y realiza forwarders a Internet. Entre las causas típicas que multiplican el número de flujos se incluyen:

Reintentos TCP/UDP provocados por zonas mal configuradas o registros huérfanos.
Bucles de resolución entre reenviadores internos.
Equipos infectados que generan consultas inusuales (túneles DNS).
Firewalls de terceros que fuerzan un handshake a cada consulta.
Auditoría de WFP ampliada o directivas GPO de seguridad demasiado verbosas.

Metodología de diagnóstico paso a paso

Revisar la configuración DNS

Comienza asegurando que ambas réplicas (S1 y S2) comparten la misma topología DNS:

Elimina zonas obsoletas o duplicadas.
Ejecuta dnscmd /enumrecords y borra registros huérfanos con dnscmd /recorddelete.
Comparte reenviadores idénticos en ambos DCs y evita que uno reenvíe al otro.

Monitorizar el tráfico de red

Usa Wireshark o Microsoft Network Monitor 3.4 en S1 durante un pico de eventos:

> netsh trace start capture=yes tracefile=c:\temp\DNSOverflow.etl scenario=internetclient

Filtra paquetes con dns && frame.len > 0 para detectar orígenes masivos. Analiza:

Indicador	Qué significa
Consultas repetidas hacia la misma IP	Posible bucle o endpoint caído
Hosts internos con miles de peticiones/min	Malware o tareas mal programadas
Tamaño anómalo (>512 bytes)	Exfiltración por túnel DNS

Comprobar Firewall y antivirus

Firewalls de endpoint insertan filtros WFP y pueden reabrir conexiones a cada consulta. Para aislarlos:

Deshabilita temporalmente el antivirus en S1 y mide los eventos.
Ejecuta fltmc y netsh wfp show filters para listar filtros ajenos a Microsoft.
Si usas Endpoint Protection, desactiva las reglas DNS inspection y registra la diferencia.

Actualizaciones y validación del sistema

Asegúrate de aplicar el CU más reciente para Windows Server 2016, con foco en parches de DNS:

dism /online /cleanup-image /scanhealth
sfc /scannow

Si el SFC devuelve archivos corruptos, restaura y reinicia el servicio DNS:

Restart-Service DNS -Force

Correlacionar con otros registros

Los eventos 5158 rara vez vienen solos. Revisa “Sistema” y “Aplicación” buscando:

6008 (apagados inesperados) – presión de recursos.
1014 (Resolver): error de resolución recursiva.
5010 (DNS): agotamiento de sockets.

Una coincidencia temporal indicará la raíz.

Ajustar la auditoría WFP

Si la organización no necesita trazabilidad fina de cada flujo, reduce la auditoría sin perder seguridad:

Abre gpedit.msc en “Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Policy → Object Access → Filtering Platform Connection”.
Habilita sólo Failure o directamente No auditing.
Aplica gpupdate /force y reinicia el servicio DNS.

Reiniciar servicios o el servidor

Un reinicio limpia el estado interno de WFP, libera PU control blocks y vacía buffers de log. Programa la ventana fuera de horario y documenta la caída.

Verificar recursos de hardware

Millones de eventos implican I/O sostenido. Comprueba:

Cola de disco: Get-Counter '\PhysicalDisk(_Total)\Avg. Disk Queue Length'
Uso de CPU: picos >80 % sostenidos implican bucles.
Páginas/s en memoria: valores >20 indican swapping.

Escalar a soporte Microsoft

Con un case number abierto, Microsoft puede:

Activar trazas ETW de WFP (netsh wfp).
Analizar minidumps de dns.exe y determinar fugas de handle.
Suministrar parches fuera de banda.

Automatizar la limpieza del Visor de eventos

Para evitar bloqueos de la consola:

wevtutil sl security /ms:32768             REM Eleva tamaño máximo a 32 MB
wevtutil cl security                      REM Limpia el log (exporta antes)
schtasks /create /sc weekly /tn Purge5158 /tr "wevtutil cl security"

Apéndice A – Scripts útiles en PowerShell

Contar entradas 5158 en tiempo real
Get-WinEvent -FilterHashtable @{LogName='Security';ID=5158; StartTime=(Get-Date).AddHours(-1)} | Measure-Object

Exportar los 100 000 eventos más recientes a CSV

Get-WinEvent -FilterHashtable @{LogName='Security';ID=5158} -MaxEvents 100000 |
Export-Csv C:\temp\DNS\_5158.csv -NoTypeInformation

Deshabilitar auditoría de conexión

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

Apéndice B – Tabla resumida de acciones

Paso	Acción	Objetivo
Revisar DNS	Eliminar zonas y registros anómalos	Evitar loops y reintentos
Monitorizar tráfico	Wireshark, `netsh trace`	Identificar origen de la tormenta
Comprobar firewall/AV	Desactivar filtros, validar WFP	Reducir flujos innecesarios
Actualizar sistema	KBs y `sfc`/`dism`	Corregir binarios dañados
Correlacionar registros	Eventos 6008, 1014, 5010…	Ubicar causa raíz
Ajustar auditoría	GPO o `auditpol`	Detener la avalancha
Reiniciar servicios	`Restart-Service DNS`	Restablecer contadores
Verificar recursos	CPU, RAM, disco	Descartar cuellos de botella
Escalar a Microsoft	Trazas ETW, hotfix	Soporte de bajo nivel

Prevención a largo plazo

Establecer límites de tamaño de log razonables (32–64 MB) y programar su depuración.
Aplicar revisiones mensuales de zonas DNS y reenviadores.
Implementar listas de control de acceso (ACL) en los firewalls para bloquear dominios maliciosos conocidos.
Usar Microsoft Defender for Identity para detectar túneles y exfiltración por DNS.
Automatizar alertas cuando el contador de eventos 5158 supere un umbral.

Conclusiones

Los eventos 5158 en masa suelen ser síntoma, no causa. Identificar y corregir la configuración DNS, racionalizar la auditoría y descartar software de filtrado excesivamente intrusivo devuelve el servicio a la normalidad sin comprometer la seguridad. Aunque en ocasiones el fenómeno se “autocorrige” tras reinicios o cambios acumulativos, disponer de un procedimiento documentado garantiza respuestas más rápidas la próxima vez.