Configure Plesk Fail2Ban jails to stop brute-force attacks

Plesk ships Fail2Ban as its built-in intrusion detection layer — the Plesk equivalent of cPanel's cPHulk and CSF/LFD stack. It watches service logs, matches failed-login patterns, and drops offenders into iptables. Out of the box it is installed but the jails are conservative, and on a busy server the defaults let too much through.

This covers enabling intrusion detection, picking the right jails, tuning ban thresholds, whitelisting your own IPs so you don't lock yourself out, and the most common failure mode — bans that appear in the panel but never make it into the firewall.

Enable intrusion detection

Fail2Ban is off until you switch it on. In the UI: Tools & Settings → IP Address Banning (Fail2Ban) → Settings tab → Enable intrusion detection, then OK. From the shell:

plesk bin ip_ban --enable
plesk bin ip_ban --info

--info prints the current ban period, detection window, retry count, and whether detection is active. The factory defaults are 5 failures inside a 10-minute window earns a 10-minute ban — fine for a quiet box, far too lenient for one being actively scanned.

Pick your jails

A jail is a filter (regexes that recognise an attack in a log) plus an action (what to do when it matches). List what's available and their state:

plesk bin ip_ban --jails

These are the jails worth enabling on almost every server:

Enable several at once:

plesk bin ip_ban --enable-jails ssh,plesk-panel,plesk-postfix,plesk-dovecot,recidive

The plesk-one-week-ban and plesk-permanent-ban jails handle manual bans you issue from the panel — you can't disable them, and you don't need to.

Tune the thresholds

Tighten the global defaults so a scanner gets fewer free attempts and stays out longer:

plesk bin ip_ban --update -ban_period 3600 -ban_time_window 600 -max_retries 3

That's 3 failures in 10 minutes → a 1-hour ban. ban_period is the ban length in seconds, ban_time_window is the detection window, and max_retries is the failure count that trips it. These are global defaults; per-jail overrides live in /etc/fail2ban/jail.local, which takes precedence over the shipped jail.conf and survives Fail2Ban package updates.

For the recidive meta-jail, a longer ban is the whole point. Set it in jail.local:

[recidive]
bantime  = 604800
findtime = 86400
maxretry = 5

Reload after editing the file directly:

plesk repair installation -y   # if the panel and config drift apart
fail2ban-client reload

Whitelist your own IPs

Lock down ban thresholds and you will eventually ban yourself — a fat-fingered password, a mail client looping on a stale credential, an office NAT that a hundred users share. Add trusted IPs that can never be banned, even when they trip an active jail:

plesk bin ip_ban --add-trusted 203.0.113.10
plesk bin ip_ban --add-trusted "198.51.100.0/24;203.0.113.10"
plesk bin ip_ban --trusted          # list current trusted entries
plesk bin ip_ban --remove-trusted 203.0.113.10

View and lift bans

plesk bin ip_ban --banned                  # everything currently banned
plesk bin ip_ban --unban 203.0.113.99,ssh  # one IP from one jail

The unban format is <ip>,<jail>. To unban from several jails at once, pass a semicolon-separated list. You can also do it natively, which is useful in scripts:

fail2ban-client set ssh unbanip 203.0.113.99

When bans show in the panel but iptables is empty

The nastiest Plesk Fail2Ban failure: the panel lists banned IPs, but those addresses are not actually in iptables and keep hammering the server. The bans are recorded; they just never reach the firewall. Three usual causes:

firewalld is overwriting the rules

If firewalld is running alongside Fail2Ban, it rewrites the chains Fail2Ban inserts and silently drops the bans. Check and reconcile:

systemctl is-active firewalld
iptables -L f2b-ssh -n      # should list banned IPs for the ssh jail

On a Plesk server you generally want Fail2Ban driving iptables directly, with firewalld stopped, or the Plesk Firewall extension owning the policy — not both fighting over the same chains.

SELinux mislabels the log files

When log files carry the wrong SELinux context, Fail2Ban can read failures but can't action them — it runs, logs matches, and never bans. Look for permission denied around the file actions:

grep -i 'denied\|error' /var/log/fail2ban.log | tail -20
restorecon -Rv /var/log

The filter isn't matching your log format

If a jail never bans even under obvious attack, the regex isn't matching. Trace one IP through the log:

grep 203.0.113.99 /var/log/fail2ban.log
fail2ban-client status plesk-panel

Currently failed staying at 0 while you can see failures in the service log means the filter and the log format have drifted — common after switching Apache/nginx log formats or moving mail to a non-default path. Point the jail's logpath at the real file in jail.local.

Next steps

• Whitelist Plesk ModSecurity rules without breaking updates
• Plesk repair utility command reference
• Plesk license tiers explained — and activate a Plesk license if you're provisioning a new node