Seguridad

Bloqueo de la aplicación mediante directivas de restricción de software

Chris Corio and Durga Prasad Sayana

 

De un vistazo:

  • Cómo funcionan las directivas de restricción de software
  • Inventario de las aplicaciones de su entorno
  • Creación y aplicación de directivas

Cuando los profesionales de TI tratan de reducir el costo total de propiedad, o TCO, de sus equipos de escritorio, existen dos estrategias clave que se suelen llevar a cabo. La primera es obtener las cuentas

de usuarios de escritorio del grupo Administradores. La segunda es limitar las aplicaciones que pueden ejecutar los usuarios. Enfocar estos problemas en un entorno empresarial puede suponer un reto, pero Windows Vista® ofrece algunas tecnologías que pueden ayudarle a conseguir sus objetivos.

Windows Vista, gracias a su característica Control de cuentas de usuario (UAC), ha realizado un gran paso para ayudar a los profesionales de TI a mover los usuarios de la empresa al grupo Usuarios (usuarios estándar). UAC cambió el contexto predeterminado de seguridad para que, además de los administradores, los usuarios puedan usar todas las aplicaciones. Esta migración al grupo Usuarios es una tarea extraordinaria, pero conforme el sector se vaya ajustando a este nuevo paradigma, esta tarea será cada vez más sencilla.

Tras analizar los retos que supone mover los usuarios al grupo Usuarios, o también a veces durante el proceso, muchos administradores catalogan las aplicaciones que los usuarios necesitan ejecutar y tienen en cuenta los pasos necesarios para permitir únicamente el uso de estas aplicaciones. La característica de la directiva de restricción de software está diseñada para ayudar a los profesionales de TI a hacerlo.

Tan sólo se deben especificar las aplicaciones que se pueden ejecutar y, a continuación, implementar la directiva mediante la directiva de grupo. La aplicación de dicha directiva a través de toda la empresa puede reducir el TCO, ya que este bloqueo limitará los problemas relacionados con las aplicaciones no admitidas. Además, puede usar las directivas de restricción de software de formas interesantes y muy radicales, tal como se indica en la barra lateral "Directiva básica de restricción de software".

Cómo funciona la directiva de restricción de software

La directiva de restricción de software pretende controlar exactamente qué código puede ejecutar un usuario en un equipo con Windows Vista. El administrador crea una directiva que defina lo que puede (o no puede) ejecutarse en su entorno. A continuación, esta directiva se evalúa en el lugar y el momento en que el código se pueda ejecutar. Puede ser durante la creación de un proceso, al llamar a ShellExecute y al ejecutar un script. (En seguida nos centraremos en este aspecto.)

Si se establece que puede ejecutarse una aplicación, se iniciará. No obstante, si se establece que no se puede ejecutar, se bloqueará y se le notificará al usuario. Por ejemplo, si intenta ejecutar el juego Solitario del menú Inicio y no estaba habilitado, aparecerá un cuadro de diálogo similar al que aparece en la figura 1.

Figura 1 Si la aplicación está bloqueada aparece un cuadro de diálogo

Figura 1** Si la aplicación está bloqueada aparece un cuadro de diálogo **(Hacer clic en la imagen para ampliarla)

La interfaz de usuario que define una directiva de restricción de software se expone en el editor de objetos de directiva de grupo (GPOE) y es donde se crea la directiva de bloqueo. Existe una serie de métodos para definir el código que se puede ejecutar. Una vez que la directiva está completa y se ha probado, puede implementarla.

Definición de la directiva de restricción de software

La primera decisión que debe tomar y que afectará en gran medida al funcionamiento de la directiva de restricción de software en su entorno, es la elección de un tipo de regla predeterminada. Las directivas de restricción de software se pueden implementar de dos formas: lista de permitidos o Lista de denegación. Básicamente, puede crear una directiva en la que se describen las aplicaciones que se pueden ejecutar en su entorno o en la que se definen las que no se pueden ejecutar.

