Logs e auditoria de acessos no servidor
Os logs respondem a três perguntas: o que quebrou, quem entrou no servidor e o que fez lá. A resposta só existe se os logs estiverem ativados, forem guardados por tempo suficiente e não ficarem apenas no mesmo servidor que pode ter sido invadido. Veja onde encontrá-los no Linux, quais comandos mostram os acessos, como configurar a rotação e o que fazer com antecedência para ter o que analisar depois de um incidente.
No Linux com systemd, dois sistemas gravam logs. O serviço journald, do systemd, reúne as mensagens de todos os serviços, do kernel e dos logins num journal binário. O rsyslog, se estiver instalado, distribui essas mesmas mensagens em arquivos de texto em /var/log. O servidor web, o banco de dados e o Docker mantêm logs próprios. Saber onde fica cada coisa é preciso antes do incidente, não durante.
Onde ficam os logs
- journald. Lido com o comando
journalctl. O journal é gravado em disco se existir o diretório/var/log/journal; caso contrário, fica só na memória e some na reinicialização (journald.conf, parâmetroStorage=auto). Confira isso num servidor novo:ls /var/log/journal. Se o diretório não existir, crie-o e reinicie o serviço:systemctl restart systemd-journald. - Arquivos do sistema. No Ubuntu, logins e sudo vão para
/var/log/auth.log, e as mensagens gerais para/var/log/syslog. No AlmaLinux e no Rocky Linux, são/var/log/securee/var/log/messages. No Debian 12 e posteriores, o rsyslog não é instalado por padrão, e tudo fica só no journald. - Servidor web. O nginx grava em
/var/log/nginx/access.logeerror.log; o Apache, em/var/log/apache2/no Debian e no Ubuntu ou em/var/log/httpd/no AlmaLinux. O log de acesso mostra cada requisição: endereço, hora, caminho, código de resposta, tamanho e navegador. Os campos são definidos pela diretiva log_format; se o site está atrás de uma CDN, configure a passagem do endereço real do visitante, senão o log terá só os endereços da CDN (mais no artigo CDN: quando um site precisa de uma). - Aplicações e Docker. Os bancos de dados gravam nos próprios diretórios em
/var/log, e os contêineres em arquivos do Docker, lidos com o comandodocker logs.
Alguns comandos do journalctl que resolvem a maioria dos casos: journalctl -u nginx --since "1 hour ago" mostra as mensagens de um serviço na última hora; journalctl -p err -b, os erros desde a última inicialização; journalctl -f, o fluxo de mensagens novas; journalctl --disk-usage, quanto espaço o journal ocupa.
Quem entrou no servidor
Cada login por SSH deixa um registro com o nome do usuário, o endereço e o método de autenticação: chave ou senha. Os logins bem-sucedidos podem ser vistos assim:
- no journald:
journalctl -u ssh --since today | grep Accepted(no AlmaLinux o serviço se chamasshd); - no arquivo:
grep Accepted /var/log/auth.logou/var/log/secure; - em resumo: o comando
lastmostra logins e reinicializações, e olastb, as tentativas que falharam.
No Debian 13, os comandos last, lastb e lastlog não existem mais: os arquivos antigos que eles usam não conseguem guardar datas depois de 2038. No lugar deles vêm os pacotes wtmpdb e lastlog2 (notas de lançamento do Debian 13). Os registros Accepted no journal continuam em qualquer versão.
O que verificar. Logins de endereços desconhecidos e em horários incomuns. Logins por senha, se você configurou acesso só por chave: isso significa que a configuração não foi aplicada. Comandos via sudo: no auth.log e no journald consta, para cada um, quem executou o quê. Chaves novas em ~/.ssh/authorized_keys e usuários novos em /etc/passwd: são adicionados para voltar ao servidor depois. Se você precisa de uma auditoria detalhada de alterações em arquivos e de comandos, o Linux tem o subsistema de auditoria auditd, mas as regras dele exigem configuração própria e espaço em disco.
fail2ban: o que ele oferece além do SSH
O fail2ban lê os logs e bloqueia temporariamente os endereços que erram o login repetidas vezes. A instalação e a proteção do SSH estão descritas no artigo Primeiros 10 passos depois de comprar uma VPS. Por padrão, o endereço é bloqueado por 10 minutos depois de 5 erros em 10 minutos (jail.conf). O que vale acrescentar:
- Bloqueios longos para reincidentes. A regra
recidivelê o log do próprio fail2ban e bloqueia por uma semana o endereço que foi pego várias vezes em um dia. O parâmetrobantime.increment = truedobra o prazo a cada novo bloqueio. - Regras para o servidor web. As regras prontas
nginx-http-auth,nginx-limit-reqenginx-botsearchreagem a erros de senha em páginas protegidas, ao excesso do limite de requisições e à varredura de endereços inexistentes. - Os seus endereços nas exceções. O parâmetro
ignoreipcom o IP fixo do escritório evita que você bloqueie a si mesmo.
O fail2ban não protege contra ataques distribuídos a partir de milhares de endereços e não substitui o login por chave. A maior utilidade dele para a auditoria é um log mais curto: ficam os eventos que importam, e não dezenas de milhares de tentativas idênticas de adivinhar a senha. A lista de endereços bloqueados aparece com fail2ban-client status sshd.
Rotação e espaço em disco
Os logs crescem sem parar, e nas VPS baratas o disco é pequeno. Pelo catálogo da accsly.io em novembro de 2026, a mediana do disco nos planos de VPS com 1 GB de memória é de 20 GB, e 9% dos planos de VPS têm disco de 20 GB ou menos. O log de acesso de um site movimentado ou um contêiner que grava um erro em loop enchem um disco desses em poucos dias, e então param o banco de dados e o próprio site.
- O journald ocupa por padrão no máximo 10% do sistema de arquivos e no máximo 4 GB. Um limite próprio é definido pelo parâmetro
SystemMaxUse=em/etc/systemd/journald.conf, e o prazo de retenção, peloMaxRetentionSec=, que vem desativado. Para liberar espaço uma vez:journalctl --vacuum-size=500Mou--vacuum-time=30d. - Os arquivos de texto são rotacionados pelo logrotate conforme as regras de
/etc/logrotate.d/. No Ubuntu 24.04, os logs do sistema são rotacionados uma vez por semana e guardam 4 arquivos antigos, ou seja, cerca de um mês. Os logs do nginx do pacote do AlmaLinux 9, uma vez por dia, com 10 arquivos antigos. Os parâmetrosrotate,dailyouweekly,compressemaxsizemudam o prazo, a compressão e a rotação por tamanho. O modocopytruncateserve para programas que não sabem reabrir o arquivo, mas, segundo a documentação, pode perder linhas. Para testar uma regra sem alterar nada:logrotate -d /etc/logrotate.d/nginx. - O Docker grava por padrão os logs dos contêineres sem limite de tamanho (driver json-file). Defina
max-sizeemax-fileem/etc/docker/daemon.jsone recrie os contêineres: as configurações só valem para os novos. Mais no artigo Docker em VPS: por onde começar.
Para descobrir o que ocupou o disco: df -h mostra a partição cheia, e du -xh /var/log | sort -h | tail, os maiores diretórios. Não apague um arquivo de log que um serviço mantém aberto: o espaço só será liberado quando o serviço for reiniciado. Esvazie-o com truncate -s 0. O aviso de disco cheio deve chegar antes: veja o artigo Monitoramento de servidor: uptime, carga e alertas.
Como guardar os logs para investigar um incidente
Se o servidor foi invadido, a primeira coisa que o invasor com acesso root faz é editar ou apagar os logs. Por isso, uma cópia que sai do servidor na hora vale mais do que qualquer configuração de retenção no próprio servidor.
- Envie os logs para outro servidor. O rsyslog consegue encaminhar mensagens pela rede, e o journald tem para isso o serviço systemd-journal-upload. O servidor receptor pode ser uma VPS barata à parte com um disco maior ou um sistema de coleta de logs como Loki, Graylog ou OpenSearch; os planos para ele estão na seleção VPS para Elasticsearch.
- Decida quanto tempo guardar. Para investigar a maioria dos incidentes, são precisos logs de 30 a 90 dias: muitas vezes a invasão é descoberta semanas depois de acontecer. No próprio servidor bastam uma ou duas semanas; o resto fica no servidor de coleta ou em arquivo.
- Sincronize o relógio. Sem a hora exata não dá para cruzar eventos de servidores diferentes. Confira com
timedatectl: a linha «System clock synchronized» deve mostrar yes. - Não guarde nos logs o que não é preciso. Senhas, tokens e números completos de cartão não devem ir para o log. Endereços IP e logins de usuários podem ser dados pessoais pela LGPD e pelo RGPD, por isso o prazo de retenção deve constar da política de tratamento de dados; mais no artigo GDPR e a escolha de hospedagem.
- No incidente, primeiro preserve, depois conserte. Copie os logs e faça um snapshot do disco no provedor antes de reinstalar o sistema. Como funcionam snapshots e backups está no artigo Backups de VPS: estratégias e ferramentas.
Se os logs servem não só para investigar, mas também para alertas, como um pico de erros 500 ou um login como root, eles são coletados junto com as métricas num servidor de monitoramento à parte. Planos para essa tarefa estão na seleção VPS para monitoramento.