Minha VPS caiu: por que logs do UFW não significam ataque DDoS (e como achei a causa real)

A queda da VPS: o que os logs do UFW realmente diziam#

Quem mantém servidores na nuvem conhece o frio na barriga de receber um alerta de máquina fora do ar. Minha VPS parou de responder de repente, e a primeira reação instintiva foi acessar o console de emergência, rodar o dmesg e tentar entender o que aconteceu.

Ao abrir a saída do terminal, dei de cara com várias linhas de bloqueio do firewall ([UFW BLOCK]). O primeiro pensamento foi: "O servidor sofreu um ataque DDoS ou uma varredura massiva que derrubou tudo."

No entanto, debugar sistemas exige calma para separar o ruído de fundo da internet dos problemas reais. Abaixo, mostro como analisei os logs, descartei o falso positivo de ataque e descobri exatamente o motivo do reinício da máquina.

1. O susto inicial: decodificando o ruído do UFW#

Os logs do kernel logo após o acesso mostravam o seguinte cenário:

[    9.811651] br-8d6ba9678e45: port 3(veth2ca8f6a) entered blocking state                                          
[    9.812683] br-8d6ba9678e45: port 3(veth2ca8f6a) entered forwarding state                                        
[   10.978154] [UFW BLOCK] IN=br-8d6ba9678e45 OUT= MAC= SRC=fe80::4cb5:f7ff:fe6b:fdc2 DST=ff02::1:3 LEN=69 PROTO=UDP SPT=5355 DPT=5355 LEN=29              
[   11.141834] [UFW BLOCK] IN=veth22de1d6 OUT= MAC= SRC=fe80::54cf:96ff:fe51:edd2 DST=ff02::1:3 LEN=69 PROTO=UDP SPT=5355 DPT=5355 LEN=29                 
...
[   25.369378] [UFW BLOCK] IN=ens3 OUT= MAC=... SRC=198.51.100.16 DST=203.0.113.170 LEN=40 PROTO=TCP SPT=46483 DPT=50802 SYN
[   28.342323] [UFW BLOCK] IN=ens3 OUT= MAC=... SRC=198.51.100.158 DST=203.0.113.170 LEN=52 PROTO=TCP SPT=42385 DPT=1514 ACK FIN
[   52.775080] [UFW BLOCK] IN=ens3 OUT= MAC=... SRC=198.51.100.243 DST=203.0.113.170 LEN=52 PROTO=TCP SPT=40887 DPT=7707 SYN

Analisando os detalhes dessas linhas, ficou claro que não era um ataque:

• Tráfego interno do Docker (br-... e veth...): Os bloqueios nos primeiros segundos eram pacotes IPv6 na porta UDP 5355. Esse é o protocolo LLMNR (Link-Local Multicast Name Resolution), usado para resolução de nomes na rede bridge local entre os containers.
• Scanners automatizados na interface pública (ens3): Conexões com flag SYN tentando portas aleatórias como 50802 e 7707 são robôs automatizados que varrem a internet pública constantemente.
• Pacotes órfãos (ACK FIN): Pacotes com flags ACK FIN na porta 1514 indicavam conexões antigas tentando fechar formalmente. Como a máquina havia reiniciado e perdido a tabela de conexões (conntrack), o UFW barrou os pacotes que continuavam chegando.

Além disso, o volume era minúsculo (um ou dois pacotes a cada vários segundos). Um ataque de negação de serviço real registraria dezenas de milhares de pacotes por segundo.

2. Investigando a causa real: memória ou falha de serviços?#

Descartado o ataque externo, passei a investigar a saúde do sistema operacional.

Teste 1: O out-of-memory killer atuou?#

Se a memória RAM acaba, o kernel aciona o OOM Killer para derrubar processos pesados (como MySQL, PHP ou Nginx):

sudo dmesg -T | grep -i -E 'oom|kill'

O comando não retornou nada. O servidor não travou por falta de memória física.

Teste 2: Erros críticos no systemd#

Fui direto ao journalctl filtrando apenas mensagens de nível crítico (-p 3):

