logs & LLMs

Overview

La gestión de logs en los sistemas de TI de una empresa suele ser una tarea ardua y que consume mucho tiempo. Normalmente, utilizamos sistemas de almacenamiento de logs con capacidades de filtrado para obtener los registros relevantes y configurar alertas o paneles de control.

Por otro lado, los LLM (large lenguage model) han demostrado una gran capacidad para detectar patrones o anomalías, lo que los convierte en aliados potenciales que complementan los sistemas actuales de gestión de logs.

Muchos de los sistemas comerciales de gestión actuales incorporan inteligencia artificial ya sea como reclamo de marketing o aportando nuevas funcionalidades, pero aquí hemos venido a jugar.

LLMs

Los modelos de lenguaje natural de gran tamaño están evolucionado a gran velocidad, cada día amplían sus capacidades y descubrimos nuevos modos de cómo usarlos.

El más conocido es GPT, de OpenAI, que nos permite usar su modelo mediante una API pagando un pequeño importe o mediante el conocido ChatGPT que dispone tanto de versión gratuita como de pago. Sin embargo, existen otras opciones como Gemini de Google y el recientemente lanzado llama3 de Meta, que puede ser utilizado localmente en nuestras computadoras. Estos modelos son de propósito general y pueden ser utilizados para una gran variedad de aplicaciones. En este artículo, nos enfocaremos en cómo pueden ser empleados para analizar los logs de nuestros servidores.

logs

Los logs de los sistemas de TI son registros secuenciales de eventos que quedan almacenados en uno o varios archivos. Cada registro suele contener información como: fecha, categoría del evento y detalles como: códigos de error o descripciones del evento. Sirvan las siguientes líneas de ejemplo. 

1
2
3
4
5
6
7
8
9
10
11
Dec 10 06:55:46 LabSZ sshd[24200]: reverse mapping checking getaddrinfo for ns.marryaldkfaczcz.com [173.234.31.186] failed - POSSIBLE BREAK-IN ATTEMPT! 

Dec 10 06:55:46 LabSZ sshd[24200]: Invalid user webmaster from 173.234.31.186 

Dec 10 06:55:46 LabSZ sshd[24200]: input_userauth_request: invalid user webmaster [preauth] 

Dec 10 06:55:46 LabSZ sshd[24200]: pam_unix(sshd:auth): check pass; user unknown 

Dec 10 06:55:46 LabSZ sshd[24200]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=173.234.31.186  

Dec 10 06:55:48 LabSZ sshd[24200]: Failed password for invalid user webmaster from 173.234.31.186 port 38926 ssh2

Cada sistema tiene su propio formato de log, lo que requiere que comprendamos y diseñemos filtros específicos para extraer la información relevante.

Para este artículo, utilizaremos los logs del repositorio loghub que ofrece un dataset de logs de distintos servicios.

Práctica

Para la práctica, descargaremos algunos de los logs del repositorio mencionado y los proporcionaremos a un LLM para obtener la información deseada. Es interesante notar que solo cambiando la pregunta que le hacemos al modelo, podemos obtener información diferente. Podemos hacer preguntas relacionadas con la seguridad, errores de aplicación, rendimiento, etc., sin necesidad de modificar el código que estamos utilizando.

GPT

Para el primer ejemplo utilizaremos los servicios de OpenAI. El costo de analizar un log de unas 2000 líneas será de aproximadamente 0,04 €, pero nos proporcionará la información casi instantáneamente. Usaremos la biblioteca langchain de Python para interactuar con el modelo de manera sencilla.

Se importan los módulos necesarios para cargar los logs, dividirlos en textos más pequeños, generar embeddings, crear un almacén de vectores y configurar el modelo de recuperación de preguntas y respuestas. 

1
2
3
4
5
6
7
from langchain_openai import OpenAI 
from langchain_community.document_loaders import TextLoader 
from langchain.text_splitter import RecursiveCharacterTextSplitter 
from langchain_openai import OpenAIEmbeddings 
from langchain_community.vectorstores import Chroma 
from langchain.chains import RetrievalQA 
import os

Establecemos la clave de API de OpenAI como una variable de entorno para autorizar las solicitudes al servicio de OpenAI. 

1
os.environ['OPENAI_API_KEY'] = "YOUR-API-KEY"

Se utiliza un cargador de documentos para cargar los logs desde un archivo específico (OpenSSH_2k.log). 

1
2
loader = TextLoader('data/OpenSSH_2k.log') 
documents = loader.load()

Los logs cargados se dividen en textos más pequeños para facilitar el procesamiento y la generación de embeddings. 

