How to Install Fail2ban with Firewalld on Fedora

Installing Fail2ban with Firewalld on Fedora creates a powerful defense against brute-force attacks and unauthorized access attempts. Fail2ban blocks hostile IP addresses after repeated login failures, while Firewalld enforces flexible network policies. When you combine them, you get responsive protection that adapts to real threats without constant manual intervention. This guide shows how to install both tools and configure Fail2ban to work seamlessly with Firewalld’s zones and ipsets.

Along the way, you’ll verify services, create custom jails, and learn how to monitor and test bans in real time. Whether you’re hardening a personal VPS or maintaining production hosts, these steps keep intruders out while preserving the workflows you rely on. Together, Fail2ban and Firewalld deliver automated jail enforcement, native ipset integration that respects Fedora zones, broad service coverage, and optional alerts so you always know when bans trigger.

Update Fedora Linux System Packages

First, update your system’s package list to ensure compatibility and avoid conflicts during installation. Open your terminal by searching for “Terminal” in Activities and run:

sudo dnf upgrade --refresh

This command refreshes and updates all your system packages. If updates include kernel changes, however, you should reboot your system to ensure all changes take effect.

Install Firewalld

Next, install Firewalld, a dynamic firewall manager for Linux systems. With your system updated, run the following command:

sudo dnf install firewalld

Firewalld manages network traffic through customizable rules and is a critical component of system security.

Enable and Start Firewalld

After installation, set Firewalld to start automatically at boot and launch it immediately using:

sudo systemctl enable firewalld --now

This ensures Firewalld runs automatically after system restarts, maintaining continuous network protection.

Verify Firewalld Status

Now, confirm Firewalld is running correctly with:

sudo firewall-cmd --state

A successful response confirms Firewalld is active:

running

Review Current Firewalld Rules

Before integrating Fail2ban, it’s important to review the current Firewalld rules to understand your existing security configuration:

sudo firewall-cmd --list-all

This shows your current active zone, allowed services, and ports. With Firewalld now operational, you can proceed to install Fail2ban.

FedoraServer (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Install Fail2ban with Firewalld Integration

Now that Firewalld is configured, install Fail2ban and its Firewalld integration package. Both are available in the Fedora repository:

sudo dnf install fail2ban fail2ban-firewalld

This installs Fail2ban and the components needed for seamless Firewalld integration.

Verify Fail2ban Installation

After installation, confirm Fail2ban installed correctly by checking its version:

fail2ban-client --version

The output confirms the installed version:

Fail2Ban v1.1.0

Enable and Start Fail2ban Service

Next, activate Fail2ban to start automatically at boot and begin monitoring immediately:

sudo systemctl enable fail2ban --now

This ensures Fail2ban continuously monitors your server for suspicious activity.

Verify Fail2ban Service Status

At this point, confirm Fail2ban is running correctly:

systemctl status fail2ban

When successful, the output shows an active status:

● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; preset: disabled)
     Active: active (running) since Sun 2024-12-29 10:00:00 UTC; 5s ago
       Docs: man:fail2ban(1)
    Process: 12345 ExecStartPre=/bin/mkdir -p /run/fail2ban (code=exited, status=0/SUCCESS)
   Main PID: 12346 (fail2ban-server)
      Tasks: 3 (limit: 4915)
     Memory: 12.0M
        CPU: 123ms
     CGroup: /system.slice/fail2ban.service
             └─12346 /usr/bin/python3 -s /usr/bin/fail2ban-server -xf start

With both services active, Fail2ban is now successfully installed and running. The following sections cover configuration basics and how to customize the setup for your specific needs.

Configure Fail2ban

Understand Fail2ban Configuration Files

To start, Fail2ban uses a hierarchy of configuration files. When you install the fail2ban-firewalld package, it automatically creates /etc/fail2ban/jail.d/00-firewalld.conf with the correct Firewalld integration settings. This file sets banaction = firewallcmd-rich-rules, which uses Firewalld’s rich rule syntax to block offending IPs.

