Hardening Windows Server: controles concretos y en qué orden aplicarlos

Endurecer un Windows Server en producción no es ejecutar una plantilla de GPO y reiniciar. Es reducir superficie de exposición —roles, servicios, accesos, cuentas y configuración base— sin cortar autenticación, aplicaciones ni accesos legítimos. El orden importa porque cada control cambia el estado del servidor y algunos son difíciles de revertir en caliente.

Este checklist está pensado para jefaturas de infraestructura y ciberseguridad que necesitan priorizar controles con criterio operacional, no para cumplir una lista plana de "buenas prácticas".

Qué implica hacer hardening en Windows Server y por qué el orden importa

El alcance real de un hardening de Windows Server se define sobre cuatro planos:

• Identidad y accesos: cuentas locales, grupos privilegiados, autenticación, RDP, acceso administrativo remoto.
• Roles y características: qué está instalado y qué se usa efectivamente.
• Servicios y puertos: qué escucha, en qué interfaz y con qué cuenta corre.
• Configuración base: políticas de contraseña, auditoría, firewall, actualizaciones, protocolos heredados (SMBv1, TLS antiguos, NTLM sin restricción).

"Endurecer todo" suele terminar en dos escenarios: un servidor que deja de autenticar contra un dominio mal documentado, o un equipo que nadie se atreve a tocar porque no hay certeza de qué rompe qué. Reducir exposición con criterio significa aplicar primero los controles de mayor impacto y menor riesgo de interrupción, y dejar para ventanas controladas los que afectan protocolos de autenticación o servicios compartidos.

El dolor operacional típico no es un ataque sofisticado: es un servidor con RDP expuesto a Internet, una cuenta local con la misma contraseña en diez equipos, SMBv1 habilitado por una aplicación antigua y servicios corriendo con cuentas de dominio privilegiadas. Esa es la superficie que conviene cerrar primero.

Controles de base: identidad, accesos y superficie de servicios

Antes de aplicar cambios, conviene levantar evidencia. Sin línea base no hay forma de saber si el endurecimiento rompió algo o si el problema ya existía.

Señales a observar antes de tocar nada:

• Inventario de cuentas locales y miembros de grupos privilegiados (Administradores, Administradores del dominio, Operadores de servidor, Usuarios de escritorio remoto).
• Servicios en ejecución, cuenta de servicio asociada y tipo de inicio.
• Puertos en escucha y en qué interfaz (Get-NetTCPConnection -State Listen).
• Roles y características instaladas frente a las efectivamente utilizadas.
• Método de administración remota en uso: RDP, WinRM, consola de virtualización, herramientas de gestión.
• Dependencias de autenticación: si el servidor es miembro de dominio, qué protocolos usa contra el DC y qué aplicaciones dependen de NTLM o LDAP sin firma.

Controles de base, en orden de bajo riesgo:

1. Cuentas locales: deshabilitar o renombrar la cuenta Administrador local, revisar cuentas creadas manualmente y eliminar las que no tengan dueño identificable. Verificar que la contraseña del administrador local esté gestionada (LAPS o equivalente) y no sea compartida entre equipos.
2. Grupos privilegiados: reducir membresía al mínimo operativo. Cada miembro debe tener justificación y ruta de acceso documentada.
3. Acceso remoto: restringir RDP por firewall a rangos administrativos o saltos definidos; nunca expuesto directamente a Internet. Si se usa WinRM, limitar a los hosts de gestión.
4. Servicios innecesarios: detener y deshabilitar lo que no se usa (por ejemplo, Remote Registry, Fax, Windows Search en servidores, servicios de impresión si no aplican). Documentar antes de deshabilitar.
5. Roles no utilizados: desinstalar características que no corresponden a la función del servidor. Un controlador de dominio no debería tener el rol de servidor web; un servidor de archivos no necesita Hyper-V.
6. Firewall de Windows: perfil activo por zona, reglas explícitas por servicio y origen, denegación por defecto en perfiles públicos.
7. SMBv1 y protocolos heredados: deshabilitar SMBv1 salvo dependencia documentada; revisar firma SMB y NTLM.
8. Auditoría: habilitar políticas de auditoría de inicio de sesión, cambios de cuenta y acceso a objetos críticos antes de aplicar el resto, para tener trazabilidad de lo que ocurra.

Cada uno de estos controles se puede aplicar en producción con ventana corta y reversión simple. Los que afectan autenticación (NTLM, Kerberos, niveles de LAN Manager, restricciones de RDP con NLA) requieren prueba previa en un equipo equivalente.

