Cómo configurar Windows para que funcione con scripts de PowerShell de forma más sencilla



Windows y PowerShell tienen funciones de seguridad integradas y configuraciones predeterminadas destinadas a evitar que los usuarios finales inicien scripts accidentalmente en el curso de sus actividades diarias. Sin embargo, si sus actividades diarias implican habitualmente escribir y ejecutar sus propios scripts de PowerShell, esto puede ser más una molestia que un beneficio. Aquí, le mostraremos cómo solucionar estas funciones sin comprometer completamente la seguridad.

Cómo y por qué Windows y PowerShell impiden la ejecución de scripts.

PowerShell es efectivamente el shell de comandos y el lenguaje de secuencias de comandos que está destinado a reemplazar CMD y las secuencias de comandos por lotes en los sistemas Windows. Como tal, un script de PowerShell se puede configurar prácticamente para hacer cualquier cosa que pueda hacer manualmente desde la línea de comandos. Eso equivale a hacer prácticamente cualquier cambio posible en su sistema, hasta las restricciones vigentes en su cuenta de usuario. Por lo tanto, si pudiera hacer doble clic en un script de PowerShell y ejecutarlo con todos los privilegios de administrador, una simple frase como esta podría arruinar su día:





|_+_|

¡NO ejecute el comando anterior!

Eso simplemente pasa por el sistema de archivos y elimina todo lo que pueda. Curiosamente, es posible que esto no inutilice el sistema tan rápido como podría pensar, incluso cuando se ejecuta desde una sesión elevada. Pero si alguien lo llama después de ejecutar este script, porque de repente no puede encontrar sus archivos o ejecutar algunos programas, apagarlo y encenderlo de nuevo probablemente solo lo llevará a la Reparación de inicio de Windows, donde se le dirá que no hay nada que se puede hacer para solucionar el problema. Lo que podría ser peor es que, en lugar de obtener un script que simplemente destruye su sistema de archivos, su amigo podría ser engañado para que ejecute uno que descargue e instale un registrador de teclas o un servicio de acceso remoto. Luego, en lugar de hacerle preguntas sobre Startup Repair, es posible que terminen haciéndole a la policía algunas preguntas sobre el fraude bancario.



A estas alturas, debería ser obvio por qué se necesitan ciertas cosas para proteger a los usuarios finales de sí mismos, por así decirlo. Pero los usuarios avanzados, los administradores de sistemas y otros geeks generalmente (aunque hay excepciones) son un poco más cautelosos con estas amenazas, saben cómo detectarlas y evitarlas fácilmente, y solo quieren continuar con su trabajo. Para hacer esto, tendrán que inhabilitar o solucionar algunos obstáculos:

    PowerShell no permite la ejecución de scripts externos de forma predeterminada.
    La configuración ExecutionPolicy en PowerShell evita la ejecución de scripts externos de forma predeterminada en todas las versiones de Windows. En algunas versiones de Windows, el valor predeterminado no permite la ejecución de secuencias de comandos en absoluto. Le mostramos cómo cambiar esta configuración en Cómo permitir la ejecución de scripts de PowerShell en Windows 7 , pero también lo cubriremos en algunos niveles aquí. PowerShell no está asociado a la extensión de archivo .PS1 de forma predeterminada.
    Trajimos esto inicialmente en nuestro PowerShell Geek School serie. Windows establece la acción predeterminada para que los archivos .PS1 los abran en el Bloc de notas, en lugar de enviarlos al intérprete de comandos de PowerShell. Esto es para prevenir directamente la ejecución accidental de scripts maliciosos cuando simplemente se hace doble clic en ellos. Algunas secuencias de comandos de PowerShell no funcionarán sin permisos de administrador.
    Incluso si se ejecuta con una cuenta de nivel de administrador, aún debe pasar por el Control de cuentas de usuario (UAC) para realizar ciertas acciones. Para las herramientas de línea de comandos, esto puede ser un poco engorroso, por decir lo menos. No queremos inhabilitar UAC , pero sigue siendo agradable cuando podemos hacer que sea un poco más fácil de manejar.

