Guide Fail2ban on CyberPanel 3.0: Brute-Force Protection Without CSF (Tested)

Guide Fail2ban on CyberPanel 3.0: Brute-Force Protection Without CSF (Tested) - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: CyberPanel (https://adminsforum.com/Forum-cyberpanel)
+---- Forum: CyberPanel Guides & Tutorials (https://adminsforum.com/Forum-cyberpanel-guides-tutorials)
+----- Forum: CyberPanel Security Guides (https://adminsforum.com/Forum-cyberpanel-security-guides)
+----- Thread: Guide Fail2ban on CyberPanel 3.0: Brute-Force Protection Without CSF (Tested) (/Thread-guide-fail2ban-on-cyberpanel-3-0-brute-force-protection-without-csf-tested)

Fail2ban on CyberPanel 3.0: Brute-Force Protection Without CSF (Tested) - JAY - 10-26-2026

Fail2ban on CyberPanel 3.0: Brute-Force Protection Without CSF (Tested)

Older CyberPanel versions came with CSF (ConfigServer Security & Firewall), which also blocked IPs that kept guessing passwords. In CyberPanel 3.0 CSF is gone (

Code:

/firewall/csf

returns 404) and the panel has nothing that replaces the brute-force part. The firewall page only opens and closes ports. So every SSH and mail login guess just keeps coming. Fail2ban fixes that: it watches the logs and blocks an IP in the firewall after a few failed logins. We set it up on our CyberPanel 3.0 test server (Ubuntu 24.04) and found one jail that silently did nothing.

Step 1: See what's hitting your server
First, how bad is it? Our test server had been online for two days:
[Image: attachment.php?aid=577]

Code:

journalctl -u ssh --since today | grep -c 'Failed password\|Invalid user'
journalctl -u ssh --since today | grep -oE 'from [0-9.]+' | sort | uniq -c | sort -rn | head -5

8,889 failed SSH logins since midnight, almost 1,000 from each of the top addresses. (We blanked the last part of the IPs.) Note the first line: there is no

Code:

/var/log/auth.log

on this server. Ubuntu 24.04 cloud images often don't run rsyslog, all logs live in the systemd journal. Many fail2ban tutorials point at

Code:

auth.log

and would watch a file that doesn't exist.

The mail side gets the same treatment, just slower:

Code:

journalctl --since today | grep -c 'SASL LOGIN authentication failed'

gave 20 on our server (bots guessing mailbox passwords over SMTP).

Step 2: Install fail2ban

Code:

apt-get install -y fail2ban
fail2ban-client status

We installed it and looked at what the package had set up.
Good news on Ubuntu 24.04: the package's own

Code:

/etc/fail2ban/jail.d/defaults-debian.conf

already sets

Code:

backend = systemd

(read the journal, no log file needed) and

Code:

banaction = nftables

, and turns on the

Code:

sshd

jail. Within a minute of installing, the sshd jail had read the journal and banned the first 2 IPs. Version 1.0.2, no extra steps.

Step 3: Does it get along with CyberPanel's firewall?
CyberPanel uses firewalld, which also works with nftables. Fail2ban puts its bans in its own table,

Code:

inet f2b-table

, next to firewalld's

Code:

inet firewalld

.
Firewall changes are usually applied with a reload. We checked that fail2ban's bans survive one:
[Image: attachment.php?aid=579]

Code:

nft list tables
firewall-cmd --reload
nft list tables

Both tables were still there after

Code:

firewall-cmd --reload

, and the banned IPs were still in

Code:

addr-set-sshd

. So you don't have to switch fail2ban to a firewalld action; the default works. Bans also come back after a fail2ban restart (they're kept in fail2ban's database).

Step 4: The Postfix jail that sees nothing
fail2ban comes with a

Code:

postfix-sasl

jail, but its filter only looks for log lines from

Code:

postfix.service

. On Ubuntu 24.04 Postfix runs as

Code:

[email protected]

. We tested the filter against today's journal, without and with a fix:
[Image: attachment.php?aid=578]

Stock filter: 0 lines read. The jail would run, look healthy, and never ban anyone.
With the fix: 2,192 Postfix lines read, 19 failed logins matched.

The fix is a small override file, so package updates don't undo it:

Code:

printf '[Init]\njournalmatch = [email protected]\n' > /etc/fail2ban/filter.d/postfix.local

Test any filter yourself the same way before you trust it:

Code:

fail2ban-regex systemd-journal 'postfix[mode=auth]' | grep '^Lines'

(The

Code:

dovecot

filter matches

Code:

dovecot.service

, which is the right unit name on our server. It had 0 failures because the bots were going for SMTP, not IMAP.)

Step 5: Your settings in jail.local
Never edit

Code:

jail.conf

; put your changes in

Code:

/etc/fail2ban/jail.local

Code:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true

[postfix-sasl]
enabled = true

[dovecot]
enabled = true

[recidive]
enabled = true

bantime / findtime / maxretry: 5 failures within 10 minutes = banned for 1 hour. The default ban is only 10 minutes, which bots simply wait out.
ignoreip: add your own static IP here (space separated) so you can never lock yourself out.
recidive: watches fail2ban's own log and bans repeat offenders for a week across all ports.

Code:

systemctl restart fail2ban
fail2ban-client status sshd

After the restart, the three login jails on our server:
[Image: attachment.php?aid=580]

The

Code:

postfix-sasl

jail now shows

Code:

Journal matches: [email protected]

: proof that the override is active.

Step 6: Banned yourself? Unban
We tested ban, check and unban with a documentation IP (

Code:

203.0.113.50

, never a real host):
[Image: attachment.php?aid=581]

Code:

fail2ban-client set sshd banip 203.0.113.50   # ban by hand
fail2ban-client banned 203.0.113.50            # which jails ban this IP?
fail2ban-client unban 203.0.113.50             # remove it from all jails

Code:

banned

answers with the jail names (

Code:

[['sshd']]

); after

Code:

unban

the IP was gone from the nftables set. If you're locked out of SSH, run the unban from your VPS provider's console. Then add your IP to

Code:

ignoreip

.

What fail2ban doesn't cover here

The CyberPanel login on port 8090. We didn't find a ready filter for it. Protect it with 2FA and a strong password, and if you can, allow port 8090 only from your own IP in the firewall.
Website attacks (SQL injection, WordPress login floods). That's the job of a WAF: see ModSecurity on CyberPanel, plus a login-limit plugin for WordPress.
The best SSH fix is no passwords at all. With key-only SSH login the guesses can't succeed; fail2ban then just keeps the logs quiet.

More CyberPanel guides

Tested on CyberPanel 3.0 (build 8, OpenLiteSpeed edition) on Ubuntu 24.04 with fail2ban 1.0.2, October 2026.