Every dedicated server connected to the internet receives automated login attempts continuously. SSH, the Secure Shell protocol used to administer Linux servers remotely, is the primary target. Automated tools scan the internet for servers with open SSH ports and attempt to log in using lists of common usernames and passwords, running thousands of attempts per hour without human intervention.
This is a brute force attack: systematic, automated credential guessing at scale. Most servers face these attacks from the moment they come online. The question is not whether your server will receive brute force attempts, it will, but whether the configuration in place makes those attempts futile.
This guide explains how brute force attacks work against SSH and web applications, what protection mechanisms exist, how to implement them on a dedicated server, and how to verify they are working.
📖 What does a complete server security posture look like?
Brute force protection is one layer of a complete security configuration. Read Dedicated Server Security: Best Practices for Protecting Your Infrastructure, a complete guide to the full security stack that complements brute force protection.
What a Brute Force Attack Is
A brute force attack is an automated attempt to gain unauthorised access by systematically trying credential combinations until one works. The attacker does not need to know your password, they need only time and a sufficiently large list of combinations to try.
Modern brute force tools are fast and distributed. A single attack tool can attempt hundreds of login combinations per second. Distributed attacks spread attempts across many source IP addresses simultaneously, making IP-based blocking more complex. Credential stuffing attacks use lists of previously leaked username and password combinations from other breached services, targeting the significant proportion of users who reuse passwords across multiple accounts.
Brute force tools targeting SSH probe for common usernames: root, admin, ubuntu, debian, paired with common passwords. Web applications face the same threat at a different entry point: login forms, admin panels, and API authentication endpoints. In both cases, the defence mechanisms are similar in principle but different in implementation.
Why Default Server Configuration Is Vulnerable
A freshly provisioned dedicated server with default configuration has several properties that make it immediately vulnerable to brute force attacks.
SSH accepts password authentication. By default, SSH allows users to authenticate with a username and password, which is exactly what brute force tools are designed to guess. Password authentication is the mechanism being attacked; leaving it enabled means the attack surface remains fully exposed.
SSH listens on port 22. Port 22 is the standard SSH port and the first port brute force scanning tools probe. A server listening on port 22 appears in automated scans within minutes of coming online.
The root account is accessible. Many default configurations allow direct SSH login as root. Compromising the root account gives an attacker complete control over the server, making it the highest-value target for brute force tools.
No rate limiting exists. Without rate limiting, an attacker can attempt thousands of login combinations per minute without any friction. The server processes every attempt, consuming CPU and network resources while providing the attacker unlimited opportunity to guess correctly.
SSH Key-Based Authentication: The Most Effective Protection
The single most effective brute force protection for SSH is eliminating password authentication entirely and replacing it with key-based authentication.
SSH key pairs consist of a private key, stored on the administrator’s machine and never shared, and a public key, stored on the server in the ~/.ssh/authorized_keys file. Authentication works by cryptographic challenge: the server verifies that the connecting client possesses the private key corresponding to an authorised public key, without the private key ever being transmitted.
A brute force attack against key-based SSH authentication is computationally infeasible. The key space for a 4096-bit RSA key or an Ed25519 key is astronomically large — no amount of automated guessing will find the correct private key within any realistic timeframe. Switching to key-based authentication and disabling password authentication in /etc/ssh/sshd_config effectively eliminates the brute force attack surface for SSH entirely.
Implementing key-based authentication
Generate a key pair on the administrator’s machine:
ssh-keygen -t ed25519 -C "[email protected]"Copy the public key to the server:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ipVerify login works with the key, then disable password authentication by setting the following in /etc/ssh/sshd_config:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin noRestart SSH to apply the changes:
systemctl restart sshdFail2ban: Automated IP Blocking for Repeated Failures
For services where password authentication cannot be disabled: web application login forms, email servers, FTP, fail2ban provides automated protection by monitoring log files for repeated failed authentication attempts and temporarily blocking the source IP addresses.
Fail2ban reads authentication logs, identifies IP addresses that exceed a defined threshold of failed attempts within a time window, and adds a firewall rule blocking that IP for a configurable ban duration. When the ban duration expires, the rule is removed and the IP can attempt connections again, or fail again and receive a longer ban.
Installing and configuring fail2ban
On Debian and Ubuntu:
apt install fail2banThe default configuration protects SSH automatically. To verify the SSH jail is active:
fail2ban-client status sshdA custom jail configuration in /etc/fail2ban/jail.local allows tuning the threshold and ban duration:
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600This configuration bans any IP that makes more than 3 failed SSH login attempts within 10 minutes, for 1 hour. For stronger protection, increase bantime to 86400 (24 hours) or use permanent bans with recidive jails that escalate ban duration for repeat offenders.
📖 How does a firewall complement fail2ban?
Fail2ban operates at the application log level, a firewall controls access before connections reach the application. Read What Is a Firewall and How Does It Protect Your Server?, covering how network-level firewall rules and fail2ban work together as complementary protection layers.
Rate Limiting at the Firewall Level
Fail2ban reacts to failed attempts after they occur. Firewall-level rate limiting prevents excessive connection attempts before they reach the application, reducing the load that brute force traffic places on the server.
Using iptables, rate limiting on SSH connections looks like this:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROPThis drops new SSH connection attempts from any IP that has made more than 4 connection attempts in the past 60 seconds, before fail2ban even sees the traffic.
UFW users can achieve similar results with rate limiting built into UFW:
ufw limit sshThis enables UFW’s built-in SSH rate limiting, which blocks connections from IP addresses that attempt more than 6 connections within 30 seconds.
Additional SSH Hardening Measures
Key-based authentication and fail2ban address the primary brute force vectors. Several additional SSH hardening steps reduce the attack surface further.
Change the default SSH port
Moving SSH from port 22 to a non-standard port (for example, 2222 or a high port number) eliminates most automated scanning traffic, which predominantly targets port 22. This is not security through obscurity in the traditional sense, it does not make SSH more secure if the port is discovered, but it dramatically reduces the volume of automated attempts the server receives, which reduces noise in logs and lowers the background load from scanning traffic.
Update /etc/ssh/sshd_config:
Port 2222Update the firewall to allow the new port and block port 22, then restart SSH.
Restrict SSH access by IP address
If administrators access the server from fixed IP addresses, an office network, a VPN, restricting SSH access to those specific IP ranges at the firewall level eliminates brute force exposure entirely for any IP not on the allowlist. An attacker whose IP is not permitted to connect cannot attempt authentication regardless of what credentials they have.
Disable root login
Setting PermitRootLogin no in sshd_config prevents direct root login via SSH. Administrators must log in as a non-root user and escalate privileges with sudo when needed. This means a successful brute force attack on any account still does not give the attacker root access directly.
Limit the number of authentication attempts per connection
MaxAuthTries 3This limits the number of authentication attempts SSH allows per connection before closing it. Combined with fail2ban, it reduces how many guesses each connection attempt can make before triggering a ban.
Brute Force Protection for Web Applications
Web application login forms face the same brute force threat as SSH, with additional complexity: they must remain accessible to legitimate users globally, making IP-based blocking more nuanced than for SSH.
Application-level rate limiting
Most web frameworks and CMS platforms include rate limiting plugins or middleware: WordPress has plugins like Limit Login Attempts Reloaded, Laravel includes rate limiting in its routing layer, and Node.js applications can use express-rate-limit. These tools limit login attempts per IP within a time window and lock accounts or require CAPTCHA after repeated failures.
Web Application Firewall rules
A WAF can detect and block brute force patterns at the HTTP layer, identifying IPs sending many requests to /wp-login.php, /admin, or /api/auth in a short window and blocking them before the requests reach the application. Read more about WAF configuration in the dedicated article on web application firewalls.
Two-Factor Authentication
Two-factor authentication (2FA) adds a second verification step that a brute force attack cannot bypass through credential guessing alone. Even if an attacker correctly guesses a username and password combination, they cannot complete authentication without the time-based one-time password (TOTP) or hardware token that the second factor requires.
Monitoring and Verifying Brute Force Protection
Protection that is configured but not monitored may fail silently. Verifying that brute force protection is working requires checking the right sources.
Check fail2ban status regularly:
fail2ban-client status sshdThis shows the number of currently banned IPs and the total number of bans since fail2ban started, a clear indicator of how much brute force activity the server is receiving and blocking.
Review authentication logs:
grep "Failed password" /var/log/auth.log | tail -50Failed password attempts that appear in the log without corresponding fail2ban bans indicate the threshold configuration may need tightening.
Monitor SSH login success:
grep "Accepted" /var/log/auth.logAll successful SSH logins appear here. Any unfamiliar IP address or username in this log requires immediate investigation.
📖 What monitoring tools help detect security incidents early?
Monitoring authentication logs is one part of a broader server monitoring strategy. Read Best Tools to Monitor Dedicated Server Performance, covering the monitoring stack that makes security incidents visible before they cause damage.
Dedicated servers with full security control
Swify dedicated servers give you complete root access to implement SSH key-based authentication, fail2ban, custom firewall rules, and the full brute force protection stack, without provider restrictions on what you can configure.
→ Explore Swify Dedicated ServersFrequently Asked Questions
What is SSH and why do attackers target it?
SSH (Secure Shell) is the protocol used to administer Linux servers remotely, it provides an encrypted command-line connection that allows administrators to configure, manage, and troubleshoot servers over the internet. Because SSH provides full administrative access to the server, it is the highest-value target for attackers: a successful SSH compromise gives complete control over the machine.
Attackers target SSH with automated brute force tools because the default configuration accepts password authentication on the standard port 22, making it accessible and guessable at scale. A server receiving brute force SSH attempts is not being specifically targeted; automated tools scan the entire internet for open port 22 and attempt logins continuously. Read more about server security best practices in Dedicated Server Security: Best Practices for Protecting Your Infrastructure.
Is fail2ban enough to protect a server from brute force attacks?
Fail2ban significantly reduces brute force risk but is most effective as one layer in a defence-in-depth approach rather than a standalone solution. It reacts to failed attempts after they occur, meaning attackers still get a defined number of attempts before being blocked. Against distributed brute force attacks that spread attempts across many IP addresses, fail2ban’s per-IP blocking is less effective.
The strongest SSH brute force protection combines multiple layers: key-based authentication (which eliminates the password attack surface entirely), firewall-level rate limiting (which reduces attempt volume before it reaches the application), fail2ban (which blocks persistent sources), and IP allowlisting for SSH where operationally feasible. No single mechanism provides complete protection; the combination does. Read more about the complete security configuration in Dedicated Server Security Checklist: How to Harden Your Server After Setup.
What is the difference between SSH key authentication and password authentication?
Password authentication verifies identity by checking a submitted password against a stored value, a mechanism that brute force tools can attack by systematically submitting guesses. Key-based authentication verifies identity through a cryptographic challenge: the server checks that the connecting client possesses the private key corresponding to an authorised public key, without the private key ever being transmitted or guessable.
The practical security difference is absolute: a well-generated SSH key pair (Ed25519 or 4096-bit RSA) is computationally infeasible to brute force, the key space is too large for any realistic attack. Password authentication, by contrast, is always vulnerable to brute force given sufficient time and a weak or reused password. Disabling password authentication and enabling key-based authentication is the single most impactful SSH security configuration change available.
How do I know if my server is receiving brute force attacks?
Check the authentication log on a Linux server with: `grep “Failed password” /var/log/auth.log | tail -50`. Any entries here represent failed SSH login attempts. A server that has been online for more than a few hours with SSH on port 22 will almost certainly show failed attempts, this is normal and expected. The volume and pattern of attempts tells you more than their presence alone.
High volumes of attempts from single IP addresses suggest targeted scanning; attempts from many different IPs suggest distributed credential stuffing. Checking `fail2ban-client status sshd` shows how many IPs fail2ban has banned and how many total bans have been issued, a high ban count confirms active brute force activity that the protection is successfully blocking. Read more about monitoring approaches in Best Tools to Monitor Dedicated Server Performance.
Does changing the SSH port stop brute force attacks?
Changing the SSH port from 22 to a non-standard port eliminates the vast majority of automated scanning traffic, which predominantly targets port 22. The volume of brute force attempts typically drops by 90% or more after moving to a non-standard port, because most automated tools do not scan all 65,535 ports, they target common service ports.
However, changing the port does not make SSH more secure if the new port is discovered, it only reduces the noise from undiscriminating automated scanners. A determined attacker performing a full port scan will find SSH regardless of which port it runs on. Changing the port is therefore a useful noise reduction measure that complements proper security configuration: key-based authentication, fail2ban, and firewall rules, rather than a replacement for it.
How does brute force protection work for WordPress login pages?
WordPress login pages face continuous automated brute force attempts targeting `/wp-login.php` and `/wp-admin`. Protection combines several layers: rate limiting plugins that restrict login attempts per IP within a time window, two-factor authentication that requires a TOTP code in addition to credentials, WAF rules that block IPs sending many requests to login endpoints, and optionally moving or restricting access to the login URL.
On a dedicated server, fail2ban can also protect WordPress login pages by monitoring the web server access log for repeated POST requests to `/wp-login.php` and blocking the source IP at the firewall level, the same mechanism that protects SSH, applied to HTTP traffic. This server-level protection operates independently of WordPress plugins and blocks attack traffic before it reaches the application. Read more about dedicated server WordPress hosting in Dedicated Server for WordPress: When Shared Hosting and VPS Are No Longer Enough.