Seis formatos comuns de arquivos de log

Os logs são um componente essencial de qualquer sistema de TI e facilitam todas estas ações:

• Monitorar o desempenho da infraestrutura
• Detectar bugs em aplicações
• Conduzir análise de causa-raiz
• Investigar incidentes de segurança
• Monitorar o comportamento do usuário
• … E muito mais.

Para aproveitar inteiramente seus logs, você precisa de um sistema robusto de gerenciamento de log que seja capaz de lidar com os vários formatos estruturados e não estruturados nos quais os logs vêm.

Uma solução de gerenciamento de log bem projetada realizará ingestão, parsing e armazenamento de logs, independentemente dos formatos desses logs. Isso significa que você pode pesquisar, analisar e correlacionados dados de diferentes sistemas para detectar tendências, criar painéis e até mesmo acionar alertas para aprimorar seus processos de negócios.

Neste artigo, conheceremos os formatos gerais de logs e abordaremos os formatos comumente utilizados nos sistemas de TI.

Uma breve introdução aos formatos de log

Um formato de log define como o conteúdo de um arquivo de log deve ser interpretado. Geralmente, um formato especifica:

• Se o conteúdo do log é estruturado ou não estruturado
• Se os dados são binários ou texto simples
• Que tipo de codificação o arquivo de log usará
• Como os registros são delimitados

Os formatos de log também podem definir os campos contidos no arquivo de log e os tipos de dados desses campos. Por exemplo, name=text ou age=number.  Campos especiais, como carimbos de data/hora, geralmente têm formatos predefinidos (como ISO 8601, que seria exibido como 2022-07-10 15:21:00.000).

Geralmente, as aplicações definem seus formatos de log disponíveis Às vezes, a aplicação dá ao usuário uma opção de formato (por exemplo, JSON ou CSV). Nos casos de dispositivos de hardware, os fabricantes geralmente definem os tipos de log a serem usados.

Logs estruturados, semiestruturados e não estruturados

Os arquivos de log vêm em formatos estruturados, semiestruturados ou não estruturados.

Formatos de log estruturados seguem um padrão claro e consistente e podem ser lidos por humanos e máquinas. Às vezes, os campos são separados por um caractere como vírgula (como em arquivos CSV), espaço ou hífen. Eles também podem se unidos por um sinal de igual (=) (por exemplo, name=Jane ou city=Paris).

A maioria dos sistemas de gerenciamento de log tem parsers pré-configurados integrados e pode ingerir facilmente formatos de log estruturados. Veja abaixo um exemplo de um arquivo de log estruturado:

[{
"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"
}]
}]

Os formatos de log não estruturado não utilizam um padrão específico, mas ainda assim são facilmente legíveis para humanos. Isso dificulta a divisão de eventos e a extração de pares de chave-valor durante o parsing. Caso não haja um parser integrado no sistema de gerenciamento de log, o log não estruturado exigirá parsing personalizado, muitas vezes gerando trabalho extra para o engenheiro.

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
Starting process to remove.
Process started.
Process completed.

Logs semiestruturados são facilmente legíveis por humanos, mas também têm um esquema ou padrão que permite a leitura por máquinas. Eles têm separadores de campo e evento mais complexos do que vírgula ou sinal de igual, mas seguem um padrão. Os sistemas de gerenciamento de log podem ingerir logs semiestruturados, mas geralmente exigem um parser para dividir eventos e extrair pares de chave-valor. Geralmente, isso é feito usando expressões regulares ou outro código.

Formatos de log comumente utilizados

Embora os formatos de log variem bastante entre sistemas, aplicações e ferramentas, determinados formatos são usados com mais frequência. Vamos conhecer mais detalhadamente os principais formatos.

JSON

JavaScript Object Notation (JSON) é um dos formatos de log mais comuns. Os logs JSON são semiestruturados e contêm múltiplos pares de chave-valor. Com JSON, os logs podem aninhar dados em diferentes camadas e, ao mesmo tempo, manter a legibilidade do formato para humanos. Esse formato também oferece uma forma de manutenção de tipos de dados, com string, número, booleano, nulo/vazio, objeto ou matriz.

JSON é um formato relativamente novo e geralmente utiliza codificação UTF-8 em repouso e em trânsito, o que o torna acessível aos sistemas operacionais *nix e Windows. Não há restrições sobre a quantidade ou o tipo de dados que podem ser incluídos. Isso funciona bem com bancos de dados NoSQL (ou sem esquema), mas pode exigir um trabalho extra do autor do log para garantir a consistência de tipos de campos entre aplicações e fontes de log.

Este é um exemplo de arquivo 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 do Windows

Os logs de eventos do Windows contêm dados relacionados e eventos que ocorrem no sistema operacional Windows. Eventos de segurança, aplicação, sistema e DNS são alguns exemplos de logs desses eventos, e todos usam o mesmo formato de log.

