Ediciones ENI

PowerShell Core y Windows PowerShell

Los fundamentos del lenguaje (2a edición)

Colección Expert IT

Extracto del Libro

373

Capítulo 12

Seguridad

Seguridad1. La seguridad: ¿para quién? ¿Por qué?

La aparición de las redes locales y de Internet ha cambiado muchas cosas en la manerade proteger su PC. Ya no basta con encadenar el disco duro a la mesa y cerrar la puertadel despacho por la noche para que no le roben o pirateen sus datos. Ahora, protegersu puesto de trabajo se ha convertido en algo esencial para no tener que remediar in-trusiones o malas intenciones.Pero entonces ¿contra quién prevenir? Pues contra todo lo que se mueve… y tambiénlos que no se mueven. En efecto, ya sean programas malintencionados, usuarios conmalas intenciones, o hasta usuarios novatos, todos están considerados una amenaza.Por este motivo debe asegurar su sistema estableciendo reglas de seguridad, aplicándo-las y asegurándose de que los demás hacen lo mismo.

2. Los riesgos vinculados al scripting

Adivinará rápidamente que lo que hace la fuerza del scripting se convierte en su debi-lidad. La facilidad con la que puede hacer todo, ya sea haciendo clic en un script o eje-cutándolo desde la ventana de comandos, puede meterle en problemas si no prestaatención.

© E

dit

ions

EN

I -

All r

ights

rese

rved

374Windows PowerShell - Los fundamentos del lenguaje

PowerShell Core

Imagine un script de inicio de sesión que en la apertura de la sesión ¡la bloquea ense-guida! Claro, es divertido entre amigos, pero en una empresa, dudamos que esto seabueno. Todavía peor un script de una persona malintencionada o realmente novataen PowerShell (en este caso, le aconsejamos comprarle un ejemplar de este libro…)puede perfectamente bloquear cuentas de usuarios en Active Directory, formatear eldisco, reiniciar el sistema en un bucle infinito… Lo ha entendido, un script puede ha-cer de todo. Aunque a día de hoy se notifica al usuario con alertas para prevenirle dela ejecución de un script, estas no son capaces de determinar si un script es nocivo parael correcto funcionamiento del sistema.Los riesgos vinculados al scripting se resumen a una historia de compromisos: o bienimpide toda ejecución de scripts, es decir asumir el riesgo de «amargarle la vida»teniendo que hacer y rehacer tareas básicas y muy ingratas, o bien elige abrir su siste-ma a PowerShell, teniendo cuidado de tomar las precauciones que se imponen.Pero no se deje desanimar ya que aunque la ejecución de scripts le expone a ciertos pro-blemas de seguridad, PowerShell está dotado de ciertos conceptos que hacen de él unode los lenguajes de script más seguros. No hay que olvidar que en caso de problemasde seguridad, es la imagen de Microsoft en su conjunto la que sufre…

3. Optimizar la seguridad de PowerShell

3.1 La seguridad de PowerShell por defecto

Lo ha entendido, la seguridad es una área muy importante, sobre todo en el dominiodel scripting. Por este motivo los creadores de PowerShell han incluido dos reglas deseguridad por defecto.

Los archivos ps1 asociados al bloc de notas

La extensión «.ps1» de los scripts PowerShell está por defecto asociada al bloc de no-tas (o Notepad). Este procedimiento permite evitar ejecutar automáticamente scriptspotencialmente peligrosos por una mala manipulación. El bloc de notas es, realmente,un editor un poco clásico, pero tiene la doble ventaja de ser inofensivo y de nobloquear la ejecución de un script cuando este está abierto con el editor. Observará sinembargo que la edición (clic con el botón derecho + Modificar) de archivos .ps1 estáasociada al editor ISE.

Observación

Este tipo de seguridad no existía con los scripts VBS cuya apertura estaba directamente

asociada a Windows Script Host.

375SeguridadCapítulo 12

Una directiva de ejecución restringida

La segunda barrera de seguridad es la aplicación de la directiva de ejecuciónRestricted por defecto para los puestos clientes y RemoteSigned por defectopara los servidores (desde Windows Server 2012 R2).La directiva Restricted es la más restrictiva. Es decir que bloquea sistemáticamentela ejecución de todos los scripts. Solo se ejecutan los comandos tecleados en la shell.Para remediar a esta situación, PowerShell requiere que el usuario cambie el modo deejecución con el comando Set-ExecutionPolicy <modo de ejecución>. Peropara ello debe ser administrador del equipo.

