Hardening de controladores de dominio: la base del DC
Lista práctica para bastionar controladores de dominio: líneas base de seguridad, Print Spooler, derechos de inicio de sesión, RDP, salida a Internet y parches.
Los controladores de dominio son el objetivo de mayor valor en la mayoría de los entornos Windows: si un atacante compromete uno, en la práctica se adueña del dominio. Aun así, los DC se tratan a menudo como servidores miembro corrientes: con roles predeterminados habilitados, accesibles por RDP para medio departamento de soporte y con permiso para navegar por Internet «por comodidad». Esta guía recorre los pasos de configuración concretos que reducen la superficie de ataque de un DC a lo que realmente necesita: autenticación, replicación y DNS.
Todo lo que sigue se suma a su ciclo de parches actual; no lo sustituye. Considérelo el mínimo exigible para cualquier DC, tanto si administra dos como doscientos.
Aplicar la línea base de seguridad de Microsoft
Parta de la línea base publicada por Microsoft en el Security Compliance Toolkit para el rol de controlador de dominio, en lugar de inventar su propia directiva desde cero. Los GPO de la línea base recogen las recomendaciones actuales de Microsoft sobre directiva de auditoría, asignación de derechos de usuario y opciones de seguridad, y se versionan para cada versión de Windows Server.
- Descargue de Microsoft el Security Compliance Toolkit (SCT) actual y la línea base de seguridad de Windows Server correspondiente a la versión del sistema operativo de sus DC.
- Importe los GPO de la línea base en su dominio (vinculados primero a una OU de pruebas) con el script
Baseline-ADImport.ps1del paquete o con el asistente Import Settings de la Consola de administración de directivas de grupo (GPMC).LGPO.exesolo aplica la configuración a la directiva local de un único equipo de prueba. - Compare la línea base con los GPO actuales de sus DC mediante
Get-GPOReport -ReportType Htmlantes del despliegue, para saber exactamente qué va a cambiar. - Vincule el GPO de la línea base a una OU que contenga únicamente controladores de dominio (normalmente la OU integrada Domain Controllers), nunca a la raíz del dominio.
# Exportar los GPO vinculados a los DC para compararlos antes de importar la línea base
Get-GPO -All | Where-Object { (Get-GPInheritance -Target "OU=Domain Controllers,DC=corp,DC=example,DC=com").GpoLinks.DisplayName -contains $_.DisplayName } |
ForEach-Object { Get-GPOReport -Guid $_.Id -ReportType Html -Path "C:\GPOBackup\$($_.DisplayName).html" }Vuelva a importar la línea base cada vez que Microsoft publique una actualización; trátelo como gestión de parches, no como un proyecto puntual.
Deshabilitar el servicio Print Spooler en los DC
El servicio Print Spooler ha sido la puerta de entrada de varias vulnerabilidades críticas, sobre todo PrintNightmare (CVE-2021-34527), además de una larga lista de problemas de instalación de controladores point-and-print y de abusos de coerción (coerción RPC basada en el spooler que alimenta ataques de NTLM relay). Ninguna de estas funciones es necesaria en un controlador de dominio.
# Deshabilitar y detener Print Spooler en todos los DC
Get-ADDomainController -Filter * | ForEach-Object {
Invoke-Command -ComputerName $_.HostName -ScriptBlock {
Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled
}
}Aplíquelo de forma centralizada mediante GPO para que persista tras reinicios y reaprovisionamientos:
- Computer Configuration → Policies → Windows Settings → Security Settings → System Services → Print Spooler → establecer en Disabled.
Verificación:
Get-ADDomainController -Filter * | ForEach-Object {
Get-Service -ComputerName $_.HostName -Name Spooler | Select-Object MachineName, Status, StartType
}Si una aplicación heredada necesita de verdad servicios de impresión en un servidor, esa es tarea de un servidor de impresión dedicado que no sea DC, nunca de un controlador de dominio.
Restringir el inicio de sesión local y por RDP solo a Tier 0
Toda cuenta que pueda iniciar sesión de forma interactiva o por RDP en un DC es, a efectos prácticos, un Domain Admin. Aplique la siguiente asignación de derechos de usuario mediante un GPO vinculado a la OU Domain Controllers y rellénela con un grupo dedicado de administradores de Tier 0, en lugar de grupos amplios como Domain Admins o Server Admins.
| Derecho | Ruta del GPO | Pertenencia recomendada |
|---|---|---|
| Allow log on locally | Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment | Solo administradores de Tier 0 |
| Allow log on through Remote Desktop Services | (misma ruta) | Solo administradores de Tier 0 (grupo pequeño y nominativo) |
| Deny log on through Remote Desktop Services | (misma ruta) | Todos los grupos de administración que no sean de Tier 0 (no Domain Users: los administradores de Tier 0 también son miembros y la denegación prevalece sobre la concesión) |
| Deny access to this computer from the network | (misma ruta) | Cuentas locales y grupos de administración de Tier 1/Tier 2 (nunca Domain Users: todos los usuarios y equipos necesitan inicio de sesión de red en los DC para SYSVOL y la directiva de grupo) |
# Verificar la pertenencia actual a Allow log on through RDS en un DC
$dc = "DC01"
secedit /export /cfg C:\Temp\dc01-secpol.cfg /areas USER_RIGHTS
Select-String -Path C:\Temp\dc01-secpol.cfg -Pattern "SeRemoteInteractiveLogonRight"Combínelo con el modelo de Tier 0 y acceso privilegiado: los administradores de Tier 0 deben conectarse desde estaciones de trabajo de acceso privilegiado (PAW), no desde su portátil de uso diario, y el acceso RDP permanente debe sustituirse, siempre que sea posible, por elevación just-in-time.
Bloquear el acceso saliente a Internet desde los controladores de dominio
Un DC no tiene ningún motivo legítimo para navegar por hosts arbitrarios de Internet. El acceso saliente es un canal habitual tras un compromiso para las conexiones de comando y control y la preparación de datos. Restrinja la salida de los DC en el firewall de red a lo estrictamente necesario para la operación:
- Windows Update / WSUS o un punto de conexión de gestión de parches
- Orígenes de sincronización NTP/hora (si no se usa una jerarquía de hora interna)
- Puntos de conexión de revocación de certificados/OCSP si están alojados públicamente
- Cualquier punto de conexión de sincronización de directorio necesario (p. ej., Entra Connect, si no está en el mismo equipo)
# Example firewall intent (implement in your perimeter/NGFW, not just Windows Firewall)
DENY DC-subnet -> ANY (0.0.0.0/0) port 80,443 [default deny]
ALLOW DC-subnet -> WSUS-server port 8530,8531
ALLOW DC-subnet -> approved-NTP port 123No confíe únicamente en el Firewall de Windows Defender para esto: aplíquelo en la capa de red para que un cambio de directiva local en el DC no pueda reabrir la salida sin que nadie lo note.
Prioridades de parcheo: ZeroLogon, PetitPotam/coerción, PrintNightmare
Tres clases de vulnerabilidades merecen prioridad permanente en su ciclo de parches, porque cada una puede llevar directamente al compromiso del dominio:
ZeroLogon (CVE-2020-1472): explota un fallo del canal seguro de Netlogon para restablecer la contraseña de la cuenta de equipo de un DC. Aplique el parche completo (la actualización inicial de 2020 más la fase de aplicación que exige que todos los clientes Netlogon usen RPC seguro) y confirme el modo de aplicación:
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "FullSecureChannelProtection" -ErrorAction SilentlyContinueConsulte ZeroLogon para conocer los detalles de la vulnerabilidad.
PetitPotam y otras técnicas de coerción: abusan de interfaces RPC/DCOM para forzar a un DC a autenticarse contra un punto de conexión controlado por el atacante, normalmente para alimentar un ataque de NTLM relay contra AD CS o LDAP. Mitigaciones:
- Habilitar Extended Protection for Authentication (EPA) en los puntos de conexión de inscripción web de AD CS y en LDAP.
- Deshabilitar NTLM donde sea viable o, como mínimo, exigir la firma LDAP/LDAPS y el enlace de canal (channel binding).
- Desplegar filtros RPC para bloquear, donde no sean necesarias, las llamadas no autenticadas a interfaces de tipo
EFSRPC/MS-RPRNdesde hosts que no sean DC.
PrintNightmare: cubierto más arriba mediante la deshabilitación del Spooler; aplique el parche de todos modos, ya que algunos CVE derivados de controladores de impresión afectan también a rutas de código ajenas al spooler.
Gestione estas tres familias de CVE como elementos de «parche en las 72 horas siguientes a su publicación» dentro del SLA de gestión de vulnerabilidades, al margen del ciclo habitual del Patch Tuesday.
Proteger la sincronización horaria (w32time)
Kerberos depende de que la hora esté sincronizada con un desfase máximo de 5 minutos de forma predeterminada; un atacante capaz de manipular el reloj de un DC puede interrumpir la autenticación o crear condiciones para la reutilización de tickets. Asegúrese de que el emulador de PDC se sincroniza con un origen de hora externo de confianza y de que el resto de DC se sincronizan con la jerarquía del dominio; nunca permita que los DC se sincronicen por su cuenta con servidores NTP arbitrarios de Internet.
# En el emulador de PDC
w32tm /config /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
# Verificar
w32tm /query /status
w32tm /query /sourceDeshabilitar roles y características innecesarios
Audite cada DC con Get-WindowsFeature y elimine todo lo que vaya más allá de AD DS, DNS y las herramientas de administración necesarias. Los culpables habituales: IIS olvidado de una antigua instalación de CA, el cliente Telnet, SMB1 y roles de uso compartido de archivos sin uso.
Get-WindowsFeature | Where-Object Installed -eq $true | Select-Object Name, InstallState
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestartResumen de verificación
# Comprobación rápida del estado de hardening de los DC
Get-ADDomainController -Filter * | ForEach-Object {
$dc = $_.HostName
[PSCustomObject]@{
DC = $dc
SpoolerRunning = (Get-Service -ComputerName $dc -Name Spooler).Status
SMB1Enabled = (Get-SmbServerConfiguration -CimSession $dc).EnableSMB1Protocol
TimeSource = (w32tm /query /source /computer:$dc)
}
}Qué se rompe
- Herramientas de administración que se conectan por RDP directamente a los DC. Algunos agentes de copia de seguridad, supervisión o parcheo dan por hecho el RDP interactivo o el inicio de sesión local sin restricciones. Rediríjalos a cuentas de servicio con derechos delegados explícitamente o migre a una administración basada en agentes que no requiera derechos de inicio de sesión interactivo.
- Herramientas heredadas dependientes de la impresión que usaban (indebidamente) un DC como servidor de impresión de respaldo.
- Agentes de supervisión de terceros que se comunican directamente con Internet desde el DC; deben enrutarse a través de un proxy aprobado o sacarse del equipo.
- Integraciones cercanas al NTLM relay que dependían de LDAP sin firmar o de una inscripción de AD CS que no admite EPA; deben actualizarse para soportar la firma y el enlace de canal antes de aplicarlos en todo el dominio.
Combine este hardening con las prácticas de hardening de Kerberos y de seguridad de objetos y ACL: un sistema operativo de DC bastionado es solo la mitad del trabajo si las ACL del directorio y la configuración de Kerberos siguen siendo permisivas.
Preguntas frecuentes
¿Se debe deshabilitar el servicio Print Spooler en todos los controladores de dominio?
Sí, salvo que un DC actúe realmente como servidor de impresión, algo que nunca debería ocurrir. Deshabilitar el servicio Spooler elimina por completo la superficie de ataque de PrintNightmare (CVE-2021-34527) y de la instalación de controladores point-and-print, y es una recomendación estándar de Microsoft y del CIS para los DC.
¿Pueden los administradores seguir conectándose por RDP a los controladores de dominio tras este hardening?
Solo las cuentas a las que se conceda explícitamente el derecho Allow log on through Remote Desktop Services, que debe limitarse a un grupo reducido de administradores de Tier 0. El resto debe administrar los DC mediante Windows Admin Center, comunicación remota de PowerShell desde una estación de trabajo de acceso privilegiado (PAW) o puntos de conexión Just Enough Administration, en lugar de RDP interactivo.
¿Por qué hay que bloquear el acceso saliente a Internet desde los controladores de dominio?
Los DC contienen el material de credenciales del dominio y no tienen ninguna necesidad legítima de navegar por la web ni de alcanzar hosts arbitrarios de Internet. Bloquear el acceso saliente (salvo los puntos de conexión necesarios de actualizaciones de Microsoft o de hora) cierra una vía habitual de comando y control y de exfiltración de datos una vez comprometido un DC.
Hardening de controladores de dominio: la base del DC