Instead of modifying the default configuration files (which get overwritten during updates), create a local configuration file for your custom settings:

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

This approach is cleaner than copying jail.conf to jail.local because it only contains your customizations rather than the entire default configuration. Settings in jail.d/local.conf override defaults while preserving the Firewalld integration already configured by 00-firewalld.conf.

Configure Basic Settings

Next, add your custom settings to /etc/fail2ban/jail.d/local.conf. Here’s a basic configuration example:

[DEFAULT]
# Backend for log parsing - systemd is used on modern Fedora
backend = systemd

# IP addresses to never ban
ignoreip = 127.0.0.1/8 ::1

# Ban duration in seconds (3600 = 1 hour)
bantime = 3600

# Time window to count failures (600 = 10 minutes)
findtime = 600

# Number of failures before ban
maxretry = 5

# Uncomment and adjust these when you enable email alerts
# destemail = root@localhost
# sender = fail2ban@localhost

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 600
bantime = 3600

Notably, Fedora already configures the systemd backend in /etc/fail2ban/paths-fedora.conf, so the backend = systemd line is optional but included here for clarity. The commented destemail and sender entries act as placeholders so you can replace them later without duplicating values when you enable alerts.

Advanced Configuration Options

Additionally, beyond the basic settings, you can fine-tune Fail2ban’s behavior with additional parameters.

Ban Time Increment

To increase ban duration for repeat offenders, add the following lines inside the existing [DEFAULT] block in your configuration:

# Enable incremental ban time for repeat offenders
bantime.increment = true

# Multiplier values for each subsequent ban
bantime.multipliers = 1 2 4 8 16 32 64

This configuration doubles the ban time with each offense, starting at the base bantime value and multiplying up to 64 times the original duration for persistent offenders.

Allowlist IP Addresses

Alternatively, prevent specific IP addresses or networks from being banned by extending the ignoreip setting in the same [DEFAULT] section:

# Allowlist local networks and trusted IPs
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24 203.0.113.50

For example, include your own IP address, trusted networks, and any monitoring systems that might trigger false positives. Use CIDR notation for network ranges.

Service-Specific Settings

Alternatively, configure ban policies for individual services. For example, set stricter rules for Apache:

[apache-auth]
enabled = true
port = http,https
logpath = %(apache_error_log)s
bantime = 86400
maxretry = 3
findtime = 600

This configuration enables protection for Apache authentication, banning IPs for 24 hours (86400 seconds) after 3 failed attempts within 10 minutes. If you’re running an Apache web server on Fedora, this jail provides essential protection against authentication attacks.

Email Notifications

Additionally, configure email alerts when Fail2ban takes action. First ensure you have a mail transfer agent installed (Postfix or Sendmail):

sudo dnf install -y postfix mailx
sudo systemctl enable --now postfix

Afterward, add the email settings to the [DEFAULT] block so every jail can reuse them:

destemail = admin@example.com
sender = fail2ban@example.com
# Send email with whois data and log lines
action = %(action_mwl)s

The action_mwl action relies on the mail binary provided by the mailx package, so install it alongside Postfix (or whichever mail relay you prefer). Send a quick test with mail to confirm outbound delivery before depending on automated alerts. If you use an external SMTP provider, adjust Postfix or swap in a different Fail2ban action that matches your mail setup.

Remember to remove or replace the commented placeholder email lines from the earlier configuration block instead of adding duplicate keys. Keeping each option defined only once prevents Fail2ban from ignoring values due to conflicting entries.

Common Jail Configurations

Fail2ban includes pre-configured jails for common services. Here are practical examples for the most frequently used services on Fedora.

The [sshd] jail from the basic configuration section protects SSH on Fedora from brute-force attacks using the systemd backend. The remaining examples show jails for other common services.

Nginx Jail

