URLs y puertos imprescindibles para habilitar Windows Update en Windows Server

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.

Índice

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 subdominioPuerto(s)Notas
http://windowsupdate.microsoft.com80Portal histórico; algunos agentes aún lo consultan.
http(s)://*.windowsupdate.microsoft.com80/443Núcleo del servicio Windows Update.
http(s)://*.update.microsoft.com80/443Microsoft Update (parches de otros productos).
http://*.windowsupdate.com80Conectividad auxiliar, telemetría de estado.
http://download.windowsupdate.com80Descarga de paquetes y catálogos.
http://download.microsoft.com80CDN alterna para contenido pesado.
http://*.download.windowsupdate.com80Instancias regionales de la CDN.
http://wustat.windows.com80Telemetría anónima (opcional, pero recomendada).
http://ntservicepack.microsoft.com80Compatibilidad 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:

  1. Equipos cliente → WSUS interno
    • Puerto 8530/TCP (HTTP) o 8531/TCP (HTTPS).
    • La URL suele ser http(s)://servidorWSUS:8530.
  2. 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 errorCausa principalAcción recomendada
0x80072EE2Timeout en conexión TCPComprueba que no haya IDS bloqueando svchost.exe.
0x80072EFDProxy exige autenticaciónConfigura netsh winhttp set proxy con credenciales.
0x8024402CDNS mal resueltoRevisa los servidores DNS o el split‑DNS interno.
0x8024401CSSL inspectionAñ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.

Índice