Seguridad de una sesión remota restringida de PowerShell

Hay escenarios en los que desea hospedar una sesión de PowerShell que, por motivos de seguridad, se ha limitado a un subconjunto de comandos de PowerShell.

Por definición, una sesión restringida es aquella en la que no se permite usar Import-Module. Puede haber otras limitaciones, pero este es el requisito principal. Si el usuario puede importar un módulo, puede ejecutar todo lo que desee.

Entre los ejemplos de sesiones restringidas se incluyen:

• Just-Enough-Administration (JEA)
• Implementaciones de comunicación remota restringida personalizadas, como los módulos de Exchange y Teams

Para la mayoría de los administradores del sistema, JEA proporciona la mejor experiencia para crear sesiones restringidas y debe ser su primera opción. Para obtener más información sobre JEA, consulte la información general de JEA.

Recomendaciones para implementaciones de sesión personalizadas

Si el escenario requiere una implementación personalizada, debe seguir estas recomendaciones.

Limitar el uso y las funcionalidades de los proveedores de PowerShell

Revise cómo se usan los proveedores permitidos para asegurarse de que no cree vulnerabilidades en la implementación de sesión restringida.

Advertencia

No permite al proveedor FileSystem. Si los usuarios pueden escribir en cualquier parte del sistema de archivos, es posible omitir completamente la seguridad.

No permita el proveedor de certificados . Con el proveedor habilitado, un usuario podría obtener acceso a las claves privadas almacenadas.

No permitir comandos que puedan crear nuevos espacios de ejecución

Advertencia

La característica Compatibilidad de Windows de PowerShell 7 crea un nuevo espacio de ejecución para hospedar Windows PowerShell. No permita ningún comando que se ejecutara a través de la característica compatibilidad de Windows. Los *-Job cmdlets pueden crear nuevos espacios de ejecución sin restricciones.

No permita el Trace-Command comando.

Advertencia

El uso de Trace-Command trae todos los comandos de rastreo a la sesión.

No cree sus propias implementaciones de proxy para los comandos restringidos.

PowerShell tiene un conjunto de comandos de proxy para escenarios de comandos restringidos. Estos comandos de proxy garantizan que los parámetros de entrada no puedan poner en peligro la seguridad de la sesión. Los siguientes comandos tienen restricción de proxy.

• Exit-PSSession
• Get-Command
• Get-FormatData
• Get-Help
• Measure-Object
• Out-Default
• Select-Object

Si crea su propia implementación de estos comandos, puede permitir accidentalmente que los usuarios ejecuten código prohibido por los comandos proxy de JEA.

Puede ejecutar el siguiente comando para obtener una lista de comandos restringidos:

$commands = [System.Management.Automation.CommandMetadata]::GetRestrictedCommands(
    [System.Management.Automation.SessionCapabilities]::RemoteServer
)

Puede examinar los comandos de proxy restringidos mediante el comando siguiente:

$commands = [System.Management.Automation.CommandMetadata]::GetRestrictedCommands(
    [System.Management.Automation.SessionCapabilities]::RemoteServer
)
$getHelpProxyBlock = [System.Management.Automation.ProxyCommand]::Create($commands['Get-Help'])

Configuración de la sesión para usar el modo NoLanguage

El modo de PowerShell NoLanguage deshabilita completamente el lenguaje de scripting de PowerShell. No se pueden ejecutar scripts ni usar variables. Solo puede ejecutar comandos y cmdlets nativos.

Para obtener más información sobre los modos de lenguaje, consulte about_Language_Modes.

No se debe permitir el uso del depurador en la sesión.

De forma predeterminada, el depurador de PowerShell ejecuta código en FullLanguage modo. Establezca en SessionState la propiedad UseFullLanguageModeInDebugger como false.

Para obtener más información, vea UseFullLanguageModeInDebugger.