Como centralizar logs de servidores e equipamentos de rede

Por que logs espalhados atrapalham qualquer investigação

Servidores, firewalls, switches e pontos de acesso registram o que acontece com eles. Na maioria das empresas, porém, esses registros ficam presos em cada equipamento. O Windows Server guarda os eventos no próprio Visualizador de Eventos. O firewall mantém um buffer em memória que se apaga quando ele reinicia. O switch guarda algumas centenas de linhas e descarta o restante. Quando algo dá errado, alguém precisa entrar em um aparelho por vez, exportar arquivos em formatos diferentes e montar a linha do tempo à mão, com pressa.

Num incidente de segurança, esse atraso custa caro. Um acesso indevido costuma deixar rastros em vários lugares ao mesmo tempo. Pode ser uma conexão VPN aceita no firewall, seguida de um logon bem-sucedido no controlador de domínio e da criação de um serviço novo no servidor de arquivos. Vistos em separado, nenhum desses eventos parece grave. Reunidos numa mesma tela e com os horários alinhados, eles contam a história completa do ataque: de onde veio, qual credencial foi usada e o que foi feito depois.

Há ainda um fator que pouca gente considera: o atacante também conhece os logs. Limpar o log de segurança do Windows ou reiniciar um equipamento de rede para apagar o buffer são técnicas comuns para esconder rastros. Se os eventos foram enviados a um servidor central no momento em que aconteceram, apagá-los na origem não adianta nada. E a própria limpeza passa a ser uma evidência a investigar.

O que vale a pena centralizar

Centralizar tudo sem critério gera volume e custo de armazenamento sem melhorar a investigação. O melhor é começar pelas fontes que respondem às perguntas mais comuns num incidente: quem acessou, de onde, quando e o que fez. Em ambientes corporativos, essas fontes costumam ser:

• Controladores de domínio (Active Directory): logons, falhas de autenticação, bloqueios de conta, criação de usuários e mudanças em grupos com privilégios elevados.
• Firewalls e concentradores de VPN: conexões aceitas e negadas, sessões VPN, mudanças de regra e acessos administrativos ao próprio equipamento.
• Servidores Windows e Linux: instalação de serviços, execução de processos, falhas de aplicação e acessos por RDP e SSH.
• Switches, roteadores e access points: quedas de link, mudanças de configuração, logins administrativos e eventos de spanning tree.
• Serviços em nuvem: registros de entrada do Microsoft 365 e do Entra ID, onde hoje se concentra boa parte dos ataques a credenciais.

Com essas fontes reunidas, a maioria das perguntas de um incidente pode ser respondida em minutos, não em dias. Depois, a cobertura pode crescer aos poucos para servidores de aplicação, bancos de dados, backup e antivírus corporativo. Antes de incluir cada nova fonte, pergunte se aquele log ajuda a detectar ou explicar algum problema real. Se não ajuda, ele só ocupa espaço.

Syslog: o padrão para equipamentos de rede e Linux

O Syslog é o protocolo mais usado para enviar logs pela rede. Quase todo firewall, switch gerenciável, roteador, storage e servidor Linux consegue mandar mensagens Syslog para um coletor remoto. A configuração costuma ser simples: basta informar o endereço do servidor central, a porta e o nível mínimo de severidade a enviar. Em servidores Linux, o rsyslog e o syslog-ng fazem esse envio e também podem receber mensagens de outros equipamentos.

Alguns cuidados fazem diferença na prática:

• Prefira TCP ou TLS quando o equipamento permitir. O Syslog tradicional usa UDP na porta 514, que não confirma a entrega. Se a rede congestionar, mensagens se perdem sem aviso. O envio por TCP, ou por TLS na porta 6514 (RFC 5425), garante a entrega e protege o conteúdo no caminho.
• Escolha bem a severidade. Enviar tudo em nível debug inunda o coletor. Enviar só erros críticos deixa de fora logins administrativos e mudanças de configuração. Para firewalls e switches, o nível informational costuma ser o equilíbrio.
• Identifique a origem. Configure o hostname correto em cada equipamento. Uma mensagem vinda de "router" ou de um IP sem nome atrapalha a análise justamente quando o tempo é curto.
• Isole o coletor. O servidor de logs deve ficar numa rede de gerência e aceitar conexões apenas dos equipamentos autorizados.

No servidor que recebe os dados, ferramentas como Graylog, Wazuh e Elastic Stack interpretam os campos de cada fabricante e permitem buscar por IP, usuário, equipamento ou período. Assim, milhares de linhas de texto viram informação pesquisável. Uma pergunta como "o que esse IP fez na rede ontem à noite?" passa a ter resposta em segundos.

Event Log do Windows: encaminhamento nativo ou agente

