Configure Fail2Ban on Plesk VPS: Protect Login Pages

Why Fail2Ban Matters on a Plesk-Managed Server

A freshly provisioned Plesk VPS is a busy target. Bots scan for open ports within minutes of first boot, and login endpoints — Plesk panel, SSH, FTP, and webmail — see automated credential-stuffing attempts around the clock. Fail2Ban sits between your logs and your firewall, watching for repeated failures and automatically blocking the offending IP for a configurable period.

Plesk ships with its own firewall module, but that module doesn't monitor authentication logs the way Fail2Ban does. The two tools complement each other well: Plesk Firewall handles broad network-level rules, while Fail2Ban reacts dynamically to behaviour in real time.

This tutorial covers installation, core configuration, and Plesk-specific jails on Ubuntu 22.04 or Debian 12. The steps apply equally to Hostperl VPS plans running Plesk Obsidian or Plesk Web Pro.

What You Need Before You Start

• Root or sudo access via SSH
• Plesk Obsidian 18.x or later installed and licensed
• Ubuntu 22.04 LTS or Debian 12 (Bookworm)
• A working firewall — UFW or iptables — already active
• Basic familiarity with the command line

If you haven't yet locked down SSH access on your server, work through setting up SSH key authentication before continuing. Fail2Ban is most effective when password-based SSH is already restricted.

Step 1 — Install Fail2Ban

Update your package index first, then install:

sudo apt update
sudo apt install fail2ban -y

Once installed, enable and start the service:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Verify it's running:

sudo systemctl status fail2ban

You should see active (running). If you see a Python error instead, check that python3-systemd is installed — on some minimal Debian images it's absent.

Step 2 — Create a Local Configuration File

Never edit /etc/fail2ban/jail.conf directly. That file gets overwritten on upgrades. Instead, create a local override:

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

Open it for editing:

sudo nano /etc/fail2ban/jail.local

Scroll to the [DEFAULT] section and set your baseline values:

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5
banaction = iptables-multiport
backend = systemd

These settings ban an IP for one hour if it fails authentication five times within ten minutes. Adjust bantime to something longer — say 86400 (24 hours) — if your logs show persistent scanners.

Step 3 — Whitelist Your Own IP

Lock yourself out once and you'll never skip this step again. Add your management IP address (or a CIDR range if you have a static office IP block) to the ignoreip line:

ignoreip = 127.0.0.1/8 ::1 203.0.113.50

Replace 203.0.113.50 with your actual IP. If you're accessing the server from a dynamic residential connection, note that whitelisting by IP won't help — focus on reducing maxretry instead and keep your SSH key on hand.

Step 4 — Enable the SSH Jail

The SSH jail is usually present in jail.local but disabled. Find the [sshd] block and enable it:

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = systemd
maxretry = 4

Four attempts is a reasonable threshold for SSH — most legitimate users don't mistype their key passphrase that often. If Plesk or your hosting provider has moved SSH to a non-standard port, specify it explicitly: port = 2222.

Step 5 — Add a Jail for Plesk Panel Logins

This is where Fail2Ban on a Plesk VPS diverges from a generic setup. Plesk logs its own authentication failures to /var/log/plesk/panel.log. You need a custom jail that reads from that file.

Create a new filter definition first:

sudo nano /etc/fail2ban/filter.d/plesk-panel.conf

Paste the following:

[Definition]
failregex = plesk\[\d+\]: .* authentication failed .* from \[?<HOST>\]?
datepattern = %%Y-%%m-%%d %%H:%%M:%%S

Save and close. Now add the corresponding jail to jail.local:

[plesk-panel]
enabled  = true
filter   = plesk-panel
logpath  = /var/log/plesk/panel.log
port     = 8443,8880
maxretry = 5
bantime  = 7200

The ports 8443 and 8880 are Plesk's default HTTPS and HTTP panel ports. If your Plesk installation uses a different port, update accordingly.

Step 6 — Protect FTP and Webmail

Plesk typically runs ProFTPD or Pure-FTPd alongside a webmail client (Roundcube or Horde). Both are common brute-force targets.

For ProFTPD:

[proftpd]
enabled  = true
port     = ftp,ftp-data,ftps,ftps-data
logpath  = /var/log/proftpd/proftpd.log
maxretry = 5

For Roundcube webmail, authentication errors typically appear in your Apache or Nginx error log, depending on how Plesk has configured the stack. Check which log is receiving them:

sudo tail -f /var/log/plesk/httpsd_error_log | grep -i roundcube

Once you've confirmed the path, create a filter at /etc/fail2ban/filter.d/roundcube-auth.conf with a regex that matches failed login entries, then wire it to a new jail block in jail.local pointing at that log. The exact regex depends on your Roundcube version — the Fail2Ban community maintains updated examples at the official GitHub repository.

