Firewall para DC: puertos, salida y acceso de administración

Un controlador de dominio tiene que ser accesible para todos los miembros del dominio. Por eso se suele dar por hecho que no se le puede aplicar un firewall. Sí se puede. Los clientes necesitan un conjunto conocido de puertos de autenticación y de directorio, pero no necesitan RDP, WinRM ni la administración remota de servicios. El propio DC casi nunca necesita iniciar una conexión hacia una estación de trabajo o hacia Internet. Si resuelve bien esas tres cosas, elimina de un plumazo el movimiento lateral hacia los DC, las rutas de relay por coerción y la salida de comando y control.

La línea base del DC enuncia el principio de control de salida. Esta guía lo convierte en una directiva desplegable. Cubre la matriz de puertos, cómo medir el tráfico real antes de bloquear, las reglas de host y de red, el acceso de administración solo desde Tier 0 y cómo verificar que nada se ha roto.

La matriz de puertos

Divida el tráfico de los DC en tres flujos. Cada flujo tiene orígenes y reglas distintos.

De clientes y servidores miembro a los DC (entrante):

De DC a DC (replicación, en ambos sentidos): todo lo anterior más los puertos RPC que usan DRSUAPI y DFSR. Permita todo el tráfico entre DC de las subredes de DC. No merece la pena diagnosticar una caída de la replicación provocada por una ACL demasiado ingeniosa.

Administración (solo Tier 0): 3389 (RDP), 5985/5986 (WinRM), 9389 (AD Web Services, que usan el módulo ActiveDirectory de PowerShell y ADAC), más RPC para los complementos de MMC. Este tráfico solo debe proceder de PAW o de hosts de salto de Tier 0.

NetBIOS heredado (UDP 137/138, TCP 139) solo es necesario si aún tiene clientes que dependen de NetBIOS. Retírelo junto con el trabajo sobre LLMNR y NBT-NS descrito en deshabilitar LLMNR, NetBIOS y WPAD.

Lo que se suele olvidar

• ICMP. El procesamiento de la directiva de grupo y algunas comprobaciones del localizador de DC usan el eco ICMP para detectar vínculos lentos. Permita la solicitud y respuesta de eco ICMP desde las subredes de clientes hacia los DC, en lugar de bloquearlas y tener que diagnosticar más tarde comportamientos extraños de los GPO.
• IPv6. Windows prefiere IPv6 cuando está disponible. Si sus reglas de red solo cubren IPv4, un DC con una dirección de vínculo local o SLAAC puede ser accesible por vías que su directiva nunca contempló. Escriba reglas para ambos protocolos o controle deliberadamente IPv6 en las subredes de DC.
• DC de solo lectura en sucursales o en el perímetro. Un RODC necesita los puertos de replicación hacia un DC grabable, pero solo en un sentido para la replicación entrante. Trate la subred del RODC como menos confiable que la subred principal de DC y no le permita llegar a los puertos de administración de los DC grabables.
• Otros bosques. Las confianzas necesitan Kerberos, LDAP, DNS, SMB y RPC entre los DC de ambos bosques. Limite esas reglas a las direcciones de los DC del socio, no a toda su red.

Opcional: fijar los servicios RPC a puertos concretos

Si su equipo de red insiste en reglas estrechas, puede fijar los servicios RPC más activos a puertos estáticos. Microsoft admite esta configuración, que requiere reiniciar el servicio afectado (en la práctica, reiniciar el DC):

$ntds     = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
$netlogon = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
Set-ItemProperty $ntds     -Name 'TCP/IP Port' -Value 50100 -Type DWord   # Replicación de AD / DRSUAPI
Set-ItemProperty $netlogon -Name 'DCTcpipPort' -Value 50101 -Type DWord   # Netlogon
dfsrdiag StaticRPC /port:50102 /Member:DC01.corp.example.com               # DFSR (SYSVOL)

Esto acota el tráfico de replicación, pero no elimina la necesidad del intervalo dinámico, porque otras interfaces RPC siguen usándolo. Considérelo opcional.

