Endurecer WinRM y la comunicación remota de PowerShell

WinRM es el transporte que hay debajo de la comunicación remota de PowerShell, winrs, el Administrador del servidor, Windows Admin Center, JEA y Windows Event Forwarding. También es uno de los canales de movimiento lateral más usados, porque una credencial de administrador válida más un puerto 5985 abierto equivale, por diseño, a ejecución remota de código. El pilar de seguridad de PowerShell enumera las tres opciones de línea base. Esta guía cubre el resto: qué está realmente a la escucha, cómo forzar una autenticación sólida, cómo añadir HTTPS y cómo limitar quién puede llegar a él.

Valores por defecto que conviene conocer

Los valores de autenticación seguros por defecto son buenos. El problema es la deriva: un instalador de un proveedor, una sesión de resolución de problemas o un script encontrado en Internet activa Basic, establece TrustedHosts en * o añade un agente de escucha en todas las interfaces. La directiva lo impide.

Paso 1: inventariar lo que está realmente configurado

En una muestra de servidores y puestos de trabajo, registre los agentes de escucha, la configuración de autenticación y los puntos de conexión:

winrm enumerate winrm/config/listener
Get-ChildItem WSMan:\localhost\Service\Auth
Get-ChildItem WSMan:\localhost\Client\Auth
Get-Item WSMan:\localhost\Service\AllowUnencrypted
Get-Item WSMan:\localhost\Client\TrustedHosts
Get-PSSessionConfiguration | Select-Object Name, Permission
Get-LocalGroupMember -Group 'Remote Management Users'

Busque agentes de escucha HTTP en puestos de trabajo que no los necesitan, agentes de escucha de compatibilidad en los puertos 80 o 443, un TrustedHosts no vacío, Basic o CredSSP en true y miembros inesperados de Remote Management Users. Cualquiera en ese grupo puede abrir una sesión remota de PowerShell en el equipo sin ser administrador.

Paso 2: imponer la autenticación y el cifrado por GPO

En Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM):

WinRM Service

WinRM Client

Los equivalentes en el registro están en HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service y ...\WinRM\Client (por ejemplo AllowBasic = 0, AllowUnencryptedTraffic = 0, DisableRunAs = 1). Las líneas base de seguridad de Microsoft y de CIS definen la mayoría de ellos; impóngalos donde las líneas base no lleguen.

CredSSP merece un comentario. Suele habilitarse para resolver el «doble salto» (una sesión remota que necesita llegar a un recurso compartido). Las mejores respuestas son la delegación restringida basada en recursos, un punto de conexión JEA que se ejecute como gMSA o pasar explícitamente un objeto de credencial al segundo comando. Cualquiera de ellas evita dejar una credencial completa en el servidor intermedio.

Paso 3: preferir Kerberos y plantearse solo Kerberos

Kerberos ofrece autenticación mutua: el cliente sabe que está hablando con el servidor real. NTLM, al que recurre Negotiate, no la ofrece y está expuesto a NTLM relay. Negotiate recurre a NTLM cuando se conecta por dirección IP, a un host fuera del dominio o a un nombre sin SPN.

Tres niveles, de menor a mayor rigor:

1. Conectarse por FQDN y dejar TrustedHosts vacío. Así los clientes usan Kerberos con los hosts del dominio y rechazan NTLM hacia servidores no autenticados sobre HTTP.
2. Restringir NTLM en todo el dominio con las directivas de auditoría y restricción de NTLM, para que el recurso a NTLM aparezca en los registros antes de bloquearlo.
3. Deshabilitar Negotiate en los servidores Tier 0. En la directiva WinRM Service, establezca Disallow Negotiate authentication = Enabled. Los clientes deberán conectarse entonces con -Authentication Kerberos.

Enter-PSSession -ComputerName dc01.corp.example -Authentication Kerberos

Pruebe con cuidado la opción 3. El Administrador del servidor, Windows Admin Center y muchos scripts usan Negotiate por defecto y fallarán hasta que se reconfiguren.

Paso 4: añadir agentes de escucha HTTPS donde se necesiten

HTTPS añade la autenticación del servidor basada en certificados y TLS. Lo necesita para los hosts fuera del dominio y los servidores de grupo de trabajo, entre bosques sin confianzas y en cualquier lugar donde la directiva exija TLS en la red. Emita un certificado desde su CA interna con el EKU Server Authentication y el FQDN del host en el sujeto o en el SAN, idealmente mediante inscripción automática. Después:

$fqdn = [System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).HostName
$cert = Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.Subject -eq "CN=$fqdn" -and $_.EnhancedKeyUsageList.FriendlyName -contains 'Server Authentication' } |
  Sort-Object NotAfter -Descending | Select-Object -First 1