Similarly, protect Nginx web servers from various attacks:

# Protect against HTTP authentication failures
[nginx-http-auth]
enabled = true
port = http,https
logpath = %(nginx_error_log)s
maxretry = 3
bantime = 3600

# Block bots scanning for exploits
[nginx-botsearch]
enabled = true
port = http,https
logpath = %(nginx_access_log)s
maxretry = 2
bantime = 7200

Postfix Email Server Jail

Likewise, protect Postfix mail servers from spam and authentication attacks:

# Protect against SMTP authentication failures
[postfix-sasl]
enabled = true
port = smtp,submission,smtps
backend = systemd
maxretry = 3
bantime = 3600

# Block dictionary attacks on email addresses
[postfix-rbl]
enabled = true
port = smtp,submission,smtps
backend = systemd
maxretry = 1
bantime = 86400

Dovecot IMAP/POP3 Jail

Similarly, secure Dovecot IMAP and POP3 services from brute-force login attempts:

[dovecot]
enabled = true
port = imap,imaps,pop3,pop3s
backend = systemd
maxretry = 5
findtime = 600
bantime = 3600

Restart Fail2ban

After making configuration changes, restart Fail2ban to apply them:

sudo systemctl restart fail2ban

Custom Filters and Actions

Creating custom filters and actions in Fail2ban lets you tailor server security to specific needs on Fedora Linux.

Custom Filters

Fail2ban uses filters, defined by regular expressions, to identify unauthorized access attempts in log files. These filters are stored in the /etc/fail2ban/filter.d directory.

Creating a Custom Filter

First, to create a custom filter, open a new file in the filter directory:

sudo nano /etc/fail2ban/filter.d/mycustomfilter.conf

This step opens a new filter configuration file for editing.

Next, define your custom filter in this file. The filter definition typically includes a failregex, which is a regular expression matching log entries that indicate unauthorized access attempts:

[Definition]
failregex = ^.*unauthorized access attempt from <HOST>.*$
ignoreregex =

In this example, the failregex pattern matches any log entry containing an unauthorized access attempt from a specific IP address (represented by <HOST>).

Custom Actions

Meanwhile, actions in Fail2ban define how the system responds to detected offenses. They are stored in the /etc/fail2ban/action.d directory.

Creating a Custom Action

Then, create a new file in the action directory:

sudo nano /etc/fail2ban/action.d/mycustomaction.conf

This step opens a new file for editing your custom action configuration.

Afterward, add your action definition to this file:

[Definition]
actionstart = /usr/local/bin/mycustomaction start <name>
actionstop = /usr/local/bin/mycustomaction stop <name>
actioncheck = /usr/local/bin/mycustomaction status <name>
actionban = /usr/local/bin/mycustomaction ban <ip>
actionunban = /usr/local/bin/mycustomaction unban <ip>

At this stage, replace /usr/local/bin/mycustomaction with the path to your custom action script. Parameters like <name> and <ip> are dynamically replaced by Fail2ban when the action executes.

Integrating Custom Filters and Actions

Finally, after creating custom filters and actions, integrate them into your jail configuration:

[mycustomjail]
enabled = true
port = 8080
logpath = /var/log/mycustomservice.log
filter = mycustomfilter
action = mycustomaction
maxretry = 3
bantime = 1h

This jail configuration uses the custom filter and action you created, monitoring the specified log file and enforcing bans based on your settings.

Apply Configuration Changes

Restart Fail2ban to activate your new configurations:

sudo systemctl restart fail2ban

This loads all your custom settings and makes them operational.

Manage Bans with Fail2ban-Client

In addition, the fail2ban-client command manages Fail2ban configurations and jails, particularly for manual ban and unban operations.

Check Active Jails

To begin, view all currently active jails and their status:

sudo fail2ban-client status

Consequently, this displays a list of all enabled jails. Example output:

Status
|- Number of jail:      2
`- Jail list:   sshd, apache-auth

Ban an IP Address

When necessary, manually ban an IP address in a specific jail:

sudo fail2ban-client set <jail-name> banip <ip-address>

Replace <jail-name> with the relevant jail name and <ip-address> with the IP you want to ban. For example:

sudo fail2ban-client set apache-auth banip 192.168.1.1

This bans the IP address 192.168.1.1 in the apache-auth jail, preventing access from that IP to services protected by this jail.

Unban an IP Address

Conversely, to remove a ban from an IP address in a specific jail:

sudo fail2ban-client set <jail-name> unbanip <ip-address>

Again, replace <jail-name> and <ip-address> with the appropriate jail name and IP address. For example:

sudo fail2ban-client set apache-auth unbanip 192.168.1.1

This removes the ban on IP address 192.168.1.1 from the apache-auth jail.

View Banned IP Addresses

Additionally, to view currently banned IP addresses in a specific jail:

sudo fail2ban-client status <jail-name>

Replace <jail-name> with the jail you want to inspect. For example:

sudo fail2ban-client status sshd

The output shows the jail’s current filter and ban statistics:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 3
|  |- Total failed:     15
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     2
   `- Banned IP list:   203.0.113.7

Get Help with Fail2ban-Client

For additional information about available fail2ban-client commands, run:

sudo fail2ban-client -h

This displays a help menu with a comprehensive list of available options and commands.

Verify Firewalld and Fail2ban Integration

Thoroughly testing the integration between Firewalld and Fail2ban confirms they work together correctly for optimal server security.

Understanding Firewalld IPsets

Under the hood, when you install fail2ban-firewalld, it configures Fail2ban to use the firewallcmd-rich-rules ban action by default. However, you can configure jails to use firewallcmd-ipset for efficient ipset-based blocking. To view any active ipsets:

sudo firewall-cmd --get-ipsets
sudo firewall-cmd --info-ipset f2b-sshd

Active Fail2ban jails create Firewalld ipsets named like f2b-jailname. For example, an active sshd jail creates f2b-sshd. This approach is more efficient than creating individual firewall rules for each banned IP, especially when managing hundreds or thousands of bans. If you still run the legacy iptables backend, sudo ipset list provides equivalent output.

Enable the SSHD Jail for Testing

If the SSHD jail is not already active, open your existing configuration file and confirm the [sshd] block keeps enabled set to true:

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

Then verify the existing SSHD jail configuration includes the enabled flag:

[sshd]
enabled = true

Afterward, save the file and restart Fail2ban:

sudo systemctl restart fail2ban

Test Ban Functionality

To validate the setup, manually test the ban functionality by banning an IP address in the SSHD jail:

sudo fail2ban-client set sshd banip 203.0.113.7

This instructs Fail2ban to ban the specified IP address in the SSHD jail.

Next, verify that Firewalld applied the ban by checking for ipset entries:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --info-ipset f2b-sshd

At this point, you should see the banned IP in the Fail2ban-managed ipset. Alternatively, check the Fail2ban jail status:

sudo fail2ban-client status sshd

