Protecting against brute-force attacks

What Is a Brute Force Attack and Why Should It Be Taken Seriously?

A brute force attack is one of the oldest yet most effective methods of infiltrating a server. In this type of attack, the attacker uses automated tools to try various combinations of usernames and passwords in order to gain access to a valid account. If your server uses SSH, a control panel, or any authentication service, it is definitely exposed to these attacks.

Statistics show that an internet-connected server experiences hundreds or even thousands of failed login attempts on average every day. Many of these attempts come from botnets and distributed IP addresses. The important point is that brute force attacks are not limited to weak passwords; even strong passwords may be cracked if subjected to prolonged attacks. For this reason, dealing with this threat requires a multi-layered strategy, which we will examine practically in this article.

A Three-Layer Strategy for Dealing with Brute Force Attacks

To effectively protect against brute force attacks, you need to implement three defensive layers simultaneously: rate limiting, temporary account lockout, and continuous log monitoring. Each of these layers alone is not sufficient, but combining them creates a strong defense.

Layer One: Rate Limiting with fail2ban

fail2ban is a powerful open-source tool that automatically monitors system logs and temporarily blocks the attacker's IP address when suspicious patterns are detected. This tool is your first line of defense against brute force attacks.

Installing fail2ban on Debian/Ubuntu-based distributions is straightforward:

sudo apt update
sudo apt install fail2ban -y

After installation, you need to create a local configuration file to override the default settings:

sudo nano /etc/fail2ban/jail.local

In this file, add the following configuration:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
findtime = 600

These settings tell fail2ban that if 5 failed SSH login attempts (maxretry) are observed within a 10-minute window (findtime), the corresponding IP address should be blocked for 1 hour (bantime). After saving the file, restart the service:

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

To view the blocking status, use the following command:

sudo fail2ban-client status sshd

This command displays the list of blocked IP addresses and the number of failed attempts.

Layer Two: Temporary Account Lockout at the System Level

Rate limiting at the IP level is useful, but attackers can use multiple different IP addresses. For this reason, you should also enable temporary account lockout. This ensures that after several failed attempts, even if the IP address changes, the user account will be locked for a specified period.

To enable temporary lockout for SSH, you need to edit the /etc/ssh/sshd_config file:

sudo nano /etc/ssh/sshd_config

Add or edit the following lines:

MaxAuthTries 3
LoginGraceTime 30

The MaxAuthTries 3 setting tells SSH to disconnect after 3 failed attempts. LoginGraceTime 30 also limits the login grace period to 30 seconds. After applying the changes, restart the SSH service:

sudo systemctl restart sshd

For web services like Apache or Nginx that use authentication, you can use rate limiting modules. For example, in Nginx you can configure rate limiting as follows:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location /login {
        limit_req zone=login burst=10 nodelay;
        proxy_pass http://backend;
    }
}

These settings tell Nginx that only 5 requests to the /login path are allowed per minute from each IP address.

Layer Three: Continuous Login Log Monitoring

Even with rate limiting and temporary lockout in place, you should regularly monitor login logs. This helps you identify unusual patterns earlier and take additional measures if needed.

To view login logs on systemd-based systems, use the following command:

sudo journalctl -u ssh --since "24 hours ago" | grep "Failed password"

This command displays all failed login attempts from the past 24 hours. To view overall statistics, you can use the following command:

sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20

This command displays the top 20 IP addresses with the most failed attempts, along with the number of attempts. If a particular IP address consistently appears in this list, you can manually block it:

sudo ufw deny from 203.0.113.5

For automated monitoring, you can set up a cron job that sends a daily summary of failed attempts to your email:

0 8 * * * grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20 | mail -s "SSH Brute Force Report" your@email.com

Common Mistakes in Dealing with Brute Force Attacks

Over the years, I have seen similar mistakes in server security configurations that have led to defense failures. Here are the most important ones:

• Not enabling fail2ban for all services: Many people only protect SSH, but leave services like FTP, email, and control panels unprotected. Enable fail2ban for all authentication services.
• Setting bantime too short: If you set bantime to 60 seconds, the attacker can try again after each block. Set bantime to at least 3600 seconds (1 hour).
• Ignoring distributed attacks: Professional attackers use thousands of different IP addresses. In this case, IP-level rate limiting is not sufficient, and you need to move to more advanced solutions like account-level rate limiting.
• Not regularly monitoring logs: Even if fail2ban is active, you should regularly review logs. New attack patterns may emerge that fail2ban does not detect.

Additional Tips for Enhanced Security

In addition to the three main layers, several supplementary measures can significantly increase your security:

Two-Factor Authentication (2FA)

Enabling 2FA for SSH and control panels prevents intrusion even if the password is compromised. For SSH, you can use Google Authenticator or similar tools.

Changing the Default SSH Port

Changing the SSH port from 22 to a non-standard port significantly reduces automated attacks. This does not provide absolute security, but it bypasses many automated scanners.

Using SSH Keys Instead of Passwords

SSH keys are far more secure than passwords and are resistant to brute force attacks. After setting up the key, you can completely disable password login:

PasswordAuthentication no

Apply this setting in /etc/ssh/sshd_config and then restart the SSH service.

Summary and Practical Steps

Brute force attacks are a constant threat, but by properly implementing defensive layers, you can minimize the risk. Here is a summary of the actions you should take:

1. Install and configure fail2ban for all authentication services
2. Enable temporary account lockout by setting MaxAuthTries and LoginGraceTime
3. Configure rate limiting on the web server for login paths
4. Regularly monitor logs and manually block suspicious IP addresses
5. Enable 2FA and use SSH keys instead of passwords

If you follow these steps correctly, your server will be resistant to most brute force attacks. Remember that security is an ongoing process, not a one-time action. Regularly review logs and update security settings as new threats emerge. Along the way, using hosting services with a proper security infrastructure can also help you focus on securing your applications and services.