It's 7:43 am. You open your laptop. An alert is blinking. CrowdSec has blocked 47 connections. Pi-hole reports unusual DNS queries. A container has restarted that you didn't start.
Is this an attack? Or is this normal?
This question is faced daily by thousands of self-hosted system operators. The wrong answer costs either nerves (false alarm) or data (real attack).
Three signals that indicate a real attack
1. Authentication failures in unusual volume. Five failed SSH logins in the morning — that could be an employee who forgot their password. Five thousand failed attempts in one hour from 40 different IP addresses — that is a brute-force attack. CrowdSec recognises this pattern automatically and blocks the sources. If you see this pattern in your logs: take it seriously.
2. Outgoing traffic to unknown destinations. Your server normally sends data to your users, backup systems and update servers you know. If regular connections suddenly appear to IP addresses in unexpected regions that you haven't mapped — that is a warning signal. Especially if these connections happen at night or at unusual times.
3. Processes you didn't start. A mining script maxing out your CPU. A port that's suddenly open. A new user in the user list. If something is running on your system that you can't explain — treat it as a threat until proven otherwise.
The three most common false alarms
CrowdSec blocks your own IP. This happens especially if you have a dynamic IP address and log in incorrectly several times. Solution: whitelist your own subnets. This is a maintenance task, not a security problem.
Backup jobs at an unusual time. If your backup cron runs at 03:00 and you read the logs at 07:00, you see a load spike and network activity at times when nobody is working. That's not a break-in — that's your backup working correctly.
Automatic updates. Watchtower, apt-cron, Docker images that update themselves — all of this generates network connections, restarts and brief load spikes. If you have no monitoring that marks these events, it looks alarming.
The rule that always applies
When you're not sure whether data or credentials could be compromised: treat it as a real attack. The cost of a false alarm is a lost morning. The cost of an ignored real attack can be existential.
What then? Block access. Secure logs before they get overwritten. Look at active connections: netstat -an or ss -tulpn. And if you're not sure what you're seeing — ask someone who knows these systems.
Solutions that solve this