Checklist priorizado de controles de hardening para Windows Server

El siguiente orden combina impacto sobre superficie de ataque y riesgo de interrupción. No es una secuencia rígida: en un servidor aislado se puede comprimir; en un servidor con aplicaciones críticas conviene respetar el escalonamiento.

Bloque 1 — Sin riesgo operacional apreciable (aplicar primero):

• Inventario de cuentas locales y grupos privilegiados, con dueño identificado por cuenta.
• Renombrar o deshabilitar Administrador local y cuenta Invitado.
• Restringir RDP y WinRM por firewall a rangos de administración.
• Deshabilitar servicios y roles no utilizados, con registro de lo deshabilitado.
• Activar auditoría de inicios de sesión y cambios de cuenta.
• Verificar que el firewall esté activo en todos los perfiles y con denegación por defecto.

Bloque 2 — Riesgo bajo, requiere verificación de dependencias:

• Deshabilitar SMBv1 tras confirmar que ninguna aplicación ni equipo legacy lo requiere.
• Exigir firma SMB y deshabilitar acceso anónimo a recursos compartidos.
• Revisar permisos de carpetas compartidas y quitar Todos donde no corresponda.
• Configurar política de contraseñas local coherente con la de dominio para cuentas no domain.
• Deshabilitar protocolos TLS antiguos (SSL 3.0, TLS 1.0/1.1) en servicios que lo permitan, verificando compatibilidad de aplicaciones.
• Revisar tareas programadas y scripts que corran con credenciales embebidas.

Bloque 3 — Riesgo medio, requiere ventana y prueba previa:

• Restringir NTLM (auditar primero, luego restringir) y revisar dependencias de autenticación heredada.
• Exigir NLA en RDP y limitar el número de sesiones simultáneas.
• Aplicar línea base de configuración (CIS Benchmark, Microsoft Security Baseline u otra referencia) con desviaciones documentadas.
• Endurecer permisos de servicio y cuentas de servicio gestionadas (gMSA) donde la aplicación lo soporte.
• Revisar y limitar delegaciones Kerberos y privilegios excesivos en cuentas de servicio.

Bloque 4 — Riesgo alto, planificar con cuidado:

• Cambios en niveles de autenticación LAN Manager y restricciones de Kerberos.
• Endurecimiento de servicios de directorio (si el servidor es DC) y de confianza entre dominios.
• Aplicación de AppLocker o WDAC en servidores con aplicaciones de terceros.
• Restricciones de ejecución de PowerShell y registro de bloques de script.

Señales para verificar que el endurecimiento no rompió la operación:

• Inicios de sesión fallidos en el visor de eventos de seguridad tras aplicar cambios de autenticación.
• Errores de aplicación en logs propios del servicio afectado.
• Conectividad desde los hosts legítimos hacia los puertos que se restringieron.
• Funcionamiento de tareas programadas y respaldos que usan cuentas de servicio.
• Acceso de usuarios a recursos compartidos y a la aplicación publicada.

Si el servidor forma parte de una operación sujeta a requisitos regulatorios, conviene registrar cada control aplicado, su justificación y la evidencia de verificación. Eso facilita la trazabilidad y sirve como insumo para preparación ante marcos como la Ley 21.719, sin que ello implique por sí solo cumplimiento normativo.

Cómo sostener el hardening sin convertirlo en un proyecto único

Un checklist aplicado una vez se degrada: aparecen servicios nuevos, cuentas temporales que quedan, parches que revierten configuraciones. Sostenerlo requiere tres prácticas mínimas:

• Línea base versionada: la configuración endurecida debe estar en un repositorio o herramienta de gestión (GPO, DSC, Ansible, Intune) y no solo en el servidor.
• Detección de desviaciones: comparar periódicamente el estado real contra la línea base y alertar sobre diferencias.
• Revisión de excepciones: cada control desviado debe tener dueño, motivo y fecha de revisión.

El criterio para evaluar si el hardening está funcionando no es cuántos controles se aplicaron, sino cuánta superficie de exposición real queda abierta y cuántas excepciones siguen vigentes sin justificación. Si el inventario de cuentas privilegiadas, puertos expuestos y servicios innecesarios no se puede responder en menos de una hora, el problema no es la plantilla de hardening: es la falta de visibilidad.

Si necesitas ordenar este trabajo en tu operación, puedes revisar el enfoque de Hardening & Seguridad.