A primeira coisa a registrar em um servidor Linux é a autenticação: quem entrou, de onde, quando e com qual método. Quase toda intrusão passa por uma credencial antes de deixar qualquer outro sinal, e é esse rastro que sustenta a linha de base de logs Linux deste guia. O MITRE ATT&CK documenta o fenômeno na técnica Valid Accounts (T1078): adversários podem obter e abusar credenciais de contas existentes para acesso inicial, persistência, escalada de privilégio ou evasão de defesa — e podem escolher não usar malware junto do acesso legítimo, justamente para dificultar a identificação da presença. Sem uma linha de base de logins bem estabelecida, esse tipo de adversário não gera alerta nenhum.
Este artigo define, em ordem prática, quais fontes de eventos priorizar em um SOC pequeno que monitora servidores Linux, como estabilizar essa coleta com o módulo de integridade de arquivos do Wazuh e como validar cada regra com eventos sintéticos antes de promover anything à operação. Todos os exemplos de laboratório usam eventos gerados em ambiente próprio, com método documentado — nenhum log de terceiros.
O que registrar primeiro
Registre em ordem: autenticação, integridade de arquivos de sistema, execução de comandos com privilégio e, por último, serviços específicos do seu ambiente. A referência consolidada de gestão de logs continua sendo o NIST SP 800-92, publicado em setembro de 2006 por Karen Kent e Murugiah Souppaya, que orienta tratar a coleta de logs como uma infraestrutura própria, com processos de configuração, análise e retenção definidos de forma consistente em toda a organização — e não como ajuste pontual por servidor. O documento descreve o tema de forma de alto nível, sem ser um passo a passo de configuração, mas estabelece o princípio que vale até hoje: o valor do log depende de uma infraestrutura que colete, armazene e proteja os eventos de forma centralizada.
Na prática, isso significa um agente que lê os arquivos locais e envia a um ponto central, com relógio sincronizado (NTP) em todos os hosts — sem timestamp confiável, a correlação entre eventos de máquinas diferentes perde sentido. É o mesmo princípio aplicado na análise de casos reais como o bypass de MFA pelo ransomware Gunra: a investigação só avança quando os eventos de acesso existem e são comparáveis entre si.
Fontes de eventos essenciais
A tabela abaixo resume a ordem de prioridade que eu aplico ao instrumentar um servidor Linux pela primeira vez, com a técnica do ATT&CK que cada fonte ajuda a enxergar:
| Fonte de log | O que revela | Técnica relacionada | Prioridade |
|---|---|---|---|
| /var/log/auth.log (ou secure) | Login SSH, falhas de senha, uso de sudo | T1078 — Valid Accounts | Alta |
| syscheck (FIM) em /etc, /usr/bin, /bin | Binários e configurações alterados ou criados | T1548.001 — Setuid e Setgid | Alta |
| /var/log/cron e timers systemd | Tarefas agendadas criadas ou alteradas | Persistência por agendamento | Média |
| journalctl de serviços expostos | Abuso de serviço acessível remotamente | Depende do serviço | Média |
A ordem importa porque autenticação e integridade de arquivos cobrem as duas pontas do ataque: a entrada e a mudança de estado no host. Movimentação lateral com credenciais reais, como no pass-the-hash, também depende de eventos de logon para ser percebida — sem a fonte, a técnica não deixa rastro utilizável.
Linha de base do syscheck
No Wazuh, o módulo syscheck é o mecanismo de monitoramento de integridade de arquivos. Conforme a documentação oficial de referência, a configuração padrão do syscheck monitora /etc, /usr/bin, /usr/sbin, /bin e /sbin, com varredura agendada a cada 43200 segundos — ou seja, duas vezes ao dia por padrão. Para uma linha de base inicial, isso é suficiente para conhecer o estado normal do host; para resposta mais rápida, a mesma referência documenta o atributo realtime, que usa as chamadas de sistema inotify no Linux para monitoramento contínuo de diretórios, e o atributo whodata, que associa a mudança ao usuário e processo responsável.
O primeiro passo com o syscheck não é criar regra: é deixar a primeira varredura completa concluir e observar uma semana de alertas. Esse período define o que é ruído normal no seu ambiente (pacotes que atualizam binários, certificados que giram) e o que é anomalia. A partir daí, todo alerta de mudança em /usr/bin sem janela de manutenção associada vira candidato a investigação.
Do log à regra testada
Um exemplo concreto, executado em laboratório com artefatos próprios (é um exemplo meu, não um caso medido): crio um binário inofensivo em /tmp, aplico permissão elevada com o utilitário nativo e verifico o resultado. O MITRE ATT&CK documenta, na sub-técnica T1548.001, que chmod u+s define o bit setuid em um arquivo e o comando find / -perm +4000 lista binários com esse bit habilitado — a mesma página registra que adversários abusam de binários com esses bits para executar código em contexto privilegiado. A regra que faz sentido no SOC é justamente essa combinação: chmod definindo setuid em caminho gravável por usuário comum, seguido de execução com privilégio, é o padrão anômalo; um setuid novo em /usr/bin durante uma atualização de pacote é o padrão benigno.
Valide a regra de ponta a ponta com eventos sintéticos antes de promovê-la: gere o comando de mudança em um host de teste, confirme que o alerta chega ao servidor central e registre no campo de falsos positivos tudo que disparou sem ser ataque. Esse ciclo — evento gerado, alerta observado, causa documentada — é o mesmo usado ao montar um primeiro SIEM com logs sintéticos.
Checklist de implantação em produção
- Sincronize NTP em todos os hosts antes de coletar qualquer log.
- Ative a coleta de /var/log/auth.log (ou secure) em todos os servidores Linux.
- Deixe o syscheck ativo com a configuração padrão por uma semana para estabelecer a linha de base.
- Classifique os alertas da semana de base em benigno conhecido, manutenção e anomalia.
- Escreva regras apenas para as anomalias, validadas com evento sintético de ponta a ponta.
- Centralize os eventos em armazenamento que o host comprometido não consiga apagar — log que vive só na máquina vira alvo de limpeza pelo invasor.
O limite deste guia é claro: ele estabelece a coleta e a linha de base, não garante que toda intrusão será identificada. Regras só cobrem o que foram desenhadas para cobrir, e falsos positivos vão existir; o que a linha de base garante é que a evidência exista quando a investigação começar.