Os administradores de sistema usam frequentemente os logs de eventos do Windows para solucionar erros de sistema e aplicação, investigar incidentes de segurança ou rastrear logins de usuários. Geralmente, esses logs são bastante detalhados e incluem informações como carimbo de data/hora, ID do evento, nome de usuário, nome de host, mensagem e categoria da tarefa.

Este é um exemplo de log de evento do Windows:

An account was successfully logged on.
Subject:
Security ID: SYSTEM
Account Name: DESKTOP-LLHJ389$
Account Domain: WORKGROUP
Logon ID: 0x3E7
Logon Information:
Logon Type: 7
Restricted Admin Mode: -
Virtual Account: No
Elevated Token: No
Impersonation Level: Impersonation
New Logon:
Security ID: AzureADRandyFranklinSmith
Account Name: rsmith@montereytechgroup.com
Account Domain: AzureAD
Logon ID: 0xFD5113F
Linked Logon ID: 0xFD5112A
Network Account Name: -
Network Account Domain: -
Logon GUID: {00000000-0000-0000-0000-000000000000}
Process Information:
Process ID: 0x30c
Process Name: C:WindowsSystem32lsass.exe
Network Information:
Workstation Name: DESKTOP-LLHJ389
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Negotiate
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

CEF

Formato de evento comum (CEF) é um formato de log aberto e baseado em texto usado para dispositivos e aplicações de segurança. Desenvolvido pelo ArcSight Enterprise Security Manager, o CEF é usado na coleta e agregação de dados pelo SIEM e por sistemas de gerenciamento de log.

Os logs do CEF usam codificação UTF-8 e incluem um prefixo comum, um cabeçalho CEF e uma extensão variável que contém uma lista de pares de chave-valor.

O prefixo contém o carimbo de data/hora do evento e o nome do host. O cabeçalho inclui a versão do software CEF, fabricante, produto e versão do dispositivo, ID da classe do evento do dispositivo, nome e gravidade. O restante da mensagem do log abrange campos personalizados adicionais para enriquecê-lo.

Este é um exemplo de entrada que utiliza o 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

O Formato de log comum (CLF) NCSA é um dos formatos de log mais antigos usados pelos servidores Web. Trata-se de um arquivo de log padronizado e baseado em texto com um formato fixo, o que significa que seus campos não podem ser personalizados. Cada linha no arquivo de log inclui:

• Endereço do host remoto
• Nome do log remoto
• Username
• Timestamp
• Solicitação e versão do protocolo
• Código do status HTTP
• Bytes enviados

Um hífen é usado para representar um campo que não contém dados para esse evento, e um sinal de mais (+) representa caracteres não suportados.

Aqui está um exemplo 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

O Formato de log estendido (ELF) é usado por aplicações Web. O ELF é semelhante ao CLF, mas contém mais informações e mais flexibilidade com relação a quais campos são usados. Os logs ELF contêm dados relacionados a uma única transação HTTP. Os campos são separados por espaços em branco, e um hífen representa um campo ausente.

O início do log contém informações relacionadas a versão, data, hora, software e quaisquer comentários relevantes. Essas informações são precedidas pelo símbolo de cerquilha (#). O log também contém os nomes dos campos, facilitando para os manipuladores de log executar parsing de todos os campos.

W3C

O Formato de arquivo de log estendido W3C é um formato de log altamente personalizável usado por servidores Windows IIS. É possível configurar quais campos incluir, reduzindo o tamanho dos arquivos de log e mantém somente as informações relevantes. Os campos disponíveis incluem:

• Timestamp
• IP do cliente
• IP do servidor
• URI-Stem
• Código do status HTTP
• Bytes enviados
• Bytes recebidos
• Tempo decorrido
• Versão

Alguns campos têm o prefixo s (servidor), c (cliente), sc (ação de servidor para cliente) ou cs (ação de cliente para servidor) para indicar se está relacionado ao lado do servidor ou do cliente.

Aqui está um exemplo de um 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

Descubra a plataforma nativa de IA líder global para SIEM e gerenciamento de log de última geração

Eleve sua cibersegurança com o CrowdStrike Falcon^®, a principal plataforma nativa de IA para SIEM e gerenciamento de log. Experimente registro de log de segurança em uma escala de petabytes, optando por nativo em nuvem ou implementação auto-hospedada. Registre seus dados com uma arquitetura avançada e livre de índices, sem gargalos e que permite investigação de ameaças com mais de 1 PB de ingestão de dados por dia. Assegure capacidades de pesquisa em tempo real para superar os adversários, atingindo latência de menos de um segundo para consultas complexas. Aproveite uma visibilidade completa, consolidando os dados para quebrar silos e possibilitar que as equipes de segurança, TI e DevOps investiguem ameaças, monitorem o desempenho e garantam a conformidade perfeitamente em 3 bilhões de eventos e em menos de um segundo.