Why security protections are not enough without blocking bad bots

Many websites already have security measures in place to prevent attackers from logging in or accessing restricted areas.
However, security alone is not enough if malicious bots are not actively blocked.
Even when a bot cannot log in, the server still needs to process the request and generate a response.
For example, if a bot tries to log in at /wp-login.php and your protection redirects it to a 404 error page, the bot will not gain access, but your server will still generate thousands of 404 pages if thousands of bots keep trying.
This consumes CPU, memory, and disk resources, and can cause your website to slow down or even become unavailable.

The real goal is not only to block unauthorized access, but also to reduce unnecessary resource consumption.
That’s why banning abusive IP addresses is essential: it protects your website’s performance while maintaining security.
I will explain how to block bad bots with Fail2Ban.

Fail2Ban — Quick Setup to Block Login Bots

Summary: Fail2Ban watches logs and bans IPs that make repeated failed requests (like many attempts to /wp-login.php), preventing bots from overloading your server.

1. Install Fail2Ban

On Ubuntu / Debian:

sudo apt update && sudo apt install fail2ban -y

On CentOS / RHEL:

sudo yum install epel-release -y
sudo yum install fail2ban -y

2. Configure the jail

Copy the default config to a local override file and edit it:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Add a simple WordPress-related jail (adjust logpath to match your server):

[wordpress]
enabled  = true
port     = http,https
filter   = wordpress
logpath  = /var/log/nginx/access.log
           /var/log/nginx/error.log
maxretry = 5
bantime  = 3600

3. Create the filter

Create /etc/fail2ban/filter.d/wordpress.conf with a regex that matches malicious attempts (this example is simple and can be improved for your logs):

[Definition]
failregex = .*"POST /wp-login.php
ignoreregex =

Note: Filter patterns must match your actual log format. Test filters with fail2ban-regex before enabling.

4. Restart and enable Fail2Ban

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

5. Check Fail2Ban status

sudo fail2ban-client status
sudo fail2ban-client status wordpress

This shows which jails are active and how many IPs are banned.

6. Important log files to inspect for bot activity

Web server logs — look for many repeated requests to /wp-login.php, /xmlrpc.php, or other suspicious paths:

• Apache: /var/log/apache2/access.log and /var/log/apache2/error.log
• Nginx: /var/log/nginx/access.log and /var/log/nginx/error.log

Quick checks:

# Count login hits
grep "wp-login.php" /var/log/nginx/access.log | wc -l

# Show top IPs requesting wp-login.php
grep "wp-login.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

If you see thousands of hits and the same IPs appear often, that’s a clear sign of bot activity.

7. Check system/resource signs of stress

High request rates from bots often coincide with high CPU, memory, or high disk I/O. Useful commands:

# Real-time processes and CPU usage
top

# Summary of resource usage
vmstat 1 5

# Check number of open connections (useful on busy sites)
ss -s
ss -tnp | head

Fail2Ban is not only for login attempts

Fail2Ban can be used to protect your server against different types of malicious activity, not just WordPress logins.
It monitors log files and automatically blocks IPs that show suspicious behavior. Common examples include:

• SSH brute-force attacks — repeated failed login attempts to the server via SSH.
• FTP/SMTP attacks — bots trying to break into file transfer or mail services.
• Database access attempts — suspicious or repeated failed connections to MySQL, MariaDB, or PostgreSQL.
• Apache/Nginx web attacks — scanning for vulnerabilities or sending too many bad requests.
• Email spam attempts — bots trying to abuse your mail server.

By configuring different jails in Fail2Ban, you can cover multiple services and reduce both the security risk and the performance impact of malicious traffic.

Recommendations to protect performance

• Use Fail2Ban to ban abusive IPs early (as shown above).
• Block obvious malicious IPs at the firewall (iptables/nftables or cloud firewall) to avoid webserver work.
• Consider rate-limiting at the webserver (nginx limit_req) for paths like /wp-login.php.
• Avoid redirecting every blocked request to a 404 page that still consumes PHP processing, prefer returning a minimal static response or dropping the connection at the webserver/firewall level.

Final note

This post is not meant to explain in detail how Fail2Ban works or how to configure every possible scenario.
For a complete guide to Fail2Ban, I suggest you reading the official documentation and this more detailed article.

The key message is that security protections alone are not enough if you don’t actively ban and block bad bots.
Otherwise, your server will still waste resources handling their requests, and your website may suffer significant performance losses.