Los logs son un componente esencial de cualquier sistema de TI y, además, te ayudan a:

• monitorizar el rendimiento de la infraestructura;
• detectar errores en aplicaciones;
• realizar un análisis de causa raíz;
• investigar incidentes de seguridad;
• hacer un seguimiento del comportamiento del usuario;
• ...y mucho más.

Para sacarles todo el partido, necesitas un sistema de gestión de logs sólido capaz de manejar los diferentes formatos estructurados y no estructurados en los que se presentan.

Una solución de gestión de logs bien diseñada ingerirá, analizará y almacenará los logs, independientemente de sus formatos. Esto te permitirá buscar, analizar y correlacionar datos de diferentes sistemas para identificar tendencias, crear paneles e incluso activar alertas para mejorar los procesos empresariales.

En este artículo, analizaremos los formatos de log generales y mencionaremos algunos de los más utilizados entre sistemas de TI.

Breve introducción a los formatos de log

El formato define cómo se deben interpretar los datos de un archivo de log. Por lo general, el formato especifica:

• si los contenidos del log están estructurados o no estructurados;
• si los datos se encuentran en texto sin formato o formato binario;
• el tipo de codificación que utilizará el log;
• cómo se delimitan los registros.

Los formatos de log también pueden definir los campos que contiene el archivo de log y los tipos de datos para esos campos. Por ejemplo, name=text o age=number.  Algunos campos especiales, como las marcas de tiempo, suelen tener formatos predefinidos, (por ejemplo, ISO 8601, que se mostrará como 2022-07-10 15:21:00.000).

Normalmente, las aplicaciones definen el formato de log que utilizan. A veces, ofrecen al usuario la opción de elegir entre varios (por ejemplo, JSON o CSV). En cuanto a los dispositivos de hardware, son los fabricantes los que determinan los tipos de log que se pueden usar.

Logs estructurados, semiestructurados y no estructurados

Los archivos de log pueden estar en formatos estructurados, semiestructurados y no estructurados.

Los formatos de log estructurados tienen un patrón claro y coherente, y pueden leerlos tanto humanos como máquinas. Los campos se separan a veces con caracteres como una coma (en archivos CSV), un espacio o un guion. También pueden unirse mediante un signo de igual (=) (por ejemplo, name=Jane o city=Paris).

La mayoría de sistemas de gestión de logs cuentan con analizadores preconfigurados y pueden ingerir fácilmente formatos de log estructurados. El siguiente es un ejemplo de archivo de log estructurado:

[{
"Env" : "Prod",
"ServerName" : "LAPTOP123",
"AppName" : "Console1.vmhost.exe",
"AppLoc" : "C:Teststackify-api-dotnetdstConsoleApplication1binDebugConsole1.vmhost.exe",
"Logger" : "StackifyLib.net",
"Msgs" : [{
"Msg" : "Incoming metrics data",
"data" : "{"clientid":12345}",
"EpochMs" : 1445345672470,
"Level" : "INFO",
"id" : "0c12301b-e4ge-11e6-8933-897567896a4"
}]
}]

Aunque son fáciles de leer para las personas, los formatos de log no estructurados no utilizan un patrón particular. Esto dificulta la división de eventos y la extracción de pares clave-valor durante el análisis. Si el sistema de gestión de logs no incluye un analizador, los logs no estructurados requerirán un análisis personalizado, lo que aumentará la carga de trabajo del ingeniero.

2018-10-25 11:56:35,008 INFO  [LAPTOP321-1-3]  c.a.c.d.RFC4519DirectoryMembershipsIterable Found 7 children for 7 groups in 2 ms
Iniciando el proceso de eliminación.
Proceso iniciado.
Proceso completado.

Los logs semiestructurados cuentan con un esquema o patrón, por lo que los pueden leer tanto humanos como máquinas. Incluyen separadores de eventos y campos más complejos que una coma o el signo de igual, pero no tienen un patrón. Los sistemas de gestión de logs pueden ingerir este tipo de logs, pero requieren un analizador para dividir los eventos y extraer los pares clave-valor. Esto se consigue mediante expresiones regulares u otro código.

