Key Takeaways
- SSH brute force is constant. Any exposed server sees relentless login attempts, and Wazuh detects them from standard auth logs with no custom rules needed to start.
- Wazuh ships SSH rules out of the box that correlate repeated failures (sshd authentication failures) into brute-force and multiple-failure alerts using frequency rules.
- Active response blocks the source automatically with the firewall-drop command, adding the attacking IP to the host firewall for a configurable time, like fail2ban but tied into your SOC.
- Tune for distributed attacks where many IPs each try a few passwords, and for your own admin activity and automation, to keep alerts meaningful.
- Combine with key-only auth and allowlists: detection is a safety net, not a substitute for disabling password login where you can.
The Constant SSH Brute-Force Problem
Any Linux server reachable from the internet is under continuous SSH attack. Automated bots scan the whole address space and hammer port 22 with username and password guesses day and night. Most are low effort, but they succeed often enough against weak or reused credentials that SSH brute force remains a leading cause of Linux compromise.
The good news is that these attacks are highly visible in logs. Every failed SSH login writes an authentication failure to the system auth log (/var/log/auth.log on Debian and Ubuntu, /var/log/secure on RHEL-family systems). Wazuh reads these logs through its agent, decodes them, and correlates repeated failures into brute-force alerts, giving you both visibility and, with active response, the ability to fight back automatically.
Collecting SSH Authentication Logs
Install the Wazuh agent on each Linux server and ensure it collects the authentication log via the localfile configuration: /var/log/auth.log on Debian-family systems and /var/log/secure on RHEL-family systems. Wazuh includes decoders for sshd messages, so failed and successful logins, invalid users and connection details are parsed into structured fields (source IP, user, port) automatically.
Because the decoders and base rules ship with Wazuh, you get SSH detection working almost immediately after deployment. The agent forwards parsed events to the manager, where the rules engine evaluates them. No custom decoder work is needed for standard OpenSSH, which is a large part of why SSH monitoring is one of the easiest high-value detections to stand up in Wazuh.
Need Help Building These Detections?
Codesecure designs, deploys and tunes Wazuh-based SOC stacks (manager, indexer, dashboard, agents, custom rules, decoders and active response) for businesses across India, Singapore, UAE and Malaysia. ISO/IEC 27001:2022 certified delivery, named OSCP, CEH and CISSP consultants, fixed-price proposals.
See SOC and SIEM Services →How the Built-In SSH Rules Work
Wazuh's default ruleset detects SSH brute force using frequency rules. A single failed login is a low-level event that is logged but does not alert. When many failures from the same source occur within a time window, a higher-level composite rule fires, for example signalling multiple authentication failures or a brute-force attempt. This is the correct model: individual failures are noise, but a cluster from one source in a short period is an attack.
The relevant rules match sshd authentication failures and invalid-user events and escalate based on count and timeframe. A particularly important pattern to watch is a brute-force burst followed by a successful login from the same source, which suggests the attack worked and should be treated as a probable compromise, not just an attempt. Understanding which rule IDs fire for your traffic is the starting point for tuning.
Blocking Attackers with Active Response
Detection is useful, but blocking is better. Wazuh active response can run the built-in firewall-drop command when a brute-force rule fires, adding the attacking source IP to the local firewall (iptables or nftables) for a configurable duration. This is effectively fail2ban functionality, but driven by your SIEM rules and centrally visible in the SOC, so every block is logged alongside the detection that caused it.
Configure active response to trigger on the brute-force rule level, set a sensible block timeout, and decide whether to block on the manager-wide decision or per-agent. Because the block is time-limited and scoped to the firewall, it is a relatively safe automated action compared with host isolation. Still, protect yourself from self-lockout by maintaining an allowlist of trusted admin and jump-host IPs that are never blocked.
Handling Distributed and Slow Attacks
Simple frequency rules catch the classic case of one IP making many attempts, but attackers adapt. Distributed brute force spreads attempts across many source IPs, each trying only a few passwords, to stay under per-source thresholds. Slow (low-and-slow) attacks spread attempts over hours or days for the same reason.
To catch these, add correlation that counts failures per targeted account or per server across all sources, not just per source IP, so a username being sprayed from many IPs still alerts. Widen the timeframe for a parallel low-threshold rule to catch slow attacks. These custom rules complement the default per-source detection rather than replacing it. The combination, per-source, per-account and slow-window, covers the realistic variants of credential guessing against SSH.
Running Wazuh But Missing Attacks?
Whether you need custom rule development, active response playbooks, a detection coverage review against MITRE ATT&CK, or full tuning, our SOC lead is available for a 30-minute free scoping call. No obligation, no slideware.
Talk to a SOC Engineer →Detection Plus Hardening
Detection and automated blocking are a strong safety net, but they work best alongside basic SSH hardening. Where possible, disable password authentication entirely and require SSH keys, which makes brute force irrelevant. Restrict SSH exposure with firewall rules or a bastion host, change defaults where it helps, and keep OpenSSH patched.
With hardening in place, Wazuh SSH monitoring shifts from front-line defence to high-value detection: it tells you when someone is probing, when a misconfiguration has exposed password auth, and crucially when an attempt has succeeded. Treat the two as complementary. Hardening reduces the attack surface; Wazuh detection and active response catch what gets through and give the SOC visibility into the constant background of attempts.
Frequently Asked Questions
Does Wazuh detect SSH brute-force attacks out of the box?
Yes. Wazuh ships with decoders for OpenSSH and default rules that correlate repeated authentication failures into brute-force alerts using frequency rules. Once the agent collects the auth log (/var/log/auth.log or /var/log/secure), SSH brute-force detection works with no custom rule development needed to get started.
How does Wazuh block a brute-force attacker automatically?
Through active response. When a brute-force rule fires, Wazuh can run the built-in firewall-drop command to add the attacking source IP to the local firewall (iptables or nftables) for a configurable time. It works like fail2ban but is driven by your SIEM rules and logged centrally in the SOC alongside the detection that triggered it.
Is Wazuh a replacement for fail2ban?
Wazuh active response with firewall-drop provides similar automatic IP-blocking functionality to fail2ban, with the advantage that detection and blocking are integrated into your SIEM and visible across the SOC. Many teams use Wazuh for this so that SSH blocking is part of their central detection and logging rather than a separate, siloed tool.
How do I detect distributed SSH brute-force attacks?
Per-source frequency rules miss distributed attacks where many IPs each try a few passwords. Add correlation that counts failures per targeted account or per server across all sources, so a username being sprayed from many IPs still alerts. Add a wider-timeframe, lower-threshold rule to catch slow low-and-slow attempts. These complement the default per-source detection.
What is the most important SSH event to alert on?
A burst of failed logins followed by a successful login from the same source IP. That sequence suggests the brute force worked and the account is likely compromised, so it should be treated as a probable intrusion with a much higher severity than failed attempts alone, and should prompt immediate investigation rather than just an automated block.
Can Codesecure configure SSH detection and blocking in our Wazuh?
Yes. Codesecure configures and tunes Wazuh SSH detection including per-source, per-account and slow-attack correlation, sets up firewall-drop active response with safe allowlists to prevent self-lockout, and integrates it with your hardening. ISO/IEC 27001:2022 certified delivery with named OSCP, CEH and CISSP consultants across India, Singapore, UAE and Malaysia.
Turn Constant SSH Attacks Into Automatic Blocks
Codesecure tunes Wazuh SSH detection for per-source, per-account and slow attacks, and configures active response to block attackers automatically with allowlists that prevent self-lockout. Delivered by named OSCP, CEH and CISSP consultants.
