Seguridad
La seguridad: ¿para quién? ¿Por qué?
La aparición de las redes locales y de Internet ha cambiado muchas cosas en la manera de proteger su PC. Ya no basta con encadenar el disco duro a la mesa y cerrar la puerta del despacho por la noche para que no le roben o pirateen sus datos. Ahora, proteger su puesto de trabajo se ha convertido en algo esencial para no tener que remediar intrusiones o malas intenciones.
Pero entonces ¿contra quién prevenir? Pues contra todo lo que se mueve… y también los que no se mueven. En efecto, ya sean programas malintencionados, usuarios con malas intenciones, o hasta usuarios novatos, todos están considerados una amenaza. Por este motivo debe asegurar su sistema estableciendo reglas de seguridad, aplicándolas y asegurándose de que los demás hacen lo mismo.
Los riesgos vinculados al scripting
Adivinará rápidamente que lo que hace la fuerza del scripting se convierte en su debilidad. La facilidad con la que puede hacer todo, ya sea haciendo clic en un script o ejecutándolo desde la ventana de comandos, puede meterle en problemas si no presta atención.
Imagine un script de inicio de sesión que en la apertura de la sesión ¡la bloquea enseguida! Claro, es divertido entre amigos, pero en una empresa, dudamos que esto sea bueno. Todavía peor un script de una persona malintencionada o realmente novata en PowerShell (en este caso, le aconsejamos comprarle un ejemplar de este libro…) puede perfectamente bloquear cuentas de usuarios en Active Directory, formatear el disco, reiniciar el sistema en un bucle infinito… Lo ha entendido, un script puede hacer de todo. Aunque a día de hoy se notifica al usuario con alertas para prevenirle de la ejecución de un script, estas no son capaces de determinar si un script es nocivo para el correcto funcionamiento del sistema.
Los riesgos vinculados al scripting se resumen a una historia de compromisos: o bien impide 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 sistema a PowerShell, teniendo cuidado de tomar las precauciones que se imponen.
Pero no se deje desanimar ya que aunque...
Optimizar la seguridad de PowerShell
1. La seguridad de PowerShell por defecto
Lo ha entendido, la seguridad es una área muy importante, sobre todo en el dominio del scripting. Por este motivo los creadores de PowerShell han incluido dos reglas de seguridad 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 notas (o Notepad). Este procedimiento permite evitar ejecutar automáticamente scripts potencialmente 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 no bloquear la ejecución de un script cuando este está abierto con el editor. Observará sin embargo que la edición (clic con el botón derecho + Modificar) de archivos .ps1 está asociada al editor ISE.
Este tipo de seguridad no existía con los scripts VBS cuya apertura estaba directamente asociada a Windows Script Host.
Una directiva de ejecución restringida
La segunda barrera de seguridad es la aplicación de la directiva de ejecución Restricted por defecto para los puestos clientes y RemoteSigned por defecto para los servidores (desde Windows Server 2012 R2).
La directiva Restricted es la más restrictiva. Es decir que bloquea sistemáticamente la 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 de ejecución con el comando Set-ExecutionPolicy <modo de ejecución>. Pero para ello debe ser administrador del equipo.
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.
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 contra de 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 determinados scripts. Podrá llegar a cambiar en función de la directiva que desee aplicar.
a. Las diferentes directivas...
Firma de scripts
1. Las firmas digitales
Una firma digital es un «proceso» que permite identificar al firmante y que garantiza la integridad del documento. Las firmas digitales, llamadas también firmas electrónicas, se usan en PowerShell para gestionar la ejecución de scripts según la directiva de ejecución elegida.
Desde un punto de vista conceptual, una firma digital corresponde generalmente al cifrado, con la ayuda de una clave privada, de una forma abreviada del mensaje llamada «huella». La huella de un mensaje es el resultado obtenido después de aplicar una función de hash al contenido del documento.
Al otro lado de la cadena, el destinatario se asegura de que los datos no han sido modificados durante la transmisión efectuando una comparación entre la huella que acompaña al documento descifrado gracias a la clave pública y la huella que él mismo ha calculado. Si ambas huellas son idénticas entonces significa que los datos son íntegros.
2. Los certificados
Un certificado es indisociable de una clave pública. Es el elemento que va a permitir asociar la clave a su propietario. Es decir que cuando desciframos una firma con la clave pública, no es necesario verificar que esta clave es del firmante. Al igual que con un documento oficial, un certificado contiene información acerca de la identidad del propietario. Añadir una firma a un script significa que debe estar en posesión de un certificado electrónico de firma, que permite identificar de manera segura a la persona que firma el script. Este certificado se puede obtener de diferentes maneras: o bien decide comprar un certificado de firma a una autoridad de certificación reconocida, o bien crea su propio certificado (certificado «auto firmado»).
a. Comprar un certificado
Para comprar un certificado, debe pasar por un organismo de certificación (Certificate Authority o CA) que entrega certificados de clase 1, 2 o 3, definidos según un uso y un nivel de protección de los datos. Estos certificados están también asociados a un tiempo de vida y a cierta garantía en función del precio que puede ir desde algunas decenas a varias centenas de euros. Algunos organismos se reconocen de manera nativa en Windows, lo que permite desplegar scripts firmados sin ninguna manipulación....
Gestionar las directivas de ejecución de PowerShell mediante las directivas de grupo
Controlar la directiva de ejecución de PowerShell en el seno de un grupo de equipos no es una tarea fácil, sobre todo cuando se trata de un parque de varias decenas de puestos informáticos. Si en el pasado era necesario instalar un modelo de administración (archivo ADM, Administration Model) de manera que se pudiese aplicar la directiva de ejecución mediante directivas de grupo (GPO en inglés, Group Policy Object), hoy en día no resulta necesario. La aplicación de una directiva de seguridad mediante GPO es en realidad muy sencilla de implementar.
Ejecute GPMC.msc.
Seleccione la OU (unidad organizativa) correspondiente y haga clic con el botón derecho para seleccionar Create a GPO in this domain, and Link it here….
Defina un nombre para la nueva GPO.
Haga clic con el botón derecho y seleccione Edit en la GPO que acabamos de crear.
Vaya en la jerarquía de la izquierda a Computer Configuration - Policies - Administrative Templates - Windows Components - Windows PowerShell.
Haga doble clic en el parámetro Turn on Script Execution y seleccione la directiva de ejecución deseada.
Cierre el editor de GPO.
La directiva de ejecución está ahora desplegada en todos los equipos que pertenezcan a la unidad organizativa correspondiente.
Para aplicar...