Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La comunicación remota de PowerShell es la manera recomendada de administrar sistemas 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 los problemas de seguridad, las recomendaciones y los procedimientos recomendados al usar la comunicación remota de PowerShell.
¿Qué es PowerShell Remoting?
La comunicación remota de PowerShell usa administración remota de Windows (WinRM) para permitir a los usuarios ejecutar comandos de PowerShell en equipos remotos. WinRM es la implementación de Microsoft del protocolo Servicios web para administración (WS-Management). Puede encontrar más información sobre el uso de la comunicación remota de PowerShell en Ejecución de comandos remotos.
La comunicación remota de PowerShell no es la misma que el uso del parámetro ComputerName de un cmdlet para ejecutarlo en un equipo remoto, que usa la llamada a procedimiento remoto (RPC) como su protocolo subyacente.
Configuración predeterminada de comunicación remota de PowerShell
La característica PowerShell Remoting de WinRM escucha en los puertos siguientes:
- HTTP: 5985
- HTTPS: 5986
De forma predeterminada, la comunicación remota de PowerShell solo permite conexiones de miembros del grupo Administradores. Las sesiones se inician en el contexto del usuario, por lo que todos los controles de acceso del sistema operativo aplicados a usuarios y grupos individuales siguen aplicándolos mientras están conectados a través de la comunicación remota de PowerShell.
En las redes privadas, la regla predeterminada de Firewall de Windows 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. Tiene que cambiar explícitamente esa regla para permitir PowerShell Remoting en todas las conexiones de una red pública.
Advertencia
La regla de firewall para redes públicas está pensada para proteger el equipo frente a intentos de conexión externa potencialmente malintencionados. Tenga cuidado al quitar esta regla. Para obtener más información sobre cómo configurar WinRM, consulte Instalación y configuración de administración remota de Windows.
Aislamiento de procesos
La comunicación remota de PowerShell usa WinRM para la comunicación entre equipos. WinRM se ejecuta como un servicio en la cuenta de servicio de red y genera procesos aislados que se ejecutan como cuentas de usuario para hospedar instancias 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 ejecución remota de PowerShell
Los investigadores de Mandiant presentaron una sesión en la conferencia BlackHat que proporciona un buen resumen de los registros de eventos y otras pruebas de seguridad generadas por sesiones de comunicación remota de PowerShell. Para obtener más información, consulte Investigación de ataques de PowerShell.
Protocolos de cifrado y transporte
Resulta útil tener en cuenta la seguridad de una conexión remota de PowerShell desde dos perspectivas: la autenticación inicial y la comunicación continua.
Independientemente del protocolo de transporte usado (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 ante el servidor - e idealmente - la del servidor ante el 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 tanto la identidad de usuario como la identidad del servidor sin enviar ninguna clase de credenciales reutilizables.
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, la autenticación Kerberos no es posible. 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 ninguna clase de credenciales delegables. Para demostrar la identidad del usuario, el protocolo NTLM requiere que tanto el cliente como el servidor calculen una clave de sesión desde la contraseña del usuario sin intercambiar la propia contraseña. Normalmente, el servidor 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. Al igual que con todos los protocolos que usan NTLM para la autenticación, un atacante con acceso a una cuenta de máquina unida a un dominio podría invocar al controlador de dominio para calcular una clave de sesión NTLM y suplantar el servidor.
La autenticación basada en NTLM está deshabilitada de forma predeterminada. Puede habilitar NTLM mediante la configuración de SSL en el servidor de destino o mediante la configuración de WinRM TrustedHosts en el cliente.
Uso de certificados SSL para validar la identidad del servidor durante las conexiones basadas en NTLM
Dado que el protocolo de autenticación NTLM no puede garantizar la identidad del servidor de destino (solo que ya conoce la contraseña), puede configurar los servidores de destino para que usen SSL para la comunicación remota de PowerShell. La asignación de un certificado SSL al servidor de destino (si lo emite una entidad de certificación en la que también confía el cliente) habilita la autenticación basada en NTLM que garantiza la identidad del usuario y la identidad del servidor.
Omitir errores de identidad de servidor basados en NTLM
Si la implementación de un certificado SSL en un servidor para las conexiones NTLM es inviable, puede suprimir los errores de identidad resultantes agregando el servidor a la lista TrustedHosts de WinRM. Agregar un nombre de servidor a la lista de TrustedHosts no debe considerarse como una declaración acerca de la confiabilidad de los hosts en sí mismos, ya que el protocolo de autenticación NTLM no puede garantizar que realmente se conecta al host al que pretende conectarse. En su lugar, debe considerar que la configuración de TrustedHosts es la lista de hosts para los que desea evitar el error generado al no poder verificar 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, WinRM usa el protocolo TLS para negociar el cifrado usado para transportar datos. Al conectarse a través de HTTP, WinRM usa el cifrado de nivel de mensaje negociado por el protocolo de autenticación inicial.
- La autenticación básica no proporciona cifrado.
- La autenticación NTLM usa un cifrado RC4 con una clave de 128 bits.
- El
etypedel ticket TGS determina el cifrado de la autenticación Kerberos. Los sistemas modernos usan el algoritmo AES-256. - El cifrado CredSSP utiliza la suite de cifrado TLS negociada en el handshake.
Realizació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 la máquina remota sin enviar credenciales a él. Esta es la forma más segura de autenticarse, pero dado que la máquina remota no tiene las credenciales del usuario, no puede acceder a otros equipos y servicios en nombre del usuario. Esto se conoce como el problema del segundo salto.
Hay varias maneras de evitar este problema. Para obtener descripciones de estos métodos y las ventajas y desventajas de cada uno, consulte Realización del segundo salto en comunicación remota de PowerShell.
Referencias
Colaborar con nosotros en GitHub
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