New-Item -Path WSMan:\localhost\Listener -Transport HTTPS -Address * `
  -CertificateThumbPrint $cert.Thumbprint -Force

Los clientes se conectan con -UseSSL. No use certificados autofirmados con -SkipCACheck y -SkipCNCheck fuera de un laboratorio: eso tira por la borda la autenticación del servidor por la que añadió HTTPS.

El agente de escucha está vinculado a una huella digital y no sigue la renovación del certificado. Actualícelo desde su gestión de la configuración tras cada renovación:

Set-WSManInstance -ResourceURI winrm/config/Listener `
  -SelectorSet @{ Address = '*'; Transport = 'HTTPS' } `
  -ValueSet @{ CertificateThumbprint = $cert.Thumbprint }

Cuando todas las herramientas de gestión usen HTTPS, puede eliminar el agente de escucha HTTP en los servidores sensibles. Déjelo donde los recopiladores de Windows Event Forwarding u otras herramientas sigan dependiendo del puerto 5985.

Paso 5: acotar quién puede llegar a WinRM

El control de WinRM más eficaz no es una opción de WinRM. Es el firewall del host. Solo los servidores de salto, las estaciones de trabajo de acceso privilegiado y los servidores de gestión necesitan llegar a 5985/5986.

• En la GPO de firewall, sustituya la regla integrada Windows Remote Management (HTTP-In) por reglas cuya dirección remota sean sus subredes de gestión, tanto para 5985 como para 5986. Consulte endurecimiento del Firewall de Windows y gestionar la directiva de firewall a escala.
• En los puestos de trabajo, bloquee por completo la entrada de WinRM salvo que una herramienta concreta la necesite.
• No confíe para esto en Allow remote server management through WinRM. Su filtro IPv4/IPv6 controla a qué direcciones locales se vincula el agente de escucha, no qué clientes remotos pueden conectarse.

Restrinja también quién puede autenticarse una vez que llega. Mantenga Remote Management Users vacío o muy controlado, y recuerde que las cuentas de administrador local están sujetas a las restricciones remotas de UAC. Mantenga esas restricciones activadas como se describe en UAC y Administrator protection.

Permisos de los puntos de conexión

Cada punto de conexión de comunicación remota tiene su propio descriptor de seguridad. Get-PSSessionConfiguration los muestra. Los predeterminados (microsoft.powershell, microsoft.powershell32 y, donde esté instalado, PowerShell.7) permiten el acceso a Administrators y Remote Management Users. A veces los proveedores registran puntos de conexión adicionales con permisos más amplios, y los puntos de conexión JEA definen los suyos mediante las definiciones de rol. Revise la lista tras cada despliegue de software, elimine con Unregister-PSSessionConfiguration los puntos de conexión que nadie usa y trate la aparición de un punto de conexión nuevo en un servidor como un cambio de configuración que necesita un responsable. En los servidores sensibles en los que nadie debería usar la comunicación remota completa, puede restringir los puntos de conexión predeterminados a un grupo de administración Tier 0 dedicado con Set-PSSessionConfiguration -SecurityDescriptorSddl y publicar puntos de conexión JEA para todo lo demás.

Qué se rompe

• El Administrador del servidor y Windows Admin Center fallan contra los hosts en los que Negotiate está deshabilitado o solo hay HTTPS, hasta que se configuran para Kerberos o HTTPS.
• Los scripts que se conectan por dirección IP dejan de funcionar con un TrustedHosts vacío. Es intencionado; corríjalos para que usen nombres.
• Los flujos de doble salto que dependían de CredSSP se rompen. Llévelos a la delegación restringida o a un punto de conexión JEA respaldado por una gMSA.
• El reenvío de eventos se detiene si deshabilita el servicio WinRM en los orígenes o bloquea el 5985 en el firewall del recopilador. Consulte Windows Event Forwarding a escala.
• Los certificados caducados rompen los agentes de escucha HTTPS sin avisar. Supervise la caducidad de los certificados de los agentes de escucha.

Comprobarlo

# ¿Directiva aplicada?
Get-Item WSMan:\localhost\Service\AllowUnencrypted          # false
Get-ChildItem WSMan:\localhost\Service\Auth                  # Basic false, CredSSP false
Get-Item WSMan:\localhost\Client\TrustedHosts                # vacío

# Kerberos y HTTPS funcionan desde un equipo de gestión
Test-WSMan -ComputerName srv01.corp.example -UseSSL
Invoke-Command -ComputerName srv01.corp.example -UseSSL -ScriptBlock { hostname }

# Bloqueado desde un puesto de trabajo normal (debería agotar el tiempo de espera)
Test-NetConnection srv01.corp.example -Port 5985

Para la detección, las sesiones remotas aparecen como procesos wsmprovhost.exe en el destino (4688 o Sysmon 1), inicios de sesión de red (4624 tipo 3) y entradas en Microsoft-Windows-WinRM/Operational. Alerte sobre las sesiones WinRM hacia servidores que no se originen en sus subredes de gestión y sobre los cambios en la configuración de WinRM fuera de su proceso de cambios. La página temática de seguridad de PowerShell reúne las guías relacionadas, incluida JEA para restringir lo que pueden hacer esas sesiones.

Lista de comprobación

• Agentes de escucha, configuración de autenticación, TrustedHosts y permisos de los puntos de conexión inventariados
• Basic, tráfico sin cifrar, CredSSP y Digest deshabilitados por GPO (servicio y cliente)
• Almacenamiento de credenciales RunAs no permitido; agentes de escucha de compatibilidad desactivados
• TrustedHosts vacío; conexiones por FQDN con Kerberos
• Negotiate deshabilitado en los servidores Tier 0 tras las pruebas
• Agentes de escucha HTTPS con certificados emitidos por la CA donde se necesiten; huella digital actualizada en cada renovación
• Entrada en 5985/5986 permitida solo desde las subredes de gestión
• Pertenencia a Remote Management Users revisada
• Detecciones de sesiones WinRM y de cambios de configuración implantadas