Medir: qué habla realmente con sus DC

No escriba un conjunto de reglas basándose solo en una tabla de puertos. Antes de bloquear nada, active el registro del firewall para las conexiones permitidas y descartadas en todos los DC. Debe configurarse por GPO en Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Windows Defender Firewall Properties > Domain Profile > Logging. El equivalente en PowerShell, útil para un DC piloto:

Set-NetFirewallProfile -Profile Domain,Private,Public `
    -LogAllowed True -LogBlocked True -LogMaxSizeKilobytes 32767 `
    -LogFileName '%systemroot%\system32\LogFiles\Firewall\pfirewall.log'

Recopile entre dos y cuatro semanas de registros, incluidos un cierre de mes y un ciclo de parches. Después, resuma por puerto de destino, subred de origen y sentido. Una forma rápida de ver las sesiones salientes activas que inicia un DC:

Get-NetTCPConnection -State Established |
    Where-Object { $_.RemoteAddress -notmatch '^(127\.|::1)' -and $_.LocalPort -gt 1023 } |
    Group-Object RemoteAddress, RemotePort | Sort-Object Count -Descending |
    Select-Object Count, Name -First 40

Es normal ver flujos salientes hacia otros DC, reenviadores DNS, su servidor WSUS o de parches, orígenes de hora, el SIEM o el recopilador de registros, servidores de copia de seguridad y ubicaciones CRL/AIA de la PKI. Todo lo demás necesita un responsable. Las sorpresas habituales son los agentes de supervisión y las herramientas de copia de seguridad que «llaman a casa», a la nube del fabricante.

Aplicar en la red

Implemente la directiva principal en el firewall de red o en la plataforma de segmentación situada delante de la subred de DC, para que los administradores locales del propio DC no puedan deshacerla:

# Inbound to DC subnet
ALLOW  client/server subnets -> DCs   53,88,123,135,389,445,464,636,3268,3269,49152-65535
ALLOW  DC subnets            -> DCs   any
ALLOW  Tier 0 PAW subnet     -> DCs   3389,5985,5986,9389 (+ above)
DENY   any                   -> DCs   3389,5985,5986,9389
DENY   any                   -> DCs   any   (log)

# Outbound from DC subnet
ALLOW  DCs -> DC subnets, DNS forwarders, WSUS, NTP, SIEM, backup, CRL/AIA
DENY   DCs -> workstation and user-server subnets  445, 80, 443   (log)
DENY   DCs -> internet                            any            (log)

La denegación saliente hacia las subredes de estaciones de trabajo en los puertos 445 y 80/443 es lo que elimina la mayor parte del valor de la coerción de autenticación. Un DC que no puede abrir SMB ni HTTP hacia el host del atacante no puede ser retransmitido desde ahí. Si se necesita un proxy para las actualizaciones, publique a través de él únicamente los puntos de conexión de actualización de Microsoft, nunca la navegación general.

Aplicar en el host

El firewall del host es su segunda capa y la única para el tráfico dentro de la misma subred. Configúrelo en un GPO vinculado únicamente a la OU Domain Controllers, en Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security:

• Firewall state: On para todos los perfiles. Inbound connections: Block (default). Outbound connections: Allow (default) hasta que haya mapeado la salida lo suficiente como para cambiarlo.
• En Customize de cada perfil: Apply local firewall rules: No y Apply local connection security rules: No, para que ni los cambios locales ni los instaladores puedan añadir excepciones.
• Como las reglas locales ya no se combinan, las reglas que el rol AD DS habilitó localmente dejan de contar. Añada los grupos de reglas predefinidos al propio GPO (New Inbound Rule > Predefined): Active Directory Domain Services (que incluye también la regla NTP de W32Time), DNS Service, DFS Replication, Kerberos Key Distribution Center, Netlogon Service y Core Networking. Pruébelo primero en un solo DC.
• No añada los grupos predefinidos Remote Desktop ni Windows Remote Management, que permiten cualquier dirección remota. Cree reglas acotadas en su lugar.

