Detecting SSH Brute-Force Attacks on Linux
SSH is the standard remote access method for Linux servers. That universal presence makes it a permanent target: automated scanners constantly probe port 22, testing stolen credentials and common passwords against every reachable host.
How SSH brute-force attacks work
The attack is simple but effective:
- an attacker identifies a host with SSH exposed;
- automated tools cycle through username/password combinations;
- thousands of attempts can be generated in minutes;
- a single successful guess grants shell access.
Once inside, attackers move laterally, install backdoors, or exfiltrate data. Brute-force is often the first stage of a longer attack chain.
Why traditional defenses are not enough
Tools like fail2ban react to log patterns and block IPs temporarily. This helps, but has limits:
- attackers rotate source IPs across botnets;
- distributed low-and-slow attacks stay under threshold;
- log-based detection has gaps when log rotation or parsing fails;
- no forensic trail is preserved after the ban expires.
You need detection that works alongside prevention and keeps a record for investigation.
How SecureExec detects SSH brute-force
SecureExec's ssh_bruteforce built-in rule uses a stateful approach:
- the Linux agent collects SSH authentication events (success and failure) from system journals;
- on the server, the rule tracks failed login attempts per source IP within a sliding 10-minute window;
- when 5 or more failures are observed from the same source, a
highseverity alert fires; - a 15-minute cooldown prevents alert fatigue from ongoing attacks;
- expired tracking state is automatically cleaned up.
This design catches both rapid automated scans and slower distributed probes, while keeping alert volume manageable.
Investigation with full context
When an SSH brute-force alert fires, SecureExec provides:
- the source IP responsible for the failures;
- exact timestamps of each authentication attempt;
- the target hostname and agent;
- all related events stored in Elasticsearch for timeline reconstruction.
Analysts can immediately answer: When did it start? How many attempts? Did any succeed? The companion ssh_success_after_failures rule specifically catches the case where a successful login follows a burst of failures — a strong signal of actual compromise.
Protect your Linux servers
SSH brute-force attacks never stop. Detect them early, track the source, and preserve evidence for response.
Try SecureExec to add stateful SSH brute-force detection with investigation history to your Linux infrastructure.