O Windows não usa Syslog de forma nativa. Os eventos ficam nos logs de Aplicativo, Sistema e Segurança, além de dezenas de canais específicos. Há dois caminhos principais para centralizá-los. O primeiro é o Windows Event Forwarding (WEF), um recurso nativo do sistema. Nele, os servidores enviam eventos a um Windows Event Collector via WinRM, e as assinaturas são distribuídas por Política de Grupo. Não exige software adicional e funciona bem em ambientes com domínio. O segundo caminho é instalar um agente, como Wazuh, NXLog, Winlogbeat ou Azure Monitor Agent. Ele lê os eventos no próprio servidor e os envia à plataforma de logs, em geral com mais opções de filtro e formatação.

Antes de encaminhar, porém, é preciso garantir que os eventos certos estão sendo gerados. A auditoria padrão do Windows deixa lacunas importantes. Além disso, o log de Segurança costuma ser pequeno demais para um servidor movimentado: num controlador de domínio com muitos usuários, eventos antigos podem ser sobrescritos em poucas horas. Ajuste a Política de Auditoria Avançada por GPO e priorize eventos como:

1. 4624 e 4625: logon bem-sucedido e falha de logon, com o tipo de logon (rede, interativo ou remoto via RDP).
2. 4740: conta bloqueada, útil para identificar tentativas de força bruta.
3. 4720, 4728 e 4732: criação de conta e inclusão de membros em grupos de segurança.
4. 4688: criação de processo, de preferência com o registro da linha de comando habilitado.
5. 7045: instalação de um novo serviço, técnica comum quando o atacante tenta se espalhar para outros servidores.
6. 1102: limpeza do log de auditoria, que quase sempre merece investigação imediata.

Não adianta centralizar logs que nunca foram gerados. Revise a política de auditoria antes de escolher a ferramenta. É ela que define o que você vai conseguir enxergar no dia do incidente.

Horário, retenção e integridade: o que torna o log confiável

Uma linha do tempo só funciona se todos os relógios estiverem de acordo. Se o firewall está cinco minutos à frente do controlador de domínio, eventos que aconteceram em sequência aparecem fora de ordem e a análise se perde. Configure NTP em todos os equipamentos, usando a mesma fonte de referência. Padronize também o fuso horário: use o horário local em todos, ou grave tudo em UTC e converta na visualização. O importante é ter uma regra única.

A segunda decisão importante é a retenção. Muitos incidentes só são descobertos semanas ou meses depois da invasão inicial, e logs de sete dias não permitem reconstruir o que aconteceu. Defina o prazo de guarda conforme a política interna, os contratos com clientes, as normas do seu setor e as obrigações legais aplicáveis. O Marco Civil da Internet, por exemplo, fixa prazos mínimos de guarda de registros de acesso para provedores de aplicação. Uma prática comum é manter alguns meses em armazenamento rápido, para busca, e períodos maiores em armazenamento compactado e mais barato.

Por fim, proteja o próprio servidor de logs. Ele precisa de acesso restrito, autenticação forte e backup e, se possível, armazenamento imutável ou com escrita controlada. Logs também contêm dados pessoais, como nomes de usuário, endereços IP e às vezes e-mails, e por isso estão sujeitos à LGPD. Dê acesso só a quem precisa e registre quem consultou o quê. Um repositório de logs mal protegido vira ele mesmo um alvo.

Do log centralizado à resposta rápida

Com os logs reunidos, o próximo passo é colocá-los para trabalhar a seu favor. Crie alertas para situações que pedem ação imediata, por exemplo:

• várias falhas de logon seguidas de um logon bem-sucedido;
• inclusão de um usuário no grupo Domain Admins;
• limpeza do log de auditoria;
• acesso administrativo ao firewall fora do horário comercial;
• VPN conectada de um país onde a empresa não opera.

Monte painéis simples para acompanhar tendências e deixe prontas as consultas para as perguntas mais comuns de uma investigação. Assim, quando o incidente acontecer, a equipe não começa do zero.

A Duk Informática & Cloud ajuda empresas a percorrer exatamente esse caminho. Definimos quais fontes centralizar e configuramos o Syslog e o encaminhamento de eventos do Windows. Também ajustamos as políticas de auditoria, sincronizamos os relógios e dimensionamos a retenção conforme a realidade de cada negócio. São mais de 18 anos de experiência e mais de 550 empresas atendidas. Como Microsoft Gold Partner, integramos servidores locais, Active Directory e Microsoft 365 numa visão única, com suporte 24/7 e data center próprio em Alphaville.

Se hoje os seus logs estão espalhados por servidores e equipamentos de rede, comece por um diagnóstico: quais eventos estão sendo gerados, onde estão guardados e por quanto tempo. A partir daí, centralizar deixa de ser um projeto distante e vira uma camada prática de segurança, que faz diferença no dia em que você mais precisar dela. Fale com a equipe da Duk para avaliar o seu ambiente.