Formatos de log más utilizados

Aunque los formatos de log varían ampliamente entre sistemas, aplicaciones y herramientas, algunos se utilizan con mayor asiduidad. Veamos los más destacados a continuación.

JSON

La Notación de Objetos de JavaScript o JSON (del inglés JavaScript Object Notation) es uno de los formatos de log más utilizados. Estos logs son semiestructurados y contienen varios pares clave-valor. Con JSON, los logs pueden anidar los datos en distintas capas en un formato fácil de leer para los humanos. También proporciona una forma de conservar los tipos de datos, como cadena, número, booleano, nulo/vacío, objeto o matriz.

Al ser un formato relativamente nuevo, JSON utiliza la codificación UTF-8 en reposo y en tránsito, por lo que es accesible tanto para los sistemas operativos *nix como para Windows. No hay restricciones en cuanto al número de campos que se pueden incluir. Esto funciona bien con bases de datos NoSQL (o sin esquema), pero puede requerir trabajo adicional por parte del autor del log para garantizar la coherencia de los tipos de campo entre las aplicaciones y las fuentes del log.

Este es un ejemplo de archivo de log JSON:

{
"timestamp": "2022-07-29T02:03:45.293Z",
"message": "User Jane.Doe has logged in",
"log": {
"level": "info",
"file": "auth.c",
"line": 66,
},
"user": {
"name": "jane.doe",
"id": 235
},
"event": {
"success": true
}
}

Logs de eventos de Windows

Los logs de eventos de Windows contienen datos relacionados con los eventos que se producen en el sistema operativo Windows, como eventos de seguridad, aplicación, sistema o DNS. Todos emplean el mismo formato.

Los logs de eventos de Windows ayudan a los administradores del sistema a resolver problemas o errores de aplicaciones, investigar incidentes de seguridad o rastrear los inicios de sesión de los usuarios. Suelen ser muy detallados e incluyen información como marca de tiempo, ID de evento, nombre de usuario, nombre de host, mensaje y categoría de tarea.

Este es un ejemplo de log de evento de Windows:

Una cuenta ha iniciado sesión correctamente.
Asunto:
ID de seguridad: SISTEMA
Nombre de cuenta: DESKTOP-LLHJ389$
Dominio de cuenta: WORKGROUP
ID de inicio de sesión: 0x3E7
Información de inicio de sesión:
Tipo de inicio de sesión: 7
Modo de administrador restringido: -
Cuenta virtual: No
Token elevado: No
Nivel de suplantación: suplantación
Nuevo inicio de sesión:
ID de seguridad: AzureADRandyFranklinSmith
Nombre de cuenta: rsmith@montereytechgroup.com
Dominio de cuenta: AzureAD
ID de inicio de sesión: 0xFD5113F
ID de inicio de sesión vinculado: 0xFD5112A
Nombre de cuenta de red: -
Dominio de cuenta de red: -
GUID de inicio de sesión: {00000000-0000-0000-0000-000000000000}
Información de proceso:
ID de proceso: 0x30c
Nombre de proceso: C:WindowsSystem32lsass.exe
Información de red:
Nombre de la estación de trabajo: DESKTOP-LLHJ389
Dirección de red de origen: -
Puerto de origen: -
Información de autenticación detallada:
Proceso de inicio de sesión: negociar
Paquete de autenticación: negociar
Servicios transitados: -
Nombre de paquete (solo NTLM): -
Longitud de la clave: 0

CEF

El formato de evento común o CEF (del inglés Common Event Format) es un formato de log abierto basado en texto que utilizan las aplicaciones y los dispositivos relacionados con la seguridad. Desarrollado por ArcSight Enterprise Security Manager, CEF se utiliza para recopilar y agrupar datos en sistemas SIEM y de gestión de logs.