# Reglas de administración acotadas escritas directamente en el GPO de firewall de los DC
$gpo = 'corp.example.com\DC - Firewall'
New-NetFirewallRule -PolicyStore $gpo -DisplayName 'T0 - RDP from PAW' -Direction Inbound `
    -Protocol TCP -LocalPort 3389 -RemoteAddress 10.10.50.0/24 -Action Allow -Profile Domain
New-NetFirewallRule -PolicyStore $gpo -DisplayName 'T0 - WinRM from PAW' -Direction Inbound `
    -Protocol TCP -LocalPort 5985,5986 -RemoteAddress 10.10.50.0/24 -Action Allow -Profile Domain
New-NetFirewallRule -PolicyStore $gpo -DisplayName 'T0 - ADWS from PAW' -Direction Inbound `
    -Protocol TCP -LocalPort 9389 -RemoteAddress 10.10.50.0/24 -Action Allow -Profile Domain

Recuerde que el Firewall de Windows procesa las reglas de bloqueo antes que las de permiso. Si quiere «denegar RDP desde cualquier sitio salvo la subred de PAW», acote la regla de permiso y elimine los permisos amplios. No añada un bloqueo amplio, porque también anularía su permiso acotado. Combine las reglas de red con las restricciones de asignación de derechos de usuario de la línea base y con el modelo de estación de trabajo de acceso privilegiado, para que la subred de PAW contenga realmente solo PAW.

Verificar

Haga pruebas desde tres lugares: una estación de trabajo estándar, una PAW y otro DC.

# Desde una estación de trabajo estándar: se espera True en los puertos de autenticación y False en los de administración
'DC01' | ForEach-Object {
    foreach ($p in 53,88,389,445,636,3268,3389,5985,9389) {
        [PSCustomObject]@{ Port = $p; Open = (Test-NetConnection $_ -Port $p -WarningAction SilentlyContinue).TcpTestSucceeded }
    }
}

# Desde un DC: confirmar que no hay salida a Internet
Test-NetConnection www.example.org -Port 443

# Estado de la replicación y del localizador tras cualquier cambio
repadmin /replsummary
dcdiag /test:replications /test:netlogons /test:advertising /e /q
nltest /dsgetdc:corp.example.com

En cada DC, confirme la directiva efectiva con Get-NetFirewallProfile -PolicyStore ActiveStore y compruebe que no se están combinando reglas locales. Revise pfirewall.log y los registros de denegación del firewall de red cada semana durante el primer mes. Todo flujo legítimo denegado es o una regla que se le pasó o un agente que no debería estar hablando con un DC.

Qué se rompe

• Herramientas de administración remota en estaciones de trabajo corrientes. Las consolas RSAT, el módulo ActiveDirectory de PowerShell (ADWS en el 9389), Enter-PSSession y el RDP desde los equipos del soporte técnico dejan de funcionar contra los DC. Ese es el objetivo. Traslade ese trabajo a PAW o delegue en herramientas que no necesiten acceso de nivel DC.
• Agentes que llaman a casa. Los agentes de supervisión, EDR y copia de seguridad que se conectan directamente a la nube del fabricante desde el DC fallan al cerrar la salida a Internet. Enrútelos a través de un proxy aprobado o de un relé en la zona de administración de Tier 0.
• Conexiones iniciadas por el DC hacia los miembros. Dejan de funcionar el gpupdate /force remoto desde un DC, los scripts que envían archivos desde un DC a los servidores y algunos modelos heredados de distribución de software. Nada de eso debería ejecutarse desde un DC.
• La replicación, si se acota en exceso. Fijar los puertos RPC y luego olvidarse de un DC o de un nuevo vínculo de sitio es la clásica interrupción autoinfligida. Mantenga completamente abierto el tráfico entre DC de las subredes de DC.
• Los clientes NetBIOS heredados que dependían de 137-139 pierden la exploración de red y la resolución de nombres.

Lecturas relacionadas: la línea base del DC, definir el Tier 0 para decidir qué hosts de administración pertenecen a la subred de PAW, y aplicación de la firma SMB para el tráfico que sigue permitiendo.