My VPS crashed: why UFW firewall logs don't mean a DDoS attack (and how i found the real cause)

The outage: what the UFW logs actually said#

Anyone running servers in the cloud knows the immediate stress of receiving a sudden downtime notification. My VPS unexpectedly stopped responding, and my first instinct was to log into the emergency recovery console, inspect dmesg, and find out what happened.

The console output was filled with firewall drops ([UFW BLOCK]). The initial thought was obvious: "The server is getting hit by a DDoS attack or an aggressive port scan that knocked it offline."

However, reliable system debugging requires separating internet background noise from actual infrastructure failures. Below is the step-by-step process I used to analyze the logs, rule out false-positive attacks, and discover why the server rebooted.

1. Initial alarm: decoding UFW firewall noise#

Kernel logs immediately following host recovery showed:

[    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

Detailed inspection confirmed this was not a malicious flood:

• Internal Docker bridge traffic (br-... and veth...): Blocks in the initial seconds were IPv6 multicast packets on UDP 5355. This is the LLMNR protocol (Link-Local Multicast Name Resolution), used for internal local name resolution across container interfaces.
• Automated internet port scanners on public interface (ens3): Random SYN packets targeting ports like 50802 and 7707 are background internet scanning noise hitting every public IP.
• Orphan packets (ACK FIN): Packets carrying ACK FIN flags on port 1514 were old connections attempting graceful teardown. Because the server had just rebooted and lost its connection tracking table (conntrack), UFW blocked the unrecognized packets.

Furthermore, packet frequency was trivial (one packet every few seconds). A real DDoS flood registers tens of thousands of packets per second.

2. Investigating root cause: memory exhaustion vs service crash#

Ruling out external attacks shifted focus to operating system health.

Check 1: Did the out-of-memory killer trigger?#

When physical RAM is exhausted, the Linux kernel triggers the OOM Killer to terminate high-memory processes:

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

The check returned empty. Physical RAM exhaustion was not the cause.

Check 2: Critical errors in systemd#

I queried journalctl for priority level 3 errors:

sudo journalctl -xe -p 3

The logs revealed:

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

Varnish received a SIGTERM (signal 15). This signal signifies a graceful, coordinated termination requested by the operating system during a planned shutdown.

3. The full timeline: what happened at 15:34?#

Opening a 10-minute window in journalctl exposed the complete timeline:

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

The chronological history clarified the sequence:

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 ...

Consolidated root cause:#

The -- Boot 89abc187d89b... -- entry confirmed the VPS went through a reboot:

1. Active SSH session: At 15:30:02, a root SSH session was initiated.
2. Cron backup warnings: The system cron attempted running rclone backup jobs, flagging INSECURE MODE due to overly permissive file modes on the cron configuration.
3. Graceful host restart: At 15:34:30, the host completed its reboot cycle. Varnish received SIGTERM as part of the normal system service shutdown procedure.

4. Fixes applied and practical takeaways#

To secure the environment and eliminate log warnings:

Fixing cron file permissions:#

Cron requires /etc/cron.d/ entries to be owned by root with strict permissions:

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

Verifying core services after boot:#

sudo systemctl status docker
sudo systemctl status varnish

Blocked packets in firewall logs are rarely a sign of a targeted attack. Internet background scans and Docker internal bridges generate continuous UFW noise. Filtering focused time windows in journalctl and checking for boot markers (-- Boot --) and process signals (SIGTERM) saves valuable time during outage investigations.

See also

Infrastructure The day Rocky Linux 8 kernel "broke" my iptables (and how i fixed it)

Servers Complete Guide to DNS Zones in cPanel and WHM: Fixing 'DNS Entry Already Exists', killdns CLI, and Advanced Templates

Servers Troubleshooting cPanel: fixing the white screen when accessing accounts via WHM (xfercpanel)

This post is licensed under CC BY-NC.