En el modo Lista de permitidos, la regla predeterminada de la directiva es que aparezca Restringido y se bloquean las aplicaciones que establezca que no se ejecuten de forma explícita. En el modo Lista de denegación, la regla predeterminada es que aparezca Sin restricciones y se restringen sólo las aplicaciones incluidas en una lista de forma explícita.

Como puede suponer, el modo Lista de denegación es un enfoque poco realista si lo que se pretende es una amplia reducción de TCO y las ventajas de seguridad procedentes del bloqueo de una aplicación. La creación y el mantenimiento de una lista extensa que bloquee el malware y otras aplicaciones problemáticas puede ser casi irrealizable. Por lo tanto, le recomendamos que implemente dicha directiva de restricción de software en el modo Lista de permitidos, lo que significa que la regla predeterminada que aparece es Restringido.

Inventario de las aplicaciones de su entorno

Si desea diseñar una directiva en la que se especifiquen las aplicaciones que se pueden ejecutar, deberá establecer de forma precisa qué aplicaciones necesitan los usuarios. La característica de la directiva de restricción de software le ofrece una característica de registro avanzada con una directiva muy sencilla para comprender exactamente qué aplicaciones que se ejecutan en su entorno.

Implemente en un conjunto de equipos de muestra de su entorno la directiva de restricción de software con el conjunto de reglas predeterminadas establecido como Sin restricciones y asegúrese de quitar las demás reglas adicionales. La idea es habilitar la directiva de restricción de software sin permitir que se restrinjan las aplicaciones. En lugar de eso, lo usará para supervisar las aplicaciones que se ejecutan.

A continuación, cree el siguiente valor del registro para habilitar la característica de registro avanzada y establecer la ruta de acceso en la que se debe escribir el archivo de registro:

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>

Al ejecutar una aplicación y evaluar la directiva de restricción de software (se evalúa aunque permita que todo se ejecute), se escribe una entrada en el archivo de registro.

Cada entrada de registro incluye la persona que llama a la directiva de restricción de software y el identificador de proceso (PID) de la llamada, el objetivo evaluado, el tipo de regla de la directiva de restricción de software seleccionada y un identificador para la regla. Se trata de una entrada escrita de muestra cuando un usuario hace doble clic en notepad.exe:

explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}

Este archivo de registro representa todas las partes de código ejecutable que comprobará la directiva de restricción de software cuando está habilitada y establecida para bloquear las aplicaciones. Esto significa que debe decidir si desea considerar todas las entradas del archivo de registro de la Lista de permitidos. Tenga en cuenta que se comprobarán varios binarios de Windows® necesarios para que funcione el sistema.

La técnica de registro que describimos en este artículo pretende indicar de manera clara con qué aplicaciones de su entorno se encontrará la directiva de restricción de software. Aunque no es la única manera de llevar a cabo esta tarea.

El recopilador de inventario que se incluye en el kit de herramientas de compatibilidad de aplicaciones 5.0 de Microsoft® permite realizar un inventario de las aplicaciones que se usan en su entorno. Esta herramienta ofrece diferentes formas de detectar las aplicaciones que se instalan en su entorno, además de consolidar los resultados en una base de datos central.

Creación de reglas adicionales

Una vez que tenga la lista de aplicaciones que se pueden ejecutar en su entorno, podrá crear las reglas reales que permitirán ejecutarlas. La característica de la directiva de restricción de software puede identificar la directiva de dos maneras: una, basada en las propiedades de cifrado de una aplicación (como su hash), mientras que la otra define una ruta de acceso de confianza o una carpeta en la que se incluirán las aplicaciones de confianza.

En la figura 2 se muestra dónde debe agregar las reglas para permitir que las aplicaciones se ejecuten en el nodo de directivas de restricción de software del GPOE (gpedit.msc). La forma más sencilla de definir las aplicaciones en su entorno es crear una regla hash para cada binario sencillo que encuentre durante la fase de registro.

