Consideraciones sobre la seguridad de comunicación remota de PowerShell mediante WinRM

  • Artículo

La comunicación remota de PowerShell es la forma recomendada para administrar los sistemas de Windows. La comunicación remota de PowerShell está habilitada de forma predeterminada en Windows Server 2012 R2 y versiones posteriores. En este documento se tratan cuestiones de seguridad, recomendaciones y procedimientos recomendados para el uso de la comunicación remota de PowerShell.

¿Qué es la comunicación remota de PowerShell?

La comunicación remota de PowerShell usa la Administración remota de Windows (WinRM) para permitir que los usuarios ejecuten comandos de PowerShell en equipos remotos. WinRM es la implementación de Microsoft del protocolo de Servicios web para la gestión (WS-Management). Puede encontrar más información acerca del uso de la comunicación remota de PowerShell en Ejecutar comandos remotos.

La comunicación remota de PowerShell no es lo mismo que usar el parámetro ComputerName de un cmdlet para ejecutarlo en un equipo remoto, que usa la llamada a procedimiento remoto (RPC) como protocolo subyacente.

Configuración predeterminada de la comunicación remota de PowerShell

La comunicación remota de PowerShell (y WinRM) escucha los puertos siguientes:

  • HTTP: 5985
  • HTTPS: 5986

De manera predeterminada, la comunicación remota de PowerShell solo permite conexiones de los miembros del grupo Administradores. Las sesiones se inician en el contexto del usuario, por lo que todos los controles de acceso del sistema operativo que se aplican a usuarios individuales y grupos continuarán aplicándose a estos mientras estén conectados a través de la comunicación remota de PowerShell.

En redes privadas, la regla de Firewall de Windows predeterminada para la comunicación remota de PowerShell acepta todas las conexiones. En redes públicas, la regla predeterminada del Firewall de Windows permite las conexiones de comunicación remota de PowerShell únicamente desde dentro de la misma subred. Tendrá que cambiar explícitamente esa regla para abrir la comunicación remota de PowerShell a todas las conexiones de una red pública.

Advertencia

La regla de firewall para redes públicas está diseñada para proteger el equipo frente a los intentos de conexión externa potencialmente malintencionados. Tenga precaución al quitar esta regla.

Aislamiento de procesos

La comunicación remota de PowerShell usa WinRM para la comunicación entre equipos. WinRM se ejecuta como servicio en la cuenta servicio de red y genera procesos aislados que se ejecutan como cuentas de usuario para las instancias de host de PowerShell. Una instancia de PowerShell que se ejecuta como un usuario no tiene acceso a un proceso que ejecuta una instancia de PowerShell como otro usuario.

Registros de eventos generados por la comunicación remota de PowerShell

FireEye ha proporcionado un buen resumen de los registros de eventos y otras pruebas de seguridad generados por las sesiones de comunicación remota de PowerShell, disponible en Investigating PowerShell Attacks (Investigación de los ataques de PowerShell).

Protocolos de transporte y cifrado

Resulta útil tener en cuenta la seguridad de una conexión de comunicación remota de PowerShell desde dos perspectivas: autenticación inicial y comunicación continua.

Independientemente del protocolo de transporte utilizado (HTTP o HTTPS), WinRM siempre cifra toda la comunicación remota de PowerShell después de la autenticación inicial.

Autenticación inicial

La autenticación confirma la identidad del cliente al servidor, e idealmente, del servidor al cliente.

Cuando un cliente se conecta a un servidor de dominio mediante su nombre de equipo, el protocolo de autenticación predeterminado es Kerberos. Kerberos garantiza la identidad del usuario y del servidor sin enviar ningún tipo de credencial reutilizable.

Cuando un cliente se conecta a un servidor de dominio mediante su dirección IP, o se conecta a un servidor de grupo de trabajo, no es posible la autenticación de Kerberos. En ese caso, la comunicación remota de PowerShell se basa en el protocolo de autenticación NTLM. El protocolo de autenticación NTLM garantiza la identidad del usuario sin enviar ningún tipo de credenciales delegables. Para demostrar la identidad del usuario, el protocolo NTLM requiere que tanto el cliente como el servidor procesen una clave de sesión de la contraseña del usuario sin intercambiar la propia contraseña. El servidor normalmente no conoce la contraseña del usuario, por lo que se comunica con el controlador de dominio que conoce la contraseña del usuario y calcula la clave de sesión del servidor.

Sin embargo, el protocolo NTLM no garantiza la identidad del servidor. De la misma forma que con todos los protocolos que usan NTLM para la autenticación, un atacante con acceso a una cuenta de equipo unido a un dominio podría invocar el controlador de dominio para procesar una clave de sesión NTLM y, por tanto, suplantar el servidor.

La autenticación basada en NTLM está deshabilitada de forma predeterminada, pero puede permitirse al configurar SSL en el servidor de destino o el valor WinRM TrustedHosts del cliente.

Uso de certificados SSL para validar la identidad del servidor durante las conexiones basadas en NTLM

Puesto que el protocolo de autenticación NTLM no puede asegurar la identidad del servidor de destino (solo que ya conoce su contraseña), puede configurar los servidores de destino para usar SSL para la comunicación remota de PowerShell. La asignación de un certificado SSL al servidor de destino (si lo emite una entidad emisora de certificados en la que el cliente también confía) habilita la autenticación basada en NTLM que garantiza la identidad del usuario y del servidor.

Omisión de errores de identidad de servidor basados en NTLM

Si no es factible implementar un certificado SSL en un servidor para las conexiones de NTLM, puede suprimir los errores de identidad resultantes mediante la adición del servidor a la lista WinRM TrustedHosts. Tenga en cuenta que la adición de un nombre de servidor a la lista TrustedHosts no se debe considerar como ninguna forma de instrucción de la confiabilidad de los mismos hosts, ya que el protocolo de autenticación NTLM no puede garantizar que, en realidad, se está conectando al host al que pretende conectarse. En su lugar, debe considerar que el valor de TrustedHosts sea la lista de hosts de la que quiere suprimir el error generado por la imposibilidad de comprobar la identidad del servidor.

Comunicación continua

Una vez completada la autenticación inicial, WinRM cifra la comunicación en curso. Al conectarse a través de HTTPS, el protocolo TLS se usa para negociar el cifrado que se usa para transportar los datos. Al conectarse a través de HTTP, el cifrado de nivel de mensaje viene determinado por el protocolo de autenticación inicial utilizado.

  • La autenticación básica no proporciona cifrado.
  • La autenticación NTLM usa un cifrado RC4 con una clave de 128 bits.
  • El cifrado de autenticación de Kerberos viene determinado por el etype del vale TGS. Es AES-256 en los sistemas modernos.
  • El cifrado CredSSP utiliza el conjunto de cifrado TLS que se negoció en el protocolo de enlace.

Creación del segundo salto

De forma predeterminada, la comunicación remota de PowerShell usa Kerberos (si está disponible) o NTLM para la autenticación. Ambos protocolos se autentican en el equipo remoto sin enviarle credenciales. Este es el modo más seguro de autenticación, pero dado que el equipo remoto no tiene las credenciales de usuario, no puede acceder a otros equipos o servicios en nombre del usuario. Esto se conoce como el "problema del segundo salto".

Hay varias formas de evitar este problema. Para obtener descripciones de estos métodos y las ventajas e inconvenientes de cada uno, consulte Realizar el segundo salto en la comunicación remota de PowerShell.

Referencias