If your Webmin panel is reachable from the public internet without IP restrictions, you are one brute-force campaign away from a full server compromise. Restricting Webmin access to trusted IP addresses is one of the most effective security controls a sysadmin can apply — and this guide shows you every method to do it correctly.
Why Webmin Needs IP Access Restrictions
Webmin runs on port 10000 by default and exposes a powerful administrative interface for your entire Linux server. Without IP restrictions, any IP on the internet can attempt to authenticate. Automated scanners actively probe port 10000 looking for exposed panels, and credential stuffing attacks against Webmin are routine.
IP allowlisting limits who can even reach the login page. Combined with strong passwords and two-factor authentication, it makes unauthorised access nearly impossible.
Common scenarios where IP restriction is critical:
- VPS or dedicated server with a public IP
- Webmin used for client server management
- Reseller or hosting panel exposed on a shared host
- Any server where the admin always connects from predictable IP addresses
💡 None of these worked? Skip the guesswork.
Get Expert Help →Method 1: GUI — Webmin IP Access Control Module
The easiest approach is Webmin's built-in IP Access Control page, which modifies /etc/webmin/miniserv.conf for you.
Open https://your-server-ip:10000 and log in as root or an admin user.
Go to Webmin → Webmin Configuration → IP Access Control.
Choose this option and enter each trusted IP, hostname, or CIDR network in the text box — one per line.
Accepted formats:
- Single IP:
203.0.113.45 - CIDR range:
192.168.1.0/24 - Netmask notation:
192.168.1.0/255.255.255.0 - Hostname:
admin.yourcompany.com - Wildcard domain:
*.yourcompany.com
Click Save. Webmin will write the change to miniserv.conf and apply it immediately. Test from an allowed IP to confirm access still works before ending your session.
Warning: If you accidentally block your own IP, you will be locked out. Always keep an SSH session open while testing so you can edit /etc/webmin/miniserv.conf directly if needed.
nano /etc/webmin/miniserv.conf
Look for an existing allow= line. If it exists, update it. If it does not exist, add it. Space-separate multiple entries:
allow=203.0.113.45 192.168.1.0/24 10.0.0.0/8
To block specific IPs instead of allowlisting, use:
deny=198.51.100.0/24
systemctl restart webmin
Or use the legacy scripts:
/etc/webmin/stop && /etc/webmin/start
grep "^allow=" /etc/webmin/miniserv.conf
Method 3: UFW Firewall Rules (Recommended Layer)
Webmin's built-in IP restriction controls access at the application layer. Adding a firewall rule provides a second, independent layer that blocks connections before they even reach Webmin's listener. This is best practice for defence-in-depth.
Block all access to port 10000 by default, then allow only your IPs:
# Deny all connections to Webmin port first
ufw deny 10000/tcp
# Allow your admin IP
ufw allow from 203.0.113.45 to any port 10000 proto tcp
# Allow your office CIDR
ufw allow from 192.168.1.0/24 to any port 10000 proto tcp
# Apply changes
ufw reload
Check the rules are active:
ufw status verbose | grep 10000
Expected output:
10000/tcp ALLOW IN 203.0.113.45
10000/tcp ALLOW IN 192.168.1.0/24
10000/tcp DENY IN Anywhere
Method 4: iptables Rules
If your server uses iptables instead of UFW, apply restrictions this way:
# Allow trusted IP
iptables -I INPUT -p tcp --dport 10000 -s 203.0.113.45 -j ACCEPT
# Allow office network
iptables -I INPUT -p tcp --dport 10000 -s 192.168.1.0/24 -j ACCEPT
# Block everyone else
iptables -A INPUT -p tcp --dport 10000 -j DROP
Persist rules across reboots:
apt install iptables-persistent -y
netfilter-persistent save
Handling Dynamic IPs and Remote Access
If your admin team does not have fixed IP addresses, use one of these patterns:
SSH tunnel (most secure option):
ssh -L 10000:localhost:10000 user@your-server-ip
Then browse to https://localhost:10000. Webmin is never exposed to the internet at all.
VPN-based access: Assign Webmin to a private VPN IP only. Block port 10000 on the public interface entirely, allow only on the VPN interface (tun0):
ufw allow in on tun0 to any port 10000 proto tcp
ufw deny 10000/tcp
Dynamic DNS allowlist: If your home IP changes but resolves to a consistent hostname, add the hostname to Webmin's allowlist and enable "Resolve hostnames on every request" in Webmin Configuration → IP Access Control. Note: hostname-based allowlisting carries a small DNS spoofing risk in adversarial environments.
Verifying and Testing Your Restrictions
After applying any IP restriction method, always verify from both an allowed and a disallowed IP.
From an allowed IP — expect the login page:
curl -sk https://your-server-ip:10000 | grep -i "webmin"
From a disallowed IP — expect a connection refusal or error:
curl -sk https://blocked-ip:10000
# Expected: connection refused or timeout
Check Webmin's auth log to confirm blocked attempts are logged:
grep "Rejected connection" /var/webmin/miniserv.error | tail -20
Combining IP Restrictions with Other Security Controls
IP allowlisting is a strong control but works best as part of a layered security posture. Pair it with:
- Two-factor authentication (2FA): Even if an allowed IP is compromised, attackers cannot log in without the TOTP code
- Fail2Ban: Bans IPs with repeated failed logins — catches mistakes from allowed networks
- Non-default port: Change Webmin from port 10000 to a high random port to reduce automated scanner hits
- HTTPS only: Ensure Webmin is running with a valid TLS certificate so credentials are encrypted in transit
- Disable root login: Create a named admin user and disable root-level Webmin authentication
If you need help implementing a comprehensive Webmin and Linux server security hardening policy, CloudHouse Technologies' server hardening service covers firewall configuration, access controls, and ongoing monitoring.