Figura 2 Uso de gpedit.msc para crear directivas de restricción de software

Figura 2** Uso de gpedit.msc para crear directivas de restricción de software **(Hacer clic en la imagen para ampliarla)

Ya que el hash es un valor único devuelto para un conjunto de bits particular, cada binario de su directiva tendrá un hash diferente. Este enfoque es especialmente seguro y sólo permitirá ejecutar binarios específicos de su directiva.

Por supuesto, hay algunos inconvenientes a este enfoque. Por ejemplo, su entorno puede tener varios miles de binarios. Puede ser difícil crear todas estas reglas en la interfaz de usuario de la directiva de restricción de software, y a medida que el número de reglas aumenta, el rendimiento puede quedar afectado. Además, cada actualización de aplicaciones de su entorno requerirá la implementación de una o varias reglas hash nuevas. La actualización de una directiva tan importante al actualizar las aplicaciones puede ser una gran carga.

Afortunadamente, esta carga se puede evitar, ya que hay otras dos maneras diferentes de identificar las reglas que facilitan el uso de las directivas de restricción de software en su entorno. Al adentrarse todavía más en la seguridad de cifrado, puede crear una regla que le permitirá ejecutar cualquier binario firmado por un certificado particular.

Esto permite simplificar el mantenimiento de la lista de directivas ya que, cuando se actualiza una aplicación, los nuevos binarios los firmará el mismo certificado que los anteriores. Sin embargo, si no desea que una versión anterior del binario se ejecute en su entorno, deberá agregar una regla de hash Restringido para no permitir el archivo.

De forma predeterminada, la evaluación de las reglas de certificado está deshabilitada para las directivas de restricción de software. Existen dos razones por las que se tuvo que optar por esta situación.

En primer lugar, las reglas de certificado de las directivas de restricción de software se definen por lo que hay en el almacén de los editores de confianza del sistema. Ya que se usa el almacén de los editores de confianza para propósitos diferentes a las reglas de la directiva de restricción de software, se necesita más tiempo y consideración cuando se usa para la característica de las directivas de restricción de software.

La segunda razón es que para determinar si la firma de un archivo es válida, debe tomar un hash del archivo y compararlo con la información de la firma. Usar un hash de un archivo es una operación carísima: el disco debe leer todo el archivo y procesarlo para calcular este hash.

Para habilitar las reglas de certificado, desplácese al nodo Directivas de restricción de software y seleccione el objeto de aplicación en el panel de resultados. A continuación, haga doble clic en él para abrir el cuadro de diálogo de propiedades y seleccione la opción de radio de las reglas del certificado de aplicación.

Otra forma de identificar del código es mediante la ruta de acceso del código en el equipo local. Se trata de una técnica efectiva y eficaz, aunque tiene un inconveniente: debe asegurarse de que la configuración de seguridad está establecida correctamente en la carpeta.

Si agrega una regla de ruta de acceso particular y permite a los usuarios escribir archivos en ella (en el escritorio, por ejemplo), podrían ejecutar lo que deseen siempre que coloquen el archivo ejecutable en esa carpeta. Sin embargo, si los usuarios no están en el grupo Administradores, no podrán modificar los directorios Archivos de programa o Windows. Esto significa que si todas sus aplicaciones están en el directorio Archivos de programa y sus usuarios no son administradores, deberá tener en cuenta las reglas de ruta de acceso para conseguir una directiva muy sencilla y eficaz.

Las reglas de la ruta de acceso ofrecen otras características que las hacen más apropiadas para algunos entornos. Admite caracteres comodín y le permite usar variables del entorno para facilitar la definición de reglas portátiles en su entorno; después de todo, %systemdrive% puede no ser c:\ para todos los usuarios.

