Setting Up Fail2Ban on

Configuration

The main configuration of Fail2Ban is done via the jail.local file. We will copy the base config and then modify it to suit our needs.

1. Creating jail.local

Copy the jail.conf file to jail.local to begin configuration:

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

Now, all changes will be made in jail.local.

2. Basic jail.local Configuration

Open the jail.local file for editing:

sudo nano /etc/fail2ban/jail.local

At the beginning of the file, you will find the [DEFAULT] section. Here you can set global parameters. Recommended settings:

[DEFAULT]
# Time for which an IP address is banned (in seconds). 1 hour.
bantime = 3600

# Time window during which attempts are counted (in seconds). 10 minutes.
findtime = 600

# Maximum number of failed attempts before banning.
maxretry = 5

# IP addresses that will never be banned (your IP, local networks).
# Multiple IPs can be specified, separated by spaces.
ignoreip = 127.0.0.1/8 ::1 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8

# Default action upon banning. 'iptables-multiport' - blocks IP
# on all ports specified in the jail.
banaction = iptables-multiport

# Email notifications (optional, requires mail server setup)
# destemail = [email protected]
# sendername = Fail2Ban
# mta = sendmail
# action = %(action_mw)s # Sends an email with Whois information

Explanations:

• bantime: Sets the duration for which an IP address is banned. 3600 seconds = 1 hour. Can be increased to 86400 (24 hours) or even -1 for permanent banning (use with caution).
• findtime: The time window during which Fail2Ban monitors failed attempts. If maxretry attempts occur within findtime, the IP will be banned.
• maxretry: The number of failed login attempts after which an IP address will be banned.
• ignoreip: A list of IP addresses or subnets that will never be banned. Be sure to add your static IP address here!
• banaction: The action that will be performed to ban an IP. iptables-multiport is standard and effective.

3. Configuring "Jails"

Below the [DEFAULT] section are separate sections for each service, called "jails". By default, many of them are disabled. To enable protection for a service, set enabled = true.

3.1. SSH Protection

This is one of the most important protections. Find the [sshd] section and enable it:

[sshd]
enabled = true
port = ssh # or your custom SSH port, if changed (e.g., 2222)
filter = sshd
logpath = /var/log/auth.log # or /var/log/secure for CentOS/RHEL
maxretry = 3 # Can be made smaller for SSH
bantime = 86400 # Ban SSH for 24 hours

If you have changed the standard SSH port (from 22 to another), remember to specify it in the port parameter. It is recommended to use a longer ban time (e.g., 24 hours) for SSH, as password brute-force attempts often come from bots.

3.2. Nginx Protection (HTTP/HTTPS)

To protect the Nginx web server from authentication attacks (e.g., on the /admin panel) or DoS-like attacks (too many requests), you can use the nginx-http-auth and nginx-dos filters.

First, ensure that Nginx logs errors. If you are using Nginx, install it:

sudo apt install nginx -y

Then add the following sections to jail.local:

[nginx-http-auth]
enabled = true
port = http,https
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 6
bantime = 1200

[nginx-dos]
enabled = true
port = http,https
filter = nginx-dos
logpath = /var/log/nginx/access.log
maxretry = 300 # For example, 300 requests in 5 minutes
findtime = 300 # 5 minutes
bantime = 600 # Ban for 10 minutes

Note: For nginx-dos, filter = nginx-dos might be missing by default. You may need to create the file /etc/fail2ban/filter.d/nginx-dos.conf with the following content:

[Definition]
failregex = ^ -."(GET|POST|HEAD).HTTP/" (403|404|401)
ignoreregex =

This is a very simple filter. More complex filters for Nginx can be found in the official Fail2Ban documentation or on GitHub.

3.3. Postfix Protection (SMTP)

If you are using Postfix for sending mail:

[postfix]
enabled = true
port = smtp,ssmtp,submission,imap,imaps,pop3,pop3s
filter = postfix
logpath = /var/log/mail.log
maxretry = 5
bantime = 1800

4. Syntax Check and Fail2Ban Restart

After making all changes, save the jail.local file. Before restarting the service, it is recommended to check the configuration for errors:

sudo fail2ban-client -d # Checks configuration without applying

If there are no errors, restart Fail2Ban to apply the new settings:

sudo systemctl restart fail2ban

5. Checking Fail2Ban Functionality

