Tras hacer un recorrido sobre algunas de las soluciones que existen para analizar la seguridad de las aplicaciones "dockerizadas" teniendo diferentes puntos de vista en la primera parte de este artículo, es el momento de hablar del trabajo que he estado realizando durante este tiempo con Dagda.
La solución propuesta para dar solución para la auditoría de las aplicaciones que corren en entornos Docker ha sido Dagda, que se puede definir como una suite de seguridad Docker que permite tanto el análisis estático de vulnerabilidades de los componentes software presentes en imágenes Docker como el análisis de dependencias de distintos frameworks de aplicaciones. Además, permite detectar comportamientos anómalos en contenedores Docker en ejecución en base a reglas.
Una visión a muy alto nivel de la arquitectura de Dagda se muestra en la Figura 13 que se muestra a continuación. En dicha figura se muestra como Dagda se ejecuta en modo servidor standalone. Para su funcionamiento, Dagda se comunica con una base de datos MongoDB y con el socket de Docker.
En primer lugar, Dagda no se apoya en el proyecto cve-search para su base de conocimiento de vulnerabilidades, ya que cve-search necesita, además de MongoDB, un Redis para su funcionamiento.
VulnDB: Base de datos de vulnerabilidades en Dagda
La necesidad de otro componente más como es Redis, unido a la rigidez de su API de consulta, ha desembocado en lo que en la Figura 13 se denomina VulnDB, que no es más que una base de datos MongoDB. Esta base de datos está fuera del servidor Dagda, por lo que puede ser cualquier MongoDB proporcionado por el usuario.
En la base de datos VulnDB de Dagda, además de almacenar los expedientes CVE e información de Exploit-db, se ha añadido la base de datos completa de BugTraq de Symantec, la cual no ha sido utilizada nunca hasta la fecha por ninguna otra herramienta.
Además, en dicha base de datos se almacena también el histórico de los análisis estáticos realizados sobre las imágenes Docker y el resultado de la monitorización de los contenedores en ejecución. Esta funcionalidad de histórico también es única entre las herramientas y productos Open Source ya que éstos únicamente utilizan su base de datos para consultar las vulnerabilidades conocidas, quedando fuera de su objetivo, la gestión del histórico de los análisis realizados.
En comparación con el resto de herramientas de análisis de vulnerabilidades que no permiten el uso de la base de datos de vulnerabilidades que se descargan para cumplir su función, Dagda dispone de una API REST completa para su gestión, incluyendo entre dicha funcionalidad, el histórico de análisis y el acceso a la base de conocimiento de vulnerabilidades que ha poblado en MongoDB.
Análisis estático de vulnerabilidades en Dagda
En cuanto al análisis estático de vulnerabilidades de los componentes software presente en las imágenes docker, Dagda extrae el listado del software instalado en la imagen y busca las coincidencias con productos y versiones vulnerables contra VulnDB. Dagda soporta un gran número de distribuciones como: Red Hat/CentOS/Fedora, Debian/Ubuntu, OpenSUSE y Alpine, aunque es fácilmente ampliable.
Por otro lado, en cuanto al análisis de dependencias de distintos framworks de aplicaciones, Dagda se integra con el proyecto Docker dependency checker, el cual utiliza OWASP Dependency Check y Retire.js para analizar múltiples lenguajes como son: Java, Python, Node.js, JavaScript, Ruby & PHP.
Dagda soporta también la detección de comportamientos anómalos en contenedores Docker en ejecución en base a reglas gracias a su integración con Sysdig/Falco, siendo dichas reglas, ampliables también según las necesidades del usuario en cada entorno de trabajo o producción.
En la siguiente Figura 17 que se muestra a continuación, se puede ver un ejemplo de como se crea una regla de monitorización cuando un servidor ElasticSearch recibe tráfico entrante en un puerto distinto de los de servicio por defecto, que son 9200/9300.
La monitorización de los contenedores en ejecución se lleva a cabo desde que se arranca el servidor Dagda, pero será el usuario el que deberá explícitamente comenzar una monitorización de un contenedor concreto y pararla cuando desee para que quede registrado en el histórico de monitrorización del propio contenedor.
Para finalizar, destacar que Dagda es un proyecto completamente Open Source y que tanto su código fuente, como la documentación de su uso, ya sea mediante el API REST o mediante su CLI, está completamente documentada en la Wiki del proyecto Dagda.
Ideas finales
Como conclusión, puedo remarcar que aunque exista un estado del arte muy amplio con respecto a herramientas focalizadas en algo muy concreto, como en este caso me ha sucedido con las herramientas de seguridad en Docker, siempre se puede encontrar un nuevo enfoque que ayude a resolver un problema dado en base a la recopilación de carencias que tengan las demás herramientas existentes.
Espero que os haya gustado este trabajo y que os anime a iniciar vuestra propia investigación o aprendizaje en todo aquello que tengáis aún en la lista de tareas por hacer como me pasaba a mí con Docker y Python. Finalmente, recordaros también que podéis utilizar libremente el proyecto Dagda en vuestros entornos, añadirle nueva funcionalidad, reportar errores que detectéis o incluso, proponer nuevas ideas :-) En el siguiente vídeo tenéis un pequeño ejemplo de funcionamiento de Dagda.
 |