1
2
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200) 
texts = text_splitter.split_documents(documents)

Se crea un objeto para generar embeddings utilizando la API de OpenAI. 

1
embeddings = OpenAIEmbeddings()

Se crea un almacén de vectores para almacenar los embeddings generados a partir de los textos divididos. 

1
store = Chroma.from_documents(texts, embeddings, collection_name="logs")

Se configura un modelo de recuperación de preguntas y respuestas utilizando el modelo de lenguaje natural de OpenAI. El almacén de vectores se utiliza como recuperador para buscar respuestas a las preguntas. 

1
2
llm = OpenAI(temperature=0) 
chain = RetrievalQA.from_chain_type(llm, retriever=store.as_retriever())

Se invoca al modelo de recuperación de preguntas y respuestas con una pregunta específica sobre los eventos de seguridad en los logs. 

1
2
3
result = chain.invoke("""Como analista de seguridad analiza el siguiente 
log y enumera cada uno de los eventos que pueda ser de interés informando  
de la fecha del evento y del motivo. Responde en castellano""")

Se imprimen los resultados de la invocación, que incluyen la respuesta del modelo a la pregunta realizada. 

1
print(result['result'])

En resumen, este código carga logs de un archivo, los divide en textos más pequeños, genera embeddings para estos textos, crea un almacén de vectores para almacenar los embeddings, configura un modelo de recuperación de preguntas y respuestas utilizando la API de OpenAI, y finalmente, invoca el modelo con una pregunta específica sobre los eventos de seguridad en los logs.

Y al ejecutarlo obtenemos la siguiente respuesta: 

1
2
3
4
5
El log muestra una serie de eventos relacionados con intentos de acceso no autorizados a través de SSH desde la dirección IP 187.141.143.180. Estos eventos ocurrieron el 10 de diciembre a las 09:16:43, 09:15:07, 09:15:23 y 09:18:33. 

El primer evento registrado a las 09:16:43 indica que se ha detectado un posible intento de intrusión desde la dirección IP mencionada. A continuación, a las 09:16:43, se registra un intento de autenticación fallido para el usuario root desde la misma dirección IP. A las 09:16:45, se registra un intento de acceso fallido para el usuario root desde el puerto 33456. A continuación, a las 09:16:45, se registra una desconexión del host remoto. 

A las 09:16:48, se registra un nuevo intento de intrusión desde la misma dirección IP, pero esta vez se intenta acceder con el usuario eoor, que no existe en el sistema. A las 09:16:48

Solo anotar que la información resultante puede ser crucial durante una intrusión real, permitiéndonos concentrarnos en la gestión de la intrusión y ahorrándonos mucho tiempo.

Llama3

Para usar Llama3 desde nuestra computadora, necesitamos tener Ollama instalado. Podemos hacerlo mediante el script de instalación proporcionado en su página web ollama.

Es importante tener en cuenta que, para obtener una buena velocidad de respuesta, se requiere una buena tarjeta gráfica, preferiblemente de Nvidia.

Una vez instalado, podemos acceder a distintos modelos:

En este ejemplo, utilizaremos Llama3, el modelo liberado por Meta.

Para ponerlo en marcha, si no disponemos de los modelos descargados ejecutaremos los siguientes comandos: 

1
2
ollama pull mxbai-embed-large 
ollama pull meta3

y una vez dispongamos de los modelos iniciaremos el servidor. 

1
ollama serve

Como veremos el código es parecido al anterior, realiza una serie de acciones utilizando las librerias ollama y chromadb para analizar un conjunto de logs y generar una respuesta a una pregunta sobre esos logs.

Importamos las librerías necesarias. 

1
2
3
import ollama 
import chromadb 
import datetime

Obtenemos los registros del log de fichero. 

1
2
with open("data/OpenSSH_2k.log", "r") as f: 
    log = f.readlines()

Se establece una conexión con ChromaDB. 

1
client = chromadb.Client()

Se crea una colección en ChromaDB llamada “log” y se combina todo el texto de los logs en una sola cadena 

1
2
collection = client.create_collection(name="log") 
log_text = ''.join(log)

Se genera un embedding para el texto completo de los logs utilizando Ollama. 

1
2
response = ollama.embeddings(model="mxbai-embed-large", prompt=log_text) 
embedding = response["embedding"]

Se agrega el embedding y el texto de los logs a la colección en ChromaDB 

1
collection.add(ids=["full_log"], embeddings=[embedding], documents=[log_text])

Se define una pregunta sobre los logs 

1
2
3
prompt = """Como analista de seguridad analiza el siguiente  
log y enumera cada uno de los eventos que puedan ser de interés, informando  
la fecha del evento y el motivo. Responde en castellano"""