Observación

Igual comprende mejor por qué el uso de PowerShell en sus equipos no constituye un

aumento del riesgo, en la medida en que se respetan ciertas reglas.

3.2 Las directivas de ejecución

PowerShell integra un concepto de seguridad que llamamos directivas de ejecución(execution policies) para que un script no autorizado no pueda ejecutarse en contrade la voluntad del usuario. Existen siete configuraciones posibles: Restricted,RemoteSigned, AllSigned, UnRestricted, Bypass, Default y Undefined.A cada una de ellas le corresponde un nivel de autorización de ejecución de determi-nados scripts. Podrá llegar a cambiar en función de la directiva que desee aplicar.

3.2.1 Las diferentes directivas de ejecución

Restricted: es la directiva más restrictiva y también la directiva por defecto en lospuestos cliente (de Windows 7 a Windows 10). No permite la ejecución de scripts peroautoriza las instrucciones por la línea de comandos tecleadas en la consola (modo in-teractivo). Esta directiva puede considerarse como la más radical dado que protegefrente a la ejecución de archivos .ps1.Con esta directiva, al tratar de ejecutar un script, se muestra un mensaje de este tipoen la consola:

.\lanzadera.ps1 : File C:\temp\lanzadera.ps1 cannot be loaded because running

scripts is disabled on this system. For more information, see

about_Execution_Policies at https://go.microsoft.com/fwlink/?LinkID=135170.

At line:1 char:1 *

+ .\lanzadera.ps1

+ ~~~~~~~~~~~~~

+ CategoryInfo : SecurityError: (:) [], PSSecurityException

+ FullyQualifiedErrorId : UnauthorizedAccess

© E

dit

ions

EN

I -

All r

ights

rese

rved

376Windows PowerShell - Los fundamentos del lenguaje

PowerShell Core

Si esta es la directiva definida por defecto en la instalación de PowerShell, tendrá quecambiarla para la ejecución de su primer script.

Observación

Para poder modificar la directiva de ejecución PowerShell, deberá ser administrador

local de la máquina.

AllSigned: es la directiva más «segura» que permite la ejecución de scripts. Autorizaúnicamente la ejecución de scripts firmados. Un script firmado es un script quecontiene una firma digital como la que se muestra en la figura de abajo.

Ejemplo de script firmado

Con la directiva AllSigned, la ejecución de scripts firmados necesita que esté enposesión de los certificados correspondientes (consulte la sección Firma de scripts).

377SeguridadCapítulo 12

RemoteSigned: esta directiva es similar a AllSigned con la diferencia de que sololos scripts que tienen un origen distinto al local necesitan una firma. Por consiguiente,todos sus scripts creados localmente pueden ser ejecutados sin necesidad de firma.A partir de Windows Server 2012 R2, PowerShell se ejecuta con esta directiva de ejecu-ción por defecto, lo que no era el caso en las versiones anteriores de Windows Server.Si intenta ejecutar un script descargado de Internet sin estar firmado, obtendrá el si-guiente mensaje de error.

.\Get-Script.ps1: File C:\Temp\Script.ps1 cannot be loaded.The file C:\Temp\Script.ps1 is not digitally signed.

Observación

Seguramente se pregunte ¿cómo hace PowerShell para saber que nuestro script tienesu origen en Internet? Respuesta: Gracias a los «Alternate Data Streams» que se imple-

mentan con la forma de flujos cachés desde las aplicaciones de comunicación talescomo Microsoft Outlook, Internet Explorer, Outlook Express y Windows Messenger

(consulte la sección dedicada a los Alternate Data Streams). En resumen, cuando des-carga un script desde un cliente Microsoft, se le adjunta su origen.

Unrestricted: con esta directiva todos los scripts, sea cual sea su origen, se ejecu-tan sin solicitar una firma.Esta directiva muestra aun así un aviso cuando intenta ejecutar algún script descarga-do de Internet.

PS > .\script.ps1

Security warning

Run only scripts that you trust. While scripts from the internet can

be useful, this script can potentially harm your computer. If you trust

this script, use the Unblock-File cmdlet to allow the script to run

without this warning message. Do you want to run C:\Temp\script.ps1?