En cuanto al rendimiento y el mantenimiento, probablemente ésta sea la manera más sencilla de identificar el código. Debe considerar las reglas de la ruta de acceso, aunque hay que tener en cuenta algunos aspectos de seguridad adicionales.

Reglas Zona de red

La directiva de restricción de software incluye un tipo de regla denominado reglas Zona de red, aunque ha quedado obsoleto. La intención original de estas reglas se basaba en la idea de que el origen del código ejecutable particular se podía identificar y era de confianza, y, por lo tanto, se podría ejecutar el código. Desafortunadamente, es algo demasiado difícil de conseguir y, como consecuencia, no funciona demasiado bien. Actualmente, este tipo de regla no se aplica en la mayoría de lugares de los puntos de entrada de la directiva de restricción de software.

En los casos en que la mayoría de las aplicaciones se instalan en el directorio %Archivos de programa% pero hay otros archivos ejecutables que se instalan en otro lugar y se firman mediante un certificado específico, puede tener sentido usar reglas de diferentes tipos. Con algunas reglas hash y un par de reglas de ruta de acceso, puede comprobar que ha encontrado la directiva adecuada.

Tan sólo tenga presente que las reglas se procesan siguiendo un orden (tal como se muestra en la figura 3). Las reglas de certificado son las más específicas, las reglas hash son las siguientes, a continuación, están las reglas de ruta de acceso y, finalmente, las reglas de ruta de acceso con caracteres comodín. De esta forma, si una regla hash y una regla de ruta de acceso identifican un código, el nivel de seguridad de la regla hash tendrá prioridad.

Figura 3 Orden de procesamiento de reglas

Figura 3** Orden de procesamiento de reglas **(Hacer clic en la imagen para ampliarla)

Aplicación de directivas

La característica de directivas de restricción de software ofrece una variedad de cobertura protegida en el sistema. La idea es que cualquier ubicación desde la que se puede ejecutar el código se debe integrar en la directiva de restricción de software y, por su parte, comprobar la directiva para saber si se puede ejecutar el código ejecutable.

Aunque hay muchos lugares que comprueban la directiva de restricción de software, el punto de entrada más directo es CreateProcess. Mediante CreateProcess, se comprueba la directiva para determinar si el binario que representa la aplicación se puede ejecutar. La comprobación de la directiva se realiza a través de la API SaferIdentifyLevel, que se documenta públicamente. El proceso general se ilustra en la figura 4. (Enseguida nos centraremos en SaferIdentifyLevel.)

Figura 4 Uso de SaferIdentifyLevel para determinar si un binario se puede ejecutar

Figura 4** Uso de SaferIdentifyLevel para determinar si un binario se puede ejecutar **(Hacer clic en la imagen para ampliarla)

Después de CreateProcess, la API que se suele usar con más frecuencia en el lugar en que se aplica la directiva de restricción de software es ShellExecute. Se trata de la API a la que se llama cuando el usuario hace clic en una aplicación del menú Inicio o doble clic en algún punto del escritorio.

Se puede llamar a ShellExecute mediante una gran variedad de formatos de archivo. En el caso de los archivos .txt, al llamar a ShellExecute en el archivo no se produce la ejecución del archivo (por supuesto, técnicamente, el archivo se abre). Por este motivo, la directiva de restricción de software contiene una lista de tipos de archivo ejecutables de manera que se pueden controlar los tipos de archivos que se comprueban al llamar a ShellExecute. Esta lista de tipos de archivos ejecutables se puede personalizar en la interfaz de usuario de la directiva de restricción de software.

Además de CreateProcess y ShellExecute, existen otros dos puntos clave de integración: LoadLibrary y hosts de scripts. Obviamente, LoadLibrary es un lugar importante para comprobar el código ejecutable, aunque presenta algunas restricciones especiales.

