Lean Threat Intelligence, Part 4: Batch alerting

*Este es el cuarto artículo de una serie acerca de la inteligencia sobre amenazas eficiente. Consulta las partes [1](https://www.fastly.com/blog/lean-threat-intelligence-part-1-plan), [2](https://www.fastly.com/blog/lean-threat-intelligence-part-2-foundation) y [3](https://www.fastly.com/blog/lean-threat-intelligence-part-3-battling-log-absurdity-kafka).* En [Inteligencia sobre amenazas eficiente \(parte 3\)](https://www.fastly.com/blog/lean-threat-intelligence-part-3-battling-log-absurdity-kafka) presentamos una tecnología que te permite dirigir mensajes hacia y desde temas a través de Kafka. De esta manera, es fácil adentrarse en estos envíos para mutar la telemetría y los registros para que se puedan analizar y presentar en Graylog. Si recuerdas el esquema de sistemas, Graylog es el punto de conexión en el que se almacenarán los registros. Los registros se envían al clúster de Kafka, y luego al procesador de envíos para devolverlos a Kafka o directamente a Graylog. Ahora que ya tienes datos moviéndose, ¿cómo puedes supervisarlos y reaccionar a incidentes de seguridad? En esta entrada te enseñaremos una estrategia de alerta por lotes que puedes usar con Graylog y Kafka. En Fastly, dividimos la reacción a los incidentes de seguridad en dos puntos diferentes del esquema de sistemas, antes y después de Graylog. Las alertas de "antes" y de "después" nos permiten lanzar alertas por envíos y por lotes, respectivamente. La búsqueda por lotes consume el procesador de la base de datos, que también intenta emitir escrituras asincrónicamente, mientras que el envío paga ese coste continuamente. Sin embargo, el procesamiento del envío puede acarrear una sobrecarga a la hora de almacenar una ventana deslizante de estado para poder comparar. Un ejemplo de alerta posterior podría ser la agregación de muchas búsquedas en Graylog, que luego se agrupan y analizan para buscar algo específico dentro de las correlaciones de tus búsquedas. Un ejemplo de alerta previa podría ser la búsqueda de un incidente muy concreto que requiera medidas inmediatas. Para obtener más información, consulta la documentación sobre alertas de Graylog.¹ ### Creación de servicios de alertas personalizados Una ventaja de tener Graylog en tu infraestructura es que su servidor web es un frontend ligero con una gran cantidad de puntos de conexión de API.² Esta decisión en el diseño permite crear integraciones personalizadas en Graylog, así como consultar datos y disfrutar de la misma funcionalidad que en la GUI, pero mediante programación. Hay unos pocos enlaces para lenguajes ahí fuera,^3,4 pero por suerte la interfaz está en Swagger, lo que hace que consultar puntos de conexión y crear integraciones sea relativamente fácil. Al navegador de la API se accede por la ventana de Nodes, que verás más abajo.²   *Lista de puntos de conexión*  *Punto de conexión search/absolute/end con campos requeridos, método HTTP* Como puedes ver en **/search/universal/absolute/terms** , Swagger nos indica la consulta que espera, los tipos de datos y qué podemos esperar en una respuesta. Este es un punto de conexión idóneo para calcular recuentos de registros según una consulta y un campo. Por ejemplo, se puede crear una consulta para contar todos los errores de SSH contra tu flota, y devolver el campo del nombre de host de ese error para ver si se accedió a una máquina que debería haber estado protegida por un firewall. Otro ejemplo es realizar una consulta de todo el tráfico de DNS de los últimos cinco minutos, pidiendo a Graylog que devuelva el nombre del host de destino e iterando por esa lista para ver si uno de los dominios es un DGA conocido, ya sea contra un clasificador o un punto de conexión de inteligencia contra amenazas. ### Escritura de los servicios de alertas Ahora que ya tienes un punto de conexión que puede realizar consultas absolutas para registros y devolver resultados como Terms para recuentos de campos específicos, se pueden construir una serie de consultas y enviarlas a Graylog. Las respuestas se pueden almacenar en una secuencia de comandos, y puedes escribir un código para hacer un análisis más complicado. Un caso de uso puede ser realizar búsquedas de dominios maliciosos. Para este ejemplo usaremos la lista del DGA de Bambanek, la biblioteca `pygraylog` y Python para realizar las búsquedas. Supongamos que tenemos una instancia de Graylog que registra el tráfico del DNS por toda una red, y cada búsqueda queda registrada y se envía en un formato que Graylog entiende \(JSON\). Para obtener una lista de verdad terreno de dominios activos del DGA, descarga la lista ⁵ de DGA de Bambenek. wget [http://osint.bambenekconsulting.com/feeds/dga\-feed.txt](http://osint.bambenekconsulting.com/feeds/dga-feed.txt) ┌─[zallen@Zacks-MBP]─(~/git/lti4) └─[15:59]$ ls -lah total 215864 drwxr-xr-x 3 zallen staff 102B Sep 20 15:59 ./ drwxr-xr-x 98 zallen staff 3.3K Sep 20 15:59 ../ -rw-r--r-- 1 zallen staff 105M Sep 19 20:15 dga-feed.txt Añade `pygraylog` a `requirements.txt`, suéltalo en un `virtualenv` e instala: echo "pygraylog" >> requirements.txt; virtualenv env; . env/bin/activate; pip install -r requirements.txt A continuación, inicia una entrada ⁶ HTTP GELF de Graylog para poder enviar alertas mediante POST a tu servidor de Graylog. Con todo donde corresponde, deberías tener la biblioteca de Python instalada, un entorno virtual operativo y una entrada HTTP para enviar alertas a Graylog. El siguiente gist de Python consultará en un servidor de Graylog los nombres de host consultados por el DNS en los últimos cinco minutos. A continuación, extraerá esos términos de la respuesta y los comparará con la lista de DGA de Bambanek. Si se encuentra una coincidencia, creará un objeto de alerta y emitirá la alerta a la entrada de POST de Graylog. Usaremos el código fuente que se encuentra en el siguiente gist: \[gist:b5ca9ca75fc788dbd340384c1ac8e022\] Introduce tus credenciales y las credenciales de Graylog en la parte superior con las `líneas 5-6` A continuación, ejecuta la secuencia de comandos con `python logger.py`, que descargará la lista de DGA a través de la función `build_data_dict`, procesará el periodo de los últimos cinco minutos basándose en la consulta de tiempo de Graylog y buscará en Graylog llamando a `search_graylog()`. Por supuesto, puedes mejorar estos pasos almacenando en caché la lista de DGA para que solo se descargue a diario. Si quieres un elemento de ejemplo, comenta el elemento de las `líneas 32-38` para crear una alerta sin consultar al servidor. Las `líneas 79-81` llamarán a la función de alerta con los `resultados`, las cadenas de tiempo y una referencia al `data_dict` que construimos anteriormente. En la línea 46, si un `término`, es decir, un `nombre de host`, se encuentra dentro de nuestro `data_dict` del DGA, crea un elemento de alerta con algunos metadatos y agrégalo a una lista. Una vez se devuelva esa lista, habrá lógica para comprobar si hay alguna alerta disponible. Si es así, se llama a `send_to_graylog` y luego se deja un mensaje en la entrada POST de Graylog. A partir de ahí, puedes configurar Graylog para que alerte sobre cualquier mensaje que aparezca en esa entrada, porque sabes que esos mensajes son incidentes dignos de una alerta. Al crear reglas para comprobar claves ahorrarás energía del procesador en el procesamiento de envíos. Además, puedes crear paneles para que sea más fácil realizar un seguimiento de las alertas a lo largo del tiempo. ### En resumen Fastly utiliza secuencias de comandos de Python parecidas a la anterior. Tenemos dos hipótesis de alerta en proceso, y la anterior muestra aquella en la que tu equipo necesita alertar sobre las búsquedas que agregan datos. Graylog tiene un complemento⁷ para ayudar con las alertas de tipo agregado, pero si tuviéramos que realizar varias búsquedas que agrupasen datos, este complemento no nos sería de ayuda. Puesto que estamos en Python, las hipótesis complicadas de alertas se pueden representar en código en lugar de en la interfaz web. Además, podemos realizar pruebas, control de revisiones e integraciones continuas con nuestro plan de alertas. *Para obtener más información sobre la gestión de incidentes de seguridad, no te pierdas la próxima charla del 1 de noviembre con los empleados de Fastly Maarten Van Horenbeeck, Lisa Phillips y Tom Daly, titulada "[Incident command: the far side of the edge](http://conferences.oreilly.com/security/network-data-security-ny/public/schedule/detail/53214)", en la Conferencia de seguridad de O'Reilly en Nueva York.* *** ** * ** *** Referencias \(pueden estar en inglés\) 1 [http://docs.graylog.org/en/2\.1/pages/getting\_started/stream\_alerts.html](http://docs.graylog.org/en/2.1/pages/getting_started/stream_alerts.html) 2 [https://www.graylog.org/blog/8\-tips\-tricks\-2\-using\-the\-graylog\-rest\-api](https://www.graylog.org/blog/8-tips-tricks-2-using-the-graylog-rest-api) 3 [https://www.npmjs.com/package/graylog\-api](https://www.npmjs.com/package/graylog-api) 4 [https://pypi.python.org/pypi/bonfire/0\.0\.6](https://pypi.python.org/pypi/bonfire/0.0.6) 5 [http://osint.bambenekconsulting.com/feeds/dga\-feed.txt](http://osint.bambenekconsulting.com/feeds/dga-feed.txt) 6 [http://docs.graylog.org/en/2\.1/pages/sending\_data.html\#gelf\-via\-http](http://docs.graylog.org/en/2.1/pages/sending_data.html#gelf-via-http) 7 [https://github.com/cvtienhoven/graylog\-plugin\-aggregates](https://github.com/cvtienhoven/graylog-plugin-aggregates)