Análise de Logs para Monitoramento e Resposta a Incidentes

CompTIABeginner
Pratique Agora

Introdução

Nos campos de administração de sistemas e cibersegurança, a análise de logs é uma habilidade crítica. Os logs do sistema registram uma ampla gama de eventos, desde operações rotineiras até erros críticos e possíveis violações de segurança. Ser capaz de navegar e interpretar efetivamente esses logs é essencial para monitorar a saúde do sistema, solucionar problemas e responder a incidentes de segurança.

Este laboratório apresenta o journalctl, a ferramenta padrão para consultar e exibir logs do serviço journald em sistemas Linux modernos. Você aprenderá a realizar tarefas básicas de análise de logs que formam a base do monitoramento e da resposta a incidentes.

Ao longo deste laboratório, você irá:

  • Revisar os logs de inicialização do sistema.
  • Filtrar logs para encontrar eventos específicos, como falhas de autenticação.
  • Simular e detectar um evento suspeito.
  • Exportar logs para análise posterior.

Revisar Logs de Inicialização do Sistema com Journalctl

Nesta etapa, você aprenderá a usar o comando journalctl para revisar os logs do sistema, focando especificamente nas mensagens geradas durante o processo de inicialização mais recente. Este é um primeiro passo comum ao diagnosticar problemas de inicialização.

O comando journalctl permite consultar o conteúdo do journal do systemd. Sem nenhum argumento, ele exibe todos os logs, o que pode ser avassalador.

Para tornar a saída mais gerenciável, podemos usar o sinalizador -b ou --boot para visualizar apenas os logs da sessão de inicialização atual.

Execute o seguinte comando em seu terminal para visualizar os logs da inicialização atual:

journalctl -b

Você verá uma saída paginada começando com as mensagens mais antigas do processo de inicialização. Você pode usar as teclas de seta Para Cima e Para Baixo para navegar. Pressione q para sair do paginador e retornar ao prompt de comando.

-- Journal begins at Tue 2023-10-31 08:30:00 UTC, ends at Tue 2023-10-31 09:00:00 UTC. --
Oct 31 08:30:01 labex-vm kernel: Linux version 5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: KERNEL supported cpus:
Oct 31 08:30:01 labex-vm kernel:   Intel GenuineIntel
Oct 31 08:30:01 labex-vm kernel:   AMD AuthenticAMD
...
(END)

Este comando é inestimável para entender quais serviços iniciaram com sucesso e para identificar quaisquer erros que ocorreram durante a inicialização do sistema.

Filtrar Logs para Falhas de Autenticação

Nesta etapa, você filtrará o journal para encontrar eventos específicos, como tentativas de autenticação falhas, que são críticas para o monitoramento de segurança. Um alvo comum para atacantes é o serviço SSH, portanto, monitorar seus logs é uma alta prioridade.

Podemos usar o sinalizador -u com journalctl para filtrar logs por uma unidade systemd específica. Para o serviço SSH, a unidade é tipicamente ssh.service (no Ubuntu/Debian) ou sshd.service (no Red Hat/CentOS).

Vamos filtrar os logs para ver apenas as entradas relacionadas ao daemon SSH. Observe que você pode precisar usar sudo para visualizar os logs do sistema:

sudo journalctl -u ssh

Este comando mostra todas as entradas de log geradas pelo serviço sshd. Para refinar nossa busca por potenciais problemas de segurança, podemos canalizar esta saída para o comando grep para procurar por palavras-chave como "Failed".

Execute o seguinte comando para encontrar tentativas de senha falhas para o serviço SSH:

sudo journalctl -u ssh | grep "Failed password"

Se não houve tentativas de login falhas recentes, este comando pode não produzir nenhuma saída. Isso é normal em um sistema seguro. Na próxima etapa, geraremos um evento como esse para ver como ele aparece nos logs.

Simular um Evento Suspeito e Analisar Logs