Estos mismos problemas se mencionan en Cómo usar un archivo por lotes para hacer que los scripts de PowerShell sean más fáciles de ejecutar, donde lo guiamos a través de la escritura de un archivo por lotes para solucionarlos temporalmente. Ahora, le mostraremos cómo configurar su sistema con una solución a más largo plazo. Tenga en cuenta que, por lo general, no debe realizar estos cambios en sistemas que usted no utilice exclusivamente; de ​​lo contrario, aumentará el riesgo de que otros usuarios se encuentren con los mismos problemas que estas funciones pretenden evitar.

Cambiar la asociación de archivos .PS1.

La primera molestia, y quizás la más importante, es la asociación predeterminada para los archivos .PS1. Asociar estos archivos a cualquier otra cosa que no sea PowerShell.exe tiene sentido para evitar la ejecución accidental de scripts no deseados. Pero, considerando que PowerShell viene con un entorno de scripting integrado (ISE) que está diseñado específicamente para editar scripts de PowerShell, ¿por qué querríamos abrir archivos .PS1 en el Bloc de notas de forma predeterminada? Incluso si no está listo para cambiar completamente y habilitar la función de hacer doble clic para ejecutar, probablemente desee modificar esta configuración.



Anuncio publicitario

Puede cambiar la asociación de archivos .PS1 a cualquier programa que desee con el Programas predeterminados panel de control, pero buscar directamente en el Registro le dará un poco más de control sobre exactamente cómo se abrirán los archivos. Esto también le permite configurar o cambiar opciones adicionales que están disponibles en el menú contextual para archivos .PS1. ¡No olvide hacer una copia de seguridad del registro antes de hacer esto!

La configuración del registro que controla cómo se abren los scripts de PowerShell se almacena en la siguiente ubicación:

|_+_|

Para explorar estas configuraciones antes de cambiarlas, eche un vistazo a esa clave y sus sub-claves con Regedit . La clave Shell debe tener un solo valor, (predeterminado), que se establece en Abrir. Este es un puntero a la acción predeterminada para hacer doble clic en el archivo, que veremos en las subclaves.

Expanda la tecla Shell y verá tres subclaves. Cada uno de estos representa una acción que puede realizar y que es específica de los scripts de PowerShell.

Puede expandir cada clave para explorar los valores dentro, pero básicamente equivalen a los siguientes valores predeterminados:

  • 0: ejecutar con PowerShell. Ejecutar con PowerShell es en realidad el nombre de una opción que ya está en el menú contextual de los scripts de PowerShell. El texto simplemente se extrae de otra ubicación en lugar de usar el nombre de la clave como los demás. Y todavía no es la acción de doble clic predeterminada.
  • Editar: abrir en PowerShell ISE. Esto tiene mucho más sentido que el Bloc de notas, pero aún debe hacer clic con el botón derecho en el archivo .PS1 para hacerlo de forma predeterminada.
  • Abrir: abrir en el Bloc de notas. Tenga en cuenta que este nombre de clave también es la cadena almacenada en el valor (predeterminado) de la clave Shell. Esto significa que al hacer doble clic en el archivo se abrirá, y esa acción normalmente está configurada para usar el Bloc de notas.
Anuncio publicitario

Si desea seguir con las cadenas de comandos predefinidas que ya están disponibles, puede simplemente cambiar el valor (predeterminado) en la clave Shell para que coincida con el nombre de la clave que coincide con lo que desea hacer con un doble clic. Esto se puede hacer fácilmente desde Regedit, o puede usar las lecciones aprendidas de nuestro tutorial sobre explorar el registro con PowerShell (más un pequeño ajuste de PSDrive) para comenzar a construir un script reutilizable que pueda configurar sus sistemas por usted. Los siguientes comandos deben ejecutarse desde una sesión elevada de PowerShell, similar a ejecutando CMD como administrador .

Primero, querrá configurar un PSDrive para HKEY_CLASSES_ROOT ya que no está configurado de forma predeterminada. El comando para esto es:

|_+_|

Ahora puede navegar y editar claves y valores de registro en HKEY_CLASSES_ROOT como lo haría en los PSDrives HKCU y HKLM normales.

Para configurar el doble clic para iniciar scripts de PowerShell directamente:

|_+_|

Para configurar el doble clic para abrir scripts de PowerShell en PowerShell ISE:

|_+_|

Para restaurar el valor predeterminado (establece el doble clic para abrir los scripts de PowerShell en el Bloc de notas):

|_+_|

