Applocker vs Política de restricción de software

El objetivo es evitar que los usuarios ejecuten programas no deseados en un servidor de terminal.

He leído muchos artículos de Microsoft y otros que dicen que la nueva función Applocker es 100% mejor que la antigua Política de restricción de software y se recomienda como reemplazo de esta última.

No estoy seguro de comprender las ventajas reales de Applocker aparte de la ejecución en modo kernel. La mayoría de sus funcionalidades se pueden reproducir con la Política de restricción de software.

Al mismo tiempo, tiene una GRAN desventaja que lo hace bastante inútil: no es extensible y no puede agregar extensiones de archivo personalizadas que desee restringir.

¿Cuáles son las ventajas de Applocker sobre SRP y qué recomendaría para el control del software?

La Política de restricción de software está en desuso por parte de Microsoft ( technet afirma que efectivamente SRP no es compatible ), ya que Windows 7 Enterprise / Ultimate introdujo AppLocker.

En la práctica, SRP tiene ciertas dificultades, tanto para falsos negativos como para falsos positivos. AppLocker tiene la ventaja de que todavía se mantiene y se mantiene de forma activa. Si AppLocker es una opción, entonces podría ser la más barata, después de tener en cuenta su tiempo y los riesgos asumidos. También es posible que haya una alternativa de terceros adecuada (pero esta pregunta no incluyó esa opción :).

Esperemos que obtenga una comprensión perfecta de las trampas de SRP antes de caer en cualquiera de ellas </sarcasm>. Algunos de ellos se describen en un buen artículo de seguridad de Vadims Podāns .

Problemas conocidos