[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D"):

Bypass: es la directiva menos restrictiva, y por lo tanto la menos segura. No sebloquea nada y no se muestra ningún mensaje de aviso. Es por lo tanto la directiva conel riesgo más elevado de ejecutar scripts malintencionados.Undefined: no se ha definido ninguna directiva para el ámbito actual. Si no se de-finen directivas de ejecución en ningún ámbito entonces la directiva efectiva será ladirectiva Restricted.Default: carga la directiva por defecto, a saber Restricted.

© E

dit

ions

EN

I -

All r

ights

rese

rved

378Windows PowerShell - Los fundamentos del lenguaje

PowerShell Core

Observación

Microsoft ha puesto en marcha mecanismos con el fin de intentar limitar los riesgos vin-culados a la ejecución de scripts que provengan del exterior de la empresa y por lo

tanto potencialmente peligrosos. La configuración por defecto permite alcanzar esteobjetivo pero no garantiza en ningún caso una seguridad perfecta.

3.2.2 Los ámbitos de las directivas de ejecución

PowerShell permite gestionar el ámbito de las directivas. El orden de aplicación es elsiguiente:– Ámbito Process: la directiva de ejecución solo afecta a la sesión actual (proceso

Windows PowerShell). El valor asignado al ámbito Process se almacena única-mente en memoria; por lo tanto no se conserva al cerrar la sesión de PowerShell.

– Ámbito CurrentUser: la directiva de ejecución aplicada al ámbitoCurrentUser solo afecta al usuario actual. Se almacena el tipo de directiva de ma-nera permanente dentro de la clave de registro HKEY_CURRENT_USER.

– Ámbito LocalMachine: la directiva de ejecución aplicada al ámbito LocalMa-chine afecta a todos los usuarios del equipo. Se almacena el tipo de directiva demanera permanente dentro de la clave de registro HKEY_LOCAL_MACHINE.

La directiva con prioridad 1 tiene preferencia sobre la que tenga prioridad 3. Por lo tan-to si el ámbito LocalMachine es más restrictivo que el ámbito Process, la directi-va aplicada será aun así la del ámbito Undefined en cuyo caso PowerShell aplicarála directiva del ámbito CurrentUser y después intentará aplicar la directivaLocalMachine.Recuerde que el ámbito LocalMachine es el definido por defecto cuando aplicamosuna directiva de ejecución sin precisar un ámbito particular.

3.2.3 Identificar la directiva de ejecución actual

La directiva de ejecución actual se obtiene con el comando Get-ExecutionPolicy.

Ejemplo

PS > Get-ExecutionPolicyRestricted

Con este comando, tenemos la opción -List. Gracias a ella, sabremos qué directivasse aplican en cada ámbito.

Ediciones ENI

Windows PowerShellAdministrar puestos cliente Windows

Colección Expert IT

Extracto del Libro

201

Capítulo 5

Seguridad y protección

Seguridad y protección1. La seguridad y el Firewall de Windows

Microsoft ha integrado un firewall con el Service Pack 2 de Windows XP. Sibien era más que bienvenido, rápidamente resultó poco fiable, pues era pococonfigurable. Desde Windows Vista, el firewall integrado de manera nativa seha repensado por completo y ahora es posible definir de una forma mucho másespecífica los parámetros de protección. Veremos cmdlets que nos permitiráninteractuar con el firewall.

© E

dit

ions

EN

I -

All r

ights

rese

rved

202Administrar puestos cliente Windows

Windows PowerShell

Página de configuración del Firewall de Windows

He aquí la lista de los cmdlets estudiados:

– Get-NetFirewallProfile: recuperar la configuración del firewall(perfil).

– Set-NetFirewallProfile: modificar la configuración del firewall(perfil).

– New-NetFirewallRule: crear una nueva regla.

– Set-NetFirewallRule: modificar una regla existente.

203Seguridad y protecciónCapítulo 5

1.1 Activar el Firewall de Windows

El Firewall de Windows está, por supuesto, habilitado por defecto tras unainstalación no personalizada de Windows. Sin embargo, según la política deseguridad y las soluciones implementadas en la empresa, es posible desactivarel Firewall de Windows. En caso de tener que reactivarlo, he aquí cómo hacer-lo mediante cmdlets de PowerShell.

La activación se lleva a cabo en dos etapas: la primera consiste en asegurarsede que el servicio de Firewall de Windows se ejecuta correctamente. Para ello,utilice Get-Service:

PS C:\Windows\system32> If ((Get-Service -Name MpsSvc).Status -eq

"Stopped")

>> {

>> Set-Service -Name MpsSvc -StartupType Automatic

>> Start-Service -Name MpsSvc

>> }

La segunda etapa consiste en activar el Firewall para los distintos perfiles de-seados. Para ello, utilice Set-NetFirewallProfile. Este cmdlet admite va-rios parámetros, pero veremos los correspondientes a la activación ydesactivación.

Parámetro Descripción

-AllowInboundRules <GpoBoolean> Especifica al firewall que blo-quee las conexiones entrantes.

-Enabled <GpoBoolean> Activa o desactiva el Firewall deWindows con seguridad avan-zada para el perfil especificado.

-LogAllowed Indica si los paquetes autoriza-dos deben escribirse en los logs ono.

-LogBlocked Indica si los paquetes blo-queados deben escribirse en loslogs o no.

© E

dit

ions

EN

I -

All r

ights

rese

rved

204Administrar puestos cliente Windows

Windows PowerShell

Ejemplo: activación del Firewall de Windows para todos los perfiles

PS C:\Windows\system32> Set-NetFirewallProfile -Name * -Enabled True

Existen tres perfiles (tipos de red) en el Firewall de Windows:

– Public: este perfil se utiliza en los lugares públicos, como cafés, hoteles, etc.Bloquea por defecto el conjunto de conexiones y la detección de redes.

– Private: este perfil se utiliza generalmente cuando se trabaja en una redlocal privada, como por ejemplo en casa.

– Domain: si el puesto de trabajo está asociado a un dominio de WindowsServer, entonces el perfil Domain está activo automáticamente. Este perfilse utiliza cuando el equipo está conectado a la red de una empresa.

En cada perfil es posible, a su vez, jugar con un parámetro de seguridad en lasconexiones entrantes, y un parámetro que gestiona las notificaciones.

El primer parámetro, -AllowInboundRules, permite definir qué compor-tamiento se desea en caso de producirse una conexión entrante. Puede tomarlos siguientes valores:

-LogFileName <String> Indica la ruta de acceso alarchivo para escribir los logs.

-LogMaxSizeKilobytes Especifica el tamaño máximodel archivo de log (en kilo-bytes).

-Name <String[]> Especifica uno o variosnombres de perfil de firewallpara modificar.

-NotifyOnListen <GpoBoolean> Autoriza la notificación.

Valor Descripción

True Bloquea todas las conexiones entrantes salvo aquellas queestén autorizadas mediante una regla de seguridad específica.

False Bloquea absolutamente todas las conexiones entrantes.

Parámetro Descripción

205Seguridad y protecciónCapítulo 5

El segundo parámetro, -NotifyOnListen, permite que se le notifique si elFirewall de Windows bloquea una nueva aplicación. Puede tomar lossiguientes valores:

Personalización de los parámetros del Firewall de Windows

Valor Descripción

True Se muestra una notificación por pantalla en caso de que el Firewall de Windows bloquee una conexión y se le pide decidir si autoriza o no las futuras conexiones.

False No se muestra ningún mensaje si el Firewall de Windows bloquea la conexión de alguna nueva aplicación.

© E

dit

ions

EN

I -

All r

ights

rese

rved

206Administrar puestos cliente Windows

Windows PowerShell

Ejemplo: activación del firewall para un perfil con los parámetros

En el siguiente ejemplo, Set-NetFirewallProfile activa el firewall parael perfil Public, rechaza todas las conexiones entrantes y no se muestra ningúnmensaje de advertencia cuando el firewall bloquea la conexión de alguna nue-va aplicación.

PS C:\Windows\system32> Set-NetFirewallProfile -Name Public

-Enabled True -AllowInboundRules False -NotifyOnListen False

1.2 Desactivar el Firewall de Windows

Para desactivar el Firewall de Windows, basta simplemente con detener el ser-vicio Firewall de Windows, cuyo efecto provoca que se permitan todas lasconexiones de red entrantes y salientes del puesto de trabajo:

PS C:\Windows\system32> Stop-Service -Name MpsSvc

PS C:\Windows\system32> Set-Service -Name MpsSvc -StartupType

Disabled

Si simplemente desea desactivar el firewall para un perfil en particular, puedeutilizar el cmdlet Set-NetFirewallProfile:

PS C:\Windows\system32> Set-NetFirewallProfile -Name

Public,Private -Enabled False

El ejemplo anterior desactiva el Firewall de Windows para los perfiles deconexión Public y Private.

1.3 Crear una nueva regla de seguridad

Pero la configuración del Firewall de Windows no se limita solamente a acti-varlo o desactivarlo según los perfiles de red. El modo avanzado del Firewall deWindows permite definir reglas de seguridad en función de las conexiones dered (protocolos, puertos) y también conexiones específicas de algún servicio oaplicación.