Eso es solo lo básico para cambiar la acción de doble clic predeterminada. En la siguiente sección, entraremos en más detalles sobre la personalización de cómo se manejan los scripts de PowerShell cuando se abren en PowerShell desde el Explorador. Manten eso en mente el alcance evita que PSDrives persista entre sesiones . Por lo tanto, probablemente desee incluir la línea New-PSDrive al comienzo de cualquier script de configuración que cree para este propósito, o agréguelo a su perfil de PowerShell . De lo contrario, deberá ejecutar ese bit manualmente antes de intentar realizar cambios de esta manera.

Cambiar la configuración de PowerShell ExecutionPolicy.

ExecutionPolicy de PowerShell es otra capa de protección contra la ejecución de scripts maliciosos. Hay varias opciones para esto y un par de formas diferentes de configurarlo. De la más segura a la menos segura, las opciones disponibles son:

  • Restringido: no se permite la ejecución de scripts. (Configuración predeterminada para la mayoría de los sistemas). Esto incluso evitará que se ejecute la secuencia de comandos de su perfil.
  • AllSigned: todos los scripts deben estar firmados digitalmente por un editor de confianza para que se ejecuten sin preguntar al usuario. Los scripts firmados por editores definidos explícitamente como no confiables, o los scripts que no están firmados digitalmente, no se ejecutarán. PowerShell le pedirá al usuario que confirme si una secuencia de comandos está firmada por un editor que aún no está definido como confiable o no confiable. Si no ha firmado digitalmente la secuencia de comandos de su perfil y no ha establecido confianza en esa firma, no podrá ejecutarse. Tenga cuidado con los editores en los que confía, ya que aún puede terminar ejecutando scripts maliciosos si confía en el incorrecto.
  • RemoteSigned: para scripts descargado de Internet , esto es efectivamente lo mismo que AllSigned. Sin embargo, los scripts creados localmente o importados de fuentes distintas de Internet pueden ejecutarse sin ningún mensaje de confirmación. Aquí, también deberá tener cuidado con las firmas digitales en las que confía, pero aún más cuidado con los scripts no firmados que elija ejecutar. Este es el nivel de seguridad más alto por debajo del cual puede tener un script de perfil de trabajo sin tener que firmarlo digitalmente.
  • Sin restricciones: todos los scripts pueden ejecutarse, pero se requerirá un mensaje de confirmación para los scripts de Internet. A partir de este momento, depende totalmente de usted evitar ejecutar scripts que no sean de confianza.
  • Bypass: todo funciona sin advertencia. Ten cuidado con éste.
  • Indefinido: no se define ninguna política en el alcance actual. Esto se utiliza para permitir el retroceso a las políticas definidas en alcances inferiores (más detalles a continuación) o a los valores predeterminados del sistema operativo.
Anuncio publicitario

Como sugiere la descripción de Indefinido, las políticas anteriores se pueden establecer en uno o más de varios ámbitos. Puede usar Get-ExecutionPolicy, con el parámetro -List, para ver todos los ámbitos y su configuración actual.

Los ámbitos se enumeran en orden de prioridad, y el ámbito definido más alto anula a todos los demás. Si no se definen políticas, el sistema vuelve a su configuración predeterminada (en la mayoría de los casos, está restringida).

  • MachinePolicy representa un Política de grupo en efecto a nivel de Computadora. Esto generalmente se aplica solo en un dominio , pero también se puede hacer localmente.
  • UserPolicy representa una política de grupo en vigor para el usuario. Esto también se usa normalmente solo en entornos empresariales.
  • El proceso es un ámbito específico para esta instancia de PowerShell. Los cambios en la política en este ámbito no afectarán a otros procesos de PowerShell en ejecución y serán ineficaces una vez finalizada esta sesión. Esto se puede configurar mediante el parámetro -ExecutionPolicy cuando se inicia PowerShell, o se puede configurar con la sintaxis Set-ExecutionPolicy adecuada desde dentro de la sesión.
  • CurrentUser es un ámbito que se configura en el registro local y se aplica a la cuenta de usuario utilizada para iniciar PowerShell. Este alcance se puede modificar con Set-ExecutionPolicy.
  • LocalMachine es un alcance configurado en el registro local y que se aplica a todos los usuarios del sistema. Este es el ámbito predeterminado que se cambia si Set-ExecutionPolicy se ejecuta sin el parámetro -Scope. Como se aplica a todos los usuarios del sistema, solo se puede cambiar desde una sesión elevada.

