View
29
Download
0
Category
Preview:
Citation preview
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.
Recommended