Checklist hardening Windows Server: la guía de red 2026

En pocas palabras: El hardening de red en Windows Server pasa por nunca exponer RDP (3389) ni SMB (445) a internet, usar VPN o gateway, activar NLA, desactivar SMBv1, poner contraseñas únicas con Windows LAPS, firewall bloqueado en los tres perfiles y auditar logons con backup offline.

Un checklist hardening Windows Server bien aplicado arranca por lo obvio: RDP y SMB expuestos a internet, SMBv1 todavía activo y la misma contraseña de administrador local repetida en todos los servidores. Según el checklist publicado originalmente en coinetic.io y republicado en dev.to, esos puntos de red y logon explican la mayoría de los ataques que realmente llegan a producción.

Un checklist de hardening para Windows Server es una lista de verificaciones de seguridad de red y acceso remoto que reduce la superficie de ataque de un servidor: firewall, puertos abiertos, configuración de RDP, SMB, contraseñas y auditoría de logons. No reemplaza al CIS Benchmark completo, pero cubre los puntos de red y logon que más explotan los atacantes.

¿Por qué la mayoría de los ataques a Windows Server no necesitan exploits sofisticados?

Porque entran por una puerta que alguien dejó abierta, no por una vulnerabilidad de día cero. RDP expuesto a internet con una contraseña adivinada, SMB viejo sin parchear o un firewall que un colega apagó “para probar algo rápido” y nunca volvió a prender. Eso es casi todo lo que necesita un atacante promedio.

Ningún CVE llamativo. Ningún exploit vendido en un foro. Solo un escáner de puertos corriendo todo el día, un diccionario de contraseñas comunes y paciencia.

Pensalo así: subís un servidor nuevo, lo configurás apurado porque hay una migración pendiente, dejás el firewall en modo “ya lo ajusto después”, te olvidás, pasan tres semanas y en el log aparecen cientos de intentos de logon fallido en RDP que nadie miró porque nadie estaba mirando el log. Ese escenario (bastante más común de lo que a cualquiera le gustaría admitir) es el que este checklist ataca de frente.

¿Cómo configurar el firewall de Windows Server con los tres perfiles activados?

El firewall de Windows Server tiene que estar activo en los tres perfiles (Domain, Private, Public) con el tráfico entrante bloqueado por defecto, salvo que una regla específica lo permita. Se verifica con Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction: el resultado esperado es Enabled True y DefaultInboundAction Block (o NotConfigured, que equivale a bloqueo). En el artículo sobre diferencias entre Microsoft y GitHub profundizamos sobre esto.

Ojo con el perfil de red: un servidor que forma parte de un dominio debería mostrar DomainAuthenticated en Get-NetConnectionProfile. El problema es que después de un reinicio, Windows puede caer al perfil Public sin avisar, y ahí las reglas que aplican son otras, generalmente más laxas de lo que uno pensaba.

Dos revisiones más que no toman más de cinco minutos: buscar reglas de entrada con dirección remota “Any” (cada una es una puerta abierta al mundo entero si el puerto está mapeado o el servidor tiene IP pública) y borrar reglas que apuntan a programas que ya no existen, sobre todo si están en carpetas donde cualquiera puede escribir un ejecutable propio.

¿Qué puertos hay que cerrar o restringir en un checklist hardening Windows Server?

Los puertos críticos a revisar son RDP (3389), SMB (445/139), WinRM (135, 5985/5986), motores de base de datos (1433, 3306, 5432) y VNC (5900+). Se listan con Get-NetTCPConnection -State Listen cruzado con el proceso que los usa, pero que un puerto esté escuchando no significa que sea alcanzable desde afuera: eso lo decide el firewall y el router.

Puerto	Servicio	Recomendación
3389	Remote Desktop	Nunca abierto a todo internet. VPN, gateway de RDP, o regla de firewall limitada a IPs propias.
445, 139	SMB / compartición de archivos	Solo LAN. Nunca mapeado desde internet.
135, 5985/5986	RPC, WinRM (PowerShell remoto)	LAN o red de gestión exclusivamente.
1433, 3306, 5432	SQL Server, MySQL, PostgreSQL	Solo desde los servidores de aplicación que realmente lo necesitan.
5900+	VNC	Desinstalar, o acceder únicamente por VPN.

Vale revisar también el router o el security group de la nube: ahí suele aparecer un mapeo de puertos que alguien configuró hace un año y nadie recuerda por qué existe.

¿Cómo hacer hardening de RDP en Windows Server?

El hardening de RDP pasa por activar Network Level Authentication, limitar el grupo Remote Desktop Users, exigir MFA en todo acceso remoto y cerrar sesiones desconectadas por tiempo. NLA se activa en Propiedades del sistema, pestaña Remoto, marcando la opción que exige autenticación antes de crear la sesión: la contraseña se valida antes de abrir nada. Para más detalles técnicos, mirá la comparativa de rendimiento con Ubuntu.