Dado que este artículo trata principalmente sobre eludir la seguridad para facilitar la usabilidad, solo nos preocupan los tres ámbitos inferiores. La configuración de MachinePolicy y UserPolicy es realmente útil solo si desea hacer cumplir una política restrictiva que no se pase por alto de manera tan simple. Al mantener nuestros cambios en el nivel de Proceso o por debajo, podemos usar fácilmente cualquier configuración de política que consideremos apropiada para una situación determinada en cualquier momento.

Para mantener cierto equilibrio entre seguridad y facilidad de uso, la política que se muestra en la captura de pantalla probablemente sea la mejor. Establecer la política de LocalMachine en Restringido generalmente evita que alguien que no sea usted ejecute scripts. Por supuesto, los usuarios que saben lo que están haciendo pueden pasar por alto sin mucho esfuerzo. Pero debería evitar que los usuarios que no son expertos en tecnología activen accidentalmente algo catastrófico en PowerShell. Tener el CurrentUser (es decir, usted) configurado como Unrestricted le permite ejecutar scripts manualmente desde la línea de comandos como desee, pero conserva un recordatorio de precaución para los scripts descargados de Internet. La configuración de RemoteSigned en el nivel de proceso debería realizarse en un acceso directo a PowerShell.exe o (como haremos a continuación) en los valores del Registro que controlan el comportamiento de los scripts de PowerShell. Esto permitirá una sencilla funcionalidad de doble clic para ejecutar para cualquier script que escriba, al tiempo que crea una barrera más fuerte contra la ejecución involuntaria de scripts (potencialmente maliciosos) de fuentes externas. Queremos hacer esto aquí, ya que es mucho más fácil hacer doble clic accidentalmente en un script que llamarlo manualmente desde una sesión interactiva.

Para configurar las políticas CurrentUser y LocalMachine como en la captura de pantalla anterior, ejecute los siguientes comandos desde una sesión elevada de PowerShell:

|_+_|
Anuncio publicitario

Para hacer cumplir la política RemoteSigned en los scripts que se ejecutan desde Explorer, tendremos que cambiar un valor dentro de una de las claves de registro que estábamos viendo anteriormente. Esto es particularmente importante porque, según su versión de PowerShell o Windows, la configuración predeterminada puede ser omitir todas las configuraciones de ExecutionPolicy excepto AllSigned. Para ver cuál es la configuración actual para su computadora, puede ejecutar este comando (asegurándose de que el HKCR PSDrive esté mapeado primero):

|_+_|

Su configuración predeterminada probablemente será una de las siguientes dos cadenas, o algo bastante similar:

(Visto en Windows 7 SP1 x64, con PowerShell 2.0)

|_+_|

(Visto en Windows 8.1 x64, con PowerShell 4.0)

|_+_|

El primero no es tan malo, ya que todo lo que hace es ejecutar el script en la configuración existente de ExecutionPolicy. Se podría mejorar aplicando restricciones más estrictas para una acción más propensa a los accidentes, pero esto no estaba pensado originalmente para activarse con un doble clic de todos modos, y la política predeterminada generalmente es Restringida después de todo. La segunda opción, sin embargo, es eludir por completo cualquier Política de Ejecución que probablemente tenga implementada, incluso Restringida. Dado que la omisión se aplicará en el alcance del proceso, solo afecta a las sesiones que se inician cuando los scripts se ejecutan desde Explorer. Sin embargo, esto significa que podría terminar lanzando scripts que de otro modo esperaría (y desearía) que su política prohibiera.

Para configurar ExecutionPolicy a nivel de proceso para scripts iniciados desde Explorer, de acuerdo con la captura de pantalla anterior, deberá modificar el mismo valor de registro que acabamos de consultar. Puede hacerlo manualmente en Regedit, cambiándolo a esto:

|_+_|

También puede cambiar la configuración desde PowerShell si lo prefiere. Recuerde hacer esto desde una sesión elevada, con el HKCR PSDrive mapeado.

|_+_|

Ejecute scripts de PowerShell como administrador.

