How to Create Fail2ban on Linux Server in 2026? – Easy Guide

To create Fail2ban on a Linux server, install the package, enable the service, and configure jails to watch logs and ban abusive IPs via your firewall. Copy jail.conf to jail.local, set bantime, findtime, maxretry, and enable service specific jails like SSH.

Verify with fail2ban client status and monitor /var/log/fail2ban.log. If you’re wondering how to create Fail2ban on a Linux server, this guide walks you through installation, configuration, testing, and best practices.

We’ll set up jails for SSH and web services, choose the right firewall backend (UFW, firewalld, iptables, or nftables), and harden your server against brute-force attacks without breaking legitimate access.

What is Fail2ban and Why You Need it?

Fail2ban is a lightweight intrusion-prevention tool that reads authentication and service logs to detect malicious behavior (like repeated login failures) and automatically bans the offending IPs using your firewall. It’s a must-have for public-facing Linux servers to reduce SSH, FTP, SMTP, and web brute-force attempts.

Prerequisites

Before you start, ensure:

• Root or sudo access over SSH
• A configured firewall (UFW, firewalld, iptables, or nftables)
• Accurate server time (NTP) to ensure correct log timestamps
• Log files available or systemd journal enabled for your services

Tip: Whitelist your management IP before enabling aggressive bans to avoid locking yourself out.

Install Fail2ban on Popular Linux Distributions

Debian/Ubuntu (including Ubuntu Server 22.04+)

sudo apt update
sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

Default SSH log: /var/log/auth.log. Modern Ubuntu often uses nftables under the hood (even with UFW).

RHEL/AlmaLinux/Rocky Linux 8/9

sudo dnf install -y epel-release
sudo dnf install -y fail2ban fail2ban-firewalld
sudo systemctl enable --now fail2ban

Default SSH log: /var/log/secure. firewalld is the default firewall on these platforms.

Fedora

sudo dnf install -y fail2ban fail2ban-firewalld
sudo systemctl enable --now fail2ban

Fedora uses systemd journals heavily; Fail2ban can read from the journal instead of flat log files.

openSUSE Leap/Tumbleweed

sudo zypper refresh
sudo zypper install -y fail2ban
sudo systemctl enable --now fail2ban

Verify the service status after installation:

sudo systemctl status fail2ban

Core Concepts: Filters, Jails, and Actions

Fail2ban uses:

• Filters: Regex patterns that detect malicious events in logs (in /etc/fail2ban/filter.d/).
• Jails: Bind a filter to a log source and firewall “action”.
• Actions: How the ban is applied (iptables, nftables, UFW, or firewalld).

We’ll configure jails in a local override file so updates won’t overwrite your changes.

Configure Fail2ban (Recommended Defaults)

Create jail.local and Set Global Defaults

Copy the stock config and edit the local file:

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

Add or adjust defaults under the [DEFAULT] section. The example below works well on modern systems:

[DEFAULT]
# Ban settings
bantime = 1h
findtime = 10m
maxretry = 5

# Whitelist your trusted IPs/subnets
ignoreip = 127.0.0.1/8 ::1

# Backend: use systemd journal when available
backend = systemd

# Choose an action matching your firewall stack:
# For firewalld:
banaction = firewallcmd-rich-rules

# For iptables (legacy):
# banaction = iptables-multiport

# For nftables (modern distros):
# banaction = nftables-multiport

# For UFW (Ubuntu):
# action = ufw

# Log level and target
loglevel = INFO
logtarget = /var/log/fail2ban.log

Notes:

• Use bantime = 1h or higher; increase for persistent abuse.
• With firewalld, ensure the fail2ban-firewalld package is installed on RHEL/Fedora.
• If you rely on UFW, set action = ufw in the jail rather than banaction.

Enable and Tune the SSH Jail

Append this to /etc/fail2ban/jail.local. Adjust logpath to your distro.

[sshd]
enabled = true
port = ssh
# For systemd journal-aware setups:
backend = systemd
logpath = %(sshd_log)s
maxretry = 5
findtime = 10m
bantime = 1h

# Optional: Protect SSH with an incremental ban
# requires Fail2ban 0.11+:
# bantime.increment = true
# bantime.factor = 1.5
# bantime.formula = bantime * (1 + (failures / 6))

Common log locations:

• Debian/Ubuntu: /var/log/auth.log
• RHEL/CentOS/Alma/Rocky: /var/log/secure
• Journal backend: use backend = systemd and logpath = journal or %(sshd_log)s