Example output showing a successful ban:

Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned:	1
   |- Total banned:	1
   `- Banned IP list:	203.0.113.7

Test Real-World SSH Protection

For a more realistic test, intentionally trigger failed SSH login attempts from a test machine (not your main connection). From another computer or VM, attempt to SSH with incorrect passwords:

ssh testuser@your-server-ip

After exceeding the maxretry threshold (default 5 attempts), your IP will be banned. Check the Fail2ban log to confirm:

sudo tail -n 20 /var/log/fail2ban.log

Soon after, you should see entries indicating the ban action. The tail command displays the most recent log entries, making it perfect for monitoring real-time events. Additionally, you can check the system auth log for the failed attempts:

sudo journalctl -u sshd | grep "Failed password" | tail -n 10

To unban the test IP and restore access:

sudo fail2ban-client set sshd unbanip YOUR_TEST_IP

Clean Up After Testing

For production servers, keep the SSHD jail enabled. The section below applies only if you specifically need to disable SSH protection, which is not recommended.

After testing, if you want to disable the SSHD jail, edit your configuration file once more:

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

If needed, set enabled to false or remove the sshd jail section entirely:

[sshd]
enabled = false

Restart Fail2ban:

sudo systemctl restart fail2ban

This deactivates the SSHD jail and returns the configuration to its original state.

Monitor Fail2ban Logs

Consistently monitoring Fail2ban logs helps ensure your jails operate correctly on Fedora Linux. The default log location is /var/log/fail2ban.log.

Watch Logs in Real-Time

To view the log file as events occur, use the tail -f command. This approach is useful for immediate troubleshooting or monitoring ongoing activities:

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

Running this command keeps the log file open and updates it in real-time with each new entry. Press Ctrl+C to stop following.

Show a Specific Number of Log Entries

Alternatively, to review a specific number of recent log entries, use the tail command with the -n flag to specify how many lines to display:

sudo tail -n 30 /var/log/fail2ban.log

This displays the last 30 lines of the log file. Replace 30 with any number that fits your needs.

Search Logs for Specific Content

For targeted log analysis, such as finding entries related to a specific IP address or event, use the grep command to search for patterns:

sudo grep '192.168.1.1' /var/log/fail2ban.log

In this example, grep locates all occurrences of the IP address 192.168.1.1 in the Fail2ban log. This is effective for quickly identifying actions taken against a specific IP or finding patterns related to certain security incidents. Learn more about advanced text searching in our grep command guide.

Remove Fail2ban from Fedora

Uninstall Fail2ban

When you no longer need Fail2ban on your Fedora system, first stop the service and unban any active IPs to restore normal access:

sudo systemctl stop fail2ban

Next, remove the packages and their unused dependencies:

sudo dnf remove fail2ban fail2ban-firewalld

DNF5 automatically removes unused dependencies, so all associated packages are cleaned up in this step.

Remove Custom Configuration Files

If you created custom jail configurations, remove them as well:

sudo rm -f /etc/fail2ban/jail.d/local.conf

The default Fail2ban configuration files remain in /etc/fail2ban/ after removal but are inactive without the main package. If you want a completely clean removal, delete the entire directory:

The following command permanently deletes all Fail2ban configuration files. If you might reinstall Fail2ban later and want to preserve your settings, skip this step.

sudo rm -rf /etc/fail2ban/

Troubleshoot Common Issues

Fail2ban Fails to Start

If Fail2ban does not start, check for configuration syntax errors:

sudo fail2ban-client -t

A successful test displays:

OK: configuration test is successful

Errors typically indicate missing brackets, typos in jail names, or invalid regular expressions. Review the error message and correct the specified configuration file.

Jails Not Activating

When a jail appears in your configuration but does not activate, verify the monitored service is running:

sudo systemctl status sshd

Fail2ban jails only activate when their corresponding service is available and generating logs. Also confirm the jail is set to enabled = true in your configuration file.

Bans Not Appearing in Firewalld

If bans are logged but not blocking traffic, verify Firewalld is running and Fail2ban is using the correct action:

sudo firewall-cmd --state
cat /etc/fail2ban/jail.d/00-firewalld.conf

The output should show running for Firewalld and banaction = firewallcmd-rich-rules in the configuration. If using a different action like firewallcmd-ipset, check that the required ipset package is installed.

Conclusion

You’ve successfully installed and configured Fail2ban with Firewalld on Fedora Linux, creating a robust defense against brute-force attacks and unauthorized intrusions. The combination of Fail2ban’s automated log monitoring and Firewalld’s dynamic rule management provides comprehensive server protection. Regular monitoring of Fail2ban logs, keeping your system updated with automatic updates, and adjusting jail configurations as your needs evolve will maintain strong security over time.