Agora, vamos simular um evento suspeito e, em seguida, usar nossas habilidades de análise de logs para detectá-lo. Um sinal comum de um ataque de força bruta é uma série de tentativas de login falhas. Simularemos uma dessas tentativas tentando fazer SSH em nossa própria máquina (localhost) com um nome de usuário que não existe.

Execute o seguinte comando em seu terminal. Você será solicitado a digitar uma senha; você pode digitar qualquer coisa, pois espera-se que falhe.

ssh non_existent_user@localhost

O sistema negará a conexão, que é o resultado esperado. Você deverá ver uma mensagem como esta:

non_existent_user@localhost's password:
Permission denied, please try again.
non_existent_user@localhost's password:
Permission denied (publickey,password).

Agora que geramos um evento de login falho, vamos executar novamente nosso comando de análise de logs da etapa anterior para ver se conseguimos encontrá-lo.

sudo journalctl -u ssh | grep "Failed password"

Desta vez, o comando deverá produzir uma saída mostrando a tentativa falha que acabamos de fazer.

Oct 31 09:15:12 labex-vm sshd[1234]: Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2

Este exercício simples demonstra o ciclo principal de resposta a incidentes: um evento ocorre, ele é registrado e um administrador ou sistema automatizado analisa os logs para detectá-lo.

Exportar Logs para Simulação de Análise Centralizada

Em um cenário do mundo real, você frequentemente exportaria logs de máquinas individuais para um servidor de logs centralizado (como um SIEM) para armazenamento de longo prazo e correlação. Nesta etapa, simularemos isso exportando nossos logs SSH recentes para um arquivo.

journalctl pode gerar logs em vários formatos. O formato json-pretty é particularmente útil, pois é legível por humanos e facilmente analisado por outras ferramentas.

Vamos exportar todos os logs SSH dos últimos 10 minutos para um arquivo chamado ssh_logs.json em seu diretório atual (~/project).

sudo journalctl -u ssh --since "10 minutes ago" -o json-pretty > ~/project/ssh_logs.json

Agora, verifique se o arquivo foi criado:

ls -l ~/project

Você deverá ver ssh_logs.json na listagem de arquivos.

total 4
-rw-r--r-- 1 labex labex 1234 Oct 31 09:20 ssh_logs.json

Finalmente, vamos visualizar o conteúdo do nosso arquivo de log exportado.

cat ~/project/ssh_logs.json

A saída será um array JSON estruturado, com cada entrada de log como um objeto. Este formato é ideal para ingestão em outras plataformas de análise.

[
    {
        "__CURSOR" : "s=...",
        "__REALTIME_TIMESTAMP" : "...",
        "__MONOTONIC_TIMESTAMP" : "...",
        "_BOOT_ID" : "...",
        "_TRANSPORT" : "syslog",
        "PRIORITY" : "6",
        "SYSLOG_FACILITY" : "4",
        "SYSLOG_IDENTIFIER" : "sshd",
        "MESSAGE" : "Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2",
        "_PID" : "1234",
        ...
    }
]

Você simulou com sucesso o processo de preparação de logs para análise centralizada.

Resumo

Neste laboratório, você adquiriu experiência prática com journalctl, uma ferramenta poderosa para análise de logs em sistemas Linux modernos. Estas são habilidades fundamentais para qualquer administrador de sistema, engenheiro DevOps ou profissional de segurança.

Você aprendeu a:

  • Revisar logs do sistema e de inicialização para diagnosticar problemas de inicialização.
  • Filtrar logs por serviços específicos e conteúdo de mensagens para encontrar eventos relevantes.
  • Identificar atividades suspeitas, como logins falhos, a partir de entradas de log.
  • Exportar logs em um formato estruturado como JSON para armazenamento centralizado e análise posterior.

Dominar essas técnicas permitirá que você monitore melhor seus sistemas, solucione problemas com mais eficiência e dê os primeiros passos na resposta a incidentes de segurança.