sudo journalctl -xe -p 3

O log exibiu:

Jun 21 15:34:31 server.domain.com.br auditd[557]: Wrong number of arguments for line 5 in /etc/audit/plugins.d/kagin-alert.conf
Jun 21 15:34:31 server.domain.com.br auditd[557]: Skipping kagin-alert.conf plugin due to errors                       
Jun 21 15:34:35 server.domain.com.br varnishd[659]: Manager got SIGTERM                                                
Jun 21 15:34:35 server.domain.com.br varnishd[659]: Child (1085) died signal=15

O Varnish recebeu um SIGTERM (sinal 15). Esse sinal indica uma finalização limpa e coordenada: o processo não quebrou sozinho, ele recebeu ordem do sistema para encerrar.

3. A linha do tempo completa: o que aconteceu às 15:34?#

Para ver todos os eventos antes e depois do desligamento, abri uma janela de 10 minutos no journalctl:

sudo journalctl --since "2026-06-21 15:30:00" --until "2026-06-21 15:40:00"

O histórico revelou o fluxo exato:

Jun 21 15:30:01 server.domain.com.br cron[612]: (*system*backup-rclone) INSECURE MODE (group/other writable) (/etc/cron.d/backup-rclone)
Jun 21 15:30:02 server.domain.com.br systemd-logind[629]: New session 511 of user root.                                
Jun 21 15:30:02 server.domain.com.br systemd[1]: Started session-511.scope - Session 511 of User root.                 
...
Jun 21 15:31:02 server.domain.com.br cron[612]: (*system*backup-rclone) INSECURE MODE (group/other writable) (/etc/cron.d/backup-rclone)
Jun 21 15:32:17 server.domain.com.br cron[612]: (*system*backup-rclone) INSECURE MODE (group/other writable) (/etc/cron.d/backup-rclone)
Jun 21 15:33:48 server.domain.com.br kernel: [UFW BLOCK] ...
-- Boot 89abc187d89b42b9a6981909d87f50ca --                                                                         
Jun 21 15:34:30 server.domain.com.br kernel: Linux version 6.1.0-49-cloud-amd64 ...

O diagnóstico consolidado:#

A linha -- Boot 89abc187d89b... -- confirmou que a VPS passou por um reboot planejado:

1. Sessão SSH root: Às 15:30:02, uma sessão SSH root foi aberta no servidor.
2. Rotinas de backup: O cron tentava rodar o script de backup via rclone, mas avisava INSECURE MODE porque as permissões do arquivo estavam abertas demais.
3. Reinicialização: Às 15:34:30, o servidor concluiu o reboot e iniciou o kernel novamente. O Varnish recebeu SIGTERM simplesmente porque o sistema estava desligando ordenadamente.

4. Medidas de correção e lições aprendidas#

Para normalizar o ambiente e remover os alertas:

Corrigindo as permissões no cron:#

O cron exige que arquivos em /etc/cron.d/ pertençam ao root e não tenham permissão de escrita para outros usuários:

sudo chmod 600 /etc/cron.d/backup-rclone
sudo chown root:root /etc/cron.d/backup-rclone

Auditando o status dos serviços após o boot:#

sudo systemctl status docker
sudo systemctl status varnish

Nem todo log bloqueado no firewall é indício de ataque. O tráfego residual da internet pública e as redes bridge do Docker geram ruído constante no UFW. Ao investigar qualquer queda, filtrar janelas no journalctl e buscar por marcadores de boot (-- Boot --) e sinais de término (SIGTERM) evita perder tempo em hipóteses erradas.

Veja também

Infraestrutura O dia em que o kernel do Rocky Linux 8 "quebrou" meu iptables (e como resolvi)

Servidores Guia Completo de Zonas DNS no cPanel e WHM: Correção do Erro 'DNS Entry Already Exists', killdns e Templates Avançados

Servidores Troubleshooting cPanel: como tratei a tela branca ao acessar contas via WHM (xfercpanel)

Este post está licenciado sob CC BY-NC.