dawgmon

Lo anterior ayuda ahora a realizar una revisión de seguridad exhaustiva de virtualbox. Los binarios suid instalados son puntos de entrada obvios y los servicios en ejecución son interesantes.

Otro ejemplo de ejecución que detecta correctamente la apertura y cierre de puertos TCP:

La herramienta no está diseñada para una precisión absoluta. Hay recomendaciones muy serias de no confiar en la salida de GNU core-utils como ls para la entrada de herramientas. En otras palabras; raramente se deberían construir herramientas para analizar y depender de este tipo de salida, ya que puede cambiar en cualquier momento. Realísticamente, la salida de estas herramientas es relativamente estable ya que muchas personas y herramientas automáticas ya dependen de sus salidas para todo tipo de propósitos.

Sin embargo, la compensación para dawgmon es la siguiente; necesitaríamos implementar mucha lógica para hacer la monitorización del sistema de archivos por nuestra cuenta, construir binarios complejos que incluyan bibliotecas para analizar y monitorear dispositivos de bloque, las interfaces de red y demás. Esto también haría que la herramienta sea mucho más compleja y menos mantenible. En proyectos actuales se puede agregar un nuevo comando incluyendo detección de cambios en muy poco tiempo, ya que la herramienta principal dawgmon ya se encarga del almacenamiento en caché, la ejecución del comando y luego suministra la salida anterior y actual al ejecutar una comparación con una implementación de comando. Esto significa que en proyectos con limitaciones de tiempo se puede agregar muy rápidamente un nuevo comando y ejecutar análisis que incluyan esos nuevos comandos.

Se puede agregar un comando simplemente heredando de la clase Command. Esta clase está definida en commands/__init__.py. Ese archivo también contiene la lista maestra de comandos (y el orden en que se ejecutan al hacer un análisis completo). Luego, las propiedades como name, shell, command y desc deberán establecerse y se deberán implementar dos métodos: parse() y compare(). Se incluyen suficientes comandos para tener una buena idea de cómo implementar y agregar nuevos.

USO

Para mejores resultados ejecute la herramienta como root. Para ayuda escriba -h/--help y para información de versión escriba -v/--version.

Siempre se debe especificar una acción principal. Estas acciones son:

• -A: analizar el sistema
• -C: comparar entradas de caché
• -E: listar comandos disponibles
• -L: listar entradas de caché

Opciones adicionales para ayudar con el análisis son:

• -d: mostrar salida de depuración
• -e: ejecutar un comando específico (se puede usar múltiples veces)
• -f: forzar la ejecución sin advertencia sobre ejecución como root
• -g: colorear la salida
• -l: ubicación de la base de datos de caché a usar
• -m: cantidad máxima de entradas de caché permitidas en la caché (si la caché tiene más entradas que esta cantidad, truncará la base de datos)
• -t: no mostrar información de marca de tiempo por anomalía detectada.

Para más información de uso ejecute la herramienta con -h.

LIMITACIONES

La herramienta analiza la salida de herramientas de línea de comandos y depende de opciones específicas de GNU core-utils para parte de ello. No hay una razón específica por la que esta herramienta y las implementaciones de comandos no puedan ser portadas rápidamente a otros sistemas operativos como los BSD, pero actualmente no se realiza detección del sistema operativo ni se clasifican los comandos según el soporte del sistema operativo. Eso tendría que implementarse primero.

En cuanto a la búsqueda de pipes, sockets UNIX, archivos en /boot, /etc y más, se debe tener en cuenta que el uso de -xdev pasado a find significa que no se recorrerán todos los sistemas de archivos montados bajo el directorio de inicio. Esto significa que, por ejemplo, /boot se escaneará correctamente pero /boot/efi podría no serlo. Se deberá utilizar un enfoque más inteligente en el futuro.

Las marcas de tiempo al realizar un análisis actual pueden ser un poco confusas. Por defecto, una marca de tiempo para un mensaje de anomalía de advertencia, normal o de depuración será la marca de tiempo de su momento de generación (como se puede ver en commands/__init__.py). Las anomalías se generan después de que se haya realizado un escaneo completo de la línea de comandos. Por lo tanto, la salida sobre la que funciona esta detección se generó antes y, posteriormente, las marcas de tiempo para anomalías individuales muestran una hora posterior a la hora del escaneo. Al comparar entradas de caché, se utiliza la marca de tiempo del escaneo para mostrar la hora en que ocurrió la detección, ya que eso tiene lógicamente más sentido.

ACERCA DE

Todos los derechos reservados. Copyright (C) 2017-2019 por Anvil Ventures Inc. Para información de licencia, consulte LICENSE. Para más información, contacte a Vincent Berg [email protected]

Para encontrar el código fuente actualizado o contribuir con parches, visite la siguiente URL: https://github.com/anvilventures/dawgmon/