| Figura 11: Dagda Docker Security Suite Parte 2 |
La solución propuesta para dar solución para la auditoría de las aplicaciones que corren en entornos Docker ha sido Dagda, que se puede definir como una suite de seguridad Docker que permite tanto el análisis estático de vulnerabilidades de los componentes software presentes en imágenes Docker como el análisis de dependencias de distintos frameworks de aplicaciones. Además, permite detectar comportamientos anómalos en contenedores Docker en ejecución en base a reglas.
 |
| Figura 12: Dagda en GitHub |
Una visión a muy alto nivel de la arquitectura de Dagda se muestra en la Figura 13 que se muestra a continuación. En dicha figura se muestra como Dagda se ejecuta en modo servidor standalone. Para su funcionamiento, Dagda se comunica con una base de datos MongoDB y con el socket de Docker.
 |
| Figura 13: Arquitectura a alto nivel de Dagda |
En primer lugar, Dagda no se apoya en el proyecto cve-search para su base de conocimiento de vulnerabilidades, ya que cve-search necesita, además de MongoDB, un Redis para su funcionamiento.
VulnDB: Base de datos de vulnerabilidades en Dagda
La necesidad de otro componente más como es Redis, unido a la rigidez de su API de consulta, ha desembocado en lo que en la Figura 13 se denomina VulnDB, que no es más que una base de datos MongoDB. Esta base de datos está fuera del servidor Dagda, por lo que puede ser cualquier MongoDB proporcionado por el usuario.
En la base de datos VulnDB de Dagda, además de almacenar los expedientes CVE e información de Exploit-db, se ha añadido la base de datos completa de BugTraq de Symantec, la cual no ha sido utilizada nunca hasta la fecha por ninguna otra herramienta.
 |
| Figura 14: Base de datos de BugTraq en SecurityFocus |
Además, en dicha base de datos se almacena también el histórico de los análisis estáticos realizados sobre las imágenes Docker y el resultado de la monitorización de los contenedores en ejecución. Esta funcionalidad de histórico también es única entre las herramientas y productos Open Source ya que éstos únicamente utilizan su base de datos para consultar las vulnerabilidades conocidas, quedando fuera de su objetivo, la gestión del histórico de los análisis realizados.
En comparación con el resto de herramientas de análisis de vulnerabilidades que no permiten el uso de la base de datos de vulnerabilidades que se descargan para cumplir su función, Dagda dispone de una API REST completa para su gestión, incluyendo entre dicha funcionalidad, el histórico de análisis y el acceso a la base de conocimiento de vulnerabilidades que ha poblado en MongoDB.
Análisis estático de vulnerabilidades en Dagda
En cuanto al análisis estático de vulnerabilidades de los componentes software presente en las imágenes docker, Dagda extrae el listado del software instalado en la imagen y busca las coincidencias con productos y versiones vulnerables contra VulnDB. Dagda soporta un gran número de distribuciones como: Red Hat/CentOS/Fedora, Debian/Ubuntu, OpenSUSE y Alpine, aunque es fácilmente ampliable.
Por otro lado, en cuanto al análisis de dependencias de distintos framworks de aplicaciones, Dagda se integra con el proyecto Docker dependency checker, el cual utiliza OWASP Dependency Check y Retire.js para analizar múltiples lenguajes como son: Java, Python, Node.js, JavaScript, Ruby & PHP.
 |