To ensure that Fail2Ban is working correctly, you can check the status of active "jails":

sudo fail2ban-client status # General Fail2Ban status
sudo fail2ban-client status sshd # Status of a specific jail (e.g., sshd)

The output for sshd should show the number of banned IP addresses, if any. To test, try entering an incorrect password several times (more than maxretry) when connecting via SSH from another IP address (or from yours, if it's not in ignoreip). Then check the status of the sshd jail.

Status for jail sshd:
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     5
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   192.168.1.100 (example of a banned IP)

This means that Fail2Ban successfully banned the IP address 192.168.1.100 after 5 failed attempts.

6. Docker Integration (Optional)

If you are using Docker, container logs might not be directly accessible to Fail2Ban from /var/log/. To protect Docker containers, you will need to configure containers to output logs in a format understandable by Fail2Ban, or use specialized solutions. One approach is to configure Docker containers to use the syslog or json-file log driver, subsequently forwarding them to a centralized log file that Fail2Ban can read. For example, for Nginx in Docker:

Add to docker-compose.yml for your service:

services:
  nginx:
    image: nginx:stable-alpine
    # ... other settings ...
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
    volumes:
      - /var/log/nginx-docker:/var/log/nginx # Mapping Nginx logs from the container

Then change the logpath in the corresponding Nginx jail to /var/log/nginx-docker/error.log and /var/log/nginx-docker/access.log respectively.

Another option is to use log-driver: syslog and configure rsyslog on the host to write Docker logs to separate files that Fail2Ban can monitor.

Backups and Maintenance

Even with Fail2Ban configured, backups remain a critically important element of security and fault tolerance. Additionally, the system needs regular maintenance.

1. What to Back Up

For Fail2Ban and overall server stability, it's important to back up the following:

• Fail2Ban configuration files: /etc/fail2ban/jail.local and any .conf files you created in /etc/fail2ban/jail.d/, as well as custom filters in /etc/fail2ban/filter.d/.
• Other important configs: /etc/ssh/sshd_config, web server configurations (Nginx: /etc/nginx/, Apache: /etc/apache2/), firewall (/etc/ufw/).
• Your application data: Databases, website files, user data, if any.

2. Simple Auto-Backup Script

To create regular backups, you can use a combination of rsync and cron. For more reliable and incremental backups, consider tools like BorgBackup or Restic.

Example of a simple script for backing up Fail2Ban and SSH configurations:

#!/bin/bash
BACKUP_DIR="/var/backups/configs"
DATE=$(date +%Y%m%d_%H%M%S)
TAR_FILE="$BACKUP_DIR/fail2ban_configs_$DATE.tar.gz"

mkdir -p "$BACKUP_DIR"

# Create an archive with important configurations
tar -czvf "$TAR_FILE" \
    /etc/fail2ban/jail.local \
    /etc/fail2ban/jail.d/ \
    /etc/fail2ban/filter.d/ \
    /etc/ssh/sshd_config \
    --exclude='.swp'

# Delete old backups (keep the last 7 days)
find "$BACKUP_DIR" -type f -name "fail2ban_configs_.tar.gz" -mtime +7 -delete

echo "Backup created: $TAR_FILE"

Save this script as /usr/local/bin/backup_fail2ban.sh and make it executable:

sudo chmod +x /usr/local/bin/backup_fail2ban.sh

Then add it to cron for daily execution. Open crontab:

sudo crontab -e

And add a line to execute the script daily at 3:00 AM:

0 3   * /usr/local/bin/backup_fail2ban.sh > /dev/null 2>&1

3. Where to Store Backups

Never store backups on the same server as the original data. If the server fails, you will lose both data and backups. Recommended options:

• External S3-compatible storage: Services like AWS S3, Backblaze B2, DigitalOcean Spaces, or other cloud storage solutions offer reliable and scalable storage.
• Separate VPS: You can use another, less powerful VPS as a backup storage, using rsync over SSH.
• Local storage: For small projects, you can use a local disk on your workstation, but this requires manual synchronization.

For automatic sending of backups to S3, you can use s3cmd or rclone.

4. Updates: Rolling vs Maintenance Window

Regular software updates are critical for security. You can choose one of the following strategies:

• Rolling updates: Applied as they are released, typically for non-critical services. For Fail2Ban, which is not updated frequently, this can be acceptable.
• Maintenance window: Updates are performed at a predetermined time, usually at night or on weekends when the load is minimal. This allows for process control and risk minimization.

For Fail2Ban, it's sufficient to run sudo apt update && sudo apt upgrade -y once a week or once a month. Always check logs after updates. For Fail2Ban, it's also important to keep its filters up-to-date. Periodically check the official Fail2Ban GitHub repository for new or updated filters, especially if you are using specific services.

Troubleshooting + FAQ

This section contains answers to frequently asked questions and solutions to common problems that may arise when working with Fail2Ban.

Fail2Ban is not blocking IP addresses, even though there are errors in the logs. What should I check?

Make sure Fail2Ban actually "sees" the logs. Check the log path in the jail.local file (logpath parameter) for the corresponding "jail". Ensure that the filter (filter) is correctly configured and matches your log format. You can test the filter manually using the command fail2ban-regex /path/to/log /etc/fail2ban/filter.d/your_filter.conf. Also, check that maxretry and findtime are set correctly and the IP address is not in the ignoreip list.

How to unblock an IP address manually?

If you accidentally blocked your IP address or need to unblock a legitimate one, use the command: sudo fail2ban-client set JAIL_NAME unbanip IP_ADDRESS. For example, for SSH: sudo fail2ban-client set sshd unbanip 1.2.3.4. After this, the IP address will be immediately unblocked.

How to check which IP addresses are blocked?

To view all active "jails" and blocked IP addresses, use: sudo fail2ban-client status. To view the status of a specific "jail" (e.g., sshd): sudo fail2ban-client status sshd. The output will show a list of blocked IP addresses and their count.

What is the minimum VPS configuration suitable for Fail2Ban?

For Fail2Ban itself, a minimal VPS with 1 CPU core, 1 GB RAM, and 20 GB NVMe/SSD disk is sufficient. However, if other services (web server, database, mail) will also be running on the server, then 2 CPU cores, 2-4 GB RAM, and 40-80 GB NVMe/SSD are recommended to ensure stable operation of all applications and have resource headroom.

What to choose — VPS or dedicated for this task?

For configuring Fail2Ban and protecting most typical services (several websites, a mail server for a small team, a game server for friends), a VPS will be an optimal and cost-effective choice. A dedicated server is justified only for high-load projects requiring maximum performance, complete isolation, or specific hardware where virtualization may be undesirable.

Fail2Ban consumes too many resources. What to do?

Check which "jails" are active and how often they trigger. Overly aggressive filters or monitoring very large log files can increase resource consumption. Try increasing findtime and bantime, and decreasing maxretry for less critical services. Ensure Fail2Ban uses an optimal backend (auto by default, which is usually good). If the problem is due to a very large number of logs, consider log rotation (logrotate) for more efficient file management.

Can Docker containers be protected with Fail2Ban?

Yes, this is possible but requires additional configuration. Fail2Ban works with logs, so containers must output their logs to the host system where Fail2Ban can read them. The most common approach is to map log files from the container to the host system via Docker volumes or configure the Docker logging driver to syslog so that logs are sent to the host's system journal. Fail2Ban is then configured to read these files or the system journal.

How to update Fail2Ban?

For Debian/Ubuntu-based systems, it is sufficient to execute the standard package update commands: sudo apt update && sudo apt upgrade -y. Fail2Ban will be updated along with the rest of the system. After the update, it is recommended to restart the service sudo systemctl restart fail2ban to ensure that new component versions are applied.

Conclusion and Next Steps

Congratulations! You have successfully configured Fail2Ban on your VPS, significantly increasing its resilience to brute-force attacks. Your server now automatically monitors suspicious activity and blocks attackers, freeing you from routine monitoring and allowing you to focus on developing your projects. This is a fundamental step in ensuring the basic security of any self-managed server.

Further steps to strengthen your server's security and optimization may include:

• Monitoring and Logging: Set up a centralized logging system (e.g., ELK Stack or Grafana Loki) for deeper analysis of security and performance events.
• Regular Security Audits: Use vulnerability scanning tools (e.g., Nessus, OpenVAS) and regularly check configurations for compliance with best practices.
• Scaling and High Availability: As your project grows, consider migrating to cluster solutions, load balancers, and redundant servers to ensure uninterrupted operation.
• Deployment Automation: Use tools like Ansible, Puppet, or Chef to automate the setup of new servers and configuration management, which will save time and reduce the likelihood of errors.