La mayoría de las aplicaciones tienen un archivo ejecutable y varias DLL cargadas. En el sistema se suelen ejecutar muchas aplicaciones. Esto significa que LoadLibrary necesita comprobar la directiva en muchas ocasiones. En función de su directiva para la identificación de código, podría ser un punto de entrada cuya aplicación resultaría muy costosa; suponga que debe comprobar el hash de todos los archivos DLL cargados en el sistema, lo que incluye usar un algoritmo hash en el binario y, a continuación, compararlo con una lista de miles de hash.

Esta funcionalidad está deshabilitada de forma predeterminada, pero se puede habilitar manualmente. Para ello, navegue al nodo Directivas de restricción de software en gpedit.msc y haga doble clic en Cumplimiento. A continuación, seleccione el botón de radio Todos de los archivos de software.

Tal como hemos mencionado, la directiva de restricción de software está integrada en el sistema con la mayoría de hosts de scripts. Se incluye cmd, VBScript, Cscript y JScript®. Estos puntos de entrada, entre otros, usan la API principal de aplicación de la directiva de restricción de software: SaferIdentifyLevel.

La API SaferIdentifyLevel establece si un archivo ejecutable específico se puede ejecutar mediante la información de identificación de las directivas de restricción de software pertinentes. Se trata de una API documentada públicamente. Los hosts de scripts de terceros y entornos ejecutables pueden y deben usarla para integrarse en la directiva de restricción de software, de forma que ésta pueda determinar si se puede ejecutar una parte del código ejecutable.

Ejecución como usuario estándar

Una característica menos conocida de la directiva de restricción de software es su capacidad para filtrar los privilegios de determinadas aplicaciones al iniciarlas. Esta funcionalidad se introdujo en Windows XP, pero no se expuso en la interfaz de usuario de la directiva de restricción de software hasta Windows Vista.

De esta forma, fue la precursora del UAC de Windows Vista ya que lo podía usar para ejecutar una aplicación como usuario estándar aunque el usuario fuera miembro del grupo Administradores. Esto es lo que sucede al crear una regla y establecer el nivel de seguridad como Usuario normal en la interfaz de usuario Reglas adicionales.

Tanto la funcionalidad de filtro de token como las reglas de usuario normal de las directivas de restricción de software de UAC aprovechan una API subyacente que implementa el mismo comportamiento que la API CreateRestrictedToken. Sin embargo, las diferencias de arquitectura generales entre las tecnologías son muy significativas. Sin embargo, UAC se diferencia de la directiva de restricción de software de un par de aspectos clave.

En primer lugar, en Windows Vista con el UAC habilitado, todas las aplicaciones se inician con un token de seguridad similar a un miembro del grupo Usuarios de forma predeterminada, aunque el usuario sea un administrador. Esto es factible con la directiva de restricción de software, pero no existe ningún medio para iniciar una aplicación con el token real de administrador del usuario, por ejemplo, cuando el usuario debe instalar una aplicación. El cambio en el contexto de seguridad predeterminado y la facilidad de acceso a un token de administrador completo del usuario son ventajas clave del UAC.

La segunda diferencia es que, en el caso de archivos ejecutables, el código en sí expresa el nivel de privilegio necesario para que funcione. Se trata de una distinción clave porque los proveedores de software independientes (ISV) y los desarrolladores comprenden las necesidades del código. Por ejemplo, si una aplicación del panel de control necesita editar alguna opción que requiera el privilegio de administrador, puede especificarlo en su manifiesto. De esta forma, el ISV podrá describir los privilegios que necesita una aplicación en lugar de imponer un determinado nivel de privilegio sin tener medios disponibles para cambiarlo.

Por ahora, debe evitar usar las reglas del usuario normal a menos que realmente comprenda su funcionamiento. UAC es una excelente manera de ayudar a sacar a sus usuarios de escritorio del grupo Administradores y debe dejar el UAC tan sólo en su entorno empresarial.

Directivas de restricción de software en el uso actual