¿Cambiar el puerto 3389 ayuda en algo? Apenas. Solo esconde el servicio de los escáneres más perezosos; cualquier herramienta decente de reconocimiento de red lo encuentra en el puerto que sea, en minutos. No es protección, es maquillaje.

Lo que sí suma: mantener el grupo Remote Desktop Users chico (los administradores entran por default, así que ese grupo también hay que vigilarlo), exigir MFA en VPN y gateway de RDP, y configurar vía Group Policy el cierre de sesiones desconectadas después de un tiempo límite razonable.

Criterios para elegir entre VPN, gateway o regla de firewall en RDP

El checklist deja claro que RDP no debe ir directo a internet, pero no todas las organizaciones necesitan la misma solución. La decisión suele depender de cuántas personas acceden y desde dónde:

• Pocos administradores, siempre desde la misma IP fija (oficina con IP estática, por ejemplo): una regla de firewall que limite el Remote IP address a esas direcciones conocidas puede ser suficiente, combinada con NLA y contraseña fuerte.
• Equipo que se conecta desde IPs dinámicas, home office o varias sucursales: ahí la regla de firewall por IP se vuelve inmanejable (hay que actualizarla cada vez que cambia una IP). Conviene una VPN primero, y NLA del lado de adentro.
• Terceros, proveedores o accesos puntuales que no conviene meter en la VPN corporativa: un Remote Desktop Gateway centraliza la autenticación y el registro de quién entró, sin exponer el puerto RDP directamente.

Ejemplo hipotético (ilustrativo, no un caso real): imaginemos una pyme con tres servidores Windows y dos administradores que siempre trabajan desde la misma oficina. En ese escenario, una regla de firewall limitada a la IP pública de la oficina, sumada a NLA y Windows LAPS, cubre el riesgo principal sin necesidad de levantar una VPN completa. Ahora imaginemos la misma pyme seis meses después, con un tercer administrador que trabaja desde su casa con IP dinámica y un proveedor externo que necesita acceso puntual una vez por mes: ahí la regla por IP fija ya no alcanza, y el checklist empuja naturalmente hacia una VPN (para el administrador remoto) y un gateway con MFA (para el acceso puntual del proveedor, que además queda registrado sin necesidad de abrirle una cuenta permanente). La lógica no cambia; lo que cambia es quién necesita entrar y desde dónde.

¿Cómo desactivo SMBv1 en Windows Server?

SMBv1 se desactiva con Set-SmbServerConfiguration -EnableSMB1Protocol $false, después de confirmar el estado actual con Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol. Desde Windows Server 2019 no viene instalado por default, pero servidores más viejos migrados o actualizados in-place suelen conservarlo sin que nadie lo note.

Antes de apagarlo, conviene asegurarse de que no haya un NAS viejo o un scanner de red que todavía dependa de ese protocolo (pasó más de una vez: se desactiva SMBv1, la impresora de red deja de funcionar, y ahí empieza el ida y vuelta con el área de IT). El firmado de SMB también debería estar activo en controladores de dominio y file servers, siguiendo el Security Baseline de Microsoft correspondiente a la versión del servidor. Y nada de shares anónimos: los permisos de compartición tienen que ser tan estrictos como los permisos NTFS que hay detrás.

¿Por qué no hay que repetir la misma contraseña de administrador en todos los servidores?

Porque la misma contraseña de administrador local en todos los servidores convierte a cualquiera de ellos en la llave de todos los demás. Si un atacante compromete uno, se mueve lateralmente al resto sin esfuerzo adicional. Windows LAPS, que ya viene integrado en versiones actuales de Windows y Windows Server, rota y almacena esas contraseñas por servidor sin que nadie tenga que anotarlas en una planilla de Excel (sí, en serio, todavía existen esas planillas). Lo explicamos a fondo en guía para conectarte por SSH a una VM.

Separá también las cuentas de administración de las de uso diario: nadie debería revisar el mail o navegar con la cuenta que administra el dominio. Para cuentas de servicio, lo ideal son grupos managed service accounts (gMSA) con los permisos mínimos que necesitan, nada más.

Si administrás un VPS Windows alojado en la nube, buena parte de la capa de infraestructura ya viene reforzada por el proveedor, pero la configuración de red y accesos sigue siendo tuya. En Argentina, proveedores como donweb.com ofrecen Windows Hosting y Cloud Servers, pero aplicar estas reglas y mantener visibilidad sobre qué está abierto sigue siendo tarea de quien administra el servidor.

¿Cómo auditar los logons y preparar backups que sobrevivan a un ataque?

