Webmin is one of the most powerful Linux server control panels available — and one of the most targeted. Running on port 10000 by default, Webmin's login page faces constant automated brute-force attacks from botnets scanning for weak credentials. A single compromised Webmin account gives attackers root-level access to your entire server.
Fail2Ban is the standard tool for blocking brute-force attacks: it watches authentication logs and bans IP addresses after a configurable number of failed login attempts. This guide covers setting up Fail2Ban specifically for Webmin, including Webmin's native Fail2Ban module (which most guides ignore entirely), multi-service jail configuration, and the procedures for managing banned IPs.
Why Webmin Is a Prime Brute Force Target
Several characteristics make Webmin particularly attractive to attackers:
- Predictable port — Port 10000 is Webmin's default across all installations. Automated scanners target it globally.
- Root access on success — Unlike SSH which might connect as a limited user, Webmin typically grants full root-equivalent control through its web interface.
- No rate limiting by default — A fresh Webmin installation has no built-in brute-force protection. An attacker can attempt thousands of passwords per minute without restriction.
- Exposed to the internet — Many server administrators don't restrict Webmin to a VPN or specific IP range, leaving the admin panel accessible from anywhere.
Fail2Ban addresses the rate-limiting gap by monitoring Webmin's authentication log and banning IPs after repeated failures — but only if configured correctly for Webmin's log format.
Step 1: Install Fail2Ban on Your Server
If Fail2Ban isn't already installed, add it via your distribution's package manager:
CentOS/RHEL/AlmaLinux/Rocky:
dnf install epel-release -y
dnf install fail2ban fail2ban-systemd -yUbuntu/Debian:
apt update
apt install fail2ban -yEnable and start Fail2Ban:
systemctl enable fail2ban
systemctl start fail2banVerify Fail2Ban is running:
systemctl status fail2ban
fail2ban-client status💡 None of these worked? Skip the guesswork.
Get Expert Help →Step 2: Configure the Webmin Fail2Ban Jail
Fail2Ban works through "jails" — each jail monitors a specific log file using a filter (regex pattern) and applies a ban action when the filter matches too many times. You need to configure a jail specifically for Webmin's authentication log.
ls -la /var/webmin/miniserv.log
# or:
ls -la /var/log/webmin/miniserv.logWebmin logs authentication attempts to miniserv.log. Failed logins appear as entries like:
Failed login from 192.168.1.100 for root : Invalid passwordCreate the filter file at /etc/fail2ban/filter.d/webmin-auth.conf:
[Definition]
failregex = Failed login from <HOST>
ignoreregex =The <HOST> placeholder is Fail2Ban's built-in pattern that matches IPv4 and IPv6 addresses.
Create or edit /etc/fail2ban/jail.local (never edit jail.conf directly — it gets overwritten on updates). Add the Webmin jail:
[webmin-auth]
enabled = true
filter = webmin-auth
logpath = /var/webmin/miniserv.log
maxretry = 5
findtime = 600
bantime = 3600
port = 10000Key settings explained:
- maxretry = 5 — Ban after 5 failed attempts
- findtime = 600 — Count failures within a 10-minute window
- bantime = 3600 — Ban for 1 hour (3600 seconds). Use
-1for a permanent ban - port = 10000 — The port Webmin listens on (adjust if you've changed Webmin's port)
fail2ban-client reload
fail2ban-client status webmin-authThe status output should show the jail is active with 0 currently banned IPs (until an attack occurs).
Log into Webmin, go to Networking > Fail2Ban Intrusion Detector. If the module doesn't appear, it may not be installed — go to Webmin > Webmin Modules and install "Fail2Ban Intrusion Detector."
The module's main page lists all configured jails with their status (enabled/disabled), ban count, and current banned IP list. You can see at a glance how many IPs are currently blocked for each service.
Click any jail to edit its settings through the web interface. The module lets you adjust maxretry, findtime, bantime, and the log path without manually editing configuration files.
When a legitimate user gets accidentally banned (common with sysadmins working from dynamic IP addresses), click the jail name, find the banned IP in the list, and click "Unban." This is significantly faster than the CLI equivalent and doesn't require SSH access to the server.
Step 4: Extend Fail2Ban to Protect SSH and Other Services
While configuring Fail2Ban for Webmin, set up protection for SSH and other exposed services at the same time. Add these jails to /etc/fail2ban/jail.local:
[sshd]
enabled = true
filter = sshd
logpath = /var/log/secure # CentOS/RHEL
# logpath = /var/log/auth.log # Ubuntu/Debian
maxretry = 5
findtime = 600
bantime = 7200
port = 22
[sshd-ddos]
enabled = true
filter = sshd-ddos
logpath = /var/log/secure
maxretry = 10
findtime = 120
bantime = 600For servers running Apache or Nginx:
[apache-auth]
enabled = true
filter = apache-auth
logpath = /var/log/httpd/*error_log
maxretry = 6
bantime = 3600
[nginx-http-auth]
enabled = true
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 6
bantime = 3600Reload Fail2Ban after adding new jails:
fail2ban-client reload
fail2ban-client status # shows all active jailsStep 5: Monitor Fail2Ban and Manage Banned IPs
View currently banned IPs for a specific jail:
fail2ban-client status webmin-authUnban a specific IP address (CLI method):
fail2ban-client set webmin-auth unbanip 192.168.1.100Check Fail2Ban logs for diagnostic information:
tail -f /var/log/fail2ban.logLook for entries like Ban 1.2.3.4 and Unban 1.2.3.4 to confirm bans are being applied and lifted correctly.
Test that your Webmin filter is working correctly:
fail2ban-regex /var/webmin/miniserv.log /etc/fail2ban/filter.d/webmin-auth.confThis command tests the filter against your actual log file and reports how many lines matched. If the match count is 0 when you know failed logins exist in the log, the regex needs adjustment for your Webmin version's log format.
Additional Security: Change Webmin's Default Port
Fail2Ban reacts to attacks — changing Webmin's port prevents automated scanners from finding the login page in the first place. Port scanners targeting port 10000 universally will miss Webmin if it's moved to an obscure high port.
In Webmin, go to Webmin > Webmin Configuration > Ports and Addresses. Change the "Listen on port" value to an unused high port (e.g., 47392). After saving, update your firewall rules to allow the new port and block port 10000, then update the port setting in your Fail2Ban jail config accordingly.
For comprehensive server hardening beyond Fail2Ban — including SSH key authentication, firewall configuration, and intrusion detection — CloudHouse's server hardening service provides a full security audit and implementation for Linux servers managed through Webmin or any other control panel.
FAQs
How do I know if Fail2Ban is actually blocking attacks on Webmin?
Check the Fail2Ban log: grep "Ban\|webmin" /var/log/fail2ban.log | tail -50. Each successful ban shows as "Ban [IP]" with the jail name. You can also check the Webmin module's GUI (Networking > Fail2Ban Intrusion Detector) which shows a real-time list of banned IPs per jail. If you see no bans but know attacks are occurring, verify the filter matches your log format with: fail2ban-regex /var/webmin/miniserv.log /etc/fail2ban/filter.d/webmin-auth.conf.
What's a good bantime setting for Webmin Fail2Ban?
For most servers, bantime = 3600 (1 hour) is a balanced starting point — long enough to stop attack scripts, short enough to automatically release accidentally banned legitimate users. For servers under heavy attack, use bantime = 86400 (24 hours) or -1 for permanent bans. Combine permanent bans with a whitelist (ignoreip = YOUR.IP.ADDRESS in jail.local) to protect your own access.
I accidentally banned my own IP. How do I unban myself without SSH access?
This is a critical scenario. If you have another IP address or can access the server via its console/VNC/KVM interface, run: fail2ban-client set webmin-auth unbanip YOUR.IP. If you have no alternative access, contact your hosting provider to either whitelist your IP at the firewall level or restart Fail2Ban (which clears all bans). Prevention: always add your static IP or IP range to the Fail2Ban whitelist: add ignoreip = 127.0.0.1/8 YOUR.STATIC.IP to /etc/fail2ban/jail.local.
Does Fail2Ban work with Webmin's built-in password timeout feature?
Yes, they complement each other. Webmin's built-in password timeout (configured under Webmin > Webmin Configuration > Authentication) adds a delay between login attempts, slowing brute-force attacks. Fail2Ban adds IP banning for persistent attackers. Use both: set Webmin's authentication timeout to 30-60 seconds AND configure Fail2Ban jails. The two-layer approach is more effective than either tool alone.
Should I use Fail2Ban or ConfigServer Firewall (CSF) for Webmin protection?
Both can protect Webmin, and they're compatible — you can run both simultaneously. CSF/LFD (Login Failure Daemon) is CSF's built-in brute-force protection that works similarly to Fail2Ban. If you already have CSF installed, LFD provides Webmin protection out of the box without additional configuration. If you only have Fail2Ban, the setup in this guide is sufficient. If you're managing multiple services and want centralized control, CSF's GUI integration with Webmin (via the CSF plugin) provides a cleaner management experience.