Checklist de endurecimiento de Windows Server expuesto

Cómo usar esta lista

Las checklists de endurecimiento suelen fallar por un motivo: están ordenadas alfabéticamente y no por riesgo. La gente baja por ellas y se queda sin tiempo hacia la política del salvapantallas, sin haber llegado nunca al acceso remoto.

Esta está ordenada. Las primeras secciones eliminan las vías por las que los servidores se comprometen de verdad. La última merece hacerse y no te salvará por sí sola. Si solo tienes una tarde, haz las secciones 2 y 3 y para.

Da por supuesto un servidor que debe seguir accesible desde internet. Si el tuyo no tiene por qué estarlo, la sección 3 se reduce a una línea, y eso es una buena noticia.

1. Cuentas y autenticación

Casi todo compromiso de un servidor Windows expuesto empieza con credenciales válidas — adivinadas, obtenidas por spraying, reutilizadas de otra filtración o conseguidas por phishing. Ahí es donde debe ir el esfuerzo.

• Deshabilita o renombra la cuenta Administrator integrada. Es el primer nombre de toda lista de ataque, y su SID bien conocido hace que renombrarla no sea por sí solo una defensa — mejor deshabilitarla, con una cuenta de administrador nombrada aparte.
• Exige autenticación multifactor en toda cuenta que pueda iniciar sesión de forma remota. Es la medida de mayor valor de esta lista; una contraseña adivinada no vale nada sin el segundo factor.
• Impón contraseñas largas — un mínimo de 15 caracteres resiste el descifrado offline mucho mejor que las reglas de complejidad sobre una más corta — y bloquea contraseñas conocidas de filtraciones si tu herramienta lo permite.
• Audita quién tiene realmente acceso remoto. Elimina cuentas de gente que se fue, de contratistas cuyo trabajo terminó y de servicios que ya no existen. Cada cuenta dormida es superficie de ataque sin nadie vigilándola.
• Da a las cuentas de servicio identidad propia, sin derechos de inicio de sesión interactivo, y contraseñas que no se usen en ningún otro sitio.
• Trata el bloqueo de cuentas con cuidado. En un host expuesto permite que cualquiera deshabilite tus cuentas a voluntad; mantén un umbral moderado si lo usas, y nunca confíes en él como defensa contra la adivinación.

2. Exposición de red

La segunda pregunta después de «quién puede entrar» es «desde dónde». Cada puerto accesible desde internet es un servicio que alguien está probando ahora mismo.

• Inventaria qué escucha realmente, desde fuera. Get-NetTCPConnection -State Listen en el host, y después verifica desde otra red cuáles responden.
• Cierra SMB (445) en el perímetro. Prácticamente nunca debería mirar a internet, y es un segundo hallazgo frecuente en servidores pensados para exponer solo RDP.
• Lo mismo con WinRM (5985/5986), MS SQL (1433) y cualquier interfaz de administración. Si un servicio no necesita ser accesible desde internet, esa es toda la corrección.
• Para el propio RDP, restringe las direcciones de origen si puedes. Si no puedes, sigue leyendo: la sección 3 es la medida compensatoria.
• Activa Network Level Authentication para que un cliente no autenticado nunca obtenga una sesión creada para él.
• Comprueba también el grupo de seguridad de la nube, no solo el firewall de Windows. Dos capas son dos sitios donde equivocarse, y un grupo que lo permite todo delante de un firewall de host cuidadoso es un desajuste habitual.

3. Bloqueo automático de inicios de sesión fallidos

Esta es la sección que la mayoría de las checklists omite, y la que cambia la realidad diaria de operar un servidor expuesto.

Windows registra cada fallo de autenticación como evento 4625 e incluye un firewall perfectamente capaz, pero no trae nada que conecte ambos. A su aire, un servidor absorbe miles de intentos al día: CPU gastada, registro de auditoría revuelto, y ningún límite al tiempo que un atacante puede seguir probando.

Lo que necesitas es el equivalente de fail2ban: vigilar el flujo de fallos y, cuando un origen cruce un umbral, descartarlo en el firewall. Tres propiedades separan una implementación que aguanta de una que gotea — banear la subred en lugar de la dirección suelta, hacer los baneos permanentes y a prueba de reinicios, y poner tu propio acceso en la lista blanca antes de activar nada.

Puedes construirlo como una tarea programada de PowerShell, y para un único servidor que revisas a diario es una elección razonable. Reserva un día, y ten claro que su modo de fallo es el silencio: las tareas programadas dejan de ejecutarse tras reinicios y cambios de contraseña sin avisar a nadie. RDP Protector es la misma lógica como agente gestionado, con lista blanca, manejo de subredes, detección de puertos y una vista de estado.

4. Parches y superficie de ataque

Las credenciales son la vía de entrada habitual; los servicios sin parchear, la memorable.

• Activa las actualizaciones automáticas, o mantén un ciclo de parcheo que de verdad cumplas. RDP ha tenido ejecución remota de código previa a la autenticación y volverá a tenerla.
• Elimina roles y características que no uses. Una instalación de IIS que nadie recuerda haber activado es un servicio que encontrará otro.
• Desinstala el software que vino con la imagen y no hace falta. Cada agente, barra de herramientas y actualizador del fabricante es código ejecutándose con privilegios en tu host.
• Mantén al día el software de agente que sí ejecutas, incluidos monitorización y copias de seguridad.
• Desactiva protocolos heredados — SMBv1, TLS 1.0 y 1.1, NTLMv1 — salvo que algo los requiera de verdad, en cuyo caso anota qué y vuelve a revisarlo.

5. Registro y detección

No puedes investigar lo que no registraste, y la configuración por defecto registra menos de lo que crees y durante menos tiempo del que esperas.

• Confirma que la auditoría de inicio de sesión captura los fallos, no solo los aciertos: auditpol /get /subcategory:"Logon" debe mostrar ambos.
• Sube el tamaño máximo del registro de seguridad. El valor por defecto se llena en horas en un host expuesto, y los eventos que necesitas caducan antes de que mires.
• Reenvía los eventos fuera del host. El registro local de una máquina comprometida es evidencia que un atacante puede editar; una copia en otro sitio no lo es.
• Alerta sobre lo que importa y no sobre el volumen: un inicio de sesión correcto desde un país nuevo, un nuevo administrador local, un servicio instalado, el borrado del registro de auditoría (evento 1102).
• Revisa, de vez en cuando y a propósito, quién inició sesión con éxito. Los fallos son ruido; un éxito que no puedes explicar es todo el asunto.

6. Copias de seguridad que hayas restaurado de verdad

Esta sección va al final no porque importe menos, sino porque es la medida que da por supuesto que todas las demás fallaron — y ese día solo importa una propiedad de tus copias.

Guarda al menos una copia que el propio servidor no pueda alcanzar ni borrar. Los operadores de ransomware buscan el destino de las copias antes de cifrar nada, y un recurso compartido en el que el host comprometido pueda escribir no es una copia de seguridad, es una segunda copia esperando a ser destruida.

Y luego restaura una. Una copia que nunca se ha restaurado es una hipótesis. Pruébala con un calendario, anota cuánto tardó, y asegúrate de que más de una persona conoce el procedimiento.