Permitir que un servidor Windows descargue parches directamente de Microsoft no solo garantiza que el sistema permanezca protegido contra vulnerabilidades críticas, sino que evita los costosos tiempos de inactividad derivados de actualizaciones fallidas. A continuación encontrarás una guía práctica, exhaustiva y actualizada para abrir únicamente los puertos y dominios necesarios, mantener la seguridad perimetral y cumplir las políticas corporativas de mínima exposición.
Por qué resulta imprescindible ajustar el firewall
Windows Update usa una infraestructura distribuida de DNS y CDN que cambia dinámicamente. Bloquear alguno de sus nodos —o inspeccionarlo en exceso— puede desencadenar:
- Errores 0x8024402C, 0x80072EE2, 0x80244023 y similares.
- Fallas de firma de paquetes CAB y catálogos .CAT debido a la alteración del certificado en proxies SSL.
- Desfase en parches de zero‑day y definiciones de Defender, elevando la superficie de ataque.
Dominios y puertos que deben mantenerse abiertos
Cuando el servidor no usa WSUS y se conecta directamente a Microsoft, bastan los puertos estándar 80/TCP (HTTP) y 443/TCP (HTTPS) hacia los dominios siguientes. Emplea comodines para abarcar cualquier subdominio nuevo que Microsoft agregue sin previo aviso:
Dominio o subdominio | Puerto(s) | Notas |
---|---|---|
http://windowsupdate.microsoft.com | 80 | Portal histórico; algunos agentes aún lo consultan. |
http(s)://*.windowsupdate.microsoft.com | 80/443 | Núcleo del servicio Windows Update. |
http(s)://*.update.microsoft.com | 80/443 | Microsoft Update (parches de otros productos). |
http://*.windowsupdate.com | 80 | Conectividad auxiliar, telemetría de estado. |
http://download.windowsupdate.com | 80 | Descarga de paquetes y catálogos. |
http://download.microsoft.com | 80 | CDN alterna para contenido pesado. |
http://*.download.windowsupdate.com | 80 | Instancias regionales de la CDN. |
http://wustat.windows.com | 80 | Telemetría anónima (opcional, pero recomendada). |
http://ntservicepack.microsoft.com | 80 | Compatibilidad con actualizaciones de versiones antiguas. |
Por qué no se incluyen rangos IP
El espacio de direcciones de Microsoft cambia continuamente y se anuncia vía BGP. Fijar rangos estáticos obliga a un excesivo mantenimiento y rompe actualizaciones el día que Microsoft migra la CDN. Por ello se aconseja filtrar por FQDN con wildcard.
Entornos con Windows Server Update Services (WSUS)
En organizaciones medianas o grandes, WSUS permite descargar los parches una sola vez y redistribuirlos internamente, ahorrando ancho de banda y tiempo de validación. La comunicación se divide en dos capas:
- Equipos cliente → WSUS interno
- Puerto 8530/TCP (HTTP) o 8531/TCP (HTTPS).
- La URL suele ser
http(s)://servidorWSUS:8530
.
- WSUS interno → Microsoft
- Exactamente los mismos dominios y puertos expuestos en la tabla anterior.
En Group Policy, configura la directiva “Specify intranet Microsoft update service location” con la URL de tu WSUS. Así los clientes jamás intentarán salir directamente a Internet, simplificando el esquema de firewall.
Cómo crear las reglas en Windows Firewall con PowerShell
# Permitir salida HTTP
New-NetFirewallRule -DisplayName "WU_HTTP" `
-Description "Windows Update HTTP" `
-Direction Outbound -Action Allow -Protocol TCP -RemotePort 80 `
-RemoteAddress Any -Program "%windir%\system32\svchost.exe"
Permitir salida HTTPS
New-NetFirewallRule -DisplayName "WU\_HTTPS" ` -Description "Windows Update HTTPS"`
-Direction Outbound -Action Allow -Protocol TCP -RemotePort 443 \`
-RemoteAddress Any -Program "%windir%\system32\svchost.exe"
Consejo: especificar -Program
reduce el riesgo de que otro proceso abuse de la regla.
Configuración en firewalls de red o proxys empresariales
- Permite HTTP/HTTPS de salida solo para el Service SID del servidor o la VLAN que aloje a los controladores de dominio.
- Crea un perfil categorizado como “Update Services” y asócialo a los FQDN de la tabla; evita usar opciones de reputación (WebFilter) que bloqueen “software updates”.
- En proxys transparentes, desactiva la inspección TLS para los dominios indicados; de lo contrario, el agente de Windows romperá la cadena de confianza y abortará la descarga.
Verificación de conectividad
Antes y después de modificar reglas, verifica que el servidor pueda resolver los FQDN correctamente y que el tráfico salga por el puerto adecuado.
# Resolución DNS
Resolve-DnsName download.windowsupdate.com
Prueba de establecimiento de conexión
Test-NetConnection download.windowsupdate.com -Port 443
Comprobar proxy WinHTTP vigente
netsh winhttp show proxy
Volcado del registro de Windows Update
Get-WindowsUpdateLog -Confirm:\$false
Solución de problemas habituales
Código de error | Causa principal | Acción recomendada |
---|---|---|
0x80072EE2 | Timeout en conexión TCP | Comprueba que no haya IDS bloqueando svchost.exe . |
0x80072EFD | Proxy exige autenticación | Configura netsh winhttp set proxy con credenciales. |
0x8024402C | DNS mal resuelto | Revisa los servidores DNS o el split‑DNS interno. |
0x8024401C | SSL inspection | Añade los FQDN a la lista de exclusión del proxy. |
Automatización y control de cambios
Para evitar desviaciones de configuración entre servidores, integra las reglas en tu herramienta de Infrastructure as Code:
# Ejemplo en Desired State Configuration (DSC)
Configuration WinUpdateFirewall {
Node "SRV‑PROD‑01" {
FirewallRule WU_HTTP {
Ensure = "Present"
Name = "WU_HTTP"
Direction = "Outbound"
LocalPort = "Any"
RemotePort = "80"
Protocol = "TCP"
Action = "Allow"
Program = "%windir%\\system32\\svchost.exe"
}
FirewallRule WU_HTTPS {
Ensure = "Present"
Name = "WU_HTTPS"
Direction = "Outbound"
LocalPort = "Any"
RemotePort = "443"
Protocol = "TCP"
Action = "Allow"
Program = "%windir%\\system32\\svchost.exe"
}
}
}
WinUpdateFirewall
Registra el archivo .mof
resultante en tu repositorio Git; cualquier modificación quedará trazada y auditable.
Buenas prácticas de seguridad complementarias
- Principio de mínimo privilegio: limita las reglas a Outbound; en la mayoría de escenarios nada necesita entrar por los puertos 80/443 hacia el servidor.
- Actualiza la CA raíz: un almacén obsoleto puede provocar errores de firma incluso si la conectividad es correcta.
- Supervisa con eventos ID 19, 20, 31 de
Microsoft‑Windows‑WindowsUpdateClient/Operational
para alertar de descargas fallidas. - Segmenta la red: coloca los servidores críticos en VLANs aisladas con reglas allow‑list específicas; bloquea todo lo demás.
- Programa las descargas fuera de horas punta: con la directiva “Automatic Updates detection frequency” controla el impacto en el ancho de banda.
Preguntas frecuentes
¿Puedo bloquear wustat.windows.com
para reducir telemetría?
Sí, no impedirá la descarga de parches. Sin embargo, perderás métricas de tasa de éxito y versión de firma de Defender en el panel de Azure Arc o Intune.
¿Es suficiente permitir HTTPS y bloquear HTTP?
No se recomienda. Aunque la mayoría de descargas grandes se migraron a HTTPS, el agente aún realiza llamadas HTTP para metadatos y compatibilidad con versiones anteriores. Bloquear el puerto 80 genera errores intermitentes difíciles de diagnosticar.
¿Cuál es la mejor estrategia si mi proxy requiere autenticación NTLM?
Ejecuta:
netsh winhttp set proxy proxy.miempresa.com:8080 "<local>"
El agente Windows Update usa WinHTTP (no WinINET), por lo que las credenciales del usuario interactivo no aplican. Configura la cuenta de servicio Network Service
con permiso para autenticarse en el proxy.
Conclusión
Permitir Windows Update con criterios estrictos —puertos 80/443 y los FQDN concretos— ofrece la doble ventaja de seguridad y cumplimiento normativo. Si usas WSUS, recuerda que solo el servidor WSUS necesita salida; los clientes quedan confinados. Documenta las reglas, automatízalas con PowerShell o DSC y supervisa los eventos para garantizar que cada parche llegue a tiempo.
Con estas prácticas, tu infraestructura Windows Server mantendrá un ciclo de parches fluido, reducirá la exposición a amenazas y pasará auditorías de seguridad sin sorpresas.