Problema
Los entornos críticos requieren un punto de acceso controlado que permita a los administradores gestionar controladores de dominio, firewalls y otros dispositivos de infraestructura sin exponer credenciales ni abrir puertos innecesarios. Un jump server Tier 0 mal configurado se convierte en un puente fácil de explotar: RDP abierto a toda la red, software no auditado, y políticas de autenticación débiles. El desafío es crear una plantilla reproducible que combine defensa en profundidad con usabilidad para un pequeño equipo de administradores.
Causa
- Configuración por defecto – Windows Server 2022 habilita RDP, servicios de escritorio remoto y varios componentes de red que no se usan en un jump box.
- Ausencia de segmentación de credenciales – Cuentas con privilegios de dominio pueden iniciar sesión desde cualquier máquina, lo que permite “pass‑the‑hash” y extracción de tickets.
- Políticas de aplicación inconsistentes – Sin control de ejecución, los administradores pueden instalar navegadores o herramientas de terceros que eluden los controles de red.
- Firewalls redundantes o ausentes – Confiar solo en la lista de control de acceso (ACL) del perímetro deja la máquina sin defensa local contra errores de configuración o malware interno.
- Auditoría insuficiente – Los eventos críticos (login, elevación de privilegios, cambios de política) no se registran de forma estructurada, dificultando la correlación en SIEM.
Solución
1. Base de hardening: combinar Microsoft Security Baseline y CIS Benchmark
- Importar la GPO del Microsoft Security Baseline (MSB) como punto de partida.
- Superponer los controles críticos del CIS Benchmark 1.2.0 que no aparecen en MSB (p. ej., desactivación de SMBv1, restricciones de PowerShell remoting).
- Resolver conflictos mediante una tabla de prioridades:
- Seguridad de credenciales (Credential Guard, LSA Protection) > Configuraciones de auditoría > Optimización de rendimiento.
- Cuando ambos benchmarks exijan valores diferentes, elige el más restrictivo y documenta la excepción.
2. Estrategia de cuentas privilegiadas
| Acción | Detalle |
|---|---|
| LAPS | Implementar LAPS para todas las cuentas locales de administrador en el jump server. |
| Cuentas de Tier 0 | Crear cuentas de dominio dedicadas, miembro del grupo Tier 0 Admins; no pertenecer a Domain Admins ni a grupos de menor nivel. |
| Protected Users | Añadir las cuentas Tier 0 a Protected Users para forzar Kerberos AES‑256 y bloquear delegación no segura. |
| Break‑glass | Mantener una cuenta de emergencia en un almacén de contraseñas fuera de línea; habilitarla solo bajo proceso de aprobación documentado. |
3. Control de ejecución: WDAC vs AppLocker
- WDAC (Windows Defender Application Control) brinda firma de código y hash, ideal para entornos donde solo se necesita un conjunto estático de binarios (PowerShell, mstsc, Edge).
- AppLocker es más flexible para permitir scripts firmados y rutas específicas, útil cuando se necesita ejecutar herramientas de diagnóstico ocasionales.
Recomendación práctica:
- Desplegar una política WDAC “audit mode” para validar el catálogo de binarios.
- Una vez aprobado, cambiar a “enforce mode”.
- Complementar con una regla AppLocker que permita scripts firmados por el equipo de seguridad, evitando la necesidad de desactivar WDAC para cada script.
4. Hardening de RDP
- Network Level Authentication (NLA) – obligatorio.
- Restricted Admin Mode – habilitar en el cliente y servidor; evita que las credenciales del administrador se transmitan al host remoto.
- RD Gateway – colocar el jump server detrás de un gateway que requiera autenticación multifactor; reduce la exposición del puerto 3389 a la DMZ.
- Redirecciones – desactivar clipboard, drives, impresoras y dispositivos de audio mediante la GPO
Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Device and Resource Redirection. - Bloqueo de usuarios – política de bloqueo después de 3 intentos fallidos, con ventana de 15 min.
5. Firewall local vs ACL perimetral
Aunque la PA‑850 ya filtra tráfico entrante, el Windows Defender Firewall sigue siendo valioso:
- Defensa en profundidad: protege contra errores de ACL, malware que abre puertos internos o tráfico lateral desde otras máquinas comprometidas en la DMZ.
- Visibilidad: los logs del firewall aparecen en el mismo canal que los eventos de seguridad, simplificando la correlación.
Implementación mínima:
- Regla de entrada: permitir RDP solo desde rangos de IP de los administradores (lista estática).
- Regla de salida: bloquear todo excepto puertos necesarios para gestión (HTTPS 443 a los firewalls, LDAP 389/636 a los DCs, y los puertos de los dispositivos de red específicos).
6. Restricción de navegación web
- Proxy transparente con allow‑list – despliegue un proxy interno (p. ej., Squid) que solo permita FQDN aprobados (PA‑850 UI, portal VPN, etc.). Configurar los navegadores para usar el proxy mediante GPO.
- Política de Edge – habilitar
Allowlist URLsenComputer Configuration → Administrative Templates → Microsoft Edge → Content settings. - Bloqueo de ejecutables – la política WDAC evita que se instalen navegadores alternativos; cualquier intento de lanzar un binario fuera del catálogo será bloqueado.
7. Auditoría y registro
- Audit Policy: habilitar
Logon,Special Logon,Privilege Use,Process Creation,Process Termination,Object Access(solo para carpetas críticas). - PowerShell transcription:
Set-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging -Name EnableScriptBlockLogging -Value 1. - Defender Advanced Threat Protection (ATP): activar
Endpoint Detection and Responsey enviar eventos a SIEM. - Credential Guard & LSA Protection: confirmar con
Get-WindowsFeature -Name CredentialGuardyGet-ProcessMitigation -System.
8. Documentación y reconstrucción automática
- Imagen base: crear una VM de referencia con todos los ajustes, exportar a un VHDX y almacenarla en un repositorio de imágenes.
- Script de despliegue: usar PowerShell DSC o Ansible (Windows) para aplicar GPO, políticas WDAC y configuraciones de firewall en cada nuevo host.
- Procedimiento de recuperación: registrar pasos de restauración de LAPS, re‑aplicación de políticas y re‑activación de cuentas break‑glass.
Cuándo aplicar esta solución
- Entornos con controladores de dominio, firewalls o VPN concentrators críticos que solo deben ser gestionados desde máquinas designadas.
- Equipos de administración reducidos (≤ 10 admins) donde la gestión de credenciales es un punto de fallo.
- Auditorías regulatorias (CFA, ISO 27001, NIST) que exigen segmentación de privilegios y registro completo.
No aplicar si la infraestructura es pequeña y no hay requisitos de separación de niveles, ya que la complejidad añadida supera los beneficios.
Código
# Habilitar LAPS en el servidor
Import-Module AdmPwd.PS
Set-AdmPwdAuditing -AuditingEnabled $true
Set-AdmPwdComputerSelfPermission -Identity "JumpServer$" -AllowedPrincipals "Tier0Admins"
# Configurar firewall local (ejemplo de regla de salida)
netsh advfirewall firewall add rule name="Allow HTTPS to firewalls" dir=out protocol=TCP remoteport=443 remoteip=10.0.0.0/24 action=allow
netsh advfirewall firewall add rule name="Block all else" dir=out action=block
Verificación
- Conexión RDP – intentar acceso desde una IP no listada; debe fallar.
- WDAC – ejecutar un binario no firmado; el evento 3076 (AppLocker) debe aparecer en el visor de eventos.
- LAPS – comprobar que la contraseña del administrador local se almacena en AD (
Get-ADComputer -Identity JumpServer$ -Properties ms-Mcs-AdmPwdExpirationTime). - Proxy – abrir un sitio no permitido; la solicitud debe ser bloqueada y registrar 403 en el proxy.
- Auditoría – generar un intento de elevación de privilegio y verificar que el evento 4672 aparece en el SIEM.
Notas adicionales
- Sincronización de tiempo: todos los servidores deben usar la misma fuente NTP; de lo contrario, Kerberos fallará con políticas de silo.
- Actualizaciones: habilitar Windows Update for Business con “semi‑annual channel” y probar parches en una máquina de prueba antes de aplicar al jump server.
- Redundancia: replicar la imagen base y los scripts en cada sitio; use un balanceador de carga de nivel 4 para distribuir sesiones RDP entre los dos servidores por sitio.
- Break‑glass: documentar el proceso de activación en un documento cifrado y almacenar la clave de recuperación en una caja de seguridad física.
- Pruebas de penetración: programar pruebas internas cada 6 meses para validar que las capas de defensa (firewall, WDAC, silo) siguen efectivas después de cambios de infraestructura.