Optional: Protect Web and Mail Services

Enable built-in jails for common services if you run them:

[nginx-http-auth]
enabled = true

[nginx-botsearch]
enabled = true

[apache-auth]
enabled = true

[postfix]
enabled = true

[dovecot]
enabled = true

Ensure the corresponding logs exist (e.g., /var/log/nginx/error.log, /var/log/maillog or journal). Some distributions ship service-specific filters in /etc/fail2ban/filter.d/; enable only what you actually run to avoid false positives.

Optional: Recidive Jail for Repeat Offenders

The “recidive” jail escalates bans for IPs that trip multiple jails across time.

[recidive]
enabled = true
logpath = /var/log/fail2ban.log
bantime = 1w
findtime = 1d
maxretry = 5

Apply, Verify, and Monitor

Restart and Enable on Boot

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

Check Jail Status

sudo fail2ban-client status
sudo fail2ban-client status sshd

The second command shows the number of currently banned IPs and the jail’s configuration.

Monitor Logs and Test

sudo tail -f /var/log/fail2ban.log

From a separate machine, attempt a few failed SSH logins, then watch Fail2ban ban that IP. Always keep one whitelisted admin session open during testing to prevent lockouts.

Choosing the Right Firewall Backend

Match Fail2ban’s action with your firewall to avoid conflicts and ensure IPv4/IPv6 coverage:

• UFW (Ubuntu): Use action = ufw in jails. UFW typically manages nftables behind the scenes.
• firewalld (RHEL/Fedora): Use banaction = firewallcmd-rich-rules. Ensure fail2ban-firewalld is installed.
• nftables (modern distros): Use banaction = nftables-multiport.
• iptables (legacy): Use banaction = iptables-multiport or iptables-allports if you need broad bans.

Consistency matters: don’t mix direct iptables rules with firewalld/UFW unless you know the implications, or rules may be overwritten or misapplied.

Security Best Practices and Real-World Tips

• Whitelist your office/VPN IPs with ignoreip to reduce lockout risk.
• Change default SSH port and disable password authentication in favor of SSH keys for stronger security.
• Use incremental bans (bantime.increment) to discourage persistent attackers.
• Enable only relevant jails; overly broad filters can cause false positives.
• Monitor for 7–14 days and adjust maxretry, bantime, and findtime based on observed traffic.
• Back up /etc/fail2ban/ regularly; treat it as part of your server’s security baseline.

Troubleshooting Common Issues

• No bans applied: Check sudo fail2ban-client status and ensure the jail is enabled. Verify the logpath and backend (journal vs file).
• Wrong logpath: On RHEL-family, SSH auth logs are in /var/log/secure; Debian/Ubuntu use /var/log/auth.log.
• Firewall conflicts: If using firewalld or UFW, avoid raw iptables actions; choose the matching banaction/action.
• SELinux: If logs are not readable, adjust contexts or use the systemd backend. Check audit.log for denials.
• IPv6 not banned: Ensure your action supports IPv6 (nftables, firewalld, or appropriate iptables v6 actions).

Essential Commands Cheat Sheet

# Service control
sudo systemctl status fail2ban
sudo systemctl restart fail2ban

# List jails and get status
sudo fail2ban-client status
sudo fail2ban-client status sshd

# Unban a specific IP
sudo fail2ban-client set sshd unbanip 203.0.113.25

# Manually ban a specific IP
sudo fail2ban-client set sshd banip 203.0.113.25

# Test your regex (replace filter and log accordingly)
sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Managed Option: Let Experts Handle Fail2ban

Don’t want to babysit firewall rules and jails? With YouStable’s managed VPS and dedicated servers, our engineers deploy, tune, and monitor Fail2ban alongside UFW/firewalld, harden SSH, and add proactive security layers. It’s the fastest route to a locked-down server without DIY risk.

Step-by-Step Example: End-to-End Setup (Ubuntu)

This quick sequence illustrates everything in one go for a typical Ubuntu server:

# 1) Install Fail2ban
sudo apt update && sudo apt install -y fail2ban

# 2) Create local config
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# 3) Edit jail.local (set defaults + SSH jail)
sudo nano /etc/fail2ban/jail.local
# [DEFAULT]: bantime=1h, findtime=10m, maxretry=5, backend=systemd, action=ufw or nftables-multiport
# [sshd]: enabled=true, logpath=%(sshd_log)s

# 4) Enable and restart
sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban

# 5) Verify
sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo tail -f /var/log/fail2ban.log

FAQ’s