1. Por defecto, \Windowsse permite la ejecución desde la carpeta. Los usuarios pueden escribir algunas subcarpetas. Applocker es el mismo, pero al menos la documentación oficial menciona esta limitación .

   EDITAR: "Para enumerar todas las carpetas con acceso de escritura de los usuarios , puede usar, por ejemplo, la utilidad AccessEnum del paquete Sysinternals". (o AccessChk ).

   Técnicamente, la documentación también le advierte que no anule las reglas predeterminadas . EDITAR: Un documento de la NSA proporciona 16 ejemplos de carpetas para incluir en la lista negra con SRP , aunque las reglas de ruta de registro usan barras invertidas incorrectamente, por lo que deben corregirse (ver el punto en las rutas de registro a continuación) y advierte sobre una entrada común de lista negra demasiado amplia.

   La pregunta obvia es por qué no incluimos cuidadosamente rutas blancas en la lista inferior \Windows. (Incluyendo el \Windows\*.exelegado System32\*.exe, etc.). No noté ninguna respuesta a esto en ninguna parte :(.

2. Utilizando variables de entorno como %systemroot%, los usuarios pueden pasar por alto SRP borrando la variable de entorno. EDITAR: no se utilizan en los valores predeterminados sugeridos. Sin embargo, pueden ser tentadores de usar. Esta pistola está arreglada en AppLocker, porque nunca analiza las variables de entorno.

3. Los valores predeterminados sugeridos omiten permitir los dos diferentes \Program Filesutilizados en las instalaciones modernas de 64 bits. Al resolver esto utilizando las "rutas de registro" más seguras, hay informes de negativas falsas en situaciones aleatorias, que podrían perderse fácilmente en las pruebas. por ejemplo, vea los comentarios sobre el tutorial de SpiceWorks SRP . EDITAR: Esto tiene que ver con aplicaciones de 32 bits que leen rutas relevantes desde el Nodo WOW6432 del registro: la resolución es agregar ambas rutas a SRP para permitir que todos los programas funcionen en máquinas de 32 bits y 64 bits como Sin restricción, ya sea que se inicie desde Un proceso de host x64 o x86:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. Las extensiones predeterminadas no permiten prohibir los scripts de PowerShell (* .PS1) compatibles con Windows . (Ver video ). Y APPX también ... también según la tabla de comparación de Microsoft, SRP no puede administrar "aplicaciones empaquetadas" en Windows 8, no tengo idea de lo que esto significa.
5. Reglas de ruta de registro no debe tener barras inmediatamente después del último signo de porcentaje (a pesar de estar incluido en la propia Microsoft incorporado reglas para XP / Server 2003) y las barras invertidas deben ser reemplazados por forwardslashes con el fin de que la regla de trabajo ( 1 / 2 / 3 )
6. De las fuentes que encontré para SRP, ninguna reunió la lista completa arriba para usted. Y solo descubrí el artículo de Vadims Podāns por accidente. ¿Qué más está acechando por ahí?
7. Muchas fuentes recomiendan simplemente eliminar los archivos LNK de la lista. (¡¿Y atajos web para evitar romper favoritos ?!). De manera inquietante, ninguna fuente parece discutir las vulnerabilidades de LNK ... o hacer que los intérpretes de script ejecuten archivos con una extensión inesperada, por ejemplowscript /e ... o tal vez rellenen suficiente código shell en un parámetro de script en línea ... etc.
8. Si intenta comprometerse permitiendo archivos LNK en el escritorio y deja a los usuarios con acceso de escritura al escritorio, ahora pueden omitir su política por completo. Sugerencia encantadora de Vadims Podāns nuevamente. Tenga en cuenta que la explicación se aplica al uso de cualquier extensión en una regla de ruta. Microsoft presenta varios ejemplos de esto *.Extension, incluidos , sin advertencia. Por lo tanto, no puede confiar en la documentación oficial , y parece poco probable que se solucione ahora.
9. [Posible desventaja de AppLocker]. Vadims Podāns informa que las entradas SRP que utilizan unidades asignadas no funcionan. La ruta UNC debe usarse en su lugar. ¿Tal vez se aplicarían para acceder a través de una unidad asignada? No es 100% claro. Aparentemente, AppLocker era diferente: tampoco funcionaba con :(. "¡Por razones desconocidas, las rutas UNC no funcionan en Applocker! Esto significa que si su aplicación está instalada en la red, debe crear reglas hash o de editor ".

Enfoque pragmático

La lista blanca de software es potencialmente una defensa muy poderosa. Si nos volvemos cínicos: esta es exactamente la razón por la cual Microsoft desprecia las versiones de menor precio e inventa las más complejas.

Quizás no haya otra opción disponible (incluye soluciones de terceros). Entonces, un enfoque pragmático sería intentar configurar SRP de la manera más simple posible. Trátelo como una capa adicional de defensa, con agujeros conocidos. Coincidiendo con las trampas anteriores:

1. Comience con las reglas predeterminadas (de la era anterior a Win7 :).
2. Prefiere no usar variables de entorno, por ejemplo %systemroot%.
3. Agregue reglas para asegurarse de que ambos \Program Files\directorios estén permitidos en las máquinas modernas de 64 bits. Las "rutas de registro" adicionales que necesitará agregar \Program Files\en las computadoras de 64 bits son %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%y %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
4. Al añadir a las reglas de ruta de registro, dejar de lado cualquier barra invertida inmediatamente después del signo de porcentaje, y sustituir las barras invertidas adicionales \con forwardslashes /(por ejemplo %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. Agregue PS1 a la lista de extensiones controladas.
6. Comprenda que una configuración SRP manejable no es segura contra un usuario decidido a vencerla. El objetivo es ayudar / alentar a los usuarios a trabajar dentro de la política, para protegerlos contra ataques como "descargas automáticas".
7. Permitir archivos LNK. (Preferiblemente eliminándolo de la lista de extensiones, no a través de alguna regla de ruta).
8. Véase más arriba :).
9. Asegúrese de que su carpeta de secuencia de comandos de inicio de sesión esté permitida. El documento de la NSA sugiere agregar \\%USERDNSDOMAIN%\Sysvol\. (Ver punto # 2, suspiro, luego ver punto # 6).

Estoy de acuerdo en que SRP tiene algunas características adicionales de las que AppLocker realmente podría beneficiarse.

Dicho esto, veo los grandes beneficios de AppLocker (como se documenta en esta comparación ) como:

• Las reglas de AppLocker pueden dirigirse a un usuario específico o a un grupo de usuarios, mientras que SRP se aplica en toda la computadora.
• AppLocker admite el modo de auditoría para que las reglas se puedan probar en producción antes de aplicarlas. SRP no tiene un modo de solo registro equivalente.

La mayor ventaja para mí es la capacidad de incluir en la lista blanca ejecutables firmados por el editor. Eche un vistazo a este http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx

No hay beneficios de AppLocker, las mentiras descaradas publicadas por Microsoft: 1. Los GPO con reglas MÁS SEGURAS se pueden adjuntar a usuarios y grupos de usuarios; 2. Windows Vista introdujo múltiples GPO locales que logran el mismo resultado sin un controlador de dominio; 3. el modo de auditoría está disponible a través de la función de registro extendido sin aplicación.

Yo uso Applocker dentro de mi empresa. La estrategia que utilizamos es: negar todo como referencia (de hecho: el Bloqueador de aplicaciones predeterminado) y luego hacer lo que se sugirió: hacer una regla que permita solo aplicaciones firmadas (office, adobe, wintools, ax, etc.). La mayoría, tal vez todo el malware es software no firmado, así que no se ejecutará. Apenas es mantenimiento. Solo tenía que permitir 3 aplicaciones heredadas adicionales.

Además, no puedo confirmar que uno no pueda usar rutas UNC. En algunas reglas adicionales de denegación de seguridad, uso con éxito la ruta UNC. La trampa está en usar variables de entorno: no funcionan para Applocker. Use * comodines. Lo uso en Windows 2008 R2 y Windows 2012 R2.

Me gusta mucho: apenas hay una caída en el rendimiento. Como dice la documentación: Applocker se basa en el Servicio de identidad de la aplicación (asegúrese de que se inicie automáticamente).