Saludos. Roberto Di Lello.<\/p>\n
—–
Windows PowerShell – Protecci\u00f3n del Shell<\/h5>\n
Cuando el equipo de Windows PowerShell se sent\u00f3 a crear un shell nuevo y sali\u00f3 a relucir la palabra “scripting”, seguramente los gritos de p\u00e1nico se oyeron en todo Redmond. Despu\u00e9s de todo, los esfuerzos anteriores de Microsoft sobre scripting administrativo (m\u00e1s concretamente me refiero a VBScript) no estuvieron exactamente libres de problemas. Un <\/p>\n
modelo de ejecuci\u00f3n excesivamente permisivo, combinado con la inclinaci\u00f3n de la mayor\u00eda de usuarios a iniciar sesi\u00f3n como administradores completos, abri\u00f3 la puerta al desastre. <\/p>\n
Los participantes de esa primera reuni\u00f3n sobre Windows PowerShell\u2122 seguramente se repitieron a ellos mismos eso de “de ninguna manera vamos a pasar por eso otra vez”. Y lo han conseguido. Microsoft ha mejorado much\u00edsimo su reputaci\u00f3n en seguridad, en gran parte porque empez\u00f3 a pensar en la seguridad en la fase inicial, en lugar de hacerlo cuando el ciclo de desarrollo de un producto ya estaba avanzado. Esta filosof\u00eda es mucho m\u00e1s evidente en Windows PowerShell. <\/p>\n
\u00bfPor qu\u00e9 no se ejecutan mis scripts?<\/h6>\n
Instale Windows PowerShell en un equipo reci\u00e9n instalado y haga doble clic en un archivo .ps1: se abrir\u00e1 el Bloc de notas, no Windows PowerShell. Esto es porque la extensi\u00f3n del nombre de archivo .ps1 (la que usan los scripts de Windows PowerShell) no est\u00e1 asociada con el propio shell. Es decir, no se puede ejecutar un script s\u00f3lo con hacer doble clic en \u00e9l. La \u00fanica manera de ejecutar un script es abrir Windows PowerShell, escribir el nombre de script y despu\u00e9s presionar Intro. <\/p>\n
En realidad, s\u00f3lo con escribir el nombre del script tampoco es suficiente. Como puede ver en la figura 1, el archivo Demo1.ps1 existe en la carpeta actual, pero al escribir demo1 y presionar Entrar se genera el error siguiente: “El t\u00e9rmino ‘demo1’ no se reconoce como cmdlet, funci\u00f3n, programa operable ni archivo de script.” \u00bfA qu\u00e9 se debe? Despu\u00e9s de todo, el archivo se encuentra ah\u00ed mismo. <\/p>\n
Ejecutar demo1 no funciona, porque no se incluye la ruta de acceso, pero ejecutar .\/demo1 funciona. Esto es porque ahora he especificado una ruta de acceso, la carpeta actual. Esa l\u00ednea de comandos es menos probable de ser confundida con un comando integrado, ya que si se estuviera refiriendo a un comando integrado nunca escribir\u00eda ning\u00fan tipo de ruta de acceso. As\u00ed, el hecho de requerir una ruta de acceso ayuda a que Windows PowerShell evite el secuestro de comandos y la confusi\u00f3n sobre lo que pueda suceder al presionar Intro. <\/p>\n As\u00ed que tiene una copia reci\u00e9n instalada de Windows PowerShell, est\u00e1 usando la sintaxis apropiada e intenta ejecutar un script. Para su sorpresa, ver\u00e1 aparecer otro mensaje de error, que le informar\u00e1 que a Windows PowerShell no se le permite ejecutar scripts. \u00bfQu\u00e9? Bienvenido a la directiva de ejecuci\u00f3n del shell. <\/p>\n Puede consultar cu\u00e1l es la directiva de ejecuci\u00f3n actual si ejecuta Get-ExecutionPolicy en el shell. De forma predeterminada, est\u00e1 establecida en Restricted, lo que resumiendo significa que los scripts no se ejecutar\u00e1n. Nunca. Para nadie. De forma predeterminada, Windows PowerShell s\u00f3lo se puede usar de manera interactiva, en lugar de para ejecutar scripts. Puede usar el cmdlet Set-ExecutionPolicy para elegir entre una de las cuatro configuraciones posibles de las directivas de ejecuci\u00f3n: <\/p>\n Francamente, AllSigned es la configuraci\u00f3n m\u00e1s baja en la que deber\u00eda establecerse cualquier equipo de producci\u00f3n. RemoteSigned resulta \u00fatil en entornos de desarrollo y pruebas, pero no es necesario para el usuario normal. Y no veo la necesidad de usar Unrestricted en ning\u00fan caso, y no me importar\u00eda si en versiones futuras de Windows PowerShell se omitiera esta configuraci\u00f3n demasiado permisiva. <\/p>\n Su equipo est\u00e1 preconfigurado para confiar en ciertas entidades de certificaci\u00f3n ra\u00edz (CA), es decir, servidores que publican certificados digitales. La figura 2 muestra la aplicaci\u00f3n de panel de control Opciones de Internet, que muestra las entidades de certificaci\u00f3n ra\u00edz de confianza. En Windows Vista\u00ae<\/sup>, esta lista es bastante corta y s\u00f3lo incluye algunas entidades de certificaci\u00f3n ra\u00edz comerciales importantes. Por el contrario, la lista predeterminada en Windows\u00ae<\/sup> XP es grande e incluye muchas entidades de certificaci\u00f3n ra\u00edz de las que nunca he o\u00eddo nada. Cuando una entidad de certificaci\u00f3n ra\u00edz est\u00e1 en esta lista, esencialmente se est\u00e1 diciendo que se conf\u00eda en que la empresa que usa la entidad de certificaci\u00f3n ra\u00edz har\u00e1 un buen trabajo al comprobar la identidad de alguien antes de emitir un certificado digital con su nombre. <\/p>\n Cuando se obtiene certificado digital de Clase III, que com\u00fanmente se denomina un certificado de firma de c\u00f3digo, la CA (que puede ser una CA comercial o privada que exista dentro de su organizaci\u00f3n) debe comprobar su identidad. Ese certificado digital es como un pasaporte o pieza de identidad electr\u00f3nicos. Por ejemplo, antes darme un identificador que diga soy Don Jones, es necesario que la CA realice algunos pasos para asegurarse de que realmente sea Don Jones. Cuando usa su certificado para firmar digitalmente un script de Windows PowerShell, cosa que puede hacer con el cmdlet Set-AuthenticodeSignature, est\u00e1 firmando con su nombre en el script. Por supuesto, si puede obtener un certificado falso que contenga el nombre de otra persona, puede firmar con su nombre el script, y por eso es tan importante que s\u00f3lo aparezcan CA de confianza en la lista de la figura 2. <\/p>\n Cuando Windows PowerShell comprueba si se conf\u00eda en un script, cosa que hace si la configuraci\u00f3n de directiva de ejecuci\u00f3n es AllSigned y RemoteSigned, hace tres preguntas: <\/p>\n \u00bfEn qu\u00e9 mejora la seguridad con la confianza? Con toda seguridad, un pirata inform\u00e1tico podr\u00eda escribir un script malintencionado, firmarlo y convencer a alguien de su entorno para que lo ejecute. Dado que el script estar\u00eda firmado, se ejecutar\u00eda. Pero dado que estaba firmado, podr\u00eda usar la firma digital para buscar la identidad del autor y tomar las medidas pertinentes (como llamar a las fuerzas de orden p\u00fablico). Aunque alguien tendr\u00eda que ser muy poco inteligente para crear un script malintencionado y despu\u00e9s poner en \u00e9l su nombre real. <\/p>\n Por supuesto, si un usuario malintencionado fuera capaz de obtener un certificado para la identidad de alguien distinto, por ejemplo de una CA que no tuviera un buen proceso de comprobaci\u00f3n de identidades, no podr\u00eda usar la firma digital para identificar al verdadero culpable. De ah\u00ed que las entidades emisoras ra\u00edz en las que conf\u00ede deben tener un proceso de comprobaci\u00f3n de identidades que considere satisfactorio. <\/p>\n Si usa la configuraci\u00f3n de directiva de ejecuci\u00f3n AllSigned, deber\u00e1 firmar digitalmente incluso los scripts que produzca usted mismo antes de poderlos ejecutar. El cmdlet Set-AuthenticodeSignature es bastante f\u00e1cil de usar, pero a\u00fan puede representar una molestia. En este punto el software de terceros puede resultar pr\u00e1ctico. Le recomiendo que seleccione un editor de scripts o un entorno de desarrollo visual que firmen autom\u00e1ticamente sus scripts con el certificado que especifique. De esta forma, el uso de firmas digitales resulta transparente y no requiere esfuerzos adicionales. Si desea ver sugerencias para editores y entornos de desarrollo que sean compatibles con esto, visite algunos de los foros de scripting (como el de mi sitio en ScriptingAnswers.com<\/a>) y env\u00ede un mensaje preguntando qu\u00e9 usan otros fan\u00e1ticos de Windows PowerShell. <\/p>\n Cuando tenga un certificado, tambi\u00e9n puede ejecutar la l\u00ednea siguiente para firmar todos los scripts de una ubicaci\u00f3n determinada: <\/p>\n La directiva de ejecuci\u00f3n de Windows PowerShell tambi\u00e9n se puede configurar individualmente, equipo por equipo. Pero esto no es una buena soluci\u00f3n en entornos empresariales. En vez de eso, puede usar la Directiva de grupo. (Puede descargar las plantillas administrativas de Windows PowerShell desde go.microsoft.com\/fwlink\/?LinkId=93675<\/a>.) Simplemente suelte el archivo en un Objeto de directiva de grupo (GPO) que afecte a todo su dominio y establ\u00e9zcalo en Restricted. De esta forma, no importa d\u00f3nde est\u00e9 instalado Windows PowerShell, podr\u00e1 estar seguro que los scripts no podr\u00e1n ejecutarse. A continuaci\u00f3n, puede aplicar una configuraci\u00f3n m\u00e1s permisiva (por ejemplo, AllSigned) en aquellos equipos que deban ejecutar scripts (como ser\u00eda el caso de su propia estaci\u00f3n de trabajo). <\/p>\n A diferencia de anteriores lenguajes de scripting administrativo para Windows, Windows PowerShell tambi\u00e9n est\u00e1 preparado para tratar con credenciales alternativas de forma segura. Por ejemplo, el cmdlet Get-WMIObject tiene un par\u00e1metro -credential que permite especificar una credencial alternativa para conexiones WMI remotas. El par\u00e1metro aceptar\u00e1 un nombre de usuario pero no una contrase\u00f1a, impidiendo as\u00ed la codificaci\u00f3n de contrase\u00f1as privadas en un script de texto normal. En cambio, cuando proporcione el nombre del usuario, Windows PowerShell le preguntar\u00e1 la contrase\u00f1a mediante un cuadro de di\u00e1logo. Si tiene pensado usar una credencial alternativa otra vez, puede almacenar la informaci\u00f3n de autenticaci\u00f3n con el cmdlet Get-Credential: <\/p>\n Se le pedir\u00e1 inmediatamente la contrase\u00f1a y la credencial final se almacenar\u00e1 en la variable $cred. A continuaci\u00f3n, la variable $cred se puede pasar al par\u00e1metro \u2013credential tan a menudo como sea necesario. Incluso puede usar los cmdlets ConvertTo-SecureString y ConvertFrom-SecureString para convertir la credencial en una cadena cifrada o para convertir una cadena cifrada anteriormente de nuevo en credencial. <\/p>\n El problema de esto es que la clave de cifrado termina siendo almacenada en un script de texto normal, cosa que est\u00e1 completamente en contra de la seguridad. As\u00ed que en vez de hacer esto, puede agregar una llamada a Get-Credential en su perfil de Windows PowerShell. En ese caso, cuando Windows PowerShell se ejecuta, se le pide inmediatamente un nombre de usuario y una contrase\u00f1a, que despu\u00e9s se almacenan en una variable llamada $cred. De este modo, siempre tiene la variable $cred disponible en el shell que representa una cuenta de administrador del dominio. Y nunca tiene que preocuparse de almacenar esa credencial en ninguna parte; dado que la credencial se vuelve a crear cada vez que se abre el shell, no hay necesidad de almacenarla. <\/p>\n De forma predeterminada, Windows PowerShell se instala y configura con los valores m\u00e1s seguros que pudiera sugerir para un shell administrativo que admita scripting. A menos que cambie alguna de esas configuraciones, Windows PowerShell permanecer\u00e1 lo m\u00e1s protegido posible. Es decir, cualquier cosa que reduzca la seguridad de Windows PowerShell ser\u00e1 resultado de su decisi\u00f3n y de sus acciones. As\u00ed que antes de cambiar alguno de los valores predeterminados (reconfigurando las asociaciones de las extensiones de archivo, cambiando la directiva de ejecuci\u00f3n, etc.) aseg\u00farese de entender completamente las consecuencias de sus acciones y est\u00e9 preparado para responsabilizarse del resultado de sus cambios. <\/p>\n Don Jones<\/b> es el gur\u00fa principal de scripting de SAPIEN Technologies y un instructor de ScriptingTraining.com.<\/a> Puede ponerse en contacto con Don a trav\u00e9s de su sitio web, ScriptingAnswers.com<\/a>. <\/p>\n Extra\u00eddo del September 2007<\/a> n\u00famero de TechNet Magazine<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Buscando info sobre un script en powershell encontre esta nota y me aprecio interesante compartirla….<\/p>\n","protected":false},"author":1,"featured_media":4291,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[4],"tags":[],"class_list":["post-244","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting"],"_links":{"self":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/244","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=244"}],"version-history":[{"count":0,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/posts\/244\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=\/wp\/v2\/media\/4291"}],"wp:attachment":[{"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.radians.com.ar\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"image\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images\/WindowsPowerShellProtecciondelShellTechn_82DB\/image_thumb.png\")
<\/a> Este es otro aspecto del modelo de seguridad de Windows PowerShell. Una artima\u00f1a que normalmente intentan los usuarios malintencionados en otros shells es crear un script con el mismo nombre de archivo que un comando integrado. As\u00ed, por ejemplo, si deseara que un usuario ejecutara su script, podr\u00eda llamarlo Dir.ps1 y dejarlo en una carpeta. Si convenciera al usuario para que escribiera Dir y despu\u00e9s presionara Intro, se podr\u00eda ejecutar su script, no el comando Dir que el usuario esperaba. Esta t\u00e9cnica se llama secuestro de comandos. En Windows PowerShell siempre es obligatorio proporcionar una ruta de acceso a ese script, protegiendo as\u00ed bastante bien a Windows PowerShell frente a secuestros de comandos. <\/p>\nDirectiva para la ejecuci\u00f3n de scripts<\/h6>\n
\n
Es una cuesti\u00f3n de confianza<\/h6>\n
![\"image\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images\/WindowsPowerShellProtecciondelShellTechn_82DB\/image_thumb_3.png\")
<\/a> <\/p>\n\n
![\"image\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images\/WindowsPowerShellProtecciondelShellTechn_82DB\/image_thumb_4.png\")
<\/a> <\/p>\nProtecci\u00f3n centralizada<\/h6>\n
Credenciales alternativas<\/h6>\n
![\"image\"](\"http:\/\/www.radians.com.ar\/Articulos\/Images\/WindowsPowerShellProtecciondelShellTechn_82DB\/image_thumb_5.png\")
<\/a> <\/p>\nSeguridad predeterminada<\/h6>\n
\n
\n