Si solo los binarios apropiados en un servidor estuvieran en la lista blanca y todos los demás fueran negados de tener la capacidad de ejecutarse, ¿qué problemas de seguridad se resolverían?

Estoy de acuerdo con Chris Brenton, hasta donde llega. El problema no es realmente con los binarios, ellos mismos. El problema es que para que el servidor funcione en todos los binarios determinados se debe permitir que se ejecuten, lo que representa un riesgo para la seguridad.
La mejor explicación de los problemas es de la Agencia de Seguridad Nacional y el desarrollo de SELinux. http://www.nsa.gov/research/seli … y http://www.nsa.gov/research/_fil …

Un ejemplo sería, cada servidor * nix va a ejecutar un shell. Puedo destruir totalmente un servidor desde el shell, y probablemente sacar todos los datos de él con solo tener un shell. Para Windows, suponga que es el símbolo del sistema.

Una vez realizada la ruta SELinux, descubrí que realmente hay muy pocos archivos binarios que se pueden deshabilitar y, por lo general, son compiladores y programas necesarios como un paso intermedio para instalar programas.

El enfoque de la lista blanca funciona bien para un producto de consumo, Windows 7 y Download.com, por ejemplo, para que sepa exactamente lo que está pasando en su PC y esté seguro de que alguien se ha tomado el tiempo de buscar malware. pero realmente no hace mucho para un servidor, donde el software se instala una vez, se prueba y solo se actualiza cuando se encuentra una falla de seguridad. El nuevo software rara vez se agrega a un servidor en funcionamiento, generalmente es una actualización de lo que ya existe. Instalamos Apache 2.0.x ahora necesitamos Apache 2.0.xx. Apache ya ha superado al portero, por así decirlo.

Finalmente, una lista blanca no es una panacea. Un ejemplo reciente, un programador de Debian (GNU / Linux) mientras trabajaba en ssh realizó un cambio en el programa con fines de prueba que hicieron que el programa creara la misma firma de seguridad cada vez. Olvidó deshacer el cambio y lanzó el binario. ¡Uy! Ese binario estaba en la lista blanca a pesar de que era fatalmente defectuoso.

Entonces, no estoy en el campamento que dice que todos nuestros problemas de seguridad desaparecerán con la lista blanca. No va a doler, pero a nivel del servidor necesitamos mucho más.

Pasé mucho tiempo trabajando con algunas aplicaciones de listas blancas hace aproximadamente 5 años. Uno, Okena Stormwatch (comprado por Cisco y luego asesinado), fue increíble. Tomó la lista blanca a un grado extremo.

Podría, por ejemplo, definir qué ejecutables podría ejecutar una aplicación, incluidos los archivos .dll, qué archivos podría abrir y sus permisos (leer, escribir, eliminar, modificar, etc.), qué objetos com podrían abrirse y qué puertos de red podría usar (tanto entrantes como salientes). Incluso monitoreó el uso de RAM.

La política era bastante grande y si no se hacía correctamente, podría romper una aplicación de manera sutil. Estaba experimentando con Word, y mientras Word se ejecutaba, algunas características no estaban disponibles (obtendría un error) porque la DLL asociada no se podía usar. Eso incluía archivos DLL que ya estaban cargados en la memoria por otra aplicación. Algo estupendo.

Lo que hizo la aplicación Okena fue reducir significativamente los tipos de acciones que un atacante podría tomar. Muchos ataques hacen que una aplicación use recursos que normalmente no usa, como llamar a cmd.exe o vincular a un puerto de red. Por ejemplo, configuré un servidor W2K con IIS5, sin parches (que tenía un montón de agujeros), y configuré una política que permitía que IIS funcionara normalmente, pero detuve cosas como recorridos de directorio, ejecutando cmd.exe y un montón de otras cosas. IIS seguía siendo vulnerable a los ataques, pero a través de una lista blanca, el atacante no podía hacer nada útil.

Probé otros productos (ya están todos muertos), y sus funciones variaron mucho. Okena fue, con mucho, el más detallado. Los límites de lo que puede hacer la lista blanca también son bastante obvios. En los productos que probé, no había capacidad para examinar la lógica de la aplicación (piense en los scripts procesados ​​por los servidores web), por lo que los ataques de aplicaciones como la inyección SQL funcionarían bien. Sin embargo, una inyección SQL que intentó generar un shell a través de MSSQL fallaría ya que configuré una política que no permitía ejecutar cmd.exe.

Respuesta corta, la inclusión en la lista blanca en general reduce el área de superficie con riesgo de complejidad. Imagine que puede definir una política que los usuarios solo puedan escribir en el directorio de documentos y leer / ejecutar / escribir solo los archivos necesarios para ejecutar el sistema operativo y las aplicaciones (dll, archivos temporales, caché del navegador, etc.). Su escritorio está cerrado herméticamente. Ese fue el santo grial, pero llegar allí fue, y es, muy difícil.

La efectividad de la lista blanca se basa en una combinación de características del producto y una política definida.