Se genera un embedding para la pregunta utilizando Ollama 

1
2
3
4
response = ollama.embeddings( 
  prompt=prompt, 
  model="mxbai-embed-large" 
)    (sembla que els  2 signes de parèntesi ( ), estan descolocats ?)

Se realiza una consulta a ChromaDB utilizando el embedding de la pregunta 

1
2
3
4
results = collection.query( 
  query_embeddings=[response["embedding"]], 
  n_results=1 
)

Se obtienen los datos de los resultados de la consulta 

1
data = results['documents'][0][0]

Se genera una respuesta utilizando el modelo Llama3 de Ollama, utilizando los datos obtenidos y la pregunta definida anteriormente 

1
2
3
4
output = ollama.generate( 
  model="llama3", 
  prompt=f"Usando estos datos: {data}. Responde este prompt: {prompt}" 
)

Se imprime la respuesta generada 

1
print(output['response'])

Una de las diferencias relevantes del código es que en este caso estamos usando dos modelos, uno más pequeño mxbai-embed-large que nos ayuda a generar el embedding y ** llama3 ** que es el que nos responde a nuestra consulta.

Dependiendo de las capacidades de nuestra computadora esta tardará más o menos en la ejecución de la consulta, en mi caso en unos pocos segundos he obtenido la respuesta.

Ejecutaremos el script analizando el mismo log y realizando la misma consulta y este es el resultado: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

Análisis de seguridad del log de sshd: 

**Evento 1:** Fecha: Dec 10 06:55:46, Motivo: Inicio de sesión remota. 

* Evento interesante: El inicio de sesión remoto puede ser un indicador de una actividad sospechosa si no está relacionado con una tarea programada o no se ha realizado una autorización previa. 

**Evento 2:** Fecha: Dec 10 06:55:46, Motivo: Intento de autenticación con el usuario "guest". 

* Evento interesante: El intento de autenticación con un usuario inválido puede ser un indicador de actividad maliciosa. Es importante verificar las configuraciones de seguridad y la lista de autorizados para evitar acceso no autorizado.  

**Evento 3:** Fecha: Dec 10 06:55:46, Motivo: Intento de autenticación con el usuario "user". 

* Evento interesante: Otro intento de autenticación con un usuario inválido puede ser un indicador de actividad maliciosa. Es importante investigar y analizar las configuraciones de seguridad para determinar si se produce un acceso no autorizado. 

**Evento 4:** Fecha: Dec 10 11:04:37, Motivo: Intento de autenticación con el usuario "guest". 

* Evento interesante: Otra tentativa de autenticación con el mismo usuario inválido puede ser un indicador de actividad maliciosa. Es importante verificar las configuraciones de seguridad y la lista de autorizados para evitar acceso no autorizado. 

**Evento 5:** Fecha: Dec 10 11:04:40, Motivo: Intento de autenticación con el usuario "guest". 

* Evento interesante: El intento de autenticación con un usuario inválido puede ser un indicador de actividad maliciosa. Es importante investigar y analizar las configuraciones de seguridad para determinar si se produce un acceso no autorizado. 

**Evento 6:** Fecha: Dec 10 11:04:41, Motivo: Intento de autenticación con el usuario "user". 

* Evento interesante: Otro intento de autenticación con un usuario inválido puede ser un indicador de actividad maliciosa. Es importante verificar las configuraciones de seguridad y la lista de autorizados para evitar acceso no autorizado. 

En general, los eventos que pueden ser de interés son: 

* Intentos de autenticación con usuarios inválidos o no autorizados. 
* Inicio de sesión remota sin previa autorización. 
* Eventos repetidos en un breve período de tiempo, lo que puede indicar una actividad maliciosa. 

Es importante analizar cuidadosamente estos eventos y verificar las configuraciones de seguridad para determinar si se produce un acceso no autorizado.

Conclusiones

Con Hadoop y Spark, y las técnicas de Big Data, podemos aprovechar el poder de la información que nos proporciona la era digital. Aunque no son las únicas herramientas disponibles, son un buen punto de partida para iniciarse en el análisis de datos y en las técnicas del Big Data.

A través del análisis de datos, las empresas pueden tomar decisiones más inteligentes, optimizar sus procesos y descubrir nuevas oportunidades de negocio.

Por otro lado, haciendo uso de estas técnicas, podemos procesar datos para otros usos, como el que hemos visto en el ejemplo.

Hasta aquí el post de hoy. Espero haya sido de vuestro interés.

No dudéis en contactar mediante el formulario para hacerme llegar vuestros comentarios.