Hay una serie de partes móviles que debe tener en cuenta al usar la directiva de restricción de software. Aunque no es como se imagina y, de hecho, puede estar usando todavía las directivas de restricción de software actuales sin darse cuenta de ello. Por ejemplo, si ejecuta la característica de control parental en un sistema de Windows Vista, está usando las directivas de restricción de software para controlar la ejecución de las aplicaciones.

La directiva de restricción de software fue un desarrollo tecnológico importante al introducirla por primera vez en Windows XP. Sin embargo, es ahora cuando el bloqueo de aplicaciones está empezando a acaparar la atención de los profesionales de TI.

La característica de la directiva de restricción de software de Windows Vista tiene algunos defectos que aún hay que pulir, pero está claro que los administradores desean un mayor control sobre lo que se ejecuta en sus entornos. Afortunadamente para todos nosotros, esta tecnología continuará evolucionando y facilitando a los profesionales de TI la administración de sus sistemas, además de la reducción del costo de ejecución de un entorno de Microsoft Windows.

Directiva básica de restricción de software

Una aplicación de la directiva de restricción de software es la creación de una directiva que bloquee Windows en una pantalla completa. Microsoft genera un juego de herramientas, denominado SteadyState™, para crear esta pantalla completa. No obstante, si sólo está interesado en bloquear las aplicaciones que se pueden ejecutar, podrá conseguirlo con más facilidad.

Para habilitar el conjunto de aplicaciones mínimo necesario para iniciar sesión en Windows Vista, cree una directiva que permita ejecutar logonui.exe y userinit.exe desde %windir%\system32. Probablemente, la mayoría de los usuarios también necesiten ejecutar las siguientes aplicaciones permitidas:

dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....

Si desea usar el shell predeterminado de Windows, tal vez considere oportuno agregar también %windir%\explorer.exe.

Otra posibilidad sería arrancarlo directamente en una aplicación, como Internet Explorer®. En ese caso, sería necesario incluir en la lista iexplore.exe en lugar de explorer.exe.

Otro aspecto a tener en cuenta de esta directiva básica es que sus usuarios no deben estar en el grupo Administradores. Este punto es importante para que no puedan eludir la directiva. Sin embargo, ya que sólo pueden ejecutar un conjunto de aplicaciones muy básico y no pueden usar los privilegios de un administrador, los usuarios no dispondrán de los privilegios para instalar aplicaciones ni para ocuparse del mantenimiento del sistema.

Deberá hacerlo de alguna forma en estos equipos. Si trata de actualizar y mantener estos equipos al iniciar sesión de forma local con una cuenta de administrador, debe seleccionar el botón de radio que aplica la directiva de restricción de software a todos usuarios excepto a los administradores locales. La directiva también debe incluir consent.exe y cmd.exe. Esto permitirá al administrador iniciar cualquier opción de administración desde un mensaje cmd de administrador.

Tenga en cuenta que el UAC limita los privilegios del token de seguridad del usuario de forma predeterminada para que parezca que el token no es un miembro del grupo Administradores. Aunque establezca la configuración anterior para no aplicar la directiva a los administradores, se aplicará a los usuarios de todas formas. Solamente al pasar por la elevación del UAC, el administrador puede obtener realmente los privilegios completos de administrador y no se aplicará la directiva de restricción de software.

Chris CorioChris Corio fue miembro del equipo de seguridad de Windows en Microsoft durante más de cinco años. En Microsoft, se centró principalmente en las tecnologías de seguridad de las aplicaciones y en las tecnologías de administración para proteger Windows. Puede ponerse en contacto con Chris en winsecurity@chriscorio.com.

Durga Prasad SayanaDurga Prasad Sayana es ingeniero y realiza pruebas de diseño de software en el equipo de seguridad principal de Windows. Sus intereses principales son las tecnologías de seguridad y las pruebas de software. Puede ponerse en contacto con Durga en durgas@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.