| Figura 15: Ejemplo de funcionamiento de Docker Dependency Checker |
Dagda soporta también la detección de comportamientos anómalos en contenedores Docker en ejecución en base a reglas gracias a su integración con Sysdig/Falco, siendo dichas reglas, ampliables también según las necesidades del usuario en cada entorno de trabajo o producción.
 |
| Figura 16: Sysdig/Falco con soporte para containers docker |
En la siguiente Figura 17 que se muestra a continuación, se puede ver un ejemplo de como se crea una regla de monitorización cuando un servidor ElasticSearch recibe tráfico entrante en un puerto distinto de los de servicio por defecto, que son 9200/9300.
 |
| Figura 17: Ejemplo de regla para detectar un uso de puerto indebido para acceder a ElasticSearch |
La monitorización de los contenedores en ejecución se lleva a cabo desde que se arranca el servidor Dagda, pero será el usuario el que deberá explícitamente comenzar una monitorización de un contenedor concreto y pararla cuando desee para que quede registrado en el histórico de monitrorización del propio contenedor.
 |
| Figura 18: Ejecución de Dagda en modo CLI |
Para finalizar, destacar que Dagda es un proyecto completamente Open Source y que tanto su código fuente, como la documentación de su uso, ya sea mediante el API REST o mediante su CLI, está completamente documentada en la Wiki del proyecto Dagda.
Ideas finales
Como conclusión, puedo remarcar que aunque exista un estado del arte muy amplio con respecto a herramientas focalizadas en algo muy concreto, como en este caso me ha sucedido con las herramientas de seguridad en Docker, siempre se puede encontrar un nuevo enfoque que ayude a resolver un problema dado en base a la recopilación de carencias que tengan las demás herramientas existentes.
 |
| Figura 19: Sección de Troubleshooting en la Wiki de Dagda |
Espero que os haya gustado este trabajo y que os anime a iniciar vuestra propia investigación o aprendizaje en todo aquello que tengáis aún en la lista de tareas por hacer como me pasaba a mí con Docker y Python. Finalmente, recordaros también que podéis utilizar libremente el proyecto Dagda en vuestros entornos, añadirle nueva funcionalidad, reportar errores que detectéis o incluso, proponer nuevas ideas :-) En el siguiente vídeo tenéis un pequeño ejemplo de funcionamiento de Dagda.
Figura 20: Demostración de uso de Dagda
Autor: Elias Grande (@3grander) autor del Proyecto ODIN
Graduado en por el Master de Seguridad de la UEM
Buenos días, Elías.
ResponderEliminarMe ha parecido muy interesante tu proyecto. Permíteme la curiosidad: ¿cómo incorporas a MongoDB la información desde CVE, exploit-Db, etc?
Saludos y te reitero mi felicitación
La información de CVEs y Exploit-db se encuentra pública en Internet y es fácilmente descargable. La de BugTraqs Ids costó algo más, pero tampoco mucho. Tienes también disponible mi proyecto PoC para hacer web scraping de la web de Security Focus en mi github: bidDB_downloader [https://github.com/eliasgranderubio/bidDB_downloader].
ResponderEliminarDe todas formas, todo el código fuente referido a este tema dentro de Dagda lo puedes encontrar en el paquete dagda/vulnDB.
Saludos.