Preámbulo
En nuestra primera publicación de nuestro serial Detonate, presentamos el sistema Detonate y para qué lo usamos en Elastic. También analizamos los beneficios que proporciona a nuestro equipo a la hora de evaluar el rendimiento de nuestros artefactos de seguridad.
En esta publicación, analizaremos cómo funciona Detonate y profundizaremos en la implementación técnica. Esto incluye cómo podemos crear este entorno de espacio aislado en la práctica, la tecnología que respalda la canalización general y cómo enviamos y leemos información de la canalización.
¿Te interesan otras publicaciones sobre Detonate? Echa un vistazo a la Parte 1 - Clic, clic... ¡Auge! donde presentamos Detonate, por qué lo creamos, exploramos cómo funciona Detonate, describimos estudios de casos y discutimos las pruebas de eficacia.
Arquitectura
A continuación se muestra una descripción general de alto nivel de la arquitectura de extremo a extremo de Detonate.
El sistema general consta de un serial de colas de mensajes y trabajadores de Python. Las tareas de detonación son creadas por un servidor API al aceptar una solicitud con tan poca información como el hash del archivo de muestra. A continuación, la tarea se mueve de una cola a otra, recogida por los trabajadores que ejecutan diversas operaciones a lo largo del camino.
El servidor y los trabajadores se ejecutan en un contenedor en Amazon ECS. La canalización también se puede activar localmente mediante Docker Compose para el desarrollo temprano y las pruebas de funciones.
Servidor de API
El servidor de API de Detonate es una aplicación de Python de FastAPI que acepta una variedad de solicitudes de destino de ejecución: hashes de muestras, comandos nativos (en bash o Powershell, con o sin argumentos) y archivos cargados. El servidor también expone puntos de conexión para obtener alertas y telemetría de agente sin procesar de un cluster de Elastic.
La documentación de la API es generada automáticamente por FastAPI e incorporada a nuestro esquema de API global.
Interacción con el servidor de API - CLI
Creamos una herramienta CLI (interfaz de línea de comandos) personalizada de Python para interactuar con nuestro servidor Detonate. La herramienta CLI se crea empleando la biblioteca de Python, haga clic junto con rich para una hermosa experiencia de formato en una ventana de terminal. La herramienta es especialmente útil para depurar la canalización, ya que también se puede ejecutar en una configuración de canalización local. La herramienta se instala y se ejecuta empleando Poetry, nuestra herramienta preferida para gestionar dependencias y ejecutar scripts.
❯ DETONATE_CLI_API_ROOT_URL="${API_ENDPOINT_URL}" \
DETONATE_CLI_API_AUTH_HEADER="${API_KEY}" \
poetry run cli \
--hash "${MY_FILE_HASH}"Interacción con el servidor de API: interfaz de usuario sitio web
Internamente, alojamos un sitio llamado Protections Portal (escrito con componentes de Elastic UI ) para ayudar a nuestro equipo con la investigación. Para una experiencia más interactiva con la API de Detonate, creamos una página en el portal para interactuar con ella. Junto con el envío de tareas, la interfaz de usuario sitio web permite a los usuarios ver la fuente de todas las detonaciones y los detalles de cada tarea.
Cada tarea se puede expandir para ver todos sus detalles. Proporcionamos los enlaces a los datos y la telemetría recopilados durante la detonación.
Interacción con el servidor de API: cliente HTTP
Si nuestros usuarios desean personalizar la forma en que interactúan con la API de Detonate, también pueden ejecutar comandos empleando el cliente HTTP de su elección (como curl , httpie , etc.). Esto les permite agregar detonaciones a los scripts o como pasos finales al final de sus propios flujos de trabajo.
Queues
La canalización se basa en un serial de colas y trabajadores. Al tener requisitos muy básicos para el motor de colas de mensajes, decidimos optar por Amazon SQS. Uno de los muchos beneficios de usar un servicio popular como SQS es la disponibilidad de recursos y bibliotecas de código abierto en los que podemos basarnos. Por ejemplo, usamos imágenes de Docker de softwaremill/elasticmq como motor de cola cuando se ejecuta la canalización localmente.
Las colas se configuran y despliegan con código Terraform que cubre toda nuestra infraestructura de producción y staging.
Trabajadores
Cada trabajador es un script de Python que actúa como consumidor de cola y productor de cola. Los trabajadores se implementan en nuestro minimarco personalizado, con el código reutilizable para el manejo de errores, los reintentos y la supervisión incorporados. Nuestro trabajador base se amplía fácilmente, lo que nos permite agregar nuevos trabajadores y evolucionar los existentes si surgen requisitos adicionales.
Para el monitoreo, empleamos la solución de observabilidad de Elastic APM . Es increíblemente poderoso, ya que nos da una visión del flujo de ejecución y hace que los problemas de la canalización de depuración sean muy sencillos. A continuación, podemos ver un movimiento de tarea Detonar entre trabajadores en la interfaz de usuario de APM:
Estos componentes de software e infraestructura nos dan todo lo que necesitamos para realizar el envío, la ejecución y la recopilación de datos que componen una detonación.
Detonaciones
La canalización puede ejecutar comandos y ejemplos en máquinas virtuales (VM) Windows, Linux y macOS. Para entornos Windows y Linux, usamos instancias de VM en Google Compute Engine. Con la amplia selección de imágenes públicas, nos permite aprovisionar entornos sandbox con diferentes versiones de Windows, Debian, Ubuntu, CentOS y RHEL.
Para entornos macOS, empleamos instancias mac1.metal en AWS y una solución de aprovisionamiento de VM macOS bajo demanda de Veertu llamada Anka. Anka nos da la capacidad de rotar rápidamente varias máquinas virtuales de macOS que se ejecutan en la misma instancia de hardware dedicado de macOS.
Actualmente, Detonate se centra en la amplitud de la cobertura de nuestro sistema operativo, la escalabilidad y la recopilación de datos contextualmente relevantes de la canalización. Actualmente se está investigando y diseñando la instalación de sofisticadas contramedidas anti-análisis en Detonate.
Aprovisionamiento de máquinas virtuales
Con el fin de mantener nuestra huella en la máquina virtual al mínimo, usamos scripts de inicio para el aprovisionamiento. Minimizar nuestra huella es importante porque nuestras actividades dentro de una máquina virtual se incluyen en los eventos que recopilamos, lo que complica el análisis luego de una ejecución. En el caso de las máquinas virtuales Windows y Linux, se usan scripts de inicio de GCP escritos en Powershell y bash para configurar el sistema; para las máquinas virtuales macOS, escribimos scripts personalizados de bash y AppleScript.
Los scripts de inicio realizan estos pasos:
- Configurar el sistema. Por ejemplo, deshabilite MS Defender, habilite la ejecución de macros en MS Office, deshabilite las actualizaciones automáticas del sistema, etc.
- Descarga e instala el agente de Elastic. El script verifica que el agente esté correctamente inscrito en el servidor de flota y que se apliquen las políticas.
- Descargue y detone una muestra, o ejecute un conjunto de comandos. La ejecución ocurre en un proceso en segundo plano, mientras que el script principal recopila los flujos de datos STDOUT / STDERR y duerme durante N segundos.
- Recopile archivos del sistema de archivos (si es necesario) y cárguelos en el almacenamiento. Esto nos permite realizar cualquier verificación o depuración adicional una vez que se completa la detonación.
El ciclo de vida de la máquina virtual lo gestionan los trabajadores start_vm y stop_vm . Dado que esperamos que algunas detonaciones interrumpan el flujo de ejecución del script de inicio (por ejemplo, en el caso del ransomware), cada máquina virtual tiene un conjunto de TTL, lo que permite al trabajador stop_vm eliminar las máquinas virtuales que ya no están en uso.
Este enfoque de borrón y cuenta nueva, con el script de inicio empleado para configurar todo lo necesario para una detonación, nos permite emplear imágenes de VM de los proveedores del catálogo de imágenes públicas de Google Cloud sin ninguna modificación.
Configuración de la red
Algunas de las muestras que detonamos son maliciosas y pueden producir tráfico malicioso, como análisis de red, llamadas C2, etc. Con el fin de mantener seguros nuestros recursos en la nube y la infraestructura de nuestros proveedores, limitamos todo el tráfico saliente de las máquinas virtuales. Las instancias se colocan en una VPC bloqueada que permite la conexión saliente solo a una lista predefinida de destinos. Restringimos los flujos de tráfico en VPC mediante las rutas y las reglas de firewall de Google Cloud, así como los grupos de seguridad de AWS.
También hacemos uso de los registros de flujo de VPC en GCE. Estos registros nos permiten ver el tráfico de red privada iniciado por las VM de sandbox en nuestra VPC.
Colección de telemetría
Para observar las detonaciones, usamos el Elastic Agent con la integración de Elastic Defend instalada con todas las protecciones en modo "Detectar" (en lugar de "Proteger"). Esto nos permite recopilar la mayor cantidad de información posible de una VM y, al mismo tiempo, permitir que la solución de Elastic Security produzca alertas y detecciones.
Cubrimos dos casos de uso con esta arquitectura: podemos validar protecciones (comparando eventos y alertas producidos para diferentes versiones del sistema operativo, versiones de agentes, artefactos de seguridad implementados, etc.) y recopilar telemetría para el análisis (para muestras frescas o malware novedoso) al mismo tiempo. Todos los datos recopilados se almacenan en un cluster persistente de Elastic y están disponibles para nuestros investigadores.
Ejecución en producción
Recientemente, completamos un mes completo de ejecución de la canalización de Detonate en producción, bajo la carga de múltiples integraciones de datos, sirviendo a los usuarios internos a través de la interfaz de usuario al mismo tiempo. Nuestro récord hasta ahora es de 1034 detonaciones en un solo día, y hasta ahora, no vimos ningún problema de escalabilidad o confiabilidad.
La mayor parte de los envíos son ejemplos específicos de Windows, por ahora. También estamos trabajando para aumentar nuestra cobertura de Linux y macOS: ¡estén atentos a las publicaciones del blog de investigación que llegarán pronto!
Mejoramos constantemente nuestro soporte para varios tipos de archivos, cerciorándonos de que la detonación sea lo más parecida posible al comportamiento de disparo previsto.
Al observar las detonaciones del último mes, vemos que la mayoría de las tareas se completaron en menos de 13 minutos (con una mediana de 515 segundos). Este tiempo incluye la preparación de los datos de las tareas, el aprovisionamiento y la limpieza de las máquinas virtuales, la ejecución de muestras y el procesamiento posterior a la detonación.
Todavía estamos en los primeros días del servicio, por lo que es normal ver los valores atípicos. Dado que la mayor parte del tiempo de una tarea se dedica a esperar a que se aprovisione una máquina virtual, podemos mejorar el tiempo de ejecución general mediante el uso de imágenes de máquina virtual personalizadas, el preinicio de instancias de máquina virtual y la optimización de los scripts de inicio.
¿Qué sigue?
Ahora que ves cómo funciona Detonate, en nuestras próximas publicaciones nos sumergiremos en casos de uso más detallados de Detonate. Profundizaremos en cómo estas detonaciones se convierten en la protección de más de nuestros usuarios, ¡incluso aquí mismo en Elastic!