Así como es una mala idea deshabilitar UAC por completo, también es una mala práctica de seguridad ejecutar scripts o programas con privilegios elevados a menos que realmente los necesite para realizar operaciones que requieren acceso de administrador. Por lo tanto, no se recomienda crear el indicador de UAC en la acción predeterminada para los scripts de PowerShell. Sin embargo, podemos agregar una nueva opción de menú contextual que nos permita ejecutar scripts fácilmente en sesiones elevadas cuando lo necesitemos. Esto es similar al método utilizado para agregue Abrir con el Bloc de notas al menú contextual de todos los archivos - pero aquí solo vamos a apuntar a scripts de PowerShell. También vamos a trasladar algunas técnicas utilizadas en el artículo anterior, donde usamos un archivo por lotes en lugar de hacks de registro para iniciar nuestro script de PowerShell.

Anuncio publicitario

Para hacer esto en Regedit, vuelva a la clave Shell, en:

|_+_|

Allí, cree una nueva subclave. Llámelo Ejecutar con PowerShell (Administrador). Debajo de eso, cree otra subclave llamada Comando. Luego, establezca el valor (predeterminado) en Comando a esto:

|_+_|

Hacer lo mismo en PowerShell necesitará tres líneas esta vez. Una para cada tecla nueva y otra para establecer el valor (predeterminado) de Comando. No olvide la elevación y el mapeo HKCR.

|_+_|

Además, preste especial atención a las diferencias entre la cadena que se ingresa a través de PowerShell y el valor real que ingresa al Registro. En particular, tenemos que envolver todo entre comillas simples y duplicar las comillas simples internas para evitar errores en el análisis de comandos.

Ahora debería tener una nueva entrada de menú contextual para los scripts de PowerShell, llamada Ejecutar con PowerShell (Admin).

La nueva opción generará dos instancias consecutivas de PowerShell. El primero es solo un lanzador para el segundo, que usa Start-Process con el parámetro -Verb RunAs para solicitar elevación para la nueva sesión. A partir de ahí, su secuencia de comandos debería poder ejecutarse con privilegios de administrador después de hacer clic en el indicador de UAC.

Últimos retoques.

Solo hay un par de ajustes más en esto que pueden ayudar a hacer la vida un poco más fácil aún. Por un lado, ¿qué tal deshacerse de la función Bloc de notas por completo? Simplemente copie el valor (predeterminado) de la tecla Comando en Editar (abajo), en la misma ubicación debajo de Abrir.

|_+_|
Anuncio publicitario

O puede usar este bit de PowerShell (con Admin y HKCR, por supuesto):

|_+_|

Una pequeña molestia más es el hábito de la consola de desaparecer una vez que se completa un guión. Cuando eso sucede, no tenemos ninguna posibilidad de revisar la salida del script en busca de errores u otra información útil. Esto puede solucionarse poniendo una pausa al final de cada uno de sus guiones, por supuesto. Alternativamente, podemos modificar los valores (predeterminados) de nuestras teclas de comando para incluir el parámetro -NoSalir. A continuación se muestran los valores modificados.

(Sin acceso de administrador)

|_+_|

(Con acceso de administrador)

|_+_|

Y, por supuesto, también te los proporcionaremos en los comandos de PowerShell. Último recordatorio: ¡Elevación y HKCR!

(No administrador)

|_+_|

(Administración)

|_+_|

Darle una vuelta.

Para probar esto, usaremos un script que puede mostrarnos la configuración de ExecutionPolicy en su lugar y si el script se inició o no con permisos de administrador. El script se llamará MyScript.ps1 y se almacenará en D: Script Lab en nuestro sistema de muestra. El código está a continuación, como referencia.

|_+_|

Usando la acción Ejecutar con PowerShell:

Usando la acción Ejecutar con PowerShell (Admin), después de hacer clic en UAC:

Anuncio publicitario

Para demostrar ExecutionPolicy en acción en el alcance del proceso, podemos hacer que Windows piense que el archivo vino de Internet con este fragmento de código de PowerShell:

|_+_|

Afortunadamente, teníamos habilitado -NoSalir. De lo contrario, ese error simplemente habría pasado y no nos habríamos dado cuenta.

El Zone.Identifier se puede eliminar con esto:

|_+_|

Referencias útiles:

LEER SIGUIENTE

Artículos De Interés