Los logs CEF utilizan la codificación UTF-8 e incluyen un prefijo común, un encabezado CEF y una extensión variable que contiene una lista de pares clave-valor.

El prefijo contiene la marca de tiempo del evento y el nombre del host. El encabezado incluye la versión del software CEF, el proveedor del dispositivo, el producto del dispositivo, la versión del dispositivo, el ID de clase de evento del dispositivo, el nombre y la gravedad. El resto del mensaje incluye campos personalizados para enriquecer el log.

El siguiente es un ejemplo de entrada que utiliza CEF:

CEF:0|Trend Micro|Deep Security Manager||600|User Signed In|3|src=10.52.116.160 suser=admin target=admin msg=User signed in from 2001:db8::5

CLF

El formato de log común o CLF (del inglés Common Log Format) de NCSA es uno de los más antiguos utilizados por los servidores web. Se trata de un archivo de log estandarizado y basado en texto con un formato fijo, lo que significa que no se pueden personalizar los campos. Cada línea del archivo de log contiene:

• la dirección del host remoto;
• el nombre del log remoto;
• el nombre de usuario;
• la marca de tiempo;
• la versión de la solicitud y protocolo;
• el código de estado HTTP;
• los bytes enviados.

Se utiliza un guion para representar un campo que no contiene datos para ese evento, y un signo de más (+) para indicar caracteres no compatibles.

El siguiente es un ejemplo de log CLF:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

ELF

El formato de registro extendido o ELF (del inglés Extended Log Format) se usa en aplicaciones web. Es similar a CLF, pero contiene más información y ofrece flexibilidad sobre los campos que se usan. Los logs ELF contienen datos relacionados con una única transacción HTTP. Los campos se separan con un espacio en blanco, mientras que un guion representa la falta de un campo.

La primera parte del log contiene información relacionada con la versión, la fecha, la hora, el software y cualquier comentario relevante. Viene precedido por una almohadilla (#). El log también contiene los nombres de los campos, lo que facilita la gestión adecuada de los campos por parte de los gestores de logs.

W3C

El formato de archivo de log extendido (W3C) es altamente personalizable y se utiliza en los servidores IIS de Windows. Es posible elegir qué campos se incluyen, lo que permite reducir el tamaño de los archivos de log y conservar solo la información relevante. Los campos disponibles incluyen:

• la marca de tiempo;
• IP del cliente;
• IP del servidor;
• URI-Stem;
• el código de estado HTTP;
• los bytes enviados.
• bytes recibidos;
• tiempo tardado;
• versión.

Algunos campos incluyen el prefijo s (servidor), c (cliente), sc (servidor-cliente) o cs (cliente-servidor) para mostrar si están relacionados con el lado del servidor o del cliente.

El siguiente es un ejemplo de log W3C:

#Software: Internet Information Services 6.0
#Version: 1.0
#Date: 2001-05-02 17:42:15
#Fields: time c-ip cs-method cs-uri-stem sc-status cs-version
17:42:15 172.16.255.255 GET /default.htm 200 HTTP/1.0

Descubre la plataforma con IA nativa líder del mundo para SIEM de nueva generación y gestión de logs

Mejora tu ciberseguridad con CrowdStrike Falcon^®, la principal plataforma nativa de IA para SIEM y gestión de logs. Disfruta de un registro de seguridad a escala de petabytes, con opciones de implementación nativas de la nube o de autoalojamiento. Registra tus datos con una arquitectura potente, sin índices y sin cuellos de botella, que hace posible el Threat Hunting con más de 1 PB de ingesta de datos al día. Disfruta de capacidades de búsqueda en tiempo real para superar al adversario y lograr una latencia inferior a un segundo en consultas complejas. Aprovecha una visibilidad integral que consolida los datos para acabar con los silos y permitir a los equipos de seguridad, TI y DevOps detectar amenazas, monitorizar el rendimiento y garantizar el cumplimiento sin problemas en 3 mil millones de eventos en menos de 1 segundo.