Keeping your outbound mail reputation clean matters here too. A VPS with compromised FTP or webmail credentials can become a spam relay overnight. See the email deliverability checklist for VPS hosting for the broader picture on mail security.

Step 7 — Reload Fail2Ban and Verify Jails

After saving all configuration changes, reload Fail2Ban:

sudo fail2ban-client reload

Check which jails are active:

sudo fail2ban-client status

You should see a list that includes sshd, plesk-panel, and proftpd. To inspect an individual jail in detail:

sudo fail2ban-client status plesk-panel

This shows the number of currently banned IPs, total bans since service start, and the list of banned addresses. If the jail shows zero monitored files, the log path is wrong — double-check it with ls -lh /var/log/plesk/panel.log.

Step 8 — Test That Blocking Works

The safest way to test without locking yourself out is to deliberately trigger a ban on a separate IP — use a different machine, a cloud shell, or a VPN endpoint that isn't whitelisted.

Attempt SSH login with a wrong password five or more times from that address, then check the jail status from your primary connection:

sudo fail2ban-client status sshd

The test IP should appear in the Banned IP list. Unban it manually when you're done:

sudo fail2ban-client set sshd unbanip 203.0.113.99

For Plesk panel testing, you can do the same from a browser on the test machine — enter the wrong password several times on the https://your-server-ip:8443 login page, then confirm the ban via sudo fail2ban-client status plesk-panel.

Step 9 — Set Up Email Alerts for Bans

Knowing when bans are triggered helps you spot targeted attacks early. Fail2Ban can send email notifications using sendmail or a compatible MTA. First, install the necessary package if it's missing:

sudo apt install mailutils -y

Then add the following to your [DEFAULT] section in jail.local:

destemail = admin@yourdomain.com
sender    = fail2ban@yourdomain.com
mta       = sendmail
action    = %(action_mwl)s

The action_mwl action sends an email with a WHOIS lookup and the relevant log lines attached — useful context when you're reviewing a ban. For a deeper walkthrough of the email alert configuration, the Fail2Ban email alerts guide covers additional delivery options.

Ongoing Maintenance and Log Checks

Fail2Ban's own log lives at /var/log/fail2ban.log. Review it regularly, especially after any Plesk update, since log format changes can silently break your regex filters. A filter that no longer matches anything won't throw an error — it simply stops banning.

Run a quick filter test against a known-bad log line using:

sudo fail2ban-regex /var/log/plesk/panel.log /etc/fail2ban/filter.d/plesk-panel.conf

If the output shows zero matches when you expected some, the regex needs updating. It's worth scheduling a monthly check — fifteen minutes of review is far cheaper than cleaning up after an account compromise.

Also keep an eye on your server's overall log volume. On busy Plesk servers, log files can grow quickly. If you haven't already configured automatic rotation, the logrotate setup guide for Ubuntu VPS walks through keeping that under control.

Frequently Asked Questions

Does Plesk have its own brute-force protection already?

Plesk includes a basic login protection feature under Tools & Settings → Security Policy, which can lock out an IP after repeated panel login failures. It's useful as a first layer, but it doesn't cover SSH, FTP, or webmail. Fail2Ban fills those gaps and gives you a unified, log-driven approach across all services.

What if Fail2Ban bans my own IP?

Unban yourself from a second connection (or the Plesk panel's terminal) using sudo fail2ban-client set sshd unbanip YOUR_IP. Then add your IP to the ignoreip list in jail.local and reload. If you're locked out entirely, most VPS providers offer an out-of-band console — Hostperl's control panel includes one.

Will Fail2Ban conflict with Plesk Firewall?

Not typically. Plesk Firewall manages persistent iptables rules for ports and services. Fail2Ban adds and removes temporary ban rules in the same iptables chain. They operate on different rule sets and don't interfere, though you should ensure Plesk Firewall isn't dropping Fail2Ban's chains during updates.

How do I see which IPs are currently banned?

Run sudo fail2ban-client status <jail-name> for any active jail, or check sudo iptables -L f2b-sshd -n to see the raw firewall rules Fail2Ban has inserted for the SSH jail.

Should I use Fail2Ban or CSF on a Plesk server?

ConfigServer Security & Firewall (CSF) is popular on cPanel servers and does overlap with Fail2Ban. On a Plesk server, Fail2Ban integrates more cleanly because it doesn't assume cPanel's file layout. CSF can be made to work, but requires additional configuration to avoid conflicts with Plesk's own firewall module. For most Plesk users, Fail2Ban is the lower-friction choice.