La auditoría de logons se activa con auditpol /get /category:"Logon/Logoff", usando la Advanced Audit Policy (no la mezcles con las nueve categorías viejas). El tamaño del log de seguridad importa: en un servidor con tráfico medio, el tamaño por defecto se llena en horas o días, así que hay que agrandarlo para cubrir varias semanas o mandar los eventos a un colector central.

¿Y sirve de algo auditar todo? No necesariamente. Auditar categorías como Sensitive Privilege Use puede generar decenas de eventos por segundo y frenar el servidor sin sumar protección real. El punto medio es clave, y alguien tiene que mirar esos logs: uno que nadie revisa solo es útil después de que ya pasó el daño.

Sobre backups: al menos una copia offline o inmutable, inalcanzable con la contraseña de administrador de dominio, porque el ransomware borra primero las copias que puede tocar. Probar la restauración de forma periódica, incluyendo un servidor completo, no es opcional.

Errores comunes al aplicar un checklist de hardening en Windows Server

• Creer que cambiar el puerto de RDP alcanza: un escáner de red lo encuentra igual en minutos. La protección real viene de VPN, gateway, NLA y contraseñas fuertes.
• Aplicar el CIS Benchmark completo sin testear antes: algunas configuraciones rompen aplicaciones viejas o herramientas de gestión remota. Conviene empezar por los puntos de red y logon de este checklist.
• Dejar la auditoría apagada “porque genera mucho log”: sin auditoría de logon, un ataque puede pasar semanas sin que nadie lo note.
• Usar la misma contraseña de administrador local en todos los servidores: convierte un solo compromiso en acceso total a toda la infraestructura.
• Revisar el hardening una sola vez y nunca más: un firewall que se apaga un viernes para “una prueba rápida” y queda así hasta el lunes es más común de lo que parece.

Preguntas Frecuentes

¿Cuál es el paso más importante para hacer hardening de un Windows Server?

No exponer Remote Desktop ni SMB a internet. La mayoría de los ataques exitosos contra servidores Windows arrancan con password guessing sobre un puerto RDP abierto al mundo. Tema relacionado: certificaciones de Azure según tu rol.

¿Es suficiente cambiar el puerto de RDP para protegerlo?

No. Los escáneres de red encuentran RDP en cualquier puerto en minutos. Hace falta VPN o gateway, limitar la regla a direcciones conocidas, y mantener NLA activo junto con contraseñas fuertes.

¿Cómo sé si el firewall de Windows Server está bloqueando correctamente las conexiones entrantes?

Corré Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction en PowerShell. Si los tres perfiles muestran Enabled True y DefaultInboundAction Block (o NotConfigured), el bloqueo por defecto está activo.

¿Cómo desactivo SMBv1 en Windows Server?

Con el comando Set-SmbServerConfiguration -EnableSMB1Protocol $false en PowerShell como administrador. Antes conviene verificar con Get-SmbServerConfiguration que nada dependa todavía de ese protocolo, como un NAS o scanner viejo.

¿Con qué frecuencia hay que revisar la configuración de seguridad de un servidor?

Después de cada actualización, instalación de software nuevo o cambio hecho por un colega, y al menos una vez por mes. La configuración se desvía con el tiempo, y solo una revisión continua detecta los cambios entre una pasada y la siguiente.

Conclusión

Este checklist hardening Windows Server no inventa nada nuevo: toma los puntos de red y logon que el CIS Benchmark y las Security Baselines de Microsoft ya cubren hace años, y los ordena por prioridad real de ataque. Lo accionable es concreto: correr Get-NetFirewallProfile y Get-NetTCPConnection hoy mismo, confirmar que RDP y SMB no estén expuestos a internet, apagar SMBv1 si todavía está activo, y meter Windows LAPS en la lista de pendientes de esta semana.

Lo que esta guía no reemplaza es una revisión periódica, ni el criterio para elegir entre VPN, gateway o una simple regla de firewall según quién necesita entrar y desde dónde (como se ve en el ejemplo de la pyme más arriba, ese criterio cambia con el tiempo, no es una decisión que se toma una sola vez). Un servidor hardenizado hoy puede dejar de estarlo la semana que viene si nadie vuelve a mirar. Como criterio práctico de verificación: antes de dar por cerrado cualquier ítem de este checklist, confirmá el resultado con el comando PowerShell correspondiente y no solo con la configuración que aparece en la interfaz gráfica, porque ahí es donde suelen aparecer las diferencias entre lo que uno cree que está activo y lo que realmente está corriendo.

Fuentes

• Coinetic AI Security – Windows Server hardening checklist (practical, network side)
• Coinetic.io – Firewall e intrusion-protection manager para Windows Servers y PCs
• CIS Benchmarks – Referencia completa de configuraciones de seguridad para Windows Server